Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP)
draft-ietf-pce-sid-algo-29

[Ballot comment]
# 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/

# All comments were addressed and answered https://mailarchive.ietf.org/arch/msg/pce/DdEUUopiVdlybs58uKhjq9lBlPs/

Thank you for the swift and smooth follow up.

[Ballot comment]
Thank you for the secdir review by Alexey Melnikov.

Section 9:  RFC 8253 is outdated because of the publication of TLS1.3 (RFC8446). Consider listing BCP 195 vice RFC 9325 to ensure the most recent guidance for the implementation of TLS.

[Ballot comment]
Thanks for the work done in this document and for addressing my previous blocking DISCUSS
(https://mailarchive.ietf.org/arch/msg/pce/ayCXnZU4FrhAm9yPH-AbJ3qilYw/ )

The COMMENTS below are non blocking but should be considered though.

## COMMENTS (non-blocking)


### Sections 4.1.1 and 4.1.2

Strongly suggest to add the position of the S flag rather than waiting to reach the IANA considerations section.

### Section 4.2.1

Please add an informative URI reference to the IANA registry.

### Sections 6.2 and 6.4

When can the "SHOULD" be bypassed ? or what are the consequences of doing so.

### Update references

As indicated by idnits, several I-Ds are now RFC (e.g., RFC 9843) even before the submission date of this I-D, so refresh these references.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-pce-sid-algo-25
CC @evyncke

Thank you for the work put into this document. Most of it was beyond my technical knowledge of PCE/SR though.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Dhruv Dhody for the shepherd's write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 4.2.1

Trivial to fix: `Future extensions SHOULD first re-use the Reserved portion` is ambiguous as there is no Reserved field in the "block" only "Unassigned". Suggest using the term "reserved" rather than "unassigned" and being consistent.

[Ballot comment]

## COMMENTS (non-blocking)


### Sections 4.1.1 and 4.1.2

Strongly suggest to add the position of the S flag rather than waiting to reach the IANA considerations section.

### Section 4.2.1

Please add an informative URI reference to the IANA registry.

### Sections 6.2 and 6.4

When can the "SHOULD" be bypassed ? or what are the consequences of doing so.

### Update references

As indicated by idnits, several I-Ds are now RFC (e.g., RFC 9843) even before the submission date of this I-D, so refresh these references.

[Ballot 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/

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?

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

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?

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?

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.

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)

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?

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

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)

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
GV> Is there anything that must be assumed if the flag was set to '0'?

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?

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?

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

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.

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

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"?

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?

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?

473   Future documents extending the Subobject Extension Block MUST:

GV> i suspect that it is not Documents, but Future "enhancements" extending....

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?

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.

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.

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?

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/

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?

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.

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'?

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/


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/

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?

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

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?

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.

596   document specifies new types for the METRIC object to enable the

GV> s/new types/additional types/

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)

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?

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

1223       |            |          | TBD4:Unsupported combination of    |
1224       |            |          | constraints 

GV> [DISCUSS#4] is this missing some entries as Error-type and meaning?

Kind Regards,
Gunter Van de Velde
RTG Area Director

[Ballot comment]
Thanks for a well-sourced terminology section. Many of these terms are abbreviations, and I would encourage you to include the expanded term here (with the abbreviation in parentheses) alongside the reference to the RFC that defines them. Also consider moving FAD and the RFC9050 reference to the top with the same format as the other RFCs where terms are imported. I also noted the terms "headend router" and "RRO" used in the document without definitions here.

There appear to be too many words here:

415   *  If no SEBF (including A flag defined in this document) is set, the
416       Length value MUST match the requirements as defined in
417       Section 5.2.1 of [RFC8664] applies.

I think this should be either "MUST follow the requirements defined in Section 5.2.1 of [RFC8664]." or "If no SEBF (...) is set, the requirements in Section 5.2.1 of [RFC8664] apply."

Throughout the document, the following sets of terms are used inconsistently. Please pick one for each and use it throughout.
- 'A flag', 'the A flag', 'the A-flag', 'the A bit', '"A" flag'
- "Subobject Extension Block", "the Subobject Extension Block"
- "IEEE floating-point format", "floating point format" "IEEE floating point"
- "Flexible Algorithm", "Flex-algo", "Flex-Algorithm"

In 4.2.1 and 4.2.2, normative requirements are placed on future extensions. That doesn't really affect implementers of this specification, and they can't be enforced on those future drafts. Instead, reframe this as guidance to those future draft authors and/or as affirmative statements about what can be done in the future. If there is behavior required now to enable those future extensions (e.g. "if an SEBF is set that you don't understand, fail"), normative requirements for those would be appropriate here.

In Sections 4.5.2 and 4.5.3, please include the appropriate reference to the definition of the floating point format (as you did in 4.5.1) or consider making this a definition used in the Terminology section.

The reference to "Section 5.1, Section 5.1.2, and Section 5.2" is awkward, especially as 5.1.2 is within 5.1. Consider making this "Sections 5.1 and 5.2" or simply "defined in this document" / "defined in this section". Are there multiple extensions here, or a single extension that involves multiple new elements?

In Section 5.2.2, should "The PCE must optimize" be "The PCE MUST optimize" or "The PCE optimizes"?

===NITS FOLLOW===
Section 3, "the mechanisms" => "mechanisms"
Section 5.2, "different SR-Algorithm constraint" => "different SR-Algorithm constraints" or "a different SR-Algorithm constraint"; "use empty ERO" => "use an empty ERO"?
Section 5.2.2, "introduced IANA registry" => "created an IANA registry"
Section 5.3, "new metric types defined in this document." => "the new metric types defined in this document." or simply "the metric types defined in this document."
Section 6, "to PCEP extensions defined in this document" => "to the PCEP extensions defined in this document" and similar throughout the section
Section 6.2, "for PCEP peer" => "for the PCEP peer"
Section 6.2, several of these section references would ideally be cross-references rather than bare section numbers

[Ballot comment]
"Abstract", paragraph 3
>    This document specifies extensions to the Path Computation Element
>    Communication Protocol (PCEP) to enhance support for Segment Routing
>    (SR) with a focus on the use of Segment Identifiers (SIDs) and SR-
>    Algorithms in Traffic Engineering (TE).  The SR-Algorithm associated
>    with a SID defines the path computation algorithm used by Interior
>    Gateway Protocols (IGPs).  This document introduces extensions in
>    three main areas.
>
>    Mechanisms for informing PCEP peers about the SR-Algorithm associated
>    with SIDs by encoding this information in Explicit Route Object (ERO)
>    and Record Route Object (RRO) subobjects.  This document updates RFC
>    8664 and RFC 9603 to allow such extension.
>
>    The document specifies SR-Algorithm constraint, enabling refined path
>    computations that can leverage IGP algorithm logic, including
>    Flexible Algorithms, and their associated constraints and
>    optimization metrics.
>
>    It defines new metric types for the METRIC object required to support
>    SR-Algorithm based path computation, but also applicable to Label
>    Switched Paths (LSPs) setup using different Path Setup Types.

The Abstract is long and most of the text is duplicated in Introduction. Suggest shortening the Abstract to the first paragraph and removing the last statement, and deferring the rest of the details to the Introduction Section as has already been done.

Section 4.4, paragraph 9
>      *  S (Strict): If set, the path computation at the PCE MUST fail
>          if the specified SR-Algorithm constraint cannot be satisfied.
>          If unset, the PCE MUST try to compute the path with SR-
>          algorithm constraint specified.  If the path computation using
>          the specified SR-Algorithm constraint fails, the PCE MUST try
>          to compute a path that does not satisfy the constraint.

In general, I support Gunter's DISCUSS. This section and this paragraph in particular was cited by OPSDIR review done by Nagendra (thanks Nagendra).

Section 6, paragraph 0
>    All manageability requirements and considerations listed in
>    [RFC5440], [RFC8231], [RFC8281], [RFC8664] and [RFC9603] apply to
>    PCEP extensions defined in this document.  In addition, the
>    requirements and considerations listed in this section apply.

Thanks for adding a section of manageability and for identifying additional parameters that need to be defined in the YANG model. In there a plan to update that model?

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document references draft-ietf-lsr-flex-algo-bw-con, but that has been
published as RFC9843.

Document references draft-ietf-pce-pcep-yang, but that has been published as
RFC9826.

Section 3, paragraph 3
> implicit algorithm of BSID is independent from SR algorithm used for the SR
>                              ^^^^^^^^^^^^^^^^
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

Section 4.4, paragraph 1
> nded along the way. * A network comprises of a set of N links {Li, (i=1...N)
>                                ^^^^^^^^^^^^
Did you mean "comprises" or "consists of"?

Section 4.4, paragraph 9
> ion that observes the worst (i.e., highest value) delay metric among all dest
>                                    ^^^^^^^
A determiner may be missing.

Section 5.2, paragraph 8
> -con], a PCE implementation may need support these IGP extensions to allow u
>                                ^^^^^^^^^^^^
The verb "support" needs to be in the to-infinitive form.

Section 10.5, paragraph 1
> EPS: Usage of TLS to Provide a Secure Transport for the Path Computation Ele
>                              ^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"Secure Transport".

[Ballot discuss]
# 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.

# I have a few simple to resolve blocking DISCUSS items (easy to resolve) and a bunch of non-blocking COMMENTS for which i hope they can be considered by the author team.

# DISCUSS
# =======

# [DISCUSS#1]
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> The above seems to instruct procedure in normative language for a dedicated SEBF in the flags field similar to the A-Flag, but it does not define that specific entity. How to make sure it is interoperable? Can the exact procedure be defined in this specification to make these future flags interoperable, by mentioning the register etc?

# [DISCUSS#2]

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> "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.

# [DISCUSS#4]

691   The conversion from 24-bit integer to 32-bit IEEE floating point
692   could introduce some loss of precision.

GV> Suddenly there is discussion on 24 and 32 bits in a formal encoding procedure section. Where do these vaklues come from? Can this be clarified? is there risk for interop issues?

1223       |            |          | TBD4:Unsupported combination of    |
1224       |            |          | constraints 

GV> The above copy/paste is found in the IANA section. I get suspicion that this is missing some fields a=or explanation why the first columns are left empty?

[Ballot comment]
# 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/

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?

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

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?

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?

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.

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)

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?

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

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)

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
GV> Is there anything that must be assumed if the flag was set to '0'?

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?

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?

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

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.

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

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"?

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?

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?

473   Future documents extending the Subobject Extension Block MUST:

GV> i suspect that it is not Documents, but Future "enhancements" extending....

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?

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.

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.

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?

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/

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?

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.

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'?

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/


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/

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?

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

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?

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.

596   document specifies new types for the METRIC object to enable the

GV> s/new types/additional types/

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)

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?

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

1223       |            |          | TBD4:Unsupported combination of    |
1224       |            |          | constraints 

GV> [DISCUSS#4] is this missing some entries as Error-type and meaning?

Kind Regards,
Gunter Van de Velde
RTG Area Director

[Ballot discuss]
# 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 usefull extension and is a timely technology extension.

# a general commnent i have is that when teh 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.

# I have a few simple to resolve blocking DISCUSS items (easy to resolve) and a bunch of non-blocking COMMENTS for whih i hope they can be considered by the author team.

# DISCUSS
# =======

# [DISCUSS#1]
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> The above seems to instruct procedure in normative language for a dedicated SEBF in the flags field similar to the A-Flag, but it does not define that specific entitity. How to make sure it is interoperable? Can the exact procedure be defined in this specification to make these future flags interoprable, by mentioning the register etc?

# [DISCUSS#2]

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> "does not satisfy the constraint". Does this allow to use any other algiorithm 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 underspecification , as different devices may use different approach causing unpredictable behavior and potential interop complexities.

# [DISCUSS#4]

691   The conversion from 24-bit integer to 32-bit IEEE floating point
692   could introduce some loss of precision.

GV> Suddenly there is discussion on 24 and 32 bits in a formal encoding procedure section. Where do these vaklues come from? Can this be clarified? is there risk for interop issues?

1223       |            |          | TBD4:Unsupported combination of    |
1224       |            |          | constraints 

GV> The above copy/paste is found in the IANA section. I get suspcion that this is misisng some fields a=or explanation why the first columns are left empty?

[Ballot comment]
# 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/

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 signalling 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 phraze?

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

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?

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 suboject is used and Subobject. Not sure if that is the intent or if it should be consistent through the document?

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.

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)

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 inheritince in any way? is that correct understanding?

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

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)

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
GV> Is there anything that must be assumed iof the flag was set to '0'?

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?

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 flegs defined in the future?

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

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 explicite intent of TLVs to allow extentions 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.

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 teh futire it will update this rfc-to-be anyway

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"?

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 entitity. How to make sure it is interoperable? Can the exact procedure be defined in this specification?

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?

473   Future documents extending the Subobject Extension Block MUST:

GV> i suspect that it is not Documents, but Future "enhancements" extending....

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 understabnding 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 indiate the a specific extension ? anything else?

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.

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.

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?

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/

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?

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.

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'?

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/


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/

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?

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

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?

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 algiorithm 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 underspecification , as different devices may use different approach causing unpredictable behavior and potential interop complexities.

596   document specifies new types for the METRIC object to enable the

GV> s/new types/additional types/

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, but nailing it doen in text better error proof)

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?

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

1223       |            |          | TBD4:Unsupported combination of    |
1224       |            |          | constraints 

GV> [DISCUSS#4] is this missing some entries as Error-type and meaning?

Kind Regards,
Gunter Van de Velde
RTG Area Director

[Ballot comment]
Hi Samuel, Zoey, Shaofu, Shuping, and Andrew,

Thank you for the effort put into this well-written and clear specification.

Thanks to Nagendra Nainar for the OPSDIR and to the authors for considering these in -14.

I only have minor comments:

# Unassigend vs. Reserved

I suggest to make this change (and also in the figure and similar uses in the spec):

OLD:
  Reserved (24 bits): This field is reserved for future use and MUST be
  set to zero when sending and ignored when receiving, unless redefined
  by a future extension that is indicated by an associated SEBF and
  capability.

NEW:
  Unassigned (24 bits): This field is reserved for future use and MUST be
  set to zero when sending and ignored when receiving, unless redefined
  by a future extension that is indicated by an associated SEBF and
  capability.

to be consistent with the definitions provided in RFC8126:

      Unassigned:  Not currently assigned, and available for assignment
            via documented procedures.  While it's generally clear that
            any values that are not registered are unassigned and
            available for assignment, it is sometimes useful to
            explicitly specify that situation.  Note that this is
            distinctly different from "Reserved".

      Reserved:  Not assigned and not available for assignment.
            Reserved values are held for special uses, such as to extend
            the namespace when it becomes exhausted.  "Reserved" is also
            sometimes used to designate values that had been assigned
            but are no longer in use, keeping them set aside as long as
            other unassigned values are available.  Note that this is
            distinctly different from "Unassigned".

# Default value

CURRENT
6.1.  Control of Function and Policy

  A PCE or PCC implementation MAY allow the capability of supporting
  PCEP extensions introduced in this document to be enabled or disabled
  as part of the global configuration.

Can we recommend a default here?

Having a default value would ensure a consistent behavior when the feature is introduced into a network.

# Inappropriate use of normative language

Section 6.4

OLD:
  An implementation SHOULD also allow the operator to view FADs, which
  MAY be used in Flexible Algorithm path computation defined in
  Section 5.2.2.

NEW:
  An implementation SHOULD also allow the operator to view FADs, which
  may be used in Flexible Algorithm path computation defined in
  Section 5.2.2.

# nits

## 1

(1)

OLD: The PCEP extensions specified in this document:

NEW: The PCEP extensions specified in this document are as follows:

(2)

CURRENT:
  Signaling SR-Algorithm in ERO and RRO:  Mechanisms are introduced for
  ..
  SR-Algorithm Constraint for Path Computation:  Mechanisms are defined
  ..
  Extensions to METRIC Object:  Several new metric types are introduced

Maybe point to the section where these mechanisms are introduced.


## 4.5.2

OLD: The Section 4 of [I-D.ietf-lsr-flex-algo-bw-con]

NEW: Section 4 of [I-D.ietf-lsr-flex-algo-bw-con]

## 4.5.3

OLD: The Section 2 of [I-D.ietf-lsr-flex-algo-bw-con]

NEW: Section 2 of [I-D.ietf-lsr-flex-algo-bw-con]


OLD: The proposed metric type range was chosen
        ^^^^^^^^

NEW: The metric type range was chosen

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pce-sid-algo-24. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are seven actions which we must complete.

First, in the SR Capability Flag Field registry in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the temporary registration for:

Bit: 5
Description: SR-Algorithm Capability

will be made permanent and its reference changed to [ RFC-to-be ].

Second, in the SRv6 Capability Flag Field registry also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

a single new registration will be made as follows:

Bit: [ TBD-at-Registration ]
Description: SR-Algorithm Capability
Reference: [ RFC-to-be ]

Third, in the SR-ERO Flag Field registry also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the temporary registration for:

Bit: 7
Description: SR-Algorithm Flag

will be made permanent and its reference changed to [ RFC-to-be ].

Fourth, in the SRv6-ERO Flag Field registry also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

Bit: [ TBD-at-Registration ]
Description: SR-Algorithm Flag (A)
Reference: [ RFC-to-be ]

Fifth, in the PCEP TLV Type Indicators registry also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the temporary registration for:

Value: 66
Description: SR-Algorithm

will be made permanent and its reference changed to [ RFC-to-be ].

Sixth, in the METRIC Object T Field registry also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the temporary registration for:

Value: 22
Description: Path Min Delay Metric

Value: 23
Description: P2MP Path Min Delay Metric

Value: 24
Description: Path Bandwidth Metric

Value: 25
Description: P2MP Path Bandwidth Metric

will be made permanent and their references changed to [ RFC-to-be ].

In addition, the definition of the range:

Value: 128-255
Description: User Defined Metric

will also be made permanent and its reference changed to [ RFC-to-be ].

Seventh, in the PCEP-ERROR Object Error Types and Values registry, also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

two new Error-Values are to be registered for Error-Type 19 as follows:

Error-Type Meaning Error-Value
19 Invalid Operation
[ TBD-at-Registration ]: Attempted use of SR-Algorithm without advertised capability
[ TBD-at-Registration ]:Unsupported combination of constraints

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-09-25):

From: The IESG
To: IETF-Announce
CC: dd@dhruvdhody.com, draft-ietf-pce-sid-algo@ietf.org, ketant.ietf@gmail.com, pce-chairs@ietf.org, pce@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP)) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Carrying SR-Algorithm in Path Computation
Element Communication
  Protocol (PCEP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-09-25. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies extensions to the Path Computation Element
  Communication Protocol (PCEP) to enhance support for Segment Routing
  (SR) with a focus on the use of Segment Identifiers (SIDs) and SR-
  Algorithms in Traffic Engineering (TE).  The SR-Algorithm associated
  with a SID defines the path computation algorithm used by Interior
  Gateway Protocols (IGPs).  This document introduces extensions in
  three main areas.

  Mechanisms for informing PCEP peers about the SR-Algorithm associated
  with SIDs by encoding this information in Explicit Route Object (ERO)
  and Record Route Object (RRO) subobjects.  This document updates RFC
  8664 and RFC 9603 to allow such extension.

  The document specifies SR-Algorithm constraint, enabling refined path
  computations that can leverage IGP algorithm logic, including
  Flexible Algorithms, and their associated constraints and
  optimization metrics.

  It defines new metric types for the METRIC object required to support
  SR-Algorithm based path computation, but also applicable to Label
  Switched Paths (LSPs) setup using different Path Setup Types.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This Shepherd Write-Up template version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG has broad consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy. The concept of 'Subobject Extension Block' was introduced late in the process, but these changes were discussed on the mailing list and reconfirmed for consensus.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)


No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The Implementation Status section notes that there are 2 known implementations at the very least.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There is no direct interaction. This I-D extends the support for IGP Flexible Algorithm (RFC 9350) from the LSR WG in PCEP. There is enough overlap between these working groups, and one of the authors of RFC 9350 provided review - https://mailarchive.ietf.org/arch/msg/pce/p64-2Y9LsZyz-7ZcjquEmgnugcU/ 

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The chair has reviewed this document. The document is clear and ready to be shipped.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard
This I-D defines a protocol extension, and thus, the standards track makes sense.
All attributes in Datatracker are set correctly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPRs. The IPR poll was conducted during the adoption and WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes. The authors/contributors list has shown their willingness to be listed. The total number of authors is 5. Earlier versions had more authors who were moved to the contributor section.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are currently no I-D nits in the document - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-19.txt

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The normative and informative references are appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Two normative references are an I-D, they are already in the RFC Editor queue.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates RFC 8664 and RFC 9603, it is captured in the metadata, abstract, and introduction. The update includes carving out the algorithm field from an earlier reserved field.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed. It has a mix of early allocations that need to be confirmed and some new allocations. The I-D does not create any new registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This Shepherd Write-Up template version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is a broad agreement in the WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)


No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The Implementation Status section notes that there are 2 known implementations at the very least.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There is no direct interaction. This I-D extends the support for IGP Flexible Algorithm (RFC 9350) from the LSR WG in PCEP. There is enough overlap between these working groups, and one of the authors of RFC 9350 provided review - https://mailarchive.ietf.org/arch/msg/pce/p64-2Y9LsZyz-7ZcjquEmgnugcU/ 

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The chair has reviewed this document. The document is clear and ready to be shipped.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard
This I-D defines a protocol extension, and thus, the standards track makes sense.
All attributes in Datatracker are set correctly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPRs. The IPR poll was conducted during the adoption and WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes. The authors/contributors list has shown their willingness to be listed. The total number of authors is 5. Earlier versions had more authors that were moved to the contributor section.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are currently no I-D nits in the document - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-19.txt

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The normative and informative references are appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

One normative reference is an I-D, it is already in the RFC Editor queue.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates RFC 8664 and RFC 9603, it is captured in the metadata, abstract, and introduction. The update includes carving out the algorithm field from an earlier reserved field.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed. It has a mix of early allocations that need to be confirmed and some new allocations. The I-D does not create any new registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This Shepherd Write-Up template version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is a broad agreement in the WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)


No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The Implementation Status section notes that there are 2 known implementations at the very least.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There is no direct interaction. This I-D extends the support for IGP Flexible Algorithm (RFC 9350) from the LSR WG in PCEP. There is enough overlap between these working groups, and one of the authors of RFC 9350 provided review - https://mailarchive.ietf.org/arch/msg/pce/p64-2Y9LsZyz-7ZcjquEmgnugcU/ 

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The chair has reviewed this document. The document is clear and ready to be shipped.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard
This I-D defines a protocol extension, and thus, the standards track makes sense.
All attributes in Datatracker are set correctly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPRs. The IPR poll was conducted during the adoption and WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes. The authors/contributors list has shown their willingness to be listed. The total number of authors is 5. Earlier versions had more authors that were moved to the contributor section.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are currently no I-D nits in the document - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-19.txt

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The normative and informative references are appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

One normative reference is an I-D, it is already in the RFC Editor queue.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates RFC 8664 and RFC 9603, it is captured in the metadata, abstract, and introduction. The update includes carving out the algorithm field from an earlier reserved field.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed. It has a mix of early allocations that need to be confirmed and some new allocations. The I-D does not create any new registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/