Re: Peering Policies and Route Servers
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 *
participants (1)
-
Justin W. Newton