Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

peng.shaofu@zte.com.cn Thu, 03 June 2021 02:42 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 832333A2580 for <lsr@ietfa.amsl.com>; Wed, 2 Jun 2021 19:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 mNTmKb0A2B0E for <lsr@ietfa.amsl.com>; Wed, 2 Jun 2021 19:42:45 -0700 (PDT)
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 6E6A83A257F for <lsr@ietf.org>; Wed, 2 Jun 2021 19:42:45 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 6ACC8FEB89A370C421A2 for <lsr@ietf.org>; Thu, 3 Jun 2021 10:42:41 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 43933B858003A8315033; Thu, 3 Jun 2021 10:42:41 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl2.zte.com.cn with SMTP id 1532g5YG045595; Thu, 3 Jun 2021 10:42:05 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Thu, 3 Jun 2021 10:42:05 +0800 (CST)
Date: Thu, 03 Jun 2021 10:42:05 +0800
X-Zmail-TransId: 2af960b8417d8d0520a4
X-Mailer: Zmail v1.0
Message-ID: <202106031042051883964@zte.com.cn>
In-Reply-To: <00ae01d75762$72fddbd0$58f99370$@tsinghua.org.cn>
References: m2wnrlcitn.fsf@ja.int.chopps.org, 00ae01d75762$72fddbd0$58f99370$@tsinghua.org.cn
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: wangaijun@tsinghua.org.cn
Cc: chopps@chopps.org, lsr@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 1532g5YG045595
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/HGW-KJ1zSJ1lIy7g_CjKeVs7X9w>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"
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: Thu, 03 Jun 2021 02:42:51 -0000

Hi Aijun,

Thanks for your comments.
Please see inline [PSF]

Regards,
PSF


------------------原始邮件------------------
发件人:AijunWang
收件人:'Christian Hopps';lsr@ietf.org;
日 期 :2021年06月02日 11:51
主 题 :Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"
Hi, All:
Again, I support part of this draft be adopted.


The deployment of Flex-Algo should be separated from the SR-TE Policy. Then
the use-case 1, 3 in section 3 should be pulled out, this can keep the
original design principle of Flex-Algo.
Adjacency-SID will only be included in the data packet when the packets need
pass a TI-LFA path, which is described in case-2 of section 3.

[PSF] If I get your point, it is use-case 1 that should be pulled out. Since use-case 3 is just the primary case with consensus.
[PSF] And, use-case 2 is related with TI-LFA path to a remote destination node. As we know an adjacency segment can be contained in the TI-LFA path. So that an algorithm specific TI-LFA path should also possibly contain algorithm related adjacency-sid. Only in this way can this adjacence-sid can be protected by the algorithm specific local repair path. Therefore, we also agree on use-case 2.


And, I saw there was contentions for the following paragraph in section 5:
"The endpoint of a link shared by multiple flex-algo plane can reserve
different queue resources for different algorithms locally, and
perform priority based queue scheduling and traffic shaping.  This
algorithm related reserved information can be advertised to other
nodes in the network through some mechanism, therefore it has an
impact on the constraint based path calculation of the flex-algo
plane.  How to allocate algorithm related resouce and advertise it in
the network is out the scope of this document."
Since Flex-Algo doesn't consider the resource reservation, then such
reservation information needs not be advertised out of the node itself for
Flex-algo calculation.

[PSF] Agree. Flex-algo itself doesn't consider the resource reservation during constraint SPF computation. 
[PSF] My means is that other computation engine (e.g, an SDN controller) can possibly compute a TE path within the scope of specific flex-algo plane. This document doesn't discuss this topic in detail, just mentions it as a use case (i.e., use-case 1). This topic can refer to "algorithm constraints" in https://datatracker.ietf.org/doc/draft-peng-pce-te-constraints/


The local behavior based on the flex-algo related Adjacency-SID can be
described if the authors prefer.

[PSF] Yes, they just help to describe the purpose of algorithm related adj-sid. It is free for an implementation to organize its local table, forwarding resource, based on algorithm directly or indirectly.


SR-TE and Flex-Algo both can achieve the same goal, we need not mix them
together.
[PSF] This opinion is actually related to use-case 1.  I don't insist on my own view that use-case 1, i.e., SR-TE path within flex-algo plane, is kept in this document. We can discuss it in another documents.


Best Regards
Aijun Wang
China Telecom
-----Original Message-----
From: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of Christian
Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: chopps@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
Advertisement"
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-
sid/
Please indicate your support or objections by June 9th, 2021
Authors, please respond to the list indicating whether you are aware of any
IPR that applies to this draft.
Thanks,
Acee and Chris.
_______________________________________________
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