Hi all, On Thu, 2009-11-26 at 02:49 -0500, Joel M. Halpern wrote: > One related side effect is that the mapping system can take > responsibility for providing traffic engineering information for such > sites, so that we do not have to use dis-aggregation for multi-homed > edge sites' traffic engineering. >
But even if traffic engineering is handled elsewhere, how much of deaggregation is rooted at TE and how much for other reasons? . All of the recent proposals and rrg discussion seem to focus on re-empowering aggregation by attempting to pinpoint the reasons for deaggregation and dealing with them. A lot of reasons have been brought up, such as PI usage, ingress TE, avoiding renumbering, etc. Yet, it is unclear how much each 'cause' contributes to overall deaggregation. I wonder if it would be preferred to have a solution that allows networks to shield themselves from routing table bloat, regardless of the causes behind long-prefix announcements - a cause-agnostic solution. > While there have been some inter-domain variations on > virtual-aggregation suggested, the primary applicability of tat > technique is intra-domain. While it has the potential (if we can > deal > with configuration complexity and issues such as loose source policy > application) to provide a significantly larger than 30% win, it is > still > largely a short term technique designed to help us keep functionaing > while we get to an architecture that works better. I understand why local FIB aggregation is just a short-term solution, but why do you consider VA a short-term solution? According to the RRG design goals draft, VA fits all the 'required' goals. VA allows networks to scale down their tables to any arbitrary size by re-enabling aggregation within the network. It's also deployment-friendly. I can see why one would want to add to VA to achieve some of the 'strongly desired' goals, but I don't think VA should be considered 'short term', as it does help with our primary goals for the long haul. Dan Jen _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
