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

[Tony Przygienda <[e-mail]>]

> Les’s response to Andrew’s comments are spot on. Over the weekend we tried
> to converge over a 16 bit BAR, and how it would look like. We where not
> able to converge on the semantics, especially related to option B and
> the “BAR sub-type”. Its opening an other can of worms and will cause new
> discussion over the BIER architecture in the future. I know, not your
> problem.
>
>
And would you care to explain in plain technical terms HOW the option B)
will cause problems specifically?  Allocating a BAR type will put the
sub-type (or whatever we call it) under full disposition of the allocator
of the value who can use it as it fits the problem they are out to solve.
You need under your BAR value an IGP registry, go ahead, you want some
flex-algo, feel free, you need some indication of e.g. hash value to
tie-break multiple possible computations, works for you ...  Same can be
achieved with sub-TLVs but as I explained in less backwards compatible
fashion. IETF must have been doing something very wrong in the last 20
years to have registries in place so resolving this mysterious unseen
problems could benefit us all ...

It seems to me like putting BIER BAR type under a clear, well managed
registry is actually the way to close this most interesting 6 months where
no'one had a particular idea where things were supposed to be steered until
things came to head and we finally talk openly about the probably
well-meant intentions (while still being very thin on truly technical
arguments of those intentions I observe) ...