On Mon, Sep 1, 2014 at 3:25 AM, Jouni <[email protected]> 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/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 >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>> >>>> >> > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
