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]
