Tony, Yes - spot on.
It is like either selecting ingredients to "make your own pizza" vs ordering a fixed one (Pepperoni, Margarita, 4 cheese, style #135 etc...) All I am saying is that both options are useful. And it seems defining few most useful flex-algos may be helpful. Call it well known flex-algos. I am questioning enforcement saying you must always select all pieces yourself. If most useful ones are going to be done under IETF umbrella or outside of it time will tell. And btw I do agree on the limited number of those code points ... Well - maybe one octet is not enough ? Kind regards, Robert. On Fri, Sep 17, 2021 at 12:48 AM Tony Li <[email protected]> wrote: > > Robert, > > > What harm would it make if someone writes a draft, defines a useful flex > algo on which (the usefulness the LSR WG agrees) say using max propagation > delay across hops as as a metric and allocates IANA type 135 for it ? > > > I’m inferring that you are suggesting that we take a code point from the > IANA IGP Algorithm Types registry. There are only 256 of those, so they > are quite precious. 135 has already been allocated to FlexAlgo for local > use. Values 2-127 are currently unassigned. > > The exact same semantics could be achieved by using a local algorithm > value and then specifying the Min Unidirectional Link Delay as the Metric > Type in the FlexAlgo Definition. > > > > That is what I have a hard time to understand the objections for. > > > You burn a precious code point and have made the problem worse. Now, you > need to ensure that not only do all of your implementations support min > delay, but now they also must know about the statically defined code > point. That lowers interoperability, not improves it. > > And once we head down this slippery slope, everyone and their uncle will > ask for a code point for their favorite particular combinations of FAD > parameters. 125 values will not go very far in encoding a rich constraint > space. > > Regards, > Tony > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
