[Pce] Re: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-27: (with DISCUSS and COMMENT)

["Gunter van de Velde (Nokia)" <[e-mail]>]

I think we converged. (changed my ballot NoObjection and is no longer blocking) See GV3>


________________________________
From: Samuel Sidor (ssidor) <[e-mail]>
Sent: Thursday, June 18, 2026 2:41 PM
To: Gunter van de Velde (Nokia) <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-27: (with DISCUSS and COMMENT)


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Thanks Gunter,

Please see inline <S2>

Regards,
Samuel

From: Gunter van de Velde (Nokia) <[e-mail]>
Date: Thursday, 18 June 2026 at 14:07
To: Samuel Sidor (ssidor) <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-27: (with DISCUSS and COMMENT)

Hi Samuel,

Many thanks for sharing these thoughts.

Answering to your responses on the DISCUSS's. See GV2>


________________________________
From: Samuel Sidor (ssidor) <[e-mail]>
Sent: Thursday, June 18, 2026 12:56 PM
To: Gunter van de Velde (Nokia) <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-27: (with DISCUSS and COMMENT)


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Hi Gunter,

Thanks a lot for your review and comments. I’ll go over those but responding for now at least to DISCUSS part - please see inline <S>.

Also note that there will be version v28 submitted today, which is handling comments from other mail threads, but not yet rest of your comments (even if some of them may be handled if raised already in other reviews.

Regards,
Samuel

From: Gunter Van de Velde via Datatracker <[e-mail]>
Date: Tuesday, 16 June 2026 at 16:58
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-27: (with DISCUSS and COMMENT)

Gunter Van de Velde has entered the following ballot position for
draft-ietf-pce-multipath-27: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-multipath/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Gunter Van de Velde, RTG AD, comments for draft-ietf-pce-multipath-27

# The line numbers used are rendered from IETF idnits tool:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-multipath-27.txt

# Many thanks for this write-up. I found it well written and was an interesting
read.

# Many thanks to Cheng Li for the RTGDIR review and Adrian Farrel for the
Shepherd write-up

# in my review there are two items that i wanted to discuss more about. The
remainder are a set of comments i made when delving through the document.

# DISCUSS
# =======

# [DISCUSS#1] The document mentions the word Link, but is not providing details
if this is referencing a L3 or L2 path, as segment routing could have Adj SIDs
associated with either one of these, or a single port may have multiple L2
channels to a single remote system. Does then Link apply to the L3 port or the
L2 channels?

<S> The document is saying that path in forward and reverse direction is supposed to use same link from PCE topology. Whether it is L2 or L3 is not important (depends on topology view on PCE), it is out of scope of this draft same way like it was out of scope of RFC8800, which defined link diversity path-computation constraint for example.

GV2> This answer works for me it this is more explicitly clarified within the document to avoid others from reading to have similar confusion. I trust your experience to weave this aspect in the document at the most convenient location.

<S2> Agreed. Is following text good enough? Note that I’m explicitly trying to do not go into details about L2/L3 and just specifying that it depends on topology view and it must be consistent in both (forward and reverse) directions.

The terms "link" and "node" used by the N-flag and L-flag refer to the
links and nodes as represented in the topology that the PCE uses for path
computation. The exact nature of a link is determined by the PCE's
topology view and is out of scope of this document. The same notion of
"link" and "node" MUST be used consistently for both the forward and the
opposite-direction path when evaluating co-routing; a path and its
opposite-direction path are represented in the same topology view.

GV3> works for me.

# [DISCUSS#2] The QoS in Per-FLow Candidate Path does not seem to consider SRv6
QoS and only discusses sr-mpls traffic class. Is that intentional? The
terminology section explains that LSP used in this document is equally valid
for SRv6 paths

<S> It is intentional. This document is mostly trying to define PCEP extensions required for SR policy architecture (RFC9256). The FC field mirrors the 3-bit MPLS TC from RFC 9256 Section 8.6. TLV is prepared for future extensions using T flag with 0 value. Those can be added in the future in separate documents.

GV2> Makes sense. Could future extension potential be hinted within the document?

<S2> That’s exactly what we are intentionally trying to avoid (trying not to speculate on how SRv6 field will look like while was not concluded). Or are you just proposing to specify that specifically SRv6 QoS is out of scope as well? In such case, I can add something like:

Forwarding-class classification for non-MPLS dataplanes (e.g., SRv6) is outside the scope of this document and may be addressed by future extensions using T=0.

Would that work for you?

GV3> That works for me. Thank you.

GV2> I'll clear my DISCUSS on this document accordingly.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# COMMENTS
# ========

125        signaling of multipath information via PCEP.  Although these
126        extensions are motivated by the SR Policy use case, they are also
127        applicable to other technologies.  For SR Policy, support for

GV> Are there examples of other technologies that could be mentioned here for
clarity?

265           0                   1                   2                   3
266           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
267          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
268          |                         Flags                         |R|  O  |
269          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
277        Flags (32 bits):

GV> The diagram seems off with the length of Flags described later. I
understand that the R and '0' are part of the 32bit Flags field, it seems that
it could be misunderstood. Is there a way to make within the diagram 32 bit and
then have a 2nd diagram to visualize the flag field? it would be less confusing
to read. It would in addition allow to identify the exact bit used (R = bit 28)
and bits 29/30/31 are set to zero

300        Optional TLVs: Variable length field that can contain one or more
301        TLVs that carry additional per-path information.  The specific TLVs
302        that can be included are defined in subsequent sections of this
303        document.

GV> Would it be correct to state that optional TLVs could contain zero or more
TLVs? It are optional TLVs and as such there may be no TLV that is advertised.
This would make the description inaccurate

349        A new MULTIPATH-OPPDIR-PATH TLV is optional in the PATH-ATTRIB
350        object.  Multiple instances of the TLV are allowed in the same PATH-

GV> The field for TLVs in PATH-ATTRIB object is called 'Optional TLVs', does
that not automatically imply it is optional?

380        Flags (16 bits):

GV> same observation as earlier. In the diagram the Flags field is 14 bits
while the description talks about 16 bits

GV> It is unclear to me if the N and L flag are only indicative and are not
prescribing a mandatory behavior? If for example i set the L bit but the
Opposite Direction Path ID is not going over the same links, what happens in
that situation?

GV> Are there any considerations when the normal opposite path would follow the
setting of N and L flags, but the path is re-routed due to tactical local
policy or LFA somewhere within the network?

389        *  L (Link co-routed): If set, indicates this path is link co-routed
390           with its opposite direction path, specified in this TLV.  Two
391           opposite direction paths are link co-routed if they traverse the
392           same links (but in opposite directions).  Link co-routing implies
393           node co-routing; therefore, it is not necessary to set the N flag
394           when the L flag is set.

GV> [DISCUSS#1] The concept of 'Link' feels slightly underspecified. What does
Link exactly mean in the context of this document. Is it a fiber, a channel of
a fiber, sub-interface, port, etc... For example, what if there is one fiber
with three L2 channels to the same remote device. Does this allow L2 interfaces
within a single L3 interface

424        identified by its constituent Colors.  To achieve W-ECMP, the
425        MULTIPATH-WEIGHT TLV (Section 3.3) is included alongside the COLOR
426        TLV in each PATH-ATTRIB object.  If multiple COLOR TLVs are contained
427        in the PATH-ATTRIB object, the first one is processed and the others
428        MUST be ignored.

GV> When reading the above, i was slightly confused. does this mean that only a
single color TLV is allowed, or multiple color TLVs each pointing to a single
color? Can this be clarified? (maybe i was overthinking this section)

467        T (1 bit): MPLS TC type.  When set, indicates that the FC value is
468        derived from the MPLS Traffic Class (TC) bits as described in
469        Section 8.6 of [RFC9256].  When not set, the interpretation of the FC
470        value is reserved for future use.

GV> [DISCUSS#2] in terminology section 2 the concept of SRv6 is introduced for
LSP and mentioned that and candidate path may be an SRv6 path. In that case t
here is no MPLS TC type. Should SRv6 QoS not be considered with a flag?

472        FC (3 bits): Forwarding class value.  When the T flag is set, this
473        carries the MPLS TC-based forwarding class value as defined in
474        Section 8.6 of [RFC9256].  This value is given by the QoS classifier
475        to traffic entering the given Candidate Path.  Different classes of
476        traffic that enter the given Candidate Path can be differentially
477        steered into different Colors.  The FC field allows up to 8 different
478        forwarding classes (values 0-7).  The semantics of specific FC values
479        are significant at the headend node (PCC) that implements the SR
480        Policy and are determined by that node's local QoS policy or
481        configuration.  Coordination of FC value meanings between PCEP peers
482        (e.g., through out-of-band configuration management or operational
483        procedures) is outside the scope of this document.

GV> IPv6 has 8 bits traffic class (6 bits DS Field and 2 bits ECN). Is this
relevant for the story here?

521        Flags (16 bits):

GV> Here is documented which 'optional TLVs' (W-flag, O-flag, etc) are
supported by a PCC or PCE. Having only 16 potential functionalities supported
seems rather limited, especially with 4 of them already specified in this
document. Would signaling the supported functionalities using sub-TLVs not be
the more future proof and scalable architecture?

694        4.  The N-flag and L-flag in the MULTIPATH-OPPDIR-PATH TLV MAY be set
695            to indicate node co-routing or link co-routing respectively.
696            These flags inform the receiver about the relationship between
697            the forward and reverse paths.

GV> Is this only informational signaling? it does not mandate that the bit is
actually true or if for example, it makes the PCC believe it is for example a
link congruent opposite path, but in reality it is not.

Many thanks for this document,

Kind Regards,
Gunter Van de Velde
Routing AD