Re: Peering Policies and Route Servers

["Justin W. Newton" <justin () erols com>]

At 10:49 AM 4/30/96 -0400, you 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
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.  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).  

> (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.  

> (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... 

> Regarding the RS (I have many friends there, and they have done many 
> good work), let me echo the fundamental issues that Steve Heimlich 
> has pointed out, would you rather have your peering policy enforced by 
> yourself or by a third party?  Would you rather develop a dependency
> on a third party (which may not be there a few years down the road)
> to deliver the critical service or depend on yourself? 

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).

> -- Enke (speaking only for myself)

Justin Newton                   * You have to change just to stay 
Internet Architect              *      caught up.
Erol's Internet Services        *