On Tue, Feb 20, 2018 at 10:25 AM, IJsbrand Wijnands <i...@cisco.com> wrote:
> 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. > yes, staticially configured BIER computaton constraints could work but then routers cannot detect mismatch. A very heavy disadvantage ... Architecture is something we can talk in London if you see value in that, sure. For the record, I however vastly prefered the direction (mainly) you/Eric gave from start on which was "enough architecture to get important first application done", hence I was never pushing some some grand cathedral building scheme. Maybe after this is in place we should have this in London, it's the call of the day one core group that carried the banner where there was nothing but first hill to take ;-) My suggestion is, let us work out either option B) or Eric's proposal as flexible and orthogonal scheme to ground the IGPs and then fall out the rest over it ... As you observed, I'm big believer in maybe overbuilding a tad in flexibility or size in control plane to have architectural wiggle room while in forwarding path one has to be extremely frugal to get the silicon @ cost ... > > > > > 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… > sorry, email is limited ... Not sure how to deal with that ... --- tony
_______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
