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

[Joel Halpern <[e-mail]>]

These references appear useful.  There is however one aspect that I am 
missing.  It may well be my own mistake, rather than a problem in the 
draft.  The usage of the sr path segment relies on the tail of the path 
being able to recognize the path segment label.  I am not familiar with 
any usage of PCE that communicates path information to the LSP tail end, 
rather than the head end. Looking at the drat you point to in these 
changes, I do not see any addition of tail notification.  Is there 
already a PCE tail notification that I have forgotten about?

Thank you,

Joel

On 9/6/2024 5:20 AM, [e-mail] wrote:
>
>
> 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
>
> [e-mail] Wed, 28 August 2024 13:56 UTCShow header 
> <https://mailarchive.ietf.org/arch/browse/pce/?gbt=1&index=#>
>
> 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-…
>     <https://mailarchive.ietf.org/arch/msg/pce/cvSuUZ3pjmArFBkgNLC4TY0xvI4/>  internet-drafts
>
>