Re: brief comparison

Hi Pierrick,

Le 09/01/2013 14:24, [email protected] a écrit :
> 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?

Yes, I the approach is relevant for the analysis.

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

Ah I see, that's why.  I agree - protocols that are deployed today.

Alex

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