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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Shraddha,

Thanks for your further explanation.

I agree if operators design it properly, it could provide the desired result of excluding links whose maximum bandwidth is lower than the specified constraint.

As you said it is not related to the bandwidth management or reservation, thus it is more like a mechanism of relative static network planning, without considering the dynamics of the link bandwidth utilization.

I don't have further questions.

Best regards,
Jie

From: Shraddha Hegde [mailto:[e-mail]]
Sent: Wednesday, May 19, 2021 6:42 PM
To: Dongjie (Jimmy) <[e-mail]>; Acee Lindem (acee) <acee=[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


>[Jie] I can understand how this works for a single Flex-Algo, while my question was if more than one Flex-Algo use
>bandwidth as constraint to exclude some links, what would be the consequence to the network?

Operators design and plan whether one flex-algo is suitable for their network or multiple. The planning also involves
the definition of each flex-algo that is suitable for their network. This network planning exercise has to be done
irrespective of whether bandwidth constraints are used in the flex-algo to ensure traffic distribution is even.

Rgds
Shraddha





Juniper Business Use Only
From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, May 19, 2021 12:59 PM
To: Shraddha Hegde <[e-mail]<mailto:[e-mail]>>; Acee Lindem (acee) <acee=[e-mail]<mailto:acee=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

Thanks for your reply. Please see further inline:

From: Shraddha Hegde [mailto:[e-mail]]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Acee Lindem (acee) <acee=[e-mail]<mailto:acee=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Acee Lindem (acee) <acee=[e-mail]<mailto:acee=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? Many thanks.

Best regards,
Jie

From: Lsr [mailto:[e-mail]] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) <acee=[e-mail]<mailto:acee=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

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?
<Shraddha>Yes. Any application can make use of generic metric including Flex-algo and SR-TE.
                      Sure. I'll add some text to clarify this.

[Jie] OK, thanks.



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?
<Shraddha> The motivation for "Exclude Minimum Bandwidth" is to avoid low capacity links for the high bandwidth traffic. For example if the Flex-algo 128 carries high bw traffic flows of bw greater than 10g, it makes sense to remove 1g links from this flex-algo topology since these links if happen to carry traffic, it  will get congested and traffic will be dropped. The introduction section talks about this motivation.

[Jie] I can understand how this works for a single Flex-Algo, while my question was if more than one Flex-Algo use bandwidth as constraint to exclude some links, what would be the consequence to the network?





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?

<shraddha> Many network operators assign link metric relative to bandwidth of the link and it is an existing practice. The draft is defining new attributes and constraints in order to simplify and automate this process.

It does not propose any bandwidth reservation/ bandwidth management solutions that a centralized computation or distributed RSVP based solutions provide.



[Jie] OK it is clear that this mechanism will not replace the centralized bandwidth computation or distributed bandwidth reservation solutions.  While if the purpose is just to simplify and automate the metric configuration process, , it seems the gain is relatively limited?





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?



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?
<Shraddha> Lets take a hypothetical example. Lets say a network starts with all 1G links and 10G reference bw.
Over the years, many links get upgraded to 10G links and some get upgraded to 100G links. Using a 10G reference bandwidth will not be feasible and reference bw need to get increased to a value > 100G.

[Jie] Yes this is a valid case of changing the reference bandwidth, although it happens in a relative large time scale.

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]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QjpfqmfDtSmB967Xe4sgDxr_V5e5fKU85mRhXYGofuadzmAhYjkW1d3yMUntZ2nT$>

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.

Thanks,
Chris and Acee