Hi Quan, Do you mind to lead this update? If yes, please update the xml(You can download it from the datatracker) and share the diff file for authors to review.
I am crazy busy on updating 10+ drafts recently. If you can help on this, I will be very appreciated! Thanks, Cheng From: xiong.q...@zte.com.cn <xiong.q...@zte.com.cn> Sent: Monday, September 9, 2024 11:23 AM To: d...@dhruvdhody.com Cc: jmh.dir...@joelhalpern.com; gregimir...@gmail.com; pce@ietf.org; draft-ietf-pce-sr-path-segm...@ietf.org Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt Hi Dhruv and Joel, Thanks for your suggestion! The adding texts in my last email mainly clarify the path segment related parameters (e.g association) within an SR policy. I think the PCE communicates with the tail instead of a notification, for example, as figure 3 shown, it send PCInitiate message to the egress PCC for PCE tail notification, for example, as figure 3 shown. I agree that the path segment is the first function that requires communication with both tail and head end cause the the path segment should be inserted at the ingress PCC and should be recognized at the egress PCC. From my understanding, the section 3 has described the operations, as per https://www.ietf.org/archive/id/draft-ietf-pce-sr-path-segment-10.html#name-overview-of-path-segment-ex, the path segment can be allocated by egress PCC or PCE. A, If it is allocated by the egress PCC as per section 5.1, the PCE (or ingress PCC first sends requests to the PCE) should request a path segment from egress PCC and notify the ingress PCC. B, If it is allocated by the PCE as per section 5.2, the PCE should allocate a path segment and notify both ingress and egress PCC. Would it be better to clarify it clearly in section 3 like following shown? "There are various modes of operations, such as · The Path Segment can be allocated by Egress PCC. The PCE should request the Path Segment from egress PCC by PCInitiate messge and notify the ingress PCC bu PCUpd messge as per section 5.1.2. · The PCE (or the ingress PCC requests the path segment to PCE) can allocate a Path Segment on its own accord and inform the ingress/egress PCC by PCInitiate or PCUpd messge as per section 5.2.2. · Ingress PCC can also request PCE to allocate the Path Segment, in this case, the PCE would either allocate and inform the assigned Path Segment to the ingress/egress PCC using PCInitiate or PCUpd message, or first request egress PCC for Path Segment and then inform it to the ingress PCC as per 5.1.1. " What is your thoughts? Best, Quan Original From: DhruvDhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> To: Joel Halpern <jmh.dir...@joelhalpern.com<mailto:jmh.dir...@joelhalpern.com>>; Cc: 熊泉00091065;gregimir...@gmail.com <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>;pce@ietf.org <pce@ietf.org<mailto:pce@ietf.org>>;draft-ietf-pce-sr-path-segm...@ietf.org <draft-ietf-pce-sr-path-segm...@ietf.org<mailto:draft-ietf-pce-sr-path-segm...@ietf.org>>; Date: 2024年09月09日 12:43 Subject: Re: [Pce] Re: I-D Action: draft-ietf-pce-sr-path-segment-10.txt Hi Joel, On Fri, Sep 6, 2024 at 7:22 PM Joel Halpern <jmh.dir...@joelhalpern..com<mailto: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<mailto: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
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
