Subject: [DMM] WG Review: Distributed Mobility Management (dmm)

From: The IESG <[email-masked]>
Date: Fri, 03 Oct 2014 12:38:29 -0700

The Distributed Mobility Management (dmm) working group in the Internet
Area of the IETF is undergoing rechartering. The IESG has not made any
determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to
the IESG mailing list (iesg at ietf.org) by 2014-10-13.

Distributed Mobility Management (dmm)
------------------------------------------------
Current Status: Active WG

Chairs:
  Dapeng Liu <[email-masked]>
  Jouni Korhonen <[email-masked]>

Assigned Area Director:
  Brian Haberman <[email-masked]>

Mailing list
  Address: [email-masked]
  To Subscribe: https://www.ietf.org/mailman/listinfo/dmm
  Archive: http://www.ietf.org/mail-archive/web/dmm

Charter:

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 between mobile
and correspondent nodes can take an optimal route. 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. flattening 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.
For example, mobility management in a limited area, such as within an
autonomous system, is not strictly limited to mentioned IP mobility
protocols but can be any existing or a new protocol solution enabling
the movement of a mobile node such as routing protocols. When extending
protocols that are not based on Mobile IP, DMM solutions will 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.

The working group will produce both informational architectural and
standards track protocol solutions on the following work item topics.

      o Distributed mobility management deployment models and scenarios:
        describe the target high-level network architectures and
        deployment models where distributed mobility management
        protocol solutions would apply.

      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.

      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. Possible new documents and
milestones must still fit into the overall DMM charter scope as outlined
above. 

Milestones:

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 7 Oct 2014 07:50:04 +0200

Dear IESG,

I received you message request for review, but there are some issues
missing for my review. For example there is no milestones presented even
though the submitted charter states below

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

Where are the initial milestone, the above statement refers to? did this WG
decide on the milestones or not? When I review the WG production there is
only one RFC and one adopted draft, while previous charters were aiming for
more drafts. In first charter dated 2007 there were about three work
items/drafts suggested without milestones which is ok because it is new but
what happened? I want to know why we did not achieve that? an input from
the AD can help.

Creating/Rechartering WGs while not having clear milestones will cost
IETF. I need to see in your review request of charter/recharter the
following so that I can make better review:

- if new WG, there can be no milestones decided, but need to have some
individual drafts submitted for discussions and for future adoption plans.
- if new WG, there should be in the charter related works/RFCs in IETF that
this WG will consider.
- if recharter WG, I need to know its evaluation of previous charter(s),
and why recharter?
- if recharter WG, I need to know clear milestones (dates of submissions
and date of conclude) and clear/stated adopted drafts and non adopted
drafts that are under consideration.
- All WG charters MUST have a date of conclude/recharter, otherwise we may
waste time/space/money in IETF.
- I prefer if the IETF charter has sections that are must and sections that
are optional, so that we agree on how we review such charter. I think
milestones are must for recharters and optional for new WG charter.
- I require for my best review for recharter, a review AD evaluation
section for the WG's previous charter(s) and challenges.

Please note we need to take care with the charter details,
the WG-decisions and then recharter review. Therefore, I object this WG to
recharter until its WG decides the milestones and have clear work adoption
plan related to drafts mentioned in the charter.

Regards,

AB

On Friday, October 3, 2014, The IESG wrote:

>   Dapeng Liu <[email-masked] <javascript:;>>
>   Jouni Korhonen <[email-masked] <javascript:;>>
>
> Assigned Area Director:
>   Brian Haberman <[email-masked] <javascript:;>>
>
> Mailing list
>   Address: [email-masked] <javascript:;>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 07 Oct 2014 12:13:36 +0300

Hi,

Thank you for the review. See my initial comments inline.

> documents listed in the initial milestones. "

When we submitted the re-charter text we were given an advice to leave 
them out - for some reason. Anyway, these were the milestones at the 
time of finishing the text in the WG:

   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.

   Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG.
              To be Proposed Standard.

   Nov 2015 - Submit 'Forwarding path and signaling management' submitted
              to the IESG.  To be Proposed Standard.

   Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network
              nodes' submitted to the IESG. To be Proposed Standard.

They are probably as of now, too aggressive time wise.

> Where are the initial milestone, the above statement refers to? did this
> WG decide on the milestones or not? When I review the WG production
> there is only one RFC and one adopted draft, while previous charters

WG has completed its work on the previous charter items. The last I-D is 
already past IETF LC and hopefully entering IESG telechat agenda any 
time soon.

> were aiming for more drafts. In first charter dated 2007 there were
> about three work items/drafts suggested without milestones which is ok
> because it is new but what happened? I want to know why we did not
> achieve that? an input from the AD can help.

See above.

- JOuni

> - if new WG, there should be in the charter related works/RFCs in IETF
> that this WG will consider.
> - All WG charters MUST have a date of conclude/recharter, otherwise we
> may waste time/space/money in IETF.
> - I prefer if the IETF charter has sections that are must and sections
> that are optional, so that we agree on how we review such charter. I
> think milestones are must for recharters and optional for new WG charter.
> the WG-decisions and then recharter review. Therefore, I object this WG
> to recharter until its WG decides the milestones and have clear work
> adoption plan related to drafts mentioned in the charter.
>
> Regards,
>
> AB
>
>     the IESG mailing list (iesg at ietf.org <http://ietf.org>) by
>     2014-10-13.
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 7 Oct 2014 11:40:35 -0500

Hi Satoru,

I copied Jouni's mail and removed ietf and iesg from the list.

On Tue, Oct 7, 2014 at 4:13 AM, Jouni Korhonen <[email-masked]> wrote:
> When we submitted the re-charter text we were given an advice to leave them
> out - for some reason. Anyway, these were the milestones at the time of
> finishing the text in the WG:
>

The above clearly states that three different protocols will be
developed by DMM as Proposed Standard.

You are an operator.
Can you please comment on the possibility of adoption by operators
three different protocols for DMM?

BTW there is no mention of deployment models and related milestones.

Regards,

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Oct 2014 13:38:29 +0200

Hello,

I would like to comment on reusing prior work.

Citing RFC3963 and RFC 5177 (v4 and v6 extensions to Mobile IP for 
network mobility) seems logical to me, since they're about Mobile IP too.

Citing RFC 4888 and RFC 4889 (NEMO Route Optimization PS and solution 
analysis) seems logical to me, since the charter says "optimal" routes.

Currently there is discussion in the DMM WG sketching potential 
solutions.  When they're ready they'll certainly compare to these two 
sets of RFCs, and will have to answer same questions: does it work with 
Mobile Router (not just Mobile Host)?  does it offer optimal routes? 
does it modify CN?  is it subject to 'stalemate' situations (RFC4888 
section 2.7)?  does it involve multiple encapsulations?  does it permit 
nestedness?

Alex

---

From: Jouni <[email-masked]>
Date: Wed, 8 Oct 2014 16:00:14 +0300

Alex, 

Do you have a specific change to the text in mind? The charter text uses systematically "mobile host/router" to make sure mobile routers are not forgotten. However, charter also allows solutions that are not specifically tailored to mobile routers. 

Jouni

-- 
Jouni Korhonen
Broadcom

(Sent from my mobile..)

> Alexandru Petrescu <[email-masked]> kirjoitti 8.10.2014 kello 14.38:
> 
> Hello,
> 
> Citing RFC3963 and RFC 5177 (v4 and v6 extensions to Mobile IP for network mobility) seems logical to me, since they're about Mobile IP too.
> 
> Citing RFC 4888 and RFC 4889 (NEMO Route Optimization PS and solution analysis) seems logical to me, since the charter says "optimal" routes.
> 
> Currently there is discussion in the DMM WG sketching potential solutions.  When they're ready they'll certainly compare to these two sets of RFCs, and will have to answer same questions: does it work with Mobile Router (not just Mobile Host)?  does it offer optimal routes? does it modify CN?  is it subject to 'stalemate' situations (RFC4888 section 2.7)?  does it involve multiple encapsulations?  does it permit nestedness?
> 
> Alex
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Oct 2014 16:23:52 +0200

Jouni,

Thank you for the message.

Here are the modifications:

Where the Charter mentions "Mobile IPv6 protocol family (RFC x, y, z)" 
it should also mention RFC 3963 and RFC 5177.

(these RFCs were mentioned in past versions but disappeared somehow).

Where the Charter says "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. 
Possible new documents and milestones must still fit into the overall 
DMM charter scope as outlined above. Milestones:[empty]"

Please clarify that "initial milestones" is "RFC 4888, RFC 4889, 
draft-ietf-dmm-best-practices-gap-analysis-08").

Alex

Le 08/10/2014 15:00, Jouni a écrit :
> Alex,
>
> Do you have a specific change to the text in mind? The charter text
> uses systematically "mobile host/router" to make sure mobile routers
> are not forgotten. However, charter also allows solutions that are
> not specifically tailored to mobile routers.
>
> Jouni
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 8 Oct 2014 14:25:39 +0000

FWIW, AERO is a mobile router solution. But, it is easy to make an AERO mobile router
act like a mobile host. Cell phones, tablets, laptops, etc. are all good candidate AERO
mobile router/hosts. (Airplanes, automobiles, ocean-going vessels, etc. are also good
candidate AERO mobile routers.)

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Jouni
> Sent: Wednesday, October 08, 2014 6:00 AM
> To: Alexandru Petrescu
> Cc: [email-masked]; dmm WG
> Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm)
> 
> Alex,
> 
> Do you have a specific change to the text in mind? The charter text uses systematically "mobile host/router" to make sure mobile
> routers are not forgotten. However, charter also allows solutions that are not specifically tailored to mobile routers.
> 
> Jouni
> 
> --
> Jouni Korhonen
> Broadcom
> 
> (Sent from my mobile..)
> 
> > Currently there is discussion in the DMM WG sketching potential solutions.  When they're ready they'll certainly compare to these
> two sets of RFCs, and will have to answer same questions: does it work with Mobile Router (not just Mobile Host)?  does it offer
> optimal routes? does it modify CN?  is it subject to 'stalemate' situations (RFC4888 section 2.7)?  does it involve multiple
> encapsulations?  does it permit nestedness?
> >
> > Alex
> >

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 08 Oct 2014 20:44:26 +0300

Alex,

> it should also mention RFC 3963 and RFC 5177.

Hmm.. rather that listing all possible Mobile IP related protocols the 
charter text could just have "e.g." in front of the list of RFCs we got 
there at the momemt?

> (these RFCs were mentioned in past versions but disappeared somehow).

Yes, to avoid listing all possible RFCs on this topic.

> draft-ietf-dmm-best-practices-gap-analysis-08").

See http://www.ietf.org/mail-archive/web/dmm/current/msg01652.html

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 8 Oct 2014 14:14:30 -0500

Hi Alex,

Added to the point you made, I have concerns on

Enhanced mobility anchoring work item text and the references made
there (BTW among others).

The RFCs cited there, RFC 6097, 6463, and 5142 all progressed after
the base protocol was developed,  RFC 3775 or MIPv6 for 5142 and  RFC
5213 or PMIPv6 for 6097 and 6363.
They were extensions to what the protocol had offering some more
advanced methods.

My concern is DMM is being rechartered to develop the base solution.
How could the base protocol be held to such a high standard even
before its existence?

I have similar concerns on the other work items and I think they carry
similar sense.

My suggestion is a base DMM protocol as an integrated solution has to
be developed first and not developed in so many pieces.

And then bring those three work items (or similar) up  as a rechartering issue.

Regards,

Behcet

On Wed, Oct 8, 2014 at 9:23 AM, Alexandru Petrescu
<[email-masked]> wrote:
> Where the Charter mentions "Mobile IPv6 protocol family (RFC x, y, z)" it
> should also mention RFC 3963 and RFC 5177.
>
> Where the Charter says "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. Possible new documents
> and milestones must still fit into the overall DMM charter scope as outlined
> above. Milestones:[empty]"
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 9 Oct 2014 11:04:13 -0500

One more comment before the deadline expires:

The first work item in the proposed charter talks about deployment
models. We have checked all IETF documents on deployment and found out
that deployment always refers to an existing protocol. In this case,
DMM protocol does not exist.

I think there is easy fix to all the issues raised:

add one work item as the first work item on the development of
base Distributed Mobility Management Protocol.

If we have that then you can talk about deployment models, various
extensions as additional work items.

Regards,

Behcet