Subject: [DMM] rechartering draft comments

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 27 Mar 2014 14:51:08 -0500

|The DMM working group will also work on maintenance-oriented and
|     incremental extensions to the Proxy Mobile IPv6 protocol, specified
|     in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily
|      addresses any protocol gaps required to support existing |deployments
 |     and other standards development organizations using the Proxy |Mobile
|      IPv6 protocol in their system architectures.

Add Mobile IPv6 or remove the whole paragraph

|
|Enhanced gateway & mobility anchor selection and re-selection: define
|       protocol solutions for a gateway and mobility anchor selection that
|       go beyond what has been, for example, described in RFC 6097. |The
|        solution should also define a mechanism for anchor re-selection
|that allow
 |       preserving ongoing mobility sessions in a single administrative
|domain.

Based on the above paragraph we have two charter items which basically make
up the dmm solution.

What is the justification? Is it RFC 6097 (no offense to you Jouni)?
What about dmm solution that do not require any anchoring?
What about SDN, NFV ideas that have been expressed by Dapeng and others?

Sorry but I don't see any enthusiasm on this charter draft in the WG.

Behcet

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 27 Mar 2014 23:26:33 +0200

Behcet,

Thank you for constructive feedback. See inline.

> Add Mobile IPv6 or remove the whole paragraph

I see no point even trying to work on client mobile ipv6 enhancements..

> |        solution should also define a mechanism for anchor 
> re-selection |that allow
>  |       preserving ongoing mobility sessions in a single 
> administrative |domain.
>
> Based on the above paragraph we have two charter items which basically 
> make up the dmm solution.
>

You know that it just happens to be the only RFC even attempting to explain
how LMAs are selected dynamically. If the reference here is contentious, 
I am
happy to remore it.. just give me alternative text.

> What about dmm solution that do not require any anchoring

In scope and in the current text.

> What about SDN, NFV ideas that have been expressed by Dapeng and others?

Not explicitly mentioned by those hype terms but not prohibited either
in the charter text.

> Sorry but I don't see any enthusiasm on this charter draft in the WG.

Then help bring in the enthusiams. The easiest way is to provide
explicit text that we can then evaluate.

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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 27 Mar 2014 21:40:14 +0000

>happy to remore it.. just give me alternative text.

I agree. RFC6097 and RFC6463 are relevant to the above work item. It is
possible the WG may (most likely) adopt newer approaches for gateway
selection, but a reference to the prior work is very much relevant. It is
a very relevant reference. We do want to leverage work where possible. I'm
fine with this.

Regards
Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 27 Mar 2014 17:18:17 -0500

Hi Jouni,

See inline.

> I see no point even trying to work on client mobile ipv6 enhancements..
3GPP may need it in the context of DSMIPv6, just like PMIPv6.

> how LMAs are selected dynamically. If the reference here is contentious, I
> am
Where? I don't think any text counts as long as it is not in the milestones.

> explicit text that we can then evaluate.
Let me bring back my proposal:

First cycle, select one from each category of solutions, client, network
based and routing based
Second cycle, select one from the selected ones as the dmm solution.

 Hope this helps to bring the enthusiasm we need :-)

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Mar 2014 12:11:22 +0100

Le 27/03/2014 22:40, Sri Gundavelli (sgundave) a écrit :
>> You know that it just happens to be the only RFC even attempting
>> to explain how LMAs are selected dynamically. If the reference here
>> is contentious, I am happy to remore it.. just give me alternative
>> text.
>
>
> I agree. RFC6097 and RFC6463 are relevant to the above work item.

I am not sure where these two RFCs appeared from, I dont remember seeing
any discussion about them.  Clarification please?

I suppose work on anchor selection would need a form of problem 
statement - is there a problem statement in the current drafts?

> It is possible the WG may (most likely) adopt newer approaches for
> gateway selection, but a reference to the prior work is very much
> relevant. It is a very relevant reference. We do want to leverage
> work where possible. I'm fine with this.

I agree with these affirmations.

Alex

>
>
>
> Regards Sri
>
>
> _______________________________________________ dmm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>
>

---

From: <[email-masked]>
Date: Fri, 28 Mar 2014 13:28:06 +0000

Hi Alex

>-----Message d'origine-----
>De : dmm [mailto:[email-masked]] De la part de Alexandru Petrescu
>Envoyé : vendredi 28 mars 2014 12:11
>À : [email-masked]
>Objet : Re: [DMM] rechartering draft comments
>
>>> You know that it just happens to be the only RFC even attempting to
>>> explain how LMAs are selected dynamically. If the reference here is
>>> contentious, I am happy to remore it.. just give me alternative text.
>>
>>
>I suppose work on anchor selection would need a form of problem statement
>- is there a problem statement in the current drafts?
>

You can find information in the gap analysis draft; in http://tools.ietf.org/html/draft-aliahmad-dmm-anchor-selection as well

Pierrick

>> relevant. It is a very relevant reference. We do want to leverage work
>> where possible. I'm fine with this.
>

_________________________________________________________________________________________________________________________

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.