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

[Charlie Perkins]

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 
*Sent:* Monday, January 22, 2018 7:10 PM
*To:* Bertz, Lyle T [CTO]
*Cc:* dmm@ietf.org
*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.

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 

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

[Bertz, Lyle T [CTO]]

​

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 
Sent: Monday, January 22, 2018 7:10 PM
To: Bertz, Lyle T [CTO]
Cc: dmm@ietf.org
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.

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 

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