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. 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. 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, 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> wrote: > Robert - > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Friday, August 20, 2021 5:01 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Ron Bonica <rbon...@juniper.net>; 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> wrote: > > Robert – > > > > Inline. > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Friday, August 20, 2021 1:29 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Ron Bonica <rbon...@juniper.net>; 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 > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr