All I support Shraddha’s Any bit draft as I think of the change as am optimization of existing ASLA RFC 8918 and 8919 taking into account practical deployment considerations when the application specific attribute differs and having to set the SABM / UDABM bit mask on every link on the network.
The focus of RFC 8918 and 8919 is to solve the issue where the application attribute is different and that is solved with the existing specification. The zero length bit mask only helps if all the applications use the same link attribute. However, now if the link attribute is different for each application, now you have to set the SABM/UDAM bit mask on every link on the network. So I do see that adds operational complexity. I do have a concern about interoperability for devices supporting ASLA and those supporting the Any bit. So now if two applications have different attributes would they set the RFC 8918 and 8919 SADM/UDAM bit for the particular application as well as the new any bit or would they now just set the any bit. This is the case where the application link attribute differs and so need to be advertised as ASLA. I see section 4 talks about backwards compatibility but I would think to conform with ASLA the SADM/UDAM application specific but still would need to be set with the use of Any bit. I would think that would still be necessary to disambiguate the application using the link which was the main goal of ASLA. As for existing ASLA deployment considerations I think BGP-LS extension for ASLA draft below would help with PCE centralized controller push of the ASLA as part of the stateful PCE operation in mix environments with many applications. https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-app-specific-attr-08 Kind Regards Gyan On Fri, Apr 8, 2022 at 8:03 AM Christian Hopps <cho...@chopps.org> wrote: > > Robert Raszuk <rob...@raszuk.net> writes: > > > 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. > > This is purely user interface code, you can do this w/o changing the on > the wire standard encoding. > > Thanks, > Chris. > [as wg-member] > > > 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 > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
