Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

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

RE: /24s run amuck again

  • From: Dave Israel
  • Date: Sun Jun 10 18:32:10 2001

[Rant below.  My apologies.  Sometimes, your spleen needs a-ventin'.]

I know I'm behind on this conversation, but I want to say that, for
the record, Bellovin's presentation, and the resultant "You're not
paying me for my routing table, you bastard" sentiment, drives me up a
wall.  BGP is for setting and sharing policy.  If you don't want to
listen to somebody else's legitimate policy, the right answer is not
to filter that policy; the right answer is not to peer.  If you're not
interested in policy decisions, you can get static routes by examining
the routing arbiters or even the registries' records.  

Despite what some venders want you to believe, memory is cheap,
processors that can handle the Internet routing table are cheap, and
the only really expensive things to build in a router are the high
speed line cards and the forwarding engine(s) to push them.  If we
were running the Internet on 68020 processors over 56k and T1 lines
still, you would have a point.  But the additional load of allowing
other people to set their policy as they see fit is not a relevant
concern on modern equipment.

There are lots of legitimate reasons for making announcements like
this.  One is backup connectivity; if the primary fails, and you're
filtering the backup, you might not be taking the best path to the end
user.  In fact, if you're well connected, you're passing it off to the
primary, who, if he is filtering as well, won't pass it off to the
secondary, and if he's not filtering, you're transiting when you don't
need to.  At a bare minimum, you're putting the decision off to your
provider, in which case, why are you peering in the first place?
Another is load sharing; if I have 60MB of traffic for my site, and I
have two T3s, I might set policy to try to equalize that data.  If you
ignore my policy, you might overload one of the links and not be able
to reach my site.  I suffer, your customers suffer, eveybody gets
pissy, because you didn't have 2k of RAM to share with a fellow member
of the Internet whose down on his luck.

You should do this to be a good neighbor.  You should do this to be
charatable.  You should do this because you might need it yourself

Now, before anybody gets the wrong idea, yes, I know there are people
who announce their supernets as /24s or smaller because of technical
incompetance.  The ISPs should do what they can to prevent that; I
know that we have historically been rat bastards to our customers who
wanted to make smaller announcements and couldn't tell us why.  And
there are people who are running old hardware, or are being victimized
by 800% markup by the vendor, or otherwise really cannot spare the
cycles and the RAM to support other people's policy.  You gotta do
what you gotta do.  But hogging cycles you aren't using, and memory
that is sitting idle, on some sort of "You're not paying me"
principle, is just absurd.


On 6/9/2001 at 13:47:15 -0700, Randy Bush said:
> >>> There are lots of reasons to have some diverse /22 announcements in your
> >>> network for example.
> >> but if you are not paying me, what reasons are there for me to spend
> >> my resources (route bloat) so you can engineer your traffic?
> > The fact that your other customers are paying you to reach everyone on the
> > internet?
> red herring alert!  the point is not reachability.  the aggregate is still
> available.  see bellovin's phoenix presentation.
> randy

Dave Israel
Senior Manager, IP Backbone
Intermedia Business Internet

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.