Verio Peering Question

Sat Sep 29 20:09:49 UTC 2001

> > The only kind of prefix filtering I would want to implement is
> > something that can accomplish:
> 
> [ snip ]
> 
> An interesting thought.  Group BGP adverts / table updates by
> prefix length... get connectivity up and going, then chew on
> the smaller details as needed.  Sort of like real-time process
> priorities; if you can get there, queue longer prefixes until
> _after_ all others have been processed.

assuming you're router can store, process and switch against n x million
routes in real time .. suspect technology will take us there but you want
to try and influence people to hold back, else we'll all suffer on the day
the internet reaches critical mass and routes overtake technology and all
providers routers give up!

> Seems to me that "saving the Internet" means strict ingress
> filtering[1] of downstreams and strict egress filtering[2] to
> peers and upstreams... which is pretty much the opposite of what
> Verio does.
> 
> [1] Providers SHOULD filter/aggregate downstream routes, unless

Two different subjects? Filter definitely, you want to ensure quality and
sanity. But aggregate... hmm, dont think that'll work with commerical
people. A customer multihomes and you aggregate whilst a.n.other
doesnt.. a.n.other gets all the traffic and you become the secondary
provider and let a.n.other get all the new business as primary!

> [2] Want to tune inbound traffic?  Fine... advertise those longer
>     prefixes to your upstreams/peers.  But don't make the rest of
>     the Internet suffer.  Communities good.  Extra routes bad.

but people dont advertise long prefixes in order to simply make use of two
providers for the sake of it, they do it in order to create their own
unique routing policies which by definition needs to be internet-wide

i would envisage all kinds of problems too where the aggregating upstream
accepts your specific routes via another isp by mistake and then your
transit traffic ends up going all round the place.. you'd be advertising
/24s to peers and all but one transit, with primary transit aggregating up
to /16 or whatever, feels bad..

> > I'm sure in reality there's many reasons this would not be able
> > to be implemented (CPU load perhaps) but it would atleast do
> > something more than a "gross hack" that nails some offenders,
> > not all by any means, and impacts multihomed customers who are
> > only a portion of the problem that the current prefix filtering
> > solution does not solve.

as i say, only one transit can aggregate, the other one cant unless they
both assign blocks and one uses nat.. but then it gets ugly and eats up
IPs

Steve

 > 
> Filter/aggregate as close to origination as possible.
> 
> "Be conservative in what you send, and liberal in what you
> receive."  Haven't I heard that somewhere before?  (Bonus points
> for anyone who can name the RFC without wimping out and using a
> search like yours truly alas had to do.)
> 
> 
> Eddy
> 
> ---------------------------------------------------------------------------
> Brotsman & Dreger, Inc. - EverQuick Internet Division
> Phone: +1 (316) 794-8922 Wichita/(Inter)national
> Phone: +1 (785) 865-5885 Lawrence
> ---------------------------------------------------------------------------
> 
> Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
> From: A Trap <blacklist at brics.com>
> To: blacklist at brics.com
> Subject: Please ignore this portion of my mail signature.
> 
> These last few lines are a trap for address-harvesting spambots.  Do NOT
> send mail to <blacklist at brics.com>, or you are likely to be blocked.
> 
> 

-- 
Stephen J. Wilcox
IP Services Manager, Opal Telecom
http://www.opaltelecom.co.uk/
Tel: 0161 222 2000
Fax: 0161 222 2008