idnits 2.17.00 (12 Aug 2021) /tmp/idnits4759/draft-chen-pce-pcep-ifit-06.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: ---------------------------------------------------------------------------- == Line 807 has weird spacing: '...eration capa...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 4, 2022) is 99 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) == Outdated reference: A later version (-14) exists of draft-ietf-6man-ipv6-alt-mark-12 == Outdated reference: A later version (-07) exists of draft-ietf-ippm-ioam-ipv6-options-06 ** Downref: Normative reference to an Informational RFC: RFC 7799 ** Downref: Normative reference to an Experimental RFC: RFC 8321 ** Downref: Normative reference to an Informational RFC: RFC 8799 == Outdated reference: A later version (-13) exists of draft-ietf-pce-segment-routing-ipv6-11 == Outdated reference: A later version (-07) exists of draft-ietf-pce-segment-routing-policy-cp-06 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-16 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE H. Yuan 3 Internet-Draft UnionPay 4 Intended status: Standards Track T. Zhou 5 Expires: August 8, 2022 W. Li 6 G. Fioccola 7 Y. Wang 8 Huawei 9 February 4, 2022 11 Path Computation Element Communication Protocol (PCEP) Extensions to 12 Enable IFIT 13 draft-chen-pce-pcep-ifit-06 15 Abstract 17 This document defines PCEP extensions to distribute In-situ Flow 18 Information Telemetry (IFIT) information. So that IFIT behavior can 19 be enabled automatically when the path is instantiated. In-situ Flow 20 Information Telemetry (IFIT) refers to network OAM data plane on-path 21 telemetry techniques, in particular the most popular are In-situ OAM 22 (IOAM) and Alternate Marking. The IFIT attributes here described can 23 be generalized for all path types but the application to Segment 24 Routing (SR) is considered in this document. This document extends 25 PCEP to carry the IFIT attributes under the stateful PCE model. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in in BCP 14 [RFC2119] 32 [RFC8174] when, and only when, they appear in all capitals, as shown 33 here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 8, 2022. 51 Copyright Notice 53 Copyright (c) 2022 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. PCEP Extensions for IFIT Attributes . . . . . . . . . . . . . 4 70 2.1. IFIT for SR Policies . . . . . . . . . . . . . . . . . . 5 71 3. IFIT capability advertisement TLV . . . . . . . . . . . . . . 5 72 4. IFIT Attributes TLV . . . . . . . . . . . . . . . . . . . . . 7 73 4.1. IOAM Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1.1. IOAM Pre-allocated Trace Option Sub-TLV . . . . . . . 9 75 4.1.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . 10 76 4.1.3. IOAM Directly Export Option Sub-TLV . . . . . . . . . 10 77 4.1.4. IOAM Edge-to-Edge Option Sub-TLV . . . . . . . . . . 11 78 4.2. Enhanced Alternate Marking Sub-TLV . . . . . . . . . . . 12 79 5. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.1. The PCInitiate Message . . . . . . . . . . . . . . . . . 13 81 5.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 14 82 5.3. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 14 83 6. Example of application to SR Policy . . . . . . . . . . . . . 14 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 15 86 7.2. IFIT-CAPABILITY TLV Flags field . . . . . . . . . . . . . 16 87 7.3. IFIT-ATTRIBUTES Sub-TLV . . . . . . . . . . . . . . . . . 16 88 7.4. Enhanced Alternate Marking Sub-TLV Flags field . . . . . 17 89 7.5. PCEP Error Codes . . . . . . . . . . . . . . . . . . . . 18 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 95 11.2. Informative References . . . . . . . . . . . . . . . . . 21 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 98 1. Introduction 100 In-situ Flow Information Telemetry (IFIT) refers to network OAM 101 (Operations, Administration, and Maintenance) data plane on-path 102 telemetry techniques, including In-situ OAM (IOAM) 103 [I-D.ietf-ippm-ioam-data] and Alternate Marking [RFC8321]. It can 104 provide flow information on the entire forwarding path on a per- 105 packet basis in real time. 107 An automatic network requires the Service Level Agreement (SLA) 108 monitoring on the deployed service. So that the system can quickly 109 detect the SLA violation or the performance degradation, hence to 110 change the service deployment. 112 This document defines extensions to PCEP to distribute paths carrying 113 IFIT information. So that IFIT behavior can be enabled automatically 114 when the path is instantiated. 116 RFC 5440 [RFC5440] describes the Path Computation Element Protocol 117 (PCEP) as a communication mechanism between a Path Computation Client 118 (PCC) and a Path Computation Element (PCE), or between a PCE and a 119 PCE. 121 RFC 8231 [RFC8231] specifies extensions to PCEP to enable stateful 122 control and it describes two modes of operation: passive stateful PCE 123 and active stateful PCE. Further, RFC 8281 [RFC8281] describes the 124 setup, maintenance, and teardown of PCE-initiated LSPs for the 125 stateful PCE model. 127 When a PCE is used to initiate paths using PCEP, it is important that 128 the head end of the path also understands the IFIT behavior that is 129 intended for the path. When PCEP is in use for path initiation it 130 makes sense for that same protocol to be used to also carry the IFIT 131 attributes that describe the IOAM or Alternate Marking procedure that 132 needs to be applied to the data that flow those paths. 134 The PCEP extension defined in this document allows to signal the IFIT 135 capabilities. In this way IFIT methods are automatically activated 136 and running. The flexibility and dynamicity of the IFIT applications 137 are given by the use of additional functions on the controller and on 138 the network nodes, but this is out of scope here. 140 IFIT is a solution focusing on network domains according to [RFC8799] 141 that introduces the concept of specific domain solutions. A network 142 domain consists of a set of network devices or entities within a 143 single administration. As mentioned in [RFC8799], for a number of 144 reasons, such as policies, options supported, style of network 145 management and security requirements, it is suggested to limit 146 applications including the emerging IFIT techniques to a controlled 147 domain. Hence, the IFIT methods MUST be typically deployed in such 148 controlled domains. 150 The Use Case of Segment Routing (SR) is also discussed considering 151 that IFIT methods are becoming mature for Segment Routing over the 152 MPLS data plane (SR-MPLS) and Segment Routing over IPv6 data plane 153 (SRv6). SR policy [I-D.ietf-spring-segment-routing-policy] is a set 154 of candidate SR paths consisting of one or more segment lists and 155 necessary path attributes. It enables instantiation of an ordered 156 list of segments with a specific intent for traffic steering. The 157 PCEP extension defined in this document also enables SR policy with 158 native IFIT, that can facilitate the closed loop control and enable 159 the automation of SR service. 161 It is to be noted the companion document [I-D.qin-idr-sr-policy-ifit] 162 that proposes the BGP extension to enable IFIT methods for SR policy. 164 2. PCEP Extensions for IFIT Attributes 166 This document is to add IFIT attribute TLVs as PCEP Extensions. The 167 following sections will describe the requirement and usage of 168 different IFIT modes, and define the corresponding TLV encoding in 169 PCEP. 171 The IFIT attributes here described can be generalized and included as 172 TLVs carried inside the LSPA (LSP Attributes) object in order to be 173 applied for all path types, as long as they support the relevant data 174 plane telemetry method. IFIT Attributes TLVs are optional and can be 175 taken into account by the PCE during path computation and by the PCC 176 during path setup. In general, the LSPA object can be carried within 177 a PCInitiate message, a PCUpd message, or a PCRpt message in the 178 stateful PCE model. 180 In this document it is considered the case of SR Policy since IOAM 181 and Alternate Marking are more mature especially for Segment Routing 182 (SR) and for IPv6. 184 It is to be noted that, if it is needed to apply different IFIT 185 methods for each Segment List, the IFIT attributes can be added into 186 the PATH-ATTRIB object, instead of the LSPA object, according to 187 [I-D.koldychev-pce-multipath] that defines PCEP Extensions for 188 Signaling Multipath Information. 190 2.1. IFIT for SR Policies 192 RFC 8664 [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6] specify 193 extensions to the Path Computation Element Communication Protocol 194 (PCEP) that allow a stateful PCE to compute and initiate Traffic- 195 Engineering (TE) paths, as well as a Path Computation Client (PCC) to 196 request a path subject to certain constraints and optimization 197 criteria in SR networks both for SR-MPLS and SRv6. 199 IFIT attibutes, here defined as TLVs for the LSPA object, complement 200 both RFC 8664 [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 201 [I-D.ietf-pce-segment-routing-policy-cp]. 203 3. IFIT capability advertisement TLV 205 During the PCEP initialization phase, PCEP speakers (PCE or PCC) 206 SHOULD advertise their support of IFIT methods (e.g. IOAM and 207 Alternate Marking). 209 A PCEP speaker includes the IFIT-CAPABILITY TLVs in the OPEN object 210 to advertise its support for PCEP IFIT extensions. The presence of 211 the IFIT-CAPABILITY TLV in the OPEN object indicates that the IFIT 212 methods are supported. 214 RFC 8664 [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6] define a 215 new Path Setup Type (PST) for SR and also define the SR-PCE- 216 CAPABILITY sub-TLV. This document defined a new IFIT-CAPABILITY TLV, 217 that is an optional TLV for use in the OPEN Object for IFIT 218 attributes via PCEP capability advertisement. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type | Length=4 | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Flags |P|I|D|E|M| 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Fig. 1 IFIT-CAPABILITY TLV Format 230 Where: 232 Type: to be assigned by IANA. 234 Length: 4. 236 Flags: The following flags are defined in this document: 238 P: IOAM Pre-allocated Trace Option Type-enabled flag 239 [I-D.ietf-ippm-ioam-data]. If set to 1 by a PCC, the P flag 240 indicates that the PCC allows instantiation of the IOAM Pre- 241 allocated Trace feature by a PCE. If set to 1 by a PCE, the P 242 flag indicates that the PCE supports the IOAM Pre-allocated Trace 243 feature instantiation. The P flag MUST be set by both PCC and PCE 244 in order to support the IOAM Pre-allocated Trace instantiation 246 I: IOAM Incremental Trace Option Type-enabled flag 247 [I-D.ietf-ippm-ioam-data]. If set to 1 by a PCC, the I flag 248 indicates that the PCC allows instantiation of the IOAM 249 Incremental Trace feature by a PCE. If set to 1 by a PCE, the I 250 flag indicates that the PCE supports the relative IOAM Incremental 251 Trace feature instantiation. The I flag MUST be set by both PCC 252 and PCE in order to support the IOAM Incremental Trace feature 253 instantiation 255 D: IOAM DEX Option Type-enabled flag 256 [I-D.ietf-ippm-ioam-direct-export]. If set to 1 by a PCC, the D 257 flag indicates that the PCC allows instantiation of the relative 258 IOAM DEX feature by a PCE. If set to 1 by a PCE, the D flag 259 indicates that the PCE supports the relative IOAM DEX feature 260 instantiation. The D flag MUST be set by both PCC and PCE in 261 order to support the IOAM DEX feature instantiation 263 E: IOAM E2E Option Type-enabled flag [I-D.ietf-ippm-ioam-data]. 264 If set to 1 by a PCC, the E flag indicates that the PCC allows 265 instantiation of the relative IOAM E2E feature by a PCE. If set 266 to 1 by a PCE, the E flag indicates that the PCE supports the 267 relative IOAM E2E feature instantiation. The E flag MUST be set 268 by both PCC and PCE in order to support the IOAM E2E feature 269 instantiation 271 M: Alternate Marking enabled flag RFC 8321 [RFC8321]. If set to 1 272 by a PCC, the M flag indicates that the PCC allows instantiation 273 of the relative Alternate Marking feature by a PCE. If set to 1 274 by a PCE, the M flag indicates that the PCE supports the relative 275 Alternate Marking feature instantiation. The M flag MUST be set 276 by both PCC and PCE in order to support the Alternate Marking 277 feature instantiation 279 Unassigned bits are considered reserved. They MUST be set to 0 on 280 transmission and MUST be ignored on receipt. 282 Advertisement of the IFIT-CAPABILITY TLV implies support of IFIT 283 methods (IOAM and/or Alternate Marking) as well as the objects, TLVs, 284 and procedures defined in this document. It is worth mentioning that 285 IOAM and Alternate Marking can be activated one at a time or can 286 coexist; so it is possible to have only IOAM or only Alternate 287 Marking enabled but they are recognized in general as IFIT 288 capability. 290 The IFIT Capability Advertisement can imply the following cases: 292 o The PCEP protocol extensions for IFIT MUST NOT be used if one or 293 both PCEP speakers have not included the IFIT-CAPABILITY TLV in 294 their respective OPEN message. 296 o A PCEP speaker that does not recognize the extensions defined in 297 this document would simply ignore the TLVs as per RFC 5440 298 [RFC5440]. 300 o If a PCEP speaker supports the extensions defined in this document 301 but did not advertise this capability, then upon receipt of IFIT- 302 ATTRIBUTES TLV in the LSP Attributes (LSPA) object, it SHOULD 303 generate a PCErr with Error-Type 19 (Invalid Operation) with the 304 relative Error-value "IFIT capability not advertised" and ignore 305 the IFIT-ATTRIBUTES TLV. 307 4. IFIT Attributes TLV 309 The IFIT-ATTRIBUTES TLV provides the configurable knobs of the IFIT 310 feature, and it can be included as an optional TLV in the LSPA object 311 (as described in RFC 5440 [RFC5440]). 313 For a PCE-initiated LSP RFC 8281 [RFC8281], this TLV is included in 314 the LSPA object with the PCInitiate message. For the PCC-initiated 315 delegated LSPs, this TLV is carried in the Path Computation State 316 Report (PCRpt) message in the LSPA object. This TLV is also carried 317 in the LSPA object with the Path Computation Update Request (PCUpd) 318 message to direct the PCC (LSP head-end) to make updates to IFIT 319 attributes. 321 The TLV is encoded in all PCEP messages for the LSP if IFIT feature 322 is enabled. The absence of the TLV indicates the PCEP speaker wishes 323 to disable the feature. This TLV includes multiple IFIT-ATTRIBUTES 324 sub-TLVs. The IFIT-ATTRIBUTES sub-TLVs are included if there is a 325 change since the last information sent in the PCEP message. The 326 default values for missing sub-TLVs apply for the first PCEP message 327 for the LSP. 329 The format of the IFIT-ATTRIBUTES TLV is shown in the following 330 figure: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type | Length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 // sub-TLVs // 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Fig. 2 IFIT-ATTRIBUTES TLV Format 344 Where: 346 Type: to be assigned by IANA. 348 Length: The Length field defines the length of the value portion in 349 bytes as per RFC 5440 [RFC5440]. 351 Value: This comprises one or more sub-TLVs. 353 The following sub-TLVs are defined in this document: 355 Type Len Name 356 ----------------------------------------------------- 357 1 8 IOAM Pre-allocated Trace Option 359 2 8 IOAM Incremental Trace Option 361 3 12 IOAM Directly Export Option 363 4 4 IOAM Edge-to-Edge Option 365 5 4 Enhanced Alternate Marking 367 Fig. 3 Sub-TLV Types of the IFIT-ATTRIBUTES TLV 369 4.1. IOAM Sub-TLVs 371 In-situ Operations, Administration, and Maintenance (IOAM) 372 [I-D.ietf-ippm-ioam-data] records operational and telemetry 373 information in the packet while the packet traverses a path between 374 two points in the network. In terms of the classification given in 375 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 376 mechanisms can be leveraged where active OAM do not apply or do not 377 offer the desired results. 379 For the SR use case, when SR policy enables IOAM, the IOAM header 380 will be inserted into every packet of the traffic that is steered 381 into the SR paths. Since this document aims to define the control 382 plane, it is to be noted that a relevant document for the data plane 383 is [I-D.ietf-ippm-ioam-ipv6-options] for Segment Routing over IPv6 384 data plane (SRv6). 386 4.1.1. IOAM Pre-allocated Trace Option Sub-TLV 388 The IOAM tracing data is expected to be collected at every node that 389 a packet traverses to ensure visibility into the entire path a packet 390 takes within an IOAM domain. The preallocated tracing option will 391 create pre-allocated space for each node to populate its information. 393 The format of IOAM pre-allocated trace option Sub-TLV is defined as 394 follows: 396 0 1 2 3 397 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 398 +-------------------------------+-------------------------------+ 399 | Type=1 | Length=8 | 400 +---------------------------------------------------------------+ 401 | Namespace ID | Rsvd1 | 402 +-------------------------------+-----------------------+-------+ 403 | IOAM Trace Type | Flags | Rsvd2 | 404 +----------------------------------------------+--------+-------+ 406 Fig. 4 IOAM Pre-allocated Trace Option Sub-TLV 408 Where: 410 Type: 1 (to be assigned by IANA). 412 Length: 8. It is the total length of the value field not including 413 Type and Length fields. 415 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 416 definition is the same as described in section 4.4 of 417 [I-D.ietf-ippm-ioam-data]. 419 IOAM Trace Type: A 24-bit identifier which specifies which data types 420 are used in the node data list. The definition is the same as 421 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 423 Flags: A 4-bit field. The definition is the same as described in 424 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 425 [I-D.ietf-ippm-ioam-data]. 427 Rsvd1: A 16-bit field reserved for further usage. It MUST be zero 428 and ignored on receipt. 430 Rsvd2: A 4-bit field reserved for further usage. It MUST be zero and 431 ignored on receipt. 433 4.1.2. IOAM Incremental Trace Option Sub-TLV 435 The incremental tracing option contains a variable node data fields 436 where each node allocates and pushes its node data immediately 437 following the option header. 439 The format of IOAM incremental trace option Sub-TLV is defined as 440 follows: 442 0 1 2 3 443 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 444 +-------------------------------+-------------------------------+ 445 | Type=2 | Length=8 | 446 +---------------------------------------------------------------+ 447 | Namespace ID | Rsvd1 | 448 +-------------------------------+-----------------------+-------+ 449 | IOAM Trace Type | Flags | Rsvd2 | 450 +----------------------------------------------+--------+-------+ 452 Fig. 5 IOAM Incremental Trace Option Sub-TLV 454 Where: 456 Type: 2 (to be assigned by IANA). 458 Length: 8. It is the total length of the value field not including 459 Type and Length fields. 461 All the other fields definition is the same as the pre-allocated 462 trace option Sub-TLV in the previous section. 464 4.1.3. IOAM Directly Export Option Sub-TLV 466 IOAM directly export option is used as a trigger for IOAM data to be 467 directly exported to a collector without being pushed into in-flight 468 data packets. 470 The format of IOAM directly export option Sub-TLV is defined as 471 follows: 473 0 1 2 3 474 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 475 +-------------------------------+-------------------------------+ 476 | Type=3 | Length=12 | 477 +---------------------------------------------------------------+ 478 | Namespace ID | Flags | 479 +-------------------------------+---------------+---------------+ 480 | IOAM Trace Type | Rsvd | 481 +-----------------------------------------------+---------------+ 482 | Flow ID | 483 +---------------------------------------------------------------+ 485 Fig. 6 IOAM Directly Export Option Sub-TLV 487 Where: 489 Type: 3 (to be assigned by IANA). 491 Length: 12. It is the total length of the value field not including 492 Type and Length fields. 494 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 495 definition is the same as described in section 4.4 of 496 [I-D.ietf-ippm-ioam-data]. 498 IOAM Trace Type: A 24-bit identifier which specifies which data types 499 are used in the node data list. The definition is the same as 500 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 502 Flags: A 16-bit field. The definition is the same as described in 503 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 505 Flow ID: A 32-bit flow identifier. The definition is the same as 506 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 508 Rsvd: A 4-bit field reserved for further usage. It MUST be zero and 509 ignored on receipt. 511 4.1.4. IOAM Edge-to-Edge Option Sub-TLV 513 The IOAM edge to edge option is to carry data that is added by the 514 IOAM encapsulating node and interpreted by IOAM decapsulating node. 516 The format of IOAM edge-to-edge option Sub-TLV is defined as follows: 518 0 1 2 3 519 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 520 +-------------------------------+-------------------------------+ 521 | Type=4 | Length=4 | 522 +---------------------------------------------------------------+ 523 | Namespace ID | IOAM E2E Type | 524 +-------------------------------+-------------------------------+ 526 Fig. 7 IOAM Edge-to-Edge Option Sub-TLV 528 Where: 530 Type: 4 (to be assigned by IANA). 532 Length: 4. It is the total length of the value field not including 533 Type and Length fields. 535 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 536 definition is the same as described in section 4.6 of 537 [I-D.ietf-ippm-ioam-data]. 539 IOAM E2E Type: A 16-bit identifier which specifies which data types 540 are used in the E2E option data. The definition is the same as 541 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 543 4.2. Enhanced Alternate Marking Sub-TLV 545 The Alternate Marking [RFC8321]technique is an hybrid performance 546 measurement method, per RFC 7799 [RFC7799] classification of 547 measurement methods. Because this method is based on marking 548 consecutive batches of packets. It can be used to measure packet 549 loss, latency, and jitter on live traffic. 551 For the SR use case, since this document aims to define the control 552 plane, it is to be noted that a relevant document for the data plane 553 is [I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data 554 plane (SRv6). 556 The format of Enhanced Alternate Marking (EAM) Sub-TLV is defined as 557 follows: 559 0 1 2 3 560 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 561 +-------------------------------+-------------------------------+ 562 | Type=5 | Length=4 | 563 +-------------------------------+-------+---------------+-------+ 564 | FlowMonID | Period | Flags | 565 +---------------------------------------+---------------+-------+ 567 Fig. 8 Enhanced Alternate Marking Sub-TLV 569 Where: 571 Type: 5 (to be assigned by IANA). 573 Length: 4. It is the total length of the value field not including 574 Type and Length fields. 576 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 577 within the measurement domain. The definition is the same as 578 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. It is to 579 be noted that PCE also needs to maintain the uniqueness of FlowMonID 580 as described in [I-D.ietf-6man-ipv6-alt-mark]. 582 Period: Time interval between two alternate marking period. The unit 583 is second. 585 Flags: A 4-bits field. Two flags are currently assigned: 587 H: A flag indicating that the measurement is Hop-By-Hop. 589 E: A flag indicating that the measurement is End-to-End. 591 Unassigned bits MUST be set to zero on transmission and ignored on 592 receipt. 594 5. PCEP Messages 596 5.1. The PCInitiate Message 598 A PCInitiate message is a PCEP message sent by a PCE to a PCC to 599 trigger LSP instantiation or deletion RFC 8281 [RFC8281]. 601 For the PCE-initiated LSP with the IFIT feature enabled, IFIT- 602 ATTRIBUTES TLV MUST be included in the LSPA object with the 603 PCInitiate message. 605 The Routing Backus-Naur Form (RBNF) definition of the PCInitiate 606 message RFC 8281 [RFC8281] is unchanged by this document. 608 5.2. The PCUpd Message 610 A PCUpd message is a PCEP message sent by a PCE to a PCC to update 611 the LSP parameters RFC 8231 [RFC8231]. 613 For PCE-initiated LSPs with the IFIT feature enabled, the IFIT- 614 ATTRIBUTES TLV MUST be included in the LSPA object with the PCUpd 615 message. The PCE can send this TLV to direct the PCC to change the 616 IFIT parameters. 618 The RBNF definition of the PCUpd message RFC 8231 [RFC8231] is 619 unchanged by this document. 621 5.3. The PCRpt Message 623 The PCRpt message RFC 8231 [RFC8231] is a PCEP message sent by a PCC 624 to a PCE to report the status of one or more LSPs. 626 For PCE-initiated LSPs RFC 8281 [RFC8281], the PCC creates the LSP 627 using the attributes communicated by the PCE and the local values for 628 the unspecified parameters. After the successful instantiation of 629 the LSP, the PCC automatically delegates the LSP to the PCE and 630 generates a PCRpt message to provide the status report for the LSP. 632 The RBNF definition of the PCRpt message RFC 8231 [RFC8231] is 633 unchanged by this document. 635 For both PCE-initiated and PCC-initiated LSPs, when the LSP is 636 instantiated the IFIT methods are applied as specified for the 637 corresponding data plane. [I-D.ietf-ippm-ioam-ipv6-options] and 638 [I-D.ietf-6man-ipv6-alt-mark] are the relevant documents for Segment 639 Routing over IPv6 data plane (SRv6). 641 6. Example of application to SR Policy 643 A PCC or PCE sets the IFIT-CAPABILITY TLV in the Open message during 644 the PCEP initialization phase to indicate that it supports the IFIT 645 procedures. 647 [I-D.ietf-pce-segment-routing-policy-cp] defines the PCEP extension 648 to support Segment Routing Policy Candidate Paths and in this regard 649 the SRPAG Association object is introduced. 651 The Examples of PCC Initiated SR Policy with single or multiple 652 candidate-paths and PCE Initiated SR Policy with single or multiple 653 candidate-paths are reported in 654 [I-D.ietf-pce-segment-routing-policy-cp]. 656 In case of PCC Initiated SR Policy, PCC sends PCReq message to the 657 PCE, encoding the SRPAG ASSOCIATION object and IFIT-ATTRIBUTES TLV 658 via the LSPA object. This is valid for both single and multiple 659 candidate-paths. Finally PCE returns the path in PCRep message, and 660 echoes back the SRPAG object that were used in the computation and 661 IFIT LSPA TLVs too. Additionally, PCC sends PCRpt message to the 662 PCE, including the LSP object and the SRPAG ASSOCIATION object and 663 IFIT-ATTRIBUTES TLV via the LSPA object. Then PCE computes path and 664 finally PCE updates the SR policy candidate path's ERO using PCUpd 665 message considering the IFIT LSPA TLVs too. 667 In case of PCE Initiated SR Policy, PCE sends PCInitiate message, 668 containing the SRPAG Association object and IFIT-ATTRIBUTES TLV via 669 the LSPA object. This is valid for both single and multiple 670 candidate-paths. Then PCC uses the color, endpoint and preference 671 from the SRPAG object to create a new candidate path considering the 672 IFIT LSPA TLVs too. Finally PCC sends a PCRpt message back to the 673 PCE to report the newly created Candidate Path. The PCRpt message 674 contains the SRPAG Association object and IFIT-ATTRIBUTES 675 information. 677 The procedure of enabling/disabling IFIT is simple, indeed the PCE 678 can update the IFIT-ATTRIBUTES of the LSP by sending subsequent Path 679 Computation Update Request (PCUpd) messages. PCE can update the 680 IFIT-ATTRIBUTES of the LSP by sending Path Computation State Report 681 (PCRpt) messages. 683 7. IANA Considerations 685 This document defines the new IFIT-CAPABILITY TLV and IFIT-ATTRIBUTES 686 TLV. 688 7.1. PCEP TLV Type Indicators 690 IANA is requested to make the assignment from the "PCEP TLV Type 691 Indicators" subregistry of the "Path Computation Element Protocol 692 (PCEP) Numbers" registry as follows: 694 Value Description Reference 695 ------------------------------------------------------------- 696 TBD1 IFIT-CAPABILITY TLV This document 698 TBD2 IFIT-ATTRIBUTES TLV This document 700 7.2. IFIT-CAPABILITY TLV Flags field 702 This document specifies the IFIT-CAPABILITY TLV 32-bits Flags field. 703 IANA is requested to create a registry to manage the value of the 704 IFIT-CAPABILITY TLV's Flags field within the "Path Computation 705 Element Protocol (PCEP) Numbers" registry. 707 New values are to be assigned by Standards Action RFC 8126 [RFC8126]. 708 Each bit should be tracked with the following qualities: 710 * Bit number (count from 0 as the most significant bit) 712 * Flag Name 714 * Reference 716 IANA is requested to set 5 new bits in the IFIT-CAPABILITY TLV Flags 717 Field registry, as follows: 719 Bit no. Flag Name Reference 720 --------------------------------------------------------------------- 721 0-26 Unassigned This document 723 27 P: IOAM Pre-allocated Trace Option flag This document 725 28 I: IOAM Incremental Trace Option flag This document 727 29 D: IOAM Directly Export Option flag This document 729 30 E: IOAM Edge-to-Edge Option This document 731 31 M: Alternate Marking Flag This document 733 7.3. IFIT-ATTRIBUTES Sub-TLV 735 This document also specifies the IFIT-ATTRIBUTES sub-TLVs. IANA is 736 requested to create an "IFIT-ATTRIBUTES Sub-TLV Types" subregistry 737 within the "Path Computation Element Protocol (PCEP) Numbers" 738 registry. 740 IANA is requested to set the Registration Procedure for this registry 741 to read as follows: 743 Range Registration Procedure 744 ------------------------------------------ 745 0-65503 IETF Review 747 65504-65535 Experimental Use 749 This document defines the following types: 751 Type Description Reference 752 --------------------------------------------------------------- 753 0 Reserved This document 755 1 IOAM Pre-allocated Trace Option This document 757 2 IOAM Incremental Trace Option This document 759 3 IOAM Directly Export Option This document 761 4 IOAM Edge-to-Edge Option This document 763 5 Enhanced Alternate Marking This document 765 6-65503 Unassigned This document 767 65504-65535 Experimental Use This document 769 7.4. Enhanced Alternate Marking Sub-TLV Flags field 771 This document specifies the Enhanced Alternate Marking Sub-TLV 4-bits 772 Flags field. IANA is requested to create a registry to manage the 773 value of the Enhanced Alternate Marking Sub-TLV's Flags field within 774 the "Path Computation Element Protocol (PCEP) Numbers" registry. 776 New values are to be assigned by Standards Action RFC 8126 [RFC8126]. 777 Each bit should be tracked with the following qualities: 779 * Bit number (count from 0 as the most significant bit) 781 * Flag Name 783 * Reference 785 IANA is requested to set 2 new bits in the IFIT-CAPABILITY TLV Flags 786 Field registry, as follows: 788 Bit no. Flag Name Reference 789 --------------------------------------------------------------------- 790 3 H: Hop-By-Hop flag This document 792 2 E: End-to-End flag This document 794 0-1 Unassigned 796 7.5. PCEP Error Codes 798 This document defines a new Error-value for PCErr message of Error- 799 Type 19 (Invalid Operation). IANA is requested to allocate a new 800 Error-value within the "PCEP-ERROR Object Error Types and Values" 801 subregistry of the "Path Computation Element Protocol (PCEP) Numbers" 802 registry as follows: 804 Error-Type Meaning Error-value Reference 805 --------------------------------------------------------------- 806 19 Invalid TBD3: IFIT This document 807 Operation capability not 808 advertised 810 8. Security Considerations 812 This document defines the new IFIT-CAPABILITY TLV and IFIT Attributes 813 TLVs, which do not add any substantial new security concerns beyond 814 those already discussed in RFC 8231 [RFC8231] and RFC 8281 [RFC8281] 815 for stateful PCE operations. As per RFC 8231 [RFC8231], it is 816 RECOMMENDED that these PCEP extensions only be activated on 817 authenticated and encrypted sessions across PCEs and PCCs belonging 818 to the same administrative authority, using Transport Layer Security 819 (TLS) RFC 8253 [RFC8253], as per the recommendations and best current 820 practices in BCP 195 RFC 7525 [RFC7525] (unless explicitly set aside 821 in RFC 8253 [RFC8253]). 823 Implementation of IFIT methods (IOAM and Alternate Marking) are 824 mindful of security and privacy concerns, as explained in 825 [I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect 826 IFIT parameters in the IFIT-ATTRIBUTES sub-TLVs SHOULD NOT have an 827 adverse effect on the LSP as well as on the network, since it affects 828 only the operation of the telemetry methodology. 830 IFIT data MUST be propagated in a limited domain in order to avoid 831 malicious attacks and solutions to ensure this requirement are 832 respectively discussed in [I-D.ietf-ippm-ioam-data] and 833 [I-D.ietf-6man-ipv6-alt-mark]. 835 IFIT methods (IOAM and Alternate Marking) are applied within a 836 controlled domain where the network nodes are locally administered. 837 A limited administrative domain provides the network administrator 838 with the means to select, monitor and control the access to the 839 network, making it a trusted domain also for the PCEP extensions 840 defined in this document. 842 9. Contributors 844 The following people provided relevant contributions to this 845 document: 847 Huanan Chen, independent, - 849 Dhruv Doody, Huawei Technologies, dhruv.ietf@gmail.com 851 10. Acknowledgements 853 The authors of this document would like to thank Huaimo Chen for the 854 comments and review of this document. 856 11. References 858 11.1. Normative References 860 [I-D.ietf-6man-ipv6-alt-mark] 861 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 862 Pang, "IPv6 Application of the Alternate Marking Method", 863 draft-ietf-6man-ipv6-alt-mark-12 (work in progress), 864 October 2021. 866 [I-D.ietf-ippm-ioam-data] 867 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 868 for In-situ OAM", draft-ietf-ippm-ioam-data-17 (work in 869 progress), December 2021. 871 [I-D.ietf-ippm-ioam-direct-export] 872 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 873 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 874 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 875 export-07 (work in progress), October 2021. 877 [I-D.ietf-ippm-ioam-flags] 878 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 879 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 880 Lemon, "In-situ OAM Loopback and Active Flags", draft- 881 ietf-ippm-ioam-flags-07 (work in progress), October 2021. 883 [I-D.ietf-ippm-ioam-ipv6-options] 884 Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", 885 draft-ietf-ippm-ioam-ipv6-options-06 (work in progress), 886 July 2021. 888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, 890 DOI 10.17487/RFC2119, March 1997, 891 . 893 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 894 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 895 DOI 10.17487/RFC5440, March 2009, 896 . 898 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 899 "Recommendations for Secure Use of Transport Layer 900 Security (TLS) and Datagram Transport Layer Security 901 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 902 2015, . 904 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 905 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 906 May 2016, . 908 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 909 Writing an IANA Considerations Section in RFCs", BCP 26, 910 RFC 8126, DOI 10.17487/RFC8126, June 2017, 911 . 913 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 914 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 915 May 2017, . 917 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 918 Computation Element Communication Protocol (PCEP) 919 Extensions for Stateful PCE", RFC 8231, 920 DOI 10.17487/RFC8231, September 2017, 921 . 923 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 924 "PCEPS: Usage of TLS to Provide a Secure Transport for the 925 Path Computation Element Communication Protocol (PCEP)", 926 RFC 8253, DOI 10.17487/RFC8253, October 2017, 927 . 929 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 930 Computation Element Communication Protocol (PCEP) 931 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 932 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 933 . 935 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 936 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 937 "Alternate-Marking Method for Passive and Hybrid 938 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 939 January 2018, . 941 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 942 and J. Hardwick, "Path Computation Element Communication 943 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 944 DOI 10.17487/RFC8664, December 2019, 945 . 947 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 948 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 949 . 951 11.2. Informative References 953 [I-D.ietf-pce-segment-routing-ipv6] 954 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 955 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 956 Routing leveraging the IPv6 data plane", draft-ietf-pce- 957 segment-routing-ipv6-11 (work in progress), January 2022. 959 [I-D.ietf-pce-segment-routing-policy-cp] 960 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 961 Bidgoli, "PCEP extension to support Segment Routing Policy 962 Candidate Paths", draft-ietf-pce-segment-routing-policy- 963 cp-06 (work in progress), October 2021. 965 [I-D.ietf-spring-segment-routing-policy] 966 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 967 P. Mattes, "Segment Routing Policy Architecture", draft- 968 ietf-spring-segment-routing-policy-16 (work in progress), 969 January 2022. 971 [I-D.koldychev-pce-multipath] 972 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 973 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 974 Signaling Multipath Information", draft-koldychev-pce- 975 multipath-05 (work in progress), February 2021. 977 [I-D.qin-idr-sr-policy-ifit] 978 Qin, F., Yuan, H., Zhou, T., Fioccola, G., and Y. Wang, 979 "BGP SR Policy Extensions to Enable IFIT", draft-qin-idr- 980 sr-policy-ifit-04 (work in progress), October 2020. 982 Authors' Addresses 984 Hang Yuan 985 UnionPay 986 1899 Gu-Tang Rd., Pudong 987 Shanghai 988 China 990 Email: yuanhang@unionpay.com 992 Tianran Zhou 993 Huawei 994 156 Beiqing Rd., Haidian District 995 Beijing 996 China 998 Email: zhoutianran@huawei.com 1000 Weidong Li 1001 Huawei 1002 156 Beiqing Rd., Haidian District 1003 Beijing 1004 China 1006 Email: poly.li@huawei.com 1008 Giuseppe Fioccola 1009 Huawei 1010 Riesstrasse, 25 1011 Munich 1012 Germany 1014 Email: giuseppe.fioccola@huawei.com 1015 Yali Wang 1016 Huawei 1017 156 Beiqing Rd., Haidian District 1018 Beijing 1019 China 1021 Email: wangyali11@huawei.com