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

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