Hi Ice, I appreciate that you have finally decided to discuss this on the BIER mailing list.
I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00 and draft-hegdeppsenak-isis-sr-flex-algo-02. I see a bit of discussion on the is-is mailing list and at IETF 100, but, of course, no WG adoption. I see BIER as a fundamental technology that can be used in different situations. For instance, there is not merely discussion of how Babel and BIER could interact - but actual code (thanks Sandy!); of course, that is not a WG-adopted draft yet either, so this is merely a thought experiment example. How do the different algorithms work for an IGP that isn't link-state? What about the ideas around using BIER with caches? Are there issues there? What about algorithms that make sense for BIER or multicast - but not for unicast? IANA registries are not price prohibitive. Why would we tie BIER to the link-state IGP registry? I do not hear you making a technical argument. Regards, Alia On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands <[email protected]> wrote: > Hi Alia, > > There is one more option that I think is not fully covered from the choice > of options related to getting a registry. > > The topic of the discussion is what information we need to pass in the IGP > in order for BIER to select the correct underlay. What identifies the > underlay is really what ever information is needed to select the Table > (MT-ID) and Algorithm. An example of Algorithm work that is going on is > Flex-Algo. My preferred option is to align with what ever the IGPs are > using to identify the Algorithm. > > Option E: Change BAR into “IGP Algorithm” registry as documented in > https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp- > algorithm-types > > Thx, > > Ice. > > On 19 Feb 2018, at 13:51, Alia Atlas <[email protected]> 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
