Hi Shraddha,
Thanks. Actually, I don't really want to define other metric types.
Let's go back to the bandwidth-metric related to bandwidth capability. My worry
is that bandwidth-metric (whether it is automatically calculated or manually
configured) is not cumulative in nature, which is different from IGP default
metric/TE metric/delay metric, so that SPF based on bandwidth-metric may get an
unexpected path (see the example of the original mail). Can more text be added
in the draft to describe why this can work ?
Regards,
PSF
原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：[email protected];[email protected];[email protected];
日 期 ：2021年05月18日 13:01
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Pengshaofu,
If an operator wants to configure any other metric type draft provides a
mechanism with generic metric.
Generic metric allows any standard or user-defined type metric to be configured.
The draft allows for any computing application such as Flex-algo, CSPF etc to
make use of the
Metric. The intention of the draft is that for a particular computation same
metric-type is used
throughout the network. If that is not clear, I’ll add some text in the draft.
Using a combination of different metrics for a single computation would need
significant change to SPF algorithm and it is not in the scope of the draft
"Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints".
Hope that clarifies.
Rgds
Shraddha
Juniper Business Use Only
From: [email protected] <[email protected]>
Sent: Monday, May 17, 2021 12:49 PM
To: Shraddha Hegde <[email protected]>
Cc: [email protected]; [email protected];
[email protected]
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,
The two methods of automatic generation of BW-metric introduced in the draft
are also likely to be the method of manual configuration of BW-metric by
operators. Operators can certainly manually configure any BW-metric he wants
to configure.
However, the manually configured BW-metric cannot deviate from the actual
bandwidth capacity of the link, otherwise it could be any other names such as
BX-metric.
For manual assignment, the problem may still exist We can find an example that
the accumulated bandwidth-metric on the path may offset the manually increased
bandwidth-metric of links on the path.
Combination of bandwidth attribute of link and other metric that is cumulative
may be another co-exist way to completely address this issue.
Regards,
PSF
原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：[email protected];[email protected];[email protected];
日 期 ：2021年05月17日 12:15
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Pengshaofu,
I was suggesting to manually assign bandwidth metric which will override the
automatic metric calculation
as described in the draft section 5. Physically adding more fiber/capacity is
not a feasible solution.
Rgds
Shraddha
Juniper Business Use Only
From: [email protected] <[email protected]>
Sent: Monday, May 17, 2021 7:40 AM
To: Shraddha Hegde <[email protected]>
Cc: [email protected]; [email protected];
[email protected]
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 rely.
So it seems that the scheme may lead to the selection of links with less
bandwidth. To address this point, the method as you described to assign more
bandwidth to high bandwidth links seems not always possible, e.g, adding more
fiber ?
Can this point can be addressed by combination of bandwidth attribute of link
and other metric that is cumulative ? IMO, bandwidth is not cumulative.
Regards
PSF
原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：[email protected];[email protected];[email protected];
日 期 ：2021年05月13日 21:01
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Peng shaofu,
As per the draft, if automatic metric calculation with reference bandwidth
method is used to calculate the metric
Then as per your example s->D path will be chosen since metric is 10.
Lets say operator wants to choose S->X1->X2-àX10->D path then operator can
manually assign higher bandwidth
Metric on S->D link which will ensure S->D path is not the least cost path.
Rgds
Shraddha
Juniper Business Use Only
From: [email protected] <[email protected]>
Sent: Thursday, May 13, 2021 1:05 PM
To: [email protected]
Cc: [email protected]; [email protected];
[email protected]
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]
Sorry for spelling mistakens in the previous email.
updated text:
Hi WG,
I have a little doubt about the scheme described in this document.
See the following example:
S ---- X1 ----- X2 ---- ... ... ----- X10 ----- D
\----------------------------------------------/
Suppose the links in S---X1---X2...---D have the same bandwidth 10G, and the
link S-D has bandwidth 1G.
Suppose that we select "reference bandwidth = 100G", then,
each link in S---X1---X2...---D will have the same bandwidth-metric 10 (i.e.,
100/10)
link S-D will have a bandwidth-metric 100 (i.e., 100/1)
So flex-algo path from S to D based on bandwidth-metric will be S-D, not
S---X1---X2...---D, because the later has a large cumulative bandwitdh-metric
(i.e., 11*10).
But our expect path should not be S-D, but S---X1---X2...---D, as it has large
bandwidth.
Do I misunderstand anything ?
Regards,
PSF
发件人：AceeLindem(acee)
收件人：[email protected];
抄送人：[email protected];
日 期 ：2021年05月13日 05:49
主 题 ：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
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 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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
