Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Peter Psenak <[e-mail]>]

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

(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.

So to answer your question, we do NOT intend to make any link attributes 
per flex-algo number.

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:[e-mail]] *On Behalf Of *Acee Lindem (acee)
> *Sent:* Thursday, May 13, 2021 5:09 AM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *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
>