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. 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. 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? 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. 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. 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. 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. --- ## 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". No minor issues found. --- _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
