idnits 2.17.00 (12 Aug 2021) /tmp/idnits5519/draft-chen-pce-pcep-ifit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2020) is 631 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7799 ** Downref: Normative reference to an Experimental RFC: RFC 8321 == Outdated reference: A later version (-14) exists of draft-ietf-6man-ipv6-alt-mark-01 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-07) exists of draft-ietf-ippm-ioam-direct-export-01 == Outdated reference: A later version (-07) exists of draft-ietf-ippm-ioam-flags-02 == Outdated reference: A later version (-07) exists of draft-ietf-ippm-ioam-ipv6-options-02 == Outdated reference: A later version (-13) exists of draft-ietf-pce-segment-routing-ipv6-06 == Outdated reference: A later version (-07) exists of draft-ietf-pce-segment-routing-policy-cp-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-04) exists of draft-qin-idr-sr-policy-ifit-02 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE H. Chen 3 Internet-Draft China Telecom 4 Intended status: Standards Track H. Yuan 5 Expires: March 1, 2021 UnionPay 6 T. Zhou 7 W. Li 8 G. Fioccola 9 Y. Wang 10 Huawei 11 August 28, 2020 13 Path Computation Element Communication Protocol (PCEP) Extensions to 14 Enable IFIT 15 draft-chen-pce-pcep-ifit-00 17 Abstract 19 This document defines PCEP extensions to distribute In-situ Flow 20 Information Telemetry (IFIT) information. So that IFIT behavior can 21 be enabled automatically when the path is instantiated. In-situ Flow 22 Information Telemetry (IFIT) refers to network OAM data plane on-path 23 telemetry techniques, in particular the most popular are In-situ OAM 24 (IOAM) and Alternate Marking. The IFIT attributes here described can 25 be generalized for all path types but the application to Segment 26 Routing (SR) is considered in this document. The SR policy is a set 27 of candidate SR paths consisting of one or more segment lists and 28 necessary path attributes. It enables instantiation of an ordered 29 list of segments with a specific intent for traffic steering. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 1, 2021. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. PCEP Extensions for IFIT Attributes . . . . . . . . . . . . . 4 73 2.1. IFIT for SR Policies . . . . . . . . . . . . . . . . . . 4 74 3. IFIT capability advertisement TLV . . . . . . . . . . . . . . 4 75 4. IFIT Attributes TLV . . . . . . . . . . . . . . . . . . . . . 5 76 4.1. IOAM Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 7 77 4.1.1. IOAM Pre-allocated Trace Option Sub-TLV . . . . . . . 7 78 4.1.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . 8 79 4.1.3. IOAM Directly Export Option Sub-TLV . . . . . . . . . 9 80 4.1.4. IOAM Edge-to-Edge Option Sub-TLV . . . . . . . . . . 10 81 4.2. Enhanced Alternate Marking Sub-TLV . . . . . . . . . . . 11 82 5. Example of operation . . . . . . . . . . . . . . . . . . . . 12 83 5.1. PCE Initiated SR Policy with single or multiple 84 candidate-paths . . . . . . . . . . . . . . . . . . . . . 12 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 9.2. Informative References . . . . . . . . . . . . . . . . . 15 91 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 In-situ Flow Information Telemetry (IFIT) refers to network OAM data 97 plane on-path telemetry techniques, including In-situ OAM (IOAM) 98 [I-D.ietf-ippm-ioam-data] and Alternate Marking [RFC8321]. It can 99 provide flow information on the entire forwarding path on a per- 100 packet basis in real time. 102 An automatic network requires the Service Level Agreement (SLA) 103 monitoring on the deployed service. So that the system can quickly 104 detect the SLA violation or the performance degradation, hence to 105 change the service deployment. 107 This document defines extensions to PCEP to distribute paths carrying 108 IFIT information. So that IFIT behavior can be enabled automatically 109 when the path is instantiated. 111 RFC 5440 [RFC5440] describes the Path Computation Element Protocol 112 (PCEP) as a communication mechanism between a Path Computation Client 113 (PCC) and a Path Computation Element (PCE), or between a PCE and a 114 PCE. 116 RFC 8231 [RFC8231] specifies extensions to PCEP to enable stateful 117 control and it describes two modes of operation: passive stateful PCE 118 and active stateful PCE. Further, RFC 8281 [RFC8281] describes the 119 setup, maintenance, and teardown of PCE-initiated LSPs for the 120 stateful PCE model, while RFC 8733 [RFC8733] is focused on the active 121 stateful PCE, where the LSPs are controlled by the PCE. 123 When a PCE is used to initiate paths using PCEP, it is important that 124 the head end of the path also understands the IFIT behavior that is 125 intended for the path. When PCEP is in use for path initiation it 126 makes sense for that same protocol to be used to also carry the IFIT 127 attributes that describe the IOAM or Alternate Marking procedure that 128 needs to be applied to the data that flow those paths. 130 The PCEP extension defined in this document allows to signal the IFIT 131 capabilities. In this way IFIT methods are automatically activated 132 and running. The flexibility and dynamicity of the IFIT applications 133 are given by the use of additional functions on the controller and on 134 the network nodes, but this is out of scope here. 136 The Use Case of Segment Routing (SR) is discussed considering that 137 IFIT methods are becoming mature for Segment Routing over the MPLS 138 data plane (SR-MPLS) and Segment Routing over IPv6 data plane (SRv6). 139 In this way SR policy native IFIT can facilitate the closed loop 140 control and enable the automation of SR service. 142 Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy] 143 is a set of candidate SR paths consisting of one or more segment 144 lists and necessary path attributes. It enables instantiation of an 145 ordered list of segments with a specific intent for traffic steering. 147 It is to be noted the companion document [I-D.qin-idr-sr-policy-ifit] 148 that proposes the BGP extension to enable IFIT methods for SR policy. 150 2. PCEP Extensions for IFIT Attributes 152 This document is to add IFIT attribute TLVs as PCEP Extensions. The 153 following sections will describe the requirement and usage of 154 different IFIT modes, and define the corresponding TLV encoding in 155 PCEP. 157 The IFIT attributes here described can be generalized and included as 158 TLVs carried inside the LSPA (LSP Attributes) object in order to be 159 applied for all path types, as long as they support the relevant data 160 plane telemetry method. IFIT TLVs are o ptional and can be taken 161 into account by the PCE during path computation. In general, the 162 LSPA object is carried within a PCInitiate message or a PCRpt 163 message. 165 In this document it is considered the case of SR Policy since IOAM 166 and Alternate Marking are more mature especially for Segment Routing 167 (SR) and for IPv6. 169 2.1. IFIT for SR Policies 171 RFC 8664 [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6] specify 172 extensions to the Path Computation Element Communication Protocol 173 (PCEP) that allow a stateful PCE to compute and initiate Traffic- 174 Engineering (TE) paths, as well as a Path Computation Client (PCC) to 175 request a path subject to certain constraints and optimization 176 criteria in SR networks both for SR-MPLS and SRv6. 178 IFIT attibutes, here defined as TLVs for the LSPA object, complement 179 both RFC 8664 [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 180 [I-D.ietf-pce-segment-routing-policy-cp]. 182 3. IFIT capability advertisement TLV 184 During the PCEP initialization phase, PCEP speakers (PCE or PCC) 185 SHOULD advertise their support of IFIT methods (e.g. IOAM and 186 Alternate Marking). 188 A PCEP speaker includes the IFIT TLVs in the OPEN object to advertise 189 its support for PCEP IFIT extensions. 191 RFC 8664 [RFC8664] and and [I-D.ietf-pce-segment-routing-ipv6] define 192 a new Path Setup Type (PST) for SR and also define the SR-PCE- 193 CAPABILITY sub-TLV. This document defined a new IFIT-CAPABILITY TLV, 194 that is an optional TLV for use in the OPEN Object for IFIT 195 attributes via PCEP capability advertisement. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Flag | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Fig. 1 IFIT-CAPABILITY TLV Format 207 Where: 209 Type: to be assigned by IANA. 211 Length: The Length field defines the length of the value portion in 212 bytes as per RFC 5440 [RFC5440]. 214 Flag: No flags are defined for this TLV in this document. Unassigned 215 bits are considered reserved. They MUST be set to 0 on transmission 216 and MUST be ignored on receipt. 218 Advertisement of the IFIT-CAPABILITY TLV implies support of IFIT 219 methods (IOAM and/or Alternate Marking) as well as the objects, TLVs, 220 and procedures defined in this document. It is worth mentioning that 221 IOAM and Alternate Marking can be activated one at a time or can 222 coexist; so it is possible to have only IOAM or only Alternate 223 Marking enabled but they are recognized in general as IFIT 224 capability. 226 4. IFIT Attributes TLV 228 The IFIT TLV provides the configurable knobs of the IFIT feature, and 229 it can be included as an optional TLV in the LSPA object (as 230 described in RFC 5440 [RFC5440]). 232 For a PCE-initiated LSP RFC 8281 [RFC8281], this TLV is included in 233 the LSPA object with the PCInitiate message. For the PCC-initiated 234 delegated LSPs, this TLV is carried in the Path Computation State 235 Report (PCRpt) message in the LSPA object. This TLV is also carried 236 in the LSPA object with the Path Computation Update Request (PCUpd) 237 message to direct the PCC (LSP head-end) to make updates to IFIT 238 attributes. 240 The TLV is encoded in all PCEP messages for the LSP if IFIT feature 241 is enabled. The absence of the TLV indicates the PCEP speaker wishes 242 to disable the feature. This TLV includes multiple IFIT-ATTRIBUTES 243 sub-TLVs. The IFIT-ATTRIBUTES sub-TLVs are included if there is a 244 change since the last information sent in the PCEP message. The 245 default values for missing sub-TLVs apply for the first PCEP message 246 for the LSP. 248 The format of the IFIT-ATTRIBUTES TLV is shown in the following 249 figure: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 // sub-TLVs // 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Fig. 2 IFIT-ATTRIBUTES TLV Format 263 Where: 265 Type: to be assigned by IANA. 267 Length: The Length field defines the length of the value portion in 268 bytes as per RFC 5440 [RFC5440]. 270 Value: This comprises one or more sub-TLVs. 272 The following sub-TLVs are defined in this document: 274 +------+-----+--------------------------------------+ 275 | Type | Len | Name | 276 +======+=====+======================================+ 277 | 1 | 8 | IOAM Pre-allocated Trace Option | 278 +------+-----+--------------------------------------+ 279 | 2 | 8 | IOAM Incremental Trace Option | 280 +------+-----+--------------------------------------+ 281 | 3 | 12 | IOAM Directly Export Option | 282 +------+-----+--------------------------------------+ 283 | 4 | 4 | IOAM Edge-to-Edge Option | 284 +------+-----+--------------------------------------+ 285 | 5 | 4 | Enhanced Alternate Marking | 286 +------+-----+--------------------------------------+ 288 Fig. 3 Sub-TLV Types of the IFIT-ATTRIBUTES TLV 290 4.1. IOAM Sub-TLVs 292 In-situ Operations, Administration, and Maintenance (IOAM) 293 [I-D.ietf-ippm-ioam-data] records operational and telemetry 294 information in the packet while the packet traverses a path between 295 two points in the network. In terms of the classification given in 296 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 297 mechanisms can be leveraged where active OAM do not apply or do not 298 offer the desired results. 300 For the SR use case, when SR policy enables IOAM, the IOAM header 301 will be inserted into every packet of the traffic that is steered 302 into the SR paths. Since this document aims to define the control 303 plane, it is to be noted that a relevant document for the data plane 304 is [I-D.ietf-ippm-ioam-ipv6-options] for Segment Routing over IPv6 305 data plane (SRv6). 307 4.1.1. IOAM Pre-allocated Trace Option Sub-TLV 309 The IOAM tracing data is expected to be collected at every node that 310 a packet traverses to ensure visibility into the entire path a packet 311 takes within an IOAM domain. The preallocated tracing option will 312 create pre-allocated space for each node to populate its information. 314 The format of IOAM pre-allocated trace option Sub-TLV is defined as 315 follows: 317 0 1 2 3 318 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 319 +-------------------------------+-------------------------------+ 320 | Type=1 | Length | 321 +---------------------------------------------------------------+ 322 | Namespace ID | Rsvd1 | 323 +-------------------------------+-----------------------+-------+ 324 | IOAM Trace Type | Flags | Rsvd2 | 325 +----------------------------------------------+--------+-------+ 327 Fig. 4 IOAM Pre-allocated Trace Option Sub-TLV 329 Where: 331 Type: 1 (to be assigned by IANA). 333 Length: the total length of the value field not including Type and 334 Length fields. 336 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 337 definition is the same as described in section 4.4 of 338 [I-D.ietf-ippm-ioam-data]. 340 IOAM Trace Type: A 24-bit identifier which specifies which data types 341 are used in the node data list. The definition is the same as 342 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 344 Flags: A 4-bit field. The definition is the same as described in 345 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 346 [I-D.ietf-ippm-ioam-data]. 348 Rsvd1: A 16-bit field reserved for further usage. It MUST be zero. 350 Rsvd2: A 4-bit field reserved for further usage. It MUST be zero. 352 4.1.2. IOAM Incremental Trace Option Sub-TLV 354 The incremental tracing option contains a variable node data fields 355 where each node allocates and pushes its node data immediately 356 following the option header. 358 The format of IOAM incremental trace option Sub-TLV is defined as 359 follows: 361 0 1 2 3 362 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 363 +-------------------------------+-------------------------------+ 364 | Type=2 | Length | 365 +---------------------------------------------------------------+ 366 | Namespace ID | Rsvd1 | 367 +-------------------------------+-----------------------+-------+ 368 | IOAM Trace Type | Flags | Rsvd2 | 369 +----------------------------------------------+--------+-------+ 371 Fig. 5 IOAM Incremental Trace Option Sub-TLV 373 Where: 375 Type: 2 (to be assigned by IANA). 377 Length: the total length of the value field not including Type and 378 Length fields. 380 All the other fields definition is the same as the pre-allocated 381 trace option Sub-TLV in the previous section. 383 4.1.3. IOAM Directly Export Option Sub-TLV 385 IOAM directly export option is used as a trigger for IOAM data to be 386 directly exported to a collector without being pushed into in-flight 387 data packets. 389 The format of IOAM directly export option Sub-TLV is defined as 390 follows: 392 0 1 2 3 393 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 394 +-------------------------------+-------------------------------+ 395 | Type=3 | Length | 396 +---------------------------------------------------------------+ 397 | Namespace ID | Flags | 398 +-------------------------------+---------------+---------------+ 399 | IOAM Trace Type | Rsvd | 400 +-----------------------------------------------+---------------+ 401 | Flow ID | 402 +---------------------------------------------------------------+ 404 Fig. 6 IOAM Directly Export Option Sub-TLV 406 Where: 408 Type: 3 (to be assigned by IANA). 410 Length: the total length of the value field not including Type and 411 Length fields. 413 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 414 definition is the same as described in section 4.4 of 415 [I-D.ietf-ippm-ioam-data]. 417 IOAM Trace Type: A 24-bit identifier which specifies which data types 418 are used in the node data list. The definition is the same as 419 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 421 Flags: A 16-bit field. The definition is the same as described in 422 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 424 Flow ID: A 32-bit flow identifier. The definition is the same as 425 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 427 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 429 4.1.4. IOAM Edge-to-Edge Option Sub-TLV 431 The IOAM edge to edge option is to carry data that is added by the 432 IOAM encapsulating node and interpreted by IOAM decapsulating node. 434 The format of IOAM edge-to-edge option Sub-TLV is defined as follows: 436 0 1 2 3 437 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 438 +-------------------------------+-------------------------------+ 439 | Type=4 | Length | 440 +---------------------------------------------------------------+ 441 | Namespace ID | IOAM E2E Type | 442 +-------------------------------+-------------------------------+ 444 Fig. 7 IOAM Edge-to-Edge Option Sub-TLV 446 Where: 448 Type: 4 (to be assigned by IANA). 450 Length: the total length of the value field not including Type and 451 Length fields. 453 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 454 definition is the same as described in section 4.6 of 455 [I-D.ietf-ippm-ioam-data]. 457 IOAM E2E Type: A 16-bit identifier which specifies which data types 458 are used in the E2E option data. The definition is the same as 459 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 461 4.2. Enhanced Alternate Marking Sub-TLV 463 The Alternate Marking [RFC8321]technique is an hybrid performance 464 measurement method, per RFC 7799 [RFC7799] classification of 465 measurement methods. Because this method is based on marking 466 consecutive batches of packets. It can be used to measure packet 467 loss, latency, and jitter on live traffic. 469 For the SR use case, since this document aims to define the control 470 plane, it is to be noted that a relevant document for the data plane 471 is [I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data 472 plane (SRv6). 474 The format of Enhanced Alternate Marking (EAM) Sub-TLV is defined as 475 follows: 477 0 1 2 3 478 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 479 +-------------------------------+-------------------------------+ 480 | Type=5 | Length | 481 +-------------------------------+-------+---------------+-------+ 482 | FlowMonID | Period | Rsvd | 483 +---------------------------------------+---------------+-------+ 485 Fig. 8 Enhanced Alternate Marking Sub-TLV 487 Where: 489 Type: 5 (to be assigned by IANA). 491 Length: the total length of the value field not including Type and 492 Length fields. 494 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 495 within the measurement domain. The definition is the same as 496 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. It is to 497 be noted that PCE also needs to maintain the uniqueness of FlowMonID 498 as described in [I-D.ietf-6man-ipv6-alt-mark]. 500 Period: Time interval between two alternate marking period. The unit 501 is second. 503 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 505 5. Example of operation 507 5.1. PCE Initiated SR Policy with single or multiple candidate-paths 509 A PCC or PCE sets the IFIT-CAPABILITY TLV in the Open message during 510 the PCEP initialization phase to indicate that it supports the IFIT 511 procedures. 513 1. For single candidate-path, PCE sends PCInitiate message, 514 containing the SRPAG Association object 515 ([I-D.ietf-pce-segment-routing-policy-cp]) and IFIT-ATTRIBUTES via 516 LSPA TLVs. For multiple candidate-paths, PCE sends a separate 517 PCInitiate message for every candidate path that it wants to create, 518 or it sends multiple LSP objects within a single PCInitiate message. 519 The SRPAG Association object 520 ([I-D.ietf-pce-segment-routing-policy-cp]) is sent for every LSP in 521 the PCInitiate message and the IFIT-ATTRIBUTES are sent as LSPA TLVs. 523 2. For single candidate-path, PCC uses the color, endpoint and 524 preference from the SRPAG object to create a new candidate path. If 525 no SR policy exists to hold the candidate path, then a new SR policy 526 is created to hold the new candidate-path considering the IFIT LSPA 527 TLVs too. For multiple candidate-paths, PCC creates multiple 528 candidate paths under the same SR policy, identified by Color and 529 Endpoint and also IFIT-ATTRIBUTES. 531 3. For both single candidate-path and multiple candidate-paths, PCC 532 sends a PCRpt message back to the PCE to report the newly created 533 Candidate Path. The PCRpt message contains the SRPAG Association 534 object and IFIT-ATTRIBUTES information. 536 +-+-+ +-+-+ 537 |PCC| |PCE| 538 +-+-+ +-+-+ 539 | | 540 |<--PCInitiate-------------------| 541 | | 542 |---PCRpt----------------------->| 543 | | 545 The procedure of enabling/disabling IFIT is simple, indeed the PCE 546 can update the IFIT-ATTRIBUTES of the LSP by sending subsequent Path 547 Computation Update Request (PCUpd) messages. 549 +-+-+ +-+-+ 550 |PCC| |PCE| 551 +-+-+ +-+-+ 552 | | 553 |<--PCUpd------------------------| 554 | | 555 |---PCRpt----------------------->| 556 | | 558 6. IANA Considerations 560 This document defines the new IFIT-CAPABILITY TLV and IFIT-ATTRIBUTES 561 TLV. IANA is requested to make the assignment from the "PCEP TLV 562 Type Indicators" subregistry of the "Path Computation Element 563 Protocol (PCEP) Numbers" registry as follows: 565 Value Description Reference 566 ------------------------------------------------------------- 567 TBD1 IFIT-CAPABILITY This document 569 TBD2 IFIT-ATTRIBUTES This document 571 This document also specifies the IFIT-ATTRIBUTES sub-TLVs. IANA is 572 requested to create an "IFIT-ATTRIBUTES Sub-TLV Types" subregistry 573 within the "Path Computation Element Protocol (PCEP) Numbers" 574 registry. 576 This document defines the following types: 578 Type Description Reference 579 ------------------------------------------------------------- 580 0 Reserved This document 582 1 IOAM Pre-allocated Trace Option This document 584 2 IOAM Incremental Trace Option This document 586 3 IOAM Directly Export Option This document 588 4 IOAM Edge-to-Edge Option This document 590 5 Enhanced Alternate Marking This document 592 6-65535 Unassigned/Experimental Use This document 594 7. Security Considerations 596 This document defines the new IFIT-CAPABILITY TLV and IFIT Attributes 597 TLVs, which do not add any substantial new security concerns beyond 598 those already discussed in RFC 8231 [RFC8231] and RFC 8281 [RFC8281] 599 for stateful PCE operations. 601 8. Acknowledgements 603 The authors would like to thank Dhruv Doody for the precious inputs 604 and suggestions. 606 9. References 608 9.1. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, 612 DOI 10.17487/RFC2119, March 1997, 613 . 615 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 616 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 617 DOI 10.17487/RFC5440, March 2009, 618 . 620 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 621 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 622 May 2016, . 624 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 625 Computation Element Communication Protocol (PCEP) 626 Extensions for Stateful PCE", RFC 8231, 627 DOI 10.17487/RFC8231, September 2017, 628 . 630 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 631 Computation Element Communication Protocol (PCEP) 632 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 633 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 634 . 636 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 637 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 638 "Alternate-Marking Method for Passive and Hybrid 639 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 640 January 2018, . 642 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 643 and J. Hardwick, "Path Computation Element Communication 644 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 645 DOI 10.17487/RFC8664, December 2019, 646 . 648 [RFC8733] Dhody, D., Ed., Gandhi, R., Ed., Palle, U., Singh, R., and 649 L. Fang, "Path Computation Element Communication Protocol 650 (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) 651 Auto-Bandwidth Adjustment with Stateful PCE", RFC 8733, 652 DOI 10.17487/RFC8733, February 2020, 653 . 655 9.2. Informative References 657 [I-D.ietf-6man-ipv6-alt-mark] 658 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 659 Pang, "IPv6 Application of the Alternate Marking Method", 660 draft-ietf-6man-ipv6-alt-mark-01 (work in progress), June 661 2020. 663 [I-D.ietf-ippm-ioam-data] 664 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 665 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 666 progress), July 2020. 668 [I-D.ietf-ippm-ioam-direct-export] 669 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 670 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 671 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 672 export-01 (work in progress), August 2020. 674 [I-D.ietf-ippm-ioam-flags] 675 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 676 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 677 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-02 678 (work in progress), July 2020. 680 [I-D.ietf-ippm-ioam-ipv6-options] 681 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 682 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 683 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 684 "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 685 ipv6-options-02 (work in progress), July 2020. 687 [I-D.ietf-pce-segment-routing-ipv6] 688 Li, C., Negi, M., Koldychev, M., Kaladharan, P., and Y. 689 Zhu, "PCEP Extensions for Segment Routing leveraging the 690 IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-06 691 (work in progress), July 2020. 693 [I-D.ietf-pce-segment-routing-policy-cp] 694 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 695 Bidgoli, "PCEP extension to support Segment Routing Policy 696 Candidate Paths", draft-ietf-pce-segment-routing-policy- 697 cp-00 (work in progress), June 2020. 699 [I-D.ietf-spring-segment-routing-policy] 700 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 701 P. Mattes, "Segment Routing Policy Architecture", draft- 702 ietf-spring-segment-routing-policy-08 (work in progress), 703 July 2020. 705 [I-D.qin-idr-sr-policy-ifit] 706 Qin, F., Yuan, H., Zhou, T., Fioccola, G., and Y. Wang, 707 "BGP SR Policy Extensions to Enable IFIT", draft-qin-idr- 708 sr-policy-ifit-02 (work in progress), July 2020. 710 Appendix A. 712 Authors' Addresses 714 Huanan Chen 715 China Telecom 716 Guangzhou 717 China 719 Email: chenhuan6@chinatelecom.cn 721 Hang Yuan 722 UnionPay 723 1899 Gu-Tang Rd., Pudong 724 Shanghai 725 China 727 Email: yuanhang@unionpay.com 728 Tianran Zhou 729 Huawei 730 156 Beiqing Rd., Haidian District 731 Beijing 732 China 734 Email: zhoutianran@huawei.com 736 Weidong Li 737 Huawei 738 156 Beiqing Rd., Haidian District 739 Beijing 740 China 742 Email: poly.li@huawei.com 744 Giuseppe Fioccola 745 Huawei 746 Riesstrasse, 25 747 Munich 748 Germany 750 Email: giuseppe.fioccola@huawei.com 752 Yali Wang 753 Huawei 754 156 Beiqing Rd., Haidian District 755 Beijing 756 China 758 Email: wangyali11@huawei.com