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

[Tony Przygienda <[e-mail]>]

On Sat, Aug 21, 2021 at 11:51 AM Robert Raszuk <[e-mail]> wrote:

> 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.
>

ok, yepp, as I said, I did not scan the draft yet and if all that has been
abundantly clear no damage in spelling it out again.


>
> > (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.
>

it's not a good suggestion AFAIS, a natural semantics for 0 length ABM is
realy "_no_ 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 <[e-mail]>
> 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=
>> [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
>>>
>>