Subject: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 24 Mar 2022 05:05:07 +0000

Folks -

Now that the slides have been posted for this presentation, I am going to send some early comments.

I do this because - as usual - the agenda for the meeting is packed and it is likely there will be little time for discussion during the meeting.

Also my comments are lengthy, it would be difficult to present them during the meeting.

As always, discussion can occur on the list, but if Shraddha has a chance to review these comments in the limited time before the meeting and has a chance to respond to them during her presentation so much the better, but I am not expecting that.

COMMENT 1

Existing encoding defined in RFCs 8919/8920 is fully functional i.e., the introduction of ANY application does not add support for deployment scenarios that could not otherwise be supported.

COMMENT 2

The argument in the presentation is that ANY application encoding adds a significant amount of efficiency to the encoding. But this requires closer scrutiny.

(Aside: The example discussed in the presentation includes the use of link attributes Maximum reservable link bandwidth(10) and Unreserved bandwidth(11) - which are link attributes only usable by RSVP-TE application.

As such, they are not candidates to be advertised using either the ANY bit or the ALL encoding defined in RFCs 8919/8920.

In the examples below I assume the attributes being used are potentially usable by all applications.)

Assume we have the following applications:  APP1 APP2 APP3

Assume we have the following link attributes: ATTR1 ATTR2 ATTR3

Example 1 (analogous to the example in Shraddha's presentation)

ATTR1 and ATTR2 have a value usable by all applications.

ATTR3 has two values:

One usable by APP1 and APP2 - call it ATTR3-12

One usable only by APP3 - call it ATTR3-3

Encoding using ANY requires two ASLA sub-TLVs

Sub-TLV1: ANY: Attributes ATTR1 ATTR2 ATTR3-12

Sub-TLV2: APP3: Attributes ATTR3-3

Encoding using RFC 8919 rules requires three ASLA sub-TLVs:

Sub-TLV1: APP1|APP2|APP3: Attributes ATTR1 ATTR2

Sub-TLV2: APP1|APP2: Attribute ATTR3-12

Sub-TLV3: APP3: Attributes ATTR3-3

ANY encoding saves 5 bytes

Example 2

All applications share the same attribute value for ATTR1 and ATTR2.

Each application has a unique value for ATTR3.

Encoding using ANY requires four ASLA sub-TLVs

Sub-TLV1: ANY APP: Attributes ATTR1 ATTR2

Sub-TLV2: APP1: Attributes ATTR3-1

Sub-TLV3: APP2: Attributes ATTR3-2

Sub-TLV4: APP3: Attributes ATTR3-3

Encoding using RFC 8919 rules requires four ASLA sub-TLVs:

Sub-TLV1: APP1|APP2|APP3: Attributes ATTR1 ATTR2

Sub-TLV2: APP1: Attributes ATTR3-1

Sub-TLV3: APP2: Attributes ATTR3-2

Sub-TLV4: APP3: Attributes ATTR3-3

Same byte usage for both approaches

Example 3

All applications share the same attribute value for all attributes.

Encoding using ANY requires one ASLA sub-TLV

Sub-TLV1: ANY APP: Attributes ATTR1 ATTR2 ATTR3

Encoding using RFC 8919 rules requires one ASLA sub-TLV:

Sub-TLV1: 0 length SABM: Attributes ATTR1 ATTR2 ATTR3

RFC 8919 encoding saves one byte (because it does not have to include any SABM)

What is the point of this???

Simply to demonstrate that ANY encoding does NOT guarantee more efficient encoding - it depends on the actual deployment scenario.

Suggesting that ANY is always more efficient is FALSE.

COMMENT 3

There are multiple interoperable implementations of RFC 8919 deployed today. ANY support is of course not included.

Introducing a new form of ASLA advertisement ("ANY") comes with the following costs:

1)All implementations MUST add support for receiving ANY

2)Any implementation wanting to send ANY must implement ANY Tx support (as well as the ALL/Explicit APP defined in RFC 8919.)

3)As it is not safe to send ANY until all deployed implementations at least support receiving ANY, implementations wanting to send ANY MUST provide controls to allow
the operator to enable/disable the sending of ANY and the operator MUST track the capabilities of the nodes deployed in the network to determine when it is safe to enable sending of ANY.

SUMMARY COMMENT

ANY does not provide additional functionality.
ANY does not guarantee encoding efficiency.
ANY increases implementation complexity
ANY increases feature deployment complexity

For me, the costs in implementation/deployment complexity far outweigh the very minimal efficiency benefits of the new encoding - which are not even guaranteed to exist in all deployments.

   Les

---

From: Martin Horneffer <[email-masked]>
Date: Thu, 24 Mar 2022 16:17:30 +0100

Dear WG,

as we just had this discussion and acoustics in the room didn't appear 
to be good I was asked to post my comment to the list:

Not a comment on the idea of the ANy Application bit per se, nor on Les' 
discussion. Rather a ceterum censeo on ASLA in general:
In my opinion this discussion shows that ASLA itself is overly complex.

Let's just hope this discussion gets resolved quickly, and doesn't 
provide yet another source for interoperability issues between vendors. 
We already have more than enough of them.

Best regards,
Martin

Am 24.03.22 um 06:05 schrieb Les Ginsberg (ginsberg):
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 24 Mar 2022 15:57:35 +0000

Martin -

I hear you.

The reality is that ASLA need not be that complex.

In many deployments life is simple. There are a small number of applications using the same set of values on each link.
>From an encoding standpoint, all that needs to be done is to send a single ASLA sub-TLV that lists the applications and the link attributes.

The use of ALL applications is only an encoding optimization - it isn't required. In hindsight, maybe we should never have defined it - but it seemed like a nice optimization at the time.
But certainly,  we should not further complicate things - both for implementations and deployments - by defining yet another encoding option. As you suggest below, this increases the possibility of interoperability issues w/o providing significant benefit.

ASLA is needed. There are real world examples where it is necessary to identify on each link which applications are using the advertised link attribute values.

   Les

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of Martin Horneffer
> Sent: Thursday, March 24, 2022 8:18 AM
> To: [email-masked]
> Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute
> (ASLA) Any Application Bit
> 
> Dear WG,
> 
> > I do this because - as usual - the agenda for the meeting is packed and it is
> likely there will be little time for discussion during the meeting.
> >
> > As always, discussion can occur on the list, but if Shraddha has a chance to
> review these comments in the limited time before the meeting and has a
> chance to respond to them during her presentation so much the better, but I
> am not expecting that.
> >
> >
> >
> > COMMENT 1
> >
> >
> >
> > Existing encoding defined in RFCs 8919/8920 is fully functional i.e., the
> introduction of ANY application does not add support for deployment
> scenarios that could not otherwise be supported.
> >
> >
> >
> > COMMENT 2
> >
> >
> >
> > The argument in the presentation is that ANY application encoding adds a
> significant amount of efficiency to the encoding. But this requires closer
> scrutiny.
> >
> >
> >
> > (Aside: The example discussed in the presentation includes the use of link
> attributes Maximum reservable link bandwidth(10) and Unreserved
> bandwidth(11) - which are link attributes only usable by RSVP-TE application.
> >
> > As such, they are not candidates to be advertised using either the ANY bit
> or the ALL encoding defined in RFCs 8919/8920.
> >
> > Simply to demonstrate that ANY encoding does NOT guarantee more
> efficient encoding - it depends on the actual deployment scenario.
> >
> > There are multiple interoperable implementations of RFC 8919 deployed
> today. ANY support is of course not included.
> >
> > 2)Any implementation wanting to send ANY must implement ANY Tx
> support (as well as the ALL/Explicit APP defined in RFC 8919.)
> >
> > 3)As it is not safe to send ANY until all deployed implementations at least
> support receiving ANY, implementations wanting to send ANY MUST provide
> controls to allow
> > the operator to enable/disable the sending of ANY and the operator MUST
> track the capabilities of the nodes deployed in the network to determine
> when it is safe to enable sending of ANY.
> >
> > SUMMARY COMMENT
> >
> > For me, the costs in implementation/deployment complexity far outweigh
> the very minimal efficiency benefits of the new encoding - which are not
> even guaranteed to exist in all deployments.
> >
> >     Les
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 25 Mar 2022 09:21:35 +0000

I believe we still have an opportunity to simplify ASLA as it is not that widely deployed.
The inter-operability issues are almost always due to unclear and ambiguous documentation
of standards. All we need is to ensure is that the protocol  extensions have unambiguous documentation.

The two main advantages of Any app are efficiency and simplicity.
The encoding efficiency of any app for common cases has been demonstrated in the presentation.
The one byte overhead that Les brings about is a distraction. It's a always a fixed additional one byte 
for all vs any ,which is negligible whereas the benefits demonstrated for any can be more if 
more attributes fall in the same category.

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, March 24, 2022 9:28 PM
To: Martin Horneffer <maho=[email-masked]>; [email-masked]
Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

[External Email. Be cautious of content]

Martin -

I hear you.

   Les

> > Now that the slides have been posted for this presentation, I am 
> > going to
> send some early comments.
> >
> > Also my comments are lengthy, it would be difficult to present them 
> > during
> the meeting.
> >
> >
> >
> chance to respond to them during her presentation so much the better, 
> but I am not expecting that.
> >
> >
> >
> > COMMENT 1
> >
> >
> >
> significant amount of efficiency to the encoding. But this requires 
> closer scrutiny.
> >
> >
> >
> > In the examples below I assume the attributes being used are 
> > potentially
> usable by all applications.)
> >
> >
> >
> > RFC 8919 encoding saves one byte (because it does not have to 
> > include any
> SABM)
> >
> >
> >
> support receiving ANY, implementations wanting to send ANY MUST 
> provide controls to allow
> track the capabilities of the nodes deployed in the network to 
> determine when it is safe to enable sending of ANY.
> >
> > SUMMARY COMMENT
> >
> > ANY increases implementation complexity ANY increases feature 
> > deployment complexity
> >
> the very minimal efficiency benefits of the new encoding - which are 
> not even guaranteed to exist in all deployments.
> >
> >     Les
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls
> > r__;!!NEt6yMaO-gk!V5RKin1YGpQigF3VmYVUWGDYci9sKdmVO2ZnQFcsfnPZLpKnPU
> > SJ-ybjYmWKEQTW$
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!V5RKin1YGpQigF3VmYVUWGDYci9sKdmVO2ZnQFcsfnPZLpKnPUSJ-y
> bjYmWKEQTW$

_______________________________________________
Lsr mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!V5RKin1YGpQigF3VmYVUWGDYci9sKdmVO2ZnQFcsfnPZLpKnPUSJ-ybjYmWKEQTW$

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 25 Mar 2022 10:37:53 +0000

Shraddha -

RFCs 8919/8920 were published in October 2020 - and implementations based on draft versions of those document date back as much as two years before that. They all are written to support the encoding formats defined in the RFCs.

The introduction of an additional way of encoding the same information is anything but "simplifying". As I have described below, you are imposing a requirement for ALL ASLA implementations to support an additional encoding format - at least for receiving.
This does not simplify implementations - it further complicates them. And it increases the possibility of interoperability issues.

It also does not simplify deployments. You impose requirements on operators to track which of the multiple formats are supported by each of the router versions deployed in their network so they can decide when it is safe to enable sending of the new format.

For any protocol extension, there are almost always multiple possible syntaxes which could have been defined to advertise the necessary information. The point of having a standard is to define an agreed upon format so that interoperability can be achieved.

Please do not complicate implementations/deployments for a feature which already has a fully functional standard and multiple implementations deployed based on that standard.

   Les

> From: Lsr <[email-masked]> On Behalf Of Shraddha Hegde
> Sent: Friday, March 25, 2022 2:22 AM
> To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Martin
> Horneffer <maho=[email-masked]>; [email-masked]
> In many deployments life is simple. There are a small number of applications
> using the same set of values on each link.
> >From an encoding standpoint, all that needs to be done is to send a single
> ASLA sub-TLV that lists the applications and the link attributes.
> 
> The use of ALL applications is only an encoding optimization - it isn't required.
> In hindsight, maybe we should never have defined it - but it seemed like a
> nice optimization at the time.
> But certainly,  we should not further complicate things - both for
> implementations and deployments - by defining yet another encoding
> option. As you suggest below, this increases the possibility of interoperability
> issues w/o providing significant benefit.
> 
> ASLA is needed. There are real world examples where it is necessary to
> identify on each link which applications are using the advertised link attribute
> values.
> 
>    Les
> 
> 
> > > r__;!!NEt6yMaO-
> gk!V5RKin1YGpQigF3VmYVUWGDYci9sKdmVO2ZnQFcsfnPZLpKnPU
> > > SJ-ybjYmWKEQTW$
> >
> > _;!!NEt6yMaO-
> gk!V5RKin1YGpQigF3VmYVUWGDYci9sKdmVO2ZnQFcsfnPZLpKnPUSJ-y
> > bjYmWKEQTW$
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!
> !NEt6yMaO-
> gk!V5RKin1YGpQigF3VmYVUWGDYci9sKdmVO2ZnQFcsfnPZLpKnPUSJ-
> ybjYmWKEQTW$
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Mar 2022 12:41:12 +0100

Hi Les,

Let me clarify if I read you correctly ...

Are you saying that because quoted RFCs have been published in Oct 2020 no
one has a right to define any new standard link attributes any more as
implementations are closed ? Including those which would be common to all
applications on a link ?

So if anyone would like to add their own new attributes one needs to define
new sub-TLV codepoint to encode it outside of ASLA ? If so please state it
then we could update the draft accordingly.

Yes deployment of those is a challenge, but I am afraid this is a
challenge with every protocol extensions unless we use mechanism like
capabilities which will assist in an automated way.

Thx,
Robert.

On Fri, Mar 25, 2022 at 11:39 AM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> Shraddha -
>
> RFCs 8919/8920 were published in October 2020 - and implementations based
> on draft versions of those document date back as much as two years before
> that. They all are written to support the encoding formats defined in the
> RFCs.
>
> The introduction of an additional way of encoding the same information is
> anything but "simplifying". As I have described below, you are imposing a
> requirement for ALL ASLA implementations to support an additional encoding
> format - at least for receiving.
> This does not simplify implementations - it further complicates them. And
> it increases the possibility of interoperability issues.
>
> It also does not simplify deployments. You impose requirements on
> operators to track which of the multiple formats are supported by each of
> the router versions deployed in their network so they can decide when it is
> safe to enable sending of the new format.
>
> For any protocol extension, there are almost always multiple possible
> syntaxes which could have been defined to advertise the necessary
> information. The point of having a standard is to define an agreed upon
> format so that interoperability can be achieved.
>
> Please do not complicate implementations/deployments for a feature which
> already has a fully functional standard and multiple implementations
> deployed based on that standard.
>
>    Les
>
>
> > I believe we still have an opportunity to simplify ASLA as it is not
> that widely
> > deployed.
> > The inter-operability issues are almost always due to unclear and
> ambiguous
> > documentation
> > of standards. All we need is to ensure is that the protocol  extensions
> have
> > unambiguous documentation.
> >
> > The one byte overhead that Les brings about is a distraction. It's a
> always a
> > fixed additional one byte
> > for all vs any ,which is negligible whereas the benefits demonstrated
> for any
> > can be more if

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 25 Mar 2022 11:50:15 +0000

Robert –

I find your post a non-sequitar.

ASLA ANY is NOT discussing advertising a new attribute. It is discussing a new format for the ASLA sub-TLV container inside of which link attribute values are advertised.

You are off-topic with your post.

   Les

From: Robert Raszuk <[email-masked]>
Sent: Friday, March 25, 2022 4:41 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Shraddha Hegde <[email-masked]>; Martin Horneffer <[email-masked]>; [email-masked]
Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Hi Les,

Are you saying that because quoted RFCs have been published in Oct 2020 no one has a right to define any new standard link attributes any more as implementations are closed ? Including those which would be common to all applications on a link ?

So if anyone would like to add their own new attributes one needs to define new sub-TLV codepoint to encode it outside of ASLA ? If so please state it then we could update the draft accordingly.

Yes deployment of those is a challenge, but I am afraid this is a challenge with every protocol extensions unless we use mechanism like capabilities which will assist in an automated way.

Thx,
Robert.

On Fri, Mar 25, 2022 at 11:39 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
Shraddha -

   Les

> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Shraddha Hegde
> To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>>; Martin
> Horneffer <maho=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Les Ginsberg (ginsberg)
> To: Martin Horneffer <maho=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Horneffer
> > To: [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ls>
> > > r__;!!NEt6yMaO-
> > [email-masked]<mailto:[email-masked]>
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_>
> > _;!!NEt6yMaO-
> [email-masked]<mailto:[email-masked]>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__>;!
> !NEt6yMaO-
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Mar 2022 12:53:05 +0100

I am afraid not .. I am exploring how to solve requirement. Proposed
method is natural and reuses ASLA encoding. There is apparently a wall this
proposal is facing.

So trying to see how to bypass that wall (or jump over it).

Cheers,
R.

On Fri, Mar 25, 2022 at 12:50 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> ASLA ANY is NOT discussing advertising a new attribute. It is discussing a
> new format for the ASLA sub-TLV container inside of which link attribute
> values are advertised.
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Friday, March 25, 2022 4:41 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Shraddha Hegde <[email-masked]>; Martin Horneffer <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Lsr] IETF13: Comments on The Application Specific Link
> Attribute (ASLA) Any Application Bit
>
>
>
> Hi Les,
>
>
>
> So if anyone would like to add their own new attributes one needs to
> define new sub-TLV codepoint to encode it outside of ASLA ? If so please
> state it then we could update the draft accordingly.
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ls>
> > > > r__;!!NEt6yMaO-
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_>
> > > _;!!NEt6yMaO-
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__>;!
> > !NEt6yMaO-

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 25 Mar 2022 12:02:36 +0000

Robert –

As I have stated in my original comments:

<snip>
<end snip>

I don’t think there is anything else that needs to be said.

   Les

Sent: Friday, March 25, 2022 4:53 AM

I am afraid not .. I am exploring how to solve requirement. Proposed method is natural and reuses ASLA encoding. There is apparently a wall this proposal is facing.

Cheers,
R.

On Fri, Mar 25, 2022 at 12:50 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

   Les

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 25, 2022 4:41 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Martin Horneffer <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Hi Les,

Thx,
Robert.

   Les

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Mar 2022 13:06:24 +0100

Les,

There is clearly a valid case for having attributes common to all
applications. Duplicating those on a per application is perhaps a way, but
is this the most efficient way encoding wise ?

Thx,
R.

On Fri, Mar 25, 2022 at 1:02 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> *Sent:* Friday, March 25, 2022 4:53 AM
> On Fri, Mar 25, 2022 at 12:50 PM Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Robert –
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 25 Mar 2022 12:11:07 +0000

Robert –

I have documented several different scenarios and how each approach encodes them and their comparable byte usage.
Your characterization isn’t accurate.

I don’t think this sub-thread is useful – you are adding noise to the conversation.

If you want to discuss offline – please contact me directly.

   Les

Sent: Friday, March 25, 2022 5:06 AM

Les,

There is clearly a valid case for having attributes common to all applications. Duplicating those on a per application is perhaps a way, but is this the most efficient way encoding wise ?

Thx,
R.

On Fri, Mar 25, 2022 at 1:02 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

<snip>

   Les

Cheers,
R.

   Les

Hi Les,

Thx,
Robert.

   Les

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Mar 2022 13:24:05 +0100

Les,

I don't think this is noise.

Your examples are missing key operational consideration .. Link attribute
applicable to ANY application may be advertised well ahead of enabling such
application in a network.

So requesting operator to always advertise tuple of app + attr is not
looking forward and makes unnecessary operational burden.

Thx.
R.

On Fri, Mar 25, 2022 at 1:11 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Robert –
>
>
>
> I have documented several different scenarios and how each approach
> encodes them and their comparable byte usage.
>
> *Sent:* Friday, March 25, 2022 5:06 AM
> On Fri, Mar 25, 2022 at 1:02 PM Les Ginsberg (ginsberg) <

---

From: Christian Hopps <[email-masked]>
Date: Sat, 26 Mar 2022 00:55:38 -0400

Robert Raszuk <[email-masked]> writes:

> Your examples are missing key operational consideration .. Link
> attribute applicable to ANY application may be advertised well ahead
> of enabling such application in a network. 
>

[as wg-member]

Hi Robert,

Originally this was the argument that sort of put wind in the sails (for me) for this any bit, but some more thinking about how things would really work changed my mind.

In order for some new feature, let's call it Wizbang, to take advantage of existing any bit marked attributes, the operator still has to deploy new software that contains the new Wizbang feature, right? So the addition of a new Wizbang bit pretty much comes free for the operator.

So, this draft really is just about making the encoding a bit more efficient.

I think if we were defining a new encoding, having this functionality makes sense, but we aren't defining a new encoding. The proposal is to change an existing published encoding, and the bar has to be higher for that I think.

Thanks,
Chris.
[as wg member]

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 26 Mar 2022 11:43:24 +0100

Hi Chris,

It seems that there is a subtle but important element on which we may have
different opinion.

You said: "has to deploy new software that contains the new Wizbang
feature, right?"

IMO however we are dealing with case where software already supports all
required functions on a box. It is just not using it from day one. You buy
a router with OS features which allow you to build zoo of different
forwarding paradigms.

Say day one you see a need to enable flex-algo_1 You enable day one links
to distribute link attributes required for this.

Day two you want to define new FAD and flood this enabling new flex-algo_2.
You reuse already present link attributes entirely or partially in
flex-algo_2 computation. You do not need to touch 100000s of links each
time you enable new flex_algo.

That's a selling point to me.

If we would expect that folks will limit flex-algo to just a few maybe this
all does not matter. But if we see proposals with rainbow of colors each
mapped to different flex-algo and perhaps subtle forwarding difference
(same metric but just a different min threshold per each flex-algo) it
seems pretty bad idea to explicitly enable each app each time such new
threshold used to build different topology.

Example:

link attribute:  delay

applications:

flex-algo_1 - build topology where max delay does not exceed 10 ms - color:
premium best effort
flex-algo_2 - build topology where max delay does not exceed 8 ms -  color:
black
flex-algo_3 - build topology where max delay does not exceed 6 ms - color:
bronze
flex-algo_4 - build topology where max delay does not exceed 4 ms - color:
blue
flex-algo_5 - build topology where max delay does not exceed 3 ms - color:
silver
flex-algo_6 - build topology where max delay does not exceed 3 ms - color:
gold

etc ...

Now tell me how does it make sense to enable each app on the link delay
attribute ?

Cheers,
Robert

On Sat, Mar 26, 2022 at 6:42 AM Christian Hopps <[email-masked]> wrote:

> Originally this was the argument that sort of put wind in the sails (for
> me) for this any bit, but some more thinking about how things would really
> work changed my mind.
>
> In order for some new feature, let's call it Wizbang, to take advantage of
> existing any bit marked attributes, the operator still has to deploy new
> software that contains the new Wizbang feature, right? So the addition of a
> new Wizbang bit pretty much comes free for the operator.
>
> I think if we were defining a new encoding, having this functionality
> makes sense, but we aren't defining a new encoding. The proposal is to
> change an existing published encoding, and the bar has to be higher for
> that I think.
>
> Thanks,
> Chris.
> [as wg member]
>
>
> >
> > Thx.
> > R.
> >
>