Re: 20402 routing entries

[Curtis Villamizar <]

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.