All good, Samuel.
Wrt implementation status: it is meant to go out of date. That’s why the section is removed before publication as an RFC. Anyway, probably not going to get a response from the implementers on an open channel :-) Go ahead. Adrian From: Samuel Sidor (ssidor) <[email protected]> Sent: 24 February 2026 14:10 To: [email protected]; [email protected] Cc: [email protected] Subject: Re: Shepherd review of draft-ietf-pce-multipath Thanks a lot, Adrian. Please find inline response <S2>. Regards, Samuel From: Adrian Farrel <[email protected]> Date: Friday, 20 February 2026 at 13:50 To: Samuel Sidor (ssidor) <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: RE: Shepherd review of draft-ietf-pce-multipath Hi Samuel, This is all looking very good. Thanks for the work. Following up on a few small points. Cheers, Adrian >> 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). Yes, it is the case of an association that bothers me. Signal forward path without a reverse path. Signal reverse path with association to forward path. But forward path does not yet have association to reverse path. Agree that this situation will resolve (forward path is resignaled), but there is a window that appears to be a failure case. But this all goes away with… <S2> I added section 4.5 based on comment from Giuseppe to clarify processing of that TLV (and to maintain consistency with other TLVs). In that section, I'm adding something like this: Opposite-direction paths can be signaled in two ways: * Within the same LSP: Forward paths (R-flag=0) and reverse paths (R-flag=1) are included in the same PCEP message, allowing bidirectional relationships to be established atomically. In this case, the opposite-direction path associations MUST be symmetric within the same message. When path A references path B as its opposite-direction path, path B MUST also reference path A as its opposite-direction path. Additionally, their R-flags in the PATH-ATTRIB object MUST have opposite values (one set to 0, the other to 1). * Across associated LSPs: Forward and reverse paths are signaled in separate LSPs that are associated using the ASSOCIATION object as defined in {{?RFC9059}}. In this scenario, opposite-direction paths are established in separate PCEP messages. When a path references an opposite-direction path in an associated LSP, that referenced path SHOULD already be established. However, transient asymmetry is expected during LSP establishment or update operations, as the two LSPs are signaled independently. The opposite-direction path associations SHOULD eventually become symmetric once both LSPs are fully established or updated. For paths within the same LSP, if a PCEP speaker receives an opposite-direction path mapping that is asymmetric or where the R-flags are inconsistent, it MUST send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = TBD4 ("Invalid opposite-direction path mapping"). For paths across associated LSPs, PCEP speakers SHOULD tolerate transient asymmetry during LSP establishment or update operations. Are you fine with that? >> 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. You appear to be saying: * P2P reverse paths not in scope for this document because P2P is out of scope * P2MP reverse path is deferred to P2MP draft if needed So reverse path is struck from this document? <S2> P2P is ruled out for backup, but not for reverse path. That should be still allowed - e.g. combination of load-balancing and reverse paths. >> 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. Ah, sorry about that. Must have become distracted. You have almost completely answered the point. Be careful about “local” – do you mean per link, per node, per subnet, per PCE domain, per operator, … ? If the scope is wider than a node, how are policies kept consistent across multiple nodes? (You may be able to punt this “Operational Considerations”) <S2> I updated it to: FC (3 bits): Forwarding class value as defined in Section 8.6 of {{!RFC9256}}. This value is given by the QoS classifier to traffic entering the given Candidate Path. Different classes of traffic that enter the given Candidate Path can be differentially steered into different Colors. The FC field allows up to 8 different forward classes (values 0-7). The semantics of specific FC values are significant at the headend node (PCC) that implements the SR Policy and are determined by that node's local QoS policy or configuration. Coordination of FC value meanings between PCEP peers (e.g., through out-of-band configuration management or operational procedures) is outside the scope of this document. And I also renamed "Forward class" to "Forwarding class" in the draft to align naming with RFC9256. >> 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. Hmmm. I assumed that in this context “originator” was supposed to be an IPv6 address. But, I should have looked at RFC 9256 (which you did reference!) and specifically section 2.4 There we have: Autonomous System Number (ASN): represented as a 4-byte number. If 2-byte ASNs are in use, the low-order 16 bits MUST be used, and the high-order bits MUST be set to 0. Node Address: represented as a 128-bit value. IPv4 addresses MUST be encoded in the lowest 32 bits, and the high-order bits MUST be set to 0. So, I suspect your encoding with a colon is a convenience (as shown in 2.13 of 9256) and I won’t push against that now (should have caught it when reviewing 9256 before it was published) And that leaves us with: 1. This example is not trying to use an IPv6 address 2. The example should use documentation addresses from the IPv4 space (as you noted above) 3. There would, ideally, be an example using IPv6 addresses (I mean, SRv6 not SRv4 ;-) 4. The encoding using a colon is going to be very confusing when you use an IPv6 address <S2>I'm fine with even splitting ASN from IP address of originator and do not follow convention from RFC9256 as I agree that it may not be ideal for IPv6. At least we would not propagate tht problem further. E.g. something like: Candidate Path CP1 <protocol-origin = 20, originator-asn = 100, originator-address = 192.0.2.1, discriminator = 1> >> 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". You probably have the best solution. Fixing up the addresses would work as well. >> 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". Yeah. Of course, the cynic in me says “Partial? Which parts?” <S2> What about "Partial (for details reach listed contact person)" 😊 I agree that more details may be better, but I can imagine that it can go out of sync quickly as well. I'll use "Partial" so far.
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
