Hi Samuel,
In Section 4.5:
You seem to have added this use case, which was not part of the original draft:
* 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.
This seems to contradict the requirement that Path ID being unique per PLSP
("The Path ID is unique within the context of a PLSP"). The reverse path is
originated by tail-end router and can allocate the same Path ID (1,2,3, etc.)
as the head-end router allocates
In other words, we shouldn't allow one PLSP to refer to Path IDs of another
PLSP (opposite direction or whatever else). The point of this draft is that
every PLSP is self-contained and has all the info (forward paths, reverse
paths, etc.). If you look at the Example for Opposite Direction Tunnels, you'll
see how Path IDs are used, they are just LOCAL NUMBERS on the head-end.
Thanks,
Mike.
On Friday, February 27th, 2026 at 2:37 PM, Samuel Sidor \(ssidor\)
<[email protected]> wrote:
> Thanks a lot, Adrian for all your review, comments and quick responses.
>
> Yes, I plan to submit it before cut-off (Monday?) if other reviewers are fine
> as well.
>
> Regards,
> Samuel
>
> From: Adrian Farrel <[email protected]>
> Date: Friday, 27 February 2026 at 20:19
> To: Samuel Sidor (ssidor) <[email protected]>,
> [email protected] <[email protected]>
> Cc: [email protected] <[email protected]>
> Subject: RE: Shepherd review of draft-ietf-pce-multipath
>
> You’ve done a really good job, Samuel.
>
> Thanks for paying attention to my review.
>
> Looking forward to you getting the update posted (before the cut-off?).
>
> Cheers
>
> Adrian
>
> From: Samuel Sidor (ssidor) <[email protected]>
> Sent: 27 February 2026 19:12
> To: [email protected]; [email protected]
> Cc: [email protected]
> Subject: Re: Shepherd review of draft-ietf-pce-multipath
>
> Hi Adrian,
>
> Please check updated version to make sure that it is addressing all your
> comments.
>
> It is addressing review comments from other mail threads as well, so the diff
> is not small.
>
> Thanks a lot,
>
> Samuel
>
> From: Adrian Farrel <[email protected]>
> Date: Tuesday, 24 February 2026 at 17:32
> To: Samuel Sidor (ssidor) <[email protected]>,
> [email protected] <[email protected]>
> Cc: [email protected] <[email protected]>
> Subject: RE: Shepherd review of draft-ietf-pce-multipath
>
> 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:
>
> - This example is not trying to use an IPv6 address
> - The example should use documentation addresses from the IPv4 space (as you
> noted above)
> - There would, ideally, be an example using IPv6 addresses (I mean, SRv6 not
> SRv4 ;-)
> - 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]
