Hi Peter, Thanks for your reply, please see inline:
> -----Original Message----- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Friday, May 14, 2021 5:12 PM > To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee) > <acee=40cisco....@dmarc.ietf.org>; lsr@ietf.org > Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org > Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, > Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02 > > Hi Jie, > > please see the response for one of your questions inline: > > On 14/05/2021 09:52, Dongjie (Jimmy) wrote: > > Hi authors, > > > > I’ve read the latest version of this document and have the following > > comments: > > > > 1.Is the generic metric type applicable to applications other than > > Flex-Algo? If so, it is better to make this clear in the document, or > > perhaps it may be defined separately from the Flex-Algo specific extensions? > > > > 2.The “Exclude Minimum Bandwidth” constraint is compared with the > > maximum link bandwidth to exclude the links from the computation, it > > would be helpful if there is some analysis about how much this can > > help in traffic engineering, such as to reduce the congestion or > > improve the link utilization. One simple example is, if multiple > > Flex-Algos use this constraint to exclude the same set of links, this > > may increase the possibility of congestion on the rest of the links? > > > > Perhaps a more general question is, what would be the benefit of > > introducing bandwidth attribute into Flex-Algo based distributed path > > computation? It is known that bandwidth can be used in centralized > > computation for efficient path placement and resource management, can > > distributed computation with bandwidth constraint achieve the same, or > > is there some advantages compared with centralized computation? > > > > 3.With the automatic metric calculation, it could introduce per > > Flex-Algo link metric value, while the existing Flex-Algo only refers > > to the metric of the link via metric type. Is this the expected behavior? > > Will it be further extended to make other link attributes flex-algo > > specific? > > we need to distinguish between: > > a) flex-algo application specific metric (applies to all flex-algos) > b) flex-algo X specific metric Yes, here I mean flex-algo number specific metric. > > (a) already exists in the form of the ASLA advertisement for delay and > TE-metric. > Bandwidth metric will be no different. > > (b) there has been no such thing as flex-algo X specific metric/attribute > defined > so far. And we are not defining it in this draft either. The draft defines > sub-TLVs > for automatic bandwidth metric calculation. It is the winning FAD for the > Flex-Algorithm X that specifies whether the automatic bandwidth metric > calculation is done or not and it would be rather complicated (certainly > possible) > to have the parameters for such calculation being advertised outside of the > FAD. > > You are right these being part of the FAD may result in the calculated > bandwidth > metric being different for each flex-algo on the same link. > The intention was NOT to have the different per algo bandwidth metric value, > rather it was the convenience of reusing the FAD that was the motivation for > the existing encoding. Understood. Perhaps some text to clarify this would be helpful, such as: The reference bandwidth is considered a global parameter for the network, it is not expected to use different reference bandwidth for different flex-algos. > > So to answer your question, we do NOT intend to make any link attributes per > flex-algo number. This answer is clear, thanks. Best regards, Jie > > thanks, > Peter > > > > > > > > 4.In the reference bandwidth method, the draft says it simplifies the > > management in case the reference bandwidth needs to be changed. Since > > the reference bandwidth applies to the metric calculation of all the > > links in the flex-algo with the same proportion, it seems the change > > of the reference bandwidth will not impact the result of the path > > computation in the flex-algo. In which case the reference bandwidth > > need to be changed? > > > > Best regards, > > > > Jie > > > > *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem > > (acee) > > *Sent:* Thursday, May 13, 2021 5:09 AM > > *To:* lsr@ietf.org > > *Cc:* draft-hegde-lsr-flex-algo-bw-...@ietf.org > > *Subject:* [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: > > Bandwidth, Delay, Metrics and Constraints" - > > draft-hegde-lsr-flex-algo-bw-con-02 > > > > Esteemed Members of the LSR WG, > > > > This begins a 2 week WG adoption call for the following draft: > > > > https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/ > > > > Please indicate your support or objection by May 27^th , 2021. > > > > Authors, please respond to the list indicating whether you are aware > > of any IPR that applies to this draft. > > > > Thanks, > > > > Chris and Acee > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
