Re: [DMM] Comments on DMM Gap Analysis.

[<[e-mail]>]

Dear all,

I also agree with Behcet that the impact of cloud networks in DMM should also be included!

Best regards,
Georgios


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Behcet Sarikaya
> Sent: donderdag 20 september 2012 18:19
> To: Jouni Korhonen
> Cc: [e-mail]
> Subject: Re: [DMM] Comments on DMM Gap Analysis.
> 
> Hi Jouni,
> 
> Isn't the gap obvious? Has this not yet been discussed already? The gap is the
> use of a central anchor. Yes there is possibility of LMA/HA selection but it is
> not dynamic.
> 
> Why can't we document this in a document quickly and move on?
> 
> What we need to do is to document the implications of moving away from
> this single anchoring towards dynamic anchoring or DMM. As I mentioned,
> what is the impact of cloud networks in DMM?
> 
> As you mentioned, we should also consider 3GPP case, i.e. GTP which brings
> control plane/data plane separation. What are the impact of DMM in
> control/data plane separation?
> 
> I think to write a document on these is the real challenge.
> 
> Regards,
> 
> Behcet
> 
> On Thu, Sep 20, 2012 at 3:34 AM, Jouni Korhonen
> <[e-mail]> wrote:
> > 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.
> >>
> >
> > _______________________________________________
> > dmm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dmm
> _______________________________________________
> dmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmm