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:shrad...@juniper.net]
Sent: Wednesday, May 19, 2021 6:42 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


>[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) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>
Sent: Wednesday, May 19, 2021 12:59 PM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; Acee 
Lindem (acee) 
<acee=40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

[External Email. Be cautious of content]

Hi Shraddha,

Thanks for your reply. Please see further inline:

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
<acee=40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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 Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
<acee=40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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

[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:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) 
<acee=40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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 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:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto: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/<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


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to