Re: Question about Interface Groups (formerly, DPN Groups)
Charlie Perkins <[email protected]> Mon, 22 Jan 2018 13:25:00 -0800
| Newsgroups | gmane.ietf.mip6 |
|---|---|
| Message-ID | <de6bf1f4-fdff-ce14-6c55-105539e059fd__20324.2380674512$1516656295$gmane$org@earthlink.net> |
This is a multi-part message in MIME format.
--===============2220362682817792182==
Content-Type: multipart/alternative;
boundary="------------67326BA1580FAC2B379D7510"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------67326BA1580FAC2B379D7510
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
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]>
> *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.
>
--------------67326BA1580FAC2B379D7510
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>
I agree that:<br>
<ol>
<li>- Interface Groups are designed to be used to select DPN.</li>
<li>- Interface Groups may contain a number of different Interface
Types</li>
<li>- There may be more than one Interface Group providing
equivalent service, at least for the purpose of selecting a DPN.</li>
</ol>
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>
<blockquote type="cite"><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></blockquote>
<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>
<br>
<div class="moz-cite-prefix">On 1/22/2018 11:36 AM, 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:"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-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;}
--></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"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">k.
I think that we are crossing conversations now.<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>
<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.<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>
<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.
<o:p></o:p></span></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.<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>
<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 ;)<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>
<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.<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>
<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.
<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>
<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 12:07 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" 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>
<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>
</div>
</blockquote>
<br>
</body>
</html>
--------------67326BA1580FAC2B379D7510--
--===============2220362682817792182==
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
--===============2220362682817792182==--