Hi Samuel, Thanks for your prompt feedbacks
I think that your proposed changes fully address my comments Italo From: Samuel Sidor (ssidor) <[email protected]> Sent: martedì 24 febbraio 2026 14:04 To: Italo Busi <[email protected]>; [email protected] Cc: [email protected]; [email protected] Subject: Re: draft-ietf-pce-multipath-19 early Opsdir review Hi Italo, Thanks a lot for your review. Please see inline <S>. Regards, Samuel From: Italo Busi via Datatracker <[email protected]<mailto:[email protected]>> Date: Wednesday, 18 February 2026 at 16:20 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: draft-ietf-pce-multipath-19 early Opsdir review Document: draft-ietf-pce-multipath Title: Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information Reviewer: Italo Busi Review result: Ready Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. - Document: draft-ietf-pce-multipath-19 - Reviewer: Italo Busi - Review Date: 17 February 2026 - Intended Status: Standards Track --- ## Summary - Has Issues: I have some minor concerns about this document that I think should be resolved before publication. ## General Operational Comments Alignment with RFC 5706bis This document defines a mechanism for signaling multi-path LSPs using PCEP, including also a mechanisms for the PCE speakers to exchange information about their capabilities in support of multi-path LSPs. Although the primary focus is the support of SR Candidate Path with more than one Segment List, the solution is generic and this generalization is clearly stated in the scope and introduction of the document. The document does not strictly follow the RFC5706bis guidelines, although the Manageability Considerations section (section 10) provides sufficient guidelines for operating the protocol extensions defined in the document and it is aligned with RFC6123. ## Major Issues No major issues found. --- ## Minor Issues These comments are mainly editorial and intended to clarify (e.g., making it more explicit) some interpretations of the current text based on my understanding. 1) Section 3.4 OLD This TLV is used to specify protecting standby path(s), for each ECMP path within a PCEP LSP. This is similar to path protection, but works at the ECMP path level instead of at the PCEP LSP level. NEW This TLV is used to describe a set of backup path(s) protecting a primary path within a PCEP LSP: see Section 4.4 for details. This is similar to path protection, but works at the ECMP path level instead of at the PCEP LSP level. Without the clarification text in section 4.4 it was very hard for me to understand how this TLV could be used by just reading this section. <S> I'll update it. 2) Section 3.5 Can N and L bits be set independently in the MULTIPATH-OPPDIR-PATH TLV? I think that a link co-routed path is also node co-routed. One option is to be liberal and ignore N when L is set. Another option is to force that N is also set when L is set. It would be better if the document is explicit about this point. <S> Thanks, Adrian (document shepherd) raised same comment, this is proposed text: * N (Node co-routed): If set, indicates this path is node co-routed with its opposite direction path, specified in this TLV. Two opposite direction paths are node co-routed if they traverse the same nodes, but MAY traverse different links. If not set, the paths are not guaranteed to be node co-routed (they may or may not traverse the same set of nodes). * L (Link co-routed): If set, indicates this path is link co-routed with its opposite direction path, specified in this TLV. Two opposite direction paths are link co-routed if they traverse the same links (but in opposite directions). Link co-routing implies node co-routing; therefore, it is not necessary to set the N flag when the L flag is set Are you fine with that? 3) Section 3.5 Is there any difference between reporting a MULTIPATH-OPPDIR-PATH TLV with Opposite Direction Path ID set to zero or not reporting the MULTIPATH-OPPDIR-PATH TLV at all? <S>Both should indicate same thing. I'll add statement to clarify and I'll try to double confirm with other co-authors (in case if it was intended to be used as indication that for example PCE tried to compute reverse path, but failed to find it). 4) Section 4.1.1 OLD New MULTIPATH-CAP TLV is defined. This TLV MAY be present in the OPEN object during PCEP session establishment. NEW New MULTIPATH-CAP TLV is defined. This TLV MAY be present in the OPEN object during PCEP session establishment. It MAY also be present in the LSP object for each individual LSP from the PCC. The proposal is to keep the first paragraph consistent with the rest of the section. <>Ack, I'll update it. 5) Section 4.1.1 OLD * O-flag: whether MULTIPATH-OPPDIR-PATH TLV is supported and requested. If this flag is set, the PCE SHOULD tell the PCC the reverse path information, if it is able to. NEW * O-flag: whether MULTIPATH-OPPDIR-PATH TLV is supported by the PCE or requested by the PCC. If this flag is set by the PCC, the PCE SHOULD tell the PCC the reverse path information, if it is able to. If my understanding is correct, it would be useful to be more explicit as proposed above. <S> I assume that your proposed text is not fully covering PCE-initiated LSPs (e.g. consider one PCE creating that LSP, which will be later re-delegated to other PCE for path-computation). What about: * O-flag: In the OPEN object, this flag indicates whether the MULTIPATH-OPPDIR-PATH TLV is supported. In the LSP object, this flag indicates that opposite-direction path information is requested or provided for that specific LSP. When set by the PCC (in PCRpt/PCReq), it requests the PCE to provide reverse path information. When set by the PCE (in PCInit/PCUpd/PCRep), it indicates the PCE is providing or will provide reverse path information. In both cases, the PCE SHOULD provide the reverse path information, if it is able to. 6) Section 4.1.1 OLD When PCE computes the LSP path, it MUST NOT return more forward multipaths than the corresponding value of "Number of Multipaths" from the MULTIPATH-CAP TLV. <...> NEW When PCE computes the LSP path, it MUST NOT return more forward multipaths than the corresponding value of "Number of Multipaths" in the MULTIPATH-CAP TLV received from the PCC. <...> If my understanding is correct, it would be useful to be more explicit as proposed above. <S> There was already suggestion from Adrian to change it to: When a PCE computes an LSP path, it MUST NOT return more forward multipaths than the minimum of the "Number of Multipaths" values advertised by both the PCE and PCC in their respective MULTIPATH-CAP TLVs during capability negotiation. Are you fine with that version as well? 7) Section 4.1.1 The last paragraph seems an example associated with the third to last paragraph and not with the penultimate paragraph. I would suggest to swap the order of the last two paragraphs. <S> Ack, I'll change it. --- ## Nits Optional editorial suggestions (e.g., acronym expansions or grammar fixes). 1) Section 4.3: please expand PLSP on first use. - Example: > Abstract: Expand "NFV" on first use. > Section 3.1: "it's" -> "its". <S> Thanks, I"ll fix those. No minor issues found. ---
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
