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, xiong.q...@zte.com.cn 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
internet-dra...@ietf.org 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
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
