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

[IJsbrand Wijnands <[e-mail]>]

Tony,

> Now, what BAR registry would give us is a "layering of constraints" if you want, i.e.  BAR=1 (since this is a very tanglible example, another one would be max. degree of fanout or things like max-label-depth e.g.)  would take care of the BIER specific constraints without IGP knowing about it in architectural terms.  On top of that IGP applies its constraints (BW, delay, whatever) but it's really not  BIER problem, we are just happy riders on coattails of the hard IGP work ;-) 

If you want to build a table for BIER, you need to have a way to associate/signal the different constraints that need to be used. In my mind, this is not coming from the IGP, but needs to be signalled in the context BIER. Like how you signal BIER-ONLY as algorithm. Or, statically configured as part of the Sub-Domain. Obviously what is required here is a architecture draft that explains how this all should work.

> 
> To address the "efficienty" constraint one has to be very deeply steeped into IGP SPF computations but the result is that an implementation can easily incorporate constraints of all layers into a single computation (SPF practically speaking) unless they lead to NP complete combinations (so .e.g. having something that is max-bw @ guaranteed delay is far from simple) ... 
> 
> So let's say we put the IGP signalling under a new cool IGP  (eeeh, I'm building one ;-)  and we do not want to shake their whole IGP standard saying "hey, you know, we have this BIER Stuff you must encode on your IGP elements (beside us being a subTLV) and put in your registries to do the right thing", if we have BAR we can just tell them, ok, encoding wise, jsut give us your SPF-on-steroids registry and we use that as subtype, underneath that we plug in BAR in our encoding, i.e. we just use them as signalling channel while constraining the SPF. We're done.  Obviously the SPF has to be modified to respect the union of all constraints but the alternative is worse, i.e. I have to be running multiple passes prunning things (which are practically far less desirable since we are loosing very cool stuff like LFA which I'm sure we could solve as well but get for free if we just prune the SPF @ runtime) 
> 
> I do hope that parses and I  make sense. I tried to be as terse as I managed and I know I am bad at that … 

You lost me, sorry…

Thx,

Ice.

> 
> Now, whether you believe that IGP signalling must be used for IGP dictated unicast computations only and IGP must be aware of BIER elements in its registries/encoding is a matter of taste to a degree (architecture of protocols is as much craft as art) but as to technial advantages of that I see none while I see unnecessary coupling ...
> 
> --- tony 
>