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.


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

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

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