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

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?

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.

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.

# É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.