Joel, I throw some thoughts into the CES/CEE debate - just some observations that I think might be interesting to share with you
A CES approach is preserving the hosts and applications, no changes needed there, right? But this is at the same time the biggest evidence that a CES approach is not really a true Identifier/Locator separation architecture - a CES solution engineers a certain address space (PI) from one repository to another, that is, from the DFZ routers' RIB/FIB to a mapping database. So why can't you then consider CES as a true Identifier/Locator separation architecture? We know that there are overloaded applications, which are carrying Identifier&Locator information in there headers&payload. You can detect them by forcing them to traverse a NAT device - two most common applications that I can think of is IPsec and SIP. These protocols will work nicely in a CES approach but in a CEE where a true Identifier/Locator separation is applied you get into trouble. It is also a well known fact that architecturally IPsec and SIP are broken, both are relying on IP addresses - so actually it is not the CEE's fault that you get into trouble with these kind of applications. And a new architecture comes with a cost, not everything can be preserved as such - if everything is preserved, then it can't be a new architecture. So is NAT really that evil as its reputation? NAT has forced the application people to decouple the location and identifier - from application's point of view, you can't really rely on the IP address since it might be changed in a middlebox. And this is good, applications that works well through a NAT middlebox shouldn't have trouble with a CEE architecture. About MPTCP, I think an identifier shouldn't be placed at all in the routing space, i.e. in the IP header, if you really obey the terminology that has been defined at: http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGTerminology Thus the identifier should be placed in the transport or application layer so the session can continue regardless of what is happening in the routing (locator) arena. This will open up the path towards host mobility that are not that heavily depending on a network architecture. This is also not about CES against CEE - we need a set of tools because what will get adapted by the end users is unknown, but it has to be cheap and it has to offer some new services or a path towards new services -- patte On Sat, Jan 30, 2010 at 8:59 PM, Joel M. Halpern <j...@joelhalpern.com> wrote: > If someone wants to add text on Identifier / Locator separation as a useful > architectural principle, I guess I can't object. Although we have not > actually done a very good job of articulating why it matters in conjunction > with things like Multipath TCP. (I think it does still matter. My point is > that we do not have a good description of why.) > > The question of IPv4 support is an example of something the RG has not > converged on. > > And I consider the CEE / CES debate to be missing the point. > Firstly, many of the solutions and not purely one or the other. As Noel has > observed, one can migrate LISP (ostensibly a CES solution) into the host. > Architecturally, and in terms of the end state, I think that CEE is a much > better target. > In terms of deployability and related issues, CES techniques tend to have a > big advantage. > Hence, I have a personal preference for solutions which straddle this > boundary, rather than seeing utility in arguing about which one we want. > And I don't the the RG has a clear agreement on this at all. > > Yours, > Joel > > Noel Chiappa wrote: >> >> > From: "Joel M. Halpern" <j...@joelhalpern.com> >> >> > I can not foresee any process which would come to an actual agreement >> > on a recommendation from the RRG, and therefore conclude that the >> > survey is probably the most effective outcome we can achieve as a >> > community. >> >> While I agree there's probably not agreement of a specific technical >> proposal, what about architectural direction(s)? E.g. I thought we did >> have >> rough consensus on the need for the separation of location and identity? >> >> True, the workshop a couple of years back (Amsterdam?) I think already >> recommended this, so we're not breaking a lot of new ground there; still, >> it >> would be useful to re-affirm that conclusion, in a larger group. >> >> And how about IPv4 support? Is a solution which doesn't support IPv4 >> judged to >> be plausible? Do most people agree with that one? >> >> Also, can we say anything about CEE/CES? I think a lot of people think >> that >> CES is sort of necessary for the short term, because any solution will >> never >> really get deployed otherwise. At the same time, there appear to be >> reasons >> that a solution has to be able to migrate in the CEE direction in the long >> term. I don't know how many agree with these, but it might be worth >> exploring >> that. >> >> Any others? >> >> Noel >> > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
