Subject: [Lsr] draft-lin-lsr-flex-algo-metric-00

From: Peter Psenak <[email-masked]>
Date: Thu, 24 Mar 2022 16:08:50 +0100

Hi,

as I was unable to make my comments during the presentation, let me put 
them here:

When we started with the flex-algo work, there has been a lengthy 
discussion on why not to use the multi-topology (MT) instead. We always 
wanted flex-algo to be light weight and as a result easy to deploy and 
manage. I believe that was one of the reasons why flex-algo has been 
successfully deployed. We do not want to loose that very property of the 
flex-algo architecture.

What you are proposing is what MT was invented for and we do not want 
flex-algo to become a new version of MT.

You have two ways to solve your problem:

a) use MT

b) if you want to solve your problem with flex-algo, please use what 
already exists in flex-algo. Please look at 
draft-ietf-lsr-flex-algo-bw-con as others have pointed out.

thanks,
Peter

---

From: Chenmengxiao <[email-masked]>
Date: Fri, 25 Mar 2022 06:35:13 +0000

Hi Peter,

Thank you for the comments.

Time for the presentation is very limited. Glad to receive your comments here.

I agree that flex-algo is much easier to deploy and manage than MT, which make it a popular tool now.

But I think using algorithm-specific link metric will not cause the loss of this property.

For example, flex-algo 128 and flex-algo 129 need to use different metrics of the same metric-type for the same link.

Solution A: Use algorithm-based metric for algorithm 128 and algorithm 129

Solution B: Use metric-type-based metric for metric-type 128 and metric-type 129 (according to Shraddha's suggestion, draft-ietf-lsr-flex-algo-bw-con)

Both in the two solutions, extra link metric tlvs need to be advertised, and they are stored locally, no matter algorithm-based or metric-type-based.

During path computation, the difference is that, solution A needs to check if there is algorithm-based metric for the link. If yes, algorithm-based metric is preferred. If no, common metric is used.

IMHO, even if the algorithm-specific link metric is used, flex-algo is still light weight, compared with MT.

Thanks,

Mengxiao Chen

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Peter Psenak
Sent: Thursday, March 24, 2022 11:09 PM
To: [email-masked]
Subject: [Lsr] draft-lin-lsr-flex-algo-metric-00

Hi,

them here:

flex-algo architecture.

a) use MT

thanks,

Peter

_______________________________________________

Lsr mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/lsr

-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
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!

---

From: Peter Psenak <[email-masked]>
Date: Fri, 25 Mar 2022 09:15:35 +0100

Hi Mengxiao,

please see inline:

On 25/03/2022 07:35, Chenmengxiao wrote:
> For example, flex-algo 128 and flex-algo 129 need to use different 
> metrics of the same metric-type for the same link.
> 
> Solution B: Use metric-type-based metric for metric-type 128 and 
> metric-type 129 (according to Shraddha's suggestion, 
> draft-ietf-lsr-flex-algo-bw-con)
> 
> Both in the two solutions, extra link metric tlvs need to be advertised, 
> and they are stored locally, no matter algorithm-based or metric-type-based.

yes, but for B, any other algorithm may share the metric used for algo 
128 or 129. That is not possible with A.

You may argue that in your case you only have two algos, so the result 
ts similar. Yes, but from the architecture perspective there is a 
difference. Not to mention that for A we would need to extend the FAD.

> 
> During path computation, the difference is that, solution A needs to 
> check if there is algorithm-based metric for the link. If yes, 
> algorithm-based metric is preferred. If no, common metric is used.
> 

not really, because it advertise algo specific metric that can not be 
used by any other algo, which is similar to topology specific metric in MT.

I would encourage you to consider option B as a solution for your problem.

thanks,
Peter

> [email-masked] <mailto:[email-masked]>
> 
> <https://www.ietf.org/mailman/listinfo/lsr>
>

---

From: Chenmengxiao <[email-masked]>
Date: Tue, 29 Mar 2022 03:45:24 +0000

Hi Peter,

Sorry to reply late. Please see inline.

Thanks,

Mengxiao Chen

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]]
Sent: Friday, March 25, 2022 4:16 PM
To: chenmengxiao (RD) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] draft-lin-lsr-flex-algo-metric-00

Hi Mengxiao,

please see inline:

> Time for the presentation is very limited. Glad to receive your comments

> here.

> I agree that flex-algo is much easier to deploy and manage than MT,

> which make it a popular tool now.

> But I think using algorithm-specific link metric will not cause the loss

> of this property.

difference.

[MXC] Yes, from the perspective of protocol, metric-type 128 and 129 in solution B are possible to be shared by other algorithm. But if we focus on the case here, metric-type 128 and 129 are used to configure their unique metrics for the same public type (bandwidth or TE metric), so the chance of sharing may be very low in practice.

From another perspective, if we use user-defined metric-type, we need to advertise it for every link. But if we use algorithm-specific link metric, the algorithm may only advertise the algorithm-specific metrics of a few links whose metric value are different from the common metric.

TLV-22 of Solution A:

   metric   <- IGP metric (used by all algorithms, if no algorithm-specific advertised)

    generic metric  <- other type (used by all algorithms, if no algorithm-specific advertised)

    ASLA

        link attribute    <- TE metric/delay (used by all algorithms, if no algorithm-specific advertised)

        algorithm-specific metric  <- metric for algorithm 128

        algorithm-specific metric  <- metric for algorithm 128

TLV-22 of Solution B:

   metric   <- IGP metric (used by all algorithms)

    generic metric  <- other type (used by all algorithms)

    generic metric  <- type 128 (for algorithm 128)

    generic metric  <- type 129 (for algorithm 129)

    ASLA

        link attribute    <- TE metric/delay (used by all algorithms)

Not to mention that for A we would need to extend the FAD.

[MXC] That’s true. I think a new bit in the Flexible Algorithm Definition Flags can be used for such extension. We’ve missed it in the current version of draft. Thank you for pointing out.

> IMHO, even if the algorithm-specific link metric is used, flex-algo is

> still light weight, compared with MT.

[MXC] Thanks for your suggestion. I don’t doubt that solution B can solve our problem at current stage. In solution B, user-defined metric-type is used as a substitution for algorithm-specific metric of a standard metric-type.

But if there are strong requirements to advertise different metrics  for different algorithms, I would prefer solution A (algorithm-specific link metric). Assume that, an algorithm uses metric-type X for path computation, and it also uses metric-type Y as constraints. And it has its own metrics for both metric-type X and Y. The user-defined metric-type may not be adequate in such case.

Besides, I still think that flex-algo with algorithm-specific link metric will not become MT. The control plane and data plane are so different.

thanks,

Peter

> To: [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄

> 露、复制、

> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人

> 并删除本

> 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

---

From: Peter Psenak <[email-masked]>
Date: Wed, 30 Mar 2022 11:58:00 +0200

Hi Mengxiao,

please see inline (##PP):

On 29/03/2022 05:45, Chenmengxiao wrote:
> [MXC] Yes, from the perspective of protocol, metric-type 128 and 129 in 
> solution B are possible to be shared by other algorithm. But if we focus 
> on the case here, metric-type 128 and 129 are used to configure their 
> unique metrics for the same public type (bandwidth or TE metric), so the 
> chance of sharing may be very low in practice.
> 
>  From another perspective, if we use user-defined metric-type, we need 
> to advertise it for every link. But if we use algorithm-specific link 
> metric, the algorithm may only advertise the algorithm-specific metrics 
> of a few links whose metric value are different from the common metric.

##PP
I do not see any reason why we would need to advertise user-defined 
metric-type for every link. You can only advertise for links that are to 
be used by FAs that use that metric type.

> [MXC] That’s true. I think a new bit in the Flexible Algorithm 
> Definition Flags can be used for such extension. We’ve missed it in the 
> current version of draft. Thank you for pointing out. >
>  >
> 
> [MXC] Thanks for your suggestion. I don’t doubt that solution B can 
> solve our problem at current stage. In solution B, user-defined 
> metric-type is used as a substitution for algorithm-specific metric of a 
> standard metric-type.

##PP
I would rephrase a bit.

Metric-type is an existing mechanism in flex-algo architecture that 
allows you to use per algorithm metric values.

> 
> But if there are strong requirements to advertise different metrics  for 
> different algorithms, I would prefer solution A (algorithm-specific link 
> metric). Assume that, an algorithm uses metric-type X for path 
> computation, and it also uses metric-type Y as constraints. And it has 
> its own metrics for both metric-type X and Y. The user-defined 
> metric-type may not be adequate in such case.

##PP
there is no such thing as metric constraint at the moment. Metric is 
used for algo specific SPF computation only.

> 
> Besides, I still think that flex-algo with algorithm-specific link 
> metric will not become MT. 

##PP
it will become dangerously close to it :)

thanks,
Peter

> The control plane and data plane are so 
> different. >
> thanks,
> 
> Peter
> 
>  >
> 
>  > Thanks,
> 
>  >
> 
>  > Mengxiao Chen
> 
>  >
> 
>  > From: Lsr [mailto:[email-masked] <mailto:[email-masked]>] 
> On Behalf Of Peter Psenak
> 
>  > To: [email-masked] <mailto:[email-masked]>
> 
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
> 
>  >
> 
>  > <https://www.ietf.org/mailman/listinfo/lsr 
> <https://www.ietf.org/mailman/listinfo/lsr>>
> 
>  >
> 
>  >