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

[Peter Psenak <[e-mail]>]

Hi Mengxiao,

please see inline (##PP):

On 29/03/2022 05:45, Chenmengxiao wrote:
> Hi Peter,
> 
> Sorry to reply late. Please see inline.
> 
> Thanks,
> 
> Mengxiao Chen
> 
> -----Original Message-----
> From: Peter Psenak [mailto:[e-mail]]
> Sent: Friday, March 25, 2022 4:16 PM
> To: chenmengxiao (RD) <[e-mail]>; [e-mail]
> Subject: Re: [Lsr] draft-lin-lsr-flex-algo-metric-00
> 
> Hi Mengxiao,
> 
> please see inline:
> 
> On 25/03/2022 07:35, Chenmengxiao wrote:
> 
>  > 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.
> 
> 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.
> 
> [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.

> 
> 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. >
>  >
> 
>  > 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.
> 
> 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.
> 
> [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
> 
>  >
> 
>  > -----Original Message-----
> 
>  > From: Lsr [mailto:[e-mail] <mailto:[e-mail]>] 
> On Behalf Of Peter Psenak
> 
>  > Sent: Thursday, March 24, 2022 11:09 PM
> 
>  > To: [e-mail] <mailto:[e-mail]>
> 
>  > Subject: [Lsr] draft-lin-lsr-flex-algo-metric-00
> 
>  >
> 
>  > 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
> 
>  >
> 
>  > _______________________________________________
> 
>  >
> 
>  > Lsr mailing list
> 
>  >
> 
>  > [e-mail] <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>
> 
>  >
> 
>  > https://www.ietf.org/mailman/listinfo/lsr 
> <https://www.ietf.org/mailman/listinfo/lsr>
> 
>  > <https://www.ietf.org/mailman/listinfo/lsr 
> <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!
>