Hi Alex, Please see inline.
Pierrick > -----Message d'origine----- > De : [email protected] [mailto:[email protected]] De la part de > Alexandru Petrescu > Envoyé : mercredi 9 janvier 2013 11:26 > À : [email protected] > Objet : Re: [DMM] brief comparison (was: Call for WG Adoption of a > "current practices and gap analysis" document) > > Hello DMMers, > > I take advantage of this request to expose briefly a comparison between > the two drafts draft-zuniga-dmm-gap-analysis-03 and draft-liu-dmm-best- > practices-gap-analysis-01. > > The first analyses gaps between DMM reqs and MIP6, MIP6-RO, HMIP, > HAswitch, flow mobility, src adr selection. Each of these is an actual > mechanism. > > The second: although it also lists such mechanisms, it guides the gap > analysis by a few mobility management functions, which are abstracted > out of the existing protocols. These functions are anchoring, mobility > routing, internetwork location management, location update. > > I do have a preference for this latter approach. > > However, I also think a refinement of its abstraction is possible. For > example, there are more functions which MIP6 does and which are not > reflected in the abstraction, e.g. DHAAD. > You're right. Actually your comment is related to the "DMM and the framework discussion" has been initiated by Jouni: http://www.ietf.org/mail-archive/web/dmm/current/msg00542.html clearly, the functional framework is to be refined but I think we can agree on the relevance of the approach for the analysis. Right? > Also, the route optimization mechanism seems better analyzed in the > former document. > > Finally, none of the documents mentions the tunnelling-vs-non- > tunnelling approaches, although the former draft leads indirectly to a > location-id split method (which includes translation in that case, see > Liebsch, translation which is incomplete too because not mentioning the > implemented NPT IPv6 RFC6292) (and non-tunnelling host-based routes are > possible without translation). Actually, as you mentioned, draft-liu does not claim to cover all possible protocols. This I-D focuses, intentionally, on protocols that are deployed today. However, the list of protocols can of course be expanded if useful. Pierrick > > That is for discussion only, Subject changed. > > Yours, > > Alex > > Le 19/12/2012 21:25, Jouni Korhonen a écrit : > > Folks, > > > > We are unfortunately slipping our milestone, our (chairs) apologies > > for that. The next step is to select a "current practices and gap > > analysis" document to serve as the basis for the future WG document. > > We consider two documents on this topic to choose from: > > > > [1] draft-zuniga-dmm-gap-analysis-02 [2] > > draft-liu-dmm-best-practices-gap-analysis-01 > > > > and we as a WG need to decide which one is going to form the _basis_ > > for the WG document. > > > > Please voice your preference either for [1] or for [2] on the mailing > > list. We would appreciate if you can also provide a one-liner > > justification for your selection. The chairs will determine if there > > is (rough) consensus from active WG participants to proceed with > > selecting one document against the other. > > > > The call starts today 19th Dec 2012 and ends by 10th Jan 2013. We > have > > a longer three week call now due the holiday season in between. > > > > - Jouni & Julien _______________________________________________ dmm > > mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm > > > > > > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _________________________________________________________________________________________________________________________ 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, France Telecom - 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, France Telecom - 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
