Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
Eric C Rosen <[email protected]> Fri, 16 Feb 2018 09:44:42 -0500
| Newsgroups | gmane.ietf.isis |
|---|---|
| Message-ID | <dd6bd5e4-1b62-8134-56ca-497cbbc059b5__21444.6204285652$1518792195$gmane$org@juniper.net> |
This is a multi-part message in MIME format. --===============9213095111195314162== Content-Type: multipart/alternative; boundary="------------950D92E75968A15082B620EC" Content-Language: en-US This is a multi-part message in MIME format. --------------950D92E75968A15082B620EC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Perhaps the following would be a good compromise (or perhaps not). Have an eight-bit field whose values are taken from the "IGP Algorithms" Registry. Have another eight-bit field whose values are taken from a new BIER-specific registry. I don't know, maybe call it the "BIER Underlay Algorithm Modifier" registry. The way the underlay paths are computed for a given BIER sub-domain is determined by the pair of codepoints: <IGP Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>. The default value for the "BIER Underlay Algorithm Modifier" field would be zero. The value zero in this field would mean "just use the IGP Algorithms field to figure out how the underlay paths are computed." Non-zero values could be used to add additional nuance. Existing drafts can say "the use of non-zero values in this field is outside the scope of this document". The registration policy for the new registry could save about half the values for "standards action", and about half for FCFS. And a few for Experimental. (This would be a good policy for the IGP Algorithms registry as well, imho.) This seems to have minimal impact on existing implementations, and leaves room for further development of BIER while avoiding entanglements (or peceived entanglements) with other technologies that might be considered controversial. Now perhaps the WG can proceed to the really important issues, such as how to best design the T-shirts. (Though frankly I'd rather get a few more home-brewed beers than a T-shirt.) On 2/16/2018 12:51 AM, Les Ginsberg (ginsberg) wrote: > > Andrew – > > There is no change being considered to the size of the algorithm field > for Segment Routing. That is 8 bits – there are mature SR documents > and multiple implementations that use that encoding. There is also the > IGP registry defined in an SR document (though not necessarily > exclusively for SR use) which defines 8 bit values. > > The only thing which is being discussed here is whether BIER should > use an 8 bit or 16 bit algorithm field. Also, even if it is decided > BIER should use a 16 bit algorithm, it is conceivable that the values > defined in the IGP algorithm registry may still be of use to BIER. > > Les > > *From:*BIER [mailto:[email protected]] *On Behalf Of *Dolganow, > Andrew (Nokia - SG/Singapore) > *Sent:* Thursday, February 15, 2018 7:39 PM > *To:* IJsbrand Wijnands <[email protected]> > *Cc:* Greg Shepherd <[email protected]>; [email protected]; > [email protected]; Xiejingrong <[email protected]>; > [email protected]; Eric C Rosen <[email protected]> > *Subject:* Re: [Bier] [Isis-wg] WGLC : > draft-ietf-bier-isis-extensions-07.txt > > Well, > > Now, there are multiple treads being discussed here under one topic: > > - how big should the the field be? > > - should there be common registry for all technologies? > > - where should it be defined and which WG should standardize it? > > To me the first question is totally dependent on the answer to the > last two, since the use case pointed out suggests a common registry. > > Now there may be different opinions (I believe there are from this > exchange) whether we should or should not have a common registry, how > complicated would it be and whether it would tax all groups trying to > use that. But even before we go there, the basic question has to be > answered: > > - which WG would own that registry. It is not in a charter of BIER to > own it nor it is in a charter of SR nor it is in a charter of ISIS. Do > none of them should own and mandate use. We are chartering LSR now - > should we add registry for all IGP algorithms, we have routing WG, > others? Would like to hear AD’s opinion. Note that although LSR > appears obvious, the algorithms to compute BIER may be > controller-based that do bot require LSR (same applies to SR). > > - if we do agree to have a common registry, I would assume we all then > tax everyone to signal that the same way. That would mean changes to > SR and changes to BIER. > > This seems a lot. We have implementations of both technologies, so are > changes to those warranted or is it too late and we should pursue > independent alg definition and registry as it has been set-up in the > existing drafts. And we are talking only of those two but more WG will > come and want to define things for them as well. > > Andrew > > Sent from my iPhone > > > On Feb 16, 2018, at 2:51 AM, IJsbrand Wijnands <[email protected] > <mailto:[email protected]>> wrote: > > I think its clear from the discussion there are different opinions > on the matter on how to make BIER use the BAR field. The reason > for me to support 16 bits is that everybody seemed ok go move > forward with an 8bits BAR without a registry, a 16bits BAR does > not change anything, its just a bigger field. But at least with > 16bits, we can split in Type, Value, and support different > use-cases. IMO, pointing to whatever the Unicast underlay is > providing is the main use-case, but it allows other ways to do things. > > One thing is clear, with just 8bits, it will be very hard to reach > an agreement what the registry would look like. If we make it > 16bits, we know we can solve multiple use-cases. The main question > (I think) is whether we document how a 16bit BAR is carved up now, > or we defer that to later. And as I said, since everybody seemed > ok with 8bit BAR without a registry, I don’t see why its now > different for 16bits. It gives us time to workout exactly how to > use it and get input from the WGs. > > And, of course, the goal is to create a registry for the 16 bits > through a new draft! > > Thx, > > Ice. > > > > On 15 Feb 2018, at 18:28, Tony Przygienda <[email protected] > <mailto:[email protected]>> wrote: > > > > On Thu, Feb 15, 2018 at 9:20 AM, Greg > Shepherd <[email protected] <mailto:[email protected]>> wrote: > On Thu, Feb 15, 2018 at 8:53 AM, Tony > Przygienda <[email protected] > <mailto:[email protected]>> wrote: > > > On Thu, Feb 15, 2018 at 8:38 AM, Greg > Shepherd <[email protected] <mailto:[email protected]>> wrote: > For the record, there is no SR Registry. There is only an IGP > Algo Type Registry as defined in > draft-ietf-ospr-segment-routing-extensions-24 section 8.5 > > So is that a good idea, having multiple drafts in flight with > fields expecting to have magic couplings to each other while > leaving e'thing "unspecified" to "publish RFCs" while we > "decide things later"? > > That was a pivot, but still; there is no reference, there is > no coupling. > > Tangental: draft-ietf-ospr-segment-routing-extensions-24 has > been around for a while, and the IGP Algo registry will > be tied to this draft and it's fate. If anyone is expecting to > use this registry outside of the scope of this draft, it > would be in their best interest to pull the registry > description out into a separate draft. > > > OK, and I agree that if such a registry is pulled and under a > clear charter of mandating multiple technologies within > an independent body then a discussion starts to make sense and > what the size of that should be given that mandates > algorithms over multiple technologies (SR, unicast, mcast, > whatever) and implies a "God's eye view" of all the elements > of all the technologies (and if a computation touches elements > from two technologies they become [optionally] coupled). We > are not talking IGP registry or multicast computation registry > or SR registry then but a "wider scope registry". Yes, that is > an intriguing thought with its own validity but outside the > scope of charter we're under as BIER. Personally, I > consider multiple, if needed loosely coupled registries for > each technology a less centralized and hence "more Internet > like" solution but I see how opinions on such a thing can > diverge ... > > thanks > > --- tony > > > > _______________________________________________ > BIER mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/bier > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=vxlvDI3ihNiRYhMD9FOOhdgHsUytgoyTrVRAkLXqc5U&e=> > > <PastedGraphic-6.png> > > _______________________________________________ > Isis-wg mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/isis-wg > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_isis-2Dwg&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=gRpwwZhHBYgy3mRmJHvKkTmqciLemxC0YhCk0qAATNg&e=> > --------------950D92E75968A15082B620EC 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"> Perhaps the following would be a good compromise (or perhaps not).<br> <br> Have an eight-bit field whose values are taken from the "IGP Algorithms" Registry.<br> <br> Have another eight-bit field whose values are taken from a new BIER-specific registry. I don't know, maybe call it the "BIER Underlay Algorithm Modifier" registry. The way the underlay paths are computed for a given BIER sub-domain is determined by the pair of codepoints: <IGP Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>.<br> <br> The default value for the "BIER Underlay Algorithm Modifier" field would be zero. The value zero in this field would mean "just use the IGP Algorithms field to figure out how the underlay paths are computed." Non-zero values could be used to add additional nuance. Existing drafts can say "the use of non-zero values in this field is outside the scope of this document". <br> <br> The registration policy for the new registry could save about half the values for "standards action", and about half for FCFS. And a few for Experimental. (This would be a good policy for the IGP Algorithms registry as well, imho.)<br> <br> This seems to have minimal impact on existing implementations, and leaves room for further development of BIER while avoiding entanglements (or peceived entanglements) with other technologies that might be considered controversial.<br> <br> Now perhaps the WG can proceed to the really important issues, such as how to best design the T-shirts. (Though frankly I'd rather get a few more home-brewed beers than a T-shirt.)<br> <br> <br> <br> <div class="moz-cite-prefix">On 2/16/2018 12:51 AM, Les Ginsberg (ginsberg) 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)"> <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;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.msonormal0, li.msonormal0, div.msonormal0 {mso-style-name:msonormal; 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;} span.EmailStyle18 {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">Andrew –<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">There is no change being considered to the size of the algorithm field for Segment Routing. That is 8 bits – there are mature SR documents and multiple implementations that use that encoding. There is also the IGP registry defined in an SR document (though not necessarily exclusively for SR use) which defines 8 bit values.<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 only thing which is being discussed here is whether BIER should use an 8 bit or 16 bit algorithm field. Also, even if it is decided BIER should use a 16 bit algorithm, it is conceivable that the values defined in the IGP algorithm registry may still be of use to BIER.<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"> Les<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 style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"> <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">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> BIER [<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>] <b>On Behalf Of </b>Dolganow, Andrew (Nokia - SG/Singapore)<br> <b>Sent:</b> Thursday, February 15, 2018 7:39 PM<br> <b>To:</b> IJsbrand Wijnands <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Cc:</b> Greg Shepherd <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>; <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>; Xiejingrong <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>; <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>; Eric C Rosen <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Subject:</b> Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.txt<o:p></o:p></span></p> </div> </div> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Well, <o:p></o:p></p> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">Now, there are multiple treads being discussed here under one topic:<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">- how big should the the field be?<o:p></o:p></p> </div> <div> <p class="MsoNormal">- should there be common registry for all technologies?<o:p></o:p></p> </div> <div> <p class="MsoNormal">- where should it be defined and which WG should standardize it?<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">To me the first question is totally dependent on the answer to the last two, since the use case pointed out suggests a common registry. <o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">Now there may be different opinions (I believe there are from this exchange) whether we should or should not have a common registry, how complicated would it be and whether it would tax all groups trying to use that. But even before we go there, the basic question has to be answered: <o:p></o:p></p> </div> <div> <p class="MsoNormal">- which WG would own that registry. It is not in a charter of BIER to own it nor it is in a charter of SR nor it is in a charter of ISIS. Do none of them should own and mandate use. We are chartering LSR now - should we add registry for all IGP algorithms, we have routing WG, others? Would like to hear AD’s opinion. Note that although LSR appears obvious, the algorithms to compute BIER may be controller-based that do bot require LSR (same applies to SR). <o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">- if we do agree to have a common registry, I would assume we all then tax everyone to signal that the same way. That would mean changes to SR and changes to BIER. <o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">This seems a lot. We have implementations of both technologies, so are changes to those warranted or is it too late and we should pursue independent alg definition and registry as it has been set-up in the existing drafts. And we are talking only of those two but more WG will come and want to define things for them as well. <o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p> <div id="AppleMailSignature"> <p class="MsoNormal">Andrew <o:p></o:p></p> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">Sent from my iPhone<o:p></o:p></p> </div> </div> <div> <p class="MsoNormal" style="margin-bottom:12.0pt"><br> On Feb 16, 2018, at 2:51 AM, IJsbrand Wijnands <<a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a>> wrote:<o:p></o:p></p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> <p class="MsoNormal">I think its clear from the discussion there are different opinions on the matter on how to make BIER use the BAR field. The reason for me to support 16 bits is that everybody seemed ok go move forward with an 8bits BAR without a registry, a 16bits BAR does not change anything, its just a bigger field. But at least with 16bits, we can split in Type, Value, and support different use-cases. IMO, pointing to whatever the Unicast underlay is providing is the main use-case, but it allows other ways to do things.<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">One thing is clear, with just 8bits, it will be very hard to reach an agreement what the registry would look like. If we make it 16bits, we know we can solve multiple use-cases. The main question (I think) is whether we document how a 16bit BAR is carved up now, or we defer that to later. And as I said, since everybody seemed ok with 8bit BAR without a registry, I don’t see why its now different for 16bits. It gives us time to workout exactly how to use it and get input from the WGs.<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">And, of course, the goal is to create a registry for the 16 bits through a new draft!<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">Thx,<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">Ice.<o:p></o:p></p> </div> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal"><br> <br> <o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal">On 15 Feb 2018, at 18:28, Tony Przygienda <<a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a>> wrote:<br> <br> <br> <br> On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <<a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a>> wrote:<br> On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <<a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a>> wrote:<br> <br> <br> On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <<a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a>> wrote:<br> For the record, there is no SR Registry. There is only an IGP Algo Type Registry as defined in draft-ietf-ospr-segment-routing-extensions-24 section 8.5<br> <br> So is that a good idea, having multiple drafts in flight with fields expecting to have magic couplings to each other while leaving e'thing "unspecified" to "publish RFCs" while we "decide things later"? <br> <br> That was a pivot, but still; there is no reference, there is no coupling. <br> <br> Tangental: draft-ietf-ospr-segment-routing-extensions-24 has been around for a while, and the IGP Algo registry will be tied to this draft and it's fate. If anyone is expecting to use this registry outside of the scope of this draft, it would be in their best interest to pull the registry description out into a separate draft.<br> <br> <br> OK, and I agree that if such a registry is pulled and under a clear charter of mandating multiple technologies within an independent body then a discussion starts to make sense and what the size of that should be given that mandates algorithms over multiple technologies (SR, unicast, mcast, whatever) and implies a "God's eye view" of all the elements of all the technologies (and if a computation touches elements from two technologies they become [optionally] coupled). We are not talking IGP registry or multicast computation registry or SR registry then but a "wider scope registry". Yes, that is an intriguing thought with its own validity but outside the scope of charter we're under as BIER. Personally, I consider multiple, if needed loosely coupled registries for each technology a less centralized and hence "more Internet like" solution but I see how opinions on such a thing can diverge ... <br> <br> thanks<br> <br> --- tony <br> <br> <br> <br> _______________________________________________<br> BIER mailing list<br> <a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a><br> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=vxlvDI3ihNiRYhMD9FOOhdgHsUytgoyTrVRAkLXqc5U&e=" moz-do-not-send="true">https://www.ietf.org/mailman/listinfo/bier</a><o:p></o:p></p> </blockquote> <p class="MsoNormal"><o:p> </o:p></p> <div> <p class="MsoNormal"><PastedGraphic-6.png><o:p></o:p></p> </div> <p class="MsoNormal"><o:p> </o:p></p> </div> </div> </blockquote> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class="MsoNormal">_______________________________________________<br> Isis-wg mailing list<br> <a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a><br> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_isis-2Dwg&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=gRpwwZhHBYgy3mRmJHvKkTmqciLemxC0YhCk0qAATNg&e=" moz-do-not-send="true">https://www.ietf.org/mailman/listinfo/isis-wg</a><o:p></o:p></p> </div> </blockquote> </div> </div> </div> </blockquote> <br> </body> </html> --------------950D92E75968A15082B620EC-- --===============9213095111195314162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg --===============9213095111195314162==--