Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

From: <[email-masked]>
Date: Sun, 18 Jul 2021 04:40:50 +0800 (CST)

Dear All,
I concur with the arguments presented by Les and Peter. Perhaps the Editors of the WG draft will update the document accordingly.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [email-masked]
www.zte.com.cn
------------------Original Mail------------------
Sender: PeterPsenak
To: Les Ginsberg (ginsberg);[email-masked];[email-masked];
Date: 2021/07/14 01:40
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
Hi,
I'm the co-author of this draft and I have tried to convince the rest of
the co-authors that encoding the new Generic Metric sub-TLV only as a
application independent value is wrong. Unfortunately, my efforts have
failed. As a result, although unwillingly, I have to express my opinions
here and let the WG decide.
1) The usage of the Generic Metric sub-TLV is likely going to be
associated with the applications, Flex-algo being the first one. Generic
Metric sub-TLV can not be used by IGP's native calculation. So having
Generic Metric being encoded only in legacy TLV does not make much sense.
2) TE-metric is defined as application specific attribute by
RFC 8919/8920 and can be advertised in ASLA. The application specific
value advertisement of TE-metric has been already proved in the field.
Generic Metric is semantically very similar to TE-metric, so I see no
reason why application specific encoding should not be supported.
3) Flex-algo specification mandates the usage of the ASLA attributes and
all of the attributes that we are using for flex-algo so far are encoded
in ALSA. Encoding the Generic Metric outside of ALSA violates that
principle.
4) RFC 8919/8920 violation brought by Les below.
thanks,
Peter
On 13/07/2021 17:39, Les Ginsberg (ginsberg) wrote:
> Draft authors -
>
> I note that the new version has altered the advertisement of the Generic Metric sub-TLV so that it is no longer supported in the ASLA sub-TLV.
> This is in direct violation of RFC 8919/8920.
>
> For example, https://www.rfc-editor.org/rfc/rfc8919.html#section-6.1 states:
>
> "New applications that future documents define to make use of the advertisements defined in this document MUST NOT make use of legacy advertisements."
>
> Flex-algo is a "new application" in the scope of these RFCs.
>
> Please correct this error.
>
> Thanx.
>
>     Les
>
>
>> -----Original Message-----
>> From: Lsr  On Behalf Of [email-masked]
>> Sent: Monday, July 12, 2021 9:12 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Link State Routing WG of the IETF.
>>
>>          Title           : Flexible Algorithms: Bandwidth, Delay, Metrics and
>> Constraints
>>          Authors         : Shraddha Hegde
>>                            William Britto A J
>>                            Rajesh Shetty
>>                            Bruno Decraene
>>                            Peter Psenak
>>                            Tony Li
>>     Filename        : draft-ietf-lsr-flex-algo-bw-con-01.txt
>>     Pages           : 27
>>     Date            : 2021-07-12
>>
>> Abstract:
>>     Many networks configure the link metric relative to the link
>>     capacity.  High bandwidth traffic gets routed as per the link
>>     capacity.  Flexible algorithms provides mechanisms to create
>>     constraint based paths in IGP.  This draft documents a generic metric
>>     type and set of bandwidth related constraints to be used in Flexible
>>     Algorithms.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
>>
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-bw-con-01
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lsr
>
>
_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 19 Jul 2021 18:04:42 +0000

Hi All,

Generic metric was allowed to be advertised in TLV 22/ ELO LSA 
as well as ASLA TLV before the draft was called for adoption.
During the recent WG adoption review, it was pointed out that
ASLA architecture does not allow an attribute to be advertised 
in both application-specific and application-independent manner.

As a result of this Generic metric has been made an 
application-independent attribute in the latest version.
The reasons are below

1.Generic metric is required to be advertised in an application-independent manner
that is metric-type 128 is advertised for a link and any application 
like flex-algo, SR-TE, RSVP LFA can make use of it.
Metric has scope outside of an IGP domain. It gets advertised
in BGP-LU and gets accumulated across domains. 
There are many usecases that will benefit from advertising generic-metric
in an application-independent manner.

2.The recent case of te-metric usecase that I came across 
where ASLA was being used, really wanted to
use a different metric-type for flex-algo and not really 
different values for same metric type.
(Peter, coincidently we may be talking of the same recent 
usecase which you claimed to be using ASLA)

3.Advertising generic metric in an application independent manner in legacy TLV 22 and ELO LSA
does not violate RFC 8919/8920. Application-independent attributes are not expected to use RFC 8919/8920
mechanisms. Generic metric is like igp cost. IGP-cost is never advertised in ASLA but it gets used in flex-algo
and generic-metric is being modeled based on igp-cost.
As currently written, this document is compliant to every RFC and draft that has
been out there and not violating any of them.

4.Generic metric is very flexible. It allows for finest granularity of
metric advertisement. 
Usecase:
Lets say flex-algo 128 wants to use metric-type 128 and flex-algo 129
wants to use metric-type 129. An year later operator decides to deploy 
SR-TE with red LSPs using metric-type 128 and Blue LSPs using metric-type 129.
 
Using generic metric in application-independent manner:
1.configure metric-type 128 and 129 and value pair on each link
2. set flex-algo 128 FAD to use metric-type 128 and flex-algo FAD 129 to use metric-type 129
3. An year later configure Red LSPs to use metric-type 128 and Blue LSPs to use metric-type 129

Using generic metric with ASLA:
1. Define user defined bit-masks for flex-algo 128 and flex-algo 129 and configure on every router
2. configure metric-type 128 and 129 on every link
3. An year later, define user defined bit masks  for SR-TE Red LSPs and SR-TE blue LSPs
4. Configure the bit masks on all head-end routers
5. Associate the new bit masks with the metric-types on every router on every link.

The most common cases look operationally very complex with ASLA while they look very
simple operationally with generic-metric being advertised in an application-independent
manner. It looks reasonable approach to allow the option of application-independent
advertisements for operators who are looking to simplify operations.

In order to decide  how the generic-metric should be advertised, it would
be good to get input from the WG on below point.
 Do you have usecases in mind that you would like to deploy that cannot be solved
with advertising generic-metric in an application-independent manner?

Looking forward to more discussions during LSR WG meeting.

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Sunday, July 18, 2021 2:11 AM
To: ppsenak=[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re:[Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[External Email. Be cautious of content]

Dear All,

Regards,
Greg Mirsky
------------------Original Mail------------------
Sender: PeterPsenak
To: Les Ginsberg (ginsberg);[email-masked];[email-masked];
Date: 2021/07/14 01:40
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
Hi,
I'm the co-author of this draft and I have tried to convince the rest of the co-authors that encoding the new Generic Metric sub-TLV only as a application independent value is wrong. Unfortunately, my efforts have failed. As a result, although unwillingly, I have to express my opinions here and let the WG decide.
1) The usage of the Generic Metric sub-TLV is likely going to be associated with the applications, Flex-algo being the first one. Generic Metric sub-TLV can not be used by IGP's native calculation. So having Generic Metric being encoded only in legacy TLV does not make much sense.
2) TE-metric is defined as application specific attribute by RFC 8919/8920 and can be advertised in ASLA. The application specific value advertisement of TE-metric has been already proved in the field.
Generic Metric is semantically very similar to TE-metric, so I see no reason why application specific encoding should not be supported.
3) Flex-algo specification mandates the usage of the ASLA attributes and all of the attributes that we are using for flex-algo so far are encoded in ALSA. Encoding the Generic Metric outside of ALSA violates that principle.
4) RFC 8919/8920 violation brought by Les below.
thanks,
Peter
On 13/07/2021 17:39, Les Ginsberg (ginsberg) wrote:
> For example, https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8919.html*section-6.1__;Iw!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx4pA8WB0$  states:
>
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
>> tf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2Ku
>> E9gbrUscAHAlbWXMsiRouKOFbEWkxyFWi9bo$
>>
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
>> ft-ietf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd
>> 2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkxwbtJYtY$
>>
>> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-i
>> etf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo
>> 2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_rX175v$
>>
>>
>> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!N
>> Et6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx6
>> GQqw0z$
>>
>>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>> __;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOF
>> bEWkx_ne0I9C$
>
>
_______________________________________________
Lsr mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_ne0I9C$

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 19 Jul 2021 18:44:16 +0000

Shraddha -

With respect, the issue here is very simple and does not warrant the long email.

As per RFC 8919/8920, any link attribute used by applications defined with an ASLA bit (other than the legacy applications RSVP-TE, SRTE, and LFA) MUST use ASLA advertisements.
As you propose to use the new metric for Flex-Algo - which is a "new application" with an ASLA assigned bit - you MUST support ASLA encoding.
You can also support encoding in a sub-TLV under TLV22 (etc.).

There is nothing to discuss here - it is simply a matter of conforming to the normative statements in existing RFCs.

Please correct the draft as requested.

   Les

> From: Shraddha Hegde <[email-masked]>
> Sent: Monday, July 19, 2021 11:05 AM
> To: [email-masked]; ppsenak=[email-masked];
> [email-masked]
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; draft-ietf-lsr-flex-algo-
> [email-masked]
> Subject: RE: Re:[Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
> 
> Hi All,
> 
> I concur with the arguments presented by Les and Peter. Perhaps the Editors
> of the WG draft will update the document accordingly.
> 
> Regards,
> Greg Mirsky
> 预研标准部/有线研究院/有线产品经营部  Standard Preresearch
> Dept./Wireline Product R&D Institute/Wireline Product Operation Division
> I'm the co-author of this draft and I have tried to convince the rest of the co-
> authors that encoding the new Generic Metric sub-TLV only as a application
> independent value is wrong. Unfortunately, my efforts have failed. As a
> result, although unwillingly, I have to express my opinions here and let the
> WG decide.
> 1) The usage of the Generic Metric sub-TLV is likely going to be associated
> with the applications, Flex-algo being the first one. Generic Metric sub-TLV
> can not be used by IGP's native calculation. So having Generic Metric being
> encoded only in legacy TLV does not make much sense.
> 2) TE-metric is defined as application specific attribute by RFC 8919/8920 and
> can be advertised in ASLA. The application specific value advertisement of TE-
> metric has been already proved in the field.
> Generic Metric is semantically very similar to TE-metric, so I see no reason
> why application specific encoding should not be supported.
> 3) Flex-algo specification mandates the usage of the ASLA attributes and all
> of the attributes that we are using for flex-algo so far are encoded in ALSA.
> Encoding the Generic Metric outside of ALSA violates that principle.
> > I note that the new version has altered the advertisement of the Generic
> Metric sub-TLV so that it is no longer supported in the ASLA sub-TLV.
> > For example, https://urldefense.com/v3/__https://www.rfc-
> editor.org/rfc/rfc8919.html*section-6.1__;Iw!!NEt6yMaO-
> gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx4
> pA8WB0$  states:
> >
> > "New applications that future documents define to make use of the
> advertisements defined in this document MUST NOT make use of legacy
> advertisements."
> >
> >> Et6yMaO-
> gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx6
> >> GQqw0z$
> >>
> >>
> >> __;!!NEt6yMaO-
> gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOF
> >> bEWkx_ne0I9C$
> >
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!
> !NEt6yMaO-
> gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_
> ne0I9C$

---

From: Peter Psenak <[email-masked]>
Date: Mon, 19 Jul 2021 21:08:39 +0200

Hi Shraddha,

> and generic-metric is being modeled based on igp-cost.

IGP cost is part of the fixed portion of the link advertisement in ISIS, 
it's not a link attribute as such. I have no problem if you have a valid 
use case for which you want to advertise the new generic metric in an 
app independent way. But for flex-algo, or any new application, you MUST 
advertise it in ASLA.

Also having the app specific advertisement for metric 128 adds value 
IMHO. So instead of advertising new metric types, you advertise 
different values of the same type per app. Provides more flexibility.

> 1. Define user defined bit-masks for flex-algo 128 and flex-algo 129 and configure on every router

there is no need to do any per algo bit mask assignments. You simply 
advertise metric 128 and metric 129 in ASLA with felx-algo bit set.

> 4. Configure the bit masks on all head-end routers

again no need to do (3) and (4). All you need to do is to add the SR-TE 
bit to the ASLA advertisement that you are already doing for flex-algo.

> 5. Associate the new bit masks with the metric-types on every router on every link.

no need to do that.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 20 Jul 2021 17:21:06 +0000

Speaking as WG member:

I agree with Les. The Generic Metric MUST be advertised as an ASLA for usage in Flex Algorithm. Additionally, it may be advertised as a sub-TLV in IS-IS link TLVs. However, the latter encoding really shouldn't be used for new applications (at least that is my reading of RFC 8919). 

For OSPF, I'd certainly hope one wouldn't originate additional LSAs when an ASLA can support the legacy applications with the ASLA mask. 

Thanks,
Acee

On 7/19/21, 2:45 PM, "Lsr on behalf of Les Ginsberg (ginsberg)" <[email-masked] on behalf of ginsberg=[email-masked]> wrote:

    Shraddha -

       Les

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 20 Jul 2021 22:59:14 -0400

Ketan brought up this  valid concern during the adoption call in May.

This is a valid concern and I am in agreement with Acee, Les, and Peter
that the Generic metric TLV for Flex Algorithm  is not a legacy
advertisement and is application specific.

Therefore, this Generic Metric defined in this draft, as it’s not legacy
per RFC 8920 OSPF ASLA and RFC 8919 ISIS ASLA, and as is a new application,
it MUST use ASLA advertisement.

I would support progressing this draft if the authors are willing to use
ALSA for this use application with Flex Algorithm and not application
independent path.

Kind Regards

Gyan

On Tue, Jul 20, 2021 at 1:21 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> Speaking as WG member:
>
> I agree with Les. The Generic Metric MUST be advertised as an ASLA for
> usage in Flex Algorithm. Additionally, it may be advertised as a sub-TLV in
> IS-IS link TLVs. However, the latter encoding really shouldn't be used for
> new applications (at least that is my reading of RFC 8919).
>
> For OSPF, I'd certainly hope one wouldn't originate additional LSAs when
> an ASLA can support the legacy applications with the ASLA mask.
>
> Thanks,
> Acee
>
> On 7/19/21, 2:45 PM, "Lsr on behalf of Les Ginsberg (ginsberg)" <
> [email-masked] on behalf of ginsberg=[email-masked]>
> wrote:
>
>     Shraddha -
>
>     As per RFC 8919/8920, any link attribute used by applications defined
> with an ASLA bit (other than the legacy applications RSVP-TE, SRTE, and
> LFA) MUST use ASLA advertisements.
>     As you propose to use the new metric for Flex-Algo - which is a "new
> application" with an ASLA assigned bit - you MUST support ASLA encoding.
>     There is nothing to discuss here - it is simply a matter of conforming
> to the normative statements in existing RFCs.
>
>     > 1.Generic metric is required to be advertised in an
> application-independent
>     > manner
>     > 3.Advertising generic metric in an application independent manner in
> legacy
>     > TLV 22 and ELO LSA
>     > does not violate RFC 8919/8920. Application-independent attributes
> are not
>     > expected to use RFC 8919/8920
>     > mechanisms. Generic metric is like igp cost. IGP-cost is never
> advertised in
>     > ASLA but it gets used in flex-algo
>     > As currently written, this document is compliant to every RFC and
> draft that
>     > has
>     > SR-TE with red LSPs using metric-type 128 and Blue LSPs using
> metric-type
>     > 129.
>     >
>     > 2. set flex-algo 128 FAD to use metric-type 128 and flex-algo FAD
> 129 to use
>     > metric-type 129
>     > 3. An year later configure Red LSPs to use metric-type 128 and Blue
> LSPs to
>     > use metric-type 129
>     >
>     > 1. Define user defined bit-masks for flex-algo 128 and flex-algo 129
> and
>     > configure on every router
>     > 3. An year later, define user defined bit masks  for SR-TE Red LSPs
> and SR-TE
>     > blue LSPs
>     > 5. Associate the new bit masks with the metric-types on every router
> on
>     > every link.
>     >
>     > simple operationally with generic-metric being advertised in an
> application-
>     > independent
>     > manner. It looks reasonable approach to allow the option of
> application-
>     > independent
>     >  Do you have usecases in mind that you would like to deploy that
> cannot be
>     > solved
>     > Cc: [email-masked];
> [email-masked]
>     > To: Les Ginsberg (ginsberg);[email-masked]
> ;draft-ietf-lsr-flex-algo-bw-
>     > [email-masked];
>     > Date: 2021/07/14 01:40
> associated
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Jul 2021 16:05:48 +0200

Hi Shraddha,

> legacy TLV 22 and ELO LSA

To me it does violate section 12 of IGP Flexible Algorithm
draft-ietf-lsr-flex-algo-17

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17#section-12

12.  Advertisement of Link Attributes for Flex-Algorithm

   Various link attributes may be used during the Flex-Algorithm path
   calculation.  For example, include or exclude rules based on link
   affinities can be part of the Flex-Algorithm definition as defined in
   Section 6 and Section 7.

*Link attribute advertisements that are to be used during Flex-   Algorithm
calculation MUST use the Application-Specific Link   Attribute (ASLA)
advertisements defined in [RFC8919] or [RFC8920],*
*   ...*

Many thx,
Robert.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 22 Jul 2021 10:19:37 +0000

Hi Shraddha,

Thanks for your detailed email explanation.

I was one of the WG members who indicated that Generic Metric not be advertised in the base as well as ASLA encodings. But what you've missed out was that I asked for it to be used in ASLA alone and not as application independent.

Generic metric not only allows advertisement of existing IGP metric types but also introduces new ones e.g. Bandwidth. There will be others/more. We definitely do need the ability to have application specific values for these various Generic Metric types. One use-case is that there be a different reference b/w or threshold yardstick for FlexAlgo and SR Policy. The appl-independent proposal will require the specification and provisioning of new/additional user-defined Generic Metric types - potentially one per application (more if we consider different flex-algo) when we need different TE or B/W metric value per application. While advertising it in ASLA allows the same b/w metric type to be used with different values for FlexAlgo and SR Policy.

Regarding the ASLA encoding, there is nothing that prevents the same Generic Metric type/value being shared across applications. We have already implementations that do so for FlexAlgo. This is a solved problem.

Therefore, I still do believe that Generic Metric is application specific - as was originally in the draft version that the WG adopted.

Coming to Generic Metric in BGP, I agree with the use-case. However, that is orthogonal to how it is advertised in IGPs. On the contrary, having too many user-defined and standard Generic Metric types (as you've proposed) make things more challenging to reconcile at the BGP level when we have a mix of types.

Like other WG members, I do still believe that Generic Metric advertisement in ASLA *alone* would be the right way to go as far as having an extensible and generic encoding approach for the IGPs.

Thank,

Ketan

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Shraddha Hegde
Sent: 19 July 2021 23:35
To: [email-masked]; ppsenak=[email-masked]; [email-masked]
Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

Hi All,

Generic metric was allowed to be advertised in TLV 22/ ELO LSA as well as ASLA TLV before the draft was called for adoption.

During the recent WG adoption review, it was pointed out that ASLA architecture does not allow an attribute to be advertised in both application-specific and application-independent manner.

As a result of this Generic metric has been made an application-independent attribute in the latest version.

The reasons are below

1.Generic metric is required to be advertised in an application-independent manner that is metric-type 128 is advertised for a link and any application like flex-algo, SR-TE, RSVP LFA can make use of it.

Metric has scope outside of an IGP domain. It gets advertised in BGP-LU and gets accumulated across domains.

There are many usecases that will benefit from advertising generic-metric in an application-independent manner.

2.The recent case of te-metric usecase that I came across where ASLA was being used, really wanted to use a different metric-type for flex-algo and not really different values for same metric type.

(Peter, coincidently we may be talking of the same recent usecase which you claimed to be using ASLA)

3.Advertising generic metric in an application independent manner in legacy TLV 22 and ELO LSA does not violate RFC 8919/8920. Application-independent attributes are not expected to use RFC 8919/8920 mechanisms. Generic metric is like igp cost. IGP-cost is never advertised in ASLA but it gets used in flex-algo and generic-metric is being modeled based on igp-cost.

As currently written, this document is compliant to every RFC and draft that has been out there and not violating any of them.

4.Generic metric is very flexible. It allows for finest granularity of metric advertisement.

Usecase:

Lets say flex-algo 128 wants to use metric-type 128 and flex-algo 129 wants to use metric-type 129. An year later operator decides to deploy SR-TE with red LSPs using metric-type 128 and Blue LSPs using metric-type 129.

1.configure metric-type 128 and 129 and value pair on each link 2. set flex-algo 128 FAD to use metric-type 128 and flex-algo FAD 129 to use metric-type 129 3. An year later configure Red LSPs to use metric-type 128 and Blue LSPs to use metric-type 129

1. Define user defined bit-masks for flex-algo 128 and flex-algo 129 and configure on every router 2. configure metric-type 128 and 129 on every link 3. An year later, define user defined bit masks  for SR-TE Red LSPs and SR-TE blue LSPs 4. Configure the bit masks on all head-end routers 5. Associate the new bit masks with the metric-types on every router on every link.

The most common cases look operationally very complex with ASLA while they look very simple operationally with generic-metric being advertised in an application-independent manner. It looks reasonable approach to allow the option of application-independent advertisements for operators who are looking to simplify operations.

In order to decide  how the generic-metric should be advertised, it would be good to get input from the WG on below point.

Do you have usecases in mind that you would like to deploy that cannot be solved with advertising generic-metric in an application-independent manner?

Rgds

Shraddha

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

To: ppsenak=[email-masked]<mailto:ppsenak=[email-masked]>; [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear All,

Regards,

Greg Mirsky

E: [email-masked]<mailto:[email-masked]>

www.zte.com.cn<http://www.zte.com.cn>

------------------Original Mail------------------

Sender: PeterPsenak

Date: 2021/07/14 01:40

Hi,

thanks,

Peter

> For example, https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8919.html*section-6.1__;Iw!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx4pA8WB0$<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8919.html*section-6.1__;Iw!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx4pA8WB0$>  states:

>> From: Lsr  On Behalf Of [email-masked]<mailto:[email-masked]>

>> To: [email-masked]<mailto:[email-masked]>

>> Cc: [email-masked]<mailto:[email-masked]>

>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ie>

>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/dra>

>> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-i<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-i>

>> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!N<https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet-drafts/__;!!N>

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

Lsr mailing list

[email-masked]<mailto:[email-masked]>

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_ne0I9C$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_ne0I9C$>

Lsr mailing list

[email-masked]<mailto:[email-masked]>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 22 Jul 2021 17:27:59 +0000

Acee,

I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919.

Section 6.1 of RFC 8919 says:

" New applications that future documents define to make use of the
   advertisements defined in this document MUST NOT make use of legacy
   advertisements.  This simplifies deployment of new applications by
   eliminating the need to support multiple ways to advertise attributes
   for the new applications."

Section 3 of RFC 8919 defines legacy advertisements. The definition of legacy 
advertisements does not include new attributes such as 
generic metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not 
violate RFC 8919

Relevant text from Section 3 of RFC 8919 is included below for convenience.

                                                                      Ron

RFC 8919, Section 3
---------------------------
3.  Legacy Advertisements

Existing advertisements used in support of RSVP-TE include sub-TLVs
   for TLVs 22, 23, 25, 141, 222, and 223 and TLVs for Shared Risk Link
   Group (SRLG) advertisement.

   Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141,
   222, and 223" registry.

   TLVs are defined in the "TLV Codepoints Registry".

3.1.  Legacy Sub-TLVs

   +======+====================================+
   | Type | Description                        |
   +======+====================================+
   | 3    | Administrative group (color)       |
   +------+------------------------------------+
   | 9    | Maximum link bandwidth             |
   +------+------------------------------------+
   | 10   | Maximum reservable link bandwidth  |
   +------+------------------------------------+
   | 11   | Unreserved bandwidth               |
   +------+------------------------------------+
   | 14   | Extended Administrative Group      |
   +------+------------------------------------+
   | 18   | TE Default Metric                  |
   +------+------------------------------------+
   | 33   | Unidirectional Link Delay          |
   +------+------------------------------------+
   | 34   | Min/Max Unidirectional Link Delay  |
   +------+------------------------------------+
   | 35   | Unidirectional Delay Variation     |
   +------+------------------------------------+
   | 36   | Unidirectional Link Loss           |
   +------+------------------------------------+
   | 37   | Unidirectional Residual Bandwidth  |
   +------+------------------------------------+
   | 38   | Unidirectional Available Bandwidth |
   +------+------------------------------------+
   | 39   | Unidirectional Utilized Bandwidth  |
   +------+------------------------------------+

       Table 1: Sub-TLVs for TLVs 22, 23, 25,
                 141, 222, and 223

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Tuesday, July 20, 2021 1:21 PM
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]; ppsenak=[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

Speaking as WG member:

Thanks,
Acee

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Jul 2021 18:49:28 +0000

Ron -

With respect, it is hard to read your email without feeling that it is disingenuous.

But, let's cover the relevant points nonetheless.

Point #1:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17#section-12 states:

" Link attribute advertisements that are to be used during Flex-
   Algorithm calculation MUST use the Application-Specific Link
   Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..."

As the new generic-metric is intended for use by flex-algo it needs to conform to this normative statement.

Point #2:

RFC 8919 and 8920 were written to address ambiguities associated with the use of multiple applications.
The Introduction sections of both documents discuss this in some detail.

The clear intent is to make use of ASLA going forward - not to restrict ASLA only to the set of link attributes defined at the time of the writing of the RFCs. Failure to do so would reintroduce the same set of issues that RFC 8919/8920 were written to address.
Your attempt to infer that because Generic-Metric was not defined at the time that RFC 8919/8920 were written that the RFCs don’t apply to it makes no sense.
ASLA is in fact a revision to the link attribute architecture and is meant to be used going forward.

The more appropriate question to ask is why we need to define a legacy style sub-TLV for new link attributes? Ketan has made this point in his post on this thread and I have sympathy with his position.

We do understand that legacy applications such as RSVP-TE may continue to be deployed in networks for some time to come. It is not reasonable to expect that legacy application implementations will be updated to use ASLA, which is why I do not object to defining a legacy style encoding for Generic Metric if folks believe that legacy applications may be enhanced to support new link attributes. 

I strongly disagree with your interpretation that ASLA is limited only to the code points defined in RFC 8919/8920.

   Les

> From: Ron Bonica <rbonica=[email-masked]>
> Sent: Thursday, July 22, 2021 10:28 AM
> To: Acee Lindem (acee) <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; Shraddha Hegde <[email-masked]>;
> [email-masked]; Peter Psenak (ppsenak) <[email-masked]>;
> [email-masked]
> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
> 
> Acee,
> 
> To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>;
> Shraddha Hegde <[email-masked]>; [email-masked];
> ppsenak=[email-masked]; [email-masked]
> usage in Flex Algorithm. Additionally, it may be advertised as a sub-TLV in IS-
> IS link TLVs. However, the latter encoding really shouldn't be used for new
> applications (at least that is my reading of RFC 8919).
> 
> For OSPF, I'd certainly hope one wouldn't originate additional LSAs when an
> ASLA can support the legacy applications with the ASLA mask.
> 
> Thanks,
> Acee
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 22 Jul 2021 15:44:39 -0400

As stated nicely by Les, the  goal and intent of RFC 8919 and 8920 as
stated clearly was meant to fix a ambiguities  related to cases where
multiple applications RSVP-TE, SR, Flex Algo making use of link attributes
by creating ASLA for a  list of link attributes sub-tlv’s that existed at
time of writing the document, however moving forward that all new link
attributes defined MUST now be advertised using ASLA sub tlv.

By not doing do you are perpetuating the problem all over again.

The chairs and other in the WG would like to draw a line in the sand that
any new link attribute MUST be advertised using ASLA SUB-TLV encoding.

RFC 8919 -Last paragraph in the introduction

   This document defines extensions that address these issues.  Also, as
   evolution of use cases for link attributes can be expected to
   continue in the years to come, this document defines a solution that
   is easily extensible to the introduction of new applications and new
   use cases.

RFC 8920- Last paragraph in the introduction

   This document defines extensions that address these issues.  Also, as
   evolution of use cases for link attributes can be expected to
   continue in the years to come, this document defines a solution that
   is easily extensible for the introduction of new applications and new
   use cases.

The key is the extensibility of RFC 8919 and RFC   8920 for all future
link attributes and not just the ones defined when the draft was
written.

Kind Regards

Gyan

On Thu, Jul 22, 2021 at 2:49 PM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> states:
> The clear intent is to make use of ASLA going forward - not to restrict
> ASLA only to the set of link attributes defined at the time of the writing
> of the RFCs. Failure to do so would reintroduce the same set of issues that
> RFC 8919/8920 were written to address.
> Your attempt to infer that because Generic-Metric was not defined at the
> time that RFC 8919/8920 were written that the RFCs don’t apply to it makes
> no sense.
> The more appropriate question to ask is why we need to define a legacy
> style sub-TLV for new link attributes? Ketan has made this point in his
> post on this thread and I have sympathy with his position.
>
> We do understand that legacy applications such as RSVP-TE may continue to
> be deployed in networks for some time to come. It is not reasonable to
> expect that legacy application implementations will be updated to use ASLA,
> which is why I do not object to defining a legacy style encoding for
> Generic Metric if folks believe that legacy applications may be enhanced to
> support new link attributes.
>
> I strongly disagree with your interpretation that ASLA is limited only to
> the code points defined in RFC 8919/8920.
>
>    Les
>
>
> an
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Ron Bonica <[email-masked]>
Date: Fri, 23 Jul 2021 04:13:19 +0000

Les,

Please, let us avoid discussion of whether my message is disingenuous. As Acee will agree, discussion of my internal motivations and moral deficiencies is beyond the scope of the LSR WG.

Now, let us address my point and your counter points. My point was that draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919. Nothing more, nothing less.

In your counterpoint #1, you point out tension between draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo. While this point deserves discussion, it is orthogonal to my point. It is entirely possible that both of the following statements are true:

- draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919
- there is tension between draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo

In your counterpoint #2, you talk about the "clear intent" of RFC 8919. Section 6.1 of RFC 8919 reduces that intent to a few very clear normative statements. Draft-ietf-lsr-flex-algo-bw-con does not violate any of those normative statements. Therefore, it does not violate RFC 8919.

You may say:

- Section 6.1 should have included more prohibitions
- The authors had additional prohibitions in mind when they wrote the draft, but failed to add them to Section 6.1

That's all fine, but the community agreed only to the words on the page, not the authors larger intent.

                                                                                                      Ron

-----Original Message-----
From: Les Ginsberg (ginsberg) <ginsberg=[email-masked]> 
Sent: Thursday, July 22, 2021 2:49 PM
To: Ron Bonica <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]; Peter Psenak (ppsenak) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

Ron -

Point #1:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$  states:

Point #2:

   Les

> Section 3 of RFC 8919 defines legacy advertisements. The definition of 
> legacy advertisements does not include new attributes such as generic 
> metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not violate RFC 
> 8919
>
> usage in Flex Algorithm. Additionally, it may be advertised as a 
> sub-TLV in IS- IS link TLVs. However, the latter encoding really 
> shouldn't be used for new applications (at least that is my reading of RFC 8919).
>
> For OSPF, I'd certainly hope one wouldn't originate additional LSAs 
> when an ASLA can support the legacy applications with the ASLA mask.
>
> Thanks,
> Acee
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 23 Jul 2021 02:12:09 -0400

Ron

I agree the way the RFC 8919 and 8920 are written it is more of an intent
by the authors based on normative language as you have stated and not
violating the specification.

I think it does sound like that future  attributes developed the authors
kept it open to developers be application independent and not a MUST
normative language for ASLA unfortunately it seems created a loophole,
however I am not sure why it was written that way as it defeats the goal
and purpose of RFC 8919 and RFC 8920.

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 12:13 AM Ron Bonica <rbonica=
[email-masked]> wrote:

> Les,
>
> Please, let us avoid discussion of whether my message is disingenuous. As
> Acee will agree, discussion of my internal motivations and moral
> deficiencies is beyond the scope of the LSR WG.
>
> Now, let us address my point and your counter points. My point was that
> draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919. Nothing more,
> nothing less.
>
> In your counterpoint #1, you point out tension between
> draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo. While this
> point deserves discussion, it is orthogonal to my point. It is entirely
> possible that both of the following statements are true:
>
> In your counterpoint #2, you talk about the "clear intent" of RFC 8919.
> Section 6.1 of RFC 8919 reduces that intent to a few very clear normative
> statements. Draft-ietf-lsr-flex-algo-bw-con does not violate any of those
> normative statements. Therefore, it does not violate RFC 8919.
>
> You may say:
>
> - The authors had additional prohibitions in mind when they wrote the
> draft, but failed to add them to Section 6.1
>
> To: Ron Bonica <[email-masked]>; Acee Lindem (acee) <[email-masked]>;
> Shraddha Hegde <[email-masked]>; [email-masked]; Peter
> Psenak (ppsenak) <[email-masked]>; [email-masked]
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Jul 2021 06:44:17 +0000

Ron -

Dealing simply with the language in the RFCs, both RFCs discuss the problems the RFCs are aimed at solving in the Introduction. Those problems are not specific to the set of link attributes defined at the time of writing the RFCs. Which is why the Introduction concludes with:

"...as evolution of use cases for link attributes can be expected to
   continue in the years to come, this document defines a solution that
   is easily extensible to the introduction of new applications and new
   use cases."

Which is exactly what is being introduced in draft-ietf-lsr-flex-algo-bw-con.

There is then the more important question as to why new attributes - and Generic Metric specifically - should NOT follow the ASLA model. The same issues discussed in the RFCs that motivated the ASLA solution certainly apply to Generic Metric. This has been made clear by others in their responses to this thread - and each of the arguments Shraddha has made have been countered by responses in this thread. The substance of what is being discussed here is not (and should not be) whether there is a violation of the "letter of the law" - but whether there is a behavioral aspect of the new attribute that makes ASLA unsuitable. On that point I think clear and cogent arguments have been made that ASLA is appropriate and necessary.

If the WG feels that more explicit language is needed to prevent such debates in the future, I am happy to work on an Errata - but that isn’t the substance of this discussion and I would much prefer that any future posts on this thread focus on the substantive issues. We can address improving the RFC language separately.

   Les

> Sent: Thursday, July 22, 2021 9:13 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee)
> <[email-masked]>; Shraddha Hegde <[email-masked]>;
> Acee will agree, discussion of my internal motivations and moral deficiencies
> is beyond the scope of the LSR WG.
> 
> In your counterpoint #1, you point out tension between draft-ietf-lsr-flex-
> algo-bw-con and draft-ietf-lsr-flex-algo. While this point deserves discussion,
> it is orthogonal to my point. It is entirely possible that both of the following
> statements are true:
> 
> To: Ron Bonica <[email-masked]>; Acee Lindem (acee)
> <[email-masked]>; Shraddha Hegde <[email-masked]>;
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-
> YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$
> states:
> 
> The clear intent is to make use of ASLA going forward - not to restrict ASLA
> only to the set of link attributes defined at the time of the writing of the
> RFCs. Failure to do so would reintroduce the same set of issues that RFC
> 8919/8920 were written to address.
> The more appropriate question to ask is why we need to define a legacy style
> sub-TLV for new link attributes? Ketan has made this point in his post on this
> thread and I have sympathy with his position.
> 
> which is why I do not object to defining a legacy style encoding for Generic
> Metric if folks believe that legacy applications may be enhanced to support
> new link attributes.
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 23 Jul 2021 10:18:44 +0200

Hi Ron,

keeping the normative statements aside.

We are defining a Generic Metric TLV.

1. The first and only defined usage at this point is for Flex-algo.

2. Generic Metric is not something that must be defined as application 
independent, on the contrary, it's a value that is either assigned by 
operator or computed somehow. Advertising application specific values 
not only make sense, but would add value. TE metric is an example which 
is very close to Generic Metric and is supported in ASLA.

3. Flex-algo is an application from the ASLA framework perspective and 
so far is only using ASLA encoded link attributes. It would make sense 
to continue to do so for Generic Metric.

4. If you feel you need the Generic Metric also as an application 
independent value, I'm fine, although I do not see the immediate use case.

Given the above, would not you thing that advertising Generic Metric in 
ASLA make sense?

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 23 Jul 2021 14:12:59 +0000

Hi Ron, 

So perhaps, generic metric is not a legacy advertisement as strictly defined. However, we don't want to go down the path of treating new attributes in the same manner as legacy attributes. It seems the discussion is progressing and hopefully we will have a resolution. 

Thanks,
Acee

On 7/22/21, 1:28 PM, "Ron Bonica" <rbonica=[email-masked]> wrote:

    Acee,

                                                                          Ron

    RFC 8919, Section 3

    3.1.  Legacy Sub-TLVs

    -----Original Message-----
    From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
    Sent: Tuesday, July 20, 2021 1:21 PM
    To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]; ppsenak=[email-masked]; [email-masked]
    Cc: [email-masked]
    Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

    Speaking as WG member:

    Thanks,
    Acee

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 23 Jul 2021 11:26:15 -0400

I believe the gap is whether or not the Generic metric is like maximum
bandwidth link attribute which is application independent and based on the
use case in this draft of the WG can be convinced that this use case is for
application independent.

In RFC 8919 and RFC 8920 the normative language was chosen precisely for
that purpose so that on a case by case basis for a an link attribute to be
deemed ASLA or application independent.

Kind Regards

Gyan

On Thu, Jul 22, 2021 at 3:44 PM Gyan Mishra <[email-masked]> wrote:

> The key is the extensibility of RFC 8919 and RFC   8920 for all future link attributes and not just the ones defined when the draft was written.
>
>
> Kind Regards
>
> Gyan
>
>
>
>
>
>
>> sub-TLV in IS-
>> when an

*Gyan Mishra*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Jul 2021 16:34:39 +0000

Gyan –

This question has been clearly addressed by Peter in his most recent post:

<snip>
<end snip>

Please read his email for the complete response.

   Les

From: Gyan Mishra <[email-masked]>
Sent: Friday, July 23, 2021 8:26 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Ron Bonica <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

I believe the gap is whether or not the Generic metric is like maximum bandwidth link attribute which is application independent and based on the use case in this draft of the WG can be convinced that this use case is for application independent.

In RFC 8919 and RFC 8920 the normative language was chosen precisely for that purpose so that on a case by case basis for a an link attribute to be deemed ASLA or application independent.

Kind Regards

Gyan

On Thu, Jul 22, 2021 at 3:44 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

As stated nicely by Les, the  goal and intent of RFC 8919 and 8920 as stated clearly was meant to fix a ambiguities  related to cases where multiple applications RSVP-TE, SR, Flex Algo making use of link attributes by creating ASLA for a  list of link attributes sub-tlv’s that existed at time of writing the document, however moving forward that all new link attributes defined MUST now be advertised using ASLA sub tlv.

The chairs and other in the WG would like to draw a line in the sand that any new link attribute MUST be advertised using ASLA SUB-TLV encoding.

   use cases.

   use cases.

Kind Regards

Gyan

On Thu, Jul 22, 2021 at 2:49 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
Ron -

Point #1:

Point #2:

   Les

> From: Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>
> To: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg)
> <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
> To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>>;
> Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> ppsenak=[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 23 Jul 2021 14:37:35 -0400

I see it.

Thanks Les & Peter!

Gyan

On Fri, Jul 23, 2021 at 12:34 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Friday, July 23, 2021 8:26 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Acee Lindem (acee) <[email-masked]>; Peter Psenak (ppsenak) <
> [email-masked]>; Ron Bonica <[email-masked]>; Shraddha Hegde <
> [email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>
>
>
>
>
>
>
> *Network Solutions Architect *
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 23 Jul 2021 14:43:54 -0400

Peter

How would you advertise Generic metric link attribute in Flex Algo as both
ASLA and application independent?

For ASLA you set the bit vector but application independent in ASLA what do
you do?

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 4:19 AM Peter Psenak <ppsenak=
[email-masked]> wrote:

> > Please, let us avoid discussion of whether my message is disingenuous.
> As Acee will agree, discussion of my internal motivations and moral
> > We do understand that legacy applications such as RSVP-TE may continue
> to be deployed in networks for some time to come. It is not reasonable to
> > I strongly disagree with your interpretation that ASLA is limited only
> to the code points defined in RFC 8919/8920.
> >
> >     Les
> >
> >
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Jul 2021 19:17:58 +0000

Gyan –

I do not see Generic Metric as an application independent link attribute.
It is an attribute that could be used by multiple applications – in which case you would advertise it in ASLA with the logical OR of all of the applications using it.

The only existing example of an application independent attribute is Maximum Link Bandwidth. This is an attribute of the physical link – independent of the application(s) which use it – in which case https://www.rfc-editor.org/rfc/rfc8919.html#section-4.2.1 applies.
If some other attribute is ever defined which has the same characteristic, then I would expect the same advertisement model to be used.

Metric – in all its forms (whether TE, Delay, or now Generic) – is not a property of the physical link. It is – as Peter has described - a value that is configured or computed to be used by one or more applications. I do not see the need to define an application independent method of advertising it.

If one believes that legacy applications such as RSVP-TE will be extended to support Generic Metric, then a valid argument can be made for supporting advertisement of Generic Metric as a direct sub-TLV in TLVs 22 et al as well as ASLA. I would be somewhat surprised if RSVP-TE were extended in this way, but that is up to the marketplace to decide.

   Les

From: Gyan Mishra <[email-masked]>
Sent: Friday, July 23, 2021 11:44 AM
To: Peter Psenak (ppsenak) <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Ron Bonica <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

Peter

How would you advertise Generic metric link attribute in Flex Algo as both ASLA and application independent?

For ASLA you set the bit vector but application independent in ASLA what do you do?

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 4:19 AM Peter Psenak <ppsenak=[email-masked]<mailto:[email-masked]>> wrote:
Hi Ron,

thanks,
Peter

On 23/07/2021 06:13, Ron Bonica wrote:
> From: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>>
> To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$>  states:
>

Gyan Mishra

M 301 502-1347

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 23 Jul 2021 19:26:47 +0000

Hi Les,

Just a short comment on the RSVP-TE part.

We do have a R bit for RSVP-TE in ASLA SABM so I don’t see the need for the advertisement under TLV 22 (et all) in ISIS.

Similar applies for OSPF too, but in that case, there is a separate TE Opaque LSA that is dedicated for RSVP-TE and hence advertisement as a sub-TLV there that may be considered (as per RFC8920). However, even in OSPF it doesn’t make sense to have it as application independent under the OSPFv2 Extended Link LSA as that is not really used by RSVP-TE today.

Thanks,
Ketan

From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: 24 July 2021 00:48
To: Gyan Mishra <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Cc: [email-masked]; Ron Bonica <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

Gyan –

   Les

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 23, 2021 11:44 AM
To: Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

Peter

Kind Regards

Gyan

thanks,
Peter

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 23 Jul 2021 19:42:02 -0400

Hi Les

I completely agree with all your comments as well as Peter’s  that from an
operators perspective the issue solved by RFC 8918 and 8919, being able to
distinguish which applications are using a link attribute is crucial from
an operators perspective especially in many cases where you are running all
three applications simultaneously.  I

ASLA does solve a real word problem and I think by allowing link attributes
that should use ASLA to be advertised as application independent when they
should not be especially in this case with Generic metric and maybe others
that might come up in the future really goes against the goals of what ASLA
is trying to achieve from an LSR WG standpoint.

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 3:18 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> It is an attribute that could be used by multiple applications – in which
> case you would advertise it in ASLA with the logical OR of all of the
> applications using it.
> Gyan> Understood
>
> The only existing example of an application independent attribute is
> Maximum Link Bandwidth. This is an attribute of the physical link –
> independent of the application(s) which use it – in which case
> https://www.rfc-editor.org/rfc/rfc8919.html#section-4.2.1 applies.
>
>
   Gyan> Agreed

If some other attribute is ever defined which has the same characteristic,
> then I would expect the same advertisement model to be used.
>
> Gyan> Agreed
>
> Metric – in all its forms (whether TE, Delay, or now Generic) – is not a
> property of the physical link. It is – as Peter has described - a value
> that is configured or computed to be used by one or more applications. I do
> not see the need to define an application independent method of advertising
> it.
>

Gyan> Understood.  Completely agree.

> If one believes that legacy applications such as RSVP-TE will be extended
> to support Generic Metric, then a valid argument can be made for supporting
> advertisement of Generic Metric as a direct sub-TLV in TLVs 22 et al as
> well as ASLA. I would be somewhat surprised if RSVP-TE were extended in
> this way, but that is up to the marketplace to decide.
>
> Gyan> I would be surprised as well.  Agreed.
>

> *Sent:* Friday, July 23, 2021 11:44 AM
> *To:* Peter Psenak (ppsenak) <[email-masked]>
> *Cc:* Acee Lindem (acee) <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; Ron Bonica <[email-masked]>; Shraddha Hegde <
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17*section-12__;Iw!!NEt6yMaO-gk!XOCcoj-YdMkhznRiGAo1oeY1A6HMHuk5BDmsYqHAUf_hYgKb9tlp_Umpu3UxZFFM$>
> states:
> >
-- 

*Gyan Mishra*

*M 301 502-1347*