Hi Samuel,
Yes that looks correct now.
Thanks,
Mike.
On Monday, March 2nd, 2026 at 5:30 AM, Samuel Sidor (ssidor) <[email protected]>
wrote:
> Also attaching updated version (I’ll submit it later today in case of no
> further comments).
>
> Thanks a lot,
> Samuel
>
> From: Samuel Sidor (ssidor) <[email protected]>
> Date: Monday, 2 March 2026 at 11:28
> To: Mike Koldychev <[email protected]>, Mike Koldychev
> <[email protected]>, Adrian Farrel <[email protected]>
> Cc: Samuel Sidor \(ssidor\) <[email protected]>,
> [email protected] <[email protected]>,
> [email protected] <[email protected]>
> Subject: Re: [Pce] Re: Shepherd review of draft-ietf-pce-multipath
> Hi Mike,
>
> For section 4.5 - thanks for catching that. I think that original text was a
> bit unclear - that’s where confusion was coming from. Hopefully, it is clear
> now (we are again allowing Path-IDs inside single PLSP-ID only).
>
> For RBNF - even RBNF in previous version was allowing “<ERO1><ERO2><ERO3>”,
> so in reality there was no big difference, but I agree that it is not ideal.
> What about:
>
> <intended-path> ::= <ERO> |
> <PATH-ATTRIB><ERO>[<intended-path-multipath>]
>
> <intended-path-multipath> ::= <PATH-ATTRIB><ERO>
> [<intended-path-multipath>]
>
> I’m also adding explicit text at the end of that section:
>
> When multiple paths are present, each ERO MUST be preceded by a PATH-ATTRIB
> object that describes it. A single path MAY be sent as a bare ERO without
> PATH-ATTRIB
> for backward compatibility.
>
> That should make it clear.
>
> Adrian - I hope that you are fine with both changes as well.
>
> Thanks,
> Samuel
>
> From: Mike Koldychev <[email protected]>
> Date: Sunday, 1 March 2026 at 13:32
> To: Mike Koldychev <[email protected]>
> Cc: Samuel Sidor \(ssidor\) <[email protected]>,
> [email protected] <[email protected]>,
> [email protected] <[email protected]>
> Subject: Re: [Pce] Re: Shepherd review of draft-ietf-pce-multipath
> 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]
