Subject: Re: [rrg] Multiple critiques, choice of single proposal, consensus on constraints due to voluntary adoption?

From: [email-masked] (Noel Chiappa)
Date: Sat, 30 Jan 2010 13:40:20 -0500 (EST)

> From: "Joel M. Halpern" <[email-masked]>

    > 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 30 Jan 2010 13:59:44 -0500

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

---

From: Tony Li <[email-masked]>
Date: Sat, 30 Jan 2010 13:07:14 -0800

Hi all,

Speaking for myself, without input from Lixia (and this is thus 
non-binding):

Joel M. Halpern wrote:
> useful architectural principle, I guess I can't object.  

If someone were to propose text and get rough consensus on this, I would 
definitely be interested in adopting it.

> And I don't the the RG has a clear agreement on this at all.

I generally agree with this: we don't necessarily have the right 
characterization of the solution space.  However, I have to interject 
that I'm absolutely thrilled to see us actually having an architectural 
discussion.  I hope it progresses and refines itself quickly.

Tony

---

From: Patrick Frejborg <[email-masked]>
Date: Mon, 1 Feb 2010 09:47:41 +0200

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 <[email-masked]> 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.)
>
> 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.
>>    > From: "Joel M. Halpern" <[email-masked]>
>>
>>    > 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.
>>
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>