Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Alia Atlas <[email protected]> Tue, 20 Feb 2018 13:39:23 -0500
| Newsgroups | gmane.ietf.isis |
|---|---|
| Message-ID | <CAG4d1rdgeQKkRVTaietcwE+1dALFYwOyVq2XXHWnEwDaZ3gsxA__40414.0879902572$1519151851$gmane$org@mail.gmail.com> |
--===============4549247642745596541== Content-Type: multipart/alternative; boundary="001a113d53843266e60565a92142" --001a113d53843266e60565a92142 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 i= s > 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 (ppsena= k)" < > [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 in > 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 doe= s > its own topology related computations, independent of IGPs. If they d= o, > 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. Currentl= y, > > 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 th= e > > IESG to progressing without an IANA registry. Given the lack of > clarity > > for future use-cases and after discussion, I decided not to force o= ne > > 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 B= AR > > 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 t= he > > 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 a= re > > 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 b= e > > helpful; the availability of sub-TLVs already > > provides future proofing. > > > > IF you have a clear technical objection to why the Current Status i= s > not > > acceptable, > > please express that - with clear details. > > > > IF you feel that additional code-points should be allocated in a BA= R > > 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 th= e > > 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 t= o > > have a change up through this Weds night - with a 1 week WGLC on th= at > > 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 expresse= d > 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 mu= ch > > 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 > > > --001a113d53843266e60565a92142 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div 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>R= egards,</div><div>Alia</div><div><br><div class=3D"gmail_extra"><br><div cl= ass=3D"gmail_quote">On Tue, Feb 20, 2018 at 1:36 PM, Acee Lindem (acee) <sp= an dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">acee= @cisco.com</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"HOEnZb"><div class=3D"h5"><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]">isis-wg-bounces= @ietf.org</a> on behalf of <a href=3D"mailto:[email protected]">ppsenak@cis= co.com</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-<wbr>exten= sions-07 and<br> =C2=A0 =C2=A0 > draft-ietf-bier-ospf-<wbr>extensions-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]">[email protected]</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/<wbr>listi= nfo/bier</a><br> =C2=A0 =C2=A0 ><br> <br> </div></div><div class=3D"HOEnZb"><div class=3D"h5">=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]">[email protected]</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/<wbr>listinf= o/isis-wg</a><br> <br> <br> </div></div></blockquote></div><br></div></div></div> --001a113d53843266e60565a92142-- --===============4549247642745596541== 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 --===============4549247642745596541==--