Lazy Engineers and Viable Excuses

Wed Aug 27 13:36:02 UTC 2003

In a message written on Wed, Aug 27, 2003 at 12:15:18AM -0400, John Payne wrote:
> If this is true, then why do the european NAP mailing lists (which push IRR 
> filtering) have an almost constant stream of "oops, our customer announced 
> everything to us and we leaked it".

Because European naps have more smaller and clueless players.  I
know more than a few people (because they ask for peering) who have
an IRR entry that is 1 prefix for the "ISP", and 1 prefix for their
only BGP customer.  It should be of no surprise they get that
customer configured wrong.  It should also be of no surprise that
most of the real ISP's would never consider peering with those types
of networks.

Of course, those small and clueless players exist elsewhere, but in
general you don't see them connected to exchange points in other parts
of the world.

> Filtering peers is not the way to go.  Filtering customers and "trusting" 
> peers to do the same is.  (Whether that trust explictly mentioned in a 
> peering agreement or whatever).

You're right, but you missed a part of that solution.  ISP's should
filter customers, and "trust" peers to do the same.  That also means
they need to qualify their peers in some way to insure they aren't
peering with someone who doesn't understand that.

> Just a shame that not everyone filters their customers.  And although it 
> has been a while, I know I've seen a route-leak from 6461 at AMS-IX.
> (Probably last year sometime)

6461 filters all customers by prefix list.  Note too, filtering
customers does not eliminate route leaks, it just removes the most
obvious and often cause.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20030827/5488e358/attachment.sig>