From: Shraddha Hegde <shraddha=40juniper....@dmarc.ietf.org> Sent: Monday, August 23, 2021 8:22 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Tony Przygienda <tonysi...@gmail.com> Cc: Ron Bonica <rbon...@juniper.net>; Robert Raszuk <rob...@raszuk.net>; lsr@ietf.org Subject: RE: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt
Les, ------------------------------------------------------------------------------------------------------------------------------------------ > But there is a second dimension – which is that the existence of an > “all-APPs” advertisement on a given >link implicitly means that all applications which have been enabled in the >network are using that link. ------------------------------------------------------------------------------------------------------------------------------------------ It seems to me that this statement illustrates a disconnect. [LES:] Indeed – this is a key point – but the misunderstanding is on your part. Please let me explain. One of the lessons we learned from RSVP-TE was that deployments suffered because there was no standard definition of what indicated use of a link by RSVP-TE. Different vendors had different internal definitions and it was left to customers to unravel this and come up with configurations that allowed interoperability. This issue was further highlighted with the introduction of other applications (e.g., SRTE) because it was not possible to distinguish what constituted links in use for SRTE vs links in use by RSVP-TE. Therefore , one of the issues ASLA set out to fully address was to make explicit the association of link attribute advertisements with the application(s) which use them. The following text from https://www.rfc-editor.org/rfc/rfc8919.html#section-2 is relevant: “There is no requirement for the link attributes advertised on a given link used by SR Policy to be identical to the link attributes advertised on that same link used by RSVP-TE; thus, there is a clear requirement to indicate independently which link attribute advertisements are to be used by each application.” Requiring ALL applications to use affinity to indicate whether link attribute advertisements are to be used by a given application imposes an unnecessary restriction. For example, suppose I have an application that wants to use only links with a certain (set of) SRLG value(s) and a certain interface type? There is no reason to require the operator to – in addition to assigning an SRLG value to a link – to require that a specific affinity value also be assigned to that link. The operational behavior is that ASLA defines the association between a set of advertisements and an application. Affinities support the inclusion/exclusion semantic within a given application. The explicit association of a link with an application that ASLA provides is one of the essential elements of the ASLA solution. HTH clarify. Les Which links are included/excluded from application’s topology is defined by applications. It has been discussed in this list multiple times that the existing applications (RSVP, SR-TE, LFA) use admin-groups/link-affinities to include/exclude links. Flex-algo is a new application and it has been discussed in this thread that admin-group/link-affinities is the best way to include/exclude links from different flex-algo topologies. You are arguing that applications will use advertisement of ASLA attributes as indication to include/exclude links from the Topology. Are you referring to new applications that are going to be invented in future? If so, it would be good to get concrete examples of those future applications. Rgds Shraddha Juniper Business Use Only From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Les Ginsberg (ginsberg) Sent: Saturday, August 21, 2021 8:11 PM To: Tony Przygienda <tonysi...@gmail.com<mailto:tonysi...@gmail.com>> Cc: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>; Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt [External Email. Be cautious of content] Tony – There already is a way to advertise link attributes to be used by “all/any application” defined in RFC 8919/8920: Use a zero length ABM. However, it comes with a restriction: if there exists any ASLA advertisement of link attributes with a non-zero ABM that includes a given application bit, that application MUST NOT use any attributes advertised in the zero length ABM advertisement. It is that restriction which the authors of draft-hegde-lsr-asla-any-app wish to avoid – so they have proposed an alternate way of advertising “any/all applications” – which is to use the new A-bit. Why did we introduce the restriction that if there were application specific advertisements for a link for application X that it MUST NOT use the “all-APPs” advertisements? We did this because once there were some attributes advertised specific to a given application, we thought it became significantly less probable that it was safe to assume that the other attributes advertised in “all-APPs” applied to application X. We thought that it was less ambiguous to say – for a given application – either you use the attributes advertised in “all-APPs” – or you use the attributes in the advertisements which explicitly mention X – but not both. (This, BTW, implicitly resolves the question of what happens when the same attribute is advertised in both forms.) The more important point is that there are two “dimensions” to consider when using an “all-APPs” style advertisement. Dimension #1 is the more obvious one: the values associated with the attributes advertised MUST be the same for all of the apps. But there is a second dimension – which is that the existence of an “all-APPs” advertisement on a given link implicitly means that all applications which have been enabled in the network are using that link. It is this second dimension which has to be considered carefully before using an “all-APPs” advertisement. It is easy to come up with examples of link attributes whose value is expected to be the same for any application using that link – maximum link bandwidth is an obvious one which exists today. But Ron has suggested other possible attributes which can easily be seen as falling into the same category. But, as I explained in one of my replies to Robert, assuming that a new application introduced into the network is intended to use the exact same set of links that are being used by the already deployed applications is much more problematic. I believe the authors of draft-hegde-lsr-asla-any-app are focused on the first dimension and have not fully considered the second dimension. One could debate whether the existing “all-APPs” using zero length ABM defined in RFC 8919/8920 is better or worse than the proposed “any-APPs” using A-bit. But given the extremely limited differences in actual usage between the two (please see my original reply on this thread) I don’t think this is worth the time. And as introduction of A-bit would require implementations to handle the various combinations of possible deployments (only zero ABM, mix of zero-ABM and A-bit, all A-bit) I do not see that ROI is worth it. A few more responses inline. From: Tony Przygienda <tonysi...@gmail.com<mailto:tonysi...@gmail.com>> Sent: Saturday, August 21, 2021 12:04 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Cc: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt My quick take: 1. yes, A bit will necessitate being either deployed in a well understood part of the network (because as Les says old nodes will basically see _no_ application [which seems desirable, they basically take themselves out]) or forklifting. Not that different from flex-algo being same kind of forklift AFAIS. 2. any application introduced after that will precondition implementation of A bit if we don't want to get into the rathole of "do not encode using A, encode using repetition per application if you have old routers". I see a value in the "A" bit from multiple angles (which I do not read as "all applications" but "any application". The distinction is subtle but important) a) it fits what flex-algo needs in ASLA architecture. E'one wins AFAIS. [LES:] Nothing about this discussion is flex-algo specific. And I do not see any gaps in current flex-algo support which this proposal fills. I understand some folks might like one proposal more than another, but there is no existing functionality gap. b) if we want to replace A with X|Y|Z we need to know on a router about _all_ applications on all routers and that may be non-trivial and on every change may force re-adverts (unless we set all bits 1 on a 8 bytes ASLA mask [as in _all_ applications]. That does not seem like a good idea given the encoding sizes). A as "any" basically means "any application on this router uses this metric" and avoids both problems. Significantly simpler AFAIS. [LES:] Please see my discussion above. A very, very subtle point (I didn't read the 'a' draft yet so it may be taken care of) is whether SABM length is 1 with all 0s or length is 0 on A bit presence and if 0 will the current implementations hold up to that ;-) [LES:] As a bit in the ABM has to be assigned to “A”, this means that the advertised ABM length is non-zero. There is also the question as to whether we need an A-bit in both the SABM and UDABM fields (I would think “yes” given the intended independence of the two fields. This is not discussed in the draft.) An alternative would be to remove the restriction associated with zero-length ABM and allow all applications to use such advertisements even in the presence application specific advertisements. This wouldn’t be backwards compatible of course. And, for the reasons I mentioned above, I believe the current restrictions provide greater safety – so I am not in favor of this. Les Les, correct me if I'm off somewhere, I was watching lots of that just from the corner of my eye ;-) -- tony On Sat, Aug 21, 2021 at 2:06 AM Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: Robert - From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Sent: Friday, August 20, 2021 5:01 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Cc: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt Hi Les, The point being is that “A-bit” is no different than introducing any other new application bit. Until all routers in the network understand it you cannot safely use it. That is true. But the entire point of A-bit is that you are doing this exercise to make sure your routers understand A-bit only one time. [LES:] This does not mean that you can introduce support for a new application (call it “bit N”) w/o upgrading your routers simply because you already have A-bit support. I hope that is obvious. 😊 My original point was simply that the statement about “backwards compatibility” regarding A-bit isn’t accurate. Good that we now agree on that. Les Otherwise you need to do it each time you invent a new bit. Thx, R. On Sat, Aug 21, 2021 at 1:34 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: Robert – Inline. From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Sent: Friday, August 20, 2021 1:29 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Cc: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt Hi Les, Please see below. It is not just that a new application wants to use the same link attribute value that allows you to use the "all applications" encoding. It is also necessary for the set of links used by the new application to be identical to the set of links used by the existing applications. Not really. You can use subset of links when you apply affinity bits to it. [LES:] This isn’t relevant. Let me try explaining this a different way. Suppose I have 1000 links in my network. On 500 of those links I have Attribute #1 advertised using “all applications”. (For the purposes of this discussion it does not matter whether I use the existing 0 length ABM format or the proposed new “A-bit” format) There are currently two applications, X and Y, deployed in the network and they are both using the same value of attribute #1 on the same set of 500 links. All is well. Now, I want to enable application Z. If I do so and make no changes to the existing link attribute advertisements, application Z will think it can use Attribute #1 on all 500 of the links on which the “all” form of the ASLA sub-TLV is being advertised. If application Z is intended to use all of those 500 links all is well. But if application Z is NOT meant to use one or more of the links on which the ALL ASLA sub-TLVs are being advertised then I have to make changes to at least some of the existing advertisements. This is why, in RFC 8919/8920, we advise caution in using the “all” form – and why we do not allow both the “all” form and the “app-specific” form to be used by a given application. It is too easy for mistakes to occur, especially when enabling a new application. Implementations that I am aware of do not send the “ALL” form for this reason i.e., it introduces dependencies between applications which are hard to validate. Likewise as Peter confirmed you also need to use affinities to select subset of links carrying given flex-algo metric to be used only by some selective flex-algo topologies. " The solution described in this document is backward compatible with [RFC8919] and [RFC8920]." This is FALSE. Well I am not sure what Shraddha wanted to express by this sentence or what "backwards" means here. But if you delete "backwards" the rest of the sentence seems just fine. Let's observe that even if you define a new application and define new bit participating nodes need to support it. That means that you must keep upgrading your OS on all participating nodes each time new new bit is invented. [LES:] Again, a simple example should suffice. All routers in my network support application X and application Y. Some of the routers support the proposed A-bit, some do not. For the set of links on which applications X and Y are using the same attribute we will then have some links using A-bit ASLA, some not using A-bit ASLA. For those routers which support the A-bit, they will see links with both styles of ASLA advertisements as usable by applications X and Y. For those routers which do NOT support A-bit, they will see only the links w/0 A-bit ASLA as usable by applications X and Y. The point being is that “A-bit” is no different than introducing any other new application bit. Until all routers in the network understand it you cannot safely use it. Les Don't you think this is pretty bad ? How often do you think operators upgrade their core routers ? With A-bit and affinities at least your OS is ready to support any application based on already defined metrics without keep inventing new bits. Of course if we assume velocity of inventing new applications is near zero then this is not a problem. But then the usefulness of ASLA also can be challenged. Thx, R. _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!VZrcMcSTqfd9NuBXlnhGPjQVxztcMMIkLf0cjL21aaMI7UfRdzqx6VBLDV32y57n$>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
