Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward

From: [email-masked]
Date: Fri, 11 Nov 2005 04:59:40 +0200

Pekka,

I actually would like to see Applicability Statements for HIP,
MIP(v4/v6),
MONAMI, SHIM6, mSCTP, NETLMM, etc.

I actually think that we need to do a bit of thinking of how each piece
might live within the Internet, how you perform address selection 
when an application wants to get a new IP address (does it use the
HIP or MIP stack on it), etc. etc.

I'd like to see some quick diagrams of the stack calls; see what
happens when we have address agility - within a single interface
and across different interfaces.  

John

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>ext Pekka Nikander
>Sent: 10 November, 2005 19:27
>To: [email-masked]
>Subject: [arch-d] Mobility and multi-homing: Summary and going forward
>
>This is my biased summary of the Mobility and Multi-homing 
>discussion so far, with some suggestions of moving forward in the end.
>
>It looks like that this particular threat diverged quite fast from  
>its original topic, to other useful -- but different -- topics.   I  
>am ignoring the other topics here.
>
>I was able to find five distinct subtopics that seemed to be relevant:
>
>   1. Noel stated that if the architecture isn't rich enough,
>      we end up with feature-cancer.  Jari stated that mobility
>      does not involve just a single solution but a set of separable
>      pieces.
>
>   2. From an architectural point of view, it is clear that supporting
>      mobility and multi-homing must take place above the traditional
>      "deliver packet from this interface to that interface" 
>IP service.
>      Noel stated that the best suggestion so far has been the NSRG
>      concept of designing a new name space, somewhere above the
>      traditional IP service.
>
>   3. According to Noel, in a perfect world, a shim approach might
>      be better, but given the current state, bundling with new
>      transports may be easier.
>
>   4. There are different operational environments, and we need to
>      pay attention to deployment in these different environments.
>
>   5. The topic can be expanded to consider also other aspects of
>      mobility and multi-homing, such as service mobility within a
>      server farm, or denial-of-service protection.
>
>In the following, I ignore topics #4 and #5, not because they 
>are not important but because I consider #4 orthogonal to the 
>other discussion and #5 as a pure research issue for the time 
>being, with little direct engineering consequences.  However, 
>I do think that as time passes more generic concepts (like 
>service mobility) will become more important and we need to 
>keep them in mind in this discussion.
>
>The problem: Lack of richness in the architecture, or missing 
>name spaces 
>===============================================================
>=========
>=
>
>Noel noted that when the underlying architecture isn't rich 
>enough, in namespaces, mechanisms, etc, the approaches to add 
>functionality  
>that would require them will not be nice (ugly "bags on the side").   
>In my opinion, another way of stating the same (in this particular
>case) is that if we are missing a layer of indirection, any 
>attempt to add the functionality without adding a name space 
>will end up using one of the existing name spaces for multiple 
>semantically different purposes, make the solutions, in some 
>sense, ugly.
>
>There are a number of questions that need to be answered in 
>order to understand what kind of name space should be added to 
>the architecture.  Hence, my conclusion here is that we should 
>focus a little bit more on understanding what are the right 
>questions.  At the IAB list, some people recently asked 
>whether we have a good set of mobility requirements, and the 
>answer is apparently "no".
>
>Related to this, Jari made the comment that to him it seems 
>more important to break down the problem into separable 
>pieces.  While I sympathetic and certainly can see how certain 
>pieces of the problem (like attachment detection or path 
>exploration) can and should be seen as separate issues, I am 
>not sure if the core problem (need for a new layer of 
>indirection) can be split into subpieces.
>
>The solution and its nature: a new name space, shim or not 
>==========================================================
>
>It seems to be clear that mobility and multi-homing support 
>has to happen above the "deliver a packet from this interface 
>to that interface" layer, or what has traditionally been 
>considered as the core of the IP.  At this point we need to be 
>careful, as today's IP has package that is not really that 
>much interface-to-interface in nature any more; IPsec is a 
>prime example, in my opinion.
>
>Noel stated his opinion that the NSRG concept of designing a 
>new namespace, and deploying it one application and/or 
>transport layer at a time, was the best one.  Personally, I am 
>a little worried about this approach, as it seems to require 
>changing all transports and  
>applications.   Noel continued to state that in a perfect world he  
>would he'd go for a shim, but in real world he'd be more 
>inclined to bundle it with transports.
>
>I have a different opinion here.  I see two concrete 
>possibilities of going forward in a shim-like way.  One is 
>HIP, perhaps first deploying HIP with IP addresses as ULIDs 
>just in order to make early deployment easier, and then later 
>on proceeding to use HITs as ULIDs.  The danger of such 
>two-step approach is, of course, that we may fail to do the 
>second step, and that would be bad.
>
>The other alternative transition mechanism would be to start 
>using CGA, or something like CGA, to associate a public key or 
>other similar identifiers with ULID IPv6 addresses.  From a 
>semantic point of view the ULID would stand as a proxy for the 
>public key, the public key (or other identifier) being the 
>real end-point identifier.  Under this layer we could then run 
>shim6 with mobility extensions, HIP, or some hybrid of them.
>
>In any case, the goal of any transition mechanism like this 
>would be to gradually move into an architecture that does have 
>a new name space and a new layer of indirection.
>
>--Pekka Nikander
>
>
>_______________________________________________
>Architecture-discuss mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/architecture-discuss
>

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 10 Nov 2005 21:28:40 -0800 (PST)

> HIP or MIP stack on it), etc. etc.

Particularly interesting would be diagram of how all the above can (or 
can not) work together; and if some of them can not be used together
explanation as to why not and which of the technologies are exclusive
of the other ones.

P.S. Personally I think we need to evaluate ASAP if we really need
another layer in between IP and TCP/UDP and if it is needed then
design it in appropriate way with "base" layer protocol and additional
specification that use this layer (instead of designing several
protocols that each introduce new layers "close" to each other).

-- 
William Leibzon
Elan Networks
[email-masked]