> 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) ...
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
