Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles

Hi Peter,

Thanks for your important comments.

It seems that we have a consensus that the use-case described in the draft is valid.

I've heard some people say that flex-algo has already supported this l2-bundles scenario, no additional definition is needed. This seems that, from the view of some people, the use-case need to be solved through flex-algo itself. 

The solution currently described in this document may not be mature, but the direction may not be wrong ?

Others please see inline [PSF].

Regards,

PSF

原始邮件

发件人：PeterPsenak
收件人：lsr@ietf.org;
日 期 ：2021年03月09日 18:08
主 题 ：[Lsr] draft-peng-lsr-flex-algo-l2bundles

Dear authors,

here are couple of comments to draft-peng-lsr-flex-algo-l2bundles:

1. Flex-algo specification as specified in draft-ietf-lsr-flex-algo only  
uses L3 link information for path computation. This is consistent with  
the regular Algo 0 path computation. My preference would be to keep it  
that way.[PSF] There maybe one way not to violate this rule, but more complex. 

[PSF] Currently for an L3 link there are multiple Application specific attributes, is it possible for an application (such as Flex-algo) there are multiple APP Instance specific attributes ? For example, an L2-bundle interface can have multiple Flex-algo APP instance delay metric, for algorithm-128 the delay metric is 10ms (exactly get from the dynamic detection of member link 1), for algorithm-129 the delay metric is 20ms (exactly get from the dynamic detection of member link 2), for algorithm-0 the delay metric get from the dynamic detection of bundles itself. However I don't like the this way. Other ways?

2. Flex-algo is not a replacement for SRTE. The problem that you are  
trying to solve can be solved by SRTE with the usage of the L2 Adj-SIDs.[PSF] Flex-algo is constraint based SPF, for the initial purpose, is SID stack depth optimization for SR-TE path ? It's hard to convince operators by just saying that "the problem is out the scope of Flex-algo" when he has already selected Flex-algo to reduce the number of Adj-SIDs.

3. Usage of the L2 link data for flex-algo path computation is much more  
complex than defining the L-flag in the FAD. You would need to deal with  
things like:

a) conflicting information in L3 and L2 link information
b) missing information in L3 or L2 link information
 [PSF] Yes, more computation rules need be added based on the existing ones defined in draft-ietf-lsr-flex-algo. I think it's no more complex than Flex-algo itself.

which would require to define a strict path computation preference rules  
and conflict resolutions that all routers would need to follow. I would  
argue that this is much easier to be done with SRTE, where the logic to  
select the path is a local matter compared to consistency in path  
selection that is required for distributed calculation used by flex-algo.
 [PSF] Unfortunately we are now in the context of Flex-algo, not SR-TE.

thanks,
Peter

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr