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: draft-ietf-lsr-flex-algo-bw-...@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 > > 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) <ginsb...@cisco.com> > Sent: Tuesday, April 9, 2024 1:08 AM > To: Acee Lindem <acee.lin...@gmail.com>; lsr <lsr@ietf.org> > Cc: draft-ietf-lsr-flex-algo-bw-...@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-boun...@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-...@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$ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
