More inline. -----Original Message----- From: Charlie Perkins [mailto:charles.perk...@earthlink.net] Sent: Monday, January 22, 2018 2:27 PM To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com> Cc: dmm@ietf.org Subject: Re: [DMM] Parent versus child mobility context
Hello Lyle, More follow-up inline. We're getting closer. On 1/22/2018 11:27 AM, Bertz, Lyle T [CTO] wrote: > > Hello Lyle and all, > > I think I agree with most of what you say below. I'm concerned with how to > organize the information in the model. So, for that purpose, please verify > whether my following understandings are correct. > > - The mobility context resides on a DPN. > > - The mobility context provides necessary information (e.g., QoS) for a > single mobile node. > > - The DPN uses it to manage data-plane traffic for that mobile node. > >>> This may be too broad of a view. What about a mobile node with >>> multiple mobility sessions? In such a case it may be managing one or >>> more (but not necessarily all of) the mobile node's mobility >>> sessions Yes. This is why I did not put "all" between "manage" and "data-plane". LB > Ok. We should probably be more explicit though for the casual observer if this language is used in the specification. > > In my earlier email on this subject, I was using Mobility Context as > describing something more associated with a mobile node, than with a > particular flow. If you want it to mean "bearer", then we ought to call it a > Bearer. > > Maybe it would be easier to understand if we had something called a > "Mobile-Node Context", and in that context we had a set of Bearer Contexts > (or, just Bearers). Each bearer would inherit from the Mobile Node context > simply by being part of it. The Mobile Node context (serving as "parent") > would determine max bandwidth, IP address, etc. Back in the old days, we also > defined security aspects and some other factors, as part of what FPC would > call the "mobility context". > >>> We have several concepts that have hierarchy, e.g. Service Level (sr-id or >>> APN - apn-oi if I recall), device level, Mobility Session, bearers, flow >>> based filters (effectively living within a bearer). There isn't anything about Service Level in the first part of the document, and I did not find anything about Service-ID that referenced mobility context. Mobility Context does not define Service Level. Similarly for APN. The string "-oi" does not occur in the document. Device level is a mystery to me. Now, this isn't to say that your comment is irrelevant. But, at minimum, the relevance is not spelled out in the current document. LB> Ack. They are not mentioned these in the documents; I was merely providing examples. >>> We also have the 5G concepts as well. We have, in fact, an infinitude of mutually contradictory 5G concepts. I might suggest that they look at Mobile IP, which was designed exactly to provide high-speed, low-latency, application-independent mobility management. But, I digress. LB> I am in agreement here but I believe that as Release 15 is finalized in 3GPP we will see clarity. My question would be if other next generation standards / technologies follow so that we have a tractable problem space but I too, digress. >>> The one thing that is obvious is that the idea of hierarchy applies >>> whether it is pacers/shapers, bearers or filters that apply some charging / >>> gating / marking. A light touch of lifecycle (fate sharing) amongst the >>> hierarchy, data does not need to be repeated within the hierarchy and >>> building the data structure by requiring a parent id if it was a child >>> (implying the parent must exist!) was the best we could do without >>> necessarily making decisions that may appear to preclude a specific set of >>> mobile network technologies. We certainly agree on the existence of hierarchy pervading our problem space. And on the need to consider fate-sharing for between mobile-node authorizations and allocated bearers. But my suggested approach of having the Bearers delineated under an inclusive Mobility Context provides for that in a natural way. Perhaps the word "bearer" shows too much bias towards 3GPP, in which case we could simply use "mobility session" or "flow". LB> Ack. I think I would object to the use of Bearer. Flow(s) may be too granular. Maybe a verbal delineation between a Flows-Context (implying 1 or more) and some other concept such as Session-Context (old terminology) or Mobility-Context. imo though it may be more beneficial to state it as a context type and imply some hierarchy? ============ end of my follow-up for this email =================== Regards, Charlie P. >>> > If you really want to maintain Parent Context and Child Context as > independent structure elements, then we need to make a new indexed set for > them. > > >>> We just used a pointer from a Context to a Parent Context. If the value was >>> non-empty it was a child and the parent Id must point to a valid Context. > Regards, > Charlie P. > > > On 1/22/2018 5:30 AM, Bertz, Lyle T [CTO] wrote: >> ++ mailing list >> >> I agree with you Marco. >> >> Keeping the parent/child relation is crucial. Although we often cite >> dedicated vs. default bearers (LTE) we need to also ack that we use >> hierarchical concepts throughout mobility and forwarding management >> protocols, e.g. meters, session and sub-session (includes accounting), etc. >> >> Lifecycle association here (fate sharing of the children with the parent) is >> an important concept. Many of the mobility systems assume gateways (LMAs >> and MAGs) have knowledge of the relationships between sessions and >> sub-session and will often kill the session in order to reduce signaling >> overhead. They also assume when installing a session / sub-session that any >> violation of hierarchy rules, e.g. setting a child's max bit rate above a >> parent's, would be properly enforced, i.e. it is an error or the child's >> value is ignored. >> >> For FPC we also use it to avoid sending redundant data (does one need >> to send the mobile's IP address for any sort of sub-session work if it >> is tied to a parent that already has it?) >> >> -----Original Message----- >> From: Marco Liebsch [mailto:marco.lieb...@neclab.eu] >> Sent: Monday, January 22, 2018 5:49 AM >> To: Charlie Perkins <charles.perk...@earthlink.net>; Bertz, Lyle T >> [CTO] <lyle.t.be...@sprint.com> >> Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; Sri Gundavelli >> (sgundave) <sgund...@cisco.com>; Moses, Danny <danny.mo...@intel.com>; >> Weaver, Farni [CTO] <farni.wea...@sprint.com>; Matsushima Satoru >> <satoru.matsush...@g.softbank.co.jp> >> Subject: RE: Parent versus child mobility context >> >> That has been introduced to reflect e.g. dedicated bearers which come on top >> of default bearers hence have some level of dependency. If context >> associated with a default bearer gets closed, dependent context will follow. >> To me it makes sense. Others? >> >> marco >> >> -----Original Message----- >> From: Charlie Perkins [mailto:charles.perk...@earthlink.net] >> Sent: Montag, 22. Januar 2018 06:29 >> To: Bertz, Lyle T [CTO] >> Cc: Marco Liebsch; Satoru Matsushima; Sri Gundavelli (sgundave); >> Moses, Danny; Weaver, Farni [CTO]; Matsushima Satoru >> Subject: Parent versus child mobility context >> >> >> Hello folks, >> >> I have looked at this several times, and I would like to propose simplifying >> it to simply be a mobility context. I don't see that the extra complication >> is worth it, especially right now. If, in the future, we need it for >> something, we could put it back in. >> >> Thanks for your consideration of this request. >> >> Regards, >> Charlie P. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the sole >> use of the recipient(s). Any use by others is prohibited. If you are not the >> intended recipient, please contact the sender and delete all copies of the >> message. > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7CLyle.T.Bertz%40sprint.com%7C44b677e7e34c4d5060f008d561d67569%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C636522496081025164&sdata=wz8DMRig03al9oWMNVJgcFMm1tiHWToTM6KwI%2FMAiiA%3D&reserved=0 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
