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

["Sri Gundavelli (sgundave)" <[e-mail]>]

I don't follow this objection either. This discussion just derails
established consensus after months of discussions.

We design protocols to enable deployment/solutions/architectures. Those
solutions/architectures are not unique to a specific SDO or unique to a
specific access. Its a broader framework.

The agreements here are based on IETF WG consensus and not strictly based
on one specific SDO's requirement.

This type of out of context references to historical material does not
help these discussions.


Sri





On 9/2/14 10:07 PM, "Jouni Korhonen" <[e-mail]> wrote:

>We were on this in yesterday's interim call. We have a proposal text
>now. You were also on the call but I did not record you commenting
>anything during the discussion we had on this particular topic. Are you
>now saying the resolution we have now in the charter text is not adequate?
>
>- JOuni
>
>9/2/2014 11:39 PM, Behcet Sarikaya kirjoitti:
>> On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen <[e-mail]>
>>wrote:
>>> Behcet,
>>>
>>> Obviously that protocols are known that the intended deployment is
>>>going to
>>> use. The details what goes inside that protocol are not. This holds
>>>for my
>>> example case 3GPP as well.
>>>
>>> We do not need to into same level of detail that e.g. 3GPP stage-2 has
>>> detailing all signaling flows and so on. I believe we as a WG are
>>>competent
>>> enough to make a fine division what level of detail is left for the
>>> "deployment models and scenarios" and what goes into protocol
>>>solutions.
>>>
>>
>> I hope you read previous mails on this issue.
>>
>> I think it clear that 3GPP agrees with IETF on the interpretation of
>> deployment. How can we close our eyes on this and try to put the horse
>> before the cart?
>>
>> Why not simply remove it?
>>
>> Regards,
>> Behcet
>>
>>
>>
>>> - Jouni
>>>
>>> 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti:
>>>
>>>> On Mon, Sep 1, 2014 at 3:25 AM, Jouni <[e-mail]> wrote:
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Thanks Alper for raising this issue.
>>>>
>>>> 3GPP Stage 2 like in SA2 documents are architecture documents.
>>>> I don't understand what is going on here.
>>>>
>>>> I am looking at 23.402 on Architecture Enhancements for non-3GPP
>>>>accesses.
>>>>
>>>> Yes, this document talks about deployment in just a few places, here
>>>> is one occurrence: on page 64, PCC deployment options
>>>> on page 94, PMIP based S5/S8 deployments, etc.
>>>>
>>>> So in all cases the protocol, i.e. PCC or PMIP is known.
>>>>
>>>> Regards,
>>>>
>>>> Behcet
>>>>>
>>>>> 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/rechart
>>>>>>>>>>>>>er_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
>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dmm mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>
>_______________________________________________
>dmm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dmm