[Pce] Re: AD review of draft-ietf-pce-sr-bidir-path-20

[Rakesh Gandhi <[e-mail]>]

Thanks Ketan for the detailed review of the document.

You may find the revised version (rev-21) posted with the suggested updates.

   - https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-21

A diff from the previous version is available at:

   -
   https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sr-bidir-path-21


Please see the replies inline with <RG>..

On Fri, Jan 23, 2026 at 10:28 AM Ketan Talaulikar <[e-mail]>
wrote:

> Hello Authors/WG,
>
> This is a partial review of the document as I found it hard to do a
> complete review due to
> the challenges below:
>
> 1) This document leverages RFC9059 in a major way. It could become shorter
> and
> clearer if it were to simply call out the differences for the SR Path
> Setup Types and the
> new Association Type being introduced. By differences I mean things that
> are added
> newly (e.g., the use of PATH_ATTRIB), things that are removed or not
> applicable, and
> the changes (i.e., replacing the code points, names, terminologies). The
> repetition of
> text/procedures and the frequent pointers make it hard to follow.
>
> 2) The mapping of SR Policy terminologies to PCEP terms is lacking or
> unclear.
> The term SR Path is used extensively (basically it's a find/replace of LSP
> to SR Path
> from RFC9059). I found it hard to understand how this integrates not just
> with the
> approach of RFC8664 but also RFC9862.
>
> 3) This document correctly leverages the draft-ietf-pce-multipath but
> lacks the
> reconciliation between RFC9059 and the use of PATH_ATTRIB (see detailed
> comments). I also found myself struggling since I had not yet
> read/reviewed
> draft-ietf-pce-multipath and wished that the WG had sent this document to
> me
> alongwith or after the multipath document. When can I expect it?
>
> This means that I will most likely need to do at least one more pass once
> I get more
> clarity.
>
> Please find below comments from this partial review provided inline in the
> idnits output
> of v20 of this document.
>
> Thanks,
> Ketan
>
> Note: Please look for the tag <EoRv20> at the end to ensure you have
> received the full review.
>
> 105 1.  Introduction
>
> <editorial> This entire section consists of verbose overviews of what
> is specified in 10 other documents (full of references in every other
> sentence).
> Can those be made more concise? More importantly there is no connection
> established between such paragraphs and what is in this document. I've
> provided
> some specific examples. Please consider taking a pass over this section to
> make
> it concise and establish relationships with what's in this document. I
> have also
> provided some suggestions further below.
>

<RG> Edited the section to remove some redundant text.


>
> 107   Segment Routing (SR) [RFC8402] can be used to steer packets through a
>
> <major> I get the impression that this spec applies to both SR-MPLS and
> SRv6.
> However, this is not explicitly being called out anywhere. Please clarify
> in
> the introduction as well as the abstract sections.
>

<RG> Added.
SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes.


>
> 109   packets onto an explicit forwarding path at the ingress node.  SR is
> 110   specified for unidirectional paths.  However, some applications
>
> <major> I am not sure what is meant by "SR is specified for unidirectional
> paths".
> Bidirectional paths are nothing but two unidirectional paths in opposite
> directions.
>

<RG> Removed.


>
> 109   packets onto an explicit forwarding path at the ingress node.  SR is
> 110   specified for unidirectional paths.  However, some applications
> 111   require bidirectional paths in SR networks, for example, in mobile
> 112   backhaul transport networks.  The requirement for bidirectional SR
> 113   paths is specified in [RFC9545] and
> 114   [I-D.ietf-spring-srv6-path-segment].
>
> <minor> Are the last 3 sentences of the above paragraph really needed? The
> use-cases for bidirectional paths are well known and PCEP has had
> extensions
> for them for many years now.
>

<RG> Removed couple of sentences.


>
> 127   to request, report or delegate them.  As specified in [RFC8664], an
> 128   SR path corresponds to an MPLS Label Switching Path (LSP) in PCEP
> 129   when using the SR-TE path setup type.  As specified in [RFC9603], the
> 130   term "LSP" used in the PCEP specifications would be equivalent to an
> 131   SRv6 path (represented as a list of SRv6 segments) in the context of
> 132   supporting SRv6 in PCEP using SRv6 path setup type.
>
> <minor> Can you please check if this document can also introduce a
> terminology
> section as other recent documents? The clarification of the term LSP
> is better placed in such a section. The current text in the Terminology
> section
> has been found to be unhelpful for external/IESG reviews and more recent
> PCEP
> documents have adapted an improved representation for such readers.
>

<RG> Added terminology section.


>
> 140   For bidirectional SR paths, there are use-cases such as directed BFD
> 141   [RFC9612] and Performance Measurement (PM) [RFC9503] that require the
>
> <major> These are not really use-cases. Suggest (same also applies later
> in this
> paragraph):
> s/there are use-cases/there are features
>

<RG> Updated.


>
> 144   ingress nodes (PCCs) using PCEP mechanisms.  This allows both
> 145   endpoint ingress nodes to be aware of the SR paths in both
> 146   directions.
>
> <minor> Perhaps: This allows both endpoint nodes to be aware of the
> forward and
> reverse SR paths.
>

<RG> Updated.


>
> 148   [RFC9059] defines PCEP extensions for grouping two unidirectional
> 149   Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs
> 150   into an associated bidirectional LSP when using a stateful PCE for
> 151   both PCE-initiated and PCC-initiated LSPs as well as when using a
> 152   stateless PCE.  Specifically, it defines the procedure for 'Double-
> 153   Sided Bidirectional LSP Association', where the PCE creates the
> 154   association and provisions the forward LSPs at their ingress nodes.
> 155   The forward LSPs to the egress nodes are signaled using RSVP-TE.
> 156   Thus, both endpoints learn the corresponding reverse LSPs forming the
> 157   bidirectional LSP association via RSVP signaling.
>
> <minor> What this is essentially saying is:
> "PCEP supports grouping of two unidirectional MPLS-TE Label Switched Paths
> (LSPs),
> signaled via RSVP-TE, using Double-Sided Bidirectional LSP Association
> [RFC9059]."
>
> Rest of the text seems overly verbose. More importantly, there is no
> connection being
> made between this paragraph and what is specified in this document. E.g.,
> why
> this existing association type not used? There is some relevant text two
> paras below
> that is related to this - so perhaps this sentence could go there and make
> some
> connection OR use the text that is much better from section 4 (overview) ?
> Anyway I
> won't point to similar instances further and I just wanted to give an
> example to improve
> readability and the set up of context for a reader.
>

<RG> Updated.


>
> 159   An SR Policy contains one or more Candidate Paths (CPs) [RFC9256],
> 160   which may be computed by a PCE.  A Candidate Path of an SR Policy can
> 161   contain one or more Segment Lists (SLs) [RFC9256].  When a Candidate
>
> <minor> Just a single reference to RFC9256 just after the term "SR Policy"
> should
> suffice?
>

<RG> Updated.


>
> 182   Note that the procedure for using the association group defined in
> 183   this document is specific to the associated bidirectional SR paths.
> 184   Associating a unidirectional SR path with a reverse direction
> 185   unidirectional RSVP-TE LSP to form a bidirectional LSP is outside the
> 186   scope of this document.
>
> <minor> Perhaps you mean: "The association group and procedures introduced
> in
> this document are specific to SR related Path Setup Types." And then
> perhaps
> the next sentence is not necessary?
>

<RG> Updated.


>
> 188 2.  Terminology
>
> 190   This document makes use of the terms defined in [RFC8408].  The
> 191   reader is assumed to be familiar with the terminology defined in
> 192   [RFC5440], [RFC8231], [RFC8281], [RFC8697], [RFC9059], and
> 193   [I-D.ietf-pce-multipath].
>
> <major> The term "SR path" is used extensively in this document. I am
> looking
> for a normative definition of what it means vis-a-vis SR Policy constructs
> as
> defined in RFC9256. Please consider both RFC8664 and RFC9862. Do the
> workflows
> in section 3 factor in RFC9862? The text in the introduction indicates that
> SR Path maps to an LSP in PCEP. So, why not just use the existing PCEP term
> LSP everywhere instead of SR Path?
>

<RG> Updated to LSP.


>
> 329 4.  PCEP Extensions
>
> 331   As per [RFC8697], TE LSPs are associated by adding them to a common
> 332   association group by a PCEP peer.  [RFC9059] uses the association
> 333   group object and the procedures as specified in [RFC8697] to group
> 334   two unidirectional RSVP-TE LSPs.  Similarly, two SR paths can also be
> 335   associated using a similar technique.  This document extends these
> 336   association mechanisms for bidirectional SR paths.  Two
> 337   unidirectional SR paths (one in each direction between two nodes in a
> 338   network) can be associated together by using the association group
> 339   defined in this document for PCEP messages.
>
> <minor> Please consider moving the above paragraph to the introduction.
> It provides the context in a clear and concise manner.
>

<RG> Updated.


>
> 348   *  Association Type (value 8) = Double-Sided Bidirectional with
> 349      Reverse LSP Association
>
> <minor> That name is really a mouthful! Why not just
> "Bidirectional SR Association" ?
>

<RG> Updated.


>
> 352   configured.  As per [RFC8697], the association group could be
> 353   manually created by the operator on the PCEP peers, and the LSP
> 354   belonging to this association is conveyed to the PCEP peer;
>
> <major> It is not clear what PCEP peers are being referred to here. There
> is
> the PCE and then two PCCs. Can you please clarify? One of the key
> differences
> between RFC9059 and this document is that there is no protocol like
> RSVP-TE that
> is signaling the EROs and LSP info between the PCCs directly. Which is
> where,
> I am thinking, the PATH_ATTRIB comes into picture. Am I correct?
>

<RG> Removed, seemed stale from previous procedure of reverse LSP.


>
> 355   alternatively, the association group could be created dynamically by
> 356   the PCEP speaker, and both the association group information and the
> 357   LSP belonging to the association group is conveyed to the PCEP peer.
>
> <nit> Please break into two sentences for readability.
>

<RG> Fixed.


>
> 366   This capability exchange for the Bidirectional Association MUST be
> 367   done before using the Bidirectional Association Type.  Thus, the PCEP
>
> <major> Which type? I am assuming it is the new type 8 introduced in this
> document.
> So, it should be the DSBRLA (acronym I created to save me some typing
> work) ?
>

<RG> Updated.


>
> 372   *  An SR path (forward or reverse direction) MUST NOT be part of more
> 373      than one "Double-Sided Bidirectional with Reverse LSP Association"
> 374      on a PCE.  A PCE, upon detecting this condition, MUST NOT send the
>
> <major> What is the identifier of SR path? Now, if the term LSP is used, it
> is clear in PCEP how LSPs are identified. This text is the same
> as in section 4.1 of RFC9059 and that makes me think that a lot more can
> be leveraged from that RFC and this spec probably needs to cover only the
> differences (what is added, what is not applicable, what is handled
> differently)?
>

<RG> Updated to LSP.


>
> 393   The Reverse LSP (R flag) MUST NOT be set for the associated
> 394   bidirectional SR path and MUST be ignored for this association group.
>
> <major> Perhaps you mean - "The Reverse LSP (R flag) is not applicable for
> the
> DSBRLA type and MUST NOT be set by the sender and MUST be ignored
> by the receiver." ? Can you explain why this is not applicable?
>

<RG> Updated, there is no reverse LSP on PCC.


>
> 400   When a PCE informs an ingress node PCC about the associated reverse
> 401   SR path EROs computed for an SR path with the 'Double-Sided
> 402   Bidirectional with Reverse LSP Association', it MUST include the
> 403   'PATH-ATTRIB' object to indicate the reverse direction for each ERO,
> 404   and it MAY optionally include the 'MULTIPATH-OPPDIR-PATH TLV' to
> 405   indicate the co-routed path properties for the ERO using the
> 406   procedure defined in Section 3 of [I-D.ietf-pce-multipath].
>
> <major> So, are there two ways to signal co-routed property - the C-flag
> in the
> Bidirectional LSP Association Group TLV and the PATH-ATTRIB object with the
> MULTIPATH-OPPDIR-PATH TLV? How are conflicts handled?
> Since the new association type name includes the Reverse LSP, I am
> assuming MULTIPATH-OPPDIR-PATH TLV then becomes mandatory? If not,
> how else does the PCC know the reverse ERO?
>

<RG> Added, to detect the mismatch and log this error/alarm.


>
> 408 5.  Additional PCEP Considerations
>
> <major> In this entire section, I find that only the PSID applicability
> and the
> path setup type check to be new/different from RFC9059. Why not just
> specify
> that alone?
>
>
<RG> Removed a couple of sub-sections.



> 434 5.3.  PLSP-ID Usage
>
> 436   For an SR Policy, the ingress PCC node reports a unique PLSP-ID
> 437   [RFC8231] for each CP of the SR Policy.
>
> <major> This is the first usage of the term "SR Policy" in the procedures
> or
> normative portion of this document. Can we use consistent terms in the
> document once they have been defined in the Terminology section?
>

<RG> Updated to LSP.


>
> 446 5.4.  Path Segment Identifier Applicability
>
> 448   [I-D.ietf-pce-sr-path-segment] defines a mechanism for communicating
> 449   Path Segment Identifier (PSID) in PCEP for SR.  The SR-MPLS PSID is
> 450   defined in [RFC9545] and SRv6 PSID is defined in
> 451   [I-D.ietf-spring-srv6-path-segment].  The PSID can be used to
> 452   identify and correlate the traffic for the two unidirectional SR
> 453   paths at both ends of an associated bidirectional SR path.
>
> <major> The above makes the reference to these paths segment drafts
> normative.
> I would suggest covering the applicability of PSIDs in the PCEP PSID
> drafts.
> This is not a mandatory piece for this specification anyway and should not
> hold it up in MISSREF.
>

<RG> Removed.


>
>
> 673   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
> 674              Decraene, B., Litkowski, S., and R. Shakir, "Segment
> 675              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
> 676              July 2018, <https://www.rfc-editor.org/info/rfc8402>.
>
> 678   [RFC8408]  Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
> 679              Hardwick, "Conveying Path Setup Type in PCE Communication
> 680              Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
> 681              July 2018, <https://www.rfc-editor.org/info/rfc8408>.
>
> 683   [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
> 684              and J. Hardwick, "Path Computation Element Communication
> 685              Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
> 686              DOI 10.17487/RFC8664, December 2019,
> 687              <https://www.rfc-editor.org/info/rfc8664>.
>
> 689   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
> 690              A., and P. Mattes, "Segment Routing Policy Architecture",
> 691              RFC 9256, DOI 10.17487/RFC9256, July 2022,
> 692              <https://www.rfc-editor.org/info/rfc9256>.
>
> <major> All of the above are normative references?
>

<RG> Updated.

Thanks,
Rakesh (for authors)




>
> <EoRv20>
>
> _______________________________________________
> Pce mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>