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

Hi Alex,


2013/8/1 Alexandru Petrescu <[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?


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

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


> 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] https://www.ietf.org/mailman/**listinfo/dmm<https://www.ietf.org/mailman/listinfo/dmm>
>>
>>
>>
>
> ______________________________**_________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/**listinfo/dmm<https://www.ietf.org/mailman/listinfo/dmm>
>



-- 

------
Best Regards,
Dapeng Liu

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm