-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> * 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 the > router associated with routing? or > * are we concerned about something else? I suspect it is the last--that this problem really revolves around traffic engineering based on injecting longer prefix matches, rather than the routing table size, strictly speaking. The problem is, at the core, I think, that competing organizations have competing traffic engineering requirements, and the primary way to express those competing traffic engineering requirements is through the injection of longer prefixes. I think I've heard it said someplace that only about 1/4 of the typical ISP's table is Internet routes, while the remainder are internally injected or 2547bis, etc. Perhaps someone can confirm or deny this? Based on Vince's presentation, about 50% of the "internet" routing table is actually also injected for traffic engineer. Hence, we get to the point where an overwhelming proportion of any given routing table is there to engineer traffic flow, rather than to provide reachability. If this is true, this puts a new spin on the set of possible solutions. 1. Provide some different form of TE that uses something other than longest match routing. 2. Figure out where the routes injected for TE lose their usefulness, and remove them at that point. 3. Other (more creative) ideas.... I'm not certain how a loc/id split would "solve" this issue, if this is the issue.... One of the reasons I'd like to see a better problem statement is to better understand the actual problem. o Is it TE? o Is it table size? o Is the table size being driven by TE? o Is the table size being driven by sheer numbers of hosts? And then, beyond understanding that, I think it's important to look at the tradeoffs when considering a loc/id split. I'm not saying it's a bad idea, we just need to compare the doo we're stepping in to the doo we're actually in before taking that step. :-) Russ - -- [EMAIL PROTECTED] CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAnKdER27sUhU9OQRAg98AKC3AEd0ZxnI9I9BkhvCj1K5iNxVJwCeMEmm qOpUooUP8d28Z/qZB+mI89A= =0Dyw -----END PGP SIGNATURE----- _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
