Re: draft charter text updates in github..

Hi Jouni,

Thank you for the revision.

Here are my comments:


      When extending non- IP mobility protocols, solutions should be
      reviewed and ratified by the WGs having the "ownership" of those
      protocols.

I think you mean "protocols that are not based on Mobile IP" instead of "non-IP mobility protocols".



      Although Internet-wide maintenance of the stable home address(es) or prefix(es)
      is a desirable goal when mobile hosts/routers change their point of
      attachment to the network, it is not a strict requirement on the DMM solutions. Mobile
      hosts/routers should not assume that the home address(es) and/or
      home network prefix(es) remain the same throughout the entire
      application level session lifetime, unless such property is indicated
      to the mobile node/router and its applications from the network.

Inserted the red text above.


      If the network or the mobile host/router do not
      support the distributed mobility management enabling protocol that
      should not prevent the mobile host/router gaining basic (i.e., nomadic) access to the
      network.


Red text again…


      o Enhanced mobility anchoring: define protocol solutions for a gateway and
        mobility anchor assignment and mid-session mobility anchor switching
        that go beyond what has been, for example, described in RFC 6097, 6463,
        and 5142. The solution should also define a mechanism for preserving
        ongoing mobility sessions in a single administrative or IGP routing
        domain, which would involve directing traffic towards the new anchor.
        
      o Forwarding path and signalling management: the mobility agent that handles
        the mobility signalling interacts with the network elements in the DMM network
        for managing the forwarding state associated with a mobile node's IP traffic.
        These two functions may or may not be collocated. Furthermore, the forwarding
        state may also be distributed into multiple network elements instead of a
        single anchor like network element. Define required protocol extensions to
        allow described forwarding path and signalling management.


These above two seem inseparable. 
I recommend we list them as one item.
(The separation was between "anchor selection" and "data-path management signaling" before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items. In this latest text, the separation got blurred. The title of the first item, along with references to "switching", "preserving sessions", "directing traffic" all point to the context of the second one…)
We can note that separate anchor discovery & selection drafts may be produced (opening the door for split documents, while not forcing people to split any solution into two parts because the charter said so..)


Alper



On Jun 11, 2014, at 2:36 PM, Jouni Korhonen wrote:

> 
> A heavily updated charter text in the github. I am not sure it addresses all wording concerns folks had. But.. flame on ;)
> 
> Reading the telco notes I realize I do not have nor have seen the slides shown during the call, so probably the "re-anchoring" sanitization in the charter text went too far compared what was discussed in the call. Please check.
> 
> If you have concerns on the milestones and specifically their timeline, express your opinion with a new month+year combination.
> 
> The cooperation with other WGs is heavily reworded. Basically it says now that DMM can mock other protocols but those then need review & ratification from the protocol "owning" WG, just like commonly done with DHCP & RADIUS.
> 
> Routing based solutions are now explicitly stated to be restricted to IGP routing domain and must not propagate routing updates outside the IGP routing domain.
> 
> Regarding the "enhanced mobility anchoring" milestone that could also be put under maintenance:
> 
>  Work items related to the PMIPv6 maintenance include:
> 
>   o Enhanced mobility anchoring: define protocol solutions for a
>     gateway and mobility anchor assignment and mid-session mobility
>     anchor switching that go beyond what has been, for example,
>     described in RFC 6097, 6463, and 5142. The solution should also
>     define a mechanism for preserving ongoing mobility sessions in a
>     single administrative or IGP routing domain, which would involve
>     directing traffic towards the new anchor.
> 
> Opinions?
> 
> 
> - Jouni
> 
> 
> 
> 6/6/2014 5:37 PM, Alper Yegin kirjoitti:
>> Hello Jouni, DMM folks,
>> 
>> We better clarify what "anchor re-selection" stands for.
>> If it is about selecting different anchors for different IP flows, that's one thing.
>> If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG.
>> 
>> I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good.
>> 
>> Cheers,
>> 
>> Alper
>> 
>> 
>> 
>> On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote:
>> 
>>> Folks,
>>> 
>>> Minor changes..
>>> 
>>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt
>>> 
>>> IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-)
>>> 
>>> I have put in editorial changes of my own and clear text proposals received from others.
>>> 
>>> - Jouni
>>> 
>>> _______________________________________________
>>> dmm mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/dmm
>>

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