Gyan – With respect, your post has several misunderstandings/inaccurate statements. I hope you have read my earlier post: https://mailarchive.ietf.org/arch/msg/lsr/JuV6frOi7LD5ybsr2iPTCgTph2w/
Let me try to correct your statements – please see inline. From: Gyan Mishra <[email protected]> Sent: Wednesday, April 13, 2022 1:54 PM To: Christian Hopps <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; Martin Horneffer <[email protected]>; Robert Raszuk <[email protected]>; Shraddha Hegde <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit 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 [LES:] This is incorrect – and unfortunately is a common misunderstanding. From the Introduction to RFC 8919: “In recent years, new applications that have use cases for many of the link attributes historically used by RSVP-TE have been introduced. Such applications include Segment Routing (SR) Policy [SEGMENT-ROUTING<https://www.rfc-editor.org/rfc/rfc8919.html#I-D.ietf-spring-segment-routing-policy>] and Loop-Free Alternates (LFAs) [RFC5286<https://www.rfc-editor.org/rfc/rfc8919.html#RFC5286>]. This has introduced ambiguity in that if a deployment includes a mix of RSVP-TE support and SR Policy support, for example, it is not possible to unambiguously indicate which advertisements are to be used by RSVP-TE and which advertisements are to be used by SR Policy. If the topologies are fully congruent, this may not be an issue, but any incongruence leads to ambiguity.” The first problem addressed by ASLA was to be able to identify which application(s) were using a given link attribute advertisement. This has nothing to do with whether a different value/application is required or not. Once we had the ability to associate an advertisement with specific application(s), we clearly also had the ability to support different values/application for a given link attribute. But that does not mean that it is expected (let alone required) to have unique values/application. In fact, in most deployment cases, there are not different values/application – but there definitely are incongruent set of links per application and potentially incongruent sets of attributes/application on a given link. It is an unfortunate fact that people get concerned about ASLA because they have a hard time trying to figure out how they could define different values for a given attribute/application. But that isn’t required by ASLA. We have the capability to do that if needed – but it isn’t required – and it is a serious mistake to make the statement you have made. 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. [LES:] The need for SABM does not go away because you have the Any bit. See my original email (referenced above) for examples which demonstrate that. And “operational complexity” is NOT impacted by the protocol encoding. You, as an operator, have to configure what applications are using what link attribute values on each link. You most certainly do NOT have to configure how this is encoded on the wire (ALL, Individual App bits, or Any). Any configuration model that requires you to do that is fundamentally broken. What does add operational complexity is the introduction of a third style of encoding (the proposed “Any”) – since you (the operator) have to monitor when it safe to enable use of this encoding. I do have a concern about interoperability for devices supporting ASLA and those supporting the Any bit. [LES:] Good that you see that. Though I would remind you that “Any” is an extension to ASLA – not an alternative to ASLA. 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. [LES:] This paragraph is hard to parse. 😊 Best answer I can give is to read the encoding examples I provided in my original email. There are currently two encoding syntaxes defined: 1)Explicit SABM mask 2)ALL (0 length SABM) – which has some restrictions “Any” continues to use ASLA – it is in fact proposed as a bit reserved for it in SABM. It just removes some restrictions which are associated with use of ALL. But it doesn’t provide any new capability i.e., any deployment scenario can be supported today without using “Any”. What it does do is introduce added implementation complexity and added deployment complexity. Note that one thing Shraddha and I agree on is that sending “Any” cannot be enabled until such time as all routers in the network support it at least for receive. This isn’t “backwards compatibility” as I understand it – so for me the claim in Section 4 isn’t credible. But I am not going to spend cycles arguing over the meaning of the term. 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 [LES:] Thanx for pointing this out. This actually adds to the cost of deploying “Any”. I had previously mentioned the implementation costs to IGPs – but I had overlooked the implementation costs for BGP-LS – which will be paid both on the encoding side and on the consumer client processing code. Whether you like “Any” or don’t like “Any”, it is fair and accurate to say that adding “Any” support comes with significant implementation costs and significant deployment costs. If it allowed us to support deployment cases that otherwise could not be supported, then such costs might be justified – but it doesn’t. Les Kind Regards Gyan On Fri, Apr 8, 2022 at 8:03 AM Christian Hopps <[email protected]<mailto:[email protected]>> wrote: Robert Raszuk <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> > wrote: > > > Robert Raszuk <[email protected]<mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
