Hi Rakesh, Thanks for posting the update and for your responses.
The document is now much simplified (majorly leverages RFC9059) and focuses on the differences related to SR LSPs. I hope the WG can take a closer look to ensure that no important/relevant details have been missed out. It looks good to me. Dhruv (as shepherding co-chair), could you please check formally with the WG that the updates are good with them and we still have consensus? Also, is it OK for me to hold this document off IESG evaluation until the WG sends over the Multipath draft as well? It would help ensure that the two documents are well-aligned and there are no inconsistencies. It would be nicer for other reviewers to review them in order. Thanks, Ketan On Wed, Feb 4, 2026 at 9:17 PM Rakesh Gandhi <[email protected]> wrote: > 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 <[email protected]> > 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
