On Feb 5, 2010, at 11:30 AM, Christopher Morrow wrote: >> [2] Let's not forget that it's not *just* routes in BGP, but just as >> importantly *paths* that has negative scaling implications, as well, on the >> control plane, (note slide 13): >> http://www.ietf.org/proceedings/74/slides/grow-6.pdf > > i agree that it's not just routes, it's not just paths, it's not just > speed of change (of either of the two previous items)... > >> ... and, keep in mind, there are things on the horizon (i.e.: add-paths, >> SIDR?) that may add _more_ state to be pushed around in BGP (should they see >> widespread deployment), which is scary. OTOH, on a more optimistic note, >> there are some additional enhancements that can make BGP more efficient, >> however it's unclear how much benefit several of the enhancements may >> provide as not all of them have been studied > > also agree with this, adding more state or more memory/cpu > requirements to existing systems is full of unknown consequences.
Not surprisingly, I completely agree with this as well. It's not just the number of prefixes in the current system, it's the number of unique routes (paths) to each prefix, the former of which is often 20x or more the number of unique prefixes in the system (today!), and any time any one of those prefixes has state change, all the paths see some piece of churn internal to a routing domain (and often inadvertently trigger external artifacts like suppression from damping, etc.). Each of those unique routes for a given prefix means more everything, including FIB I/O. IPv6 during long term transitional coexistence with IPv4 is just going to compound this. Surprisingly, all the work in IDR is about adding more state and paths and attributes and features, not dealing with this scaling issue. If the goal here is scalability, it's important to factor both inter- domain, AND intra-domain, and understand the issues with scaling in the current system. -danny _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
