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:lsr-boun...@ietf.org] 代表 Aijun Wang
发送时间: 2022年3月23日 9:22
收件人: 'Acee Lindem (acee)' <acee=40cisco....@dmarc.ietf.org>; 
draft-lin-lsr-flex-algo-met...@ietf.org
抄送: lsr@ietf.org
主题: 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: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
<lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, March 23, 2022 2:02 AM
To: 
draft-lin-lsr-flex-algo-met...@ietf.org<mailto:draft-lin-lsr-flex-algo-met...@ietf.org>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to