Peering Policies and Route Servers

Matt Zimmerman mdz at netrail.net
Tue Apr 30 23:45:03 UTC 1996


On Tue, 30 Apr 1996, Justin W. Newton wrote:

> >    Unrestricted peering policy would accelerate rolling of the
> >    snowball, and lead to the collapse of an interconnect. In order
> >    for Internet to survive, this snowball effect got to stop.
> ... or the hardware has to be manufactured to support it.  /Some day/ there

If the current trend continues, IXP's may start seeing exponential growth
curves, especially as more of them emerge.  I can't think of very many
hardware manufacturers that have been able to keep up with that kind of
demand for better equipment.  Hardware can be designed and built to meet
demands on performance, sometimes even on cost.  Growth is much more
difficult to account for.

> are going to be 500 companies at the interconnects, and they are /all/ going
> to be important players, or that is at least a likely scenario.  Will this
> be next year?  No.  Unrestricted peering policies are gone, the internet is
> not what it once was.  "There was a day when anyone could peer with
> anyone..."  Yeah, there was also a day when the backbone was uucp serial
> links, I don't hear you mourning that.  (generic you, not specific)  The
> internet has frown.  There are some things which can be done on a handshake
> and a smile, a global network isn't one of them.

Dunno about you, but I don't recall a day of unrestricted peering.  There
may not have been lawyerized, codified policies you see now, but you still
had to convince NSP X that you knew what you were doing.  Said policies
are allegedly attempting the same thing, but that's another thread.

> Heck, if all I needed was a connection to the MAE to get global routing,
> I'd run a ds-3 to my house and be done with it (its only about 3 miles
> from my house to MAE East, maybe 5).

Hmm...how many PC's and workstations do you have at home to fill a DS3
with? ;-)

> >(2) There is no connectivity gain for a national provider to peer
> >    with a single-attached organizaiton as all these organizations have
> >    transit providers that are present at multiple interconnects.
> This is a chicken and egg scenario.  If CompanyX could get to everywhere
> without buying a link to an upstream as well as their connection to the MAE,
> well, then they wouldn't buy the connection to the upstream provider.  The
> real point should be that losing connectivity to all whopping X,000 of their
> customers where X is between 1 and 9 is really not all that big a deal,
> netwise.

Not a big deal to whom?  It certainly is to those customers, and to
CompanyX.  And probably to a percentage of the rest of the net.population,
who now can't get to Joe's Whiz-Bang homepage.  And who's making a
decision on whether they have connectivity?

(or what does this have to do with chickens and eggs?)

> >(3) There is a huge investment involved to build a national backbone.
> >    Many providers currently do "hot-potato" routing (closed-exit)
> >    because of this cost. Peering with a single-attached organization
> >    would require much more backbone investment as traffic to this
> >    organization needs to be carried across the backbone, while the
> >    cost for this single-attached organization would be small (one
> >    DS3 to an interconnect).
> This is somewhat of a paper tiger.  This singly homed is also not nearly so
> likely to generate as much traffic as some of the larger backbones, and you
> are only carrying /your customers'/ traffic to them.  One way or another, so
> long as you are peering and not transiting, any packets that cross your
> network are for the good of /your customers/.  Please keep that in mind, but
> I digress...

Actually, you're very much on-topic, and this is true; however,
closest-exit/hot-potato routing depends on asymmetric division of traffic
to share load between peers.  The one who ends up backhauling the traffic
is the one with the bicoastal DS3 backbone, with none of the load shared
by the single-homed peer.  Were the single-homed peer not single-homed,
the large peer could hand off the "potato" much closer to its source.

[RS peering]
> As a representative of Erol's I can say that I would want to directly peer
> with MCI. Sprint, ANS, UUnet and a few others, all of the people annoucing
> one or two routes I would likely be better serverd as hearing through the RA
> until which time as I have lots of free processor/memory/everything else on
> my router doing the peering, at which point I would be more than willing to
> peer with anyone who I could be assured was technically competent.
> (Basical;ly I am not /dependant/ on getting to a lot of those smaller sites,
> so I don't very much care if I lose them somehow).

This is a risky attitude.  Simply because those sites are smaller than you
doesn't mean you can force them down by refusing to peer.  You do have a
relatively large dialup customer base, but explaining to your customers
exactly why they can't get to <interesting route> from your service, but
can from GrumbleSmurf down the road, can be tricky when you burn bridges.
I'd place more emphasis on the "technically competent" aspect of your
policy than the "I don't much need your routes anyhow" motivation.

// Matt Zimmerman       Chief of System Management           NetRail, Inc.
// mdz at netrail.net                                       sales at netrail.net
// (703) 524-4800 [voice]    (703) 524-4802 [data]    (703) 534-5033 [fax]





More information about the NANOG mailing list