Tony > I see a value in the "A" bit from multiple angles (which I do not read as "all applications" but "any application".
Spot on ! Yes we did mean "any app" not "all apps". Even title says "any" :) Each app can still cherry pick what it uses in FAD. > (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 ;-) I am not following this one ... SABM length in octets describes length of the actual application bit octets. A-bit or R,S,F,X are part of it. So for A-bit length must be at least 1 or more. But now comes Les and says: *> (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)* That to me is ambiguous as it sort of means that 0 length ABM flags may be defined as any application. If that would be the case (which I believe is not today) then indeed no need to define A-bit. Cheers, R. On Sat, Aug 21, 2021 at 9:05 AM Tony Przygienda <[email protected]> wrote: > 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= > [email protected]> wrote: > >> Robert - >> >> >> >> *From:* Robert Raszuk <[email protected]> >> *Sent:* Friday, August 20, 2021 5:01 PM >> *To:* Les Ginsberg (ginsberg) <[email protected]> >> *Cc:* Ron Bonica <[email protected]>; [email protected] >> *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) < >> [email protected]> wrote: >> >> Robert – >> >> >> >> Inline. >> >> >> >> *From:* Robert Raszuk <[email protected]> >> *Sent:* Friday, August 20, 2021 1:29 PM >> *To:* Les Ginsberg (ginsberg) <[email protected]> >> *Cc:* Ron Bonica <[email protected]>; [email protected] >> *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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
