[DMM] Long message <was, Re: Using traffic Descriptors to characterize flows in a Mobility Context>

[Charlie Perkins]

Hello again Lyle and all,

Here's what it starts to look like.  From discussion earlier today, all 
of this data structure effectively resides in the DPN, and pertains to a 
single mobile node that is current utilizing some of the resources of 
the DPN.  The DPN uses it to manage data-plane traffic to/from the 
Mobile Node.



  |
  +-[Mobility-Context]  
  |+-[Interface-Group-Key] (O)
  |+-[Flow] (O)
  ||   +-[Interface-Key]  (O)
  ||   |   +-[Direction] (O)
  ||   +-[Descriptor-Match-Type] (M)
  ||   +-[Descriptor-Key] 
  ||   |   +-[Descriptor-Value]
  |+-[Assigned-Policy-DPN-Key] 
  ||  +-[Complementary-DPN-Settings]
  ||  +-[Interface-Id-Reference]
  ||  +-[Embedded-Rule]  (O)
  ||  +-[Assigned-Policy-Key]  (O)
  |+-[Requested-Policy-Key]  (O)
  |+-[Complementary-Context-Settings]  (O)


I have been puzzling over the Policy entries for a good while and I 
still am mostly in the dark.


Here's my guess, based on the previously existing descriptions for the 
terms.


Somehow the DPN wants to know *which* policies are *available* for 
managing traffic for a flow.  From among those policies, the DPN wants 
to know which policies have actually been *requested* for a flow.


The available policies are called "Assigned", perhaps because they have 
been assigned by the FPC Client as part of the Mobility Context (which 
up until previous versions was per-flow, not per-mobile_node).  Or maybe 
the "assignment" was performed by the FPC Agent in charge of the DPN.


For each "available" Policy, the actual policy is specialized from the 
Policy definition (which is in the Indexed Set of policies) by including 
some additional settings.  In this part of the document, these settings 
are called "Complementary", because they "complement" the Type of the 
Policy.  But in other places we have used "Values" to connote the 
operation of supplying specific values for what might be thought of as 
"wild-card" variable slots in the Policy definition.  By the way, these 
wild-card slots could either be in the Descriptor or in the Action, as I 
currently understand it.


But, stepping back a little bit...  why do we need the Policies? We can 
have them, but we already have the Flow characterizations by using 
Descriptors in a natural way.


Regarding Embedded-Rule...

Since we have Rules in an indexed set, why can't the Embedded-Rule 
reference the indexed Rule?  I don't think that having a Rule in an 
Indexed Set prevents the rule from being "embedded" in a Mobility 
Context.  It would be very natural for the DPN Agent (... errr, "FPC 
Agent") to initiate processing for a new Flow by copying over the 
definition from the Indexed Set of Rules (i.e., the Rule-Set).  Or maybe 
this was really the intention behind configuring the Assigned-Policy-DPN 
when the Mobility-Context was first created (during registration).  Even 
so, it would make definitional sense to keep the *definitions* of the 
Rules in the indexed Rule-Set, while still allowing them to be copied 
over and embedded whenever necessary for efficiency.


Thanks in advance for your consideration of my many questions.

Regards,
Charlie P.



On 1/22/2018 8:08 PM, Charlie Perkins wrote:

Hello Lyle and all,

I had an idea about characterizing the flows in a Mobility Context.

Namely, it seems that they can be characterized using the same kind of 
Descriptors that are already used in the Rules.  A Rule matches 
traffic against a Descriptor expression and if the traffic satisfies 
the Descriptor, some action is taken.


That's just about what we want to say about a flow -- namely, that it 
matches some Descriptor expression.


I am proposing to modify the Mobility Context to have some 
mobile-node-specific information and a List of Descriptors, just as we 
already reference under the Policy structure.  Since the Descriptors 
are located in an Indexed Set, the Mobility Context only has to supply 
the Descriptor-Key along with Descriptor-Values as before.


I am hoping this will provide a boost towards improving the 
naturalness of the Information Model for Mobility Context.


Comments?

Regards,
Charlie P.



On 1/22/2018 1:28 PM, Bertz, Lyle T [CTO] wrote:

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] 
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 

[DMM] Using traffic Descriptors to characterize flows in a Mobility Context

[Charlie Perkins]

Hello Lyle and all,

I had an idea about characterizing the flows in a Mobility Context.

Namely, it seems that they can be characterized using the same kind of 
Descriptors that are already used in the Rules.  A Rule matches traffic 
against a Descriptor expression and if the traffic satisfies the 
Descriptor, some action is taken.


That's just about what we want to say about a flow -- namely, that it 
matches some Descriptor expression.


I am proposing to modify the Mobility Context to have some 
mobile-node-specific information and a List of Descriptors, just as we 
already reference under the Policy structure.  Since the Descriptors are 
located in an Indexed Set, the Mobility Context only has to supply the 
Descriptor-Key along with Descriptor-Values as before.


I am hoping this will provide a boost towards improving the naturalness 
of the Information Model for Mobility Context.


Comments?

Regards,
Charlie P.



On 1/22/2018 1:28 PM, Bertz, Lyle T [CTO] wrote:

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] 
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 

Re: [DMM] Question about Interface Groups (formerly, DPN Groups)

[Charlie Perkins]

Hello Lyle,

Thanks for the detailed reply.  It clears up a lot of questions in my 
mind.  To briefly reply:


- The reason I was asking about whether or not an Interface Group lived 
on a DPN was to help me figure out how to structure the Interface Group 
definition.  It's already structured as an Indexed Set, and so we will 
have an Interface-Group-Key.  The DPN structure will have a list of such 
keys, for each Interface Group that exists and includes an Interface 
from the DPN.  I think this is O.K. for your scenario of different 
security zones.  Notably, we do not provide that as an attribute of an 
Interface, but then again I don't think we could reasonably be expected 
to delineate all possible attributes of Interfaces.


An Interface Group will also have a DPN-Key, for the DPN that hosts its 
interfaces.


Your example about having to select a DPN to handle emergency calls as 
well as "normal" call processing is very interesting.  What if we make 
that to be two different access-network features, and enable selection 
of Interface Groups for each feature?  Then we are still O.K. with 
having each Interface Group to be configured with only one DPN-Key.


Regards,
Charlie P.

On 1/22/2018 1:49 PM, Bertz, Lyle T [CTO] wrote:


Your scenarios are correct.  I think we are in agreement but I want to 
clarify a few things:


Wrt your statement “(b) it makes good sense for all the Interfaces of 
an Interface Group to be hosted on the same DPN.”


Ack.  I agree when the required interfaces within an Interface Group 
can be hosted on the same DPN to service a request.  However, we leave 
DPN selection up to the implementations as they may have proprietary 
or other perfectly good reasons not to do this.  By the above 
statement I have interpreted it as a recommendation and not a mandate, 
i.e. it is not a requirement in FPC to do this.   Is that correct?


Wrt the statement “I just want all of the Interfaces of an Interface 
Group to be on the same DPN”


I wish that was always the case but when the interface types are 
different or have a different purpose, e.g. normal calls vs. emergency 
calls, this is not the case in practice.


In the model then are you proposing the Interface Groups only reside 
under the DPN structure? If so, then one must load all DPNs and index 
them by Interface Groups Id to determine they are from the same 
group.  The purpose in pulling them out was to create a single Set 
that could be used to house the typing and common configuration 
information. DPN interfaces assigned to support an Interface Group are 
then assigned to it.  Thus, if a DPN had 2 interfaces which are of the 
same type but in different security zones (or have different 
routes/networks served) they may not be able to serve in the same group.


Lyle

*From:*Charlie Perkins [mailto:charles.perk...@earthlink.net]
*Sent:* Monday, January 22, 2018 3:25 PM
*To:* Bertz, Lyle T [CTO] 
*Cc:* dmm@ietf.org
*Subject:* Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

I agree that:

 1. - Interface Groups are designed to be used to select DPN.
 2. - Interface Groups may contain a number of different Interface Types
 3. - There may be more than one Interface Group providing equivalent
service, at least for the purpose of selecting a DPN.

For (1) -- I imagine that the selection process would look to make 
sure that the Interface Group has the proper interfaces that are 
needed (say, by the FPC Client).  Then, the FPC Client would select 
the DPN hosting the Interface Group, set up connectivity with the 
interfaces in the Peer Interface Group(s), and all is good.


For (2) -- this is really the motivation for the concept of Interface 
Groups.


For (3) -- really a follow-on from (1): the FPC Client would then look 
at the other properties of the DPN hosting the Interface Group, to 
determine which was the least cost, or highest benefit, choice.  Or 
alternatively the FPC Client would look at the Settings on the 
Interfaces of the Group, to see which Interfaces had the best fit for 
the purposes of the FPC Client.


If I have these scenarios right, then (a) we don't need to introduce 
any further virtual DPN definitions for proper operation and (b) it 
makes good sense for all the Interfaces of an Interface Group to be 
hosted on the same DPN.




The intent of the structure is for use during DPN selection. To
maintain it as a DPN means some DPNs are used during selection but
others are not.


I agree with this completely, if I understand it.  After the selection 
occurs based on the suitability of the Interface Group, its function 
is done.  I did not in any way mean to suggest that the Interface 
Group was ever going to be a DPN or a virtual DPN.


I just want all of the Interfaces of an Interface Group to be on the 
same DPN.


Regards,
Charlie P.


On 1/22/2018 11:36 AM, Bertz, Lyle T [CTO] wrote:

k. I think that we are crossing conversations now.

Re: [DMM] Question about Interface Groups (formerly, DPN Groups)

[Bertz, Lyle T [CTO]]

Your scenarios are correct.  I think we are in agreement but I want to clarify 
a few things:

Wrt your statement “(b) it makes good sense for all the Interfaces of an 
Interface Group to be hosted on the same DPN.”

Ack.  I agree when the required interfaces within an Interface Group can be 
hosted on the same DPN to service a request.  However, we leave DPN selection 
up to the implementations as they may have proprietary or other perfectly good 
reasons not to do this.  By the above statement I have interpreted it as a 
recommendation and not a mandate, i.e. it is not a requirement in FPC to do 
this.   Is that correct?

Wrt the statement “I just want all of the Interfaces of an Interface Group to 
be on the same DPN”

I wish that was always the case but when the interface types are different or 
have a different purpose, e.g. normal calls vs. emergency calls, this is not 
the case in practice.

In the model then are you proposing the Interface Groups only reside under the 
DPN structure? If so, then one must load all DPNs and index them by Interface 
Groups Id to determine they are from the same group.  The purpose in pulling 
them out was to create a single Set that could be used to house the typing and 
common configuration information.   DPN interfaces assigned to support an 
Interface Group are then assigned to it.  Thus, if a DPN had 2 interfaces which 
are of the same type but in different security zones (or have different 
routes/networks served) they may not be able to serve in the same group.

Lyle



From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 3:25 PM
To: Bertz, Lyle T [CTO] 
Cc: dmm@ietf.org
Subject: Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

I agree that:

  1.  - Interface Groups are designed to be used to select DPN.
  2.  - Interface Groups may contain a number of different Interface Types
  3.  - There may be more than one Interface Group providing equivalent 
service, at least for the purpose of selecting a DPN.
For (1) -- I imagine that the selection process would look to make sure that 
the Interface Group has the proper interfaces that are needed (say, by the FPC 
Client).  Then, the FPC Client would select the DPN hosting the Interface 
Group, set up connectivity with the interfaces in the Peer Interface Group(s), 
and all is good.

For (2) -- this is really the motivation for the concept of Interface Groups.

For (3) -- really a follow-on from (1): the FPC Client would then look at the 
other properties of the DPN hosting the Interface Group, to determine which was 
the least cost, or highest benefit, choice.  Or alternatively the FPC Client 
would look at the Settings on the Interfaces of the Group, to see which 
Interfaces had the best fit for the purposes of the FPC Client.

If I have these scenarios right, then (a) we don't need to introduce any 
further virtual DPN definitions for proper operation and (b) it makes good 
sense for all the Interfaces of an Interface Group to be hosted on the same DPN.



The intent of the structure is for use during DPN selection.   To maintain it 
as a DPN means some DPNs are used during selection but others are not.

I agree with this completely, if I understand it.  After the selection occurs 
based on the suitability of the Interface Group, its function is done.  I did 
not in any way mean to suggest that the Interface Group was ever going to be a 
DPN or a virtual DPN.

I just want all of the Interfaces of an Interface Group to be on the same DPN.

Regards,
Charlie P.


On 1/22/2018 11:36 AM, Bertz, Lyle T [CTO] wrote:
k. I think that we are crossing conversations now.

“An Interface Group on a DPN would also have have attributes for Peer Interface 
Groups residing on other DPNs. ” < Did not see that.

Interface Groups (aka DPN Groups) can be used for DPN pool selection (multiple 
options) with a different interface strategy.
Interface Groups (aka DPN Groups) may also contain hetergeneous DPN-Type 
(interface types).  In this case the totality of services could be provided by 
more than one DPN.

If we say that this is ‘just a virtual DPN with a selection strategy of 
multiple underlying DPNs” I feel that we are jamming too many concepts into the 
DPN.  Overloading is okay until one is overloaded ;)

The intent of the structure is for use during DPN selection.   To maintain it 
as a DPN means some DPNs are used during selection but others are not.

I would propose that we keep this concept separate for now, look at proposed 
changes and then revisit this issue.


From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 12:07 PM
To: Bertz, Lyle T [CTO] 

Cc: dmm@ietf.org
Subject: Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

An Interface Group on a DPN would also have have attributes for Peer 

Re: [DMM] Parent versus child mobility context

[Bertz, Lyle T [CTO]]

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] 
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 

Re: [DMM] Parent versus child mobility context

[Bertz, Lyle T [CTO]]

Comments inline.

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net] 
Sent: Monday, January 22, 2018 11:54 AM
To: Bertz, Lyle T [CTO] ; Marco Liebsch 

Cc: dmm@ietf.org
Subject: Re: Parent versus child mobility context

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

- Your description seems to imply that there are separate mobility contexts for 
each mobility session (i.e., for each bearer, or flow) that terminates (or 
originates) on the mobile node.

>> Yes.

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).   We also have the 5G 
>> concepts as well.  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. 

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 ; Bertz, Lyle T 
> [CTO] 
> Cc: Satoru Matsushima ; Sri Gundavelli 
> (sgundave) ; Moses, Danny ; 
> Weaver, Farni [CTO] ; Matsushima Satoru 
> 
> 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-
> 

Re: [DMM] Question about Interface Groups (formerly, DPN Groups)

[Charlie Perkins]

Hello Lyle,

An Interface Group on a DPN would also have have attributes for Peer 
Interface Groups residing on other DPNs.  So, the data plane 
configuration can already exhibit the ("cross-DPN") interconnection 
between Interface Groups even if the interfaces of the Group all reside 
on the same DPN.


Could you give an example of an Interface Group that perforce requires 
to reside on multiple DPNs?  Is it a case that could be handled better 
by defining a virtual DPN to host the Interface Group?  I understand the 
word "containment" but I'm not at all clear about what sort of Group 
requires the extra complication to expedite the stated purpose, which is 
DPN selection.  If there are other purposes, I would be inclined to 
define other structures for them that do not have the effect of 
complicating the Interface Group definition.


Regards,
Charlie P.


On 1/22/2018 5:11 AM, Bertz, Lyle T [CTO] wrote:




No, I don’t think they should reside under a DPN.   Groups like these 
also span multiple DPNs which would make containment graphs far too 
confusing.


*From:*Charlie Perkins [mailto:charles.perk...@earthlink.net]
*Sent:* Sunday, January 21, 2018 10:51 PM
*To:* Bertz, Lyle T [CTO] 
*Cc:* Marco Liebsch ; Satoru Matsushima 
; Sri Gundavelli (sgundave) 
; Moses, Danny ; Weaver, 
Farni [CTO] ; Matsushima Satoru 


*Subject:* Question about Interface Groups

Hello folks,

Can we have it so that all the Interfaces of an "Interface Group" 
(formerly, "DPN Group") reside on the same DPN?


If so, I can make good sense out of the text in the document, but 
otherwise I think there are big problems.


I have some other questions, but this is the main thing right now.  If 
the answer to my question is "Yes" I think I will have a sensible 
revision tomorrow.


I have some more questions, not quite as important, which I will put 
in separate emails.


Regards,
Charlie P.

On 1/18/2018 5:26 AM, Bertz, Lyle T [CTO] wrote:

Charlie,

Glad to hear things are going well.  I’m looking forward to your
document update.

Lyle




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://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Parent versus child mobility context

[Charlie Perkins]

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.

- Your description seems to imply that there are separate mobility 
contexts for each mobility session (i.e., for each bearer, or flow) that 
terminates (or originates) on the mobile node.


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".


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.


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 ; Bertz, Lyle T [CTO] 

Cc: Satoru Matsushima ; Sri Gundavelli (sgundave) 
; Moses, Danny ; Weaver, Farni [CTO] 
; Matsushima Satoru 
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://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Parent versus child mobility context

[Bertz, Lyle T [CTO]]

++ 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 ; Bertz, Lyle T [CTO] 

Cc: Satoru Matsushima ; Sri Gundavelli (sgundave) 
; Moses, Danny ; Weaver, Farni [CTO] 
; Matsushima Satoru 

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://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Indexed sets

[Bertz, Lyle T [CTO]]

I agree with the text below.  The text is great but your Example 4 is a bit 
confusing to me.  Hopefully you can help me out with that later or having it in 
the entire revision will probably clear that up for me (it is often hard to see 
clarity in the snippets).

I would change "the YANG models" to "the FPC YANG models" as we do not want to 
speak for all YANG models.


-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Sunday, January 21, 2018 11:11 PM
To: Bertz, Lyle T [CTO] 
Cc: Marco Liebsch ; Satoru Matsushima 
; Sri Gundavelli (sgundave) ; 
Moses, Danny ; Weaver, Farni [CTO] 
; Matsushima Satoru 

Subject: Indexed sets

Hello folks,

Here is some relevant text I developed to explain this concept.  It was mostly 
present in the previous document I sent out last week. Below, I have some 
follow-up questions regarding the concept.

>To encourage re-use, the YANG models define indexed sets of various
>types of entities.  To access such an model entity, other model
>elements contain an attribute which is typically denoted as
> "entity-
>Id".  When such an attribute is encountered, the referencing model
>element will indicate how to supply any needed values so that the
>entity model will be fully defined when used in any instance of the
>referencing model element.  For example: Figure 4 shows 2 entities:
>
>   EntityA definition references entityB model elements.
>
>   EntityB model elements are in a set indexed by entity-Id.
>
>Each EntityB model element has an Id which allows it to be uniquely
>identified, and a Type which specifies its form, allowing for
>creation of an instance by inserting entityB-Values as indicated.
>  .
>  .
>  |
>  +-[entityA]
>  |  +-[entityB-Id]
>  |  +-[entityB-Values]
>  .
>  .
>  |
>  +-[entityB] 
>  |  +-[entityB-Id]  (M)
>  |  +-[entityB-Type]
>  .
>  .
>
> Figure 4: Indexed sets of entities
>
>Indexed sets are specified for the following kinds of entities:
>
>   Domains
>   DPNs
>   Policies
>   Descriptors
>   Actions
>   Interface Groups

==

According to this, for example with "DPN", we would have a DPN-Id that allows 
one to locate the DPN (i.e., find what had been previously called a 
DPN-reference).  With that in mind, I put in the following lines in the DPN 
structure:

> |
> +-[DPN] 
> | +-[DPN-Id] ,  (O)

But this isn't really correct.  As I read it, the structure would mean that 
there is a thing called a "DPN-Id Key", and another thing called a "DPN-ID 
Name".  What we really want is a DPN-Key and a DPN-Name.

That could be specified more simply as follows:

> |
> +-[DPN] ,  (O) 
>

If we could use this to mean that there are attributes denoted "DPN-Key"
and "DPN-Name", then we have a natural and understandable structure. These 
attributes would apply to the *elements* of the DPN Set, not the DPN-Set 
itself.  In this case, I would rewrite the relevant parts of the document to 
replace instances of "DPN-Id" to instead use "DPN-Key".  And similarly for 
other indexed sets.

I hope you will agree, so that we can get to unambiguous language for 
describing this important concept without the currently existing redundancy.

Somewhat less important, but still of interest:

In the example above, there seems to be an implicitly described entity called a 
"DPN-Set" which is a set of DPNs.  In the text, when we need to refer to the 
set of DPNs, I propose that we use exactly the naming convention that it is 
called "DPN-Set".  That would be slightly but significantly different than "a 
set of DPNs", and if you approve, the nomenclaure "DPN Set" (i.e., lacking the 
'-') should probably not be used.

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://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Question about Interface Groups

[Bertz, Lyle T [CTO]]

No, I don’t think they should reside under a DPN.   Groups like these also span 
multiple DPNs which would make containment graphs far too confusing.


From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Sunday, January 21, 2018 10:51 PM
To: Bertz, Lyle T [CTO] 
Cc: Marco Liebsch ; Satoru Matsushima 
; Sri Gundavelli (sgundave) ; 
Moses, Danny ; Weaver, Farni [CTO] 
; Matsushima Satoru 

Subject: Question about Interface Groups

Hello folks,

Can we have it so that all the Interfaces of an "Interface Group" (formerly, 
"DPN Group") reside on the same DPN?

If so, I can make good sense out of the text in the document, but otherwise I 
think there are big problems.

I have some other questions, but this is the main thing right now.  If the 
answer to my question is "Yes" I think I will have a sensible revision tomorrow.

I have some more questions, not quite as important, which I will put in 
separate emails.

Regards,
Charlie P.
On 1/18/2018 5:26 AM, Bertz, Lyle T [CTO] wrote:
Charlie,

Glad to hear things are going well.  I’m looking forward to your document 
update.

Lyle





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://www.ietf.org/mailman/listinfo/dmm