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) <[email protected]> Date: Wednesday, 8 October 2025 at 20:32 To: Gunter Van de Velde <[email protected]>, The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> 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 <[email protected]> Date: Tuesday, 7 October 2025 at 12:01 To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> 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
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
