Subject: Re: [netlmm] Re: [elm] Re: SDOs and NETLMM WG

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 9 Mar 2007 09:38:15 -0800 (PST)

Hi Raj,
  The point Alex is making I think is that IPv4 support using DSMIP is probably good but it should not be part of the base PMIPv6 protocol.

Regards,

Behcet

----- Original Message ----
From: Basavaraj Patil <[email-masked]>
To: ext Alexandru Petrescu <[email-masked]>; Sri Gundavelli <[email-masked]>
Cc: [email-masked]; Singh Ajoy-ASINGH1 <[email-masked]>; [email-masked]
Sent: Friday, March 9, 2007 11:17:24 AM
Subject: Re: [netlmm] Re: [elm] Re: SDOs and NETLMM WG

Alex,

There was/is a good reason why in the case of DS-MIP6 the use of
Teredo/ISATAP/6to4 were not used. You have proposed these for consideration
in the design of DS-MIP6 as well and are well aware of the reasoning that
went into why none of these were chosen.
PMIP6 is essentially an off-shoot of MIP6 (albeit host involvement) and
hence the use of the same design principle that went into DS-MIP6 for IPv54
support can and are being applied here as well.

No doubt that the IETF has developed many different transition mechanisms
and you can pick and choose which makes sense. In the case of MIP6 and PMIP6
the entities that are at play are the MN, PMA and the HA (some or all of
these being DS). The preference would be to enable IPv4 support as well as
transition mechanism within the context of these elements. So while you can
argue about using a standardized transition mechanism, I do not see any of
these being a good fit for the MIP6 and PMIP6 scenario.

-Raj

On 3/9/07 10:48 AM, "ext Alexandru Petrescu" <[email-masked]>
wrote:

> Sri Gundavelli wrote:
>> Alex,
>> 
>> 
>> 
>> On Fri, 9 Mar 2007, Alexandru Petrescu wrote:
>> 
>>>> 
>>>> KC> I don't think we should take the IPv4 support out of the base
>>>>  spec. It is very important that the base spec supports IPv4 and
>>>> IPv6 (addressing and transport) so that a comprehensive solution
>>>> is available ASAP. The draft-sgundave has this support, and I
>>>> don't believe we need to take this out.
>>> 
>>> The question is _how_ to support IPv4 support.
>>> 
>>> The current draft-sgundave PMIPv6 talks mainly in terms of
>>> DS-MIPv6. DS-MIPv6 is an extension to MIPv6 protocol, under
>>> development in the MIP6 WG.
>>> 
>> 
>> IPv4 HoA or transport support is a straight forward thing. We dont
>> have to complicate things and bring generic transition solutions,
>> such as ISATAP or TEREDO.
> 
> Sri, one doesn't 'complicate' anything by using ISATAP or TEREDO,
> because these are Standards Track edited RFCs documents with widely
> available implementations.  At least TEREDO is widely deployed today.
> 
> 6to4 is also widely deployed.
> 
> MIP6 and 6to4 is something that can and has been done straight away,
> without any need for interoperability or for documenting at IETF.  At
> many sites.
> 
> STUN for NAT Traversal is widely deployed on mobile phones.
> 
> I think SDO may think that 6to4/TEREDO/ISATAP/STUN is too complicated
> but I can refer SDO to relevant RFCs and to deployed software (all
> windows xp and vista do TEREDO, one 15% coverage Internet operator does
> STUN in their rich handset offer, etc).
> 
> Besides, it seems contradictory for one not to want TEREDO/6to4/ISATAP,
> but SDO wanting it (it so happens) and at the same time claim that SDO
> needs what NETLMM WG proposes.
> 
>> MIP6 working group already chose DSMIP6 and we leverage that work and
>>  have created normative reference.
> 
> That creates a dependency outside this working group.  If this working
> group works under SDO pressure it doesn't mean that other WG at IETF does.
> 
> Do you agree it's better without going with another dependency of
> another under-development document?
> 
>> We dont have to redo the whole spin to define this simple extension.
>>  If your primary objective is to create room for 10 different drafts,
>>  sure we can go that route and can work on the base problems for the
>>  next 3 years.
> 
> I agree what I'm suggesting with thin document may take longer than what
> some SDOs may expect.  I won't be specific in dates, but looks so.
> 
> However, every other SDO surely doesn't think that NETLMM WG is going to
> solve all SDOs needs in terms of IPv4, IPv6 and all other communication.
> 
>> We wanted the base to be complete. Any operator deploying IPv6
>> address mobility will certainly look for  IPv4 addressing support and
>>  we offer that.
> 
> Not only you offer that.  Deployers of IPv6 networks already have IPv4
> in place.  We offer a solution to that and it's not called DS-MIPv6 and
> uses other existing transitioning mechanism RFCs.
> 
> Besides, a deployer who plans to deploy an IPv6-only network can not be
> accommodated by DS-MIPv6, I've explained why earlier: a DS-MIPv6 HA MUST
>   run both IPv4 and IPv6, while a solution of MIPv6+6to4 allows the HA to
> be IPv6 only.
> 
> What do you think?
> 
>> If there are technical issues, please speak out and we will fix it.
> 
> Check the one above.  What do you think?  How can you fix that in the
> PMIPv6 spec?  It can also be solved in DS-MIPv6 spec (a dependency) or
> by not using DS-MIPv6 but 6to4.
> 
>> But, lets not split this doc and create work items for 10 parties,
>> just for the sake of doing that. There are other problems such as
>> context transfer, Shared-link support etc, that working group can
>> focus on. This doc is fairly complete, lets improve it, fix things
>> and take it forward.
> 
> I'm not asking to split.  There's not enough matter in this document for
> 10 drafts.  I'm asking to leave place and to stop taking in features
> that nobody asked to take these features in.
> 
> Alex
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Mar 2007 19:18:31 +0100

Behcet Sarikaya wrote:
> Hi Raj,
>   The point Alex is making I think is that IPv4 support using DSMIP is 
> probably good but it should not be part of the base PMIPv6 protocol.

Yes, that's what I meant, thanks for pointing it out: MIP6 WG choosing 
DS-MIPv6 is probably a good IPv6 migration path for MIP6 protocol but 
that doesn't make it necessarily a good path for PMIPv6.

MIP6: Mobile IPv6 protocol rfc3776/6
DS-MIPv6: Dual Stack Mobile IPv6 (WG item in MIP6 Working Group)
PMIPv6: Proxy Mobile IPv6 (draft-sgundave and draft-singh)

Alex

> ------------------------------------------------------------------------
>

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 09 Mar 2007 12:28:10 -0600

Inline:

>> probably good but it should not be part of the base PMIPv6 protocol.

I think I got that... :)

> that doesn't make it necessarily a good path for PMIPv6.

And why not? 
As I said earlier PMIPv6 is an extension/enhancement/.... to MIP6...... The
signaling messages, Home agent are all the same. So why would you delude
yourself into thinking that this is anything else.

> PMIPv6: Proxy Mobile IPv6 (draft-sgundave and draft-singh)

So what's the point??? After all we have MIPSHOP doing work on HMIPv6 and
FMIPv6 and MONAMI6 doing work on extending MIP6 as well. So if Netlmm is
enhancing MIP6 to support a non-host based mobility solution using the same
design and entities, I see it as no different.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Mar 2007 19:42:33 +0100

> yourself into thinking that this is anything else.

There are _many_ other extensions to MIP6 that are documented as RFCs 
that are not even mentioned in PMIPv6.  Why aren't these mentioned? 
BEcause we don't have Problem Statements and Requirements for these 
particular features.

> design and entities, I see it as no different.

Ok, how does PMIPv6 work with FMIPv6?  Does SDO want fast handovers?  Of 
course they do want it.  But do they work together?  How is MN moving 
fast influencing the AR doing FMIPv6 on its behalf?

We don't know, there many ways of doing, so we leave that out.  Check 
NETLMM RO, NETLMM NEMO and all.  Same goes with IPv4.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 09 Mar 2007 12:54:29 -0600

Alex,

> fast influencing the AR doing FMIPv6 on its behalf?

My point was that WGs other than MIP6 are doing extensions to the base MIP6
protocol. I did not say that PMIPv6 should support RO or Fast HO etc. What I
meant to say  was that PMIPv6 as a feature/enhancement to MIP6 is being
worked on in Netlmm. Because the way I interpreted your original comment was
that PMIPv6 should not necessarily rely on DS-MIP6 as the basis for IPv4
support. 

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Mar 2007 20:11:12 +0100

> that PMIPv6 should not necessarily rely on DS-MIP6 as the basis for IPv4

Thanks, I understand better.

By the same coin, DS-MIPv6 is an extension to MIP6 protocol.  Some 
people are happy using MIP6 don't need DS-MIPv6.  Check the Ethereal 
understanding of MIP6 vs DS-MIP6.  Some other people do indeed need 
DS-MIPv6 and they may use it.  And, after all we have no SDO requestion 
DS-MIPv6 exclusively, they request IPv4 and sometimes they even suggest 
solutions (which aren't DS-MIPv6).

And I continue to say PMIPv6 should not necessarily rely on DS-MIPv6 as 
basis for IPv4 support.  I can stand corrected on this, maybe one day 
PMIPv6 _will_ use DS-MIPv6.  But I signal that a Problem Statement for 
this is under progress, published in this WG (personal, not WG item). 
People will discuss on it.  At least two solutions for the space IPv4 in 
a PMIP6 protocol were proposed.  It's not fair to cut the way of these 
drafts by including IPv4 in draft-sgundave.

We can discuss the IPv4 inclusion in netlmm Charter separately if you 
wish, a good thread Subject is always useful.  I'm usually supportive on 
all IPv4 work.

Alex