Home page logo

nanog logo nanog mailing list archives

Re: Lazy Engineers and Viable Excuses
From: Jared Mauch <jared () puck Nether net>
Date: Tue, 26 Aug 2003 09:55:30 -0400

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...
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://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


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 () puck nether net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]