Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
Tony Przygienda <[email protected]> Fri, 16 Feb 2018 18:29:31 -0800
| Newsgroups | gmane.ietf.isis |
|---|---|
| Message-ID | <CA+wi2hPeRgqS2C+y_wy3=7po5M9rocr3E+sjOPMqiaAraBTWZw__26626.6020400964$1518834533$gmane$org@mail.gmail.com> |
--===============9206945695817459859== Content-Type: multipart/alternative; boundary="94eb2c0a54ce8994e405655f3d0c" --94eb2c0a54ce8994e405655f3d0c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm working on a strawman of what I understood we seem to agree on for further comments in detail, ETA tommorow ... On Fri, Feb 16, 2018 at 6:18 PM, Dolganow, Andrew (Nokia - SG/Singapore) < [email protected]> wrote: > Agree, what Eric has is starting to look like a compromise. Let=E2=80=99s= get the > final text (wip) on the list asap. > > > > Andrew > > > > *From: *"Les Ginsberg (ginsberg)" <[email protected]> > *Date: *Friday, February 16, 2018 at 11:08 PM > *To: *Eric Rosen <[email protected]>, Andrew Dolganow < > [email protected]>, "(Ice) IJsbrand Wijnands" <[email protected]> > *Cc: *Greg Shepherd <[email protected]>, "[email protected]" <[email protected]>, = " > [email protected]" <[email protected]>, Xiejingrong <[email protected]= >, > Arkadiy Gulko <[email protected]> > *Subject: *RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis- > extensions-07.txt > > > > Eric - > > > > *From:* Eric C Rosen [mailto:[email protected]] > *Sent:* Friday, February 16, 2018 6:45 AM > *To:* Les Ginsberg (ginsberg) <[email protected]>; Dolganow, Andrew > (Nokia - SG/Singapore) <[email protected]>; IJsbrand Wijnands < > [email protected]> > *Cc:* Greg Shepherd <[email protected]>; [email protected]; [email protected]; > Xiejingrong <[email protected]>; [email protected] > *Subject:* Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis- > extensions-07.txt > > > > 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 fo= r > a given BIER sub-domain is determined by the pair of codepoints: <IGP > Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>. > > > *[Les:] Makes sense =E2=80=93 except I would think only when the BUAM =3D= =3D 0 do the > values come from IGP registry. Other values for BUAM would require a > different set of definitions for the algorithm value.* > > * Les* > > > 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 regist= ry > 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 ho= w > 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 =E2=80=93 > > > > There is no change being considered to the size of the algorithm field fo= r > Segment Routing. That is 8 bits =E2=80=93 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 fo= r > SR use) which defines 8 bit values. > > > > The only thing which is being discussed here is whether BIER should use a= n > 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] <[email protected]>] *On > Behalf Of *Dolganow, Andrew (Nokia - SG/Singapore) > *Sent:* Thursday, February 15, 2018 7:39 PM > *To:* IJsbrand Wijnands <[email protected]> <[email protected]> > *Cc:* Greg Shepherd <[email protected]> <[email protected]>; [email protected]; > [email protected]; Xiejingrong <[email protected]> > <[email protected]>; [email protected]; Eric C Rosen > <[email protected]> <[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 o= f > them should own and mandate use. We are chartering LSR now - should we ad= d > registry for all IGP algorithms, we have routing WG, others? Would like = to > hear AD=E2=80=99s opinion. Note that although LSR appears obvious, the al= gorithms > 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 ta= x > 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 co= me > 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]> 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 suppor= t > 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 underl= ay > 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 kno= w > we can solve multiple use-cases. The main question (I think) is whether w= e > 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=E2=80=99t see why its now different for 16bits. It gives us time to w= orkout > 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]> wrote: > > > > On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <[email protected]> wrote: > On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <[email protected] > > wrote: > > > On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <[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 the= n > a discussion starts to make sense and what the size of that should be giv= en > 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 "wid= er > 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 technolo= gy > 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] > https://www.ietf.org/mailman/listinfo/bier > <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_bier&d=3DDwMGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoC= I&r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3D6OA-v6Lzq8oR77r5sobl4= BRPQbtAOImezBFZ2ljFIHA&s=3DvxlvDI3ihNiRYhMD9FOOhdgHsUytgoyTrVRAkLXqc5U&e=3D= > > > > > <PastedGraphic-6.png> > > > > _______________________________________________ > Isis-wg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/isis-wg > <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_isis-2Dwg&d=3DDwMGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTX= cWzoCI&r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3D6OA-v6Lzq8oR77r5= sobl4BRPQbtAOImezBFZ2ljFIHA&s=3DgRpwwZhHBYgy3mRmJHvKkTmqciLemxC0YhCk0qAATNg= &e=3D> > > > > _______________________________________________ > BIER mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bier > > --94eb2c0a54ce8994e405655f3d0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I'm working on a strawman of what I understood we seem= to agree on for further comments in detail, ETA tommorow ... <br></div><di= v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Feb 16, 2018= at 6:18 PM, Dolganow, Andrew (Nokia - SG/Singapore) <span dir=3D"ltr"><= <a href=3D"mailto:[email protected]" target=3D"_blank">andrew.dolga= [email protected]</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div link=3D"blue" vlink=3D"purple" lang=3D"EN-CA"> <div class=3D"m_8030113096626299545WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:windowtext" lang=3D"EN-US">Agree, what Eric ha= s is starting to look like a compromise. Let=E2=80=99s get the final text (= wip) on the list asap.<u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:windowtext" lang=3D"EN-US"><u></u>=C2=A0<u></u= ></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:windowtext" lang=3D"EN-US">Andrew<u></u><u></u= ></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:windowtext" lang=3D"EN-US"><u></u>=C2=A0<u></u= ></span></p> <div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><b>From: </b>"Les = Ginsberg (ginsberg)" <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>><br> <b>Date: </b>Friday, February 16, 2018 at 11:08 PM<br> <b>To: </b>Eric Rosen <<a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a>>, Andrew Dolganow <<a href=3D"mailto:an= [email protected]" target=3D"_blank">[email protected]</a>>= ;, "(Ice) IJsbrand Wijnands" <<a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a>><span class=3D""><br> <b>Cc: </b>Greg Shepherd <<a href=3D"mailto:[email protected]" target=3D"= _blank">[email protected]</a>>, "<a href=3D"mailto:[email protected]" ta= rget=3D"_blank">[email protected]</a>" <<a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a>>, "<a href=3D"mailto:isis-wg@= ietf.org" target=3D"_blank">[email protected]</a>" <<a href=3D"mailt= o:[email protected]" target=3D"_blank">[email protected]</a>>, Xiejingrong= <<a href=3D"mailto:[email protected]" target=3D"_blank">xiejingron= [email protected]</a>>, Arkadiy Gulko <<a href=3D"mailto:arkadiy.gulko@tho= msonreuters.com" target=3D"_blank">arkadiy.gulko@thomsonreuters.<wbr>com</a= >><br> </span><b>Subject: </b>RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-<wb= r>extensions-07.txt<u></u><u></u></p> </div><div><div class=3D"h5"> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"font-siz= e:11.0pt;color:windowtext"><u></u>=C2=A0<u></u></span></p> </div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><a name=3D"m_8030113096= 626299545__MailOriginalBody"><span style=3D"font-size:11.0pt;font-family:&q= uot;Calibri",sans-serif;color:#1f497d">Eric -</span><u></u><u></u></a>= </p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><span style=3D"fo= nt-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">= =C2=A0</span><u></u><u></u></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><b><span style=3D= "font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowte= xt">From:</span></b></span><span><span style=3D"font-size:11.0pt;font-famil= y:"Calibri",sans-serif;color:windowtext"> Eric C Rosen [mailto:<a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a>] <br> <b>Sent:</b> Friday, February 16, 2018 6:45 AM<br> <b>To:</b> Les Ginsberg (ginsberg) <<a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a>>; Dolganow, Andrew (Nokia - S= G/Singapore) <<a href=3D"mailto:[email protected]" target=3D"_bl= ank">[email protected]</a>>; IJsbrand Wijnands <<a href=3D"ma= ilto:[email protected]" target=3D"_blank">[email protected]</a>><br> <b>Cc:</b> Greg Shepherd <<a href=3D"mailto:[email protected]" target=3D"= _blank">[email protected]</a>>; <a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>; <a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>; Xiejingrong <<a href=3D"mailto:xiejing= [email protected]" target=3D"_blank">[email protected]</a>>; <a href= =3D"mailto:[email protected]" target=3D"_blank">arkadiy.gulk= o@thomsonreuters.<wbr>com</a><br> <b>Subject:</b> Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-<wbr>exten= sions-07.txt</span><u></u><u></u></span></p> </div> </div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> <p class=3D"MsoNormal" style=3D"margin-right:0cm;margin-bottom:12.0pt;margi= n-left:36.0pt"> <span>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 Algorithm= s" Registry.<br> <br> Have another eight-bit field whose values are taken from a new BIER-specifi= c registry.=C2=A0 I don't know, maybe call it the "BIER Underlay A= lgorithm Modifier" registry.=C2=A0 The way the underlay paths are comp= uted for a given BIER sub-domain is determined by the pair of codepoints: <IGP Algorithms codepoint, BIER Underlay Algorithm Modif= ier codepoint>.<br> <br> <br> <u></u><u></u></span></p> <p class=3D"MsoNormal" style=3D"margin-right:0cm;margin-bottom:12.0pt;margi= n-left:36.0pt"> <span><b><i><span style=3D"font-size:11.0pt;font-family:"Calibri"= ,sans-serif;color:#1f497d">[Les:] Makes sense =E2=80=93 except I would thin= k only when the BUAM =3D=3D 0 do the values come from IGP registry. Other v= alues for BUAM would require a different set of definitions for the algorithm value.</span></i>= </b><u></u><u></u></span></p> <p class=3D"MsoNormal" style=3D"margin-right:0cm;margin-bottom:12.0pt;margi= n-left:36.0pt"> <span><b><i><span style=3D"font-size:11.0pt;font-family:"Calibri"= ,sans-serif;color:#1f497d">=C2=A0=C2=A0 Les</span></i></b><u></u><u></u></s= pan></p> <p class=3D"MsoNormal" style=3D"margin-right:0cm;margin-bottom:12.0pt;margi= n-left:36.0pt"> <span><br> The default value for the "BIER Underlay Algorithm Modifier" fiel= d would be zero.=C2=A0=C2=A0 The value zero in this field would mean "= just use the IGP Algorithms field to figure out how the underlay paths are = computed."=C2=A0 Non-zero values could be used to add additional nuance.=C2=A0 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=C2=A0 half th= e values for "standards action", and about half for FCFS.=C2=A0 A= nd a few for Experimental.=C2=A0 (This would be a good policy for the IGP A= lgorithms registry as well, imho.)<br> <br> This seems to have minimal impact on existing implementations, and leaves r= oom for further development of BIER while avoiding entanglements (or peceiv= ed entanglements) with other technologies that might be considered controve= rsial.<br> <br> Now perhaps the WG can proceed to the really important issues, such as how = to best design the T-shirts.=C2=A0 (Though frankly I'd rather get a few= more home-brewed beers than a T-shirt.)<br> <br> <br> <br> <u></u><u></u></span></p> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>On 2/16/2018 12:5= 1 AM, Les Ginsberg (ginsberg) wrote:<u></u><u></u></span></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><span style=3D"fo= nt-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">An= drew =E2=80=93</span><u></u><u></u></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><span style=3D"fo= nt-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">= =C2=A0</span><u></u><u></u></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><span style=3D"fo= nt-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Th= ere is no change being considered to the size of the algorithm field for Se= gment Routing.=C2=A0 That is 8 bits =E2=80=93 there are mature SR documents and multiple implem= entations that use that encoding. There is also the IGP registry defined in= an SR document (though not necessarily exclusively for SR use) which defin= es 8 bit values.</span><u></u><u></u></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><span style=3D"fo= nt-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">= =C2=A0</span><u></u><u></u></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><span style=3D"fo= nt-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Th= e 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 r= egistry may still be of use to BIER.</span><u></u><u></u></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><span style=3D"fo= nt-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">= =C2=A0</span><u></u><u></u></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><span style=3D"fo= nt-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">= =C2=A0=C2=A0 Les</span><u></u><u></u></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><span style=3D"fo= nt-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">= =C2=A0</span><u></u><u></u></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><b><span style=3D= "font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span><= /b></span><span><span style=3D"font-size:11.0pt;font-family:"Calibri&q= uot;,sans-serif"> BIER [</span></span><a href=3D"mailto:[email protected]" target=3D"_bl= ank"><span><span style=3D"font-size:11.0pt;font-family:"Calibri",= sans-serif">mailto:[email protected]</span></span><span></span></a><spa= n><span style=3D"font-size:11.0pt;font-family:"Calibri",sans-seri= f">] <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 </span></span><a href=3D"mailto:[email protected]"= target=3D"_blank"><span><span style=3D"font-size:11.0pt;font-family:"= Calibri",sans-serif"><[email protected]></span></span><span></span><= /a><span><span style=3D"font-size:11.0pt;font-family:"Calibri",sa= ns-serif"><br> <b>Cc:</b> Greg Shepherd </span></span><a href=3D"mailto:[email protected]" = target=3D"_blank"><span><span style=3D"font-size:11.0pt;font-family:"C= alibri",sans-serif"><[email protected]></span></span><span></span= ></a><span><span style=3D"font-size:11.0pt;font-family:"Calibri",= sans-serif">; </span></span><a href=3D"mailto:[email protected]" target=3D"_blank"><span><spa= n style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">bie= [email protected]</span></span><span></span></a><span><span style=3D"font-size:11.= 0pt;font-family:"Calibri",sans-serif">; </span></span><a href=3D"mailto:[email protected]" target=3D"_blank"><span><= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= [email protected]</span></span><span></span></a><span><span style=3D"font-si= ze:11.0pt;font-family:"Calibri",sans-serif">; Xiejingrong </span></span><a href=3D"mailto:[email protected]" target= =3D"_blank"><span><span style=3D"font-size:11.0pt;font-family:"Calibri= ",sans-serif"><[email protected]></span></span><span></span= ></a><span><span style=3D"font-size:11.0pt;font-family:"Calibri",= sans-serif">; </span></span><a href=3D"mailto:[email protected]" target=3D= "_blank"><span><span style=3D"font-size:11.0pt;font-family:"Calibri&qu= ot;,sans-serif">arkadiy.gulko@thomsonreuters.<wbr>com</span></span><span></= span></a><span><span style=3D"font-size:11.0pt;font-family:"Calibri&qu= ot;,sans-serif">; Eric C Rosen </span></span><a href=3D"mailto:[email protected]" target=3D= "_blank"><span><span style=3D"font-size:11.0pt;font-family:"Calibri&qu= ot;,sans-serif"><[email protected]></span></span><span></span></a><s= pan><span style=3D"font-size:11.0pt;font-family:"Calibri",sans-se= rif"><br> <b>Subject:</b> Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-<wbr>exten= sions-07.txt</span><u></u><u></u></span></p> </div> </div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>Well, <u></u><u></u></span></p> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>Now, there are mu= ltiple treads being discussed here under one topic:<u></u><u></u></span></p= > </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>- how big should = the the field be?<u></u><u></u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>- should there be= common registry for all technologies?<u></u><u></u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>- where should it= be defined and which WG should standardize it?<u></u><u></u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>To me the first q= uestion is totally dependent on the answer to the last two, since the use c= ase pointed out suggests a common registry.=C2=A0<u></u><u></u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>Now there may be = different opinions (I believe there are from this exchange) whether we shou= ld 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:=C2=A0<u></u><u></u></span></p= > </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>- 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 al= l IGP algorithms, we have routing WG, others?=C2=A0 Would like to hear AD= =E2=80=99s 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).=C2=A0<u></u><u></u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>- if we do agree = to have a common registry, I would assume we all then tax everyone to signa= l that the same way. That would mean changes to SR and changes to BIER.=C2= =A0<u></u><u></u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>This seems a lot.= We have implementations of both technologies, so are changes to those warr= anted or is it too late and we should pursue independent =C2=A0alg definiti= on and registry as it has been set-up in the existing drafts. And we are talk= ing only of those two but more WG will come and want to define things for t= hem as well.=C2=A0<u></u><u></u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-right:0cm;margin-bottom:12.0pt;margi= n-left:36.0pt"> <span>=C2=A0<u></u><u></u></span></p> <div id=3D"m_8030113096626299545AppleMailSignature"> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>Andrew <u></u><u></u></span></p> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>Sent from my iPho= ne<u></u><u></u></span></p> </div> </div> <div> <p class=3D"MsoNormal" style=3D"margin-right:0cm;margin-bottom:12.0pt;margi= n-left:36.0pt"> <span><br> On Feb 16, 2018, at 2:51 AM, IJsbrand Wijnands <</span><a href=3D"mailto= :[email protected]" target=3D"_blank"><span>[email protected]</span><span></span></= a><span>> wrote:<u></u><u></u></span></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>I think its clear= from the discussion there are different opinions on the matter on how to m= ake 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 leas= t 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 wa= ys to do things.<u></u><u></u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>One thing is clea= r, with just 8bits, it will be very hard to reach an agreement what the reg= istry 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 every= body seemed ok with 8bit BAR without a registry, I don=E2=80=99t see why it= s now different for 16bits. It gives us time to workout exactly how to use it and get input from the WGs.<u></u><u= ></u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>And, of course, t= he goal is to create a registry for the 16 bits through a new draft!<u></u>= <u></u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>Thx,<u></u><u></u= ></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>Ice.<u></u><u></u= ></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><br> <br> <br> <br> <u></u><u></u></span></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>On 15 Feb 2018, a= t 18:28, Tony Przygienda <</span><a href=3D"mailto:[email protected]" = target=3D"_blank"><span>[email protected]</span><span></span></a><span>&g= t; wrote:<br> <br> <br> <br> On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd=C2=A0<</span><a href=3D"m= ailto:[email protected]" target=3D"_blank"><span>[email protected]</span><spa= n></span></a><span>>=C2=A0<wbr>wrote:<br> On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda=C2=A0<</span><a href=3D= "mailto:[email protected]" target=3D"_blank"><span>tonysietf@gmail.<wbr>c= om</span><span></span></a><span>>=C2=A0wrote:<br> <br> <br> On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd=C2=A0<</span><a href=3D"m= ailto:[email protected]" target=3D"_blank"><span>[email protected]</span><spa= n></span></a><span>>=C2=A0<wbr>wrote:<br> For the record, there is no SR Registry. There is only an IGP Algo Type Reg= istry as defined in draft-ietf-ospr-segment-<wbr>routing-extensions-24 sect= ion 8.5<br> <br> So is that a good idea, having multiple drafts in flight with fields expect= ing to have magic couplings to each other=C2=A0while leaving e'thing &q= uot;unspecified" to "publish RFCs" while we "decide thi= ngs later"?=C2=A0<br> <br> That was a pivot, but still; there is no reference, there is no coupling.= =C2=A0<br> <br> Tangental: draft-ietf-ospr-segment-<wbr>routing-extensions-24 has been arou= nd for a while, and the IGP Algo registry will be=C2=A0tied to this draft a= nd it's fate. If anyone is expecting to use this registry outside of th= e scope of this draft, it would=C2=A0be 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=C2=A0independent body then a = discussion starts to make sense and what the size of that should be given t= hat mandates algorithms=C2=A0over multiple technologies (SR, unicast, mcast, whatever) and implies a "God's = eye view" of all the elements of all the=C2=A0technologies (and if a c= omputation touches elements from two technologies they become [optionally] = coupled).=C2=A0 We are not=C2=A0talking IGP registry or multicast computation registry or SR registry then but a "wider scope registry&= quot;. Yes, that is an=C2=A0intriguing thought with its own validity but ou= tside the scope of charter we're under as BIER.=C2=A0 Personally, I con= sider=C2=A0multiple, if needed loosely coupled registries for each technology a less centralized and hence "more Internet like"= ;=C2=A0solution but I see how opinions on such a thing can diverge ...=C2= =A0<br> <br> thanks<br> <br> --- tony=C2=A0<br> =C2=A0<br> <br> <br> ______________________________<wbr>_________________<br> BIER mailing list<br> </span><a href=3D"mailto:[email protected]" target=3D"_blank"><span>[email protected]= rg</span><span></span></a><span><br> </span><a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ww= w.ietf.org_mailman_listinfo_bier&d=3DDwMGaQ&c=3DHAkYuh63rsuhr6Scbfh= 0UjBXeMK-ndb3voDTXcWzoCI&r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VN= o&m=3D6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=3DvxlvDI3ihNiRY= hMD9FOOhdgHsUytgoyTrVRAkLXqc5U&e=3D" target=3D"_blank"><span>https://ww= w.ietf.org/mailman/<wbr>listinfo/bier</span><span></span></a><span><u></u><= u></u></span></p> </blockquote> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span><PastedGraphic= -6.png><u></u><u></u></span></p> </div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> </div> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>_________________= _____________<wbr>_________________<br> Isis-wg mailing list<br> </span><a href=3D"mailto:[email protected]" target=3D"_blank"><span>Isis-wg@= ietf.org</span><span></span></a><span><br> </span><a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ww= w.ietf.org_mailman_listinfo_isis-2Dwg&d=3DDwMGaQ&c=3DHAkYuh63rsuhr6= Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0= kG0VNo&m=3D6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=3DgRpwwZhH= BYgy3mRmJHvKkTmqciLemxC0YhCk0qAATNg&e=3D" target=3D"_blank"><span>https= ://www.ietf.org/mailman/<wbr>listinfo/isis-wg</span><span></span></a><span>= <u></u><u></u></span></p> </div> </blockquote> </div> </div> </blockquote> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span>=C2=A0<u></u><u><= /u></span></p> </div> </div></div></div> </div> <br>______________________________<wbr>_________________<br> BIER mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/bier" rel=3D"noreferrer" t= arget=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/bier</a><br> <br></blockquote></div><br></div> --94eb2c0a54ce8994e405655f3d0c-- --===============9206945695817459859== 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 --===============9206945695817459859==--