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

[Tony Przygienda <[e-mail]>]

>
> From an architectural view, the idea of having the IGP/routing layer have
> to understand
> BIER specifics seems an undesirable coupling.
>

very much so, in stark terms one could say that IGP is BIER signalling
while the fact that we use SPF to perform BIER nexthop calculations is a
convenient first artifact. The architecture RFC does not separate that
clearly IMO but is rather an "example" of practical BIER architecture
embodiment ;-) I do absolutely prefer it that way from practical
standpoint, abstract architectures with all degrees of flexibility written
first are hard to understand and slow to build. BIER delivered on a real
problem but after this first delivery needs the flexibility to spread its
wings into fields where IGP unicast may not be enough IMO and in any case,
IGP unicast computation coupling to BIER specific elements is unnecessary
and undesirable unless one believes e'thing is better off centralized. It
would be _highly_ unfortunate and immense waste of resources if we ended up
building another signalling just so we can perform non unicast IGP
computations.

Could someone walk me through how this would be supported in each of the
> different options?
>
> For Option D, where there is a sub-TLV and that sub-TLV can supply the
> additional non-BIER
> constraints, I understand it.
>
> For Option B - which some folks are preferring, I do not see understand
> how it would work.
>

BAR = 0 SPF, subtype can be FlexAlgo, any other IGP metric or constraint or
even an IGP registry value, this is a unicast computation
BAR = 1 SPF without BIER routers, subtype can be FlexAlgo, any other IGP
metric or constraint specification, this is a unicast computation
BAR = X (some unicast computation type)  same as 0/1

BAR = Y (multicast specific computation that IGP cnanot perform), subtype
can be anything

What is important to observe that SPF with additional constraints is as
efficient as SPF without those constraints (as long we're talking certain
convex properties AFAIR but I don't want to bore anyone with math, most of
the stuff we use today like max. BW, min. delay has this property).



> For Option A, I do not understand how it would work.
>

replace subtype with a sub-TLV so it's basically option D). I explained in
my +1/+2 my reasoning why option B) is more preferrable if you are
concerned about backwards compatibility but it's nothing architecturally
important. IGPs were muddling for years without clear distinction between
mandatory/optional TLVs are IDR has and we lived to tell the tale ;-) ...


>
> Obviously, this is going far out on a design limb - where flex-algo does
> not yet have any IETF
> support or adoption, but since it is clear that people's perspectives are
> being strongly influenced
> by what that might morph into, I think this is important for the whole WG
> to understand.
>
>
 AFAIU we have BIER RFCs that form a solid foundation to deliver now.
Things to be done in the future can obviously morph into many directions
and claim to cover any problem presented to them without much risk ...

thanks

--- tony