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]> Cc: [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
