Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles Fri, 12 March 2021 03:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6D743A1EC6 for <>; Thu, 11 Mar 2021 19:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8ojVyhm8pVgn for <>; Thu, 11 Mar 2021 19:26:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4439F3A1EC3 for <>; Thu, 11 Mar 2021 19:26:41 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id B3A3F80399DB6627AD88 for <>; Fri, 12 Mar 2021 11:26:38 +0800 (CST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 9A313C0B9195E5B3D751; Fri, 12 Mar 2021 11:26:38 +0800 (CST)
Received: from ([]) by with SMTP id 12C3QSOk054789; Fri, 12 Mar 2021 11:26:28 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Fri, 12 Mar 2021 11:26:28 +0800 (CST)
Date: Fri, 12 Mar 2021 11:26:28 +0800
X-Zmail-TransId: 2af9604adf64dfccbd8b
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 12C3QSOk054789
Archived-At: <>
Subject: Re: [Lsr] draft-peng-lsr-flex-algo-l2bundles
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Mar 2021 03:26:44 -0000

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].




日 期 :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.

Lsr mailing list