Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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.
> 
> 
>