Re: [DMM] WG Review: Distributed Mobility Management (dmm)
Jouni Korhonen <jouni.nospam@gmail.com> Tue, 07 October 2014 09:13 UTC
Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEABE1A9233; Tue, 7 Oct 2014 02:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.486
X-Spam-Level:
X-Spam-Status: No, score=-0.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVeuvAzIw2aH; Tue, 7 Oct 2014 02:13:34 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB241A9176; Tue, 7 Oct 2014 02:13:33 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id w7so5699151lbi.22 for <multiple recipients>; Tue, 07 Oct 2014 02:13:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=A6QcA4glPy83J6B/U7kz0FhI7NmpFf22bvox0RPltnc=; b=VALJG+rrxC25aLi+Gm1EmLvS/UibVl5gQH5gCGn/7kJovaxzWrXJkU9iC4deCo8v+i cfoXw1rx6MU/AkwVJa3GwnGTHeqH9qr61cnChiPG3yQ2p2syNfWfER6If7cwL3lmjkej k1Y7R/yYV0FcCI2Sazi7adc5UX1Knc/iVjpZnrzQ28qi0zxEWm6/6+XZCUZtzFJHGdZU wWFP/tH8o//WK31HRXFJjYvyyH8ZJ1NzRs6yN3QPYVpAPBQbzxTYsSIvhy0zEhwixAJT TNUwQZXlsaLPwutYmVJuRsWfdPQkBUxUXMKCF5mH9vTJmYBN5O00VL1qqt7QMkTz5A5u 4Kbg==
X-Received: by 10.152.29.100 with SMTP id j4mr2620272lah.47.1412673212045; Tue, 07 Oct 2014 02:13:32 -0700 (PDT)
Received: from [10.17.0.20] ([83.150.126.201]) by mx.google.com with ESMTPSA id us3sm6514769lbc.24.2014.10.07.02.13.30 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 02:13:31 -0700 (PDT)
Message-ID: <5433AEC0.6000104@gmail.com>
Date: Tue, 07 Oct 2014 12:13:36 +0300
From: Jouni Korhonen <jouni.nospam@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Abdussalam Baryun <abdussalambaryun@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>
References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> <CADnDZ88K0XQ11bp9hVdSrDn58-1=NOtAYRr_Z6_pP==nbr=7rw@mail.gmail.com>
In-Reply-To: <CADnDZ88K0XQ11bp9hVdSrDn58-1=NOtAYRr_Z6_pP==nbr=7rw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Kt3vhJaNnJHANLFTTNBqyJ3xeRc
Cc: "iesg@ietf.org" <iesg@ietf.org>, dmm WG <dmm@ietf.org>
Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2014 09:13:37 -0000
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 <liudapeng@chinamobile.com <javascript:;>> > Jouni Korhonen <jouni.nospam@gmail.com <javascript:;>> > > Assigned Area Director: > Brian Haberman <brian@innovationslab.net <javascript:;>> > > Mailing list > Address: dmm@ietf.org <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: > >
- [DMM] WG Review: Distributed Mobility Management … The IESG
- Re: [DMM] WG Review: Distributed Mobility Managem… Abdussalam Baryun
- Re: [DMM] WG Review: Distributed Mobility Managem… Jouni Korhonen
- Re: [DMM] WG Review: Distributed Mobility Managem… Behcet Sarikaya
- Re: [DMM] WG Review: Distributed Mobility Managem… Alexandru Petrescu
- Re: [DMM] WG Review: Distributed Mobility Managem… Jouni
- Re: [DMM] WG Review: Distributed Mobility Managem… Alexandru Petrescu
- Re: [DMM] WG Review: Distributed Mobility Managem… Templin, Fred L
- Re: [DMM] WG Review: Distributed Mobility Managem… Jouni Korhonen
- Re: [DMM] WG Review: Distributed Mobility Managem… Behcet Sarikaya
- Re: [DMM] WG Review: Distributed Mobility Managem… Behcet Sarikaya