Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing
draft-ietf-pce-segment-routing-ipv6-25

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-pce-segment-routing-ipv6 and RFC 9603, changed IESG state to RFC Published)

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-pce-segment-routing-ipv6-23

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

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

Other thanks to Bob Halley, the Internet directorate reviewer (at my request):
https://datatracker.ietf.org/doc/review-ietf-pce-segment-routing-ipv6-22-intdir-telechat-halley-2024-02-24/ (Bob found no issue)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Title

The title is rather long, should it rather use "IPv6 Segment Routing"

## Abstract

Like other IESG members, I find the abstract convoluted, i.e., please be straight to the point and focus on SRv6 and PCEP, e.g., no need to mention LDP in the abstract.

## Section 1

The second paragraph is rather useless, with another mention of SR-MPLS in a SRv6 document. The 3rd paragraph is not that useful either.

4th and 5th paragraphs could be used during the WG call for adoption, but have little to do in a SRv6-related document. Please really consider to change this section.

## Section 2

Consider adding a reference to the SRH RFC.

## Section 3

Is `subobject` term well-defined ? Honestly, I never read this term before and even if I can *guess* the meaning, it may be worth adding it to the terminology section.

## Section 3.1

I have *very hard* time to understand what is meant by `When SR-MPLS is used with an IPv6 network` to be honest. I was about to ballot a blocking DISCUSS on this point, but I assume that I simply lack the PCEP context. May I ***REQUEST*** some explanations here ?

## Section 4.1.1

Is there a reason why the only defined bit in the flag field it not the rightmost one ?

Please mention the position of the N bit (bit 30 from picture but let's be crystal clear).

Is it common for PCEP communication to use the term TLV where the Length is not actually the field length ? How can a non SRv6 capable PCEP speakers will parse/skip this TLV without prior knowledge of the 4-octet alignment ?

## Section 4.3.1

No need to reply, but the encoding of TLV object is really weird again as it starts with an important flag and the length is now only 1 octet.

Isn't it weird that S&V flags indicate an absence and T flag a presence ?

Should there be a reference to the IANA registry already here ?

## Section 4.3.1.2

`The presence of each of them ` should probably be "presence or absence" cfr my comment above.

[Ballot comment]
Please find this review using a fresh pair of eyes upon the draft. feel free to use or ignore these comments.
Comments are ordered with some first set of idnit typo's, followed with observations when reading the document.

**Idnits:**

349   Endpoint node as well as the tailend node also need to be considered

I believe that the grammatically correct form is "tail-end," which refers to the final part of something, such as a process, activity, or physical object. Using a hyphen clarifies that the two words function together as a single concept. Not sure if there is earlier art that uses the term with the proposed spelling in the document?

659   PCE.  As such,the flags MUST be set to zero and a (MSD-Type,MSD-

s/such,the/such, the/

635   mechanisms, e.g routing protocols [RFC9352], then it ignores the

s/e.g/e.g./

653   SRv6 MSD capabilties, the PCC MUST send a PCErr message with Error-

s/capabilties/capabilities/

**Observations when reading through the document:**

20   Segment Routing (SR) can be used to steer packets through an IPv6 or
21   MPLS network using the source routing paradigm.  SR enables any head-
22   end node to select any path without relying on a hop-by-hop signaling
23   technique (e.g., LDP or RSVP-TE).

Proposed rewrite
Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. SR enables any head-end node to select any path without relying on hop-by-hop signaling techniques (e.g., LDP or RSVP-TE).

29   Since SR can be applied to both MPLS and IPv6 forwarding planes, a
30   PCE should be able to compute an SR Path for both MPLS and IPv6
31   forwarding planes.

I suspect we are talking dataplane instead of forwarding plane? I see the terms "forwarding plane" and "data plane" often used interchangeably, but they do seem to have nuanced differences. The forwarding plane deals with the logical decision-making process of packet forwarding, the data plane deals with the physical implementation of forwarding those packets based on those decisions. In addition the term dataplane is used later in this same abstract. Maybe best to use single terminology (maybe dataplane) through the document?

31   forwarding planes.  The PCEP extension and mechanisms to support SR-
32   MPLS have been defined.

What about adding the reference to RFC5440?

32   MPLS have been defined.  This document describes the extensions
33   required for SR support for the IPv6 data plane in the Path
34   Computation Element communication Protocol (PCEP).

This text reads a bit odd. What about a readability rewrite:
“This document outlines the necessary extensions to support Segment Routing (SR) for the IPv6 data plane within the Path Computation Element Communication Protocol (PCEP).”

126   When the SR architecture is applied to the MPLS forwarding plane, it
127   is called SR-MPLS.  When the SR architecture is applied to the IPv6
128   data plane, is is called SRv6 (Segment Routing over IPv6 data plane)
129   [RFC8754].

See earlier comments. Data plane vs forwarding plane.

133   IGP SPT.  Such paths may be chosen by a suitable network planning
134   tool, or a PCE and provisioned on the ingress node.

The correlation between PCE and suitable network planning tool is unclear. Can the following text be used to close down on the ambiguity:
“Such paths can be selected either by an appropriate network planning tool or by a Path Computation Element (PCE) and then provisioned on the ingress node.”

143   [RFC8231] specifies extensions to PCEP that allow a stateful PCE to
144   compute and recommend network paths in compliance with [RFC4657] and
145   defines objects and TLVs for MPLS-TE LSPs.  Stateful PCEP extensions

I am unclear what 'recommend' means in this context? Can this be better explained and clarified? In RFC8231 there is no mentioning of recommended paths.

157   account various constraints and objective functions.  Once a path is
158   chosen, the stateful PCE can initiate an SR-TE path on a PCC using
159   PCEP extensions specified in [RFC8281] and the SR-specific PCEP

“Once a path is chosen” seems to imply that there are multiple paths calculated and the best one is selected or chosen. Is this what is implied with this?

161   extensions for supporting a SR-TE LSP for the MPLS data plane.  This
162   document extends [RFC8664] to support SR for the IPv6 data plane.
163   Additionally, using procedures described in this document, a PCC can
164   request an SRv6 path from either a stateful or stateless PCE.  This
165   specification relies on the PATH-SETUP-TYPE TLV and procedures
166   specified in [RFC8408].

This section is explaining what this draft is standardizing. It is a bit hidden and tucked all the way in the back of the introduction, a bit less trivial for the reader to discover.

168   This specification provides a mechanism for a network controller
169   (acting as a PCE) to instantiate candidate paths for an SR Policy
170   onto a head-end node (acting as a PCC) using PCEP.  For more

Before there was mentioning of a “network planning tool”. Maybe instead the term network controller can be used?

212   Basic operations for PCEP speakers are as per [RFC8664].  SRv6 Paths
213   computed by a PCE can be represented as an ordered list of SRv6
214   segments

Reading this gives wrong indication that RFC8664 computes SRv6 paths. In the RFC8664 is explicitly written that “This document is relevant to the MPLS forwarding plane only.”

250   In SR networks, an SR source node encodes all packets being steered
251   onto an SR path with a list of segments.

“SR source node”. I am unsure what this refers towards. Would this be the segment routing ingress node? In Segment Routing (SR), the ingress node is known by the fact that it is the node where the packet enters the Segment Routing domain. When a packet enters a network that employs Segment Routing, it is typically tagged with a Segment List at the ingress node.

363   order to indicate that the path is for SRv6, any RP or SRP object

These acronyms are not specified in the terminology section: Request Parameters (RP) [RFC5440] and the Stateful PCE Request Parameters (SRP)

398   The 'L' Flag: Indicates whether the subobject represents a loose-hop
399   (see [RFC3209]).  If this flag is set to zero, a PCC MUST NOT
400   overwrite the SID value present in the SRv6-ERO subobject.
401   Otherwise, a PCC MAY expand or replace one or more SID values in the
402   received SRv6-ERO based on its local policy.

The exact meaning of L-flag is confusing for SRv6. When looking at RFC3209 it reflects upon nodes, however with SRv6 this may be an adj-SID or some other instruction. Maybe the L-flag can be enhanced to described what this means in the context of SRv6 SID.

From RFC3209:
  The path between a strict node and its preceding node MUST include
  only network nodes from the strict node and its preceding abstract
  node.

438   Flags: Used to carry additional information pertaining to the
439   SRv6-SID.  This document defines the following flag bits.  The other
440   bits MUST be set to zero by the sender and MUST be ignored by the
441   receiver.

There is mentioning of S/F/T/V. is there a reason they are called like that? I suspect I am missing the history of naming of these flags and it just looks mostly random at this stage

475   SRv6 SID: SRv6 Identifier is an 128-bit value representing the SRv6
476   segment

Any special considerations for csid?
481   At least one SRv6-SID or the NAI MUST be included in the SRv6-ERO
482   subobject, and both MAY be included.

Is there any checking or processing to check if the NAI and SRV6-SID belong to the same node? Can they belong to different nodes?

731   If a PCC receives an SRv6 path that exceeds the SRv6 MSD
732   capabilities, it MUST send a PCErr message with Error-Type = 10
733   ("Reception of an invalid object") and Error-Value = 43 ("Unsupported
734   number of SRv6-ERO subobjects") as per [RFC8664].

I assume this is about exceeding the local PCC capabilities? A local PCC router may have enough intelligence to understand the capability of all nodes through which the datapacket will be steered.  In theory the encoded payload may traverse a node that is not capable to process the SRH pushed by the SR PCC ingress router.

738   The SRv6-ERO contains a sequence of subobjects.  According to
739   [RFC9256], each SRv6-ERO subobject in the sequence identifies a
740   segment that the traffic will be directed to, in the order given.
741   That is, the first subobject identifies the first segment the traffic
742   will be directed to, the second SRv6-ERO subobject represents the
743   second segment, and so on

Is there expectation that the node of a NAI corresponds with the node owning a SRv6-SID

771   Note that this specification enables a network controller to
772   instantiate an SRv6 path in the network.  This creates an additional

Would it be more correct to indicate that it enables both to initiate and to monitor an SRv6 path?

[Ballot comment]
Thank you for a well written document. Minor nit:

Section 3.1 - 2nd Paragraph. Please review this paragraph as it seems to say that the MPLS mechanisms remain unchanged, but the text is difficult to parse. Please make the meaning clear.

[Ballot comment]
Thanks for working on this document. I am not an expert in PCEP and its related drafts, but as I understand it, this document is defining an extension for SRv6 and not SR-MPLS. Therefore, I am confused by this long paragraph in the Introduction section that delves into how SR-MPLS works. To quote:

  [RFC8231] specifies extensions to PCEP that allow a stateful PCE to
  compute and recommend network paths in compliance with [RFC4657] and
  defines objects and TLVs for MPLS-TE LSPs.  Stateful PCEP extensions
  provide synchronization of LSP state between a PCC and a PCE or
  between a pair of PCEs, delegation of LSP control, reporting of LSP
  state from a PCC to a PCE, controlling the setup and path routing of
  an LSP from a PCE to a PCC.  Stateful PCEP extensions are intended
  for an operational model in which LSPs are configured on the PCC, and
  control over them is delegated to the PCE.

If there is something this paragraph conveys applies to SRv6, it is not apparent in the next paragraph. In anything, the next paragraph on how this would work in SRv6 was clear in itself, without needing this paragraph.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pce-segment-routing-ipv6-21. If any part of this review is inaccurate, please let us know.

IANA has a question about the second and fifth actions requested in the IANA Considerations section of this document.

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

First, in the Subobject type - 20 EXPLICIT_ROUTE - Type 1 Explicit Route sub-registry of the Class Types or C-Types - 20 EXPLICIT_ROUTE registry in the Resource Reservation Protocol (RSVP) Parameters registry group located at:

https://www.iana.org/assignments/rsvp-parameters/

the temporary registration for:

Value: 40
Description: SRv6-ERO (PCEP-specific)

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

Second, the second action in Section 9.1 of the current draft refers to "REPORTED_ROUTE" in the Resource Reservation Protocol (RSVP) Parameters registry group located at:

https://www.iana.org/assignments/rsvp-parameters/

There is no REPORTED_ROUTE in the C-Types registry.

IANA Question --> IANA believes that the authors intend C-Type 21, "ROUTE_RECORD" Is this correct?

If so, in the Subobject type - 21 ROUTE_RECORD - Type 1 Explicit Route sub-registry of the Class Types or C-Types - 21 ROUTE_RECORD registry in the Resource Reservation Protocol (RSVP) Parameters registry group located at:

https://www.iana.org/assignments/rsvp-parameters/

the temporary registration for:

Value: 40
Description: SRv6-RRO (PCEP-specific)

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

Additionally, IANA would like to request for Section 9.1 to be updated to refer to "ROUTE_RECORD" instead of "REPORTED_ROUTE".

Third, a new registry will be created called the PCEP SRv6-ERO NAI Types registry. The new registry will be located in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

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

The new registry will be managed via IETF Review as defined in RFC8126.

There are initial registrations in the new registry as follows:

Value Description Reference
----- ----------- ---------
0 NAI is absent. [ RFC-to-be ]
1 Unassigned
2 NAI is an IPv6 node ID. [ RFC-to-be ]
3 Unassigned
4 NAI is an IPv6 adjacency [ RFC-to-be ]
with global IPv6 addresses
5 Unassigned
6 NAI is an IPv6 adjacency [ RFC-to-be ]
with link-local IPv6 addresses.
7-15 Unassigned

Fourth, a new registry is to be created called the SRv6-ERO Flag Field registry. The new registry will be located in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

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

The new registry will be managed via Standards Action as defined in RFC8126.

There are initial registrations in the 12-bit field as follows:

Bit Description Reference
----- ------------------ --------------
0-7 Unassigned
8 SID Verification (V) [ RFC-to-be ]
9 SID Structure is [ RFC-to-be ]
present (T)
10 NAI is absent (F) [ RFC-to-be ]
11 SID is absent (S) [ RFC-to-be ]

Fifth, in the LSP-ERROR-CODE TLV Error Code Field registry on the Path Computation Element Protocol (PCEP) Numbers registry group located at:

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

a single new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Meaning: SID Verification fails
Reference: [ RFC-to-be ]

IANA Note --> In Section 9.4 of the current draft, the authors request a value of 9 for this registration. That value is unavailable. IANA will use the next available value at the time of registration.

Sixth, in the PATH-SETUP-TYPE-CAPABILITY Sub-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: 27
Meaning: SRv6-PCE-CAPABILITY

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

Seventh, a new registry will be created called the SRv6 Capability Flag Field registry will be created in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

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

The new registry will be managed via Standards Action as defined in RFC8126. There are initial registrations in the new registry as follows:

Bit Description Reference
----- ------------------ --------------
0-13 Unassigned
14 Node or Adjacency Identifier (NAI) is supported (N)  [ RFC-to-be ]
15 Unassigned

Eighth, in the PCEP Path Setup Types 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: 3
Description: Traffic engineering path is set up using SRv6.

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

Ninth, 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/

The following temporary Error-values will be made permanent for Error-Types 10 and 19 as follows:

Error-Type Meaning
---------- -------
10 Reception of an invalid object
Error-value = 34 (Missing PCE-SRv6-CAPABILITY sub-TLV)
Error-value = 35 (Both SID and NAI are absent in SRv6-RRO subobject)
Error-value = 36 (RRO mixes SRv6-RRO subobjects with other subobject types)
Error-value = 37 (Invalid SRv6 SID Structure)

19 Invalid Operation
Error-value = 19 (Attempted SRv6 when the capability was not advertised)

The reference for each of these Error-values will be changed to [ RFC-to-be ].

Tenth, also 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/

new Error-values are to be registered for Error-Type 10 as follows:

Error-Type Meaning
---------- -------
10 Reception of an invalid object
Error-value = [ TBD-at-Registration ] (Unsupported number of SRv6-ERO subobjects)
Error-value = [ TBD-at-Registration ] (Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject)
Error-value = [ TBD-at-Registration ] (Both SID and NAI are absent in the SRv6-ERO subobject)
Error-value = [ TBD-at-Registration ] (ERO mixes SRv6-ERO subobjects with other subobject types)
Error-value = [ TBD-at-Registration ] (Unsupported number of SRv6-ERO subobjects)

IANA will set the reference of each of these four new Error-Types to [ RFC-to-be ]. IANA will use the next available values for the Error-Types at the time of registration.

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 2024-02-15):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pce-segment-routing-ipv6@ietf.org, hari@netflix.com, hariharan.ietf@gmail.com, jgs@juniper.net, pce-chairs@ietf.org, pce@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing leveraging the IPv6 dataplane) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Path Computation Element Communication
Protocol (PCEP) Extensions for
  Segment Routing leveraging the IPv6 dataplane'
  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 2024-02-15. 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


  Segment Routing (SR) can be used to steer packets through an IPv6 or
  MPLS network using the source routing paradigm.  SR enables any head-
  end node to select any path without relying on a hop-by-hop signaling
  technique (e.g., LDP or RSVP-TE).

  A Segment Routed Path can be derived from a variety of mechanisms,
  including an IGP Shortest Path Tree (SPT), explicit configuration, or
  a Path Computation Element(PCE).

  Since SR can be applied to both MPLS and IPv6 forwarding planes, a
  PCE should be able to compute an SR Path for both MPLS and IPv6
  forwarding planes.  The PCEP extension and mechanisms to support SR-
  MPLS have been defined.  This document describes the extensions
  required for SR support for the IPv6 data plane in the Path
  Computation Element communication Protocol (PCEP).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5857/
  https://datatracker.ietf.org/ipr/3441/

# Document Shepherd Write-Up for Group Documents

*This 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?
-> Concurrence of a few individuals, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
-> Not a controversy, but the earlier X bit in SRv6-PCE-CAPABILITY is deemed not useful in the later stage of the I-D. Since there were no objections to removing the X flag from the WG, and no known implementation that is setting it, it is removed in the latest version

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?
-> Yes
Have a significant number of potential implementers indicated
  plans to implement?
-> Yes
Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
-> Section 8 of this document.

## 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.
-> Links with Segment Routing (Spring WG). Spring WG has been notified. We would have welcomed more reviews from Spring but there is sufficient common participation in the WGs.

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.
-> N/A

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]?
-> N/A

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.
-> N/A

## Document Shepherd Checks

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

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?
-> N/A

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])?
-> Proposed Standard
Why is this the proper type of RFC?
-> It extends a PS protocol.
Do all Datatracker state attributes correctly reflect this intent?
-> Yes

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]?
-> Yes
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.
-> The authors were requested to respond as per the WG's IPR policy.
[https://mailarchive.ietf.org/arch/msg/pce/Pgajtvk5PMtbURBLxxDiWAe1r2Y/]

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

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.)
-> Nits corrected after review.

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

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

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

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

19. Will publication of this document change the status of any existing RFCs?
-> No
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.
-> N/A

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. All the new registry values are associated with
the appropriate reservations in IANA registries.

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.
-> N/A

[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 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?
-> Concurrence of a few individuals, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
-> Not a controversy, but the earlier X bit in SRv6-PCE-CAPABILITY is deemed not useful in the later stage of the I-D. Since there were no objections to removing the X flag from the WG, and no known implementation that is setting it, it is removed in the latest version

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?
-> Yes
Have a significant number of potential implementers indicated
  plans to implement?
-> Yes
Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
-> Section 8 of this document.

## 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.
-> Links with Segment Routing (Spring WG). Spring WG has been notified. We would have welcomed more reviews from Spring but there is sufficient common participation in the WGs.

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.
-> N/A

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]?
-> N/A

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.
-> N/A

## Document Shepherd Checks

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

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?
-> N/A

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])?
-> Proposed Standard
Why is this the proper type of RFC?
-> It extends a PS protocol.
Do all Datatracker state attributes correctly reflect this intent?
-> Yes

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]?
-> Yes
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.
-> The authors were requested to respond as per the WG's IPR policy.
[https://mailarchive.ietf.org/arch/msg/pce/Pgajtvk5PMtbURBLxxDiWAe1r2Y/]

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

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.)
-> Nits corrected after review.

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

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

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

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

19. Will publication of this document change the status of any existing RFCs?
-> No
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.
-> N/A

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. All the new registry values are associated with
the appropriate reservations in IANA registries.

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.
-> N/A

[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 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?
-> Concurrence of a few individuals, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
-> Not a controversy, but the earlier X bit in SRv6-PCE-CAPABILITY is deemed not useful in the later stage of the I-D. Since there were no objections to removing the X flag from the WG, and no known implementation that is setting it, it is removed in the latest version

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?
-> Yes
Have a significant number of potential implementers indicated
  plans to implement?
-> Yes
Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
-> Section 8 of this document.

## 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.
-> Links with Segment Routing (Spring WG). Spring WG has been notified. We would have welcomed more reviews from Spring but there is sufficient common participation in the WGs.

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.
-> N/A

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]?
-> N/A

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.
-> N/A

## Document Shepherd Checks

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

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?
-> N/A

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])?
-> Proposed Standard
Why is this the proper type of RFC?
-> It extends a PS protocol.
Do all Datatracker state attributes correctly reflect this intent?
-> Yes

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]?
-> Yes
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.
-> The authors were requested to respond as per the WG's IPR policy.
[https://mailarchive.ietf.org/arch/msg/pce/Pgajtvk5PMtbURBLxxDiWAe1r2Y/]

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

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.)
-> Nits corrected after review.

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

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

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

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

19. Will publication of this document change the status of any existing RFCs?
-> No
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.
-> N/A

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. All the new registry values are associated with
the appropriate reservations in IANA registries.

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.
-> N/A

[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 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?
-> Concurrence of a few individuals, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
-> The X bit that is proposed as part of SRv6-PCE-CAPABILITY has been deemed not useful in the later stage of the I-D. Since there were no objections to remove X flag from the WG, and there are no implementations that are using that, it is removed in the latest version.

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?
-> Yes
Have a significant number of potential implementers indicated
  plans to implement?
-> Yes
Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
-> Section 8 of this document.

## 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.
-> Links with Segment Routing (Spring WG). Spring WG has been notified. Reviews would be welcome.

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.
-> N/A

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]?
-> N/A

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.
-> N/A

## Document Shepherd Checks

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

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?
-> N/A

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])?
-> Proposed Standard
Why is this the proper type of RFC?
-> It updates a PS protocol.
Do all Datatracker state attributes correctly reflect this intent?
-> Yes

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]?
-> Yes
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.
-> The authors were requested to respond about the IPR policy.
[https://mailarchive.ietf.org/arch/msg/pce/Pgajtvk5PMtbURBLxxDiWAe1r2Y/]

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

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.)
-> Nits corrected after review.

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

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

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

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

19. Will publication of this document change the status of any existing RFCs?
-> No
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.
-> N/A

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. All the new registry values are associated with
the appropriate reservations in IANA registries.

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.
-> N/A

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