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

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 protected]<mailto:[email protected]>>
Authors,

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

[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 :)

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.

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

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