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

[Joel Halpern <[e-mail]>]

It seems to me these additions would be helpful.

Yours,

Joel

On 9/9/2024 5:22 AM, [e-mail] wrote:
>
>
> 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 <[e-mail]>
> *To: *Joel Halpern <[e-mail]>;
> *Cc: *熊泉00091065;[e-mail] 
> <[e-mail]>;[e-mail] 
> <[e-mail]>;[e-mail] 
> <[e-mail]>;
> *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.direct@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, [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
>
>