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

[IJsbrand Wijnands <[e-mail]>]

Tony,

> 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).

My first observation is that what is documented here as “BIER Algorithm Registry” is not an Algorithm, but a constraint. Suppose you want to build a topology with {BIER-ONLY, LOWEST-DELAY, BW}. From an architecture POV, any combination should be allowed. Would you propose to create BAR values to capture every possible combination? I don’t think that scales very well. Constraints would be better served with a BitMask IMO.

Thx,

Ice.

>  
> 
>  
> 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 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier