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. 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. 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. 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. 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. 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 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. 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. 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? 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? 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? 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. 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" ? 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? 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. 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) ? 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)? 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? 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? 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? 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? 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. 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? <EoRv20>
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
