Hi Ketan,
Thanks for your review. I've uploaded version -16 with your changes addressed
and also please see inline with <MK></MK>.
Thanks,
Mike.
On Monday, April 8th, 2024 at 7:45 AM, Ketan Talaulikar <ketant.i...@gmail.com>
wrote:
> 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.
<MK>
The unit of signaling is the CP. We're not signaling the SR Policy, that would
require a per-Association message type in PCEP. Also, this draft does not cover
all of SR Policy Architecture (Segment-Lists are left out). Hence I think the
sr-policy-cp is more appropriate title.
</MK>
> 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 PCEP
> extensions (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.
<MK>
I would lean more towards "extends" than "updates", because there is nothing
that we want to correct/fix in RFC8664, it's just that this draft allows for
signaling *extra* stuff that RFC8664 does not.
</MK>
> 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 its
> support in PCEP. That term is not specified in RFC8402 and does match to SR
> Policy. So be it. It is important for the introduction to provide some context
> around this and specify that it is this document that is introducing the
> support for SR Policy construct in PCEP.
<MK>
Thanks. I added a sentence in the Introduction section, describing the legacy
nature of RFC8664.</MK>
> 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 the
> purpose 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 CPas per RFC9256.
<MK>
Thanks for drawing attention to this. I improved the wording to say that we
want to signal "LSP membership in Association", not a "grouping of LSPs". I
also removed some duplicate/redundant wording from the Introduction section.
Hopefully it's more clear now.</MK>
> 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 for
> the PCE. Can someone please give an example? My concern here is that the key
> semantics on why the extensions in the spec are absolutely critical for SR
> Policy are being missed out for things that are of perhaps secondary or
> tertiary importance.
<MK>
I reworded the Introduction section. Let me know if anything is till unclear.
The "additional knowledge" I was referring to was the membership of SR CP in
the SR Policy. I removed that particular phrase, I agree it is confusing.</MK>
> 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 a
> reference to specific sections of RFC9256. Just a reference to RFC9256 has
> been found to be difficult for readers for other documents. This is done
> later in the document for some sections so consistency would be good.
<MK>
Done.</MK>
> 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 why
> these extensions are a MUST have for SR Policy signaling via PCEP. I will try
> to
> summarize:
> a) To align with SR Policy construct per RFC9256
> b) To ensure that the headend is able to "associated" a SR Policy CP signaled
> via 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 used
> on the headend for steering BGP service routes over the SR Policy provisioned
> via PCEP (PCE initiated).
> None of these were possible without this extension for certain deployment
> designs - especially PCE initiated.
<MK>
Isn't it kind of obvious that "things that we define in this draft were not
possible prior to this draft"? I had a motivation section earlier in the draft,
but I decided to remove it
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-08#section-3).
If we believe there is any value in it, we can bring it back. I prefer RFCs to
be as brief and to the point as possible. It is assumed that the reader is
already famiiliar with SR Policy and we don't need to explain *why* we want to
signal it.</MK>
> 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 for
> the above.
<MK>
Done.</MK>
> 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 also
> the preference in sec 3.3 below) for the tiebreaking at the headend by
> reference to the RFC9256 section 2.9.
<MK>
We assume the reader is fully familiar with RFC9256, I don't want to put
redundant text here.</MK>
> 216 * Protocol Origin.
>
> 218 * Originator.
>
> 220 * Discriminator.
>
> [minor] Same as the previous comment - please provide references to sections
> in
> RFC9256.
<MK>
Done.</MK>
> 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?
<MK>
Done.</MK>
> 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 above
> really necessary? Could they be combined?
<MK>
Good point. Done.</MK>
> 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?
<MK>
Thanks, added text about color-only steering.</MK>
> 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 not
> available/known.
<MK>
Thanks! Updated.</MK>
> 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.
<MK>
By "optional TLV" I meant that the TLV is not mandatory in general, but it is
definitely mandatory for SR Policy. I updated the wording to reflect this. SRPA
already has its own Capability negotiation using the PCEP ASSOC-Type-List TLV.
I added a mention of that here as well, to make sure the reader doesn't miss
it.</MK>
> 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 of
> bits/flags?
<MK>
I do not see much extensibility here, to be honest. Hence I don't think it's
worth to create 2 registries for this.</MK>
> 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 be
> aligned with draft-ietf-idr-sr-policy-safi
<MK>
Updated.</MK>
> 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).
<MK>
Ok. Thanks.</MK>
> 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 >
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
