Re: [DMM] Comments on DMM Gap Analysis.

[<[e-mail]>]

I agree. So, we have different "DMM practices" on the table and first step is probably to get consensus on what could be the practices.

Pierrick

> -----Message d'origine-----
> De : Peter McCann [mailto:[e-mail]]
> Envoyé : mercredi 19 septembre 2012 21:54
> À : Zuniga, Juan Carlos; SEITE Pierrick RD-RESA;
> [e-mail]; [e-mail]; [e-mail]; h chan
> Cc : [e-mail]
> Objet : RE: [DMM] Comments on DMM Gap Analysis.
> 
> Maybe the document should be entitled "Existing IP Mobility Practices
> and DMM Gap Analysis."  I am not sure there are any "DMM Practices"
> currently.
> 
> -Pete
> 
> Zuniga, Juan Carlos wrote:
> > Hi Pierrick, all,
> >
> > The document title is "DMM Practices and Gap Analysis", and the
> > intention is to address both. When we presented at the meeting it I
> > made it clear that we wanted to show our approach to the problem,
> > which was first to agree on what are the "current practices" that we
> > want to consider, and then provide a "gap analysis" wrt the DMM
> > requirements document.
> >
> > We are currently working on a new version of the document taking into
> > account the feedback we got at the meeting and on the ML. We will
> > provide more details about the current practices and will take a stab
> > at the gap analysis for discussion.
> >
> > Cheers,
> >
> > Juan Carlos
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]]
> >> Sent: Wednesday, September 19, 2012 9:03 AM
> >> To: '[e-mail]'; [e-mail]; [e-mail];
> >> [e-mail]; Zuniga, Juan Carlos
> >> Cc: [e-mail]
> >> Subject: RE: [DMM] Comments on DMM Gap Analysis.
> >>
> >> 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 :-)
> >>
> >> Actually, in the charter, we agreed to firstly "document practices
> >> for the deployment of existing mobility protocols in a distributed
> >> mobility management 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?
> >>
> >> 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 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?
> >>
> >> 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.
> >
> > _______________________________________________
> > 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.