Patrick Frejborg allegedly wrote on 02/01/2010 02:47 EST: > But this is at the same time the biggest evidence that a CES approach > is not really a true Identifier/Locator separation architecture
But that's okay. The goals of - robust scalable routing and addressing, and - weaning endpoint identification functions from location-dependent data are complementary but you do not have to satisfy them with a single piece of technology. In fact, if you decouple the solutions the whole system becomes more flexible. It would be fine if a CES approach takes care of scaling the networks and something else takes care of loc/id separation in the endpoints. > 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 Sounds good. Joel M. Halpern allegedly wrote on 02/01/2010 09:39 EST: > One of the reasons why I have not tried to write text about the value of > ID / Locator separation is that even within this limited community, > there have been significant differences is when the term "identifier" > should be used. In my book, an IEEE MAC address is an identifier. it > remains an identifier even if one is using a bridged network that is > forwarding packets based on that identifier. Other people have > different books, i.e. they use the terms slightly differently. > > Thus, for me, the question of whether a given bit string is an > identifier has to do with whether its assignment and usage is location > insensitive, rather than whether some forwarding system could use it. > (To take an extreme example, if compact routing for Internet traffic > worked, we could just use identifiers with no locators, and still have a > scalable system. The "locators" in that system are the landmarks used > for tunneling the traffic.) Note "assignment and usage". Exactly. A bit field itself may be intended to be used in a certain way, but what matters is how it is actually used. Any bit field can be used by a location function or an identification function or both. The problem is when usage doesn't correlate with assignment, and an identification function uses fields that are location-dependent. > the quesiton of what layer the identifiers are at is one that again > causes a significant difference of opinion. And also causes > complications. In a true MP-TCP environment, one might well want to > view the identifier as being above the TCP flows. On the other hand, in > a regular TCP environment, placing the identifier below TCP so that TCP > picks up a significant degree of locator invariance without needing > MP-TCP is also valuable. Hence, in terms of the abstract question of > whether some stable identifier has value, I do not want to get tied up > in the question of which layer should hold the identifier. Yes. That's a separate question from building a robust scalable routing and addressing system. In RRG, let's _assume_ that the endpoints work out their own LIS problems. Given that assumption (but also extrapolating what the endpoints will want to do, now that they have better architected stacks), how would you build routing? Scott _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
