Subject: Re: [DMM] regarding the re-chartering..

From: Alper Yegin <[email-masked]>
Date: Tue, 5 Aug 2014 11:43:46 +0300

Hello,

Thank you Kostas for this rewrite. The charter reads better now.

Please see below for few comments.

On Jul 30, 2014, at 11:20 AM, Jouni Korhonen wrote:

> Folks,
> 
> A major rewrite of the charter is in github (and below). Thanks to Kostas providing excellent feedbask on the text. Comments are welcome.
> 
> --------------------------------------------------------------------
> 
> Description of Working Group:
> 
> Mobility management solutions lie at the center of the wireless Internet
> and enable mobile devices to partake in IP networks anytime and
> anywhere. The IETF Distributed Mobility Management (DMM) working group
> (WG) specifies solutions for IP networks so that traffic can be
> expedited between mobile and correspondent nodes. DMM solutions aim for
> transparency above the IP layer, including maintenance of active
> transport level sessions when mobile hosts or mobile networks change
> their point of attachment to the Internet.
> 
> Wireless network deployments have traditionally relied on hierarchical
> schemes that often lead to centralized deployment models, where a small
> number of mobility anchors manage both mobility and reachability for a
> mobile node. The DMM WG will consider the latest developments in mobile
> networking research and operational practice (i.e. flat network
> architectures, the impact of virtualization, new deployment needs as
> wireless access technologies evolve in the coming years) and will
> describe how distributed mobility management addresses the new needs in
> this area better than previously standardized solutions.
> 
> A topic of particular focus will be mobility anchoring in this new
> context, and the DMM working group is chartered to work on
> maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC
> 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new
> approaches which capitalize on other protocols specified by the IETF.
> When extending protocols that are not based on Mobile IP, DMM solutions
> will be have to be reviewed by the corresponding WGs.
> 
> IPv6 is assumed to be present in both the mobile host/router and the
> access networks. DMM solutions are primarily targeted at IPv6
> deployments and are not required to support IPv4, in particular for the
> case where private IPv4 addresses and/or NATs are used. DMM solutions
> must maintain backward compatibility: If the network or the mobile
> host/router does not support the distributed mobility management
> protocol that should not prevent the mobile host/router gaining basic
> access (i.e., nomadic) to the network.
> 
> Contrary to earlier IP mobility protocols, mobility management signaling
> paths and end-user traffic forwarding paths may differ. Further,
> mobility-related functions may be located in separate network nodes.
> DMM
> solutions should not distinguish between physical or virtualized
> networking functions. Whenever applicable, clarifications and additional
> features/capabilities for specific networking function deployment
> models, e.g. in virtualized environments, are in-scope and encouraged.
> Solutions may also specify the selection between the care-of addresses
> and home address(es)/prefix(es) for different application use cases.
> 
> Work items related to distributed mobility management include:
> 
>      o Distributed mobility management deployment models and scenarios:
>        describe the target high-level network architectures and
>        deployment models where distributed mobility management
>        protocol solutions could apply.
> 

Can someone elaborate on what kind of information will go into such a document?

>      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 specified, for
>        example, in RFC 6097, 6463, and 5142. Traffic steering
>        associated with the anchor switch is also in-scope if deemed
>        appropriate.
> 
>      o Forwarding path and signaling management: the function
>        that handles mobility management signaling interacts with the
>        DMM network elements 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 network element (e.g., anchor). Protocol extensions
>        or new protocols will be specified to allow the above mentioned
>        forwarding path and signalling management.
> 

I cannot separate "mobility anchoring" from "fwding path and signaling management".
Wherever you want to set your anchor or move your anchor to, you'd need signaling and setting up data path. The two are inseparable.
Having said that, I'm OK to keep the current work item descriptions and finalize rechartering. Once we have detailed discussions about the breakdown of the work, we can come back and refine the goals and milestones (as already stated below [*]).

>      o Exposing mobility state to mobile nodes and network nodes:
>        define solutions that allow, for example, mobile nodes to select
>        either a care-of address or a home address depending on an
>        application' mobility needs. In order to enable this
>        functionality, the network-side control functions and other
>        networking nodes must also be able to exchange appropriate
>        control information, as well as to the mobile nodes and their
>        applications.
> 
> The working group may decide to extend the current milestones based on
> the new information and knowledge gained during working on other
> documents listed in the initial milestones. [*]

Cheers,

Alper

> Possible new documents and
> milestones must still fit into the overall DMM charter scope as outlined
> above.
> 
> Goals and Milestones:
> 
>  Feb 2015 - Submit 'The deployment models and scenarios' as a working
>             group document(s). To be Informational RFC.
> 
>  Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group
>             document. To be Proposed Standard.
> 
>  Feb 2015 - Submit 'Forwarding path and signaling management' as a
>             working group document. To be Proposed Standard.
> 
>  May 2015 - Submit 'Exposing mobility state to mobile nodes and network
>             nodes' as a working group document(s). To be Proposed
>             Standard.
> 
> 
>  May 2015 - Submit 'The deployment models and scenarios' submitted to
>             the IESG. To be Informational RFC.
> 
>  Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG.
>             To be Proposed Standard.
> 
>  Jun 2015 - Submit 'Forwarding path and signaling management' submitted
>             to the IESG. To be Proposed Standard.
> 
>  Oct 2015 - Submit 'Exposing mobility state to mobile nodes and network
>             nodes' submitted to the IESG. To be Proposed Standard.
> 
> 
> 
> 7/29/2014 4:22 PM, Jouni Korhonen kirjoitti:
>> The webex sessions have been cancelled in accordance of better IETF
>> process compliancy. New dates will be announced rougghly two weeks ahead
>> of tomorrow.
>> 
>> You can (and should) still actively send edits to the list and I'll
>> update the text accordingly. Maybe we manage to get ready even without a
>> call!
>> 
>> - Jouni & Dapeng
>> 
>> 7/25/2014 12:49 AM, Jouni Korhonen kirjoitti:
>>> Folks,
>>> 
>>> The latest charter draft can be found here:
>>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt
>>> 
>>> 
>>> The deadline for the text chnges are 31st July. I'll setup a call for
>>> next week so that those who want to dial in and have verbal commenting
>>> can do that. In a meanwhile, email works as usual for updates and
>>> comments on the text. The actual milestone dates are to be done last but
>>> suggestions are more than welcome.
>>> 
>>> - Jouni & Dapeng
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 13 Aug 2014 14:42:08 +0300

Alper, all,

> Can someone elaborate on what kind of information will go into such a document?

See the reply to Brian:
http://www.ietf.org/mail-archive/web/dmm/current/msg01406.html

> Wherever you want to set your anchor or move your anchor to, you'd need signaling
 > and setting up data path. The two are inseparable.
> Having said that, I'm OK to keep the current work item descriptions and finalize
 > rechartering. Once we have detailed discussions about the breakdown 
of the work, we
 > can come back and refine the goals and milestones (as already stated 
below [*]).

The enhanced mobility anchoring above is/was rather MIP type solutions 
influenced with "anchors" like we understand today, while the 
"forwarding path and signaling management" was meant for more future 
oriented solutions where the forwarding path does not necessarily have 
anything mobility specific etc.

Any other opinions on collapsing these two?

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Wed, 13 Aug 2014 15:35:56 +0300

Hi Jouni,

> http://www.ietf.org/mail-archive/web/dmm/current/msg01406.html

Yes, I had read that. But even that does not really clarify it for me. Brian had said and you had agreed that:

I interpreted the the charter text as describing
deployment models like:

- Wi-Fi-based mobility management

- Cellular (e.g., 3GPP) mobility management

- Mixed technology mobility management

But, what exactly would go into, say, 3GPP mobility management? Are we going to describe how 3GPP system works? 
Would that be simply documenting 3GPP mobility in an IETF draft?

> > rechartering. Once we have detailed discussions about the breakdown of the work, we
> > can come back and refine the goals and milestones (as already stated below [*]).
> 
> The enhanced mobility anchoring above is/was rather MIP type solutions influenced with "anchors" like we understand today, while the "forwarding path and signaling management" was meant for more future oriented solutions where the forwarding path does not necessarily have anything mobility specific etc.
> 

(Just FYI: It's not possible to gather what you are saying from reading the charter. Different people reading the charter may not have the same understanding. But like I said, this is just FYI, I can live with this text until we come back and refine it later).

Thanks.

Alper

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Aug 2014 22:44:14 +0000

Hi Jouni,

Is the draft charter under some sort of version control, or are
the previous versions gone for good?

Thanks - Fred
[email-masked]

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 14 Aug 2014 08:38:23 +0300

https://github.com/jounikor/dmm-re-charter

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Aug 2014 14:37:41 +0000

OK, I see it now. thanks.

Fred

> -----Original Message-----
> From: Jouni Korhonen [mailto:[email-masked]]
> Sent: Wednesday, August 13, 2014 10:38 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [DMM] regarding the re-chartering..
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Aug 2014 15:39:12 +0000

> will be have to be reviewed by the corresponding WGs.

That text has changed considerably from earlier versions but I am
still thinking that AERO can be considered a "new approach which
capitalizes on other protocols specified by the IETF". Am I right
that AERO could be a candidate for such a "new approach"?

If so, then my only concern is that AERO doesn't currently have a
working group home, and I was sort of thinking dmm could become
the home working group. Is that wishful thinking?

Thanks - Fred

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 19 Aug 2014 17:12:20 +0300

Alper,

> Would that be simply documenting 3GPP mobility in an IETF draft?

Okay, we are not going to define how the existing 3FPP system works - 
that knowledge is assumed. What I thought goes into the document, for 
example, in the case of 3GPP system would be identifying the 
architecture changes or modifications needed. If the deployment model 
assumes all network functions are virtualized, the document states that 
and lays out the architecture based on that. Satoru's & Ryuji's vEPC 
deployment model (based on their solution) is IMHO a good example of 
what could be documented. The similar applies for other system 
architectures such as SP Wi-Fi etc.

> (Just FYI: It's not possible to gather what you are saying from reading
> the charter. Different people reading the charter may not have the same
> understanding. But like I said, this is just FYI, I can live with this
> text until we come back and refine it later).

Ok. I'll try to clarify the point the text tries to make.

- Jouni

>>>> [email-masked] <mailto:[email-masked]>