Hi All, I've also issued the IETF LC on this document after checking offline with Dhruv.
If there are any issues or further updates/tweaks needed, do bring them up during this IETF LC period as well and request the authors to address them. Thanks, Ketan On Thu, Feb 5, 2026 at 1:29 AM Ketan Talaulikar <[email protected]> wrote: > ... But I am also happy to send this document to the IESG if the multipath > document is going to take more time to get to me. Please let me know. > > Thanks, > Ketan > > > On Thu, Feb 5, 2026 at 1:21 AM Ketan Talaulikar <[email protected]> > wrote: > >> 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]
