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 <akat...@gmail.com> 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" <senthil.dhana...@huawei.com> > wrote: > >> +1 to Option-B >> >> Seems future proof to me. >> >> >> >> Thanks, >> >> Senthil >> >> >> >> >> >> >> >> *From:* BIER [mailto:bier-boun...@ietf.org] *On Behalf Of *Alia Atlas >> *Sent:* 20 February 2018 03:21 >> *To:* BIER WG <b...@ietf.org>; isis-wg@ietf.org list <isis-wg@ietf.org> >> *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 > b...@ietf.org > https://www.ietf.org/mailman/listinfo/bier > >
_______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
