Les, To me what corresponds to network application is effectively a forwarding paradigm/topology build and used to forward corresponding traffic classe. You can overload application name the way you like but it does not change anything.
So if this is going to make you more happy let's rename my example accordingly and let's not get hang out on flex-algo name itself. Example: link attribute: delay applications: app_1 - build topology using SPF_algo_1 where max delay does not exceed 10 ms - color: premium best effort app_2 - build topology using SPF_algo_2 where max delay does not exceed 8 ms - color: black app_3 - build topology using SPF_algo_3 where max delay does not exceed 6 ms - color: bronze app_4 - build topology using SPF_algo_4 where max delay does not exceed 4 ms - color: blue app_5 - build topology using SPF_algo_5 where max delay does not exceed 3 ms - color: silver app_6 - build topology using SPF_algo_6 where max delay does not exceed 1 ms - color: gold etc ... Now tell me how does it make sense to enable each app on the link delay attribute ? Thx, R. On Sat, Mar 26, 2022 at 4:56 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > I changed the subject – because what you are talking about has nothing to > do w the discussion of ANY bit. > > > > You have mentioned this before – and been corrected before – but it seems > that did not alter your thinking. > > > > Flex-Algo is ONE APP. > > There is not a bit in the SABM assigned per algo – nor is there any intent > to do so. > > Nor does ANY bit introduce the notion of one bit per algo. > > > > All link attributes advertised with the Flex-Algo (X-bit) in the SABM are > usable by any algo. Same would be true if you used ALL encoding. Same would > be true if you used ANY encoding. > > Which ones are used and how they are used (e.g., which affinity bits apply > to a given algorithm) is determined by the Algorithm Specific FAD. > > > > Either you don’t understand Flex-Algo – or you do understand it and want > to do a major rewrite of it – I am not sure which. > > But either way, none of this has anything to do with the original thread. > > > > Les > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Saturday, March 26, 2022 3:43 AM > *To:* Christian Hopps <cho...@chopps.org> > *Cc:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Shraddha Hegde < > shrad...@juniper.net>; Martin Horneffer <m...@lab.dtag.de>; lsr < > lsr@ietf.org> > *Subject:* Re: [Lsr] IETF13: Comments on The Application Specific Link > Attribute (ASLA) Any Application Bit > > > > 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 <cho...@chopps.org> wrote: > > > Robert Raszuk <rob...@raszuk.net> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
