Peering Policies and Route Servers

Wed May 1 19:44:36 UTC 1996

At 07:45 PM 4/30/96 -0400, you wrote:

>> 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? ;-)

Well, it'd be good for IOS code downloads ;)

>
>> >(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?)

Its no big deal to BigBackboneDude.  That /seems/ to be the attitude that
some of the larger backbone providers take, and I am not sure that I
completely blame them.  I.e.  Is it worth this level of effort both for me
and for my routers to add connectivity to this level of hosts?  If the
number of hosts is large it obviously is.  If it is small it may not be.
The problem is deciding where that line is.

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

You're misreading what I am saying, hopefully not intentionally.  What I am
saying is that Sprint, MCI et al are large snugh that they are absolutely
critical that they work 100% of the time, or as close to 100% of the time as
is possible.  If the route server hiccups, or they start implementing wierd
policies that cause me to lose connectivity to those people for /any/ amount
of time I am in deep kimshee.  If the route server screws up and decides I
can no longer talk to JustinsTinyISP, I have a little time to ditch the
route server and set up a private peering session with JustinsSmallISP
before it becomes a critical issue.  It is not that I don't want to hear the
routes for that provider it is simply that it may not be worth the resources
both on the router and in human manpower to setup a private peering session
with them.  The routers do have limits you know.  There is no "I don't much
need your routes anyhow" motivation anywhere.

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