Hi Chris, It seems that there is a subtle but important element on which we may have different opinion.
You said: "has to deploy new software that contains the new Wizbang feature, right?" IMO however we are dealing with case where software already supports all required functions on a box. It is just not using it from day one. You buy a router with OS features which allow you to build zoo of different forwarding paradigms. Say day one you see a need to enable flex-algo_1 You enable day one links to distribute link attributes required for this. Day two you want to define new FAD and flood this enabling new flex-algo_2. You reuse already present link attributes entirely or partially in flex-algo_2 computation. You do not need to touch 100000s of links each time you enable new flex_algo. That's a selling point to me. If we would expect that folks will limit flex-algo to just a few maybe this all does not matter. But if we see proposals with rainbow of colors each mapped to different flex-algo and perhaps subtle forwarding difference (same metric but just a different min threshold per each flex-algo) it seems pretty bad idea to explicitly enable each app each time such new threshold used to build different topology. Example: link attribute: delay applications: flex-algo_1 - build topology where max delay does not exceed 10 ms - color: premium best effort flex-algo_2 - build topology where max delay does not exceed 8 ms - color: black flex-algo_3 - build topology where max delay does not exceed 6 ms - color: bronze flex-algo_4 - build topology where max delay does not exceed 4 ms - color: blue flex-algo_5 - build topology where max delay does not exceed 3 ms - color: silver flex-algo_6 - build topology where max delay does not exceed 3 ms - color: gold etc ... Now tell me how does it make sense to enable each app on the link delay attribute ? Cheers, Robert On Sat, Mar 26, 2022 at 6:42 AM Christian Hopps <[email protected]> wrote: > > Robert Raszuk <[email protected]> writes: > > > Les, > > > > I don't think this is noise. > > > > Your examples are missing key operational consideration .. Link > > attribute applicable to ANY application may be advertised well ahead > > of enabling such application in a network. > > > > So requesting operator to always advertise tuple of app + attr is not > > looking forward and makes unnecessary operational burden. > > [as wg-member] > > Hi Robert, > > Originally this was the argument that sort of put wind in the sails (for > me) for this any bit, but some more thinking about how things would really > work changed my mind. > > In order for some new feature, let's call it Wizbang, to take advantage of > existing any bit marked attributes, the operator still has to deploy new > software that contains the new Wizbang feature, right? So the addition of a > new Wizbang bit pretty much comes free for the operator. > > So, this draft really is just about making the encoding a bit more > efficient. > > I think if we were defining a new encoding, having this functionality > makes sense, but we aren't defining a new encoding. The proposal is to > change an existing published encoding, and the bar has to be higher for > that I think. > > Thanks, > Chris. > [as wg member] > > > > > > Thx. > > R. > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
