On Mar 22, 2007, at 4:27 AM, Eliot Lear wrote:
With the routing and internet areas working on ID/Locator split and the security and application areas taking notice, can we please be more specific about what problem we think we're solving?Specifically: * Are we concerned about routing table size? Is there a cache limitation? or * are we concerned about routing entropy on the wire? and/or* are we concerned about other control plane entropy internal to therouter associated with routing? or * are we concerned about something else?
I suspect one way to look at this is to ask what's going to break first? While I agree that FIB scaling issues exist, I suspect many of the folks most concerned today operate routers in the networks closest to the "Internet Core". As the denseness of interconnection in the global routing system increases, it's the internal network devices that are hit the hardest. Everyone is looking at external paths and unique FIB entries and there's clearly concerning growth there, but from all the data I've seen it's the number of *paths* that are internal to a given AS that are the most immediate problem. As I mentioned at the microphone in IDR, the number of paths on 'PEs' in SP networks seems to be anywhere from 300-800k (~1.5 - 3x the number of unique prefixes in the routing system), while in the core of the network the number of paths on iBGP speakers is often 10-30x the number of unique prefixes in the routing system (e.g., 3 'tier 1 ISPs' polled yesterday had from 3-5 million unique paths on 'core' route reflectors; I had routers with 2 million paths 7 years ago). This is largely dictated by the requirement that route reflection and/or AS confederations are needed to avoid a full mesh, and then one, or two, or three more are required to provide redundancy, and then that external denseness in interconnection increases and you end up with a ton of churn and update duplication, driving CPU cycles, DRAM, and even data<->control plane bandwidth problems. Furthermore, functions like BGP update packing are negatively impacted because of the number of unique path attributes grows (e.g., originiator IDs, cluster IDs, IGP metrics, MEDs, next hops, etc..). Then we make protocol changes to optimize implementations (e.g., BGP Route Reflection changes regarding whether client knows it's a client and whether RR reflects routes learned from clients back to that client) and the system level problem only gets worse. So you can either make things flatter, add more hierarchy, modify the protocol to support new scaling mechanisms, or design a new protocol -- all of the above introduce the usual offshoots (e.g., TCP session state v. route oscillation probability, etc.) In short, the growth curve for internal BGP speaker paths is much steeper than that of unique prefixes and general RIB data, and is highly topologically dependent. I believe there is opportunity here for short-term protocols, implementation and operational gains. FWIW, I believe that loc/ID split makes sense longer term, as discussed in another email I posted here earlier. -danny _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
