|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Lazy Engineers and Viable Excuses
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.
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.
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.
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.
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.
Almost everyone filters customers. The large ISP's all have the
same opinion, if small to medium sized players abuse the system
they get depeered and become someone's customer aggressively filtered.
The large ISP's then trust each other to do that aggressive filtering.
So be careful if you advocate filtering. The IRR, with everyone
doing an update for every customer worldwide does not scale, but
depeering all the smaller peers and letting a few big guys sort it
out does. I don't think that's the result most people pushing
filtering want.
--
Leo Bicknell - [email protected] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [email protected], www.tmbg.org
Attachment:
pgp00058.pgp
|