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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Shraddha -

Thanx for the response.
Please see inline.

> -----Original Message-----
> From: Shraddha Hegde
> Sent: Friday, April 12, 2024 8:02 AM
> To: Les Ginsberg (ginsberg) ; Acee Lindem ; lsr
> Cc: [e-mail]
> Subject: 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.
> 
[LES:] True - but this option is at the control of the operator. They can choose to set the I-bit or not.

> "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"
>
[LES:] This sounds good to me - but I point out this is the equivalent of always having the I-bit set - the only exception being when all links have link bandwidth advertised.

 
> 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.
> 
[LES:] I do not like Option #1. I think user defined metric is intended to allow the user to set metric values based on their own heuristics - not to address this use case.
Option #2 seems consistent with the new text you proposed above - so this seems appropriate to me.

In summary, I think the only open issue is whether to introduce the I-bit or not. Doing so would provide some additional flexibility - but given the other changes you propose I won’t insist.

   Les

> Let me know what you think.
> 
> 
> Rgds
> Shraddha
> 
> Juniper Business Use Only
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <[e-mail]>
> Sent: Tuesday, April 9, 2024 1:08 AM
> To: Acee Lindem <[e-mail]>; lsr <[e-mail]>
> Cc: [e-mail]
> 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 <[e-mail]> On Behalf Of Acee Lindem
> > Sent: Monday, February 19, 2024 2:26 PM
> > To: lsr <[e-mail]>
> > Cc: [e-mail]
> > 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
> > [e-mail]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > _;!!NEt6yMaO-gk!CnWa8DhzclXyIWWfxwRc7drMZ8u5PeYwo-
> igztZ7ldO2XGqLDqrkUF
> > YdW-wHndStV44AccJ0eM9SmM_X$