Subject: Re: RE : [netlmm] Revised text for LMA definition

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 6 Jun 2007 14:54:56 -0700 (PDT)

I read Goal 10 in 4831. PMIP6 satisfies this goal, I see no problem. It is just a nuance that PMIP6 happens to be an extension of MIP6 which is a global mobility protocol. Hence comes the use of HA.

Regards,

--behcet

----- Original Message ----
From: Julien Abeille <[email-masked]>
To: Ashutosh Dutta <[email-masked]>; Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, June 6, 2007 4:17:58 AM
Subject: RE : [netlmm] Revised text for LMA definition

Hi Behcet, Ashutosh, 

you are saying that the charter and the requirements (check goal 10 of the RFC) were written after the solution, right?
Regards,
julien

-------- Message d'origine--------
De: Ashutosh Dutta [mailto:[email-masked]]
Date: mer. 6/6/2007 12:14
À: Behcet Sarikaya
Cc: Julien Abeille; [email-masked]
Objet : Re: [netlmm] Revised text for LMA definition
 
Behcet,
    I agree that we need to either modify the charter or accommodate 
PMIPv6's applicability to support other global mobility protocols.

    Currently, part of the charter still says that "The protocol will be 
independent of any particular global mobility management protocol, and 
it will be link-layer agnostic by running on top of IP."

Thanks
Ashutosh

Behcet Sarikaya wrote:
> 
> The main point here is that netlmm WG accepted PMIP6 solution without 
> changing the charter for which netlmm DT solution was being developed.
> It was decided to change the charter only after the base protocol is 
> developed.
> The compromise is to use the terms MAG and LMA in PMIP6 base document. 
> Otherwise, certainly, LMA is the HA.
> 
> Regards,
> 
> --behcet
> ----- Original Message ----
> From: Ashutosh Dutta <[email-masked]>
> To: Julien Abeille <[email-masked]>
> Cc: [email-masked]
> Sent: Monday, June 4, 2007 8:10:56 AM
> Subject: Re: [netlmm] Revised text for LMA definition
> 
> Julien,
>     I think the important question is if we should attempt to design a
> generalized local mobility protocol that has the ability to interwork
> independent of any global mobility protocol, not just restricted to MIPv6.
> 
>     As of now, PMIPv6 appears to be very much in alignment with MIPv6 as
> the global mobility protocol. But that does not preclude it from being
> considered to be used with other global mobility protocols such as HIP
> or SIP etc.
> 
> Thanks
> Ashutosh
> 
> 
> 
> Julien Abeille wrote:
>  > Hi Ashutosh,
>  >
>  > as far as deployment is concerned, I agree with you. This does not mean
>  > that it is a requirement do design a protocol depending on any Global or
>  > host based mobility protocol. On the contrary, goal 10 of RFC 4831 is
>  > clear about the issue.
>  > Moreover, i think the issues raised when collocating a HA and a LMA can
>  > be solved in a cleaner way if PMIP design is independent of MIP.
>  >
>  > Thanks,
>  > Julien
>  >
>  >
>  >
>  >
>  > Ashutosh Dutta wrote:
>  >> Julien,
>  >>         In my opinion, unlike previous versions of local mobility
>  >> protocols, such as Cellular IP or HAWAII, PMIPv6 is very much tightly
>  >> coupled with the global mobility protocol like MIPv6. Thus there will
>  >> be an opportunity for reusability of lot of functional components
>  >> between these two protocols during the deployment. The degree of
>  >> re-usability will depend upon the type and pattern of mobile's movement.
>  >>
>  >> Thanks
>  >> Ashutosh
>  >>
>  >>
>  >> Julien Abeille wrote:
>  >>>   Hi Raj,
>  >>>
>  >>> my view is that the MIPv6 behavior is different from the PMIPv6 one
>  >>> in important aspects, such as tunnel management, lookup entry key....
>  >>> It is not PMIPv6 role in my view to design a LMA which is able to
>  >>> handle BUs from MNs. a LMA high level role is defined in the charter
>  >>> and there is no mention in this section of about handling host based
>  >>> mobility.
>  >>> Again, the charter says
>  >>> "The protocol will be independent of any
>  >>> particular global mobility management protocol"
>  >>> I think this is desirable and that for now, the draft fails to do so.
>  >>>
>  >>> the damage i am referring to is the lack of flexibility in the
>  >>> protocol, and the not clean specification. PMIPv6 behavior is
>  >>> different form MIPv6, if you want to merge them, the only way top do
>  >>> so is to keep acking MIPv6. the different lookup key is a good
>  >>> example for me.
>  >>>
>  >>> Particular scenarios, like PMIP/CMIP interaction or PMIP/HIP...
>  >>> should be solved in different documents.
>  >>>
>  >>> Best regards,
>  >>> Julien
>  >>>
>  >>>
>  >>>
>  >>> Basavaraj Patil wrote:
>  >>>> Julien,
>  >>>>
>  >>>> Two points:
>  >>>>
>  >>>> 1. PMIP6 is an add-on or enhancement to MIP6. That is how I view it.
>  >>>> If you
>  >>>> believe PMIP6 is an entirely new protocol, then I am not sure why you
>  >>>> perceive it as such.
>  >>>>
>  >>>> 2. What damage to PMIP6 are you refering to or you consider will
>  >>>> occur if we
>  >>>> continue on the path of PMIP6 being a MIP6 enhancement?
>  >>>>
>  >>>> In the context of PMIP6 as it is being defined today and in the
>  >>>> context of
>  >>>> mobility protocols in the IETF, what global mobility protocol do you
>  >>>> think
>  >>>> is essentially being refered to in PMIP6?
>  >>>>
>  >>>> -Raj
>  >>>>
>  >>>> On 6/1/07 6:39 AM, "ext Julien Abeille"
>  >>>> <[email-masked]> <mailto:[email-masked]>
>  >>>> wrote:
>  >>>>
>  >>>>  
>  >>>>> Hi Jean Michel,
>  >>>>>
>  >>>>> I strongly agree with you as suggested my previous and non answered
>  >>>>> emails (PMIP/CMIP dependency). I think it would be doing a lot of
>  >>>>> damage
>  >>>>> to PMIP than building it as an RFC3775 plugin, which is not what the
>  >>>>> charter proposes by the way: "The protocol will be independent of any
>  >>>>> particular global mobility management protocol", even though the term
>  >>>>> "global" is not very clear.
>  >>>>>
>  >>>>> Cheers,
>  >>>>> Julien
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>> Jean-Michel Combes wrote:
>  >>>>>  
>  >>>>>> Hi Raj,
>  >>>>>>
>  >>>>>> 2007/6/1, Basavaraj Patil <[email-masked]>
>  >>>>>> <mailto:[email-masked]>:
>  >>>>>>    
>  >>>>>>> The discussion regarding the use of the term LMA indicated that the
>  >>>>>>> terms local and global mobility depend on the context and hence
>  >>>>>>> cannot
>  >>>>>>> really be generalized.
>  >>>>>>>
>  >>>>>>> My initial proposal was to refer to the LMA as an HA. I am not
>  >>>>>>> sure if
>  >>>>>>> there was a concrete conclusion to be derived from the 
> discussion. I
>  >>>>>>> think that the term LMA is context dependent.
>  >>>>>>>
>  >>>>>>> Below is a proposal for the term LMA in the PMIP6 I-D
>  >>>>>>> [draft-ietf-netlmm-proxymip6]:
>  >>>>>>>
>  >>>>>>> Local Mobility Anchor/HA
>  >>>>>>>
>  >>>>>>> The term LMA and HA are interchangeable and depend on the 
> context in
>  >>>>>>> which the protocol is used. When the protocol specified in this
>  >>>>>>> document is used for local mobility management of a host, i.e 
> within
>  >>>>>>> the scope of an access network or administrative domain, the term
>  >>>>>>> LMA
>  >>>>>>> is used or applicable. When the protocol is used for global 
> mobility
>  >>>>>>> management of a host, the entity is essentially a Home Agent and
>  >>>>>>> should be refered to as such.
>  >>>>>>>        
>  >>>>>> The entity _is essentially_ a Home Agent doesn't mean the entity 
> _is_
>  >>>>>> a HA.
>  >>>>>>
>  >>>>>>    
>  >>>>>>> The local mobility anchor is the entity that maintains the binding
>  >>>>>>> between the prefix assigned to an MN and the Proxy-CoA. The LMA has
>  >>>>>>> the functional capabilities of a home agent as defined in Mobile
>  >>>>>>> IPv6
>  >>>>>>> base specification [RFC-3775] and with the additional required
>  >>>>>>> capabilities for supporting Proxy Mobile IPv6 as defined in this
>  >>>>>>> specification. The prefix assigned to an MN is a local prefix.
>  >>>>>>>        
>  >>>>>> s/capabilities/modifications  .... this is the main reason why, 
> IMHO,
>  >>>>>> the LMA is not a RFC 3775 HA, or better, a RFC 3776 HA.
>  >>>>>>
>  >>>>>>    
>  >>>>>>> In the context of Proxy MIP6 being used for global mobility the
>  >>>>>>> HA is
>  >>>>>>> the entity that maintains the binding between the prefix (or
>  >>>>>>> address)
>  >>>>>>> assigned to an MN and the proxy-CoA (at the MAG). This HA has the
>  >>>>>>> functional capability of the HA as per RFC3775
>  >>>>>>>        
>  >>>>>> but not the RFC 3776 one when it is used for PMIP.
>  >>>>>>
>  >>>>>> So, I can accept the name "pHA" or "PMIP HA" but I strongly disagree
>  >>>>>> to name it simply "HA".
>  >>>>>>
>  >>>>>> Best regards.
>  >>>>>>
>  >>>>>> JMC.
>  >>>>>>
>  >>>>>>    
>  >>>>>>> and proxy MIP6 features
>  >>>>>>> specified in this document. The prefix assigned to the MN when used
>  >>>>>>> for global mobility MAY be the MNs home-link prefix causing
>  >>>>>>> home-link
>  >>>>>>> emulation from the MNs perspective.
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> Thoughts?
>  >>>>>>>
>  >>>>>>> -Raj
>  >>>>>>>
>  >>>>>>>
>  >>>>>>> _______________________________________________
>  >>>>>>> netlmm mailing list
>  >>>>>>> [email-masked] <mailto:[email-masked]>
>  >>>>>>> https://www1.ietf.org/mailman/listinfo/netlmm
>  >>>>>>>
>  >>>>>>>        
>  >>>>>> _______________________________________________
>  >>>>>> netlmm mailing list
>  >>>>>> [email-masked] <mailto:[email-masked]>
>  >>>>>> https://www1.ietf.org/mailman/listinfo/netlmm
>  >>>>>>
>  >>>>>>      
>  >>>>
>  >>>>  
>  >>>
>  >>> --
>  >>> Julien Abeillé
>  >>> Research Associate
>  >>> NEC Europe Ltd.
>  >>> Network Laboratories
>  >>> Kurfürsten-Anlage 36
>  >>> 69115 Heidelberg
>  >>> GERMANY
>  >>>
>  >>> tel: +49 6221 43421 19
>  >>> fax: +49 6221 43421 55
>  >>> eMail: [email-masked]
>  >>> <mailto:[email-masked]>
>  >>> http://www.netlab.nec.de
>  >>>
>  >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
>  >>> London W3 6BL | Registered in England 2832014
>  >>>
>  >>>
>  >>> 
> ------------------------------------------------------------------------
>  >>>
>  >>> _______________________________________________
>  >>> netlmm mailing list
>  >>> [email-masked]
>  >>> https://www1.ietf.org/mailman/listinfo/netlmm
>  >>
>  >
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 

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