Alia, > I forgot to add - of course - that I understand you have already stated that > you don't have any technical objections to the current status.
That is true. Sticking with 8 bits BAR and not yet declare what is means is better than rushing into 16bit with a registry during LC. Thx, Ice. > > Regards, > Alia > > On Mon, Feb 19, 2018 at 8:58 PM, Alia Atlas <akat...@gmail.com> wrote: > Ice, > > At this point in the process, it would be necessary to make an overwhelming > technical argument - that would sway almost the whole > WG to your perspective. > > I see you saying that you have a personal preference for having the IGP > Algorithm registry also be used for the BAR registry. While > I do, of course, respect where you have technical expertise, my response - > particularly from a process perspective - is "that's nice". > > Regards, > Alia > > On Mon, Feb 19, 2018 at 8:15 PM, IJsbrand Wijnands <i...@cisco.com> wrote: > Alia, > > > An architectural argument can't also limit itself to the drafts in the > > title. > > > > If it sounded like the IANA registry was suggested as separate for BIER > > OSPF and BIER ISIS, then your attempt to reframe the conversation might be > > reasonable. Let me clarify - I see no current reason for an OSPF BAR > > registry and an ISIS BAR registry; it would just be a BAR registry. Perhaps > > that clarification is a good reason to get the IANA registry included in > > the next update? > > There is no reason for an individual BIER OSPF and BIER ISIS registry. The > point is to align with what ever ISIS and OSPF are using to identify the > algorithm. > > > The routing layer is separate from the BIER layer. The BAR is for the BIER > > layer. > > The underlay is separate from the BIER layer, and each underlay can carry > BIER specific information that is needed for for BIER to make the selection. > > Thx, > > Ice. > > >
_______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
