Peter,

It may become necessary to do proxy aggregation in the interest of preventing people from blowing up. Certainly proxy by consent is the best approach, and I am sure we can get a lot of consent by telling people that they will be disconnected from someone otherwise.

The are a few potential large aggregates who 1) peer us in more than one place, haven't allocated among their aggregate according to proximity to an exit point, and need the load split, 2) peer us in one or more places and peer another provider and split their traffic, 3) are not BGP4 capable and have asked for proxy aggregation and peer one or more other providers. The first case we can handle and I think we are ready to handle Suranet and CANET this way (I think we have discussed this with others, but aren't as far along). The second case requires us and another provider to take aggregates and a more specific route and block further propogation of the more specific routes at all borders to other parties (I think there is at least one case of this - PREPnet maybe). The third case is a mess since two or more providers must do proxy aggregation (I know there is at least on such case - DSI). [BTW - In DSI's case, it appears that we could proxy aggregate since the back doors are individual DSI sites and don't provide transit for other parts of DSI. We found a bug in proxy aggregation that affects DSI and have held off on this for the moment. One of the problems has been DSI must find all site for which the backdoor is a backup so we can also announce those components and not turn the backup into the primary. I'm not sure how current I am on the DSI situation, so DSI's homework may already have been completed.] Please note that in all of these cases, ANS continues to carry the components (at least site aggregated though). In addition at all of our borders we accept more specific routes (and propogate no further than the border) to get the next hop right (preventing overload of border interfaces and/or regional routers). In 1) we are taking on a large configuration burden for the benefit of others. In 2) and 3) we are willing to take on a configuration burden if the other provider(s) are capable of doing the same. The BGPD workerbees are finding out that there are more backdoors than anyone imagined. The community as a whole has little choise but to move forward in a way that will not break routing. So far I don't think we have encountered unreasonable opposition to aggregating (Elise can correct me if this is wrong).

Also, isn't it possible to configure things such that a specific route can be generated upon hearing an aggregate? (yuk) This has the nice "feature" of placing the policy burden on those networks which are the most policyful.

I suspect that if one transit provider did this, some of their customers would have no choice but to scream and threaten to change providers on the basis of breach of contract for not providing full connectivity. The problem with this is that the aggregate could lead to a black hole for valid destinations.

By the way, is it time to start looking for people/networks to renumber? (I feel like an ice cream vendor on a hot day)

peter

Who wants to go first? We've helped a few customers renumber in the past (for other reasons) and it is costly in terms of people time and service disruption. It can be weeks before the last of the single user OS and privately administered systems are discovered and changed. Curtis BTW - I don't think all of this discussion is getting us anywhere.