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

Jouni <jouni.nospam@gmail.com> Mon, 01 September 2014 08:25 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 D19801A01D0 for <dmm@ietfa.amsl.com>; Mon, 1 Sep 2014 01:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 3HlX3keeeLmJ for <dmm@ietfa.amsl.com>; Mon, 1 Sep 2014 01:25:13 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF5E1A01CA for <dmm@ietf.org>; Mon, 1 Sep 2014 01:25:12 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id 10so5593049lbg.3 for <dmm@ietf.org>; Mon, 01 Sep 2014 01:25:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fWkIYy60xf+4EA3FL4aVafP1eMlBcLwUreV3wOeZWuE=; b=xfNI9PyGOxLyu4h8/zt09vbNRwoH/dkj3V9wZ9XtOZT2vxklVrYXrGIudFmuYVD56N OrULaDLHjXiASrm3jV4HIdde8axbU2gDLPXohsnYAlWX7qtODqEO9gEiGmcBEGxNfUHb BSNH2xUOxNMrrGQzyPQWq5oOH3N6N4osVmM/LbOrq1c5cj3PaWG5MzJywolQneEaVTGY c6Bmlhu/Li0Su9oiMq90ltSVlJNHnFaV9kPsH0TYodyLioLTVzAnQFVwdXvqlnStJDAP wyKRaV4sL4MdUD4y/MJ4x7/cFaHKcVZ9qGXrQXWkX8KyFNFFwAMh7IAOlFO4ZfzdtqLG VxXg==
X-Received: by 10.152.43.81 with SMTP id u17mr15280660lal.50.1409559910635; Mon, 01 Sep 2014 01:25:10 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:2423:d50f:b7a:bc0c? ([2001:1bc8:101:f101:2423:d50f:b7a:bc0c]) by mx.google.com with ESMTPSA id j10sm194030lbb.34.2014.09.01.01.25.09 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Sep 2014 01:25:09 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Jouni <jouni.nospam@gmail.com>
In-Reply-To: <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org>
Date: Mon, 01 Sep 2014 11:25:07 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com>
References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <A02C6954-3EC9-443F-ACC3-4A635EC79EFC@yegin.org> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/kOoEOZPISVGQYLPf9S2krXjDnqs
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: Mon, 01 Sep 2014 08:25:16 -0000

Alper,

I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 and stage-3 work. The ""deployment models and scenarios" are the stage-2 descriptions and then we also need the protocol level solutions that are in separate documents.

Makes sense?

- Jouni


On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote:

>> 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.
>> 
> 
> Jouni,
> 
> The "architecture changes" would be based on the a "specific solution". So, as part of describing a solution one can be talking about what you are suggesting above. But I don't understand how we can be talking about "deployment models and scenarios" before we agree on the solutions.
> 
> Alper
> 
> 
> 
> 
>>>>>>    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).
>> 
>> Ok. I'll try to clarify the point the text tries to make.
>> 
>> - Jouni
>> 
>>> 
>>> 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 <mailto:dmm@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>> 
>>> 
>