Hi, Aijun:
Thank you for the clarification of FAPM sub-TLV. Really helpful :-)
Hi, Acee:
Thank you for the review and comment.
why you couldn’t just use the algorithm-specific metric in section 8 and 9 and
draft-ietf-lsir-flex-algo
>>>> About the FAPM sub-TLV, I agree with Aijun that it’s used for Prefix
>>>> Metric, not for Link Metric. According to draft-ietf-lsr-flex-algo, it is
>>>> usually used in multi-area and multi-domain scenarios. IMHO, FAPM may be
>>>> not a good solution for our case.
It seems to me that the use case is fairly obscure
>>>> Sorry for that we did not make it clear in the draft. We have revised the
>>>> use case in the slide, and will update the draft later (maybe after the
>>>> meeting).
Case 1:
A------C
| |
| |
| |
B------D
We have two network slices for the traffic from A to D. For slice 1, the
network operator expects to use A-B-D as the primary path and A-C-D as the
backup path. For slice 2, A-C-D is the primary path and A-B-D is the backup
path.
Bandwidth resources are reserved along the primary paths for slices. On the
backup path, no dedicated resources are reserved, and the bandwidth is shared
with BE traffics.
The metric-type of the two Flex-Algorithms are the same since they both care
about the bandwidth resources.
For Flex-Algo 128, we hope that metrics of link A-B and B-D are smaller than
link A-C and C-D. But for Flex-Algo 129, we hope link A-C and C-D have smaller
metrics.
Case 2:
A------C
/|* |
/ | * |
/ | * |
E---B------D
There is TE-tunnel (or SR Policy) between A and D. A uses the tunnel as a
short-cut path to D.
In Flex-Algo 128 and 129, forward adjacency is enabled for the tunnel A-D to
allow other nodes to see it.
The metric of tunnel A-D is different in Flex-Algo 128 and 129 (for example,
the physical path in Flex-Algo 128 is A-B-D, in Flex-Algo 129 is A-C-D).
So, we hope A can advertise the virtual link A-D with different metrics for
Flex-Algo 128 and 129.
Best Regards
Mengxiao Chen
发件人: Lsr [mailto:[email protected]] 代表 Aijun Wang
发送时间: 2022年3月23日 9:22
收件人: 'Acee Lindem (acee)' <[email protected]>;
[email protected]
抄送: [email protected]
主题: Re: [Lsr] Question on "Advertisement of Dedicated Metric for Flexible
Algorithm in IGP"
Hi, Acee:
The Sub-TLV described in Section 8 and section 9 of the
draft-ietf-lsr-flex-algo is for Prefix Metric, not for Link Metric.
Such sub-TLV is carried with the prefix advertisement. Will you change the name
and application scope of such Sub-TLV?
Currently, the name is “IS-IS Flexible Algorithm Prefix Metric Sub-TLV”, its
application scope is limited in:
“The IS-IS FAPM Sub-TLV is a sub-TLV of TLVs 135, 235, 236, and 237”.
Same situation as OSPF
Best Regards
Aijun Wang
China Telecom
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>> On Behalf Of Acee Lindem
(acee)
Sent: Wednesday, March 23, 2022 2:02 AM
To:
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: [Lsr] Question on "Advertisement of Dedicated Metric for Flexible
Algorithm in IGP"
Speaking as WG member:
Hi Co-authors,
I’m read this draft and I really don’t see why you couldn’t just use the
algorithm-specific metric in section 8 and 9 and draft-ietf-lsir-flex-algo? It
seems to me that the use case is fairly obscure and there is nothing to prevent
usage of these metrics for this use case and the draft is simply a matter of
semantics.
Thanks,
Acee
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C,
which is
intended only for the person or entity whose address is listed above. Any use
of the
information contained herein in any way (including, but not limited to, total
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify
the sender
by phone or email immediately and delete it!
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
