Re: [DMM] Comments on DMM Gap Analysis.

[jouni korhonen <[e-mail]>]

Pierrick,


On Sep 20, 2012, at 2:51 PM, <[e-mail]> <[e-mail]> wrote:

> Jouni,
> 
> Thanks for clarifications. I agree, we have a good idea on what could be a DMM environment. However, the application of IP mobility protocols in such environments is worth to be described; we need to clearly figure out application and issues. Now, you're probably 

Sure. And I call for realistic environments. Something that we have real hands-on
operational experience with. Even if those were not originally drawn at the power
point level as "distributed environments" but in practice some level distribution
can be achieved. Might not be _currently_ what the DMM aims for but that is the
gap we are after, right? When the real gap is reveal, real new stuff flows in with
even new architectures..

> right when saying there is no room for dedicated document. Actually, I think it is a good idea to have the description of practices 

Good.

> together with gap analysis in a single document :-) But, the problem is that, today, we have couple of documents on practices and others on gap analysis, without real consensus on practices. So, IMHO, we need to firstly agree on practices the WG will recommend.

Having multiple documents and a split at the moment is no problem.. It might be an
issue at a personal level coffee consumption, though ;) Glue and duct tape works out
nicely with small effort. Personally, I would do my analysis against the practices in
DMMish capable architectures I think are relevant, and in one place.

>  And, to do that, we probably need to consider current contributions and limit the scope to some protocols (as you reminded in a previous email). That's my point but I do not push for separate document :-)
> 
> BTW, since mobility management is not deployed in distributed architecture, it would be better to talk about "recommendations" than "practices" :)

Practices.. what is the problem with that. Honestly, I struggle with that. Say, some
deployed networks already do things like functional split (like user & control plane
separation). Some other deployed technologies allow relocating your "centralized agents"
based on xyz criteria. Not directly DMMish but you have current practices how to get
closer to our distributes goals using the existing tools we got.

- Jouni


> 
> Pierrick
> 
>> -----Message d'origine-----
>> De : Jouni Korhonen [mailto:[e-mail]]
>> Envoyé : jeudi 20 septembre 2012 10:35
>> À : SEITE Pierrick RD-RESA; '[e-mail]';
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Cc : [e-mail]
>> Objet : Re: [DMM] Comments on DMM Gap Analysis.
>> 
>> Pierrick,
>> 
>> On 9/19/12 4:03 PM, "ext [e-mail]"
>> <[e-mail]> wrote:
>> 
>>> Hi Jouni and Julien,
>>> 
>>> 
>>> Sorry for jumping into the discussion but I'm a little bit confused
>>> with recent discussions in DMM. So, let me ask for clarifications
>>> about the scope of the gap analysis...
>>> 
>>> The WG is now tackling with the work item 'Practices and Gap
>> Analysis'
>>> and, in my understanding, we are expected to provide a gap analysis
>>> regarding the use of  mobility protocols in a distributed mobility
>> management environment.
>>> However, it seems that the scope of discussions on gap analysis is
>>> different.... and I'm confused :-)
>> 
>> The "distributed" environment would be what we have now.. Like if you
>> operate a network that has more than one anchor node, you can consider
>> that as a system which could enable distribution. And if e.g. anchor
>> distribution is possible/done today that would be documented (example:
>> LMA selection during the attach time based on geographical location).
>> 
>>    o Practices: Document practices for the deployment of existing
>>       mobility protocols in a distributed mobility management
>>       environment.
>> 
>> Gap analysis is then based on that.. and
>> 
>>> Actually, in the charter, we agreed to firstly "document practices
>> for
>>> the deployment of existing mobility protocols in a distributed
>>> mobility management
>> 
>> ..during the meeting I asked the question whether we deal current
>> practices and gap analysis in the same document, since there are
>> conflicting milestones. There was no clear answer from the room as far
>> as I remember (and minutes indicate).
>> 
>> I am (still) on the opinion that these two can and probably should be
>> the one same document. There are not too many current practices given
>> the rather low number of _really_deployed_ IP mobility technologies
>> that we can write meaningful current practices about. Then you would do
>> the gap analysis against those.
>> 
>>> environment" and, then, to make the gap analysis. However,
>> considering
>>> current discussions on "gap analysis": the document on practices has
>>> been omitted and discussions are about vanilla mobility protocols and
>>> architectures with respect to DMM requirements. So, maybe, such
>>> considerations are interesting in the scope of the problem statement,
>>> but it seems to me that it is not the goal of the gap analysis, as
>>> initially intended in the charter. Am I missing something?
>> 
>> I should have been clearer that I would like to see these two combined.
>> o Submit I-D 'Practices and Gap Analysis' as a working group document.
>> 
>> That also kind of forces strict scoping of mobility technologies I
>> mentioned about in my earlier mail.
>> 
>> I don't want to see a current practices or gap analysis of solutions
>> that has no relation to an existing and rather short term planned
>> deployment reality..
>> 
>>> If I refer to previous DMM charter (because current DMM charter is
>> empty...
>>> BTW, is there a reason for an empty charter?), one Work item was:
>>> "Document
>> 
>> There are issues between datatracker and tools coordination or
>> something.
>> Tools guys are on this. You can find older(?) version of the charter on
>> the tools page and yesterday the charter re-appeared again to
>> datatracker.
>> 
>>> practices for the deployment of existing mobility protocols in a
>>> distributed mobility management  environment". Is this document still
>>> in DMM stuff? If yes, shouldn't we document practices before going
>> into the gap analysis?
>> 
>> Mmm yes. But if you combine both you should be fine too. If folks think
>> and insist that there shall be a current practices as a separate
>> document, so be it.
>> 
>> - Jouni
>> 
>> 
>> 
>>> 
>>> BR,
>>> Pierrick
>>> 
>>>> -----Message d'origine-----
>>>> De : [e-mail] [mailto:[e-mail]] De la part
>> de
>>>> [e-mail] Envoyé : mercredi 19 septembre 2012 13:11 À :
>>>> [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]
>>>> Cc : [e-mail]
>>>> Objet : Re: [DMM] Comments on DMM Gap Analysis.
>>>> 
>>>> Hi Jouni, Hi all,
>>>> 
>>>> After discussing this issue with Carlos Jesús Bernardos and Juan
>>>> Carlos Zuniga, we concluded that the following set of possible
>>>> technologies could be included in the Gap analysis draft:
>>>> 
>>>> => Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc-
>>>> editor.org/rfc/rfc5533.txt
>>>> 
>>>> 
>>>> => LISP Mobile Node
>>>> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt
>>>> Locator/ID Separation Protocol (LISP)
>>>> http://www.ietf.org/id/draft-ietf-lisp-23.txt
>>>> 
>>>> => Mobile IPv6 Fast Handovers
>>>> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt
>>>> This is the draft that became then RFC5568, so no need to mention
>> it.
>>>> http://www.rfc-editor.org/rfc/rfc5568.txt
>>>> 
>>>> 
>>>> => Fast Handovers for Proxy Mobile IPv6
>>>> http://www.rfc-editor.org/rfc/rfc5949.txt
>>>> 
>>>> => Host Identity Protocol
>>>> http://www.rfc-editor.org/rfc/rfc4423.txt
>>>> http://www.rfc-editor.org/rfc/rfc5201.txt
>>>> http://www.rfc-editor.org/rfc/rfc6253.txt
>>>> http://www.rfc-editor.org/rfc/rfc5206.txt
>>>> 
>>>> 
>>>> 
>>>> => IKEv2 Mobility and Multihoming Protocol (MOBIKE)
>>>> http://www.rfc-editor.org/rfc/rfc4555.txt
>>>> 
>>>> 
>>>> => GTPv2-C: 3rd Generation Partnership Project; Technical
>>>> Specification Group Core Network and Terminals; 3GPP Evolved Packet
>>>> System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling
>>>> Protocol for Control plane (GTPv2-C); Stage 3 (Release 11)
>>>> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip
>>>> 
>>>> Please inform us if this list makes sense to you?
>>>> 
>>>> Best regards,
>>>> Georgios
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>>>> Of jouni korhonen
>>>>> Sent: woensdag 19 september 2012 9:58
>>>>> To: [e-mail]; h chan; Juan Carlos Zuniga
>>>>> Cc: [e-mail]
>>>>> Subject: Re: [DMM] Comments on DMM Gap Analysis.
>>>>> 
>>>>> 
>>>>> Folks,
>>>>> 
>>>>> It has been rather silent on the list recently. Regarding the
>>>> "explosion" of
>>>>> possible technologies in the GAP analysis, we discussed (chairs)
>>>>> that
>>>> it is
>>>>> better to scope the area "a bit". The charter today has the
>>>> assumption that
>>>>> we build on top of existing _IP_ _Mobility_ protocols (and bunch of
>>>> IETF
>>>>> defined examples follow). So, to tighten the scope, the Gap
>> Analysis
>>>> should
>>>>> leave all routing, session  (SIP, ..), transport (MPTCP, SCTP,
>> DCCP,
>>>> ..),
>>>>> locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..)
>>>>> etc
>>>> based
>>>>> solutions out. Coarse but should help us to make progress. We could
>>>> discuss
>>>>> whether transport layer solution like SCTP fit in but I do not see
>>>> them as end-
>>>>> 2-end solutions being deployable in Internet at the moment.
>>>>> 
>>>>> Let us stick with  technologies out there that have/had a place in
>>>> sun: few
>>>>> MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this
>>>> deserves to be
>>>>> evaluated since they are somewhat popular), and what applications
>> do
>>>>> (reconnecting..). This analysis should be down to earth practical
>>>>> and
>>>> realistic
>>>>> on what is already out there to play with.
>>>>> 
>>>>> - Jouni & Julien
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote:
>>>>> 
>>>>>> Dear Anthony and Juan.
>>>>>> 
>>>>>> I enjoyed the both gap analysis documents (draft-chan-dmm-
>>>> framework-
>>>>> gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give
>>>> some
>>>>> comments that should be used directly in the gap analysis documents
>>>> if you
>>>>> guys like.
>>>>>> 
>>>>>> Kindly consider the followings during the gap analysis discussion
>>>> (since I will
>>>>> not be attending the IETF meeting this time).
>>>>>> 
>>>>>> 1. Comment on address (resource) management in a DMM environment.
>>>>>> 2. Comment on a deployment of a client-based mobility solution
>>>> (i.e.,
>>>>> MIPv6) in a DMM environment.
>>>>>> 3. Commnet on neighbor mobility anchors' information in a DMM
>>>>> environment.
>>>>>> 4. Commnet on an establishment of security associations in a DMM
>>>>> environment.
>>>>>> 
>>>>>> === 1. Comment on address (resource) management in a DMM
>>>>> environment.
>>>>>> === When existing IP mobility support protocols (e.g., MIPv6 and
>>>> PMIPv6)
>>>>> are considered to be deployed in a DMM environment, a mobile node
>>>> (MN)
>>>>> is allowed to configure a new address while keeping its previous
>>>> address(es).
>>>>> It introduces the following differences with the address (resource)
>>>>> management of the existing ones:
>>>>>> 
>>>>>> MN's address configured at the interface with a DMM environment: n
>>>> =
>>>>>> (IP address at the current access network + previously configured
>>>> IP
>>>>>> address(es) with ongoing sessions) MN's address configured at the
>>>>>> interface without a DMM environment: 1 = (care-of address in MIPv6
>>>> or
>>>>>> MN's home address in PMIPv6)
>>>>>> 
>>>>>> This leads a couple of considerations we didn't have with the
>>>> existing
>>>>>> IP mobility support protocols. For instance,
>>>>>> 
>>>>>> 1) MN's address management: use of a newly configured address at
>>>> the
>>>>> current access network for new communication sessions while a
>> proper
>>>>> address selection for previously established ongoing communication
>>>>> sessions.
>>>>>> 
>>>>>> 2) Additional treatment for ingress filtering: Ingress filtering
>> is
>>>> widely used
>>>>> against source address spoofing. The source addresses (especially,
>>>> the
>>>>> network prefix part) of incoming packets are strictly checked to
>>>>> make
>>>> sure
>>>>> that those packets are actually from the network that they claim to
>>>> be from.
>>>>> As the MN are allowed to send data packets with the previously
>>>> configured
>>>>> address(es) at the new access network, those data packets would be
>>>> filtered
>>>>> at the ingress filtering place because the source address of those
>>>> data
>>>>> packets is not belonging to the new access network. Accordingly, an
>>>>> additional treatment for ingress filtering is required.
>>>>>> 
>>>>>> 3) MN's address increase at the MN's interface: Recall the number
>>>> of MN's
>>>>> address configured at an interface is n. Then, n is increased, as
>>>>> the
>>>> MN
>>>>> changes its point of attachment while keeping its ongoing
>>>> communication
>>>>> sessions. It brings the question: "How many addresses are currently
>>>> possible
>>>>> to be configured at an interface?"
>>>>>> 
>>>>>> 4) Routing entry increase at the serving mobility anchor: Let the
>>>> serving
>>>>> mobility anchor is the mobility anchor serves the MN. Traffic
>>>> associated to
>>>>> the MN travels via the serving mobility anchor. The increase of the
>>>> addresses
>>>>> associated to the MN, n, is not only concerning to the MN, but also
>>>>> concerning the serving mobility anchor as it contributes the
>>>>> increase
>>>> of
>>>>> routing entries for the MN.
>>>>>> 
>>>>>> === 2. Comment on a deployment of a client-based mobility solution
>>>>>> (i.e., MIPv6) in a DMM environment. === When a client-based
>>>> mobility
>>>>> solution (i.e., MIPv6) is consiered to be deployed in a DMM
>>>> environment, an
>>>>> MN is involved in mobility signaling such as Binding Update and
>>>>> Acknowledgement messages. This is the big difference with the
>>>> network-
>>>>> based mobility solution (i.e., PMIPv6). As the MN send signaling to
>>>> inform its
>>>>> movement to its mobility anchor, the client-based mobility solution
>>>> allows
>>>>> the MN to supply client-centric decision for mobility management.
>>>>>> 
>>>>>> Suppose that the origin mobility anchor is the mobility anchor
>>>> where the
>>>>> MN has configured its IP address and established ongoing
>>>> communication
>>>>> sessions with the IP address. The number of origin mobility anchors
>>>> are n - 1.
>>>>> Recall that the serving mobility anchor is the mobility anchor
>> where
>>>> the MN is
>>>>> being served by. Then, the MN's involvement in mobility signaling
>>>> brings us
>>>>> the questions: "Should we let the MN send mobilty signaling to its
>>>> all mobility
>>>>> anchors?" or "Would it make sense that the MN only sends mobility
>>>> signaling
>>>>> to its serving mobility anchor?" Depending on the choice, we will
>>>> have
>>>>> different results:
>>>>>> 
>>>>>> 1) "MN sends mobility signaling to its all mobility anchors"
>>>> causes:
>>>>>> 1.1 increased mobility signaling load, e.g., signaling * (n - 1).
>>>>>> 1.2 bidirectional tunnels are established between the MN and its
>>>> mobility
>>>>> anchors.
>>>>>> 1.3 tunneling overhead over the air is present.
>>>>>> 1.4 but the tunnels are terminated at the MN so that the MN has
>>>> control
>>>>> over the tunnels.
>>>>>> 
>>>>>> 2) "MN sends mobility signaling only to its serving mobility
>>>> anchor" causes:
>>>>>> 2.1 reduced mobility signaling load, e.g., signaling * 1.
>>>>>> 2.2 bidirectional tunnels are established between the serving
>>>> mobility
>>>>> anchors and origin mobility anchors.
>>>>>> 2.3 tunneling overhead over the air can be avoided.
>>>>>> 2.4 but the MN does not have control over the tunnels so it might
>>>> affect to
>>>>> NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the
>>>> tunneling
>>>>> control.
>>>>>> 
>>>>>> === 3. Neighbor mobility anchors' information in a DMM
>> environment.
>>>>>> === In the client-based mobility solution such as MIPv6, the
>>>> network
>>>>> topology information does not required to be known to the mobility
>>>> anchor,
>>>>> i.e., home agent (HA), since the HA is informed the current
>> location
>>>> of the
>>>>> MN. As the HA knows the current location of the MN, it is able to
>>>> tunnel
>>>>> packets associated to the MN. In the network-based mobility
>> solution
>>>> such
>>>>> as PMIPv6, the similar things happen, i.e., the tunnel between the
>>>> local
>>>>> mobility anchor (LMA) and the mobile access gateway (MAG) is
>>>> established
>>>>> for a given MN.
>>>>>> 
>>>>>> However, as mobility anchors are distributed and bidirectional
>>>> tunnels (for
>>>>> a given MN) between the distributed mobility anchors are required,
>>>> the
>>>>> neighbor mobility anchors' information should be provided to the MN
>>>> or the
>>>>> mobility anchor for the establishment of the directional tunnels or
>>>> the
>>>>> update of the MN's current location.
>>>>>> 
>>>>>> Decoupling the data plane and control plane while keeping a
>>>> centralized
>>>>> node maintaining the mobility context including neighbor mobility
>>>> anchors'
>>>>> information (e.g., identification, IP address, etc) in a DMM
>>>> environment is
>>>>> one of possible solutions.
>>>>>> 
>>>>>> === 4. Comment on an establishment of security associations in a
>>>> DMM
>>>>>> environment. === For each IP mobility support protocol, different
>>>> security
>>>>> associations (SAs) are required for providing secure mobility
>>>> services to MNs
>>>>> as follows:
>>>>>> 
>>>>>> 1) MIPv6
>>>>>> 1.1 SA between MN and HA.
>>>>>> 1.2 SA between MN and serving access router (AR) providing
>> wireless
>>>> link
>>>>> to the MN.
>>>>>> 
>>>>>> 2) Fast Handover MIPv6 (FMIPv6)
>>>>>> 2.1 SA between MN and HA.
>>>>>> 2.2 SA between MN and serving AR.
>>>>>> 2.3 SA between previous and new ARs.
>>>>>> 
>>>>>> 3) PMIPv6
>>>>>> 3.1 SA between MN and serving MAG.
>>>>>> 3.2 SA between serving MAG and LMA.
>>>>>> 
>>>>>> 4) Fast Handover PMIPv6 (FPMIPv6)
>>>>>> 4.1 SA between MN and serving MAG.
>>>>>> 4.2 SA between serving MAG and LMA.
>>>>>> 4.3 SA between previous and new MAGs.
>>>>>> 
>>>>>> Note that the above ones do not consider the cases of SA with a
>>>> security-
>>>>> backend server (e.g., AAA server) and with a correspondent node
>> (CN).
>>>>>> 
>>>>>> However, depending on DMM solutions, SAs are configured that are
>>>>>> different from those of the existing IP mobility support
>> protocols.
>>>>>> For instance,
>>>>>> 
>>>>>> 1) the case of "MN sends mobility signaling to its all mobility
>>>>>> anchors" (client-based mobility solution)
>>>>>> 1.1 SA between MN and serving mobility anchor providing wireless
>>>> link to
>>>>> the MN.
>>>>>> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs
>>>> required
>>>>> with MN and origin mobility anchors.
>>>>>> 
>>>>>> 2) the case of "MN sends mobility signaling only to its serving
>>>>>> mobility anchor" (client-based mobility solution)
>>>>>> 2.1 SA between MN and serving mobility anchor.
>>>>>> 2.2 SA between serving mobility anchor and origin mobility
>> anchors,
>>>> i.e., (n
>>>>> - 1) SAs required with serving mobility anchor and origin mobility
>>>> anchors.
>>>>>> 
>>>>>> 3) the case of "serving mobility anchor sends signaling on behalf
>>>> of
>>>>>> the MN to origin mobility anchors" (network-based mobility
>>>> solution)
>>>>>> 3.1 SA between MN and serving mobility anchor.
>>>>>> 3.2 SA between serving mobility anchor and origin mobility
>> anchors,
>>>> i.e., (n
>>>>> - 1) SAs required with serving mobility anchor and origin mobility
>>>> anchors.
>>>>>> 
>>>>>> Note that as like before SAs with a security-backend server (e.g.,
>>>> AAA
>>>>> server) and with a CN are not presented.
>>>>>> 
>>>>>> As shown above, DMM solutions (that relies on bidirectional
>>>> tunnelings for
>>>>> packet forwarding between MN and mobility anchors or between just
>>>>> mobility anchors) might bring the key management issues to
>> establish
>>>> such
>>>>> SAs.
>>>>>> 
>>>>>> Since it's a holiday season, I cannot fully address all of them in
>>>> my mind, but
>>>>> kindly consider these ones.
>>>>>> 
>>>>>> Cheers.
>>>>>> 
>>>>>> --
>>>>>> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living
>>>>>> somewhere between /dev/null and /dev/random
>>>>>> 
>>>>>> #email: jonghyouk (at) gmail (dot) com
>>>>>> #webpage: http://sites.google.com/site/hurryon/
>>>>>> 
>>>>>> _______________________________________________
>>>>>> dmm mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>> 
>>>>> _______________________________________________
>>>>> dmm mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>> _______________________________________________
>>>> dmm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>> 
>>> 
>> ______________________________________________________________________
>>> ________ ___________________________________________
>>> 
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>>> que les pieces jointes. Les messages electroniques etant susceptibles
>>> d'alteration, France Telecom - Orange decline toute responsabilite si
>>> ce message a ete altere, deforme ou falsifie. Merci.
>>> 
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not
>>> be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender
>> and
>>> delete this message and its attachments.
>>> As emails may be altered, France Telecom - Orange is not liable for
>>> messages that have been modified, changed or falsified.
>>> Thank you.
>>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>