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

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 <tonysietf@gmail.com> 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=
> 40cisco.com@dmarc.ietf.org> wrote:
>
>> Robert -
>>
>>
>>
>> *From:* Robert Raszuk <robert@raszuk.net>
>> *Sent:* Friday, August 20, 2021 5:01 PM
>> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
>> *Cc:* Ron Bonica <rbonica@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) <
>> ginsberg@cisco.com> wrote:
>>
>> Robert –
>>
>>
>>
>> Inline.
>>
>>
>>
>> *From:* Robert Raszuk <robert@raszuk.net>
>> *Sent:* Friday, August 20, 2021 1:29 PM
>> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
>> *Cc:* Ron Bonica <rbonica@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
>>
>