Re: [Pce] PCE SID-algo draft extension
peng.shaofu@zte.com.cn Wed, 29 March 2023 09:45 UTC
Return-Path: <peng.shaofu@zte.com.cn>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A78C15C501; Wed, 29 Mar 2023 02:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBuk0o7R2W83; Wed, 29 Mar 2023 02:45:53 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1C3C15256E; Wed, 29 Mar 2023 02:45:52 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4PmhWJ5l3qz4xVnK; Wed, 29 Mar 2023 17:45:48 +0800 (CST)
Received: from njy2app03.zte.com.cn ([10.40.13.14]) by mse-fl2.zte.com.cn with SMTP id 32T9jaEM064874; Wed, 29 Mar 2023 17:45:36 +0800 (+08) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njy2app01[null]) by mapi (Zmail) with MAPI id mid201; Wed, 29 Mar 2023 17:45:38 +0800 (CST)
Date: Wed, 29 Mar 2023 17:45:38 +0800
X-Zmail-TransId: 2af9642408c2ffffffffece-5c80f
X-Mailer: Zmail v1.0
Message-ID: <202303291745388369897@zte.com.cn>
In-Reply-To: <DM6PR11MB4122708234F46AD3937B72A0D0899@DM6PR11MB4122.namprd11.prod.outlook.com>
References: DM6PR11MB4122FA3E3A5024A13385BD66D0FF9@DM6PR11MB4122.namprd11.prod.outlook.com, CAP7zK5bCJwLxNg=MpigrVw35NQU6zdhAjMR_BJvZygApntdHvg@mail.gmail.com, 01ec01d92511$6129ee70$237dcb50$@gmail.com, DM6PR11MB4122A89B5BB141948CE0852BD0FD9@DM6PR11MB4122.namprd11.prod.outlook.com, DM6PR11MB4122708234F46AD3937B72A0D0899@DM6PR11MB4122.namprd11.prod.outlook.com
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: ssidor@cisco.com
Cc: pce@ietf.org, pce-chairs@ietf.org, slitkows.ietf@gmail.com, dd@dhruvdhody.com, andrew.stone@nokia.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 32T9jaEM064874
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 642408CC.000/4PmhWJ5l3qz4xVnK
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/fG2BVhyKrRnT-Nc4KPaiHfk2TqE>
Subject: Re: [Pce] PCE SID-algo draft extension
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2023 09:45:56 -0000
Hi Samuel, WG, Thanks for the effort work to get the consensus about path computation according to the content of FAD. An explicit flag based on the existing SID-algo constraint for the purpose of behavior b, seems good to me. Regards, PSF Original From: SamuelSidor(ssidor) <ssidor@cisco.com> To: pce@ietf.org <pce@ietf.org>;'pce-chairs' <pce-chairs@ietf.org>; Cc: slitkows.ietf@gmail.com <slitkows.ietf@gmail.com>;'Dhruv Dhody' <dd@dhruvdhody.com>;彭少富10053815;Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com>; Date: 2023年03月29日 17:10 Subject: RE: [Pce] PCE SID-algo draft extension Hi all, Thanks all for discussion, which happened during PCE session and thanks for supporting this extension. I think that we agreed that it is necessary to consider FAD in the path-computation on PCE side if SID-algo constraint was specified, but we were not able to finish discussion whether there is a need to introduce new flag, which will control whether original behavior (SID-algo filtering) or new behavior should be used, so re-opening this mail thread to finish that discussion. I would say that there are really at least two usecases/behaviors for SID-algo constraint and we need new flag in SID-algorithm constraint to allow PCC to pick required behavior. SID-filtering - already exists in the draft (valid for all algorithms) Path-computation should occur on the topology associated with specified SID-algo Computed path can have only SIDs of specified algo value (+ adjacency SIDs) PCE path-computation is done based on metric-type and constraints from PCRpt Flex-algo specific part: PCE still has to make sure that IGP path of FA SID is congruent with computed path Path-computation based on FAD (only valid for Flex-algo) Metric-type and constraints are primarily retrieved from FAD Path-computation follow IGP Flex-algo path-computation logic Flex-algo participation, ASLA attributes,... Metric-type from FAD is overriding metric-type from PCRpt PCUpdate will use metric-type from FAD PCC can send metric-type in PCRpt and it does not have to be same as metric-type from FAD, but it is recommended to do not advertise any optimization metric Other constraints from PCRpt: PCE implementation can decide based on flags in PCEP object It is not recommended to specify constraints in PCRpt, which are already specified in FAD PCE is not supposed to include constraints from FAD in PCUpdate Description here is slightly different then the proposal presented in original slides, but main idea is still same and more details is provided now. Please provide any comments. Thanks, Samuel From: Pce <pce-bounces@ietf.org> On Behalf Of Samuel Sidor (ssidor) Sent: Thursday, January 12, 2023 10:12 AM To: slitkows.ietf@gmail.com; 'Dhruv Dhody' <dd@dhruvdhody.com> Cc: pce@ietf.org; 'pce-chairs' <pce-chairs@ietf.org> Subject: Re: [Pce] PCE SID-algo draft extension Hi Dhruv, Thanks for feedback. I completely agree – I would like to hear from WG if they can see added value in both (or they can specify even other) use-cases – using SID-algo constraint just for SID filtering and using it also for specification of constraints from FAD (I agree with Stephane here – computation based on in FAD seems to be even more important use-case to me and it is not covered in current version of that draft). For constraint conflict solving – there are multiple possible solutions, but I would prefer to ignore metric-type from PCRpt (as metric-type would be retrieved from FAD) or reject PCEP Metric object completely (that may have potential issues with backward compatibility). Do not block usage of other constraints on top of SID-algo constraint explicitly in the draft – actual PCE implementation can still reject any combination of constraints, which PCE cannot handle (with PCUpdate with empty ERO or with some specific PCError) That would allow usage of some specific constraints like metric bounds on top of path computed with constraints from FAD. I would like to clearly specify in the draft that PCC is not supposed to reflect constraints from FAD in PCRpt as intended/requested attributes (only constraints, which should be used on top of FAD should be specified). For SID-algo constraint signaling – can you please specify benefit of using association in this case? FAD with constraints is part of topology information received from IGP/BGP-LS, so we need to encode only algorithm number (and potentially source IGP, but that is separate story). Thanks, Samuel From: slitkows.ietf@gmail.com <slitkows.ietf@gmail.com> Sent: Tuesday, January 10, 2023 5:34 PM To: 'Dhruv Dhody' <dd@dhruvdhody.com>; Samuel Sidor (ssidor) <ssidor@cisco.com> Cc: pce@ietf.org; 'pce-chairs' <pce-chairs@ietf.org> Subject: RE: [Pce] PCE SID-algo draft extension Hi Happy new year guys ! IMO, from a use case point of view, the SID filtering use case is far more limited and niche (e.g.: plane selection…) vs the interdomain FA path computation which is widely required. For large networks that are multidomain, there must be a PCE based solution for interdomain FA path computation. Brgds, Stephane From: Pce <pce-bounces@ietf.org> On Behalf Of Dhruv Dhody Sent: mardi 10 janvier 2023 14:00 To: Samuel Sidor (ssidor) <ssidor@cisco.com> Cc: pce@ietf.org; pce-chairs <pce-chairs@ietf.org> Subject: Re: [Pce] PCE SID-algo draft extension Hi Samuel, As a WG participant --- Assuming the WG agrees with the usecase, we need a clear way to signal when the Algo is a constraint along with others (current) v/s when Algo is a shorthand to refer to the constraints as per the IGP definition (proposed). This could be a flag in the SID Algorithm TLV or could be a brand new mechanism (such as a new dynamic association type for FlexAlgo). More importantly, we need to be clear on how other PCEP constraints interact with the constraints referred in the IGP. The easiest thing would be to not allow other PCEP constraints to be encoded at all and rely only on IGP; or have flags to signal how to handle the complexity of combining them including mismatch! This needs to be handled with care! Thanks! Dhruv On Tue, Jan 10, 2023 at 3:51 PM Samuel Sidor (ssidor) <ssidor@cisco.com> wrote: Hi all, I would like to get feedback from PCE WG for one extension proposed for existing SID-algo draft (currently expired), which is trying to cover all existing algorithm types as defined in IGP – that includes SPF (algo 0), Strict-SPF (algo 1) and Flex-algo (algo 128-255) It introduced SID-algo constraint, which currently can be used for filtering SIDs used in path computed by PCE. To be able to compute inter-domain Flex-algo path, PCE Flex-algo path-computation must be aligned with path-computation done by IGP (Use ASLA attributes, honor FAD lookup priorities,…). This use-case is different one from SID filtering we need to use constraints/metric-type from Flex-algo definition that is bound to SID algo number specified in constraint. Before we modify the draft, we would like to know if WG has any objection. Thanks, Samuel
- [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)
- Re: [Pce] PCE SID-algo draft extension Dhruv Dhody
- Re: [Pce] PCE SID-algo draft extension slitkows.ietf
- Re: [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)
- Re: [Pce] PCE SID-algo draft extension peng.shaofu
- Re: [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)
- Re: [Pce] PCE SID-algo draft extension peng.shaofu
- Re: [Pce] PCE SID-algo draft extension Andrew Stone (Nokia)
- Re: [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)
- Re: [Pce] PCE SID-algo draft extension Andrew Stone (Nokia)
- Re: [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)
- Re: [Pce] PCE SID-algo draft extension Andrew Stone (Nokia)
- Re: [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)
- Re: [Pce] PCE SID-algo draft extension Andrew Stone (Nokia)
- Re: [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)
- Re: [Pce] PCE SID-algo draft extension Dhruv Dhody
- Re: [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)
- Re: [Pce] PCE SID-algo draft extension Dhruv Dhody
- Re: [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)
- Re: [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)
- Re: [Pce] PCE SID-algo draft extension Samuel Sidor (ssidor)