[Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt

xiong.quan@zte.com.cn Fri, 06 September 2024 09:21 UTC

Return-Path: <xiong.quan@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 4E7C1C16940E; Fri, 6 Sep 2024 02:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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 InK640BhVMVD; Fri, 6 Sep 2024 02:21:28 -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 D284CC157938; Fri, 6 Sep 2024 02:21:24 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (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 4X0W1s5f1Jz4xth3; Fri, 6 Sep 2024 17:21:21 +0800 (CST)
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 mxct.zte.com.cn (FangMail) with ESMTPS id 4X0W1D2LHsz51SYd; Fri, 6 Sep 2024 17:20:48 +0800 (CST)
Received: from njb2app05.zte.com.cn ([10.55.22.121]) by mse-fl2.zte.com.cn with SMTP id 4869K2Io017164; Fri, 6 Sep 2024 17:20:03 +0800 (+08) (envelope-from xiong.quan@zte.com.cn)
Received: from mapi (njb2app07[null]) by mapi (Zmail) with MAPI id mid201; Fri, 6 Sep 2024 17:20:05 +0800 (CST)
Date: Fri, 06 Sep 2024 17:20:05 +0800
X-Zmail-TransId: 2aff66dac945ffffffff997-82e5b
X-Mailer: Zmail v1.0
Message-ID: <20240906172005470rVkrD2uj3_bzEZJX66mUG@zte.com.cn>
Mime-Version: 1.0
From: xiong.quan@zte.com.cn
To: gregimirsky@gmail.com, jmh@joelhalpern.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 4869K2Io017164
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 66DAC991.002/4X0W1s5f1Jz4xth3
Message-ID-Hash: HWVMO47CNQM6FPK4PHOGUJAYAUCQH66M
X-Message-ID-Hash: HWVMO47CNQM6FPK4PHOGUJAYAUCQH66M
X-MailFrom: xiong.quan@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: pce@ietf.org, draft-ietf-pce-sr-path-segment@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/wELlVSXe0si79icnxgRTdo4_yhY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Owner: <mailto:pce-owner@ietf.org>
List-Post: <mailto:pce@ietf.org>
List-Subscribe: <mailto:pce-join@ietf.org>
List-Unsubscribe: <mailto:pce-leave@ietf.org>

Hi Greg, Joel and all,

Thanks for your discussion on the MPLS mailing list as following link shown~
https://mailarchive.ietf.org/arch/msg/mpls/e3CI8xeDN1OTu5FgAIB6tI_yRaY/ 

Allow me to take the discussion to PCE. As per RFC9545 and draft-ietf-spring-srv6-path-segment, a path segment can identify a SR path, a SR policy,  a candidate-path or a SID-List in a SR policy. But this document did not mention the path segment processing within SR policy PCEP instantiation. It may cause some misunderstandings about PCEP processes and parameters for path segment within a SR policy.  So I suggest to add some texts for next version of this draft.  Please see inline with <suggested text>.


  1 Introduction     [RFC8664] specifies extensions to the Path Computation Element
   Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE
   to compute and initiate SR-TE paths, as well as a PCC to request,
   report or delegate SR paths. <suggested text> "[ietf-pce-segment-routing-policy-cp]
   specifies the PCEP extension to signal candidate paths of the SR Policy. "      This document specifies a mechanism to carry the SR path
   identification information in PCEP messages [RFC5440] [RFC8231]
   [RFC8281].  The SR path identifier can be a Path Segment in SR-MPLS
   [RFC9545] and SRv6 [I-D.ietf-spring-srv6-path-segment], or other IDs
   that can identify an SR path <suggested  text> "or an SR Policy".  This document also extends the PCECC-
   SR mechanism to inform the Path Segment to the egress PCC.               5.1.1 Ingress PCC-Initiated Path Segment Allocation      The PATH-SEGMENT TLV MUST be included in an LSP object in the
   PCInitiate message sent from the PCE to the egress to request Path
   Segment allocation by the egress PCC.  The P flag in LSP object MUST
   be set to 0.  This PCInitiate message to egress PCC would be the
   similar to the one sent to ingress PCC as per [RFC8664], but the
   egress PCC would only allocate the Path Segment and would not trigger
   the LSP initiation operation (as it would be the egress for this
   LSP). <suggested  text> "The association object should also be carried in PCInitiate message
   to indicate the SR policy association parameters  as per [ietf-pce-segment-routing-policy-cp] 
   if this path segment identifies an SR policy."   
What is your thoughts with these texts? Thanks!

Best Regards,
Quan




<<[Pce] I-D Action: draft-ietf-pce-sr-path-segment-10.txt
internet-drafts@ietf.org Wed, 28 August 2024 13:56 UTCShow header
Internet-Draft draft-ietf-pce-sr-path-segment-10.txt is now available. It is a
work item of the Path Computation Element (PCE) WG of the IETF.

 Title: Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR)
 Authors: Cheng Li
 Mach(Guoyi) Chen
 Weiqiang Cheng
 Rakesh Gandhi
 Quan Xiong
 Name: draft-ietf-pce-sr-path-segment-10.txt
 Pages: 25
 Dates: 2024-08-28

Abstract:

 The Path Computation Element (PCE) provides path computation
 functions in support of traffic engineering in Multiprotocol Label
 Switching (MPLS) and Generalized MPLS (GMPLS) networks.

 The Source Packet Routing in Networking (SPRING) architecture
 describes how Segment Routing (SR) can be used to steer packets
 through an IPv6 or MPLS network using the source routing paradigm. A
 Segment Routed Path can be derived from a variety of mechanisms,
 including an IGP Shortest Path Tree (SPT), explicit configuration, or
 a Path Computation Element (PCE).

 Path identification is needed for several use cases such as
 performance measurement in Segment Routing (SR) network. This
 document specifies extensions to the Path Computation Element
 Communication Protocol (PCEP) to support requesting, replying,
 reporting and updating the Path Segment ID (Path SID) between PCEP
 speakers.

The IETF datatracker status page for this Internet-Draft is:https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/There is also an HTMLized version available at:https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment-10A diff from the previous version is available at:https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sr-path-segment-10Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts

[Pce] I-D Action: draft-ietf-pce-sr-path-segment-…  internet-drafts