Thanks a lot, Adrian for the review. Please find responses inline marked with <S>.
Regards, Samuel From: Adrian Farrel <[email protected]> Date: Tuesday, 17 February 2026 at 20:35 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: Shepherd review of draft-ietf-pce-multipath Hi authors, I'm your shepherd for the next stage of the journey. As part of that process, I am doing a review during working group last call to be ready to do the shepherd write-up. I found a number of issues and nits which will require some discussion and a new revision. Best, Adrian === Author count. As you all know, the RFC Editor has a front page limit of five authors unless the IESG can be persuaded to vary that. The shepherd is expected to provide *good* reasons why a document has more than five front-page authors. The options here are: 1. Reduce the count to 5 by moving some to Contributors. Perhaps you could limit to one per company. 2. Drop to just the Editor on the front page and move everyone else to Contributors. 3. Come up with a really good reason that will convince me, and I will try to convince the AD. <S> The same topic was already discussed with other co-authors and resulted in reduction of number of authors from 9 to 7, but I initiated another mail thread to agree on next steps. Please give me a few more days to get closure on this. --- Are you really updating 8231 and 8281? An update would mean that an implementation of either of those RFCs MUST include what is in this document. I think it is probable that you are simply defining a new tool that an implementation may choose to include. This view is supported by the fact that you have defined a mechanism to discovery whether the tool is supported. <S> I agree that it is new tool and it is even guaraded with new capabilities, so update is probably not required. I'll udpate the RFC to drop it. --- The Abstract got me quite worried because PCEP, as defined in 5440, allows a PCE to supply multiple paths. Section 6.5 The PCRep message may also contain multiple acceptable paths corresponding to the same request. ...and then... If the path computation request can be satisfied (i.e., the PCE finds a set of paths that satisfy the set of constraints), the set of computed paths specified by means of Explicit Route Objects (EROs) is inserted in the PCRep message. The ERO is defined in Section 7.9. The situation where multiple computed paths are provided in a PCRep message is discussed in detail in Section 7.13. Furthermore, when a PCC requests the computation of a set of paths for a total amount of bandwidth by means of a LOAD-BALANCING object carried within a PCReq message, the ERO of each computed path may be followed by a BANDWIDTH object as discussed in section Section 7.16. It was only when I got to "[RFC9862] specifically avoids defining how to signal multiple Segment Lists" that it became clear that you are talking about PCEP for SR. I think your Abstract could use a little cleaning up. And the document title is probably wrong as well. The nub of the problem comes in section 2.1. It is not that multiple EROs cannot be present on a PCRep; the problem is with the definition of "path" and "LSP" in SR. We're not going to fix any of that (although, IMHO, it would be really neat if we could), so what this document needs to do, up front and in the Introduction, is set out the terminology... - Path - LSP - Segment list - ERO Then everything else will fall into place. You should also check through the rest of the text (especially the Introduction) for places where it says "PCEP" but means "PCEP for SR" or "multipath" where it means "SR multipath". <S> The base idea was that the draft defines extensions for SR, but in a way that it can be easily re-used for other path types in the future That's why even terminology in the draft is trying to be generic ("path" vs "segment-list"). If we will strictly define all new TLVs/objects with SR terminology, then it can be difficult to re-use them for different path types. But I agree that current text in abstract is not correct, when it is saying that PCEP was not allowing encoding of multiple paths before and I'll fix it to make it more SR specific and update terminology as you suggested. I'll re-check other sections as well. --- 3.2 Why does this text use "SHOULD" and not "MUST"? Under what circumstances would this not be the case (i.e., what is the missing "MAY")? But, anyway, it reads very odd so say something about per PATH metrics and then immediately say per-path metrics are out of scope. Why do you mix "PATH" and "path"? <S> What about: The PCEP METRIC object can continue to be used at the LSP level. Mechanisms for encoding per-path metrics (e.g., a separate METRIC for each path) are outside the scope of this document and would require further extensions. --- 3.4 Why not move the definition of the MULTIPATH-BACKUP TLV to [I-D.draft- ietf-pce-sr-p2mp-policy] since that appears to be the only use case for it at the moment and since you are specifically ruling out P2P at this time? And given that you are ruling out P2P, why do you only say the an implementation "SHOULD" reject a MULTIPATH-BACKUP TLV applied to a P2P path? On the other hand, I fail to see why p2p is such a hard case that has to be excluded here. After all p2p is just p2mp is the special case of a single destination. The example in 6.2 seems to work for p2p. <S> P2P was excluded as there were concerns that use for P2P will require further definition as since there is known usecase currently, the it was considered as safer to exclude it and any future document, which will define usecase, you unblock use of it (potentially with required capabilities as well since implementations may not properly support it). For moving "MULTIPATH-BACKUP TLV" to P2MP draft - that discussion happened already (including during last presentantion on IETF), but overall preference from authors of both drafts was to preserve it in this draft to allow potential re-use (P2P, but also other path types) and keep "framework" to support multiple paths in single document (even if that is not that strong argument after you high-lighted existing LOAD-BALANCING object). I'll convert SHOULD to MUST. --- 3.4 It would be really helpful to what the Backup Path IDs match against. Where are the identifiers of the backup paths found? <S> I'll change to: Backup Path ID(s): A series of 4-octet identifier(s) that reference the Path ID field (see {{PATH-ID}}) of other PATH-ATTRIB objects within the same PCEP LSP. These referenced paths act as backup paths that protect this primary path. Each Backup Path ID value MUST match the Path ID of a PATH-ATTRIB object in the same LSP that has the B-flag set (indicating it is a pure backup path). And I'll update section 3.5 based on that as well ("Opposite Direction Path ID" field definition). --- 3.5 New MULTIPATH-OPPDIR-PATH TLV is optional in the PATH-ATTRIB object. Multiple instances of the TLV are allowed in the same PATH-ATTRIB object. This TLV encodes a many-to-many mapping between forward and reverse paths. I don't think this TLV encodes a many-to-many mapping because it is present in the PATH-ATTRIB object of a single path, and encodes a single Opposite Direction Path ID. So, the TLV encodes a relationship between two paths, one in each direction. You cover this nicely, later, with: Multiple instances of this TLV present in the same PATH-ATTRIB object indicate that there are multiple opposite-direction paths corresponding to the given path. This allows for many-to-many relationship among the paths of two opposite direction LSPs. <S>I'll update to: New MULTIPATH-OPPDIR-PATH TLV is optional in the PATH-ATTRIB object. Multiple instances of the TLV are allowed in the same PATH-ATTRIB object. Each TLV instance identifies one opposite-direction path for the path described by this PATH-ATTRIB object. When multiple instances of this TLV are present in the same PATH-ATTRIB object, they collectively enable a many-to-many mapping between forward and reverse paths. --- 3.5 I think you need some commentary on the non-setting of bits N and L. In particular, not setting N does not mandate that the two paths use different nodes: they may use the same or different nodes. You might also note that setting L implies that the two paths also use the same set of nodes, but it is not necessary to set N when L is set. <S> Please check update definition of those flags: * 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. --- 3.5 You describe the requirement that if path a shows an opposite direction relationship with path b. But (presumably) there is the possibility of setting up paths one at a time. How does that work? <S> Do you mean in case of opposite paths associated within single LSP? If yes, then I would expect them to be always signalled atomically - I can add text to mnake it clear: Typically, the referenced path is in the same PCEP LSP, where forward paths (R-flag=0) and reverse paths (R-flag=1) are signaled together in a single PCEP message. This allows bidirectional path relationships to be established atomically within one LSP. Alternatively, the referenced path may be in an associated opposite-direction LSP (using the ASSOCIATION object per RFC 9059). --- 3.5 I wondered, given that the draft rules out using the backup processing for p2p paths, whether you should rule out using the reverse path association for p2mp paths. It is certainly the case that p2mp reverse path is a complex issue. <S> I'm fine with that. P2MP draft can still define it if needed. --- 3.6 To signal the Composite Candidate Path, we make use of the COLOR TLV, defined in [RFC9863]. For a Composite Candidate Path, the COLOR TLV is included in the PATH-ATTRIB Object, thus allowing each Composite Candidate Path to do ECMP/W-ECMP among SR Policies identified by its constituent Colors. Only one COLOR TLV MUST be included into the PATH-ATTRIB object. If multiple COLOR TLVs are contained in the PATH-ATTRIB object, only the first one MUST be processed and the others MUST be ignored. As written, the use of "MUST" is a little confusing. Are you saying that it is a requirement that a COLOR TLV is present in the PATH-ATTRIB object? I think you can safely delete the "Only one..." sentence. And you can change the second sentence to: If multiple COLOR TLVs are contained in the PATH-ATTRIB object, the first one is processed and the others MUST be ignored. <S> Sure, I'll update it. --- 3.6.1 Is there any guidance about the value of the FC field? Is it <S> Is the comment complete? I can imagine extending definition of FC field for example with following text (but I'm not sure if you are really looking for that or something else): The FC field allows up to 8 different forward classes (values 0-7). The semantics of specific FC values are locally significant and determined by local policy or configuration. --- 4.1.1 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. If this TLV is absent (from both OPEN and LSP objects), then the "Number of Multipaths" is assumed to be 1. The value the PCE sent, or the value the PCC sent? Or both? And what if it does? <S> I can update 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. This ensures the PCE does not exceed either its own computation capability or the PCC's installation capability. If this TLV is absent (from both OPEN and LSP objects), then the "Number of Multipaths" is assumed to be 1. If a PCC receives more paths than it advertised support for, it MUST send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = TBD3 ("Unsupported multipath capability"). --- 5. I wanted to check that the RBNF you present is really what you want. You have: <intended-path> ::= (<ERO>| (<PATH-ATTRIB><ERO>) [<intended-path>]) This is ambiguous because you can't see whether the repeated <intended-path> happens only if (<PATH-ATTRIB><ERO>) is chosen. I think you probably mean: <intended-path> ::= ( <ERO> | (<PATH-ATTRIB><ERO>) ) [<intended-path>] If so, you could write: <intended-path> ::= [<PATH-ATTRIB>]<ERO> [<intended-path>] The same for <actual-path> <S> Thanks for finding it. I'll update it. --- 5. Each path is preceded by a PATH-ATTRIB object that describes it. According to the RBNF (whether you make my change or not) this should read: Each path may be preceded by a PATH-ATTRIB object that describes it. <S> Ack, I'll update it. --- 6. I believe your examples should use addresses from the ranges reserved for documentation. That is 2001:db8::/32 and 3fff::/20 <S> Are you referring to "100:1.1.1.1" and "100:2.2.2.2"? If yes, then I assume that we need to replace them with blocks from "https://datatracker.ietf.org/doc/html/rfc5737#section-3"; since those are just combinations of originator ASN (100) and IPv4 addresses. --- 6.1 Consider the following sample SR Policy, taken from [RFC9256]. I don't find that sample in 9256. <S> I assume that it was originally referring to: https://www.rfc-editor.org/rfc/rfc9256#section-2.13 But I can just simplify to "Consider the following sample SR Policy". --- 6.1 It would be useful to refer to 8231 for <state-report> <S> Sure. --- The inclusion of the Implementation Status section is appreciated (although it is pretty thin). Obviously, the early assignments done by IANA has made this a lot easier. Given that there are some code points still marked as TBDx, I wonder how the "full" implementations have been achieved. <S> Ack, I'm not sure about that part. I'll keep authors/contributors from Ciena to comment. Otherwise I can just update it to "Partial". --- 8.1 correctly asks for IANA to confirm the assignment of object-class 45 and the object-type 1. However, it should also describe the other object-type values shown in the registry. <S> Ack, I'll add 0 and 2-15. --- == Nits <S> Ack, for nits. I'll update them. 1. There are no PCEP standards, so probably s/standards/specifications/ --- 2.3 s/path(s)/paths/ --- 3.1 "several ERO/Recorded Route Object (RRO) objects" "ERO/RRO objects" Seems to be tautology --- 3.1 The text should directly reference "Figure 1" --- 3.1 Missing description of "Optional TLVs" --- 3.3 You should probably say that Weight is an unsigned integer --- 3.4 s/path(s)/paths/ (four times) s/ID(s)/IDs/ s/identifier(s)/identifiers/ --- 4.3 Expand PLSP on first use. Does it also need a reference? --- 4.3 Steps 2 and 3 use the passive voice. It would be helpful to say which component is responsible for each action. ---
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
