Re: Question about Interface Groups (formerly, DPN Groups)
Charlie Perkins <[email protected]> Mon, 22 Jan 2018 17:10:23 -0800
| Newsgroups | gmane.ietf.mip6 |
|---|---|
| Message-ID | <d2be9bf6-e5be-b19e-da40-0cd621e656ab__47463.413529522$1516669750$gmane$org@earthlink.net> |
This is a multi-part message in MIME format. --===============5844113051576464328== Content-Type: multipart/alternative; boundary="------------5A3321628B05AD7A6A84D07E" Content-Language: en-US This is a multi-part message in MIME format. --------------5A3321628B05AD7A6A84D07E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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. > --------------5A3321628B05AD7A6A84D07E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hello Lyle,<br> <br> Thanks for the detailed reply. It clears up a lot of questions in my mind. To briefly reply:<br> <br> - 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.<br> <br> An Interface Group will also have a DPN-Key, for the DPN that hosts its interfaces.<br> <br> 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.<br> <br> Regards,<br> Charlie P.<br> <br> <div class="moz-cite-prefix">On 1/22/2018 1:49 PM, Bertz, Lyle T [CTO] wrote:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <!--[if !mso]><style>v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--> <style><!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman",serif; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:#0563C1; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:#954F72; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman",serif; color:black;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman",serif; color:black;} span.EmailStyle19 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle22 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle23 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle24 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle25 {mso-style-type:personal-reply; font-family:"Calibri",sans-serif; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:1385519717; mso-list-type:hybrid; mso-list-template-ids:2100460678 67698699 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-start-at:0; mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";} @list l0:level2 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Courier New";} @list l0:level3 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l0:level4 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;} @list l0:level5 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Courier New";} @list l0:level6 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l0:level7 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;} @list l0:level8 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Courier New";} @list l0:level9 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l1 {mso-list-id:1943763216; mso-list-template-ids:1399106718;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="WordSection1"> <p class="MsoNormal">Your scenarios are correct. I think we are in agreement but I want to clarify a few things:<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Wrt your statement “(b) it makes good sense for all the Interfaces of an Interface Group to be hosted on the same DPN.”<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">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?<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Wrt the statement “I just want all of the Interfaces of an Interface Group to be on the same DPN”<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">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. <o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">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.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Lyle<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"> Charlie Perkins [<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>] <br> <b>Sent:</b> Monday, January 22, 2018 3:25 PM<br> <b>To:</b> Bertz, Lyle T [CTO] <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a><br> <b>Subject:</b> Re: Question about Interface Groups (formerly, DPN Groups)<o:p></o:p></span></p> </div> </div> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Hello Lyle,<br> <br> I agree that:<o:p></o:p></p> <ol start="1" type="1"> <li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1"> - Interface Groups are designed to be used to select DPN.<o:p></o:p></li> <li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1"> - Interface Groups may contain a number of different Interface Types<o:p></o:p></li> <li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1"> - There may be more than one Interface Group providing equivalent service, at least for the purpose of selecting a DPN.<o:p></o:p></li> </ol> <p class="MsoNormal">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.<br> <br> For (2) -- this is really the motivation for the concept of Interface Groups.<br> <br> 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.<br> <br> 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.<br> <br> <br> <br> <o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p> </blockquote> <p class="MsoNormal" style="margin-bottom:12.0pt"><br> 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.<br> <br> I just want all of the Interfaces of an Interface Group to be on the same DPN.<br> <br> Regards,<br> Charlie P.<br> <br> <br> <o:p></o:p></p> <div> <p class="MsoNormal">On 1/22/2018 11:36 AM, Bertz, Lyle T [CTO] wrote:<o:p></o:p></p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">k. I think that we are crossing conversations now.</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">“</span>An Interface Group on a DPN would also have have attributes for Peer Interface Groups residing on other DPNs. <span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">” < Did not see that.</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Interface Groups (aka DPN Groups) can be used for DPN pool selection (multiple options) with a different interface strategy. </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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 ;)</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I would propose that we keep this concept separate for now, look at proposed changes and then revisit this issue. </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"> Charlie Perkins [<a href="mailto:[email protected]" moz-do-not-send="true">mailto:[email protected]</a>] <br> <b>Sent:</b> Monday, January 22, 2018 12:07 PM<br> <b>To:</b> Bertz, Lyle T [CTO] <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><br> <b>Cc:</b> <a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a><br> <b>Subject:</b> Re: Question about Interface Groups (formerly, DPN Groups)</span><o:p></o:p></p> </div> </div> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal" style="margin-bottom:12.0pt">Hello Lyle,<br> <br> 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.<br> <br> 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.<br> <br> Regards,<br> Charlie P.<br> <br> <br> <o:p></o:p></p> <div> <p class="MsoNormal">On 1/22/2018 5:11 AM, Bertz, Lyle T [CTO] wrote:<o:p></o:p></p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><adding mailing list></span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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. </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"> Charlie Perkins [<a href="mailto:[email protected]" moz-do-not-send="true">mailto:[email protected]</a>] <br> <b>Sent:</b> Sunday, January 21, 2018 10:51 PM<br> <b>To:</b> Bertz, Lyle T [CTO] <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a><br> <b>Cc:</b> Marco Liebsch <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a>; Satoru Matsushima <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a>; Sri Gundavelli (sgundave) <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a>; Moses, Danny <a href="mailto:[email protected]" moz-do-not-send="true"> <[email protected]></a>; Weaver, Farni [CTO] <a href="mailto:[email protected]" moz-do-not-send="true"> <[email protected]></a>; Matsushima Satoru <a href="mailto:[email protected]" moz-do-not-send="true"> <[email protected]></a><br> <b>Subject:</b> Question about Interface Groups</span><o:p></o:p></p> </div> </div> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal" style="margin-bottom:12.0pt">Hello folks,<br> <br> Can we have it so that all the Interfaces of an "Interface Group" (formerly, "DPN Group") reside on the same DPN?<br> <br> If so, I can make good sense out of the text in the document, but otherwise I think there are big problems.<br> <br> 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.<br> <br> I have some more questions, not quite as important, which I will put in separate emails.<br> <br> Regards,<br> Charlie P.<o:p></o:p></p> <div> <p class="MsoNormal">On 1/18/2018 5:26 AM, Bertz, Lyle T [CTO] wrote:<o:p></o:p></p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Charlie,</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Glad to hear things are going well. I’m looking forward to your document update.</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Lyle</span><o:p></o:p></p> <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p> </blockquote> <p class="MsoNormal"> <o:p></o:p></p> <p class="MsoNormal"> <o:p></o:p></p> <div class="MsoNormal" style="text-align:center" align="center"> <hr size="2" align="center" width="100%"> </div> <p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:gray"><br> 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.</span><o:p></o:p></p> </blockquote> <p class="MsoNormal"> <o:p></o:p></p> </blockquote> <p class="MsoNormal"><o:p> </o:p></p> </div> </blockquote> <br> </body> </html> --------------5A3321628B05AD7A6A84D07E-- --===============5844113051576464328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm --===============5844113051576464328==--