>
> 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.
>
>
Ice, I assume we talk the unicast computation case. Let's discuss that in
architectural terms that easily map down to the case on hand IMO:
When faced with a combinatorial problem that you mention (often caused by
coupling of many things to each other) a good approach is layering (or
think about it as indirection), i.e. the layers become decoupled and can be
developed/progressed independently. Problem with decoupling is that it
often is inefficient (indirections).
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 ;-)
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 ...
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
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
