Subject: Re: [DMM] comments on draft-ietf-dmm-best-practices-gap-analysis-01

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Aug 2013 09:52:41 +0200

Hello DMMers,

I follow on the Chair invitation to suggest gaps to the gap analysis
document.  I must though say I have been following this discussion only
remotely so I am not up to date.

1. The Route Optimization feature of Mobile IPv6 does not support
    mobile network prefixes - it only works for a full /128 Home
    Address.  There is a security problem in extending the RR tests for
    prefixes.  But if done, it will allow direct communications from an
    LFN in the moving network to an arbitrary  Correspondent Node in the
    Internet.

2. Anchoring a Mobile Node's Home Address at multiple points may be a
    very good goal, but one wonders whether it could be achieved within
    useful limits.  An IP address is typically valid at a single point
    in the Internet.  Anchoring it at more places involves the use of
    route updates or of tunnelling.  It is a question whether this could
    be achieved within measurable and advantageous limits, compared to
    changing the IP address, or prefer still anchor at remote HA.

3. Simultaneous use of multiple interfaces at a same mobile router is
    something that is not supported by Mobile IPv6 today (although it
    does support multiple Care-of Addresses).  If done, it allows
    bandwidth augmentation (i.e. add 10 cellular interfaces to a Mobile
    Router deployed in a bus, and thus multiply the bandwidth by ten)
    for all kinds of applications.

These are some thoughts about gaps.  If necessary I can try to provide
text, provided I understand the current context.

Alex

Le 24/07/2013 14:54, Jouni Korhonen a écrit :
> Authors,
>
> I finally read the draft and below are some comments to hopefully
> help completing and improving the draft.
>
> In Section 4.2. it is stated:
>
> "view using common and standardized protocols.  Since WiFi is the
> most widely deployed wireless access technology nowadays, we take it
>  as"
>
> Do you have some data/reference to backup your claim?
>
> In Section 4.2.1. it is stated:
>
> "at different point of attachment.  However there is no mechanism
> specified to enable an efficient dynamic discovery of available"
>
> I would add a clarification here that there is no such mechanism
> available within IETF specifications. Other SDOs do have such
> mechanism (e.g. 3GPP).
>
> Furthermore, around the bulleted list for the MIPv6 RO discussion, I
>  would mention that nothing prevents a MN to use its CoA directly
> when communicating CNs on the same link or anywhere in the internet.
> Of course there is no mobility in that case but it is a valid
> scenario to mention IMHO (and also part of our charter). I recon the
> HMIPv6 text mentions at least the use of RCoA already.
>
> In Section 4.2.2. where the text describes RFC6463, I would also
> reference to RFC6097 since that has quite a bit of text regarding the
> discovery procedure of the LMA.
>
> While I found Section 4.2. good in general I was somehow expecting to
> see text regarding MOBIKE (RFC4555). We can safely assume MOBIKE is
> probably the most deployed client mobility enabling technology out
> there today.
>
> In Section 4.3. it says:
>
> "GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is a network-based
> mobility protocol specified for 3GPP networks (S2a, S2b, S5 and S8
> interfaces)."
>
> While 29.060 is about GTP, for the above referenced interfaces
> 29.281 and 29.274 are probably more appropriate.
>
> "A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO)
> enabled network [3GPP.23.829] allows offloading some IP services at"
>
> I would say referencing to e.g. 23.401 on LIPA/SIPTO is more
> appropriate these days, since the TR23.829 is somewhat left behind
> and the LIPA/SIPTO functionality is part of the main stage-2 specs
> already.
>
> I found Section 4 in general quite nice. However, I was somehow
> expecting to see a bit of text of WiMAX. Or can we safely state that
>  no IPv6 deployments ever took place in WiMAX? Anyway, at least a
> reference to WiMAX would be nice, since they spent quite a bit of
> time developing both CMIPv6 and PMIPv6 functionality into their
> architecture.
>
> In Section 4.3. I would reference to 3GPP TS29.303 and say something
> about 3GPP's heavy use of DNS as the "gateway location database" and
> how that is used to discover gateways with both topological and
> gateway collocation in mind
>
> In Section 5. it is stated:
>
> "o  The dynamic anchor relocation needs to ensure that IP address
> continuity is guaranteed for sessions that need it at the relocated
> anchor.  This for example implies having the knowledge"
>
> Since our charter _allows_ solutions where mobility is used "when
> needed" that fact should be reflected above. Even if there is
> mobility supported only locally within a limited area, it might meet
>  the requirements from the MN or the application point of view i.e.
> when the MN or the application does not care about a "full
> longstanding mobility" to be provided.
>
> "o  Dynamic discovery and selection of anchors.  There might be more
> than one available anchor for a mobile node to use.  Currently, there
> is no efficient mechanism that allows to dynamically discover the
> presence of nodes that can play the role of anchor, discover their
> capabilities and allow the selection of the most suitable one."
>
> Within 3GPP TS29.303 makes that possible and is deployed.
>
> In general the draft is heading to a good direction IMHO! Just
> complete it fast ;-)
>
> - Jouni
>
> _______________________________________________ dmm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>
>

---

From: <[email-masked]>
Date: Thu, 1 Aug 2013 07:58:34 +0000

Hi,

In this email I am repeting the comment that I had today on the mike:

The current version of the draft is not using the requirements defined in the requirements draft to identify the gaps on existing mobility protocols.

In my opinion it is important to use these requirements in order to identify the gaps.

Best regards,

Georgios

---

From: Liu Dapeng <[email-masked]>
Date: Mon, 5 Aug 2013 10:22:17 +0800

Hi Georgios:

Thanks for the comment, let us see how we resolve this in the updated
version.

Dapeng

2013/8/1 <[email-masked]>

> The current version of the draft is not using the requirements defined in
> the requirements draft to identify the gaps on existing mobility protocols.
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>
>

-- 

------
Best Regards,
Dapeng Liu

---

From: Liu Dapeng <[email-masked]>
Date: Wed, 7 Aug 2013 11:37:51 +0800

Hi Alex,

2013/8/1 Alexandru Petrescu <[email-masked]>

> [Dapeng] Mobile IPv6 Route Optimization is analysed in section 4.2.1. Do
you propose any changes of current text?

>    changing the IP address, or prefer still anchor at remote HA.

[Dapeng] Some current proposal in DMM WG use multiple home addresses for
multiple anchors.

> [Dapeng] I am not sure whether mobile router case should be in the scope
of DMM?

> text, provided I understand the current context.

[Dapeng] Yes, text will be appreciated.

Dapeng

>> ______________________________**_________________ dmm mailing list
>> [email-masked] https://www.ietf.org/mailman/**listinfo/dmm<https://www.ietf.org/mailman/listinfo/dmm>
>>
>>
>>
>
> ______________________________**_________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dmm<https://www.ietf.org/mailman/listinfo/dmm>
>

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Wed, 7 Aug 2013 10:10:30 +0000

Hi,

Please let me jump into the discussion. First of all, thanks for having read and comment the draft. Although, I agree with Dapeng's  answers, I have couple of comments:

2013/7/24 Jouni Korhonen <[email-masked]<mailto:[email-masked]>>
Authors,

  "view using common and standardized protocols.  Since WiFi is the most
   widely deployed wireless access technology nowadays, we take it as"

[Dapeng] Maybe we can change the wording a little bit. e.g. remove 'most'.

[Pierrick]  Here, the idea is to focus on a specific non-3GPP network as to give possible DMM practices; basically we have the choice between wimax and wifi... so I guess we can reasonably assume that WiFi is the most deployed, no? :). Anyway, we can just say :

"Since WiFi is widely deployed nowadays, we take it as"

Furthermore, around the bulleted list for the MIPv6 RO discussion, I would
mention that nothing prevents a MN to use its CoA directly when communicating
CNs on the same link or anywhere in the internet. Of course there is no
mobility in that case but it is a valid scenario to mention IMHO (and also
part of our charter). I recon the HMIPv6 text mentions at least the use of
RCoA already.
[Dapeng] Agree.

[pierrick] Well... Clearly, nothing prevent to use the CoA. In this case there is no IP address preservation, but mobility is still possible; for example, if the application can handle it. Of course, dynamic selection of the CoA or the HoA, e.g. depending on application characteristic,  (what we can call this feature "dynamic mobility support") is a valid scenario need to be addressed (it's in the charter if I remember well) . So, when the decision maker (e.g. connection manager, application, ...) decides that IP preservation is needed, then this document comes in, focusing on IP address preservation in a DMM style. This is what we stressed in section 4.1/bullet 3. But if current text gives the impression that dynamic mobility support is out of DMM scope, we have to revise this...

While I found Section 4.2. good in general I was somehow expecting to see
text regarding MOBIKE (RFC4555). We can safely assume MOBIKE is probably
the most deployed client mobility enabling technology out there today.

[Pierrick] Do you have some data/reference to backup your claim? ;-)

[Dapeng] We can add MOBIKE there.

I found Section 4 in general quite nice. However, I was somehow expecting
to see a bit of text of WiMAX. Or can we safely state that no IPv6 deployments
ever took place in WiMAX? Anyway, at least a reference to WiMAX would be
nice, since they spent quite a bit of time developing both CMIPv6 and
PMIPv6 functionality into their architecture.

[Dapeng] OK.

[Pierrick] originally we had text on wimax but we finally did not include in -01 to not burden the initial draft to favor discussion... so, no problem for adding Wimax :)

  "o  The dynamic anchor relocation needs to ensure that IP address
      continuity is guaranteed for sessions that need it at the
      relocated anchor.  This for example implies having the knowledge"

Since our charter _allows_ solutions where mobility is used "when needed"
that fact should be reflected above. Even if there is mobility supported
only locally within a limited area, it might meet the requirements from
the MN or the application point of view i.e. when the MN or the application
does not care about a "full longstanding mobility" to be provided.

[Dapeng] We can change the wording here.

[Pierrick] I definitely agree with Jouni, of course we do not want to exclude the dynamic aspect of the mobility support... This is why we wrote < for sessions that need [IP address continuity]". If you think it is not explicit enough we can reword... let us know..

BR,
Pierrick

_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Aug 2013 11:43:50 +0200

Le 07/08/2013 05:37, Liu Dapeng a écrit :
> Hi Alex,
>
>
> 2013/8/1 Alexandru Petrescu <[email-masked]
> <mailto:[email-masked]>>
>
> Hello DMMers,
>
> document.  I must though say I have been following this discussion
> only remotely so I am not up to date.
>
> mobile network prefixes - it only works for a full /128 Home Address.
> There is a security problem in extending the RR tests for prefixes.
> But if done, it will allow direct communications from an LFN in the
> moving network to an arbitrary  Correspondent Node in the Internet.
>
> [Dapeng] Mobile IPv6 Route Optimization is analysed in section 4.2.1.
> Do you propose any changes of current text?

It currently says:
> o  The RO mode is only supported by Mobile IPv6.  There is no route
> optimization support standardized for the NEMO protocol, although
> many different solutions have been proposed.

It should say:
> o  The RO mode is only supported by Mobile IPv6 for Mobile Hosts.
> There is no agreement for route optimization support for a Mobile
> Router running the NEMO extensions.  The difficulty lies, among other
> things, in extending the Return Routability tests of RO from a single
> address (the Home Address) to an entire set of addresses (the mobile
> network prefix).  Although no common RO solution for Mobile Router is
> agreed, many different solutions have been proposed; the Network
> Mobility Route Optiomization Solution Space Analysis is in RFC4889.

> 2. Anchoring a Mobile Node's Home Address at multiple points may be
> a very good goal, but one wonders whether it could be achieved
> within useful limits.  An IP address is typically valid at a single
> point in the Internet.  Anchoring it at more places involves the use
> of route updates or of tunnelling.  It is a question whether this
> could be achieved within measurable and advantageous limits, compared
> to changing the IP address, or prefer still anchor at remote HA.
>
> [Dapeng] Some current proposal in DMM WG use multiple home addresses
>  for multiple anchors.

Yes, and all have advantages and inconvenients (no session continuity).

> 3. Simultaneous use of multiple interfaces at a same mobile router
> is something that is not supported by Mobile IPv6 today (although it
> Router deployed in a bus, and thus multiply the bandwidth by ten) for
> all kinds of applications.
>
> [Dapeng] I am not sure whether mobile router case should be in the
> scope of DMM?

I do not know either.  The charter is explicit about the use of NEMO,
but not sure whether current DMM works consider this Mobile Router
paradigm from start or for later.

Alex

>
> These are some thoughts about gaps.  If necessary I can try to
> provide text, provided I understand the current context.
>
>
> would mention that nothing prevents a MN to use its CoA directly when
> communicating CNs on the same link or anywhere in the internet. Of
> course there is no mobility in that case but it is a valid scenario
> to mention IMHO (and also part of our charter). I recon the HMIPv6
> text mentions at least the use of RCoA already.
>
> reference to RFC6097 since that has quite a bit of text regarding
> the discovery procedure of the LMA.
>
> While I found Section 4.2. good in general I was somehow expecting
> to see text regarding MOBIKE (RFC4555). We can safely assume MOBIKE
> is probably the most deployed client mobility enabling technology
> out there today.
>
> In Section 4.3. it says:
>
> While 29.060 is about GTP, for the above referenced interfaces 29.281
> and 29.274 are probably more appropriate.
>
> _________________________________________________ dmm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/__listinfo/dmm
> <https://www.ietf.org/mailman/listinfo/dmm>
>
>
>
>
> _________________________________________________ dmm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/__listinfo/dmm
> <https://www.ietf.org/mailman/listinfo/dmm>
>
>
>
>
> --
>
> ------ Best Regards, Dapeng Liu