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) <[email protected]>
Sent: Tuesday, April 9, 2024 1:08 AM
To: Acee Lindem <[email protected]>; lsr <[email protected]>
Cc: [email protected]
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 <[email protected]> On Behalf Of Acee Lindem
> Sent: Monday, February 19, 2024 2:26 PM
> To: lsr <[email protected]>
> Cc: [email protected]
> 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
> [email protected]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!CnWa8DhzclXyIWWfxwRc7drMZ8u5PeYwo-igztZ7ldO2XGqLDqrkUF
> YdW-wHndStV44AccJ0eM9SmM_X$
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
