Subject: Re: [DMM] Question about Interface Groups

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 22 Jan 2018 13:11:01 +0000

<adding mailing list>

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:[email-masked]]
Sent: Sunday, January 21, 2018 10:51 PM
To: Bertz, Lyle T [CTO] <[email-masked]>
Cc: Marco Liebsch <[email-masked]>; Satoru Matsushima <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>; Moses, Danny <[email-masked]>; Weaver, Farni [CTO] <[email-masked]>; Matsushima Satoru <[email-masked]>
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.

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 22 Jan 2018 13:19:26 +0000

<adding list>

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:[email-masked]]
Sent: Sunday, January 21, 2018 11:11 PM
To: Bertz, Lyle T [CTO] <[email-masked]>
Cc: Marco Liebsch <[email-masked]>; Satoru Matsushima <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>; Moses, Danny <[email-masked]>; Weaver, Farni [CTO] <[email-masked]>; Matsushima Satoru <[email-masked]>
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] <Set>
>                          |      +-[entityB-Id] <L-Key> (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] <Set>
>         |     +-[DPN-Id] <G-Key>, <Name> (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] <G-Key>, <Name> (O) <Set>
>

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.

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 22 Jan 2018 13:30:48 +0000

++ 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:[email-masked]]
Sent: Monday, January 22, 2018 5:49 AM
To: Charlie Perkins <[email-masked]>; Bertz, Lyle T [CTO] <[email-masked]>
Cc: Satoru Matsushima <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>; Moses, Danny <[email-masked]>; Weaver, Farni [CTO] <[email-masked]>; Matsushima Satoru <[email-masked]>
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:[email-masked]]
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.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 22 Jan 2018 09:53:41 -0800

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.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 22 Jan 2018 10:07:17 -0800

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:
>
> <adding mailing list>
>
> 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:[email-masked]]
> *Sent:* Sunday, January 21, 2018 10:51 PM
> *To:* Bertz, Lyle T [CTO] <[email-masked]>
> *Cc:* Marco Liebsch <[email-masked]>; Satoru Matsushima 
> <[email-masked]>; Sri Gundavelli (sgundave) 
> <[email-masked]>; Moses, Danny <[email-masked]>; Weaver, 
> Farni [CTO] <[email-masked]>; Matsushima Satoru 
> <[email-masked]>
> *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.
>
> ------------------------------------------------------------------------
>
> 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.

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 22 Jan 2018 19:27:02 +0000

Comments inline.

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]] 
Sent: Monday, January 22, 2018 11:54 AM
To: Bertz, Lyle T [CTO] <[email-masked]>; Marco Liebsch <[email-masked]>
Cc: [email-masked]
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 provides necessary information (e.g., QoS) for a single 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:
> 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?)
>
> Cc: Satoru Matsushima <[email-masked]>; Sri Gundavelli 
> (sgundave) <[email-masked]>; Moses, Danny <[email-masked]>; 
> Weaver, Farni [CTO] <[email-masked]>; Matsushima Satoru 
> Cc: Marco Liebsch; Satoru Matsushima; Sri Gundavelli (sgundave); 
> Moses, Danny; Weaver, Farni [CTO]; Matsushima Satoru

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 22 Jan 2018 19:36:06 +0000

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:[email-masked]]
Sent: Monday, January 22, 2018 12:07 PM
To: Bertz, Lyle T [CTO] <[email-masked]>
Cc: [email-masked]
Subject: Re: Question about Interface Groups (formerly, DPN Groups)

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.

From: Charlie Perkins [mailto:[email-masked]]
Sent: Sunday, January 21, 2018 10:51 PM
To: Bertz, Lyle T [CTO] <[email-masked]><mailto:[email-masked]>
Cc: Marco Liebsch <[email-masked]><mailto:[email-masked]>; Satoru Matsushima <[email-masked]><mailto:[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]><mailto:[email-masked]>; Moses, Danny <[email-masked]><mailto:[email-masked]>; Weaver, Farni [CTO] <[email-masked]><mailto:[email-masked]>; Matsushima Satoru <[email-masked]><mailto:[email-masked]>
Subject: Question about Interface Groups

Hello folks,

Regards,
Charlie P.

Lyle

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 22 Jan 2018 12:26:42 -0800

Hello Lyle,

More follow-up inline.  We're getting closer.

>>> 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 se…

Yes.  This is why I did not put "all" between "manage" and "data-plane".

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

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

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

============ end of my follow-up for this email ===================

Regards,
Charlie P.

> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 22 Jan 2018 13:25:00 -0800

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:
> “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.
>
> *Sent:* Monday, January 22, 2018 12:07 PM
> *Cc:* [email-masked]
> *Subject:* Re: Question about Interface Groups (formerly, DPN Groups)
>
> Hello Lyle,
>
> between Interface Groups even if the interfaces of the Group all 
> reside on the same DPN.
>
> 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.
>
>     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.
>
>     <mailto:[email-masked]>
>     *Cc:* Marco Liebsch <[email-masked]>
>     <mailto:[email-masked]>; Satoru Matsushima
>     <[email-masked]>
>     <mailto:[email-masked]>; Sri Gundavelli (sgundave)
>     <[email-masked]> <mailto:[email-masked]>; Moses, Danny
>     <[email-masked]> <mailto:[email-masked]>; Weaver,
>     Farni [CTO] <[email-masked]>
>     <mailto:[email-masked]>; Matsushima Satoru
>     <mailto:[email-masked]>
>     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.
>
>     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.
>

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 22 Jan 2018 21:28:34 +0000

More inline.

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]] 
Sent: Monday, January 22, 2018 2:27 PM
To: Bertz, Lyle T [CTO] <[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] Parent versus child mobility context

Hello Lyle,

On 1/22/2018 11:27 AM, Bertz, Lyle T [CTO] wrote:
>>> 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

LB > Ok.  We should probably be more explicit though for the casual observer if this language is used in the specification.

>>> 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 bear…

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.

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.    

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.

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?   

Regards,
Charlie P.

> 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

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 22 Jan 2018 21:49:15 +0000

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:[email-masked]]
Sent: Monday, January 22, 2018 3:25 PM
To: Bertz, Lyle T [CTO] <[email-masked]>
Cc: [email-masked]
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.

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.

Cc: [email-masked]<mailto:[email-masked]>

Hello Lyle,

Regards,
Charlie P.

Hello folks,

Regards,
Charlie P.

Lyle

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 22 Jan 2018 17:10:23 -0800

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:
> 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?
>
> 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
>
> *Sent:* Monday, January 22, 2018 3:25 PM
> 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.
>
> 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.
>
>
>
> 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.
>
>     “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.
>
>     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 ;)
>
>     I would propose that we keep this concept separate for now, look
>     at proposed changes and then revisit this issue.
>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     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.
>
>
>         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.
>
>         <mailto:[email-masked]>; Sri Gundavelli
>         (sgundave) <[email-masked]> <mailto:[email-masked]>;
>         Moses, Danny <[email-masked]>
>         <mailto:[email-masked]>; Weaver, Farni [CTO]
>         <[email-masked]> <mailto:[email-masked]>;
>         Matsushima Satoru <[email-masked]>
>         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.
>
>         now.  If the answer to my question is "Yes" I think I will
>         have a sensible revision tomorrow.
>
>         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.
>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 22 Jan 2018 20:08:47 -0800

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.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 22 Jan 2018 21:18:30 -0800

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] <G-Key> <Set>
>           |            +-[Interface-Group-Key] (O)
>           |            +-[Flow] (O)
>           |            |       +-[Interface-Key] <Set> (O)
>           |            |       |       +-[Direction] (O)
>           |            |       +-[Descriptor-Match-Type] (M)
>           |            |       +-[Descriptor-Key] <Set>
>           |            |       |       +-[Descriptor-Value]
>           |            +-[Assigned-Policy-DPN-Key] <Set>
>           |            |          +-[Complementary-DPN-Settings]
>           |            |          +-[Interface-Id-Reference]
>           |            |          +-[Embedded-Rule] <Set> (O)
>           |            |          +-[Assigned-Policy-Key] <Set> (O)
>           |            +-[Requested-Policy-Key] <Set> (O)
>           |            +-[Complementary-Context-Settings] <Set> (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:
> 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.
>
> 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.
>
>
>
>>> 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.
>>>
>> LB > Ok.  We should probably be more explicit though for the casual 
>> observer if this language is used in the specification.
>>
>>> particular flow. If you want it to mean "bearer", then we ought to 
>>> call it a 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).
>> 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.
>>
>> 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.
>> 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?
>>
>>> 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.
>>>
>>>
>>>> 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.
>>>>
>>>> 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
>>>>
>>>> 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.
>>>>
>>>> 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.

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Tue, 23 Jan 2018 13:25:05 +0000

​

wrt

"What if we make that to be two different access-network features, and enable selection of Interface Groups for each feature?"

> emergency calls when roaming are not treated the same when they are domestic.   this is especially true when it comes from an automobile.    In fact, they are often set aside as different APNs.   I'd like to be able to support the current DDDS implementations as well as TS 29.303.  Furthermore, such scenarios are indexed given their criticality; requiring an index to be built from a feature scan or security scenarios is not placing the operator in a comfortable situation.

________________________________
From: Charlie Perkins <[email-masked]>
Sent: Monday, January 22, 2018 7:10 PM
To: Bertz, Lyle T [CTO]
Cc: [email-masked]
Subject: Re: Question about Interface Groups (formerly, DPN Groups)

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.

Lyle

Hello Lyle,

I agree that:

Regards,
Charlie P.

Hello Lyle,

Regards,
Charlie P.

Hello folks,

Regards,
Charlie P.

Lyle

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Tue, 23 Jan 2018 13:38:57 +0000

The current Mobility Context uses the assigned address or prefixes in conjunction with device information, or similar information in an ancestor (if this is a child/descendent), to let the DPN know all traffic serviced with the Mobility Context information MUST have a destination/source matching the address(es) (per the direction of the traffic).

This is an implicit Descriptor if you would like to view it that way.  It was placed in the original documents in this manner I would assume for consistency with the current and next gen designs.

The implication of what you are proposing is a more granular (sub-session) context with possible no actions.   The current implementation allows Rules to be assigned to DPNs in the underlying list.   The Rule containing the Descriptors and associated Actions.

I would stick to the current design; placing lists of Descriptors (beyond the Addresses) w/o Rule and DPN assignment creates too much ambiguity, validation cross checking in the DPN / Agent and would result in large, granular hierarchies.

________________________________________
From: Charlie Perkins <[email-masked]>
Sent: Monday, January 22, 2018 10:08 PM
To: Bertz, Lyle T [CTO]
Cc: [email-masked]
Subject: Using traffic Descriptors to characterize flows in a Mobility Context

Hello Lyle and all,

Comments?

Regards,
Charlie P.

On 1/22/2018 1:28 PM, Bertz, Lyle T [CTO] wrote:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7CLyle.T.Bertz%40sprint.com%7C33aa7651efaa45ea243408d562170238%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C636522773320593139&sdata=inVe0h40xJ71cyWrfMTBbt8TePDmXQGkXWccr7GtoYY%3D&reserved=0

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 23 Jan 2018 06:58:54 -0800

Hello Lyle,

I am sorry to say that I don't understand your explanation.

To start with, I didn't mean to have a direct mapping between Interface 
Groups and 3GPP features.  Instead, I would like to suggest that 
Interface Groups are defined/configured/populated to make it easier to 
support features as needed.  If multiple Interface Groups are required 
(say, because the feature is complicated, or multi-modal, or spans 
multiple DPNs) that should be O.K.  If necessary, we could create a new 
kind of entity which collects together multiple Interface Groups which 
are then configured together to support the complicated feature. 
Hierarchically, you might say.

Questions below:

On 1/23/2018 5:25 AM, Bertz, Lyle T [CTO] wrote:
>
> ​
>
> wrt
>
> "What if we make that to be two different access-network features, and 
> enable selection of Interface Groups for each feature?"
>
>
> > emergency calls when roaming are not treated the same when they are 
> domestic.
>

Doesn't this mean that they are handled using different DPNs, and thus 
different Interface Groups?

>   this is especially true when it comes from an automobile.
>

I reckon that for vehicular mobility we will indeed see substantial 
differences in many aspects of mobility management.

>    In fact, they are often set aside as different APNs.
>

Somehow this seems to motivate even more strongly the design advantage 
of having the Interfaces of an Interface Group reside on a single DPN.

>   I'd like to be able to support the current DDDS implementations as 
> well as TS 29.303.
>

Agreed -- if we can't do that, something is likely to be wrong, or else 
outside the jurisdiction of IETF.

> Furthermore, such scenarios are indexed given their criticality;
>

Here I am at a loss.  An indexed set provides entity handles for 
reference in other structures.  Do you have some additional mechanism in 
mind?  How does criticality affect the creation of the index?

> requiring an index to be built from a feature scan or security 
> scenarios is not placing the operator in a comfortable situation.
>

And so I do not understand this either.  An indexed set offers 
references to a set of ("indexed") entities that share the same 
information model definition.  Can you say more about when and how a 
feature scan might work?  How would the indexed set be populated from 
that?  How would a security scenario impact the indexing of the Indexed 
Set?  If we don't provide an Information Model that enables the desired 
security scenarios, then we didn't finish our job yet. Security could 
well influence the configuration of appropriate Interfaces into an 
Interface Group, but I don't see how it is related to the creation of an 
index into a set of such Groups.

Thanks in advance for your consideration of my questions!

Regards,
Charlie P.

> *From:* Charlie Perkins <[email-masked]>
> *Sent:* Monday, January 22, 2018 7:10 PM
> *To:* Bertz, Lyle T [CTO]
> *Cc:* [email-masked]
> - 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.
>
>> 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?
>>
>> different or have a different purpose, e.g. normal calls vs. 
>> emergency calls, this is not the case in practice.
>>
>> 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 
>> 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 
>>     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.
>>
>>     DPN-Type (interface types).  In this case the totality of
>>     services could be provided by more than one DPN.
>>
>>     maintain it as a DPN means some DPNs are used during selection
>>     but others are not.
>>
>>     interconnection between Interface Groups even if the interfaces
>>     of the Group all reside on the same DPN.
>>
>>     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.
>>
>>

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 23 Jan 2018 07:13:01 -0800

Hello Lyle and all,

Follow-up below...

> The current Mobility Context uses the assigned address or prefixes in conjunction with device information, or similar information in an ancestor (if this is a child/descendent), to let the DPN know…

I think this means that the DPN provides service to a flow in a way that 
depends on the source/destination addresses of the traffic of the flow.

> This is an implicit Descriptor if you would like to view it that way.  It was placed in the original documents in this manner I would assume for consistency with the current and next gen designs.

Check.  In fact, a flow could be defined to also depend on other things 
about the traffic (port number, packet size, ...).

>
> The implication of what you are proposing is a more granular (sub-session) context with possible no actions.

I am O.K. with having actions as well.  Granularity is according to 
whatever is convenient for whoever defines the flows.

>     The current implementation allows Rules to be assigned to DPNs in the underlying list.   The Rule containing the Descriptors and associated Actions.

This will very simple to provide, and I will change the rough draft to 
reflect this.  Suppose the Rule is something like "if byte count exceeds 
current payment, send warning".  Is that related to what you have in mind?

> I would stick to the current design; placing lists of Descriptors (beyond the Addresses) w/o Rule and DPN assignment creates too much ambiguity, validation cross checking in the DPN / Agent and wou…

Does the above resolve your concern?  I don't think I grasp the 
implication of your last clause, but if associating Rules with flows is 
acceptable, then all is good.

Regards,
Charlie P.

========================= end of new text ===========================

---

From: Lyle Bertz <[email-masked]>
Date: Tue, 23 Jan 2018 12:32:11 -0600

snipped all but this response to reduce size.

I believe you are close in your understanding.

Regarding policy.

Policies have a couple of origins.   They are typically referred to as
"dynamic" (dynamically built) or "pre configured" (templates aka static
policy).   Prior to FPC the focus had been on dynamic or sending a
'dynamic' policy over the wire and remembering it.  How pre-configuration
works was largely out of the scope of most protocols but needed to be
addressed in reality.  The more pre-configuration of policy that was done,
the more complexity was required in a dynamic only protocol so support it.
Many operators referred to these static policies and their lifecycles as
"magic" which is never a great sign when troubleshooting.

Is the difference necessary? Yes.  Pre-configuration works more as a
template that needs some complementary runtime information to make it
applicable to individual users.   The value of templates are well
understood as well as having entities pre-configured.

Dynamic has trended toward highly customized policies.  There are two
origins of this in today's networks:
- Application Detection - The Rule has a vague descriptor such as "bit
torrent" or "example.com".   This isn't really actionable.  In 3GPP and
other systems once the IP flows (5-tuple) is associated with the traffic,
then the actions are associated with the 5-tuple (descriptor).  In the case
of 3GPP some configurations only use Application Detection to notify the
policy decision point (PCRF in this case) of the 5-tuple and the PCRF will
apply a rule on a gateway with the 5-tuple and action.
- Application Function (AF) -  There are many products that require
different treatment (most people think QoS but it can be more general).
The widest application is SIP / IMS based flows (which do require QoS).
SDP based negotiations are dynamic and very narrow.  They are, in effect,
not very reusable.

To support generic, re-usable Rules we put them in the Mobility-Context
(not shown below) to reflect the fact that they are required but their
assignment will change as the device moves.  In the Assigned-DPN-Policy you
have a couple of things that need to be noted:
- DPN interface the Rule(s) are applied to
- Complementary Settings which you described below (a 'fill in the blanks'
set of attributes)
- Rules to be assigned.  The templates (Assigned-Policy-Key Set) and/or
(dynamic) embedded rules

We chose the term embedded to note it was part of the Context.  It does not
require being remembered once the Context is destroyed.

per your question "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."

I think you are talking about your proposed change.   I would say I am
against the Flow model you propose.  Too granular of a flow makes the
Context a Rule without an Action Set and why wouldn't you call it a Rule?
When it is an IP address its a Session.   If we nix the policy as you
propose then it is truly just a Rule and we already have that convention in
the model.

I like the Request-Policy-Key and Assigned-Policy-Key.  It's clear imo and
should be adopted.

The question becomes if the Embedded-Rules are vague enough they can be
assigned to the top level (I *think* this is the case but will look at pcap
files today to determine).  If this is true then they would be a second
class of Rule (one that does not need Descriptor-Id values or Action-Id) as
it is never intended to be re-used after the Context is destroyed.

Charlie,

I would propose we keep working the Requested (template) and Embedded
(disposable) first.  I would like to see the updated context with the
prefixes.  I think we can describe the Agent/DPN logic then tackle the Flow
vs. Prefix.  It is a lot to try to address and we may change our views on
the matter once we have an agreed up on approach for static vs. dynamic
policy.

Nice work!

On Mon, Jan 22, 2018 at 11:18 PM, Charlie Perkins <
[email-masked]> wrote:

> 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.
>
>           |
> I have been puzzling over the Policy entries for a good while and I still
> am mostly in the dark.
>
> managing traffic for a flow.  From among those policies, the DPN wants to
> know which policies have actually been *requested* for a flow.
>
> 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.
>
> 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.
>
> 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.
>
> </snip>

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 26 Jan 2018 12:02:05 -0800

Hello folks,

Looking at the FPC draft 10, it has the following organization in section 4:

Version 10:

4    FPC Mobility Information Model
4.1    Model Notation and Conventions
4.2    Core Structure - Information Model Components
4.3    Topology
4.3.1    DPN
4.3.2    DPN-Type
4.3.3    DPN-Group
4.3.4    Domain
4.4    Policy
4.5    Configurable Policy
4.6    Mobility-Context
4.7    Monitors
4.8    Namespace and Format
4.9    Attribute Application

I'd like to reorganize this somewhat, while keeping most of the same 
kind of content with modifications according to recent discussion. Here 
is a proposed new organization.  Below the proposed reorganization of 
the sections, I have some comments that will, I hope, be agreeable.

  4    FPC Mobility Information Model
4.1    Model Notation and Conventions
4.2    Namespace and Format
4.3    Attribute Application
4.4    Information Model Components
4.4.1        Domain
4.4.2        Configurable Policy
4.4.3        DPN-Type
4.4.4        Interface
4.4.5        Interface-Group
4.5    Topology Information Model
4.6    DPN Information Model
4.7    Policy Information Model
4.8    Mobility-Context Information Model
4.9    Monitor Information Model

For this reorganization, the major concepts are Topology, DPN, Policy, 
Mobility-Context, and Monitor.  I have promoted each of these major 
concepts to have its own subsection of the FPC Information Model section.

I am proposing a change in the implied meaning of "Component".  In the 
new text, I would use "component" to mean a small-ish building block 
that is used in the major concepts of FPC.  They are secondary in nature 
(compared to the major concepts).  I think that the "Interface" 
component deserves its own small section, and then "Interface-Group" 
[was, DPN-Group] could use that in a natural fashion.

If Interface-Group seems "unlike" the other components, we could 
describe it as an "assembly".  On the other hand, just because something 
is described as a "component" doesn't mean it is unimportant.  For 
instance, "domain" is very important, but in the information model it 
looks like a component of the definition of a Topology.

The Namespace subsection seems to belong nearer the start before getting 
into the technical description of the Components and major sections.  A 
lot of the complication in this document is related to difficulty of 
describing abstract concepts, and naming is crucial to clarify and 
reduce the complications.  So namespace takes some priority.  I have 
more discussion about this later, but for now this is enough to justify 
moving that subsection closer to the front of section 4.

Finally, the method of applying Settings to complete the Attribute 
values of an Information Model object should be described more generally 
and then specialized to Embedded Rules and so forth.  I don't have good 
text for that yet [TBD!!], but it seems important also for the way we 
use Descriptors and Actions in the Policy Information Model.

Regards,
Charlie P.