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

[Peter Psenak <[e-mail]>]

Hi Ran,

On 12/03/2021 14:35, [e-mail] wrote:
> 
> Hi Peter,
> 
> Thank you very much for your comments.
> 
> 
> ##PP
> as I expressed earlier, my preference would be to keep the flex-algo
> being based on L3 link information only and not to use L2 link
> information during the flex-algo computation. There are other ways to
> 
> solve your problem. But I will let the WG to discuss and decide.
> 
> 
> Ran:Would you like to provide other ways? Then we can take it as an 
> optional solution and compare with our solution.

a) SRTE
b) usage of L3 links instead of L2 bundle in such case

thanks,
Peter


> 
> 
> 
> Best Regards,
> 
> Ran
> 
> 
> 
> 
> 原始邮件
> *发件人：*PeterPsenak
> *收件人：*彭少富10053815;
> *抄送人：*[e-mail];
> *日 期 ：*2021年03月12日 20:04
> *主 题 ：**Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles*
> Hi Shaofu,
> 
> please see inline (##PP):
> 
> On 12/03/2021 04:26, [e-mail] wrote:
>  >
>  > 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.
> 
> ##PP
> no, flex-algo does not have any support for l2-bundles at this point.
> 
>  >
>  > The solution currently described in this document may not be mature, but
>  > the direction may not be wrong ?
> 
> ##PP
> as I expressed earlier, my preference would be to keep the flex-algo
> being based on L3 link information only and not to use L2 link
> information during the flex-algo computation. There are other ways to
> 
> solve your problem. But I will let the WG to discuss and decide.
> 
> 
> 
>  >
>  >
>  > Others please see inline [PSF].
>  >
>  >
>  > Regards,
>  >
>  > PSF
>  >
>  >
>  > 原始邮件
>  > *发件人：*PeterPsenak
>  > *收件人：*[e-mail];
>  > *日 期 ：*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?*
> 
> ##PP
> what you are proposing above is a per flex-algo ID link attributes, but
> I don't believe that is the direction we want to go. It does not scale.
> 
>  >
>  >
>  > 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.**
> 
> ##PP
> Flex-algo is constraint based SPF, but so far based on L3 link
> information only.
> 
>  >
>  >
>  > 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.*
> 
> ##PP
> the question is how much extra complexity do we want to add for the
> benefit it brings.
> 
> We need to consider how frequent is the use case that you describe
> present in the field and whether existing mechanisms like SRTE, or usage
> of L3 links instead if L2 bundles in such case, are not sufficient to
> address the problem.
> 
> The fact that it is possible to address the problem by flex-algo does
> not mandate the usage of it.
> 
> thanks,
> Peter
> 
>  >
>  >
>  > 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
>  > [e-mail]
>  > https://www.ietf.org/mailman/listinfo/lsr
>  >
>  >
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
> 
>