|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: verio arrogance
This is all great and wonderful, except for one thing - the RIR allocation boundaries were never really meant to be used as "official" filtering prefix length limits. I certainly support Verio's right to filter on whichever boundaries make business sense to them. However, there is no denying that they have long been on the conservative side of filtering, and that this has caused problems for their peer's customers. Their policy causes a certain amount of difficulty for smaller multihomers, who may not have a RIR allocation. Currently, RIR's will issue an AS and will allow the issuance of a /24 to a multihomed enterprise, simply on the basis of being multihomed. From this point of view, it's easy to make the case that the proper "RIR-approved" boundary for prefix filtering should be at the /24 level. At any rate, Verio has been slowly liberalizing their filtering policy, and bring it into line with the rest of the industry. Two other things to consider, when discussing the economic impact of routing table size. When a carrier already is buying routers with sufficient memory to handle a very large routing table, the "cost savings" of a smaller routing table are illusory. The other thing to consider is that technically intensive support calls are relatively expensive to the provider receiving them, so that policies which encourage such calls should be looked at very carefully. This cuts both ways right now, as having enough routes to break BGP on a customer's 3640 will generate a support call, while causing reachability problems to people who lack clue to properly advertise their routes will also generate support calls. - Daniel Golding > -----Original Message----- > From: [email protected] [mailto:[email protected]]On Behalf Of > Stephen Griffin > Sent: Friday, July 26, 2002 10:24 PM > To: Stephen Stuart > Cc: [email protected] > Subject: Re: verio arrogance > > > > In the referenced message, Stephen Stuart said: > > > > > I can't really see why, as long as the provider has punched the > > > appropriate hole for your aggregate in their filters. More specific > > > routes always win out. Or am I missing your point? > > > > The point, I think, is the effort involved in using global route > > announcements to solve your traffic engineering problems. > > > > When you use provider-assigned space, you have to coordinate your > > intent to add entries to the global routing table with the provider > > who assigned the space and the providers that you want to accept the > > new routes. > > > > When you use provider-independent space, you get to decide to add > > entries to the global routing table pretty much all by yourself, > > modulo running afoul of the occasional provider that does not, by > > default, buy into solving local traffic engineering problems in other > > people's networks using global routing table entries. > > > > Stephen > > Not to mention that the common retort is that everyone else in the world > should upgrade their CPU and memory to solve a third parties traffic > engineering problem. Thereby transferring the cost to others. > > The verio (and others) mechanism involves a stated policy soundly > derived based upon RiR allocation policy. A policy which, if everyone > announced their aggregates would lead to no blackholes during > steady-state. > > If parties feel the need to exchange long prefixes, they can do so > privately, without infecting everyone. In fact, many providers exchange > regional routes, tagged no-export, for such mutual agreed-upon optimal > traffic exchange purposes. This should, however, be constrained to those > parties who mutually agree upon it. > > However, there are some who want to handle their traffic engineering needs > preferably by transferring the costs to others. This is just shady, even > if it makes perfect "business sense" from a capitalistic "maximize profit > no matter what the consequences" mind set. > > I wonder how the anti-filter folks would feel if all of their > providers/peers > ceased filtering out iBGP routes on the sessions facing them. Would they > begin scrambling to filter? If so, where would the line be drawn? Some > arbitrary prefix-length, or based upon a published length obtained from > some allocation authority? What about if everyone ceased filtering > out their iBGP routes, and just leaked it all? Looking at only a single > router, I could add another 8538 prefixes into the routing system. > Certainly everyone could handle 9k more prefixes, right? Ok, then we get > to do that across all my routers. Then across all providers. This > is all in > the name of optimal routing, right? What's a couple million routes between > friends? >
|