You can't do proxy aggrigation without consent!!! You WILL create policy violations as well as destablizing global routing. Forget any concept of 'forced proxy aggregation'!!!! Tony, yell all you like. How will you stop someone? As we mentioned at IETF, folks will have to do proxy aggregation unless there is substantial aggregation happening just so that they can survive. Well, I suppose Tony H. could offer to buy us all 64Mb routers if he's so concerned about us creating policy problems for him... As for destabilizing global routing - we're going to have plenty of opportunity to experience that if we *don't* deploy aggregation; routers which crash and reboot every 5 minutes because they are out of memory do simply delightful things to routing stability. Question to the MERIT folks: have you had any luck (and have you tried) using the ASxxx@MERIT.EDU mailing lists to try and get in touch with those non-BGP4 sites which might not be on the BGPD or Regional Techs mailing list? I'm likely asking the obvious, but... --Vince
Tony H., 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. In terms of the policyful routing implications: can we get some idea of those long prefixes that are needed to satisfy policy constraints? I would think that it is incumbent on those who need this information to collect it and then determine how to get these prefixes propogated to them. I suspect that most policies involve networks that already peer with each other directly and this sort of policy (specific vrs aggregate prefix) negotiation will be done on a peer by peer basis. 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. 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
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.
participants (3)
-
Curtis Villamizar -
Peter S. Ford -
Vince Fuller