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:[email protected]]
> *Sent:* Monday, January 22, 2018 3:25 PM
> *To:* Bertz, Lyle T [CTO] <[email protected]>
> *Cc:* [email protected]
> *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:[email protected]]
>     *Sent:* Monday, January 22, 2018 12:07 PM
>     *To:* Bertz, Lyle T [CTO] <[email protected]>
>     <mailto:[email protected]>
>     *Cc:* [email protected] <mailto:[email protected]>
>     *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.
>
>
>     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 protected]]
>         *Sent:* Sunday, January 21, 2018 10:51 PM
>         *To:* Bertz, Lyle T [CTO] <[email protected]>
>         <mailto:[email protected]>
>         *Cc:* Marco Liebsch <[email protected]>
>         <mailto:[email protected]>; Satoru Matsushima
>         <[email protected]>
>         <mailto:[email protected]>; Sri Gundavelli
>         (sgundave) <[email protected]> <mailto:[email protected]>;
>         Moses, Danny <[email protected]>
>         <mailto:[email protected]>; Weaver, Farni [CTO]
>         <[email protected]> <mailto:[email protected]>;
>         Matsushima Satoru <[email protected]>
>         <mailto:[email protected]>
>         *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
[email protected]
https://www.ietf.org/mailman/listinfo/dmm