Lars, even the existing routing paradigms should be questioned. LISP doesn't do anything for Multicast, it doesn't do anything wrt the IPv4 depletion issue, it produces new update churn as to fight existing update churn. Or: Wasn't IPv6 the future? Now the new routing architecture is supposed to be backward compatible with IPv4 AND !!! IPv6. Hasn't IPv6 got its chance and didn't it miss this chance ? What about the orthogonality between intra- and interdomain routing protocols?! Isn't this a pity ? I mentioned Multicast and LISP above. I should defend LISP. All existing multicast models have an enormous flaw: they are not state-less. This can be changed and -imo- should be changed. Summary: There could be such a bright future for routing.But not if BGP, i.e. the distance vector algorithm, is considered a holy cow. Heiner In einer eMail vom 18.04.2008 19:29:10 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]:
Hi, thanks for your note - it does really make things a lot clearer. On 2008-4-18, at 0:07, ext Lixia Zhang wrote: > Further, once we have surveyed the solution space, we need to > develop rough consensus on the approach through the solution space. > Arguing about 'incremental deployment', for example, doesn't help > this at all. We need to first come to some agreement on the very > highest level branches in the decision tree (e.g., do we do map-and- > encap or translation or ???), and not worry about the detailed > leaves. That is up to the IETF to wrestle with. I hate to bring up the R-word, but I think before we can get to a consensus on architectural or technical directions for a solution, we need some consensus on what the requirements are for the architecture. What are the goals and non-goals? All the solution proposals on the table apear to have slightly different sets of problems they address, based on what the proponents of each consider important. The ongoing discussion intermingles arguments about which goals are important to address for a future architecture with which technical mechanisms are suitable to address them, and that's confusing (well, to me at least.) Lars -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
