Subject: RE: [netlmm] Dual Stack Moving Internet (DSMI)

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 8 Sep 2006 08:01:24 -0700

> I am against freezing any new, creative thinking. 

wow! 
lets not bottle anybody's creative thinking! :)

if there is an existing WG that is already addressing
the problem space, it would make sense to have the
discussion on that WG's mailing list.

Vijay

That's 
> simply impossible.
> Maybe this effort could produce something to replace netlmm, 
> which as Henrik said so far did not do much (I am just 
> quoting DT member), who knows?
>  
> Kindest regards to our new Co-chair.
>  
> Behcet
> 
> 
> ----- Original Message ----
> From: Vijay Devarapalli <[email-masked]>
> To: Henrik Levkowetz <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Sent: Friday, September 8, 2006 9:45:20 AM
> Subject: RE: [netlmm] Dual Stack Moving Internet (DSMI)
> 
> 
> agree with most of Henrik's comments.
> 
> Jari, Mark, perhaps we need a temporary freeze on 
> creating new BoFs/WGs related to IP Mobility in the 
> INT Area. 
> 
> Vijay
> 
> > -----Original Message-----
> > From: Henrik Levkowetz [mailto:[email-masked]] 
> > Sent: Friday, September 08, 2006 5:46 AM
> > To: Pekka Savola
> > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]
> > Subject: Re: [netlmm] Dual Stack Moving Internet (DSMI)
> > 
> > Hi Pekka,
> > 
> > On 2006-09-08 13:03 Pekka Savola said the following:
> > > On Fri, 8 Sep 2006, Henrik Levkowetz wrote:
> > >> on 2006-09-08 11:53 Sangjin Jeong said the following:
> > >>> As you already know, NETLMM WG works on IPv6 solution and
> > >>> it is likely to develop IPv4 solution later. However, 
> > when mobile nodes
> > >>> roam over IPv6 NETLMM and IPv4 NETLMM domains, maintaining IP
> > >>> connectivity during handover seems not to be trivial. I 
> > think that maintaining
> > >>> IPv6 connectivity in IPv4 NETLMM domains or IPv4 
> > connectivity in IPv6
> > >>> NETLMM domains does not look straightforward and requires more
> > >>> consideration.
> > >> Well, then we clearly disagree on this.  Since the user 
> > traffic is tunnelled
> > >> in the NetLMM domain, the underlying infrastructure 
> > doesn't matter to the
> > >> nature of the user traffic. [...]
> > > 
> > > Maybe there are different considerations, such as:
> > > 
> > >   - If a NETLMM network is v6-only, how can the 
> infrastructure send 
> > > tunneled packets to a v4-only NETLMM network as they have 
> > no common IP 
> > > protocol version?  (This is a more general IPv6 
> transition problem)
> > 
> > We have to be precise here, and distinguish between the IP 
> > version of the
> > underlying infrastructure, and the IP version of the user traffic.
> > 
> > I'm saying that the IP version of the underlying 
> > infrastructure doesn't
> > matter - it can carry both IPv4 and IPv6 in the tunnels, as 
> long as we
> > specify how.
> > 
> > Of course, if a MN is trying to reach a server with an IPv6 
> address if
> > the MN only has an IPv4 address, or vice versa, then we 
> don't have an
> > NetLMM problem, but the MN has a general IPv6 transition 
> > problem, which
> > is maybe what you're saying above.  But this shouldn't be solved by
> > NetLMM - NetLMM should only ensure two things, if we want to fully
> > support deployment on IPv4 infrastructure:
> > 
> >   * Be deployable on both IPv4 and IPv6 infrastructure
> >   * Be able to carry both IPv4 and IPv6 user traffic
> > 
> > >   - Are NETLMM domains (/implementations) required to 
> > support all the 
> > > possible user data traffic protocols?  IPv4 and IPv6, 
> > someone is bound 
> > > to come up with a case for IPX, AppleTalk, etc. as well 
> -- you name 
> > > it.  If I recall correctly, each of these may require a slightly 
> > > different MN-AR interface (at the very least). Will such support 
> > > always exist?  What if it doesn't, is it out of scope?
> > 
> > I would expect it to eventually be specified to support 
> IPv4 and IPv6.
> > 
> > If people want something else, they can propose extensions, 
> or define
> > vendor-specific extensions to handle this.  I don't see it as 
> > a primary
> > IETF concern.
> > 
> > >> No, till someone does a really thorough analysis and shows 
> > there are hard
> > >> problems to be solved, I maintain that this is trivial.  
> > Needs specification,
> > >> but no hard problems.
> > > 
> > > I'm not sure if this the right time to look at this because there 
> > > isn't even a WG draft on NETLMM protocol yet, so everything 
> > is subject 
> > > to change (for worse or better).
> > > 
> > > On the other hand, I agree that the problem being solved 
> > needs to be 
> > > clearer.  To me, the most important focus at first should be 
> > > identifying whether there are issues in federating v6 
> > NETLMM domains.
> > 
> > Agreed.  My personal belief is that this will be trivial 
> > (ooh, I'm really
> > repeating myself here) but an analysis is better than beliefs.
> > 
> > 
> >     Henrik
> > 
> > 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 
> 

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