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://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
