Les Thanks for the clarification. The Any versus All was confusing to me in the presentation, and your examples at the beginning of this thread have cleared up my confusion regarding ASLA and what Any bit brings to the table.
Responses in-line On Thu, Apr 14, 2022 at 2:21 AM Les Ginsberg (ginsberg) <[email protected]> wrote: > 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/ > > Gyan> Your post really helps clarify ASLA for me and based on what your > examples and analysis of Any bit draft, I don’t see any benefits to the > draft and do agree it does add more complexity. > > 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.* > Gyan> Ack and thanks for the clarification of my misunderstandings > *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.* > > * Gyan> Ack* > > *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.* > Gyan> Ack > * But that does not mean that it is expected (let alone required) to have > unique values/application.* > Gyan> Ack > * 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.* > > * Gyan> Ack and agreed that in general not different values/applications > but possible incongruent links in the topology * > > *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.* > Gyan> Ack. I think that sums it up that when most folks including myself think of ASLA they think of the not so common use case different values for a given attribute/application. Agreed. > *But that isn’t required by ASLA. * > Gyan> Ack > *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.* > > * Gyan> Understood and am back tracking what I have said based on the > clarification you provided with your original post. * > > > > 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.* > Gyan>. This was quite confusing and you’d post really helps clarify for me and I think as well others whom may have the same confusion > *And “operational complexity” is NOT impacted by the protocol encoding. * > Gyan> Ack > *You, as an operator, have to configure what applications are using what > link attribute values on each link. * > Gyan> Understood. > *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.* > > Gyan> Ack > *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.* > > Gyan> Ack as well as possible interoperability issues. Agreed > > > > 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.* > > Gyan> Ack and Understood > > 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.* > Gyan> I read the post and that really helped clarify my understanding. > *There are currently two encoding syntaxes defined:* > > *1)Explicit SABM mask* > > *2)ALL (0 length SABM) – which has some restrictions* > > * Gyan> Ack* > > *“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.* > Gyan> Ack > *But it doesn’t provide any new capability i.e., any deployment scenario > can be supported today without using “Any”.* > > Gyan> Ack. Bottom line is that other then the added complexity and possible interoperability issues there is no functionality gains with Any. Agreed. I am going back on what I stated and do not support the Any bit proposal. Thank you for the clarification of my misunderstandings. > *What it does do is introduce added implementation complexity and added > deployment complexity.* > > * Gyan> Ack. Completely agree * > > *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.* > Gyan> That would require software upgrade of all devices receiving the Any bit. > *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.* > > Gyan> Ack. > > > > 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.* > > *Gyan> Welcome. I agree this adds cost to deployments of Any for encoding > and receive side client processing code. Agreed * > > *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.* > > * Gyan> Completely agree that “Any” in summary does provide any > additional functionality that does not exist with ASLA today and at a high > implementation cost for IGP as well as BGP-LS. Thank you Les for the > clarification on my ASLA misunderstandings!* > > * Les* > > > > Kind Regards > > > > Gyan > > > > On Fri, Apr 8, 2022 at 8:03 AM Christian Hopps <[email protected]> wrote: > > > Robert Raszuk <[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]> > > 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 > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
