Label Switched Path Ping for Segment Routing Path Segment Identifier with MPLS Data Plane
draft-ietf-mpls-spring-lsp-ping-path-sid-13

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-mpls-spring-lsp-ping-path-sid and RFC 9884, changed IESG state to RFC Published)

[Ballot comment]
Hi Xiao, all,

The changes made 07vs12 [1] address all my DISCUSS and COMMENTs [2].

Thank you for all your effort.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-mpls-spring-lsp-ping-path-sid-07&url2=draft-ietf-mpls-spring-lsp-ping-path-sid-13&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/mpls/f0wAu26o2B83jJLSb9xfKDANEcI/

[Ballot comment]
Thanks to the authors for addressing the comments raised previously on the v07 of this document.

I am listing below a few comments related to text that has been introduced between v07 and v10 in the idnits output of the v10 of this document. Request the authors/WG to please take a look and consider the suggestions provided.

17 Abstract

19   Segment Routing (SR) leverages source routing to steer packets
20   through an ordered list of instructions, called segments.  SR can be
21   instantiated over the MPLS data plane without the need for additional
22   signaling protocols.  Path Segment Identifiers (PSIDs) are used to

I am not sure why this sentence "SR can be instatiated ... protocols."
was added. Is it relevant to this document to be placed in the abstract?


83 1.  Introduction

85   A Path Segment is a local segment [RFC8402] that uniquely identifies
86   an SR path on the egress node.  A Path Segment Identifier (PSID) is a
87   single label that is assigned from the Segment Routing Local Block
88   (SRLB) [RFC8402] of the egress node of an SR path.

The reference to RFC9545 when talking about Path Segment is completely
missing in this paragraph. Was the first reference meant to be RFC9545 instead
of RFC8402?


100   verify the PSID against the control plane.  Checking correct
101   operation means that an initiator can use LSP Ping to check whether a
102   PSID reached the intended node and got processed by that node
103   correctly.  Moreover, verifying a PSID against the control plane

PSID is not about getting to the correct endpoint/tailend node. That
is the property of the Node SID of that node. The PSID is about identification
of the correct context of the SR Path on that endpoint/tailend node - is it
matching the correct SL, CP, or SR Policy.


133       of an SR Policy.  Although not defined in [RFC9256], the Segment-
134       List-ID is the same identifier as that can be signalled through

s/same identifier as that can be/same identifier as the one that can be

186   These three new Target FEC Stack sub-TLVs are not expected to be
187   present in the same message.  If more than one of these sub-TLVs are

Perhaps ... These three new Target FEC Stack sub-TLVs MUST NOT be ...


211   Type (length: 2 octets)

213       The Type field identifies the sub-TLV as an SR Policy Associated
214       PSID Sub-TLV.  The value is set to (TBD1) and is to be assigned by
215       IANA.

I find this style of of putting "(length: 2 octets)" strange and don't
remember seeing this in other routing documents. Perhaps you can also say "The two
octet Type field ..." which seems more natural to me. But this is an editorial thing
so I will leave it to the authors.

233       -  A value of 1 indicates IPv4.

235       -  A value of 2 indicates IPv6.

237       -  Other values are reserved.

s/Other values are reserved/All other values are invalid and MUST NOT
be used.


321       and takes values from the IANA registry [PROTOCOL-ORIGIN].  If an
322       unregistered value is used, validation at the responder MUST fail.

s/unregistered/unsupported

[Ballot comment]
I support Ketan's DISCUSS.

The IANA review of this document seems to not have concluded yet.

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

Section 1, paragraph 2
>    Procedures for LSP Ping [RFC8029] as defined in [RFC8287] and
>    [RFC8690] are also applicable to PSID.  Concretely, LSP Ping can be
>    used to check the correct operation of a PSID and verify the PSID
>    against the control plane.  Checking correct operation means that an
>    initiator can use LSP Ping to check whether a PSID reached the
>    intended node and got processed by that node correctly.  Moreover,
>    verifying a PSID against the control plane means that the initiator
>    can use LSP Ping to verify whether a given node has the same
>    understanding whith the initiator on how the PSID was constructed by
>    the control plane.  To that end, this document specifies three new
>    Target Forwarding Equivalence Class (FEC) Stack sub-TLVs for such
>    PSID checks.

s/whith/which/

Section 7, paragraph 1
>    The authors would like to acknowledge Yao Liu and Quan Xiong for the
>    very helpful f2f discussion.

While probably ok to say in chat, please use the English language instead of f2f in this document.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-lsp-ping-path-sid-08

# 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-mpls-spring-lsp-ping-path-sid-08.txt

# many thanks for this nice useful technology write-up.

# for your convenience, please find some review COMMENTS (non-blocking however i would appreciate a follow up)

# comments
# ========

19   Path Segment is a type of Segment Routing (SR) segment, and a Path
20   Segment Identifier (PSID) is used to identify an SR path.  Path
21   Segment can be used in an SR over MPLS (SR-MPLS) data plane.  This
22   document specifies three new Target Forwarding Equivalence Class
23   (FEC) Stack sub-TLVs for PSID checks.

GV> I find the abstract to read slightly odd and overly brief.
What about the following alternative textblob:

"
Segment Routing (SR) leverages source routing to steer packets through an ordered list of instructions, called segments. SR can be instantiated over the MPLS data plane without the need for additional signaling protocols. Path Segment Identifiers (PSIDs) are used to identify and correlate bidirectional or end-to-end paths in Segment Routing networks. This document defines procedures (i.e. three new Target forwarding Equivalence Class (FEC) Stack sub-TLVs) for the use of LSP Ping to support connectivity verification and fault isolation for SR paths that include Path Segment Identifiers. The mechanisms described enable the validation and tracing of SR paths with Path SIDs in MPLS networks, complementing existing SR-MPLS OAM capabilities.
"

78   Path Segment is a type of Segment Routing (SR) segment, and a Path
79   Segment Identifier (PSID) is used to identify an SR path.  PSID in
80   MPLS-based segment routing networks is defined in [RFC9545].

GV> I think that the section here is underspecifying what is a PSID. In section 2 of https://datatracker.ietf.org/doc/rfc9545/ we see that is uniquely identifies an SR path, and maybe the definition used in this document should align closer to the definition used o RFC9545:

"
  A Path Segment is a local segment [RFC8402] that uniquely identifies
  an SR path on the egress node.  A Path Segment Identifier (PSID) is a
  single label that is assigned from the Segment Routing Local Block
  (SRLB) [RFC8402] of the egress node of an SR path.
"

82   As specified in [RFC9545], PSID is a single label inserted by the
83   ingress node of the SR path, and then processed by the egress node of
84   the SR path.  The PSID is placed within the MPLS label stack as a
85   label immediately following the last label of the SR path.  The
86   egress node MUST pop the PSID.

GV> This section seems to disregard that the single PSID may be multiple segments as seen in RFC9545 section 2. Does this procedure property break in any way the procedures within the proposal?

"
  A PSID is used to identify a segment list.  However, one PSID can be
  used to identify multiple segment lists in some use cases if needed.
"

150 3.1.  SR Policy's PSID
151
152   The format of SR Policy's PSID sub-TLV is specified as below:
153
154     0                  1                  2                  3
155     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
156   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
157   |          Type = TBD1          |            Length            |
158   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
159   | Address Type  |                  Reserved                    |
160   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
161   ~                    Headend  (4/16 octets)                    ~
162   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
163   |                      Color  (4 octets)                      |
164   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
165   ~                    Endpoint  (4/16 octets)                    ~
166   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
167
168                     Figure 1: SR Policy's PSID sub-TLV
169
170   Type
171
172       This field is set to the value (TBD1) which indicates that it's an
173       SR Policy's PSID sub-TLV.
174
175   Length
176
177       This field is set to the length of the sub-TLV in octets, not
178       including the first 4 octets.  If Headend and Endpoint fields are
179       in IPv4 address format which is 4 octets long, it MUST be set to
180       16; If Headend and Endpoint fields are in IPv6 address format
181       which is 16 octets long, it MUST be set to 40.
182
183   Address Type
184
185       This field is set to 1 when the Headend and Endpoint are both
186       IPv4.  This field is set to 2 when the Headend and Endpoint are
187       both IPv6.
188
189   Reserved
190       The Reserved field MUST be set to 0 when sent and MUST be ignored
191       on receipt.
192
193   Headend
194
195       The same as defined in Section 2.1 of [RFC9256].
196
197   Color
198
199       The same as defined in Section 2.1 of [RFC9256].
200
201   Endpoint
202
203       The same as defined in Section 2.1 of [RFC9256].

GV> What about the following alternative. slightly reworded to avoid that a diagram is normative by adding the field lengths in the description

"
3.1. SR Policy PSID Sub-TLV

The SR Policy PSID sub-TLV is defined as follows:

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Type = TBD1          |            Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Address Type  |                  Reserved                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Headend (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Color (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Endpoint (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: SR Policy PSID sub-TLV Format

Type (length: 2 octets)
The Type field is set to a value (TBD1) to indicate the SR Policy PSID sub-TLV. The value is to be assigned by IANA.

Length (length: 2 octets)
The Length field indicates the length of the sub-TLV in octets, excluding the Type and Length fields (i.e., the first 4 octets).

* If the Headend and Endpoint fields contain IPv4 addresses (4 octets each), the Length field MUST be set to 16.
* If the Headend and Endpoint fields contain IPv6 addresses (16 octets each), the Length field MUST be set to 40.

Address Type (length: 1 octet)
This field indicates the address family used in the Headend and Endpoint fields:

* A value of 1 indicates IPv4.
* A value of 2 indicates IPv6.
* Other values are reserved.

Reserved (length: 3 octets)
This field is reserved for future use. It MUST be set to zero when sent and MUST be ignored upon receipt.

Headend (length: 4 or 16 octets)
The Headend field encodes the headend address of the SR Policy. This field is defined in Section 2.1 of [RFC9256].

Color (length: 4 octets)
The Color field identifies the color (i.e., policy identifier) of the SR Policy and is encoded as defined in Section 2.1 of [RFC9256].

Endpoint (length: 4 or 16 octets)
The Endpoint field encodes the endpoint address of the SR Policy. This field is defined in Section 2.1 of [RFC9256].
"

205 3.2.  SR Candidate Path's PSID

207   The format of SR Candidate Path's PSID sub-TLV is specified as below:
208
209     0                  1                  2                  3
210     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
211   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
212   |          Type = TBD2          |            Length            |
213   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
214   | Address Type  |                  Reserved1                  |
215   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
216   ~                    Headend  (4/16 octets)                    ~
217   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
218   |                      Color  (4 octets)                      |
219   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
220   ~                    Endpoint  (4/16 octets)                    ~
221   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
222   |Protocol-Origin|                  Reserved2                  |
223   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
224   |                                                              |
225   |                                                              |
226   |                  Originator  (20 octets)                      |
227   |                                                              |
228   |                                                              |
229   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
230   |              Discriminator  (4 octets)                      |
231   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
231
233                 Figure 2: SR Candidate Path's PSID sub-TLV
234
235   Type
236       This field is set to the value (TBD2) which indicates that it's an
237       SR Candidate Path's PSID sub-TLV.
238
239   Length
240
241       This field is set to the length of the sub-TLV in octets, not
242       including the first 4 octets.  If Headend and Endpoint fields are
243       in IPv4 address format which is 4 octets long, it MUST be set to
244       44; If Headend and Endpoint fields are in IPv6 address format
245       which is 16 octets long, it MUST be set to 68.
246
247   Address Type
248
249       This field is set to 1 when the Headend and Endpoint are both
250       IPv4.  This field is set to 2 when the Headend and Endpoint are
251       both IPv6.
252
253   Reserved1
254
255       The Reserved1 field MUST be set to 0 when sent and MUST be ignored
256       on receipt.
257
258   Headend
259
260       The same as defined in Section 2.1 of [RFC9256].
260
262   Color
263
264       The same as defined in Section 2.1 of [RFC9256].
265
266   Endpoint
267
268       The same as defined in Section 2.1 of [RFC9256].
269
270   Protocol-Origin
271
272       The same as defined in Section 2.3 of [RFC9256].  This field takes
273       a value from the IANA registry defined in Section 8.4 of
274       [I-D.ietf-idr-bgp-ls-sr-policy].  If any unregistered value is
275       used for this field, the validation at the responder would fail.
276
277   Reserved2
278
279       The Reserved2 field MUST be set to 0 when sent and MUST be ignored
280       on receipt.
281
282   Originator
283       The same as defined in Section 2.4 of [RFC9256].
284
285   Discriminator
286
287       The same as defined in Section 2.5 of [RFC9256].

GV> slightly reworded and avoiding that a diagram is normative by adding the field lengths in the description

"
3.2. SR Candidate Path PSID Sub-TLV
The SR Candidate Path PSID sub-TLV is formatted as follows:

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Type = TBD2          |            Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Address Type  |                  Reserved1                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Headend (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Color (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Endpoint (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Protocol-Origin |                Reserved2                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                              |
  |                                                              |
  |                  Originator (20 octets)                      |
  |                                                              |
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Discriminator (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: SR Candidate Path PSID sub-TLV Format

Type (length: 2 octets)
The Type field identifies the sub-TLV as an SR Candidate Path PSID sub-TLV. The value is set to (TBD2) and is to be assigned by IANA.

Length (length: 2 octets)
The Length field specifies the length of the sub-TLV in octets, excluding the first 4 octets (Type and Length fields).

* When the Headend and Endpoint fields are encoded as IPv4 addresses (4 octets each), the Length MUST be set to 44.
* When these fields are encoded as IPv6 addresses (16 octets each), the Length MUST be set to 68.

Address Type (length: 1 octet)
This field indicates the address family of the Headend and Endpoint fields:

* A value of 1 indicates IPv4.
* A value of 2 indicates IPv6.
* All other values are reserved.

Reserved1 (length: 3 octets)
The Reserved1 field is reserved for future use. It MUST be set to zero when sent and MUST be ignored upon receipt.

Headend (length: 4 or 16 octets)
The Headend field encodes the address of the headend of the SR Candidate Path. This field is defined in Section 2.1 of [RFC9256].

Color (length: 4 octets)
The Color field specifies the policy color and is defined in Section 2.1 of [RFC9256].

Endpoint (length: 4 or 16 octets)
The Endpoint field encodes the address of the endpoint of the SR Candidate Path. This field is also defined in Section 2.1 of [RFC9256].

Protocol-Origin (length: 1 octet)
The Protocol-Origin field indicates the protocol that originated the SR Candidate Path. The values for this field are defined in Section 2.3 of [RFC9256] and are drawn from the IANA registry specified in Section 8.4 of [I-D.ietf-idr-bgp-ls-sr-policy]. If an unregistered value is used, validation at the responder MUST fail.

Reserved2 (length: 3 octets)
The Reserved2 field is reserved for future use. It MUST be set to zero when sent and MUST be ignored upon receipt.

Originator (length: 20 octets)
The Originator field identifies the originator of the SR Candidate Path and is encoded as defined in Section 2.4 of [RFC9256].

Discriminator (length: 4 octets)
The Discriminator field uniquely identifies the SR Candidate Path within the context of the Headend, Color, and Endpoint. This field is defined in Section 2.5 of [RFC9256].

289 3.3.  SR Segment List's PSID
290
291   The format of SR Segment List's PSID sub-TLV is specified as below:
292
293     0                  1                  2                  3
294     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
295   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
296   |          Type = TBD3          |            Length            |
297   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
298   | Address Type  |                  Reserved1                  |
299   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
300   ~                    Headend  (4/16 octets)                    ~
301   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
302   |                      Color  (4 octets)                      |
303   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
304   ~                    Endpoint  (4/16 octets)                    ~
305   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
306   |Protocol-Origin|                  Reserved2                  |
307   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
308   |                                                              |
309   |                                                              |
310   |                  Originator  (20 octets)                      |
311   |                                                              |
312   |                                                              |
313   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
314   |              Discriminator  (4 octets)                      |
315   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
316   |            Segment-List-ID  (4 octets)                      |
317   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
318
319                   Figure 3: SR Segment List's PSID sub-TLV
320
321   Type
322
323       This field is set to the value (TBD3) which indicates that it's an
324       SR Segment List's PSID sub-TLV.
325
326   Length
327       This field is set to the length of the sub-TLV in octets, not
328       including the first 4 octets.  If Headend and Endpoint fields are
329       in IPv4 address format which is 4 octets long, it MUST be set to
330       48; If Headend and Endpoint fields are in IPv6 address format
331       which is 16 octets long, it MUST be set to 72.
332
333   Address Type
334
335       This field is set to 1 when the Headend and Endpoint are both
336       IPv4.  This field is set to 2 when the Headend and Endpoint are
337       both IPv6.
338
339   Reserved1
340
341       The Reserved1 field MUST be set to 0 when sent and MUST be ignored
342       on receipt.
343
344   Headend
345
346       The same as defined in Section 2.1 of [RFC9256].
347
348   Color
349
350       The same as defined in Section 2.1 of [RFC9256].
351
352   Endpoint
353
354       The same as defined in Section 2.1 of [RFC9256].
355
356   Protocol-Origin
357
358       The same as defined in Section 2.3 of [RFC9256].  This field takes
359       a value from the IANA registry defined in Section 8.4 of
360       [I-D.ietf-idr-bgp-ls-sr-policy].  If any unregistered value is
361       used for this field, the validation at the responder would fail.
362
363   Reserved2
364
365       The Reserved2 field MUST be set to 0 when sent and MUST be ignored
366       on receipt.
367
368   Originator
369
370       The same as defined in Section 2.4 of [RFC9256].
371
372   Discriminator
376
374       The same as defined in Section 2.5 of [RFC9256].
375
376   Segment-List-ID
376
378       This field identifies an SR path within the context of a candidate
379       path of an SR Policy.  The Segment-List-ID is a 4-octet identifier
380       of a segment list.

GV> slightly reworded and avoiding that a diagram is normative by adding the field lengths in the description

"
3.3. SR Segment List PSID Sub-TLV
The SR Segment List PSID sub-TLV is used to identify a specific segment list within the context of a candidate path of an SR Policy. The format of this sub-TLV is shown in Figure 3.

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Type = TBD3          |            Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Address Type  |                  Reserved1                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Headend (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Color (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Endpoint (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Protocol-Origin |                Reserved2                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                              |
  |                                                              |
  |                  Originator (20 octets)                      |
  |                                                              |
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Discriminator (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Segment-List-ID (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: SR Segment List PSID sub-TLV Format

Type (length: 2 octets)
The Type field identifies the sub-TLV as an SR Segment List PSID sub-TLV. The value is set to (TBD3) and is to be assigned by IANA.

Length (length: 2 octets)
The Length field specifies the length of the sub-TLV in octets, excluding the first 4 octets (Type and Length).

* If the Headend and Endpoint fields are encoded as IPv4 addresses (4 octets each), the Length MUST be set to 48.
* If the Headend and Endpoint fields are encoded as IPv6 addresses (16 octets each), the Length MUST be set to 72.

Address Type (length: 1 octet)
This field indicates the IP address family used in the Headend and Endpoint fields:

* A value of 1 indicates IPv4.
* A value of 2 indicates IPv6.
* Other values are reserved.

Reserved1 (length: 3 octets)
The Reserved1 field is reserved for future use. It MUST be set to zero when transmitted and MUST be ignored upon receipt.

Headend (length: 4 or 16 octets)
The Headend field specifies the headend address of the SR Policy. This field is defined in Section 2.1 of [RFC9256].

Color (length: 4 octets)
The Color field identifies the color of the SR Policy and is encoded as specified in Section 2.1 of [RFC9256].

Endpoint (length: 4 or 16 octets)
The Endpoint field specifies the endpoint address of the SR Policy, as defined in Section 2.1 of [RFC9256].

Protocol-Origin (length: 1 octet)
The Protocol-Origin field indicates the protocol that originated the SR Candidate Path. It is defined in Section 2.3 of [RFC9256] and takes values from the IANA registry specified in Section 8.4 of [I-D.ietf-idr-bgp-ls-sr-policy]. If an unregistered value is used, validation at the responder MUST fail.

Reserved2 (length: 3 octets)
The Reserved2 field is reserved for future use. It MUST be set to zero when transmitted and MUST be ignored upon receipt.

Originator (length: 20 octets)
The Originator field identifies the originator of the SR Candidate Path and is defined in Section 2.4 of [RFC9256].

Discriminator (length: 4 octets)
The Discriminator field uniquely identifies the SR Candidate Path within the context of the Headend, Color, and Endpoint. This field is defined in Section 2.5 of [RFC9256].

Segment-List-ID (length: 4 octets)
The Segment-List-ID field is a 4-octet identifier that uniquely identifies a segment list within the context of the candidate path of an SR Policy.
"

417 4.1.  PSID FEC Validation Rules
418
419   This is an example of Segment Routing PSID validation.
420
421   Else, if the Label-stack-depth is 0 and the Target FEC Stack sub-TLV
422   FEC-stack-depth is TBD1 (SR Policy's PSID sub-TLV), {

GV> This reads slightly awkward. The validation check starts with "else". Is there something that comes ahead of this line from a validation perspective? Maybe add a bit more context where the "else" is referring towards

GV> Are there for the validation any assumptions that the policy must be installed in the dataplane and be an active construct?

Kind Regards,
Gunter Van de Velde,
Routing AD

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-lsp-ping-path-sid-08

# 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-mpls-spring-lsp-ping-path-sid-08.txt

# for your convenience, please find some COMMENTS (non-blocking but i would appreciate a follow up)

# comments
# ========

19   Path Segment is a type of Segment Routing (SR) segment, and a Path
20   Segment Identifier (PSID) is used to identify an SR path.  Path
21   Segment can be used in an SR over MPLS (SR-MPLS) data plane.  This
22   document specifies three new Target Forwarding Equivalence Class
23   (FEC) Stack sub-TLVs for PSID checks.

GV> I find the abstract to read slightly odd and overly brief.
What about the following alternative textblob:

"
Segment Routing (SR) leverages source routing to steer packets through an ordered list of instructions, called segments. SR can be instantiated over the MPLS data plane without the need for additional signaling protocols. Path Segment Identifiers (PSIDs) are used to identify and correlate bidirectional or end-to-end paths in Segment Routing networks. This document defines procedures (i.e. three new Target forwarding Equivalence Class (FEC) Stack sub-TLVs) for the use of LSP Ping to support connectivity verification and fault isolation for SR paths that include Path Segment Identifiers. The mechanisms described enable the validation and tracing of SR paths with Path SIDs in MPLS networks, complementing existing SR-MPLS OAM capabilities.
"

78   Path Segment is a type of Segment Routing (SR) segment, and a Path
79   Segment Identifier (PSID) is used to identify an SR path.  PSID in
80   MPLS-based segment routing networks is defined in [RFC9545].

GV> I think that the section here is underspecifying what is a PSID. In section 2 of https://datatracker.ietf.org/doc/rfc9545/ we see that is uniquely identifies an SR path, and maybe the definition used in this document should align closer to the definition used o RFC9545:

"
  A Path Segment is a local segment [RFC8402] that uniquely identifies
  an SR path on the egress node.  A Path Segment Identifier (PSID) is a
  single label that is assigned from the Segment Routing Local Block
  (SRLB) [RFC8402] of the egress node of an SR path.
"

82   As specified in [RFC9545], PSID is a single label inserted by the
83   ingress node of the SR path, and then processed by the egress node of
84   the SR path.  The PSID is placed within the MPLS label stack as a
85   label immediately following the last label of the SR path.  The
86   egress node MUST pop the PSID.

GV> This section seems to disregard that the single PSID may be multiple segments as seen in RFC9545 section 2. Does this procedure property break in any way the procedures within the proposal?

"
  A PSID is used to identify a segment list.  However, one PSID can be
  used to identify multiple segment lists in some use cases if needed.
"

150 3.1.  SR Policy's PSID
151
152   The format of SR Policy's PSID sub-TLV is specified as below:
153
154     0                  1                  2                  3
155     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
156   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
157   |          Type = TBD1          |            Length            |
158   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
159   | Address Type  |                  Reserved                    |
160   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
161   ~                    Headend  (4/16 octets)                    ~
162   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
163   |                      Color  (4 octets)                      |
164   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
165   ~                    Endpoint  (4/16 octets)                    ~
166   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
167
168                     Figure 1: SR Policy's PSID sub-TLV
169
170   Type
171
172       This field is set to the value (TBD1) which indicates that it's an
173       SR Policy's PSID sub-TLV.
174
175   Length
176
177       This field is set to the length of the sub-TLV in octets, not
178       including the first 4 octets.  If Headend and Endpoint fields are
179       in IPv4 address format which is 4 octets long, it MUST be set to
180       16; If Headend and Endpoint fields are in IPv6 address format
181       which is 16 octets long, it MUST be set to 40.
182
183   Address Type
184
185       This field is set to 1 when the Headend and Endpoint are both
186       IPv4.  This field is set to 2 when the Headend and Endpoint are
187       both IPv6.
188
189   Reserved
190       The Reserved field MUST be set to 0 when sent and MUST be ignored
191       on receipt.
192
193   Headend
194
195       The same as defined in Section 2.1 of [RFC9256].
196
197   Color
198
199       The same as defined in Section 2.1 of [RFC9256].
200
201   Endpoint
202
203       The same as defined in Section 2.1 of [RFC9256].

GV> What about the following alternative. slightly reworded to avoid that a diagram is normative by adding the field lengths in the description

"
3.1. SR Policy PSID Sub-TLV

The SR Policy PSID sub-TLV is defined as follows:

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Type = TBD1          |            Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Address Type  |                  Reserved                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Headend (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Color (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Endpoint (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: SR Policy PSID sub-TLV Format

Type (length: 2 octets)
The Type field is set to a value (TBD1) to indicate the SR Policy PSID sub-TLV. The value is to be assigned by IANA.

Length (length: 2 octets)
The Length field indicates the length of the sub-TLV in octets, excluding the Type and Length fields (i.e., the first 4 octets).

* If the Headend and Endpoint fields contain IPv4 addresses (4 octets each), the Length field MUST be set to 16.
* If the Headend and Endpoint fields contain IPv6 addresses (16 octets each), the Length field MUST be set to 40.

Address Type (length: 1 octet)
This field indicates the address family used in the Headend and Endpoint fields:

* A value of 1 indicates IPv4.
* A value of 2 indicates IPv6.
* Other values are reserved.

Reserved (length: 3 octets)
This field is reserved for future use. It MUST be set to zero when sent and MUST be ignored upon receipt.

Headend (length: 4 or 16 octets)
The Headend field encodes the headend address of the SR Policy. This field is defined in Section 2.1 of [RFC9256].

Color (length: 4 octets)
The Color field identifies the color (i.e., policy identifier) of the SR Policy and is encoded as defined in Section 2.1 of [RFC9256].

Endpoint (length: 4 or 16 octets)
The Endpoint field encodes the endpoint address of the SR Policy. This field is defined in Section 2.1 of [RFC9256].
"

205 3.2.  SR Candidate Path's PSID

207   The format of SR Candidate Path's PSID sub-TLV is specified as below:
208
209     0                  1                  2                  3
210     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
211   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
212   |          Type = TBD2          |            Length            |
213   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
214   | Address Type  |                  Reserved1                  |
215   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
216   ~                    Headend  (4/16 octets)                    ~
217   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
218   |                      Color  (4 octets)                      |
219   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
220   ~                    Endpoint  (4/16 octets)                    ~
221   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
222   |Protocol-Origin|                  Reserved2                  |
223   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
224   |                                                              |
225   |                                                              |
226   |                  Originator  (20 octets)                      |
227   |                                                              |
228   |                                                              |
229   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
230   |              Discriminator  (4 octets)                      |
231   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
231
233                 Figure 2: SR Candidate Path's PSID sub-TLV
234
235   Type
236       This field is set to the value (TBD2) which indicates that it's an
237       SR Candidate Path's PSID sub-TLV.
238
239   Length
240
241       This field is set to the length of the sub-TLV in octets, not
242       including the first 4 octets.  If Headend and Endpoint fields are
243       in IPv4 address format which is 4 octets long, it MUST be set to
244       44; If Headend and Endpoint fields are in IPv6 address format
245       which is 16 octets long, it MUST be set to 68.
246
247   Address Type
248
249       This field is set to 1 when the Headend and Endpoint are both
250       IPv4.  This field is set to 2 when the Headend and Endpoint are
251       both IPv6.
252
253   Reserved1
254
255       The Reserved1 field MUST be set to 0 when sent and MUST be ignored
256       on receipt.
257
258   Headend
259
260       The same as defined in Section 2.1 of [RFC9256].
260
262   Color
263
264       The same as defined in Section 2.1 of [RFC9256].
265
266   Endpoint
267
268       The same as defined in Section 2.1 of [RFC9256].
269
270   Protocol-Origin
271
272       The same as defined in Section 2.3 of [RFC9256].  This field takes
273       a value from the IANA registry defined in Section 8.4 of
274       [I-D.ietf-idr-bgp-ls-sr-policy].  If any unregistered value is
275       used for this field, the validation at the responder would fail.
276
277   Reserved2
278
279       The Reserved2 field MUST be set to 0 when sent and MUST be ignored
280       on receipt.
281
282   Originator
283       The same as defined in Section 2.4 of [RFC9256].
284
285   Discriminator
286
287       The same as defined in Section 2.5 of [RFC9256].

GV> slightly reworded and avoiding that a diagram is normative by adding the field lengths in the description

"
3.2. SR Candidate Path PSID Sub-TLV
The SR Candidate Path PSID sub-TLV is formatted as follows:

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Type = TBD2          |            Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Address Type  |                  Reserved1                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Headend (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Color (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Endpoint (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Protocol-Origin |                Reserved2                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                              |
  |                                                              |
  |                  Originator (20 octets)                      |
  |                                                              |
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Discriminator (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: SR Candidate Path PSID sub-TLV Format

Type (length: 2 octets)
The Type field identifies the sub-TLV as an SR Candidate Path PSID sub-TLV. The value is set to (TBD2) and is to be assigned by IANA.

Length (length: 2 octets)
The Length field specifies the length of the sub-TLV in octets, excluding the first 4 octets (Type and Length fields).

* When the Headend and Endpoint fields are encoded as IPv4 addresses (4 octets each), the Length MUST be set to 44.
* When these fields are encoded as IPv6 addresses (16 octets each), the Length MUST be set to 68.

Address Type (length: 1 octet)
This field indicates the address family of the Headend and Endpoint fields:

* A value of 1 indicates IPv4.
* A value of 2 indicates IPv6.
* All other values are reserved.

Reserved1 (length: 3 octets)
The Reserved1 field is reserved for future use. It MUST be set to zero when sent and MUST be ignored upon receipt.

Headend (length: 4 or 16 octets)
The Headend field encodes the address of the headend of the SR Candidate Path. This field is defined in Section 2.1 of [RFC9256].

Color (length: 4 octets)
The Color field specifies the policy color and is defined in Section 2.1 of [RFC9256].

Endpoint (length: 4 or 16 octets)
The Endpoint field encodes the address of the endpoint of the SR Candidate Path. This field is also defined in Section 2.1 of [RFC9256].

Protocol-Origin (length: 1 octet)
The Protocol-Origin field indicates the protocol that originated the SR Candidate Path. The values for this field are defined in Section 2.3 of [RFC9256] and are drawn from the IANA registry specified in Section 8.4 of [I-D.ietf-idr-bgp-ls-sr-policy]. If an unregistered value is used, validation at the responder MUST fail.

Reserved2 (length: 3 octets)
The Reserved2 field is reserved for future use. It MUST be set to zero when sent and MUST be ignored upon receipt.

Originator (length: 20 octets)
The Originator field identifies the originator of the SR Candidate Path and is encoded as defined in Section 2.4 of [RFC9256].

Discriminator (length: 4 octets)
The Discriminator field uniquely identifies the SR Candidate Path within the context of the Headend, Color, and Endpoint. This field is defined in Section 2.5 of [RFC9256].

289 3.3.  SR Segment List's PSID
290
291   The format of SR Segment List's PSID sub-TLV is specified as below:
292
293     0                  1                  2                  3
294     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
295   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
296   |          Type = TBD3          |            Length            |
297   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
298   | Address Type  |                  Reserved1                  |
299   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
300   ~                    Headend  (4/16 octets)                    ~
301   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
302   |                      Color  (4 octets)                      |
303   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
304   ~                    Endpoint  (4/16 octets)                    ~
305   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
306   |Protocol-Origin|                  Reserved2                  |
307   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
308   |                                                              |
309   |                                                              |
310   |                  Originator  (20 octets)                      |
311   |                                                              |
312   |                                                              |
313   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
314   |              Discriminator  (4 octets)                      |
315   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
316   |            Segment-List-ID  (4 octets)                      |
317   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
318
319                   Figure 3: SR Segment List's PSID sub-TLV
320
321   Type
322
323       This field is set to the value (TBD3) which indicates that it's an
324       SR Segment List's PSID sub-TLV.
325
326   Length
327       This field is set to the length of the sub-TLV in octets, not
328       including the first 4 octets.  If Headend and Endpoint fields are
329       in IPv4 address format which is 4 octets long, it MUST be set to
330       48; If Headend and Endpoint fields are in IPv6 address format
331       which is 16 octets long, it MUST be set to 72.
332
333   Address Type
334
335       This field is set to 1 when the Headend and Endpoint are both
336       IPv4.  This field is set to 2 when the Headend and Endpoint are
337       both IPv6.
338
339   Reserved1
340
341       The Reserved1 field MUST be set to 0 when sent and MUST be ignored
342       on receipt.
343
344   Headend
345
346       The same as defined in Section 2.1 of [RFC9256].
347
348   Color
349
350       The same as defined in Section 2.1 of [RFC9256].
351
352   Endpoint
353
354       The same as defined in Section 2.1 of [RFC9256].
355
356   Protocol-Origin
357
358       The same as defined in Section 2.3 of [RFC9256].  This field takes
359       a value from the IANA registry defined in Section 8.4 of
360       [I-D.ietf-idr-bgp-ls-sr-policy].  If any unregistered value is
361       used for this field, the validation at the responder would fail.
362
363   Reserved2
364
365       The Reserved2 field MUST be set to 0 when sent and MUST be ignored
366       on receipt.
367
368   Originator
369
370       The same as defined in Section 2.4 of [RFC9256].
371
372   Discriminator
376
374       The same as defined in Section 2.5 of [RFC9256].
375
376   Segment-List-ID
376
378       This field identifies an SR path within the context of a candidate
379       path of an SR Policy.  The Segment-List-ID is a 4-octet identifier
380       of a segment list.

GV> slightly reworded and avoiding that a diagram is normative by adding the field lengths in the description

"
3.3. SR Segment List PSID Sub-TLV
The SR Segment List PSID sub-TLV is used to identify a specific segment list within the context of a candidate path of an SR Policy. The format of this sub-TLV is shown in Figure 3.

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Type = TBD3          |            Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Address Type  |                  Reserved1                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Headend (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Color (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Endpoint (4 or 16 octets)                  ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Protocol-Origin |                Reserved2                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                              |
  |                                                              |
  |                  Originator (20 octets)                      |
  |                                                              |
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Discriminator (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Segment-List-ID (4 octets)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: SR Segment List PSID sub-TLV Format

Type (length: 2 octets)
The Type field identifies the sub-TLV as an SR Segment List PSID sub-TLV. The value is set to (TBD3) and is to be assigned by IANA.

Length (length: 2 octets)
The Length field specifies the length of the sub-TLV in octets, excluding the first 4 octets (Type and Length).

* If the Headend and Endpoint fields are encoded as IPv4 addresses (4 octets each), the Length MUST be set to 48.
* If the Headend and Endpoint fields are encoded as IPv6 addresses (16 octets each), the Length MUST be set to 72.

Address Type (length: 1 octet)
This field indicates the IP address family used in the Headend and Endpoint fields:

* A value of 1 indicates IPv4.
* A value of 2 indicates IPv6.
* Other values are reserved.

Reserved1 (length: 3 octets)
The Reserved1 field is reserved for future use. It MUST be set to zero when transmitted and MUST be ignored upon receipt.

Headend (length: 4 or 16 octets)
The Headend field specifies the headend address of the SR Policy. This field is defined in Section 2.1 of [RFC9256].

Color (length: 4 octets)
The Color field identifies the color of the SR Policy and is encoded as specified in Section 2.1 of [RFC9256].

Endpoint (length: 4 or 16 octets)
The Endpoint field specifies the endpoint address of the SR Policy, as defined in Section 2.1 of [RFC9256].

Protocol-Origin (length: 1 octet)
The Protocol-Origin field indicates the protocol that originated the SR Candidate Path. It is defined in Section 2.3 of [RFC9256] and takes values from the IANA registry specified in Section 8.4 of [I-D.ietf-idr-bgp-ls-sr-policy]. If an unregistered value is used, validation at the responder MUST fail.

Reserved2 (length: 3 octets)
The Reserved2 field is reserved for future use. It MUST be set to zero when transmitted and MUST be ignored upon receipt.

Originator (length: 20 octets)
The Originator field identifies the originator of the SR Candidate Path and is defined in Section 2.4 of [RFC9256].

Discriminator (length: 4 octets)
The Discriminator field uniquely identifies the SR Candidate Path within the context of the Headend, Color, and Endpoint. This field is defined in Section 2.5 of [RFC9256].

Segment-List-ID (length: 4 octets)
The Segment-List-ID field is a 4-octet identifier that uniquely identifies a segment list within the context of the candidate path of an SR Policy.
"

417 4.1.  PSID FEC Validation Rules
418
419   This is an example of Segment Routing PSID validation.
420
421   Else, if the Label-stack-depth is 0 and the Target FEC Stack sub-TLV
422   FEC-stack-depth is TBD1 (SR Policy's PSID sub-TLV), {

GV> This reads slightly awkward. The validation check starts with "else". Is there something that comes ahead of this line from a validation perspective? Maybe add a bit more context where the "else" is referring towards

GV> Are there for the validation any assumptions that the policy must be installed in the dataplane and be an active construct?

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-mpls-spring-lsp-ping-path-sid-07
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points / nits.

Special thanks to Tarek Saad for the shepherd's detailed write-up including the WG consensus _but it lacks_ the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Title

Suggest removing the acronym definition from the title.

### Section 6

Please use a normative reference to the IANA registry URI to avoid any potential ambiguity.

[Ballot comment]
# Internet AD comments for draft-ietf-mpls-spring-lsp-ping-path-sid-07
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S3

* "mutual exclusive" -> "mutually exclusive"

[Ballot discuss]
Thanks to the authors and the WG for this document.

I have a couple of points that I would like to discuss with the authors/WG as I see some lack of clarity and ambiguities in the specification.

The document is not clear about which of the 3 types of sub-TLVs
are to be used in which scenarios. For each type, please clarify where they should
be used. Is it ok to always use the per-SL type even if the same PSID is used
for all SLs (or even for all SLs for all CPs for the entire SR Policy)? Or,
should the per-SL type be used only when not all of the SLs in a CP have the
same PSID? Similar questions arise for the other two types. I hope this gives
an idea of the type of details that are required. Please also check some related
comments (in the comments section) that would provide additional context.

AFAIK there is no concept of Segment List ID that is specified in
a document from SPRING WG that can be referenced in this document for the SL
level PSID sub-TLV. Therefore, something more needs to be specified in this
document for clarity. One option would be to define the term in this document
and then informatively reference all of the following control plane protocol
specs to indicate that this ID is same as what is signaled in those protocols
when they are in use.
- draft-ietf-pce-multipath sec 5.2
- draft-ietf-idr-bgp-ls-sr-policy sec 5.7.4
- draft-ietf-idr-sr-policy-seglist-id sec 2.1

[Ballot comment]
Please also find below some comments for which I would appreciate responses/updates. These are provided inline in the idnits output of v07 of the document:

17 Abstract

19   Path Segment is a type of Segment Routing (SR) segment, and a Path
20   Segment Identifier (PSID) is used to identify an SR path.  Path

PSID is used to identify an SR path on the endpoint or tailend router.
It is not an universal identifier of an SR path. This is how it is specified
in RFC9545. Can you please clarify and correct the same here and in other
places through the document?


75 1.  Introduction

77   Path Segment is a type of Segment Routing (SR) segment, and a Path
78   Segment Identifier (PSID) is used to identify an SR path.  PSID in

The term SR Path was introduced specifically for PSID in RFC9545.
Please cover this terminology in section 2.2.


83   the SR path.  The PSID is placed within the MPLS label stack as a
84   label immediately following the last label of the SR path.  The
85   egress node MUST pop the PSID.

s/node MUST pop the PSID./node pops the PSID. ... this has been
specified normatively in RFC9545 and does not need to be re-specified in this
document.


88   Stack TLV and sub-TLV definitions for PSID.  Procedures for LSP Ping
89   [RFC8029] as defined in [RFC8287] and [RFC8690] are applicable to
90   PSID as well, which can be used to check correct operation of the
91   PSID and to verify the PSID against the control plane.  Note that LSP

It is not clear to me what specific procedures of RFC8287/8690 are
applicable/used for PSID. Can you please elaborate with pointers and
references to specific sections?


119         Sub-Type    Sub-TLV Name
120         --------    -----------------------------
121         TBD1      SR Policy's PSID
122         TBD2      SR Candidate Path's PSID
123         TBD3      SR Segment List's PSID

Please provide a table number.

125   As specified in Section 2 of [RFC9545], a PSID is used to identify a
126   segment list, some or all segment lists in a Candidate path or an SR
127   policy, so three different Target FEC Stack sub-TLVs need to be
128   defined for PSID.  When a PSID is used to identify an SR Policy, the
129   Target FEC Stack sub-TLV of the type "SR Policy's PSID" is used to
130   validate the control plane to forwarding plane synchronization for
131   this PSID; When a PSID is used to identify an SR Candidate Path, the
132   Target FEC Stack sub-TLV of the type "SR Candidate Path's PSID" is
133   used to validate the control plane to forwarding plane
134   synchronization for this PSID; When a PSID is used to identify a
135   Segment List, the Target FEC Stack sub-TLV of the type "SR Segment
136   List's PSID" is used to validate the control plane to forwarding
137   plane synchronization for this PSID.  Note that the three new Target
138   FEC Stack sub-TLVs are mutual exclusive and they wouldn't be present
139   in one message simultaneously.

There is a lot of repetition in the block above - "is used to validate
the control plane to forwarding plane ...". Please consider rephrasing and
using a bullet list for each of the 3 types. Perhaps even merge this with the
Sub-Type and Sub-TLV Name table? This is purely editorial and I leave it to
the authors.


157                     Figure 1: SR Policy's PSID sub-TLV

159   Type

161       This field is set to the value (TBD1) which indicates that it's an
162       SR Policy's PSID sub-TLV.

I support Med's discuss on this topic of disambiguating the types for
IPv4 and IPv6. Please consider doubling them so the type indicates whether the
headend and endpoints are IPv4 or IPv6 addresses. Same goes for the other two.


237   Protocol-Origin

239       The same as defined in Section 2.3 of [RFC9256].  The value of
240       this field follows the IANA registry requested in Section 8.4 of
241       [I-D.ietf-idr-bgp-ls-sr-policy].

Now that this Segment Routing registry has been created by IANA (refer
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#sr-policy-protocol-origin
) please remove the reference to the BGP-LS document and instead put a name
and URL reference to the actual IANA registry instead. Same goes for the SL
specific PSID. The BGP-LS draft is no longer a normative reference.


305   Protocol-Origin

307       The same as defined in Section 2.3 of [RFC9256].  The value of
308       this field follows the IANA registry requested in Section 8.4 of
309       [I-D.ietf-idr-bgp-ls-sr-policy].

Please add description for Reserved field, what is the value to be
set in there, and expectation on the receiver side.


329   monitoring system as described in [RFC8403].  For the PSID, the
330   responder nodes that receive echo request and send echo reply MUST be
331   the endpoint of the Segment Routing path.

s/Segment Routing path/SR path


333   When an endpoint receives the LSP echo request packet with top FEC
334   being the PSID, it MUST perform validity checks on the content of the
335   PSID FEC Stack sub-TLV.  The basic length check should be performed
336   on the received FEC.

338       SR Policy's PSID
339       ------------------
340       Length = 12 or 36 octets

342       SR Candidate Path's PSID
343       ------------------
344       Length = 40 or 64 octets

346       SR Segment List's PSID
347       ------------------
348       Length = 44 or 68 octets

This would need updated as the types are disambiguated for IPv4/IPv6


354       4a.  Segment Routing PSID Validation:

356       If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at
357       FEC-stack-depth is TBD1 (SR Policy's PSID sub-TLV), {

359       -  Set the Best-return-code to 10, "Mapping for this FEC is not
360         the given label at stack-depth " if any below conditions
361         fail (the notation  refers to the Return Subcode):

363         o  Validate that the PSID is signaled or provisioned for the SR
364             Policy {

366             +  Validate that the signaled or provisioned headend, color,
367               and endpoint, for the PSID, matches with the
368               corresponding fields in the received SR Policy's PSID
369               sub-TLV.

371             }

373         }

Please review/update this logic based on the resolution for my first
discuss point. The point here is that the context of the PSID as provisioned
on the endpoint has to match what is signaled - if there is a mismatch then an
error has to be generated. e.g., if the same PSID is assigned for all SLs of
all CPs of an SR Policy, and then a ping is received with a per SL PSID
sub-TLV then that is an error since the endpoint is not going to be aware of
any CP or SL identifiers at all. Please rememeber that normally there is no
state instantiated on the tailend of the SR Policy and PSID is a deviation -
but that deviation is limited to what is specifially needed for the PSID
itself.


461     Sub-Type  Sub-TLV Name                Reference
462     --------  -------------------------  ------------
463       TBD1      SR Policy's PSID            Section 3.1
464       TBD2      SR Candidate Path's PSID    Section 3.2
465       TBD3      SR Segment List's PSID      Section 3.3

Please add table number

Please consider renaming the sub-TLVs (as appropriate) once my first
discuss point is addressed. Perhaps, instead of SR Policy's PSID it could be
SR Policy Specific PSID? Or something like that ...

[Ballot discuss]
Hi Xiao, Shaofu, Liyan, Rakesh, and Carlos,

Thanks for the effort put into this document.

Thanks to Bing Liu for the OPSDIR and for the authors for engaging and releasing a new version. I do agree with Bing that the changes are really minimal. I do think the same concern still apply for this version and some more context/background/intended use is worth be included in the specification. I do understand that the specification extends RFC8287, which itself is based on RFC8029 so we don’t need to repeat all these details but a minimum is needed to help those who will make use of this extensions.

# DISCUSS

## Demux v4/v6

Other than that, I have an additional DISCUSS point about the procedure to demux IPv4 vs IPv6 TLVs. I suspect that we may rely on the length (although this is not said explicitly), but I’m afraid this may not be reliable. For example, a truncated TLV (for whatsoever reason) with an IPv6 address to 44 octets might be interpreted as valid TLV with IPv4. BTW, not sure if mixed forms are allowed (they shouldn’t) such as having a head as an IPv4-mapped IPv6 address and the endpoint as an IPv4 address?

Any reason why an explicit approach is not followed here (similar to the “Adj. Type” used in the IGP-Adjacency Segment ID in RFC8287) to indicate the address family of a TLV?

Can we please clarify this in the specification?

## Presence of several TLVs

CURRENT:
  Note that the three new Target
  FEC Stack sub-TLVs are mutual exclusive and they wouldn't be present
  in one message simultaneously.

How is this reflected in the validation procedure in Section 4?

BTW, you may reword as follows:

NEW1:
  These three new Target
  FEC Stack sub-TLVs are mutually exclusive (i.e., they must not be present
  in the same message).

Or simply

NEW2:
  These three new Target
  FEC Stack sub-TLVs are mutually exclusive.

[Ballot comment]
# Section 3.1

CURRENT
      This field is set to the length of the sub-TLV's Value field in

I think I understand what is meant here but there is formally no such field in the figure. Better to refer to the fields used in the Figure.

# Figure 2/Figure 3

CURRENT:
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                    Endpoint  (4/16 octets)                    ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Protocol-Origin|                    Reserved                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

…

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Protocol-Origin|                    Reserved                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

“Reserved” Field is not provided in the description. Consider adding:

NEW:
  Reserved

      The Reserved field MUST be set to 0 when sent and MUST be ignored
      on receipt.

# Section 3.2

CURRENT:
      The same as defined in Section 2.3 of [RFC9256].  The value of
      this field follows the IANA registry requested in Section 8.4 of
      [I-D.ietf-idr-bgp-ls-sr-policy].

What is the expected behavior when unregistered values are used?

BTW, may consider rewording as follows:

NEW:
      The same as defined in Section 2.3 of [RFC9256]. This field takes
      a value from the IANA registry defined in Section 8.4 of
      [I-D.ietf-idr-bgp-ls-sr-policy].

# Section 6

OLD:
    Sub-Type  Sub-TLV Name                Reference
    --------  -------------------------  ------------
      TBD1      SR Policy's PSID            Section 3.1
      TBD2      SR Candidate Path's PSID    Section 3.2
      TBD3      SR Segment List's PSID      Section 3.3

NEW:
    Sub-Type  Sub-TLV Name                Reference
    --------  -------------------------  ------------
      TBD1      SR Policy's PSID            Section 3.1 of THIS_DOCUMENT
      TBD2      SR Candidate Path's PSID    Section 3.2 of THIS_DOCUMENT
      TBD3      SR Segment List's PSID      Section 3.3 of THIS_DOCUMENT

As this will be in a public registry.

Cheers
Med

[Ballot comment]
I have read this in IESG review and I did not see transport-related concerns, so I rely on routing experts to comment upon the operation.

The following comments are therefore non-blocking, but I would appreciate their consideration when the next I-D is prepared (DONE, thanks).

(1) It would be helpful if “LSP Traceroute” was supported by a reference.

(2) The following is expressed as a note in the I-D:
  /Note that the three
  new Target FEC Stack sub-TLVs are mutual exclusive and they wouldn't
  be present in one message simultaneously./
- I am not familiar with the details of MPLS, so I ask could this be about a requirement with a “MUST” - I’d like to know what happens if a receiver sees all three present: is reception of more than one a fault, something resolved by precedence between the items? or something else?
- I’d appreciate an email to explain this to help me learn.

(3) There are a few places were the text might be improved replacing “would”:
/would follow/follows/
/ would be used to validate/is used to validate/ - three times?

[Ballot comment]
I have read this in IESG review and I did not see transport-related concerns, so I rely on routing experts to comment upon the operation.

The following comments are therefore non-blocking, but I would appreciate their consideration when the next I-D is prepared/

(1) It would be helpful if “LSP Traceroute” was supported by a reference.

(2) The following is expressed as a note in the I-D:
  /Note that the three
  new Target FEC Stack sub-TLVs are mutual exclusive and they wouldn't
  be present in one message simultaneously./
- I am not familiar with the details of MPLS, so I ask could this be about a requirement with a “MUST” - I’d like to know what happens if a receiver sees all three present: is reception of more than one a fault, something resolved by precedence between the items? or something else?
- I’d appreciate an email to explain this to help me learn.

(3) There are a few places were the text might be improved replacing “would”:
/would follow/follows/
/ would be used to validate/is used to validate/ - three times?

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mpls-spring-lsp-ping-path-sid-04. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Sub-TLVs for TLV Types 1, 16, and 21 subregistry of the TLV registry in the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry group located at:

https://www.iana.org/assignments/mpls-lsp-ping-parameters/

three new registrations are to be made as follows:

Sub-Type: [ TBD-at-Registration ]
Sub-TLV Name: SR Policy's PSID
Reference: [ RFC-to-be; Section 3.1 ]
Comment:

Sub-Type: [ TBD-at-Registration ]
Sub-TLV Name: SR Candidate Path's PSID
Reference: [ RFC-to-be; Section 3.2 ]
Comment:

Sub-Type: [ TBD-at-Registration ]
Sub-TLV Name: SR Segment List's PSID
Reference: [ RFC-to-be; Section 3.3 ]
Comment:

All three registrations will come from the 0-16383 range of the registry.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action 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-04-21):

From: The IESG
To: IETF-Announce
CC: draft-ietf-mpls-spring-lsp-ping-path-sid@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org, tsaad@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifier with MPLS Data Plane) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Label Switched Path (LSP) Ping
for Segment Routing (SR) Path Segment
  Identifier with MPLS Data Plane'
  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-04-21. 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


  Path Segment is a type of Segment Routing (SR) segment, and a Path
  Segment Identifier (PSID) is used to identify an SR path.  Path
  Segment can be used in an SR over MPLS (SR-MPLS) data plane.  This
  document provides Target Forwarding Equivalence Class (FEC) Stack TLV
  and sub-TLV definitions for PSID.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-lsp-ping-path-sid/



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

# Document Shepherd Write-Up for Group Documents

## 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?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]: During the WG LC, comments were raised by the WG about need for state for "Path Segment"
      to be present at the SR policy endpoint. A follow-up discussion has happened on the
      PCE WG mailing list (see [1] [2] [3]), and clarification text was added to the
      related PCE document.
[1] https://mailarchive.ietf.org/arch/msg/pce/wELlVSXe0si79icnxgRTdo4_yhY/
[2] https://mailarchive.ietf.org/arch/msg/pce/msIzEdXWjQ7AyTvv1OrUiYu3QXs/
[3] https://mailarchive.ietf.org/arch/msg/pce/96bgBGeTaeIix9vzFPdZULaexYU/

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.)
[Ans]: 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)?
[Ans]: No known implementations reported.

## 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.
[Ans]: Yes, the document has intersection with SPRING and PCE technologies. Bother WGs were
kept in the loop, especially when addressing comments raised during last call.

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.
[Ans]: No such formal language.

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]?
[Ans]: 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.
[Ans]: No formal language.

## 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?
[Ans]: 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?
[Ans]: An early review from the RTG-Dir was requested and completed satisfactorily.

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?
[Ans]: The intended RFC status is Proposed Standard and document reflects it in the Datatracker.

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.
[Ans]: The authors formally confirmed that they know of no IPRs related to the document
      at the time of the WG last call.

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.
[Ans]: There are five co-authors on the front page. By responding to the IPR poll, they
      have implicitly confirmed their willingness to be listed as co-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.)
[Ans]: IDnits reports:
  == Outdated reference: A later version (-20) exists of
    draft-ietf-pce-segment-routing-policy-cp-18
  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year
The document shepherd will work with authors to address those in the next revision.
No additional issues were spotted by the shepherd.

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

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: All references are to IETF material.

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.
[Ans]: No downrefs.

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?
[Ans]: Yes. The document references draft-ietf-pce-segment-routing-policy-cp which is
      undergoing WG LC now.

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.
[Ans]: No status changes made.

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]).
[Ans]: The document includes an IANA section that requests:
      assignment of three new sub-TLVs from the "Sub-TLVs for TLV Types 1, 16, and 21"
      sub-registry in the "TLVs" registry of the MPLS LSP Ping Parameters name space.

  Sub-Type  Sub-TLV Name                Reference
  --------  -------------------------  ------------
  TBD1      SR Policy's PSID            Section 3.1
  TBD2      SR Candidate Path's PSID    Section 3.2
  TBD3      SR Segment List's PSID      Section 3.3

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.
[Ans]: 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

## 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?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]: During the WG LC, comments were raised by the WG about need for state for "Path Segment"
      to be present at the SR policy endpoint. A follow-up discussion has happened on the
      PCE WG mailing list (see [1] [2] [3]), and clarification text was added to the
      related PCE document.
[1] https://mailarchive.ietf.org/arch/msg/pce/wELlVSXe0si79icnxgRTdo4_yhY/
[2] https://mailarchive.ietf.org/arch/msg/pce/msIzEdXWjQ7AyTvv1OrUiYu3QXs/
[3] https://mailarchive.ietf.org/arch/msg/pce/96bgBGeTaeIix9vzFPdZULaexYU/

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.)
[Ans]: 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)?
[Ans]: No known implementations reported.

## 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.
[Ans]: Yes, the document has intersection with SPRING and PCE technologies. Bother WGs were
kept in the loop, especially when addressing comments raised during last call.

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.
[Ans]: No such formal language.

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]?
[Ans]: 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.
[Ans]: No formal language.

## 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?
[Ans]: 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?
[Ans]: An early review from the RTG-Dir was requested and completed satisfactorily.

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?
[Ans]: The intended RFC status is Proposed Standard and document reflects it in the Datatracker.

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.
[Ans]: The authors formally confirmed that they know of no IPRs related to the document
      at the time of the WG last call.

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.
[Ans]: There are five co-authors on the front page. By responding to the IPR poll, they
      have implicitly confirmed their willingness to be listed as co-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.)
[Ans]: IDnits reports:
  == Outdated reference: A later version (-20) exists of
    draft-ietf-pce-segment-routing-policy-cp-18
  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year
The document shepherd will work with authors to address those in the next revision.
No additional issues were spotted by the shepherd.

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

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: All references are to IETF material.

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.
[Ans]: No downrefs.

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?
[Ans]: Yes. The document references draft-ietf-pce-segment-routing-policy-cp which is
      undergoing WG LC now.

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.
[Ans]: No status changes made.

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]).
[Ans]: The document includes an IANA section that requests:
      assignment of three new sub-TLVs from the "Sub-TLVs for TLV Types 1, 16, and 21"
      sub-registry in the "TLVs" registry of the MPLS LSP Ping Parameters name space.

  Sub-Type  Sub-TLV Name                Reference
  --------  -------------------------  ------------
  TBD1      SR Policy's PSID            Section 3.1
  TBD2      SR Candidate Path's PSID    Section 3.2
  TBD3      SR Segment List's PSID      Section 3.3

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.
[Ans]: 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

## 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?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]: During the WG LC, comments were raised by the WG about need for state for "Path Segment"
      to be present at the SR policy endpoint. A follow-up discussion has happened on the
      PCE WG mailing list (see [1] [2] [3]), and clarification text was added to the
      related PCE document.
[1] https://mailarchive.ietf.org/arch/msg/pce/wELlVSXe0si79icnxgRTdo4_yhY/
[2] https://mailarchive.ietf.org/arch/msg/pce/msIzEdXWjQ7AyTvv1OrUiYu3QXs/
[3] https://mailarchive.ietf.org/arch/msg/pce/96bgBGeTaeIix9vzFPdZULaexYU/

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.)
[Ans]: 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)?
[Ans]: TBD.

## 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.
[Ans]: Yes, the document has intersection with SPRING and PCE technologies. Bother WGs were
kept in the loop, especially when addressing comments raised during last call.

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.
[Ans]: No such formal language.

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]?
[Ans]: 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.
[Ans]: No formal language.

## 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?
[Ans]: 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?
[Ans]: An early review from the RTG-Dir was requested and completed satisfactorily.

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?
[Ans]: The intended RFC status is Proposed Standard and document reflects it in the Datatracker.

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.
[Ans]: The authors formally confirmed that they know of no IPRs related to the document
      at the time of the WG last call.

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.
[Ans]: There are five co-authors on the front page. By responding to the IPR poll, they
      have implicitly confirmed their willingness to be listed as co-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.)
[Ans]: IDnits reports:
  == Outdated reference: A later version (-20) exists of
    draft-ietf-pce-segment-routing-policy-cp-18
  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year
The document shepherd will work with authors to address those in the next revision.
No additional issues were spotted by the shepherd.

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

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: All references are to IETF material.

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.
[Ans]: No downrefs.

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?
[Ans]: Yes. The document references draft-ietf-pce-segment-routing-policy-cp which is
      undergoing WG LC now.

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.
[Ans]: No status changes made.

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]).
[Ans]: The document includes an IANA section that requests:
      assignment of three new sub-TLVs from the "Sub-TLVs for TLV Types 1, 16, and 21"
      sub-registry in the "TLVs" registry of the MPLS LSP Ping Parameters name space.

  Sub-Type  Sub-TLV Name                Reference
  --------  -------------------------  ------------
  TBD1      SR Policy's PSID            Section 3.1
  TBD2      SR Candidate Path's PSID    Section 3.2
  TBD3      SR Segment List's PSID      Section 3.3

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.
[Ans]: 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/