Re: comments on draft-ietf-dmm-best-practices-gap-analysis-01

Le 07/08/2013 05:37, Liu Dapeng a écrit :
> Hi Alex,
>
>
> 2013/8/1 Alexandru Petrescu <[email protected]
> <mailto:[email protected]>>
>
> 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.
>
> [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
>  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.
>
> [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.
>
>
> [Dapeng] Yes, text will be appreciated.
>
> Dapeng
>
> 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 protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/__listinfo/dmm
> <https://www.ietf.org/mailman/listinfo/dmm>
>
>
>
>
> _________________________________________________ dmm mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/__listinfo/dmm
> <https://www.ietf.org/mailman/listinfo/dmm>
>
>
>
>
> --
>
> ------ Best Regards, Dapeng Liu