[Pce] Re: Gunter Van de Velde's No Objection on draft-ietf-pce-sid-algo-25: (with COMMENT)

["Samuel Sidor (ssidor)" <[e-mail]>]

Hi Gunter,

One more update with more responses included (<S>). I’ll submit changes in version 27.

Thanks a lot,
Samuel

From: Samuel Sidor (ssidor) <ssidor=[e-mail]>
Date: Wednesday, 8 October 2025 at 20:32
To: Gunter Van de Velde <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [Pce] Re: Gunter Van de Velde's No Objection on draft-ietf-pce-sid-algo-25: (with COMMENT)

Thanks a lot for your comments and for quick responses.

I updated slightly originally proposed text handling “# [DISCUSS#1]” to replace “future documents” wording based on your suggestion. Updated version (26) should be submitted now.

Please check inline responses with <S> for some of your comments. I’m still going over remaining ones and I’ll respond to rest of them as well.

Thanks,
Samuel

From: Gunter Van de Velde via Datatracker <[e-mail]>
Date: Tuesday, 7 October 2025 at 12:01
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Gunter Van de Velde's No Objection on draft-ietf-pce-sid-algo-25: (with COMMENT)

Gunter Van de Velde has entered the following ballot position for
draft-ietf-pce-sid-algo-25: No Objection

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-sid-algo/



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

# Gunter Van de Velde, RTG AD, comments for draft-ietf-pce-sid-algo-25

# 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-sid-algo-25.txt

# Many thanks for the RTGDIR review from Russ White and the shepherd writeup
from Dhruv Dhody. This draft specifies a useful extension and is a timely
technology extension.

# a general comment i have is that when the document is read in detail all in a
single go, that some parts are written in different style as some other parts.
This does not always make the document easy to digest for a reader.

# Thank you for responding and resolving the open DISCUSS observations. I am
considering the discussion resolved with the pending v26 of the draft.
https://mailarchive.ietf.org/arch/msg/pce/HK56k2rcwXNMGC-ewsW6EtPVkHI/

# comments
# ========

132        [RFC8664] and [RFC9603] specify PCEP extensions to support Segment
133        Routing (SR) over MPLS and IPv6 respectively.

GV> RFC9603 uses explicit mentioning that it is about dataplanes, hence i
suggest: s/and IPv6/and IPv6 dataplanes/

<S> Ack, updated.

143        Signaling SR-Algorithm in ERO and RRO:  Mechanisms are introduced for
144           PCEP peers to exchange information about the SR-Algorithm
145           associated with each SID.  This includes extending SR-ERO, SR-RRO
146           and SRv6-ERO, SRv6-RRO subobjects to carry an Algorithm field.
147           This document updates [RFC8664] and [RFC9603] to enable such
148           encoding.

GV> I am wondering if the wording "about the SR-Algorithm associated with each
SID" is correct here. I understand the intent. My understanding is that when we
know the SID, then the algorithm is already implicitly known by the IGP through
the segment routing extensions for both sr-mpls and srv6. What i am wondering
about is if the signaling SR-Algorithm here is not intended for NAI instead so
that the a corresponding algorithm aware SID can be associated? Maybe i missed
understanding the exact intent of this phrase?

<S>Motivation for encoding algorithm for each SID is described in Motivation section - it is supposed to be used networking monitoring or troubleshooting purposes. E.g. in case of inter-domain path computed by PCE, where PCC/headend may not be able to derive algorithm of SIDs from other IGP domains. We considered usage of NAI in the past already, but it would require duplicating existing NAI types (since existing NAI types were not easily extensible).

169     2.  Terminology

GV> This section is slightly inconsistent. Sometimes it expands acronyms and
sometimes it doesn't eventhough in both instances a reference RFC is provided

<S> Ack, aligning terms with reference provided (“FAD” and “winning FAD”) with rest of terminology section.

191        The term extension block is used in this document to identify the
192        additional bytes appended to a PCEP Object, which may exist depending
193        on the inclusion of a flag in that object

GV> Is this a specific flag for the extension block that can be called out here?

<S> This is just generic definition of “extension block”, so not pointing to specific flag. Even in case of more specific “Subobject Extension Block” inclusion may depend on multiple flags.

204        Subobject Extension Block:  Optional, variable-length extension block
205           for SR-ERO and SR-RRO subobjects defined in Section 4.2.1 of this
206           document.

GV> a search through the body of text in the draft seems to indicate that
sometimes subobject is used and Subobject. Not sure if that is the intent or if
it should be consistent through the document?

<S> It seems that even original RFC8664 which introduced SR-ERO subject is not very consistent. I’ll update to:

  *
“subobject” if used for “SR-ERO subobject” (same for SRv6 and RRO) since it seems to be used more in existing RFCs
  *
But I’ll keep “Subobject” when referring to “Subobject Extension Block"

214        Existing PCEP specifications lack the mechanisms to explicitly signal
215        and negotiate SR-Algorithm capabilities and constraints.  This limits
GV> It could be worthwhile to add the word "constraints" to the terminology
section to set the scene for what is a 'constraint' in the context of this
document.

<S> I’ll think about it, but I personally don’t think that term “constraint” is considered in different way then in other existing PCEP RFCs, where it is already used. Would it help if I add something like this to terminology?

Constraint:
A restriction or requirement that must be satisfied during path computation or signaling. Constraints may include, but are not limited to, bandwidth, topology requirements, or specific algorithms (such as an SR-Algorithm constraint that restricts path computation to a particular Segment Routing Algorithm).

To me eve that is too generic to help to reader.

235        between PCEP peers for purposes such as network monitoring and
236        troubleshooting.  In scenarios involving multiple (redundant) PCEs,
GV> redundant or resilient? I tend to look at resilient as resiliency and
redundant as useless overhead (duplicates for example)

<S> I can even drop that word completely - "multiple PCEs” should be sufficient in this context.

258           However, the implicit algorithm of BSID is independent from SR
259           algorithm used for the SR Policy associated with that BSID.
GV> Is this saying that the the SRv6 BSID has through the locator an associated
SR-Algorithm, but that when the BSID is used in an SR Policy, then that policy
SR-Algorithm overwrites such SR-Algorithm. Which means fully decoupled and no
inheritance in any way? is that correct understanding?

<S>My understanding is that when a packet is sent to a BSID, the network nodes are using the locator’s advertised algorithm to forward the packet to the headend. SR-Algorithm constraint is used for computing path for that policy, so for forwarding from headend to policy tailend. So both are decoupled and independent.

261        *  Topologies with two Interior Gateway Protocol (IGP) domains, each
262           using the same FAD but with differing algorithm numbers.
GV> This confuses me. Would this for example not be a algo 129 in topology#1
and algo 200 in topology#2? how can the PCEP SR-ALgorithm be any different for
each of these topologies. I am missing an abstraction which is implied here
with the text

<S> This is not applicable for case, when SR-Algorithm constraint is applied, but for cases, where for example explicit segment-list was specified by operator. So segment-list of policy would be:

  1.
SID1 (Algo 129) // for domain 1
  2.
SID2 (Algo 200) // for domain 2

Where FAD for both algos can be potentially even completely same.

276        *  SR-Algorithm Capability (S): If the S-flag is set, a PCEP speaker
277           indicates support for the Algorithm field and the Subobject
278           Extension Block in the SR-ERO subobject described in Section 4.2
279           and the SR-Algorithm TLV described in Section 4.4 for LSPs setup
280           using Path Setup Type 1 (Segment Routing) [RFC8664].  It does not
281           indicate support for these extensions for other Path Setup Types.
GV> What does it mean as the S-flag is not set? What behavior should PCEP
speakers assume? (similar for the SRv6 dataplane)

<S> Case of unset capability is described in processing of individual extensions - e.g. in section 5.1.1

"If the PCEP peer receives an SR-ERO subobject with the A flag set, but the S flag was not advertised in SR-PCE-CAPABILITY Sub-TLV, then it MUST consider the entire ERO as invalid as described in Section 5.2.1<https://rfc-editor.org/rfc/rfc8664#section-5.2.1> of [RFC8664<https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-25.html#RFC8664>]."

But I can still add statement like this if it will make it clear:

"If the S-flag is not set, behavior reverts to the procedures defined in existing specifications prior to the introduction of this extension."


323        *  A-flag (SR-Algorithm Flag): If set to '1' by a PCEP speaker, the
324           Subobject Extension Block MUST be included in the SR-ERO subobject
GV> Here is mentioned set to '1' while in prior section it was just mentioned
that the flag S-flag was set. Maybe align language for consistency

<S> Sure.

GV> Is there
anything that must be assumed if the flag was set to '0’?

<S>There is already “If this flag is set to 0, then either:” part describing that case.


335           -  the Subobject Extension Block is included (due to an SEBF in a
336              future document) and the Algorithm field MUST be ignored.
GV> due to Future document? not sure what this is intends to indicate?

<S> I can change to “due to an SEBF introduced in a future specifications”)
if it makes clear.

423        SEBF in the subobject's Flags field (e.g., the A-flag defined in this
424        document, or flags defined by future documents).
GV> why not simply say flags defined in the future?
<S> I think that original text is clear and readable as well, but I don’t have anything against “in the future” as well.

428        *  If the A bit is 1, and no other SEBF is set, the block Length MUST
429           be 4.
GV> A bit, A-Flag, A Flag, i assume all is the same bit? using the same name
through the document may help readers

<S> I’ll update “A-Flag” to “A Flag” and also some occurrences of “A bit”, but there will most likely some occurrences which will have to stay there, because of “bit” naming used in RFC8664, which this document is updating.

437        *  Future documents may define additional SEBFs and corresponding
438           fields, allowing the block to be increased in size beyond the
439           initial 4 bytes as needed.
GV> Is this not the explicit intent of TLVs to allow extensions to the field. I
do not feel convinced that adding this text blob contributes to the formal
procedure definition. Can this be removed? No need to make predictions about
the future or what technology will extend the field.

<S>This guidance was included because, there was no straightforward mechanism for extending the SR-ERO subobject and working group/reviewers feedback requested that the draft should define clear procedures for both current and future extensions. The referenced statement is intended to clarify how the unassigned (padding) space introduced by this draft can be reused and how further extensions should be handled if that space is insufficient. So we are not talking about TLVs in this case.

450        Unassigned (24 bits): This field is reserved for future use and MUST
451        be set to zero when sending and ignored when receiving, unless
452        redefined by a future extension that is indicated by an associated
453        SEBF and capability.
GV> The text "unless redefined by a future extension that is indicated by an
associated SEBF and capability." sounds a bit wishy washy. Can this not be
removed? If it is changed in the future it will update this rfc-to-be anyway

<S> Sure, I’ll remove it (we originally tried to minimize potential need to update the RFC).

458        Future extensions SHOULD first re-use the Reserved portion of the
GV> Why re-use? was it used before? would this not be simply 'used”?

<S> Sure, I’ll update “re-use” to “use”.

461        increments.  Each such extension MUST be indicated by a dedicated
462        SEBF in the Flags field (similar to the A-flag) and MUST be
463        accompanied by capability signaling in the appropriate capability
464        sub-TLV.
GV> [DISCUSS#1] The above seems to instruct in normative was a dedicated SEBF
in the flags field similar to the A-Flag, but it dies not define that entity.
How to make sure it is interoperable? Can the exact procedure be defined in
this specification?

<S>Responded already as part of “# [DISCUSS#1]” and the draft was updated.

466        When receiving a Subobject Extension Block longer than 4 bytes,
467        receivers that do not recognize or have not negotiated support for
468        additional flags MUST ignore the unknown additional bytes beyond
469        those defined in this document.
GV> Beyond ignoring must the receiver do something else? logging? not
forwarding?

<S>Nothing specific. This is same as any unrecognized TLVs - can be even silently ignored. Implementation can still decide to log if they are considering as helpful, but I don’t see value in mandating it.

473        Future documents extending the Subobject Extension Block MUST:
GV> i suspect that it is not Documents, but Future "enhancements" extending….
<S> Ack, updated.

475        *  Define a new SEBF in the Flags field to indicate their extension,
476           and specify corresponding capability signaling.
GV> i guess i am thrown off the rails by not understanding PCEP in the greatest
detail. The language used here says "their extension". What does that exactly
indicate? DOes that mean a new flag (assigned in the future when describing the
extension) needs to be added to indicate the a specific extension ? anything
else?
<S> Iti is just saying that if SR-ERO subobject is extended with new field, then corresponding flag in SEBF is required to indicate that new field is filled and that capability is not needed to negotiate support for such extensions.

“Define a new SEBF in the Flags field to indicate the presence of new extension, and specify the corresponding capability signaling for that extension."


482        *  The reserved bits in the initial 4 bytes are reused when possible,
483           and the block is extended only when additional space is necessary.
GV> Mentioning of reused again, Would simply saying 'used' not be more correct?
they were not used before, so there is no reuse i think.
<S>Ack, updated.

485        *  Future documents may define additional SEBFs and corresponding
486           fields, allowing the block to be increased in size beyond the
487           initial 4 bytes as needed.
GV> s/Future documents/Future extensions/ ... i think the intent is to describe
extensions and not documents.
<S>The aim was to say that other drafts/RFCs (that what we are calling documents) can define new SEBF,… but I can change to extensions as well (or specifications if that make it more formal/standard).

489        Example: Future extension introducing a Z-flag and a new Z field (8
490        bits):
GV> For clarity, will there be a reserved Z-flag in a register somewhere with a
very specific location in the flags field?
<S> This is just an example, but if Z-flag will be introduced by some future draft, then it will allocate specific position in SEBF.

508        Reserved field.  Further, a new "A" flag in defined in the existing
509        Flags field as shown in Figure 3.
GV> s/in/is/
<S>Ack, fixed.

520           |                           (128-bit)                           |
530        A new bit in the Flags field:
GV> The flag is being defined by this document, and by implicit understanding
it is new. Maybe simply remove this statement?
<S> Updated

532        A-flag (SR-Algorithm Flag): If set to '1' by a PCEP speaker, the
533        Algorithm field is included in SRv6-ERO subobject as specified in
534        Figure 3.  If this flag is set to 0, then the Algorithm field is
535        absent and processing described in Section 5.2.1 of [RFC9603]
536        applies.
GV> set to '1' and set to 0... different use of of accents. maybe use
consistent markups.
<S> Changed to “set to 1” and “set to 0”.

538        Reserved (8 bits): Reduced from 16 to 8 bits.  It MUST be set to zero
539        while sending and ignored on receipt.
GV> Why mention it is reduced? reduced from where and why? In this formal
encoding description the field length is exactly 8 bits. maybe remove the
'reduced’?
<S> Sure, dropped “Reduced from 16 to 8 bits.”

544        Note: Subobject Extension Block is applicable to SRv6-ERO Subobject,
545        but is not required by this specific document as existing reserved
546        space is re-used.  When additional space is needed in the SRv6-ERO
GV> s/document/specification/
<S> Sure (even I personally still don;’t see anything wrong even in original statement).

552        A new TLV for the LSPA Object is introduced to carry the SR-Algorithm
GV> s/A new TLV for the LSPA/The LSPA/
<S> I’m probably missing something here “The LSPA object is introduced” … does not make sense since that is existing object and we are really introducing only new TLV for that object. Was that supposed to be “The TLV is introduced …”? That would not be accurate as we want to explicitly specify for which PCEP subjects that TLV is introduced (it is not supposed to be included in other PCEP objects).

552        A new TLV for the LSPA Object is introduced to carry the SR-Algorithm
553        constraint (Section 5.2).  This TLV SHOULD only be used when PST
554        (Path Setup type) = 1 or 3 for SR-MPLS and SRv6, respectively.  Only
555        the first instance of this TLV MUST be processed, subsequent
556        instances MUST be ignored.
GV> What happens if it used for other path setups? maybe this is a MUST instead
of a SHOULD?
<S>The idea was to keep it opened for potential re-use of that TLV for other path-setup types. If there is a MUST, then if somebody will try to use it for other new PST, then they will have to update this RFC. Is that really necessary?

570        Type (16 bits): 66.
571
572        Length (16 bits): 4.
GV> These are values defined in this specification, correct? maybe call that
out explicitly instead of just displaying a numbers
<S> What would be the added value? The text is already saying that TLV is new (introduced by this document), so it must be clear that TLV type is new as well (it is listed already in IANA considerations section as well). In this case, I prefer number over having statement, which is just saying same thing in longer statement with no added value.

579        Flags (8 bits):  This document defines the following flag bits.  The
580           other bits MUST be set to zero by the sender and MUST be ignored
581           by the receiver.
GV> s/bits/bit/
GV> or is it a flag instead of a bit?
<S> Updated to just flag.

583           *  S (Strict): If set, the path computation at the PCE MUST fail
584              if the specified SR-Algorithm constraint cannot be satisfied.
585              If unset, the PCE MUST try to compute the path with SR-
586              algorithm constraint specified.  If the path computation using
587              the specified SR-Algorithm constraint fails, the PCE MUST try
588              to compute a path that does not satisfy the constraint.
GV> [DISCUSS#2] GV> "does not satisfy the constraint". Does this allow to use
any other algorithm or does this imply falling back to using algorithm 0 (the
default SPF)? If this refers to using any other Algorithm topology then i get a
hint of under specification , as different devices may use different approach
causing unpredictable behavior and potential interop complexities.
<S> Discussed already and document updated.

596        document specifies new types for the METRIC object to enable the
GV> s/new types/additional types/
<S> Updated.
614        *  A network comprises of a set of N links {Li, (i=1...N)}.
GV> What is Li, i exact (it not so complicated to deduct from the text, however
nailing it down in text seems to allow it to be more error proof)
<S> This is aligned with other RFCs defining PCEP metrics, e.g.:
https://datatracker.ietf.org/doc/html/rfc8233#section-3.1
So I prefer to keep that terminology aligned between PCEP RFCs.

691        The conversion from 24-bit integer to 32-bit IEEE floating point
692        could introduce some loss of precision.
GV> [DISCUSS#3] where is the 24 and 32 bit coming from?
<S> Already handled in updated version.

984     5.3.  New Metric types
GV> it reads odd to see new metric types. in few years they are not new
anymore. Suggest to rename this section to something that describes that it is
about metrics types being specified in this document and in the future
<S> Removed word “New”

1223          |            |           | TBD4:Unsupported combination of    |
1224          |            |           | constraints
GV> [DISCUSS#4] is this missing some entries as Error-type and meaning?
<S> Handled already.
Kind Regards,
Gunter Van de Velde
RTG Area Director