North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Lazy Engineers and Viable Excuses

  • From: Leo Bicknell
  • Date: Tue Aug 26 10:13:21 2003

In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote:
> > 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?

Please correct me if I'm wrong, but they all use the IRR to filter
customers.  That's a fine application of the IRR, and one I encourage.
I don't think any of them use the IRR to filter peers.  Indeed, I
can provde they don't filter certian big peers due to the fact they
don't register thier routes at all. :)

My rant is on peer-to-peer filtering.  Customers should always be
filtered by every ISP.  Period.  ISP's should automate that as much
as possible for their customers, and using the IRR is a fine solution.

> >     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?

It's a bad thing because it doesn't scale.   It's not a matter of
before or not, it's that there is a linear relationship between the
size of the internet and the processing needed to be done by each
ISP.  That doesn't scale.

> 	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/ in a easily queryable
> format, I can install anti-spoofing filters.

No, you couldn't.  Please go back and take routing 101 again.
Internet routing is asymetrical, the source of the packet has nothing
to do with where the return route points in the core.  If it were that
simple we could just use Unicast RPF on all peering links and spoofing
would be a thing of the past.

       Leo Bicknell - [email protected] - CCIE 3440
        PGP keys at
Read TMBG List - [email protected],

Attachment: pgp00060.pgp
Description: PGP signature