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

Hi Jouni,

Thanks for the comments.


2013/7/24 Jouni Korhonen <[email protected]>

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

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


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

[Dapeng] OK.


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


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

[Dapeng] OK.


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

[Dapeng] We can add MOBIKE there.


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

[Dapeng] We will  add those reference.

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

[Dapeng] We will update this reference.

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


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

[Dapeng] OK.


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

[Dapeng] We can change the wording here.


>   "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.
>
> [Dapeng] We can scope the statement in IETF?


> In general the draft is heading to a good direction IMHO! Just complete
> it fast ;-)
>

[Dapeng] Thanks for the valuable comments. We will update the draft
according to the comments soon.

Dapeng

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



-- 

------
Best Regards,
Dapeng Liu

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