Hi Joel, On Fri, Sep 6, 2024 at 7:22 PM Joel Halpern <jmh.dir...@joelhalpern.com> wrote:
> 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? > There is a PCECC model RFC 9050 that communicates with all nodes (including the tail) along the path, so there is some precedence. But the path segment draft is the first one that requires communication with the tail end ( https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-10.html#figure-3) outside of the PCECC model. Authors, I suggest that your draft should highlight this explicitly rather than it being buried in a subsection. Thanks! Dhruv > 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 >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
