In einer eMail vom 25.11.2008 01:57:17 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]:
wasn't able to make the IETF so I don't have any insight as to whether RRG community is converging or diverging. Regardless, it doesn't surprise me that not everybody agrees with any given point -- RRG is too large a community for that. However, I resonate with Brian's initial observation because if we restrict RRG to routing only, then we also restrict the diversity of solutions under consideration and are therefore converging on a common solution. IMO,we shouldn't restrict the view only towards the scalability and IPv4 depletion problem but CONCURRENTLY have in mind better routing - both for inter- and intra-domain routing. Current Multipath is just ECMP. But there are three classes of next hops, not only router which are a) closer but also which are b) equidistant and c) one hop more remote. The pretty simple TTL is still in place. On the one hand, this is self-serving on my part because the solutions that I resonate with are routing only. Some may argue that such a limitation would eliminate the best alternatives. I have two counter-arguments to that claim: 1) I don't discern any strong consensus building upon approaches involving host modification so if they are a better approach, the majority has yet to become aware of their superiority. See above. Routing in the network can be done much smarter and concurrently done such that the scaling/depletion problems are solved too. The time for smarter routing will have to come sooner or later anyway. Host-based routing may either be "taking advantage of the IP network layer" just like MPLS and Ethernet are utilized. Or: The host nodes become part of the network. But is this really wanted ? What are the arguments for doing so ? 2) If modifying hosts are out-of-bounds for RRG, then perhaps middleboxes can also be deemed out-of-scope as well? If this is the case, then we are just that much closer to convergence My personal belief is that I'd like us to converge soon on a routing-only solution. I think that it is time to begin to wrap the theoretical discussions up and proceed to modeling and simulation and limited deployment experimentation. How about tolerating alternative solutions concurrently? Particularly in case they do not cost neither memory nor performance time (by avoiding any update churn) ? Failing that, I would like to better understand why the RRG community hasn't yet converged on the desirability of map-and-encaps as a desirable RRG vector. I appreciate Tony's answers on this respect. Heiner
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
