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 10:40:21 -0800
| Newsgroups | gmane.ietf.isis |
|---|---|
| Message-ID | <CA+wi2hPGOwfQoZtqut-ektyey3Whg3bpnytFZLHGyxNFvHjfOw__5593.29031170837$1519151968$gmane$org@mail.gmail.com> |
--===============3552551411181278868== Content-Type: multipart/alternative; boundary="089e082f6a44fe0c4b0565a92625" --089e082f6a44fe0c4b0565a92625 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 obviously ... On Tue, Feb 20, 2018 at 10:39 AM, Alia Atlas <[email protected]> wrote: > Hi Acee, > > Thanks for your feedback. I appreciate and agree with the perspective. > > Regards, > Alia > > > On Tue, Feb 20, 2018 at 1:36 PM, Acee Lindem (acee) <[email protected]> > wrote: > >> Hi Alia, >> I support Peter's position on the draft. While I believe at 8 bit space >> is more than enough to support variations of the BIER algorithm for the >> foreseeable future, I think reaching consensus is more critical than the >> precise encoding. >> >> Thanks, >> Acee >> >> =EF=BB=BFOn 2/20/18, 12:28 PM, "Isis-wg on behalf of Peter Psenak (ppsen= ak)" < >> [email protected] on behalf of [email protected]> wrote: >> >> Hi Alia, >> >> 1. I see a benefit in having the BIER a way to map to any of the IGP >> algorithms. Simply because IGPs already provide paths to all nodes i= n >> the domain and BIER can simply use these paths instead of computing >> its own. >> >> 2. Not sure if people plan to deploy the BIER in a model where it do= es >> its own topology related computations, independent of IGPs. If they >> do, >> I'm not objecting that. >> >> The encoding of the BAR though must be done in a way that it easily >> supports both (1) and (2). >> >> my 2c, >> Peter >> >> >> >> On 19/02/18 22:51 , Alia Atlas wrote: >> > 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 registr= y >> - >> > with the expectation that one will be created when the first >> additional >> > use is clear. It is possible that there will be objections from t= he >> > 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 BIE= R >> 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 polic= y >> 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 absolutel= y >> 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 B= AR >> > 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 t= he >> > 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 deploymen= t >> 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 >> > >> >> _______________________________________________ >> Isis-wg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/isis-wg >> >> >> > > _______________________________________________ > Isis-wg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/isis-wg > > --089e082f6a44fe0c4b0565a92625 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">+1 obviously ... <br></div><div class=3D"gmail_extra"><br>= <div class=3D"gmail_quote">On Tue, Feb 20, 2018 at 10:39 AM, Alia Atlas <sp= an dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">a= [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"><d= iv dir=3D"ltr">Hi Acee,<div><br></div><div>Thanks for your feedback.=C2=A0 = I appreciate and agree with the perspective.</div><div><br></div><div>Regar= ds,</div><div>Alia</div><div><div class=3D"h5"><div><br><div class=3D"gmail= _extra"><br><div class=3D"gmail_quote">On Tue, Feb 20, 2018 at 1:36 PM, Ace= e Lindem (acee) <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" tar= get=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">Hi Alia,<br> I support Peter's position on the draft. While I believe at 8 bit space= is more than enough to support=C2=A0 variations of the BIER algorithm for = the foreseeable future, I think reaching consensus is more critical than th= e precise encoding.<br> <br> Thanks,<br> Acee<br> <div class=3D"m_-5529016344999748452HOEnZb"><div class=3D"m_-55290163449997= 48452h5"><br> =EF=BB=BFOn 2/20/18, 12:28 PM, "Isis-wg on behalf of Peter Psenak (pps= enak)" <<a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a> on behalf of <a href=3D"mailto:ppsenak@cisc= o.com" target=3D"_blank">[email protected]</a>> wrote:<br> <br> =C2=A0 =C2=A0 Hi Alia,<br> <br> =C2=A0 =C2=A0 1. I see a benefit in having the BIER a way to map to any of = the IGP<br> =C2=A0 =C2=A0 algorithms. Simply because IGPs already provide paths to all = nodes in<br> =C2=A0 =C2=A0 the domain and BIER can simply use these paths instead of com= puting its own.<br> <br> =C2=A0 =C2=A0 2. Not sure if people plan to deploy the BIER in a model wher= e it does<br> =C2=A0 =C2=A0 its own topology related computations, independent of IGPs. I= f they do,<br> =C2=A0 =C2=A0 I'm not objecting that.<br> <br> =C2=A0 =C2=A0 The encoding of the BAR though must be done in a way that it = easily<br> =C2=A0 =C2=A0 supports both (1) and (2).<br> <br> =C2=A0 =C2=A0 my 2c,<br> =C2=A0 =C2=A0 Peter<br> <br> <br> <br> =C2=A0 =C2=A0 On 19/02/18 22:51 , Alia Atlas wrote:<br> =C2=A0 =C2=A0 > As the Sponsoring AD for draft-ietf-bier-isis-extension<= wbr>s-07 and<br> =C2=A0 =C2=A0 > draft-ietf-bier-ospf-extension<wbr>s-12, I have been fol= lowing the discussion<br> =C2=A0 =C2=A0 > on the mailing list with interest.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > I have not seen clear consensus for any change.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > Let me be clear on what I see the options are from the d= iscussion.=C2=A0 Then<br> =C2=A0 =C2=A0 > I'll elaborate<br> =C2=A0 =C2=A0 > a bit on how you can express your perspective most usefu= lly.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > 1) Current Status:=C2=A0 Bier Algorithm (BAR) field is 8= bits.=C2=A0 Currently,<br> =C2=A0 =C2=A0 > only value 0 is specified.=C2=A0 The drafts do not have = an IANA registry -<br> =C2=A0 =C2=A0 > with the expectation that one will be created when the f= irst additional<br> =C2=A0 =C2=A0 > use is clear.=C2=A0 It is possible that there will be ob= jections from the<br> =C2=A0 =C2=A0 > IESG to progressing without an IANA registry.=C2=A0 Give= n the lack of clarity<br> =C2=A0 =C2=A0 > for future use-cases and after discussion, I decided not= to force one<br> =C2=A0 =C2=A0 > after my AD review - but I will not push back against ha= ving a BIER IANA<br> =C2=A0 =C2=A0 > registry if raised by others.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > 2) Option B:=C2=A0 Add a BAR sub-type of 8 bits.=C2=A0 T= his would modify the<br> =C2=A0 =C2=A0 > current TLVs.<br> =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Define an IANA registry for the BAR t= ype.=C2=A0 The meaning of the BAR<br> =C2=A0 =C2=A0 > sub-type derives<br> =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0from the BAR type.=C2=A0 =C2=A0We can= debate over the registration policy for<br> =C2=A0 =C2=A0 > the BAR type.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > 3) Option C: Change the BAR field to be 16 bits and defi= ne an IANA<br> =C2=A0 =C2=A0 > registry.=C2=A0 Part of the range can be FCFS with Exper= t Review, part can be<br> =C2=A0 =C2=A0 > Specification Required, and part can be IETF Consensus.<= br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > 4) Option D: At some point in the future, if there is an= actual<br> =C2=A0 =C2=A0 > understood and documented need, a BAR sub-type could be = added a<br> =C2=A0 =C2=A0 > sub-TLV.=C2=A0 The length of the BAR sub-type could be d= etermined when the<br> =C2=A0 =C2=A0 > sub-TLV is defined.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > Given<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 >=C2=A0 =C2=A0 a) option D exists<br> =C2=A0 =C2=A0 >=C2=A0 =C2=A0 b) there is currently only one defined valu= e for BAR<br> =C2=A0 =C2=A0 >=C2=A0 =C2=A0 c) I do not see strong consensus for change= to one particular other<br> =C2=A0 =C2=A0 > option<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > I see no current reason for a change and I certainly see= absolutely no<br> =C2=A0 =C2=A0 > reason for<br> =C2=A0 =C2=A0 > a delay in progressing the documents.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > I do want to be clear about what the WG wants to do on t= his issue.<br> =C2=A0 =C2=A0 > Therefore, here is<br> =C2=A0 =C2=A0 > my following request.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > Please send your feedback to the mailing list as follows= :<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > IF you prefer or can accept the current status, please s= ay so.=C2=A0 No more<br> =C2=A0 =C2=A0 > justification<br> =C2=A0 =C2=A0 > or reasoning is required. I just don't want the bulk= of folks who are<br> =C2=A0 =C2=A0 > content to be<br> =C2=A0 =C2=A0 > overlooked by those suggesting change.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > IF you prefer or can accept the current status, but thin= k there should<br> =C2=A0 =C2=A0 > be an IANA registry<br> =C2=A0 =C2=A0 > as is usual for managing code-points, please say so.=C2= =A0 No more<br> =C2=A0 =C2=A0 > justification is needed.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > IF you prefer Option B, C, and/or D, please say so with = your<br> =C2=A0 =C2=A0 > explanation.=C2=A0 More technical depth than "'= we might need it" would be<br> =C2=A0 =C2=A0 > helpful; the availability of sub-TLVs already<br> =C2=A0 =C2=A0 > provides future proofing.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > IF you have a clear technical objection to why the Curre= nt Status is not<br> =C2=A0 =C2=A0 > acceptable,<br> =C2=A0 =C2=A0 > please express that - with clear details.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > IF you feel that additional code-points should be alloca= ted in a BAR<br> =C2=A0 =C2=A0 > IANA Registry or<br> =C2=A0 =C2=A0 > have thoughts on the appropriate policy, please say so w= ith your<br> =C2=A0 =C2=A0 > explanation for what<br> =C2=A0 =C2=A0 > those should be.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > Unless I see clear and strong consensus for something ot= her than the<br> =C2=A0 =C2=A0 > Current Status,<br> =C2=A0 =C2=A0 > that will remain.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > IF there is clear and strong consensus for Option B, C, = or D, or adding<br> =C2=A0 =C2=A0 > an IANA registry with particular values, then it will be= possible to<br> =C2=A0 =C2=A0 > have a change up through this Weds night - with a 1 week= WGLC on that<br> =C2=A0 =C2=A0 > particular technical change.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > My priority is to have the base BIER specifications publ= ished as<br> =C2=A0 =C2=A0 > Proposed Standards so that more BIER implementations and= deployment can<br> =C2=A0 =C2=A0 > be done.=C2=A0 I would like the WG to wrap up the core w= ork (as expressed in<br> =C2=A0 =C2=A0 > the proposed recharter) so that you all can look<br> =C2=A0 =C2=A0 > at how to use it.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > Given this topic was raised last Weds and given that the= re are no<br> =C2=A0 =C2=A0 > technical objections raised to the documents as are, the= re isn't much<br> =C2=A0 =C2=A0 > time - so please just respond to this email ASAP.=C2=A0 = My deadline for a<br> =C2=A0 =C2=A0 > decision is 6pm EST on Weds.<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > Regards,<br> =C2=A0 =C2=A0 > Alia<br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 ><br> =C2=A0 =C2=A0 > ______________________________<wbr>_________________<br> =C2=A0 =C2=A0 > BIER mailing list<br> =C2=A0 =C2=A0 > <a href=3D"mailto:[email protected]" target=3D"_blank">BIER@= ietf.org</a><br> =C2=A0 =C2=A0 > <a href=3D"https://www.ietf.org/mailman/listinfo/bier" r= el=3D"noreferrer" target=3D"_blank">https://www.ietf.org/mailman/l<wbr>isti= nfo/bier</a><br> =C2=A0 =C2=A0 ><br> <br> </div></div><div class=3D"m_-5529016344999748452HOEnZb"><div class=3D"m_-55= 29016344999748452h5">=C2=A0 =C2=A0 ______________________________<wbr>_____= ____________<br> =C2=A0 =C2=A0 Isis-wg mailing list<br> =C2=A0 =C2=A0 <a href=3D"mailto:[email protected]" target=3D"_blank">Isis-wg= @ietf.org</a><br> =C2=A0 =C2=A0 <a href=3D"https://www.ietf.org/mailman/listinfo/isis-wg" rel= =3D"noreferrer" target=3D"_blank">https://www.ietf.org/mailman/l<wbr>istinf= o/isis-wg</a><br> <br> <br> </div></div></blockquote></div><br></div></div></div></div></div> <br>______________________________<wbr>_________________<br> Isis-wg mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/isis-wg" rel=3D"noreferrer= " target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/isis-wg</a><= br> <br></blockquote></div><br></div> --089e082f6a44fe0c4b0565a92625-- --===============3552551411181278868== 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 --===============3552551411181278868==--