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) <a...@cisco.com> 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 > > On 2/20/18, 12:28 PM, "Isis-wg on behalf of Peter Psenak (ppsenak)" < > isis-wg-boun...@ietf.org on behalf of ppse...@cisco.com> 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 does > 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 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 > > >
_______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
