I agree, let's not mixup DMM API with MIF API….

On Mar 18, 2014, at 10:41 AM, <[email protected]> wrote:

> Hi,
> 
> Mobility issues are not specifically in MIF scope. So, as long as we are 
> talking about exposing mobility state, the I-D should be in DMM. Another 
> reason is that MIF is still discussing the generic MIF API, so, I'm not sure 
> they can go on the mobility  area before a while.
> 
> Pierrick
> 
>> -----Message d'origine-----
>> De : dmm [mailto:[email protected]] De la part de Zuniga, Juan Carlos
>> Envoyé : mardi 18 mars 2014 05:08
>> À : Sri Gundavelli (sgundave); Jouni Korhonen; [email protected]
>> Objet : Re: [DMM] re-charter text updated
>> 
>> Hi,
>> 
>>> -----Original Message-----
>>> From: dmm [mailto:[email protected]] On Behalf Of Sri Gundavelli
>>> (sgundave)
>>> Sent: Monday, March 17, 2014 11:49 PM
>>> To: Jouni Korhonen; [email protected]
>>> Subject: Re: [DMM] re-charter text updated
>>> 
>>> 
>>> 
>>> On 3/17/14 7:20 PM, "Jouni Korhonen" <[email protected]> wrote:
>>> 
>>>> Folks,
>>>> 
>>>> Triggered by the question from Behcet, we should come up with the
>>>> milestones. Few proposals:
>>>> 
>>>> o The deployment models and scenarios I-D is obvious.
>>>> o Anchor selection I-D is obvious. Could we also bundle
>>>> the re-anchoring solution into this one or should it be
>>>> a different I-D?
>>> 
>>> 
>>> IMO, these are two different topics and can be kept as separate work
>> items.
>>> 
>>> Anchor selection is tied to access network, request path, policy,
>> handovers
>>> and load on the target elements. The entity using the gateway
>> selection can
>>> be a end point, a network node or a policy system. The bulk of the
>> work is
>>> around laying out the considerations for gateway selection and
>> specifying
>>> the logic. The selection to most part is about the assigning a gateway
>> during
>>> initial session establishment.
>>> 
>>> Session Re-anchoring is about moving a session state between gateways,
>>> after the session got established. It has impact on the forwarding
>> plane and
>>> is more about a routing problem. But, you may argue this is also
>> touching
>>> the aspect of gateway (re)-selection at a failure point. In this sense
>> there is
>>> some relation there, but it depends on how the re-anchoring solution
>> is
>>> specified.
>>> 
>>> IMO, its better to track them as separate work items.
>> 
>> [JCZ] +1
>> 
>>> 
>>> 
>>>> o Mobility state exposing I-D. This would communication
>>>> between the end host and the network. Maybe also covering
>>>> the missing parts within the end host.. Are we OK with one
>>>> I-D or how people want to see this?
>>> 
>>> 
>>> Single ID is fine.
>> 
>> [JCZ] Single ID is fine indeed. However, we still need to assess whether this
>> will be a DMM or a MIF ID.
>> 
>> Regards,
>> 
>> Juan Carlos
>> 
>>> 
>>> 
>>> Regards
>>> Sri
>>> 
>>> _______________________________________________
>>> 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,
> 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

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

Reply via email to