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

peng.shaofu@zte.com.cn Fri, 12 March 2021 03:26 UTC

Return-Path: <peng.shaofu@zte.com.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D743A1EC6 for <lsr@ietfa.amsl.com>; Thu, 11 Mar 2021 19:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ojVyhm8pVgn for <lsr@ietfa.amsl.com>; Thu, 11 Mar 2021 19:26:41 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4439F3A1EC3 for <lsr@ietf.org>; Thu, 11 Mar 2021 19:26:41 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id B3A3F80399DB6627AD88 for <lsr@ietf.org>; Fri, 12 Mar 2021 11:26:38 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 9A313C0B9195E5B3D751; Fri, 12 Mar 2021 11:26:38 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl2.zte.com.cn with SMTP id 12C3QSOk054789; Fri, 12 Mar 2021 11:26:28 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
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 (CST)
X-Zmail-TransId: 2af9604adf64dfccbd8b
X-Mailer: Zmail v1.0
Message-ID: <202103121126283037967@zte.com.cn>
In-Reply-To: <1a64e6ae-457c-df93-2a44-5d2c737bcde7@cisco.com>
References: 1a64e6ae-457c-df93-2a44-5d2c737bcde7@cisco.com
Mime-Version: 1.0
From: <peng.shaofu@zte.com.cn>
To: <ppsenak=40cisco.com@dmarc.ietf.org>
Cc: <lsr@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 12C3QSOk054789
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/c9FKmuy2uymghbIoNQNahll1rzQ>
Subject: Re: [Lsr] =?utf-8?q?draft-peng-lsr-flex-algo-l2bundles?=
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=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].






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