[Pce] Review of draft-ietf-pce-segment-routing-policy-cp-15 from SR Policy Arch POV

[Ketan Talaulikar <[e-mail]>]

Hello Authors/All,

I've reviewed the draft from the perspective of consistency with the SR
Policy Arch RFC9256 as well as the BGP SR Policy SAFI IDR draft. As such, I
find some issues that I think need to be addressed before publication.

Note that these may seem editorial (no change needed in PCEP signaling),
but they are semantically important for this document to convey the intent
and operations for these extensions.

My comments are embedded in the idnits format below.

Thanks,
Ketan


13 Path Computation Element Communication Protocol (PCEP) Extensions for
14              Segment Routing (SR) Policy Candidate Paths

*[major] A more appropriate title would be "PCEP Extensions for SR Policy" *
*since this is not just about CPs but support for SR Policy construct.*

15              draft-ietf-pce-segment-routing-policy-cp-15

17 Abstract

19   Segment Routing (SR) allows a node to steer a packet flow along any
20   path.  SR Policy is an ordered list of segments (i.e., instructions)
21   that represent a source-routed policy.  Packet flows are steered into
22   an SR Policy on a node where it is instantiated called a headend
23   node.  An SR Policy is made of one or more candidate paths.

25   This document specifies Path Computation Element Communication
26   Protocol (PCEP) extension to associate candidate paths of the SR
27   Policy.  Additionally, this document updates [RFC8231] to allow
28   stateful bringup of an SR LSP, without using PCReq/PCRep messages.
29   This document is applicable to both Segment Routing over MPLS and to
30   Segment Routing over IPv6 (SRv6).



*[major] This document has the specifications that actually align the
PCEPextensions (e.g. RFC8664) for SR defined prior to this document to the *
*SR Policy architecture RFC9256. This should be the most important thing to
call out and that this spec formally updates RFC8664 and *
*RFC-draft-ietf-pce-segment-routing-ipv6.*

112 1.  Introduction

114   [RFC8664] specifies extensions that allow PCEP to work with basic SR-
115   TE paths.  [RFC8697] introduces a generic mechanism to create a
116   grouping of LSPs, called an Association.  [RFC9256] introduces the SR
117   Policy construct as a grouping of SR Candidate Paths.

119   This document extends [RFC8664] to support signaling SR Policy
120   Candidate Paths and their attributes.  SR Policy is modeled in PCEP
121   as an Association, where the SR Candidate Paths are the members of
122   that Association.  Thus the PCE can take computation and control
123   decisions about the Candidate Paths, with the additional knowledge
124   that these Candidate Paths belong to the same SR Policy.





*[major] What RFC8664 did was to introduce a term called "SR Path" and
itssupport in PCEP. That term is not specified in RFC8402 and does match to
SRPolicy. So be it. It is important for the introduction to provide some
contextaround this and specify that it is this document that is introducing
thesupport for SR Policy construct in PCEP.*

126   Segment Routing Policy for Traffic Engineering [RFC9256] details the
127   concepts of SR Policy and approaches to steering traffic into an SR
128   Policy.

130   PCEP Extensions for Segment Routing [RFC8664] specifies extensions to
131   the Path Computation Element Protocol (PCEP) that allow a stateful
132   PCE to compute and initiate Traffic Engineering (TE) paths, as well
133   as a PCC to request a path subject to certain constraint(s) and
134   optimization criteria in SR networks.

136   PCEP Extensions for Establishing Relationships Between Sets of LSPs
137   [RFC8697] introduces a generic mechanism to create a grouping of LSPs
138   which can then be used to define associations between a set of LSPs
139   and a set of attributes (such as configuration parameters or
140   behaviors) and is equally applicable to stateful PCE (active and
141   passive modes) and stateless PCE.



*[major] It may be somewhat misleading to give an impression that
thepurpose for introducing the SRPA is "to create a grouping of LSPs". *


*For sure, the SRPA enables the  grouping of CPs associated with a single
SR Policy. However, SRPA is  absolutely necessary even when signaling a
single SR Policy CP as it is  indicating the Color of the SR Policy and
the identifiers of the SR Policy CP  **as per RFC9256.*

143   This document extends [RFC8664] to support signaling SR Policy
144   Candidate Paths and their attributes.  SR Policy is modeled in PCEP
145   as an Association, where the SR Candidate Paths are the members of
146   that Association.  Thus the PCE can take computation and control
147   decisions about the Candidate Paths, with the additional knowledge
148   that these Candidate Paths belong to the same SR Policy.  This is





*[minor] Not sure what this "additional knowledge" serves as the purpose
forthe PCE. Can someone please give an example? My concern here is that the
keysemantics on why the extensions in the spec are absolutely critical for
SRPolicy are being missed out for things that are of perhaps secondary
ortertiary importance.*

149   accomplished via the use of the PCEP Association object with a new
150   association type and several new TLVs.

152 2.  Terminology

154   The following terminologies are used in this document:



*[minor] suggest to introduce here all the SR Policy CP identifiers with
areference to specific sections of RFC9256. Just a reference to RFC9256
hasbeen found to be difficult for readers for other documents. This is done*
*later in the document for some sections so consistency would be good.*


156   Endpoint:  The IPv4 or IPv6 endpoint address of the SR Policy in
157      question, as described in [RFC9256].

159   SRPA:  SR Policy Association.  A new association type 'SR Policy
160      Association' is used to group candidate paths belonging to the SR
161      Policy.  Depending on discussion context, it can refer to the PCEP
162      ASSOCIATION object of SR Policy type or to a group of LSPs that
163      belong to the association.

165   Association Parameters:  As described in [RFC8697], refers to the key
166      data, that uniquely identifies the Association.

168   Association Information:  As described in [RFC8697], refers to the
169      non-key information about the Association.

171 3.  Overview












*[major] What we are missing here is some text about the motivation for
whythese extensions are a MUST have for SR Policy signaling via PCEP. I
will try tosummarize:a) To align with SR Policy construct per RFC9256b) To
ensure that the headend is able to "associated" a SR Policy CP signaledvia
PCEP with other CPs of the same SR Policy from other sources - e.g.,locally
configured or via BGP.c) To indicate the intent of the SR Policy via
"color" that can then be usedon the headend for steering BGP service routes
over the SR Policy provisionedvia PCEP (PCE initiated).None of these were
possible without this extension for certain deploymentdesigns - especially
PCE initiated.*

173   The SR Policy is represented by a new type of PCEP Association,
174   called the SR Policy Association (SRPA).  The SR Candidate Paths of
175   an SR Policy are the PCEP LSPs within the same SRPA.  The subject of
176   encoding multiple Segment Lists within an SR Policy Candidate Path is
177   described in [I-D.ietf-pce-multipath].

179   The SRPA carries three pieces of information: SR Policy Identifier,
180   SR Policy Candidate Path Identifier, and SR Policy Candidate Path
181   Attribute(s).

183   This document also specifies some additional information that is not
184   encoded as part of SRPA: Computation Priority, Explicit Null Label
185   Policy, Drop-upon-invalid behavior, and Specified-BSID-only.

187 3.1.  SR Policy Identifier

189   SR Policy Identifier uniquely identifies the SR Policy [RFC9256]
190   within the network.  SR Policy Identifier MUST be the same for all SR
191   Policy Candidate Paths in the same SRPA.  SR Policy Identifier MUST
192   NOT change for a given SR Policy Candidate Path during its lifetime.
193   SR Policy Identifier MUST be different for different SRPAs.  When
194   these rules are not satisfied, the PCEP speaker MUST send a PCErr
195   message with Error-Type = 26 "Association Error", Error Value = 20
196   "SR Policy Identifier Mismatch".  SR Policy Identifier consist of:

198   *  Headend router where the SR Policy originates.

200   *  Color of SR Policy.

202   *  Endpoint of SR Policy.


*[minor] It would be helpful to give specific section references in RFC9256
forthe above.*

204 3.2.  SR Policy Candidate Path Identifier

206   SR Policy Candidate Path Identifier uniquely identifies the SR Policy
207   Candidate Path within the context of an SR Policy.  SR Policy
208   Candidate Path Identifier MUST NOT change for a given LSP during its
209   lifetime.  SR Policy Candidate Path Identifier MUST be different for
210   distinct Candidate Paths within the same SRPA.  When these rules are
211   not satisfied, the PCEP speaker MUST send a PCErr message with Error-
212   Type = 26 "Association Error", Error Value = 21 "SR Policy Candidate
213   Path Identifier Mismatch".  SR Policy Candidate Path Identifier
214   consist of:




*[major] The document should mention the purpose of these parameters (as
alsothe preference in sec 3.3 below) for the tiebreaking at the headend
byreference to the RFC9256 section 2.9.*
216   *  Protocol Origin.

218   *  Originator.

220   *  Discriminator.



*[minor] Same as the previous comment - please provide references to
sections inRFC9256.*
222 3.3.  SR Policy Candidate Path Attributes

224   SR Policy Candidate Path Attributes carry non-key information about
225   the Candidate Path and MAY change during the lifetime of the LSP.  SR
226   Policy Candidate Path Attributes consist of:

228   *  Preference.

*[minor] Preference is also optional - perhaps remove "Optionally" from the*
*2 below?*

230   *  Optionally, the SR Policy Candidate Path name.

232   *  Optionally, the SR Policy name.

264 4.1.  Association Parameters

266   As per [RFC9256], an SR Policy is identified through the tuple
267   <headend, color, endpoint>.  The headend is encoded in the
268   'Association Source' field in the ASSOCIATION object and the color
269   and endpoint are encoded as part of the Extended Association ID TLV.

271   The Association Parameters (see Section 2) consist of:

273   *  Association Type: set to 6 "SR Policy Association".

275   *  Association Source (IPv4/IPv6): set to the headend IP address.

277   *  Association ID (16-bit): set to "1" (this 16-bit field is not
278      utilized, just set to a fixed value).

280   *  Extended Association ID TLV: encodes the Color and Endpoint of the
281      SR Policy.


*[minor] The above is repeated below but using normative text. Is the
abovereally necessary? Could they be combined?*

283   The Association Source MUST be set to the headend value of the SR
284   Policy, as defined in [RFC9256] Section 2.1.

286   The 16-bit Association ID field in the ASSOCIATION object MUST be set
287   to the value of "1".

289   The Extended Association ID TLV MUST be included and it MUST be in
290   the following format:

292       0                   1                   2                   3
293       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
294      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
295      |           Type = 31           |       Length = 8 or 20        |
296      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
297      |                             Color                             |
298      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
299      ~                           Endpoint                            ~
300      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

302                Figure 1: Extended Association ID TLV format

304   Type: Extended Association ID TLV, type = 31 [RFC8697].

306   Length: Either 8 or 20, depending on whether IPv4 or IPv6 address is
307   encoded in the Endpoint field.

309   Color: SR Policy color value, non-zero as per [RFC9256] Section 2.1.

311   Endpoint: can be either IPv4 or IPv6.  This value MAY be different
312   from the one contained in the Destination address field in the END-
313   POINTS object, or in the Tunnel Endpoint Address field in the LSP-
314   IDENTIFIERS TLV.

316   If the PCEP speaker receives an SRPA object whose Association
317   Parameters do not follow the above specification, then the PCEP
318   speaker MUST send PCErr message with Error-Type = 26 "Association
319   Error", Error-Value = 20 "SR Policy Identifier Mismatch".

321   The purpose of choosing the Association Parameters in this way is to
322   guarantee that there is no possibility of a race condition when
323   multiple PCEP speakers want to associate the same SR Policy at the
324   same time.  By adhering to this format, all PCEP speakers come up
325   with the same Association Parameters independently of each other
326   based on the SR Policy [RFC9256] parameters.  Thus, there is no
327   chance that different PCEP speakers will come up with different
328   Association Parameters for the same SR Policy.

330   The last hop of the computed SR Policy Candidate Path MAY differ from
331   the Endpoint contained in the <headend, color, endpoint> tuple.  An
332   example use case is to terminate the SR Policy before reaching the
333   Endpoint and have decapsulated traffic go the rest of the way to the
334   Endpoint node using the native IGP path(s).  In this example, the
335   destination of the SR Policy Candidate Paths will be some node before
336   the Endpoint, but the Endpoint value is still used at the head-end to
337   steer traffic with that Endpoint IP into the SR Policy.  Destination
338   of the SR Policy Candidate Path is signaled using the END-POINTS
339   object and/or LSP-IDENTIFIERS TLV, as per the usual PCEP procedures.
340   When neither END-POINTS object nor LSP-IDENTIFIERS TLV is present,
341   the PCEP speaker MUST extract the destination from the Endpoint field
342   in the SRPA Extended Association ID TLV.

*[major] What about the null endpoint support?*


394 4.2.2.  SR Policy Candidate Path Identifier TLV

396   The SRPOLICY-CPATH-ID TLV is a mandatory TLV for the SRPA object.

398       0                   1                   2                   3
399       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
400      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
401      |             Type              |             Length            |
402      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
403      | Proto. Origin |                      MBZ                      |
404      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
405      |                         Originator ASN                        |
406      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
407      |                                                               |
408      |                       Originator Address                      |
409      |                                                               |
410      |                                                               |
411      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
412      |                         Discriminator                         |
413      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

415                 Figure 3: The SRPOLICY-CPATH-ID TLV format

417   Type: 57 for "SRPOLICY-CPATH-ID" TLV.

419   Length: 28.

421   Protocol Origin: 8-bit value that encodes the protocol origin, as
422   specified in Section 6.5.  Note that in PCInitiate message [RFC8281],
423   the Protocol Origin is always set to 10 (PCEP).

425   MBZ: Must be zero.

427   Originator ASN: Represented as 4-byte number, part of the originator
428   identifier, as specified in [RFC9256] Section 2.4.  If 2-byte ASNs
429   are in use, the low-order 16 bits is used, and the high-order bits
430   are set to 0.  When sending PCInitiate message [RFC8281], the PCE is
431   acting as the originator and therefore MUST set this to an ASN that
432   it belongs to.



*[major] This is an unnecessary restriction on PCEP which does not use
ASN.RFC9256 section 2.4 allows the value of 0 to be used by PCEP when ASN
is notavailable/known.*

434   Originator Address: Represented as 128-bit value where IPv4 address
435   is encoded in lowest 32 bits and high-order bits are set to 0, part
436   of the originator identifier, as specified in [RFC9256] Section 2.4.
437   When sending PCInitiate message, the PCE is acting as the originator
438   and therefore MUST set this to an address that it owns.

440   Discriminator: 32-bit value that encodes the Discriminator of the
441   Candidate Path, as specified in [RFC9256] Section 2.5.  This is the
442   field that mainly distinguishes different SR Candidate Paths, coming
443   from the same originator.  It is allowed to be any number in the
444   32-bit range.


506 5.1.  SR Policy Capability TLV

508   The SRPOLICY-CAPABILITY TLV is an optional TLV for the OPEN object.
509   It is used at session establishment time to learn the other PCEP
510   peer's capabilities with respect to SR Policy.

*[major] I would have preferred if this draft had some text that strongly*
*RECOMMENDS implementations that support SR to support specific aspects *
*in this document (e.g., this capability, SRPA, etc. - the minimal set) *
*to confirm and align **with the SR Policy architecture. This guidance is*
*important for smooth **interop. Most things are "optional" per PCEP, but*
*what is mandatory for alignment with SR Policy Architecture is not clear.*

512       0                   1                   2                   3
513       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
514      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
515      |             Type              |             Length            |
516      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
517      |                             Flags                   |L|S|I|E|P|
518      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

520                Figure 6: The SRPOLICY-CAPABILITY TLV format

522   Type: 71 for "SRPOLICY-CAPABILITY TLV.

524   Length: 4.

526   P-flag: If set to '1' by a PCEP speaker, the P flag indicates that
527   the PCEP speaker supports the handling of COMPUTATION-PRIORITY TLV
528   for the SR Policy, see Section 5.2.  If this flag is not set, then
529   the PCEP speaker MUST NOT send the COMPUTATION-PRIORITY TLV and
530   SHOULD ignore it on receipt.

532   E-Flag: If set to '1' by a PCEP speaker, the E flag indicates that
533   the PCEP speaker supports the handling of ENLP TLV for the SR Policy,
534   see Section 5.3.  If this flag is not set, then the PCEP speaker MUST
535   NOT send the ENLP TLV and SHOULD ignore it on receipt.

537   I-Flag: If set to '1' by a PCEP speaker, the I flag indicates that
538   the PCEP speaker supports the handling of INVALIDATION TLV for the SR
539   Policy, see Section 5.4.  If this flag is not set, then the PCEP
540   speaker MUST NOT send the INVALIDATION TLV and SHOULD ignore it on
541   receipt.

543   S-Flag: If set to '1' by a PCEP speaker, the S flag indicates that
544   the PCEP speaker supports the handling of "Specified-BSID-only"
545   behavior for the SR Policy, see Section 5.5.  If this flag is not
546   set, then the PCEP speaker MUST NOT set the Specified-BSID-only flag
547   in the TE-PATH-BINDING TLV and SHOULD ignore it on receipt.

549   L-Flag: If set to '1' by a PCEP speaker, the L flag indicates that
550   the PCEP speaker supports the stateless (PCReq/PCRep) operations for
551   the SR Policy, see Section 5.6.  If the PCE did not set this flag
552   then the PCC SHOULD NOT send PCReq messages to this PCE for the SR
553   Policy.

555   Unassigned bits MUST be set to '0' on transmission and MUST be
556   ignored on receipt.


622 5.4.  Invalidation TLV

624   The INVALIDATION TLV is an optional TLV for the LSP object.  It is
625   used to control traffic steering into the LSP during the time when
626   the LSP is operationally down/invalid.  In the context of SR Policy,
627   this TLV facilitates the Drop-upon-invalid behavior, specified in
628   Section 8.2 of [RFC9256].  Normally, if the LSP is down/invalid then
629   it stops attracting traffic and traffic that would have been destined
630   to that LSP is redirected somewhere else, such as via IGP or via
631   another LSP.  The Drop-upon-invalid behavior specifies that the LSP
632   keeps attracting traffic and the traffic has to be dropped at the
633   head-end.  Such an LSP is said to be "in drop state".  While in the
634   drop state, the LSP operational state is "UP", as indicated by the
635   O-flag in the LSP object.  However the ERO object MAY be empty, if no
636   valid path has been computed.

638   The INVALIDATION TLV is used in both directions between PCEP peers:

640   *  PCE -> PCC: PCE specifies to the PCC whether to enable or disable
641      Drop-upon-invalid (Config).

643   *  PCC -> PCE: PCC reports the current setting of the Drop-upon-
644      invalid (Config) and also whether the LSP is currently in the drop
645      state (Oper).

647       0                   1                   2                   3
648       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
649      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
650      |             Type              |             Length            |
651      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
652      |   Oper        |   Config      |              MBZ              |
653      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
654                   Figure 9: The INVALIDATION TLV format

656   Type: 70 for "INVALIDATION" TLV.

658   Length: 4.

660   Oper: encodes the current state of the LSP, i.e., whether it is
661   actively dropping traffic right now.  This field can be set to non-
662   zero values only by the PCC, it MUST be set to 0 by the PCE and
663   SHOULD be ignored by the PCC.

665                               0 1 2 3 4 5 6 7
666                              +-+-+-+-+-+-+-+-+
667                              |             |D|
668                              +-+-+-+-+-+-+-+-+

670             Figure 10: Oper state of Drop-upon-invalid feature

672   *  D: dropping - the LSP is currently attracting traffic and actively
673      dropping it.

675   *  The unassigned bits in the Flag octet MUST be set to zero upon
676      transmission and MUST be ignored upon receipt.

678   Config: encodes the current setting of the Drop-upon-invalid feature.

680                               0 1 2 3 4 5 6 7
681                              +-+-+-+-+-+-+-+-+
682                              |             |D|
683                              +-+-+-+-+-+-+-+-+

685            Figure 11: Config state of Drop-upon-invalid feature

687   *  D: drop enabled - the Candidate Path has Drop-upon-invalid feature
688      enabled.

690   *  The unassigned bits in the Flag octet MUST be set to zero upon
691      transmission and MUST be ignored upon receipt.



*[major] Was there a specific reason to specify this as a boolean instead
ofbits/flags?*

833 6.5.  SR Policy Candidate Path Protocol Origin field

835   This document requests IANA to maintain a new registry under "Segment
836   Routing" registry group.  New values are to be assigned by "Standards
837   Action" [RFC8126].  The new subregistry is requested to be created
838   under it be called "SR Policy Protocol Origin".  The subregistry
839   contains the following codepoints, with initial values, to be
840   assigned by IANA with the reference set to this document:



*[major] As shared on a separate email thread, the IANA section needs to
bealigned with draft-ietf-idr-sr-policy-safi*
842   +------------+------------------------------------------------------+
843   | Value        | Description                                        |
844   +--------------+----------------------------------------------------+
845   | 0            | Reserved (not to be used)                          |
846   +--------------+----------------------------------------------------+
847   | 1-9          | Unassigned                                         |
848   +--------------+----------------------------------------------------+
849   | 10           | PCEP                                               |
850   +--------------+----------------------------------------------------+
851   | 11-19        | Unassigned                                         |
852   +--------------+----------------------------------------------------+
853   | 20           | BGP SR Policy                                      |
854   +--------------+----------------------------------------------------+
855   | 21-29        | Unassigned                                         |
856   +--------------+----------------------------------------------------+
857   | 30           | Configuration (CLI, YANG model via NETCONF, etc.)  |
858   +--------------+----------------------------------------------------+
859   | 31-250       | Unassigned                                         |
860   +--------------+----------------------------------------------------+
861   | 251 - 255    | Private Use (not to be assigned by IANA)           |
862   +--------------+----------------------------------------------------+

864 6.6.  SR Policy Explicit Null Label Policy field

866   This document requests IANA to maintain a new registry under "Segment
867   Routing" registry group.  New values are to be assigned by "Standards
868   Action" [RFC8126].  The new subregistry is requested to be created
869   under it be called "SR Policy Explicit Null Label Policy".  The
870   subregistry contains the following codepoints, with initial values,
871   to be assigned by IANA with the reference set to this document:

*[major] Even this IANA allocation needs alignment with the *
*draft-ietf-idr-sr-policy-safi - the action is though on the IDR draft*

*authors (I will take that AI as co-author of that document).*
873   +----------+--------------------------------------------------------+
874   | Value    | Description                                            |
875   +----------+--------------------------------------------------------+
876   | 0        | Reserved (not to be used).                             |
877   +----------+--------------------------------------------------------+
878   | 1        | Push an IPv4 Explicit NULL label on an unlabeled IPv4  |
879   |          | packet, but do not push an IPv6 Explicit NULL label on |
880   |          | an unlabeled IPv6 packet.                              |
881   +----------+--------------------------------------------------------+
882   | 2        | Push an IPv6 Explicit NULL label on an unlabeled IPv6  |
883   |          | packet, but do not push an IPv4 Explicit NULL label on |
884   |          | an unlabeled IPv4 packet.                              |
885   +----------+--------------------------------------------------------+
886   | 3        | Push an IPv4 Explicit NULL label on an unlabeled IPv4  |
887   |          | packet, and push an IPv6 Explicit NULL label on an     |
888   |          | unlabeled IPv6 packet.                                 |
889   +----------+--------------------------------------------------------+
890   | 4        | Do not push an Explicit NULL label.                    |
891   +----------+--------------------------------------------------------+
892   | 5 - 255  | Reserved.                                              |
893   +----------+--------------------------------------------------------+

< end of review >