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
收件人：[email protected];
日 期 ：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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
