Hi Peter, Thanks very much for the feedback.
On Tue, Feb 20, 2018 at 12:27 PM, Peter Psenak <[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. > Makes sense. > 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. > That is what I'm hearing as a requirement. The encoding of the BAR though must be done in a way that it easily > supports both (1) and (2). > There's the rub :-) The challenge seems to be when there are BIER-specific constraints and also other more generic constraints. Regards, Alia 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/bier >> >> >
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
