Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

[Robert Raszuk <[e-mail]>]

Les,

Your point is brilliant and valid if you assume flex-algo will be a *single*
topology. And in few networks that may be indeed the case.

But the very moment customers want to use more then one flex-algo topology
with selective set of metrics and links you are back to the exactly same
set of problems you are clearly describing which led to ASLA. And as we all
agreed use of hand crafted set of affinities is again the only to in the
tool box to come to the rescue.

So maybe its time to admit it and fix the flex-algo spec ?

Cheers,
R.





On Mon, Aug 23, 2021 at 7:03 PM Les Ginsberg (ginsberg) <ginsberg=
[e-mail]> wrote:

>
>
>
>
> *From:* Shraddha Hegde <shraddha=[e-mail]>
> *Sent:* Monday, August 23, 2021 8:22 AM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>; Tony Przygienda <
> [e-mail]>
> *Cc:* Ron Bonica <[e-mail]>; Robert Raszuk <[e-mail]>;
> [e-mail]
> *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
> <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 <[e-mail]> *On Behalf Of *Les Ginsberg (ginsberg)
> *Sent:* Saturday, August 21, 2021 8:11 PM
> *To:* Tony Przygienda <[e-mail]>
> *Cc:* Ron Bonica <[e-mail]>; Robert Raszuk <[e-mail]>;
> [e-mail]
> *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 <[e-mail]>
> *Sent:* Saturday, August 21, 2021 12:04 AM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>
> *Cc:* Robert Raszuk <[e-mail]>; Ron Bonica <[e-mail]>;
> [e-mail]
> *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=
> [e-mail]> wrote:
>
> Robert -
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Friday, August 20, 2021 5:01 PM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>
> *Cc:* Ron Bonica <[e-mail]>; [e-mail]
> *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) <
> [e-mail]> wrote:
>
> Robert –
>
>
>
> Inline.
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Friday, August 20, 2021 1:29 PM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>
> *Cc:* Ron Bonica <[e-mail]>; [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!VZrcMcSTqfd9NuBXlnhGPjQVxztcMMIkLf0cjL21aaMI7UfRdzqx6VBLDV32y57n$>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>