Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

Hi Les,

Thanks for bringing-up this point.
I agree some clarification is required for the case when G bit is set.

In case of automatic metric calculation, there may be some links that are outliers and an operator
may want to statically configure the bandwidth metric for such links. This is the reason, if bandwidth metric
is advertised that MUST be used.

I think providing an I bit at the FAD level would mean network wide and the flexibility of overriding
On a per-link basis won't be possible.

"In case of Interface Group Mode, if all the parallel links have been advertised with the Bandwidth Metric, The individual link Bandwidth Metric MUST be used. If only some links among the parallel links have the Bandwidth Metric advertisement, the Bandwidth Metric for such links MUST be ignored and automatic
Metric calculation MUST be used to derive link metric"

For the case you described where for different flex-algorithms are using some of the parallel links an operator can use below options.
        > Option 1:
        For flex-algo 128, which uses configured bandwidth metric, use user defined metric type 128 and flex-algo 128 to use metric-type 128.
              For Flex-algo 129 use automatic bandwidth metric with G bit set.
          > Option 2:
        For flex-algo 128 use configured  bandwidth metric
              For flex-algo 129 use automatic bandwidth metric.

Let me know what you think.

Rgds
Shraddha

Juniper Business Use Only
-----Original Message-----
From: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Sent: Tuesday, April 9, 2024 1:08 AM
To: Acee Lindem <acee.lindem@gmail.com>; lsr <lsr@ietf.org>
Cc: draft-ietf-lsr-flex-algo-bw-con@ietf.org
Subject: RE: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]

Draft authors -

Regarding Section 5, which defines the rules for deriving Bandwidth metric, Rule #1 states:

"If the Generic Metric sub-TLV with Bandwidth metric type is advertised for the link as described in Section 4, it MUST be used during the Flex-Algorithm calculation."

I think this constraint does not fit all possible use cases.

(Note: For brevity, I am inventing the acronym GMBM to represent "Generic Metric sub-TLV with Bandwidth metric type".)

Consider two nodes A, B that are connected by two parallel links - call them AB-1 and AB-2.

Suppose a customer deploys Flex-Algo 128, which specifies use of Bandwidth Metric, but also uses affinity to exclude link AB-2. Customer configures advertisement of GMBM for link AB-1 - all is working as expected.

Now customer deploys Flex-Algo 129, also specifying use of bandwidth metric, but wants both links (AB-1, AB-2) to be used and wants automatic bandwidth metric calculation to be used so metric automatically adapts to the number of links which are up between A-B. Since there is advertisement of GMBM for link AB-1, automatic bandwidth calculation cannot include Link AB-1 - which means the customer does not have a way to get what is desired without:

o Removing the advertisement of GMBM for AB-1 o Adding automatic bandwidth to the FAD for Flex-Algo 128

This might be quite surprising to a customer - especially if Flex-Algo 128 has been deployed for some time and has been working well.

There are probably multiple ways this limitation could be overcome.

One way would be to define an additional bit in the bandwidth constraint sub-TLVs - call it the I-bit - meaning ignore GMBM even when advertised.
This would specify use of the automated calculation based on the bandwidth of all links even in the presence of an explicit GMBM on one or more members of the Group.

Related to this, I think some clarification as regards the existing G-bit is required i.e., I assume that automatic calculation only includes the bandwidth for links which do not have a GMBM advertisement - but the current text is not clear on that point.

    Les

> -----Original Message-----
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Acee Lindem
> Sent: Monday, February 19, 2024 2:26 PM
> To: lsr <lsr@ietf.org>
> Cc: draft-ietf-lsr-flex-algo-bw-con@ietf.org
> Subject: [Lsr] Working Group Last Call for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-ietf-lsr-flex-algo-bw-con-07
>
>
> This starts the Working Group Last call for draft-ietf-lsr-flex-algo-bw-con-07.
> At least some of the flex algorithm enhancements described in the
> document have been implemented.
>
>  Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!CnWa8DhzclXyIWWfxwRc7drMZ8u5PeYwo-igztZ7ldO2XGqLDqrkUF
> YdW-wHndStV44AccJ0eM9SmM_X$