Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Tony Przygienda <[email protected]> Tue, 20 Feb 2018 07:37:24 -0800
| Newsgroups | gmane.ietf.isis |
|---|---|
| Message-ID | <CA+wi2hPoTA0u2rx0f5eoBsoOAH+m1uN0ggr=P7sSYFcX=1qQxw__3785.17156136713$1519140974$gmane$org@mail.gmail.com> |
--===============2539115662610804248== Content-Type: multipart/alternative; boundary="f403045c7fa8b48d730565a69873" --f403045c7fa8b48d730565a69873 Content-Type: text/plain; charset="UTF-8" all the implementations I am aware off can adjust to Option A) with BAR registry without problems, neither do I see a problem with option B) given we are talking only 0/0 being in IGP RFC @ this point in time. thanks. tony On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas <[email protected]> wrote: > I have one additional question for those with implementations or testing > them. > > What is the impact of going with your preferred option in terms of > interoperability? It may be early enough that changes can happen, but more > feedback is needed. > > For those favoring Option B, could you send email to the list providing > exact text so we have the details? > > For those favoring the current status without an IANA registry, are you > able to handle one being imposed during IESG Review? It is an obvious > concern to raise. Are you just prolonging or postponing the discussion? > > Regards, > Aka > > > > On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" <[email protected]> > wrote: > >> +1 to Option-B >> >> Seems future proof to me. >> >> >> >> Thanks, >> >> Senthil >> >> >> >> >> >> >> >> *From:* BIER [mailto:[email protected]] *On Behalf Of *Alia Atlas >> *Sent:* 20 February 2018 03:21 >> *To:* BIER WG <[email protected]>; [email protected] list <[email protected]> >> *Subject:* [Bier] BAR field length in draft-ietf-bier-isis-extensions >> and draft-ietf-bier-ospf-extensions >> >> >> >> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and >> draft-ietf-bier-ospf-extensions-12, I have been following the discussion >> on the mailing list with interest. >> >> >> >> I have not seen clear consensus for any change. >> >> >> >> Let me be clear on what I see the options are from the discussion. Then >> I'll elaborate >> >> a bit on how you can express your perspective most usefully. >> >> >> >> 1) Current Status: Bier Algorithm (BAR) field is 8 bits. Currently, >> only value 0 is specified. The drafts do not have an IANA registry - with >> the expectation that one will be created when the first additional use is >> clear. It is possible that there will be objections from the IESG to >> progressing without an IANA registry. Given the lack of clarity for future >> use-cases and after discussion, I decided not to force one after my AD >> review - but I will not push back against having a BIER IANA registry if >> raised by others. >> >> >> >> 2) Option B: Add a BAR sub-type of 8 bits. This would modify the >> current TLVs. >> >> Define an IANA registry for the BAR type. The meaning of the BAR >> sub-type derives >> >> from the BAR type. We can debate over the registration policy for >> the BAR type. >> >> >> >> 3) Option C: Change the BAR field to be 16 bits and define an IANA >> registry. Part of the range can be FCFS with Expert Review, part can be >> Specification Required, and part can be IETF Consensus. >> >> >> >> 4) Option D: At some point in the future, if there is an actual >> understood and documented need, a BAR sub-type could be added a sub-TLV. >> The length of the BAR sub-type could be determined when the sub-TLV is >> defined. >> >> >> >> Given >> >> >> >> a) option D exists >> >> b) there is currently only one defined value for BAR >> >> c) I do not see strong consensus for change to one particular other >> option >> >> >> >> I see no current reason for a change and I certainly see absolutely no >> reason for >> >> a delay in progressing the documents. >> >> >> >> I do want to be clear about what the WG wants to do on this issue. >> Therefore, here is >> >> my following request. >> >> >> >> Please send your feedback to the mailing list as follows: >> >> >> >> IF you prefer or can accept the current status, please say so. No more >> justification >> >> or reasoning is required. I just don't want the bulk of folks who are >> content to be >> >> overlooked by those suggesting change. >> >> >> >> IF you prefer or can accept the current status, but think there should be >> an IANA registry >> >> as is usual for managing code-points, please say so. No more >> justification is needed. >> >> >> >> IF you prefer Option B, C, and/or D, please say so with your >> explanation. More technical depth than "'we might need it" would be >> helpful; the availability of sub-TLVs already >> >> provides future proofing. >> >> >> >> IF you have a clear technical objection to why the Current Status is not >> acceptable, >> >> please express that - with clear details. >> >> >> >> IF you feel that additional code-points should be allocated in a BAR IANA >> Registry or >> >> have thoughts on the appropriate policy, please say so with your >> explanation for what >> >> those should be. >> >> >> >> Unless I see clear and strong consensus for something other than the >> Current Status, >> >> that will remain. >> >> >> >> IF there is clear and strong consensus for Option B, C, or D, or adding >> an IANA registry with particular values, then it will be possible to have a >> change up through this Weds night - with a 1 week WGLC on that particular >> technical change. >> >> >> >> My priority is to have the base BIER specifications published as Proposed >> Standards so that more BIER implementations and deployment can be done. I >> would like the WG to wrap up the core work (as expressed in the proposed >> recharter) so that you all can look >> >> at how to use it. >> >> >> >> Given this topic was raised last Weds and given that there are no >> technical objections raised to the documents as are, there isn't much time >> - so please just respond to this email ASAP. My deadline for a decision is >> 6pm EST on Weds. >> >> >> >> Regards, >> >> Alia >> >> >> > > _______________________________________________ > BIER mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bier > > --f403045c7fa8b48d730565a69873 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">all the implementations I am aware off can adjust to Optio= n A) with BAR registry without problems, neither do I see a problem with op= tion B) given we are talking only 0/0 being in IGP RFC @ this point in time= . thanks. tony <br></div><div class=3D"gmail_extra"><br><div class=3D"gmail= _quote">On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas <span dir=3D"ltr"><<= a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>= ></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">I ha= ve one additional question for those with implementations or testing them.<= div dir=3D"auto"><br></div><div dir=3D"auto">What is the impact of going wi= th your preferred option in terms of interoperability?=C2=A0 It may be earl= y enough that changes can happen, but more feedback is needed.</div><div di= r=3D"auto"><br></div><div dir=3D"auto">For those favoring Option B, could y= ou send email to the list providing exact text so we have the details?</div= ><div dir=3D"auto"><br></div><div dir=3D"auto">For those favoring the curre= nt status without an IANA registry, are you able to handle one being impose= d during IESG Review?=C2=A0 It is an obvious concern to raise.=C2=A0 Are yo= u just prolonging or postponing the discussion?</div><div dir=3D"auto"><br>= </div><div dir=3D"auto">Regards,</div><div dir=3D"auto">Aka</div><div dir= =3D"auto"><br></div><div dir=3D"auto"><br></div></div><div class=3D"HOEnZb"= ><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote= ">On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" <<a href=3D"mai= lto:[email protected]" target=3D"_blank">senthil.dhanaraj@huawei.= com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div link=3D"#0563C1" vlink=3D"#954F72" lang=3D"EN-US"> <div class=3D"m_166906979626783871m_-5649539534793705773WordSection1"> <p class=3D"MsoNormal">+1 to Option-B<u></u><u></u></p> <p class=3D"MsoNormal">Seems future proof to me.<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal">Thanks,<u></u><u></u></p> <p class=3D"MsoNormal">Senthil<span style=3D"font-size:11.0pt;font-family:&= quot;Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1f497d"><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:#1f497d"><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:#1f497d"><u></u>=C2=A0<u></u></span></p> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri",sans-serif">From:</span></b><span style=3D"font-size:11.0pt;= font-family:"Calibri",sans-serif"> BIER [mailto:<a href=3D"mailto= :[email protected]" target=3D"_blank">[email protected]</a>] <b>On Behalf Of </b>Alia Atlas<br> <b>Sent:</b> 20 February 2018 03:21<br> <b>To:</b> BIER WG <<a href=3D"mailto:[email protected]" target=3D"_blank">b= [email protected]</a>>; <a href=3D"mailto:[email protected]" target=3D"_blank"= >[email protected]</a> list <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>><br> <b>Subject:</b> [Bier] BAR field length in draft-ietf-bier-isis-extension<w= br>s and draft-ietf-bier-ospf-extension<wbr>s<u></u><u></u></span></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <div> <div> <div> <div> <p class=3D"MsoNormal">As the Sponsoring AD for draft-ietf-bier-isis-extens= ion<wbr>s-07 and draft-ietf-bier-ospf-extension<wbr>s-12, I have been follo= wing the discussion on the mailing list with interest.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">I have not seen clear consensus for any change.<u></= u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">Let me be clear on what I see the options are from t= he discussion.=C2=A0 Then I'll elaborate<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">a bit on how you can express your perspective most u= sefully.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">1) Current Status:=C2=A0 Bier Algorithm (BAR) field = is 8 bits.=C2=A0 Currently, only value 0 is specified.=C2=A0 The drafts do = not have an IANA registry - with the expectation that one will be created w= hen the first additional use is clear.=C2=A0 It is possible that there will be objections from the IESG to progressing without an IANA= registry.=C2=A0 Given the lack of clarity for future use-cases and after d= iscussion, I decided not to force one after my AD review - but I will not p= ush back against having a BIER IANA registry if raised by others.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">2) Option B:=C2=A0 Add a BAR sub-type of 8 bits.=C2= =A0 This would modify the current TLVs.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">=C2=A0 =C2=A0Define an IANA registry for the BAR typ= e.=C2=A0 The meaning of the BAR sub-type derives=C2=A0<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">=C2=A0 =C2=A0from the BAR type.=C2=A0 =C2=A0We can d= ebate over the registration policy for the BAR type.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">3) Option C: Change the BAR field to be 16 bits and = define an IANA registry.=C2=A0 Part of the range can be FCFS with Expert Re= view, part can be Specification Required, and part can be IETF Consensus.<u= ></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">4) Option D: At some point in the future, if there i= s an actual understood and documented need, a BAR sub-type could be added a= sub-TLV.=C2=A0 The length of the BAR sub-type could be determined when the= sub-TLV is defined.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">Given<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">=C2=A0 a) option D exists=C2=A0<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">=C2=A0 b) there is currently only one defined value = for BAR<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">=C2=A0 c) I do not see strong consensus for change t= o one particular other option<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">I see no current reason for a change and I certainly= see absolutely no reason for<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">a delay in progressing the documents.<u></u><u></u><= /p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">I do want to be clear about what the WG wants to do = on this issue.=C2=A0 Therefore, here is<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">my following request.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">Please send your feedback to the mailing list as fol= lows:<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">IF you prefer or can accept the current status, plea= se say so.=C2=A0 No more justification<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">or reasoning is required. I just don't want the = bulk of folks who are content to be<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">overlooked by those suggesting change.<u></u><u></u>= </p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">IF you prefer or can accept the current status, but = think there should be an IANA registry<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">as is usual for managing code-points, please say so.= =C2=A0 No more justification is needed.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">IF you prefer Option B, C, and/or D, please say so w= ith your explanation.=C2=A0 More technical depth than "'we might n= eed it" would be helpful; the availability of sub-TLVs already<u></u><= u></u></p> </div> <div> <p class=3D"MsoNormal">provides future proofing.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">IF you have a clear technical objection to why the C= urrent Status is not acceptable,<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">please express that - with clear details.<u></u><u><= /u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">IF you feel that additional code-points should be al= located in a BAR IANA Registry or<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">have thoughts on the appropriate policy, please say = so with your explanation for what<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">those should be.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">Unless I see clear and strong consensus for somethin= g other than the Current Status,<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">that will remain.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">IF there is clear and strong consensus for Option B,= C, or D, or adding an IANA registry with particular values, then it will b= e possible to have a change up through this Weds night - with a 1 week WGLC= on that particular technical change.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">My priority is to have the base BIER specifications = published as Proposed Standards so that more BIER implementations and deplo= yment can be done.=C2=A0 I would like the WG to wrap up the core work (as e= xpressed in the proposed recharter) so that you all can look<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">at how to use it.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">Given this topic was raised last Weds and given that= there are no technical objections raised to the documents as are, there is= n't much time - so please just respond to this email ASAP.=C2=A0 My dea= dline for a decision is 6pm EST on Weds.<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">Regards,<u></u><u></u></p> </div> <div> <p class=3D"MsoNormal">Alia<u></u><u></u></p> </div> </div> </div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> </div> </div> </blockquote></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> --f403045c7fa8b48d730565a69873-- --===============2539115662610804248== 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 --===============2539115662610804248==--