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

Alper Yegin <alper.yegin@yegin.org> Wed, 13 August 2014 12:36 UTC

Return-Path: <alper.yegin@yegin.org>
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 A0CC81A870D for <dmm@ietfa.amsl.com>; Wed, 13 Aug 2014 05:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
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 iTIkgR0w9geg for <dmm@ietfa.amsl.com>; Wed, 13 Aug 2014 05:36:04 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C821A8706 for <dmm@ietf.org>; Wed, 13 Aug 2014 05:36:04 -0700 (PDT)
Received: from [192.168.1.4] (88.244.81.189.dynamic.ttnet.com.tr [88.244.81.189]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0LmdF7-1WhefN0AYV-00aH5L; Wed, 13 Aug 2014 14:36:02 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_383CDF49-3635-419C-8CC3-6CD858E5EE66"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <53EB4F10.1040502@gmail.com>
Date: Wed, 13 Aug 2014 15:35:56 +0300
Message-Id: <A02C6954-3EC9-443F-ACC3-4A635EC79EFC@yegin.org>
References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:KfVLZsHms5VbBE0Udwt/R96GmEy5gWJgR8qi9e3055Q IDzd14vdUqzxbuHaav2EWOGK3R8IHqdHEpC5CDZM4nHB/nrN20 yHWL3MjUxTAXfyKKRIBZbm0+n9jT14U/ER1A/RYy0D3neDx0Ii WpKqXI3ku6cNJqsxPszuubZexCynrqLgJqHeaDIFwSH+11q2uA XmMekBrzGsahfSGiYSgmmV7pg1dAZZ6/KwIaLjEOYaetCjyW7/ o2AT4X1aINzO1UvuiS5aET/7pRmNnKlNMDyH9xWPfCpHgACOCs +TFHM+MQX1fKK9W7JW26lHO0V7ogL2FdxQuTrzLFlciP2whqje HJXQ+8adPzWA+qpAPnA1YrjI1rpU49Tlb6pIPigk9QUZdop2Vu geUC9zOWcNDkA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/3nNC8PSw4QJ-W2xlu6pXcYn6tnk
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] regarding the re-chartering..
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: Wed, 13 Aug 2014 12:36:07 -0000

Hi Jouni,


>>> 
>>> 
>>>      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?
> 
> See the reply to Brian:
> 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?




>>>      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 [*]).
> 
> 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




> Any other opinions on collapsing these two?
> 
> - Jouni
> 
>>>      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
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>>