PS
RBNF seems not quite correct?
<intended-path> ::= [<PATH-ATTRIB>]<ERO>
[<intended-path>]
This would allow you to send:
<intended-path>=<ERO1><ERO2><ERO3>
Which is not correct, you need to separate them with <PATH-ATTRIB>:
<intended-path>=<PATH-ATTRIB1><ERO1><PATH-ATTRIB2><ERO2><PATH-ATTRIB3><ERO3>
The previous RBNF that I had:
<intended-path> ::= (<ERO>|
(<PATH-ATTRIB><ERO>) [<intended-path>])
Seems more correct, because it's saying that you either send a single <ERO>
object, or you have to prepend <PATH-ATTRIB> if you send multiple <ERO> objects.
Thanks,
Mike.
On Sunday, March 1st, 2026 at 7:23 AM, Mike Koldychev
<[email protected]> wrote:
> 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]
