[Pce] Re: Shepherd Review of draft-ietf-pce-sr-bidir-path-19

[Dhruv Dhody <[e-mail]>]

Hi Rakesh,

Thanks for quickly handling the comments and sharing the update. Please
post it and I will ship the draft to our AD.

Thanks!
Dhruv

On Thu, Jan 8, 2026 at 5:07 AM Rakesh Gandhi <[e-mail]> wrote:

> Hi Dhruv,
>
> Happy New Year!
>
> Thank you for the thorough review of the draft.
>
> Attaching work in progress updates to the draft that address your comments.
>
> Please see replies inline with <RG>...
>
> On Wed, Jan 7, 2026 at 6:44 AM Dhruv Dhody <[e-mail]> wrote:
>
>> Hi Authors,
>>
>> I have finished the shepherd review of the draft. I have noted some minor
>> comments and nits that should be fixed before sending the draft to our AD.
>>
>> ## Minor
>>
>> * Introduction (and abstract) mentions ‘tunneling paradigms’; note that
>> RFC 8402 does not use that term. Suggest removing it.
>>
>
> <RG> Fixed.
>
>
>>
>> * Section 1, “This allows both endpoint ingress nodes to be aware of the
>> SR paths in both directions, including their status and all other
>> path-related information”; don't we need to remove the text about status
>> and path-related information based on the recent changes in the draft?
>>
>
> <RG> Fixed.
>
>
>>
>> * Section 3, should RFC 9059 (which is about RSVP-TE only) be listed?
>>
>
> <RG> Removed.
>
>
>>
>> * Section 3.1, Step 1 is unclear, as the first and second sentences use
>> 'MAY' and 'MUST' with essentially the same condition, which makes it
>> difficult to understand under what circumstances each applies.
>>
>
> <RG> Fixed to use non-normative language as it uses the existing RFC
> messages. Does that help?
>
>
>> Mentioning PLSP-ID in Step 2 is unnecessary since the reverse-side LSP
>> creation is removed, and PLSP-ID allocation follows normal PCEP behavior
>> and does not need to be restated here, nor does it need to be expressed as
>> a normative MUST.
>>
>
> <RG> It would be good to say what happens on PCC.
> <RG> Fixed to use non-normative language as it uses the existing RFC
> messages.
>
>
>
>> In Figure 1, can we explicitly state that F1==R1 and F2==R2, as well as
>> at PCC, the association #1 has a single LSP in the group.
>>
>
> <RG> Added.
>
>
>>
>> * Section 3.2, here as well, step 1 MAY and MUST use is unclear to me.
>> What is the change of association group now? And the above comments apply
>> here as well.
>>
>
> <RG> Updated as above.
>
>
>>
>> * Section 4.1, Can we reuse “5 | Double-Sided Bidirectional LSP
>> Association | RFC 9059” instead of defining a new association type? Any
>> behavior change can be handled via PST? If a new association type is needed
>> than it should be justified.
>>
>
> <RG> The concept is different for RSVP-TE, where the association of the
> reverse LSPs happen on the PCCs via signalling, whereas for SR-TE, the
> association happens on PCE and PCC is just given the reverse EROs, there is
> no instantiation of reverse SR LSPs on PCCs.
>
> <RG> Overloading the type with different procedures based on PST would be
> kludgy, IMO.
>
> <RG> Association type has a range of 64K values available; it is not a
> scarce resource and not worth saving one value.
>
>
>
>> Remove MUST in the 3rd paragraph, when restating behaviour from the
>> published RFC.
>>
>
> <RG> Removed the paragraph as it is just repeating the existing procedure.
>
>
>> * Section 4.1, we need better error handling. For the first bullet, apart
>> from not sending associated reverse SR path EROs to PCC, we need to raise
>> an alarm and log it. For the second, we have an existing error “19:
>> Endpoint mismatch in the association group” from 9059 that could be reused?
>>
>
> <RG> Added.
>
>
>>
>> * Section 4.2, for R flag, we should explicitly state that it MUST NOT be
>> set and if received, it MUST be ignored"
>>
>
> <RG> Added.
>
>
>>
>> * Section 5.4, it sounds like you are saying PSID can be used instead of
>> association. I would also suggest not mentioning any details such as
>> PATH-SEGMENT TLV, especially since no change is being made to it.
>>
>
> <RG> Updated.
>
>
>>
>> * Section 5.5, can we simplify this -
>>
>> OLD:
>> [RFC9059] in Section 5.7, defines a PCErr message for the Path Setup Type
>> (PST) of ‘0: Path is set up using the RSVP-TE signaling protocol’
>> [RFC8408]. The PST for SR path is set to ‘1: Traffic-engineering path is
>> set up using Segment Routing’ [RFC8664] or ‘3: Traffic engineering path is
>> set up using SRv6’ [RFC9603]. If a PCEP speaker receives an unsupported PST
>> value for the ‘Double-Sided Bidirectional with Reverse LSP Association’,
>> the PCE speaker MUST return a PCErr message with Error-Type = 26
>> (Association Error) and Error-value = ‘16: Path Setup Type not supported’
>> [RFC9059].
>> NEW:
>> The PST for SR path is either ‘1: Traffic-engineering path is set up
>> using Segment Routing’ [RFC8664] or ‘3: Traffic engineering path is set up
>> using SRv6’ [RFC9603]. If a PCEP speaker receives a non-SR PST value for
>> the ‘Double-Sided Bidirectional with Reverse LSP Association’, the PCE
>> speaker MUST return a PCErr message with Error-Type = 26 (Association
>> Error) and Error-value = ‘16: Path Setup Type not supported’ [RFC9059].
>> END
>>
>
> <RG> Updated.
>
>
>>
>> * Section 7, consider adding this - “as per the recommendations and best
>> current practices in [RFC9325]”
>>
>
> <RG> Added.
>
>
>>
>> * Section 8, avoid repetition of references in 8.1, 8.3, 8.4, and 8.6
>> since you have already added text in section 8. I think you can also add a
>> reference to RFC 8697 for association-related stuff.
>>
>
> <RG> Updated.
>
>
>>
>> * Section 10.2, RFC 8253 should be a normative reference.
>>
>
> <RG> Updated.
>
>
>>
>> ## Nits
>>
>> * Let me suggest a rewrite for your abstract to make it flow better -
>>
>> ````
>> The Path Computation Element Communication Protocol (PCEP) provides
>> mechanisms for Path Computation Elements (PCEs) to perform path
>> computations in response to Path Computation Clients (PCCs) requests.
>> Segment Routing (SR) can be used to steer packets through a network
>> employing the source routing paradigm. Stateful PCEP extensions for SR,
>> allow a PCE to maintain state and to control and initiate SR Traffic
>> Engineering (TE) paths.
>>
>> PCEP supports grouping of two unidirectional MPLS-TE Label Switched Paths
>> (LSPs), signalled via RSVP-TE, using association. This document defines
>> PCEP extensions for grouping two unidirectional SR paths (one in each
>> direction in the network) into a single associated bidirectional SR path.
>> The mechanisms defined in this document are applicable to both stateless
>> and stateful PCEs for PCE-initiated and PCC-initiated LSPs.
>> ````
>>
>>
> <RG> Updated.
>
>
>> * Section 1, s/The RSVP-TE signals the forward LSP to the egress
>> nodes/The forward LSPs to the egress nodes are signaled using RSVP-TE/
>>
>
> <RG> Updated.
>
>
>>
>> * Section 1, s/learn the reverse LSPs/learn the corresponding reverse
>> LSPs/
>>
>
> <RG> Updated.
>
>
>>
>> * Section 1, this sentence needs rephrasing - “An SR Policy contains one
>> or more Candidate Paths (CPs) [RFC9256] from which one or more Candidate
>> Paths can be computed via PCE”, maybe - “An SR Policy contains one or more
>> Candidate Paths (CPs) [RFC9256], which may be computed by a PCE”. Also,
>> “When a Candidate Path is computed by the PCE, it means that the PCE
>> computed all SLs of that Candidate Path”, can this be - “When a Candidate
>> Path is computed by the PCE, the PCE computes one or more Segment Lists for
>> that Candidate Path”.
>>
>
> <RG> Updated.
>
>
>>
>> * Section 4.1, s/PCE peers/PCEP peers/ or just say PCCs in this context?
>>
>
> <RG> Updated.
>
> Again, many thanks for the great review and suggestions.
>
> Regards,
> Rakesh (for authors)
>
>
>
>
>
>> Thanks!
>> Dhruv
>> _______________________________________________
>> Pce mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>