Re: WG Review: Distributed Mobility Management (dmm)
Jouni Korhonen <[email protected]>
| Newsgroups | gmane.ietf.nemo,gmane.ietf.general |
|---|---|
| Message-ID | <[email protected]> |
Hi,
Thank you for the review. See my initial comments inline.
10/7/2014 8:50 AM, Abdussalam Baryun kirjoitti:
> 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. "
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
>
> 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:
>
> 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 <http://ietf.org>) by
> 2014-10-13.
>
> Distributed Mobility Management (dmm)
> ------------------------------------------------
> Current Status: Active WG
>
> Chairs:
> Dapeng Liu <[email protected] <javascript:;>>
> Jouni Korhonen <[email protected] <javascript:;>>
>
> Assigned Area Director:
> Brian Haberman <[email protected] <javascript:;>>
>
> Mailing list
> Address: [email protected] <javascript:;>
> 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:
>
>