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

Peter Psenak <ppsenak@cisco.com> Fri, 12 March 2021 15:30 UTC

Return-Path: <ppsenak@cisco.com>
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 ABA9F3A130B for <lsr@ietfa.amsl.com>; Fri, 12 Mar 2021 07:30:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 NOtLdINBPNuO for <lsr@ietfa.amsl.com>; Fri, 12 Mar 2021 07:30:18 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2F43A1300 for <lsr@ietf.org>; Fri, 12 Mar 2021 07:30:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6690; q=dns/txt; s=iport; t=1615563018; x=1616772618; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=8/8qfGuZKDU976lN0kYBkvzAsWuud6TxV+KPFQ+Gll4=; b=aH2IIJjkZkbIAaqSSr5zmg6W+k1xY7fH8oeaUuVeAunR3coG7dThamyO /mWpl5ts+aBUsE0eiYTI89RQhGdjHebiDAQAoV1KNd+vSq4y8mJuubpVO L1Bu+3BDM7hZ90UQHC0hBks0Kqyh88+mWZDJ6mtEP93lDINmvgrw6QlSu Q=;
X-IPAS-Result: =?us-ascii?q?A0BeBABeh0tgjBbLJq1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DIVYBJxIxhEGJBIgTLQOabYFoCwEBAQ8dCwwEAQGETQKBdSY4EwIDAQEBA?= =?us-ascii?q?wIDAQEBAQUBAQECAQYEFAEBAQGGOg2GRQEBAQMBASEPAQU2CxAJAhgCAiYCA?= =?us-ascii?q?icwEwYCAQEXglUBgwcPkG6bCnaBMoVYgziBPwaBDyqNQ0KBSkKBEAEngnQ+g?= =?us-ascii?q?mABAYElg1CCXwSBVAFragQvJFALIAo/FQQlARsSGxq6AYMLgzOYeAUHAx+DP?= =?us-ascii?q?YpbhVaQIrJnBAuEc4FrIYFZMxoIGxU7gmlQGQ2OKw0JiGGFRkADLzgCBgEJA?= =?us-ascii?q?QEDCZQAAQE?=
IronPort-HdrOrdr: A9a23:q1boxahiCQaCkq1wnXgGwDf65XBQX5N13DAbvn1ZSRFFG/Gwvc rGppgm/DXzjyscX2xlvNiGNrWJT3+0z+8T3aA6O7C+UA76/FayJIZ54of4hxHmESvy9ulSvJ 0QFZRWItv2EFR8kILG8BC1euxQpOWv3ai0iY7lr0tFYhptb8hbgTtRKgHeKUFuQRkDOJxRLu v42uNihx6NPUsadd66AH5tZZmgm/TumIj9aRALQz4LgTPusRqS5LT3EweV034lOlsl/Z4Y/W fIiAD/7Km42svV9jbny2TR455K8eGK9vJ/AqW35/Q9Fi/hkUKBaohnRtS5zVMIidDqzko2m9 /RpBplGMJ/5xrqDxmIiCqo/RX82zAz7HKn83ukuD/IpMz0Qy9SMbs5ub5k
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,243,1610409600"; d="scan'208";a="34141123"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2021 15:30:13 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 12CFUDcx004014; Fri, 12 Mar 2021 15:30:13 GMT
To: chen.ran@zte.com.cn
Cc: peng.shaofu@zte.com.cn, lsr@ietf.org
References: <202103122135080751771@zte.com.cn>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <6f0ffcd0-b8e5-6fb5-08a6-2059b140911d@cisco.com>
Date: Fri, 12 Mar 2021 16:30:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <202103122135080751771@zte.com.cn>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/24n0-PvfSIWwcecmgAzFkuFVZ70>
Subject: Re: [Lsr] 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 15:30:21 -0000

Hi Ran,

On 12/03/2021 14:35, chen.ran@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.shaofu@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
> 
>