Lazy Engineers and Viable Excuses

Tue Aug 26 13:55:30 UTC 2003

On Tue, Aug 26, 2003 at 09:35:57AM -0400, Leo Bicknell wrote:
> In a message written on Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote:
> > If folks want to filter, please, please, PLEASE, employ IRR
> > infrastructure and filter customers *AND* peers explicitly.
> > If your vendors have issues with this, push them to fix it.
> > Then you don't have to worry about bogons, max-prefixes,
> > route hijacking, de-aggregation, or...
> [snip]
> > Is it really that hard?
> 
> Yes, it is that hard.  Sadly, almost everyone I see push the IRR
> works for a small ISP.  And at least half of those work for a small
> ISP in Europe.

	C&W, Level3, Global Crossing and NTT/Verio are small isps?

http://infopage.cary.cw.net/Routing_Registry/mainpage.html
http://info.us.bb.verio.net/routing.html#VRR
http://www.irr.net/docs/list.html#LEVEL3
http://www.irr.net/docs/list.html#FGC (you need to replace gctr.net
with gblx.net)

	I'm not able to give you the skitter related metric for the
"core of the internet" as i'm getting connref from
http://as-rank.caida.org/cgi-bin/main.pl but please do review it
and comb the rest of the list at irr.net to get an idea of how much
of the internet actually is doing this and then think about if you're
in the majority or the minority.

> The fundamental problem with the "IRR Everywhere" notion is simple.
> If everyone filtered everyone, then, drum roll please:
> 
>     Every ISP on the planet would have to reconfigure their filters
>     for /EVERY/ customer change worldwide.

	Exactly.  And this is a bad thing how?  You can't plan ahead
and register route objects 24 hours in advance of a customer
being installed?

> Now, you can pontificate all you want about the things that would
> be better if you could filter every session, but the problems are
> going to be quite similar to the problems of scaling BGP.  BGP gets
> the routes to where they need to go today.  Any filtering system
> is going to move roughly the same data, and needs to move it roughly
> as quick (surely you don't think customers are going to wait three
> days for their internet access to work, do you?).  Just as we've
> had to do with BGP over the years, that's going to mean other built
> in safeguards a la dampening on the IRR infrastructure.
> 
> Plus of course, the IRR is actually /FAR WORSE/ than BGP.  Why?
> Well, with BGP there may be 20 possible routes between you and the
> destination, however only the best is in everyone's tables, with
> most of the backup routes "pruned" near the "edge" of the routing
> domain.  However with filters that doesn't work.  If I can hear a
> route from two providers I have to put it in both provider's filter
> lists all the time, or else when it fails and BGP switches over
> I'll reject the route, which is no good.

	If you misuse the IRR data as you state here, yeah,
your network will break.  Same thing will happen if you do other
bad things in configuring your network policy.  This is why network
operations are not for those armchair geeks, you can easily
cause significant unexpected problems as it relates to this.

> While filtering is very important on the customer edge, it breaks
> down for the same reasons when you talk about provider to provider
> filtering.  If UUNet can't trust Sprint to send it good, valid
> routes on the average there is a much deeper problem than filtering
> will ever solve.

	Yeah, but that's not what we're attempting to discuss here, we're
asking what hurdles (that are not self-errected due to improper policy
decisions) that honestly are preventing you from deploying irr type 
filtering.  (or that's what I think danny was trying to ask yesterday)

> In a message written on Tue, Aug 26, 2003 at 03:13:11AM +0100, Ian Mason wrote:
> > The trick is for IXPs and NAPs to have terms that *require* people to:-
> >         1) put their routes in an IRR
> >         2) keep them accurate
> > 
> > The LINX in London does (1) as a joining requirement and contractual 
> > obligation, and applies pressure where (2) cause a problem. How many others 
> > follow similar practices?
> 
> I'm going to pick on this example.  The LINX is interesting in that
> it is one of the most successful public fabrics worldwide.  That
> cannot be denied.  There own statistics
> 
> https://stats.linx.net/cgi-pub/combined?log=combined.bits
> 
> show about 23 Gig of traffic moves through there on a daily basis.
> 
> That said, the LINX is a drop in the bucket.  Top ISP's have
> individual customers with 10 Gig contracts.  Public peering in total
> is non-interesting to backbone providers, which is why so many of
> them don't do it.  To put this in perspective my own employer,
> AboveNet, who's agressive on public peering as large ISP's go does
> more traffic to our single largest peer than we do across all the
> public exchanges worldwide combined.
> 
> Even if IXP's and NAP's were able to ensure 100% filtering of the
> public participants it wouldn't make a measurable difference in
> the global internet.  Indeed, I suspect it would only serve to drive
> more medium sized player away from exchange points and to private
> interconnects with only the largest players.

	Hmm.. you are missing some of the benifits that I
see associated with this.  If I have a list of all the
prefixes that I could get sourced from MFN/above.net in a easily queryable
format, I can install anti-spoofing filters.

	There are also other uses for this data.  you could build
max-prefix numbers off of the irr data (for example).

	- jared

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.