First note that I am not at all sure that the terms CES and CEE are even
useful. I will use them to respond to you, but since they largely
represent specific points in engineering tradeoffs, they actually make
the discussion harder.
From a deployment perspective, it is very useful if one can leave the
hosts, and the site routing, alone. Therefore, many of the proposed
solutions have either an end state or a transition state that leaves
those items unchanged.
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.)
As a minor point, SIP is probably a bad example to use in analyzing
these issues. SIP can be used in multiple ways. I believe you are
actually referring to the SDP message, which is frequently carried by
SIP, and which frequently carries an IP address. Note that if we had
resolvable identifiers which worked through NATs, and which had the same
syntax as IP addresses, those could be carried in SDP, possibly
improving the situation significantly.
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.
Yours,
Joel M. Halpern
Patrick Frejborg wrote:
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
