Subject: Re: [DMM] Comments on DMM Gap Analysis.

From: jouni korhonen <[email-masked]>
Date: Wed, 19 Sep 2012 10:57:42 +0300

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: <[email-masked]>
Date: Wed, 19 Sep 2012 11:11:03 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> jouni korhonen
> Sent: woensdag 19 september 2012 9:58
> To: [email-masked]; h chan; Juan Carlos Zuniga
> Cc: [email-masked]
> 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
> 
> 
> 
> > 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.
> > === 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:
> > 2) "MN sends mobility signaling only to its serving mobility anchor" causes:
> > 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
> > 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)
> > 2) the case of "MN sends mobility signaling only to its serving
> > mobility anchor" (client-based mobility solution)
> > 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.2 SA between serving mobility anchor and origin mobility anchors, i.e., (n
> - 1) SAs required with serving mobility anchor and origin mobility anchors.
> >
> > 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.
> >
> > RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living
> > somewhere between /dev/null and /dev/random
> >

---

From: <[email-masked]>
Date: Wed, 19 Sep 2012 13:03:05 +0000

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 : [email-masked] [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : mercredi 19 septembre 2012 13:11
> À : [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc : [email-masked]
> 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
> => 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)
> > > 2. Comment on a deployment of a client-based mobility solution
> (i.e.,
> > MIPv6) in a DMM environment.
> > > 1.2 bidirectional tunnels are established between the MN and its
> mobility
> > anchors.
> > > 1.4 but the tunnels are terminated at the MN so that the MN has
> control
> > over the tunnels.
> > >
> > > 2.2 bidirectional tunnels are established between the serving
> mobility
> > anchors and origin mobility anchors.
> > > 1.2 SA between MN and serving access router (AR) providing wireless
> link
> > to the MN.
> > >
> > > 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.
> > >
> > > Note that as like before SAs with a security-backend server (e.g.,
> AAA
> > server) and with a CN are not presented.
> > >
> > > Since it's a holiday season, I cannot fully address all of them in
> my mind, but
> > kindly consider these ones.
> > >
> > > Cheers.
> > >
> > > --

_________________________________________________________________________________________________________________________

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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Sep 2012 11:14:57 -0500

Hi Jouni,

I agree.

I also suggest that we do not take cloud networks lightly.
Operator cloud networks are there already and it is spreading fast,
and I can say that soon it is going to cover all operators worldwide
soon.

We should not ignore that fact that mobility entities will be in the
cloud. Also many entities we thought they were far away, with cloud
networks they will become neighbors in IPv6 sense.

I suggest that gap analysis should take into account the cloud.

Regards,

Behcet

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 19 Sep 2012 15:08:07 -0400

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 

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2012 9:03 AM
> To: [email-masked]'; [email-masked]; [email-masked];
> [email-masked]; Zuniga, Juan Carlos
> 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
> 
> > > possible technologies in the GAP analysis, we discussed (chairs)
> that
> > it is
> > > 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
> > > (reconnecting..). This analysis should be down to earth practical
> and
> > realistic
> > > > MN's address configured at the interface with a DMM environment:
> n
> > =
> > > > interface without a DMM environment: 1 = (care-of address in
> MIPv6
> > or
> > > > 2) Additional treatment for ingress filtering: Ingress filtering
> is
> > widely used
> > > network prefix part) of incoming packets are strictly checked to
> make
> > sure
> > > address configured at an interface is n. Then, n is increased, as
> the
> > MN
> > > concerning the serving mobility anchor as it contributes the
> increase
> > of
> > > Recall that the serving mobility anchor is the mobility anchor
> where
> > the MN is
> > > i.e., home agent (HA), since the HA is informed the current
> location
> > of the
> > > packets associated to the MN. In the network-based mobility
> solution
> > such
> > > > 2.2 SA between serving mobility anchor and origin mobility
> anchors,
> > i.e., (n
> > > > 3.2 SA between serving mobility anchor and origin mobility
> anchors,
> > i.e., (n
> > > mobility anchors) might bring the key management issues to
> establish
> > such
> > > SAs.
> > > >
> _______________________________________________________________________
> __________________________________________________
> 
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.

---

From: Peter McCann <[email-masked]>
Date: Wed, 19 Sep 2012 19:54:16 +0000

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
> 
>> with recent discussions in DMM. So, let me ask for clarifications
>> about the scope of the gap analysis...
>> 
>> 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 : [email-masked]
>>> [mailto:[email-masked]] De la part de [email-masked]
>>> Envoyé : mercredi 19 septembre 2012 13:11 À : [email-masked];
>>> [email-masked]; [email-masked];
>>> [email-masked] Cc : [email-masked]
>>> 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:
>>> 
>>> 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.
>>> => 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
>>> 
>>>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
>> Of
>>>> jouni korhonen
>>>> 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
>>>> 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-
>>>> 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
>>>> 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
>>>>> 1. Comment on address (resource) management in a DMM environment. 2.
>>>>> Comment on a deployment of a client-based mobility solution
>>> (i.e.,
>>>>> 3. Commnet on neighbor mobility anchors' information in a DMM
>>>>> environment. 4. Commnet on an establishment of security associations
>>>>> in a
> DMM
>>>> environment.
>>>>> 
>>>>> 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:
>>>>> 
>>>>> 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
>>>> against source address spoofing. The source addresses
> (especially,
>>> the
>>>> 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
>>>> 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
>>>> 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.
>>>>> 
>>>> 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:
>>>>> 
>>>>> 2) "MN sends mobility signaling only to its serving mobility anchor"
>>>>> causes: 2.1 reduced mobility signaling load, e.g., signaling * 1.
>>>>> 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.
>>>>> 
>>>> topology information does not required to be known to the
> mobility
>>> anchor,
>>>> 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.
>>>>> 
>>>> 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.
>>>>> 
>>>> 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
>>>>> Note that the above ones do not consider the cases of SA with
>>>>> a
>>> security-
>>>>> 1) the case of "MN sends mobility signaling to its all
>>>>> mobility anchors" (client-based mobility solution)
>>>>> 2) the case of "MN sends mobility signaling only to its
>>>>> serving mobility anchor" (client-based mobility solution)
>>>> - 1) SAs required with serving mobility anchor and origin
> mobility
>>> anchors.
>>>>> 
>>>>> 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.
>>>>> 
>>>> 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
>>>>> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee,
>>>>> living somewhere between /dev/null and /dev/random
>>>>> 
>> ______________________________________________________________________
>> _ __________________________________________________
>> 
>> 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.
>> 
>> 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.
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 19 Sep 2012 16:55:11 -0400

Good point Pete, although I'm not sure the title can fit... We'll look for an alternative to reflect the actual content.

Thanks,

Juan Carlos

> From: Peter McCann [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2012 3:54 PM
> To: Zuniga, Juan Carlos; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; h chan
> 2.

---

From: liu dapeng <[email-masked]>
Date: Thu, 20 Sep 2012 11:47:28 +0800

Hello All,

I also have the similar thinking that we should first document and
agree on the "practices for the deployment of existing mobility
protocols in a distributed mobility management environment".  After
that, if we find that there indeed some "gap" existing, we can then
move to "gap analysis".

Best Regards,
Dapeng

2012/9/19, [email-masked] <[email-masked]>:
> 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
> 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
>
>> "explosion" of
>> assumption that
>> discuss
>> deserves to be
>> if you
>> (MN)
>> existing
>> be from.
>> communication
>> associated to
>> environment, an
>> communication
>> brings us
>> signaling
>> tunneling
>> tunnel
>> or the
>> anchors'
> 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,
> As emails may be altered, France Telecom - Orange is not liable for messages
> that have been modified, changed or falsified.
> Thank you.
>

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Thu, 20 Sep 2012 07:14:56 +0000

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

> De : Peter McCann [mailto:[email-masked]]
> Envoyé : mercredi 19 septembre 2012 21:54
> À : Zuniga, Juan Carlos; SEITE Pierrick RD-RESA;
> Objet : RE: [DMM] Comments on DMM Gap Analysis.
> 
> >> 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?
> >>
> this
> >>> Envoyé : mercredi 19 septembre 2012 13:11 À :
> >>> [email-masked]; [email-masked]; [email-masked];
> >>> 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.
> >>>> 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
> >>>>> environment. 4. Commnet on an establishment of security
> >>>>> associations in a
> > DMM
> >>>> environment.
> >>>>>
> >>>> (MN) is allowed to configure a new address while keeping its
> >>>> previous address(es). It introduces the following differences with
> >>>> the address
> >>>> current access network for new communication sessions while a
> >>>> proper address selection for previously established ongoing
> >>>> communication sessions.
> >>>>>
> an
> >>>> concerning to the MN, but also concerning the serving mobility
> >>>> anchor as it contributes the
> >> increase
> >>> of
> >>>> 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.
> >>>>>
> >>>> brings us the questions: "Should we let the MN send mobilty
> >>>> signaling to
> > its
> >>> all mobility
> >>>> anchors' information (e.g., identification, IP address, etc) in a
> >>>> DMM environment is one of possible solutions.
> >>>>>
> >>>>> 3) the case of "serving mobility anchor sends signaling on behalf
> >>>>> of the MN to origin mobility anchors" (network-based mobility
> >>>>> solution)
> _____________________________________________________________________
> >> _ _ __________________________________________________
> >>
> 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.
> >

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 20 Sep 2012 11:34:33 +0300

Pierrick,

On 9/19/12 4:03 PM, "ext [email-masked]"
<[email-masked]> wrote:

> 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.

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
 
> 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..

> 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.

> 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

> ______________________________________________________________________________
> ___________________________________________
>

---

From: <[email-masked]>
Date: Thu, 20 Sep 2012 11:51:19 +0000

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 right when saying there is no room for dedicated document. Actually, I think it is a good idea to have the description of practices 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. 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" :)

Pierrick

> De : Jouni Korhonen [mailto:[email-masked]]
> Envoyé : jeudi 20 septembre 2012 10:35
> À : SEITE Pierrick RD-RESA; [email-masked]';
> management environment.
> 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).
> 
> 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
> > 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?
> 
> 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..
> 
> empty...
> 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
> >
> >> [email-masked] Envoyé : mercredi 19 septembre 2012 13:11 À :
> >>> From: [email-masked] [mailto:[email-masked]] On Behalf
> >>> Of jouni korhonen
> proper
> > ________ ___________________________________________
> >
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, France Telecom - Orange decline toute responsabilite si
> > 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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Sep 2012 11:19:15 -0500

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

---

From: <[email-masked]>
Date: Fri, 21 Sep 2012 08:29:38 +0000

Dear all,

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

Best regards,
Georgios

> Behcet Sarikaya
> Sent: donderdag 20 september 2012 18:19
> To: Jouni Korhonen
> Cc: [email-masked]
> 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.
> 
> 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?
> 
> >> 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.
> > that we can write meaningful current practices about. Then you would
> > do the gap analysis against those.
> >
> >> 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?
> >
> > 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.
> >
> >> 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
> >>
> >>> De : [email-masked] [mailto:[email-masked]] De la part
> >>> de [email-masked] Envoyé : mercredi 19 septembre 2012 13:11
> >>>> evaluated since they are somewhat popular), and what applications
> >>>> do (reconnecting..). This analysis should be down to earth
> >>>> practical and
> >>> realistic
> >> _________ ___________________________________________
> >>
> >> and delete this message and its attachments.

---

From: jouni korhonen <[email-masked]>
Date: Fri, 21 Sep 2012 12:09:54 +0300

Pierrick,

On Sep 20, 2012, at 2:51 PM, <[email-masked]> <[email-masked]> 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 :-)
> 

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

>> Analysis'
>> de
>> do

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Fri, 21 Sep 2012 12:18:44 +0000

Hi Pierrick, Jouni, All,

  | we have a good idea on what could be a DMM environment

Actually, I would like to see a concrete definition, say, of less than 25 words, of what a "DMM environment" is. Pointers much appreciated.

Best Regards,

Kostas

---

From: <[email-masked]>
Date: Mon, 24 Sep 2012 08:14:08 +0000

Jouni,

> De : jouni korhonen [mailto:[email-masked]]
> Envoyé : vendredi 21 septembre 2012 11:10
> À : SEITE Pierrick RD-RESA
> Cc : 'Jouni Korhonen'; [email-masked]'; [email-masked];
> [email-masked]; [email-masked]; dmm-
> [email-masked]
> > 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? 

Ok, I see. I agree.

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.
> 

You're right, some architectures support distribution features; I meant that, IP mobility in distributed architecture is not supported. But, ok, no problem with  "practices" :-)

Basically, we are in agreement. Thanks for the clarifications.

Pierrick

> >> De : Jouni Korhonen [mailto:[email-masked]] Envoyé : jeudi
> 20
> >> septembre 2012 10:35 À : SEITE Pierrick RD-RESA;
> >> [email-masked]'; [email-masked]; [email-masked];
> >> [email-masked]; [email-masked]
> >> 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:
> >> conflicting milestones. There was no clear answer from the room as
> >> far as I remember (and minutes indicate).
> >>
> >>> 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
> >>> distributed mobility management  environment". Is this document
> >>> still in DMM stuff? If yes, shouldn't we document practices before
> >>> going
> >> into the gap analysis?
> >>
> >> think and insist that there shall be a current practices as a
> >> separate document, so be it.
> >>
> >> - Jouni
> >>
> >>
> >>
> >>>
> >>> BR,
> >>> Pierrick
> >>>
> >>>> http://www.rfc- editor.org/rfc/rfc5533.txt
> >>>>
> >>>>
> >>>> => LISP Mobile Node
> >>>> 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.zi
> >>>> p
> >>>>
> >>>>> we build on top of existing _IP_ _Mobility_ protocols (and bunch
> >>>>> of
> >>>> IETF
> >>>>> whether transport layer solution like SCTP fit in but I do not
> see
> >>>> them as end-
> >>>>> It introduces the following differences with the address
> >>>>>> (IP address at the current access network + previously
> configured
> >>>> IP
> >>>>> address(es) at the new access network, those data packets would
> be
> >>>> filtered
> >>>>> sessions. It brings the question: "How many addresses are
> >>>>> currently
> >>>> possible
> >>>>> 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
> >>>>>> === 2. Comment on a deployment of a client-based mobility
> >>>>>> solution (i.e., MIPv6) in a DMM environment. === When a
> >>>>>> client-based
> >>>> mobility
> >>>>> 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
> >>>>> sessions with the IP address. The number of origin mobility
> >>>>> anchors
> >>>> are n - 1.
> >>>>> the questions: "Should we let the MN send mobilty signaling to
> its
> >>>> all mobility
> >>>>> mobility anchor for the establishment of the directional tunnels
> >>>>> or
> >>>> the
> >> _
> > ___________________________________________________
> >

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 24 Sep 2012 08:16:06 +0000

Hi,

of course the gap analysis can be limited to a study and assessment of solely available
IP mobility protocols. The question is against which template these gaps are assessed.
To tackle and address the complete space of DMM problems (and some of them are
very specific to DMM) I doubt that relying only on mobility extensions is sufficient.
Simply because the nature of DMM moves some problems out of the IP mobility
space. Squeezing them to fit into a mobility problem and solving them by mobility extension
may work functionally, but..

In the past, backend protocols played always role in solving the complete problem.
IMHO, some non-mobility protocols should be included in the analysis and the
solution space. If the WG wants to start with analyzing solely mobility protocols first
and extend the scope in a next step, fine. But I just worry that the limited gap analysis
will be taken as base to solve DMM completely as mobility protocol extension. That'll
help only to be fast, nothing else.

marco

>liu dapeng
>Sent: Donnerstag, 20. September 2012 05:47
>To: [email-masked]; jouni.nospam; Julien Laganier
>Cc: [email-masked]; [email-masked]
>I also have the similar thinking that we should first document and agree on the
>"practices for the deployment of existing mobility protocols in a distributed
>mobility management environment".  After that, if we find that there indeed
>some "gap" existing, we can then move to "gap analysis".
>
>Best Regards,
>Dapeng
>
>> mobility management environment" and, then, to make the gap analysis.
>> 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?
>>
>> 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
>>

---

From: <[email-masked]>
Date: Mon, 24 Sep 2012 09:44:38 +0000

Hi Kostas,

Maybe some clues in section 3.2 of draft-ietf-dmm-requirements and in https://tools.ietf.org/html/draft-chan-distributed-mobility-ps-05
As well in http://tools.ietf.org/id/draft-yokota-dmm-scenario-00.txt and http://tools.ietf.org/html/draft-liu-distributed-mobility-02 

Br,
Pierrick

> De : Konstantinos Pentikousis [mailto:[email-masked]]
> Envoyé : vendredi 21 septembre 2012 14:19
> À : SEITE Pierrick RD-RESA; [email-masked]; [email-masked]
> Actually, I would like to see a concrete definition, say, of less than
> 25 words, of what a "DMM environment" is. Pointers much appreciated.
> 
> Best Regards,
> 
> Kostas
> 
> 
>

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 26 Sep 2012 15:31:41 -0400

> I suggest that gap analysis should take into account the cloud.

I think you'll need to be more specific about what you call
an operator cloud network.

If it is just services hosted within the operator network,
I doubt that there's value in using the word "cloud".  To
the mobile node and rest of the infrastructure how a service
is provided above layer-3 should not be of concern.

As far as mobile nodes being part of a cloud, that's a
totally different problem, is it not?  I doubt that should
be in scope here.  DMM is hard enough without bringing
this in.

-- 
Wes Eddy
MTI Systems

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 26 Sep 2012 14:40:39 -0500

I am talking about 3GPP entities like Serving Gateway and PDN Gateway
being placed in the cloud.

Regards,

Behcet

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 26 Sep 2012 15:48:51 -0400

> being placed in the cloud.

Sure, so they run on a VM somewhere ... what's the technical
challenge that this poses?  To the mobile node and rest of
the DMM infrastructure, it should not matter whether these
are physical or virtualized.

-- 
Wes Eddy
MTI Systems

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 26 Sep 2012 15:08:08 -0500

> are physical or virtualized.

DMM is based on the premise that mobility entities come closer to the
UE and UE can access a different one as it moves. Central anchoring in
PMIPv6 or MIPv6 is no longer there.

With the cloud, two mobility entities may now become IPv6 neighbors in
the cloud. Trying to define signaling between such entities maybe no
longer a big issue.

With cloud, DMM's premise somewhat disappears. We need to find a new premise.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Thu, 27 Sep 2012 18:32:28 +0300

I am inclined to agree with Wes that DMM is hard enough already without
having clouds arising in the horizon. Cloud computing and such has a 
premise but I have hard time seeing how that would drive distributed
mobility management. I rather see it as opposite.. shifting the mindset
again towards centralized data centers.

On the other hand if we just think mobility management entities as VMs,
spawning new functions here and there does not differentiate from what
we are already trying to figure out - from mobility protocols point of
view. The difference would be that the possible gateway is not a physical
box anymore. The herding of VMs is not what we are tasked to do.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 27 Sep 2012 11:12:32 -0500

> again towards centralized data centers.

Yes, exactly. So cloud is going in a different direction then DMM,
unfortunately.

> box anymore. The herding of VMs is not what we are tasked to do.

Here the issue is these VMs doing mobility functions.
We need to develop a different set of goals for DMM implemented in VMs.
What are the issues there? Certainly different than the issues we are
considering now.
Will control plane/data plane separation be the central issue?

I am not saying we should not work on the current DMM direction. We
can work on both.

Regards,

Behcet