Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles
Hi Ran, On 12/03/2021 14:35, chen@zte.com.cn 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; *抄送人：*lsr@ietf.org; *日 期 ：*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, peng.sha...@zte.com.cn 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 > *收件人：*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?* ##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 > arg
Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles
Hi Peter, Thank you very much for your comments. ##PPas 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. Best Regards, Ran 原始邮件 发件人：PeterPsenak 收件人：彭少富10053815; 抄送人：lsr@ietf.org; 日 期 ：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, peng.sha...@zte.com.cn 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 > *收件人：*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?* ##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 pat
Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles
Hi Shaofu, please see inline (##PP): On 12/03/2021 04:26, peng.sha...@zte.com.cn 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 *收件人：*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?* ##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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[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. 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. 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 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. thanks, Peter ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
