idnits 2.17.1 draft-chen-pce-pcep-ifit-02.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 == Line 755 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Implementation of IFIT methods (IOAM and Alternate Marking) are mindful of security and privacy concerns, as explained in [I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect IFIT parameters in the IFIT-ATTRIBUTES sub-TLVs SHOULD not have an adverse effect on the LSP as well as on the network, since it affects only the operation of the telemetry methodology. -- The document date (February 9, 2021) is 1166 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 (-17) exists of draft-ietf-6man-ipv6-alt-mark-02 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-02 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-03 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-04 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Downref: Normative reference to an Informational RFC: RFC 7799 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-08 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-05) exists of draft-koldychev-pce-multipath-04 Summary: 3 errors (**), 0 flaws (~~), 13 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: August 13, 2021 UnionPay 6 T. Zhou 7 W. Li 8 G. Fioccola 9 Y. Wang 10 Huawei 11 February 9, 2021 13 Path Computation Element Communication Protocol (PCEP) Extensions to 14 Enable IFIT 15 draft-chen-pce-pcep-ifit-02 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. This document extends 27 PCEP to carry the IFIT attributes under the stateful PCE model. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in in BCP 14 [RFC2119] 34 [RFC8174] when, and only when, they appear in all capitals, as shown 35 here. 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 August 13, 2021. 54 Copyright Notice 56 Copyright (c) 2021 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 . . . . . . . . . . . . . . 5 75 4. IFIT Attributes TLV . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. IOAM Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 8 77 4.1.1. IOAM Pre-allocated Trace Option Sub-TLV . . . . . . . 8 78 4.1.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . 9 79 4.1.3. IOAM Directly Export Option Sub-TLV . . . . . . . . . 10 80 4.1.4. IOAM Edge-to-Edge Option Sub-TLV . . . . . . . . . . 11 81 4.2. Enhanced Alternate Marking Sub-TLV . . . . . . . . . . . 12 82 5. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 13 83 5.1. The PCInitiate Message . . . . . . . . . . . . . . . . . 13 84 5.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 13 85 5.3. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 13 86 6. Example of application to SR Policy . . . . . . . . . . . . . 14 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 93 11.2. Informative References . . . . . . . . . . . . . . . . . 19 94 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 97 1. Introduction 99 In-situ Flow Information Telemetry (IFIT) refers to network OAM 100 (Operations, Administration, and Maintenance) data plane on-path 101 telemetry techniques, including In-situ OAM (IOAM) 102 [I-D.ietf-ippm-ioam-data] and Alternate Marking [RFC8321]. It can 103 provide flow information on the entire forwarding path on a per- 104 packet basis in real time. 106 An automatic network requires the Service Level Agreement (SLA) 107 monitoring on the deployed service. So that the system can quickly 108 detect the SLA violation or the performance degradation, hence to 109 change the service deployment. 111 This document defines extensions to PCEP to distribute paths carrying 112 IFIT information. So that IFIT behavior can be enabled automatically 113 when the path is instantiated. 115 RFC 5440 [RFC5440] describes the Path Computation Element Protocol 116 (PCEP) as a communication mechanism between a Path Computation Client 117 (PCC) and a Path Computation Element (PCE), or between a PCE and a 118 PCE. 120 RFC 8231 [RFC8231] specifies extensions to PCEP to enable stateful 121 control and it describes two modes of operation: passive stateful PCE 122 and active stateful PCE. Further, RFC 8281 [RFC8281] describes the 123 setup, maintenance, and teardown of PCE-initiated LSPs for the 124 stateful PCE model. 126 When a PCE is used to initiate paths using PCEP, it is important that 127 the head end of the path also understands the IFIT behavior that is 128 intended for the path. When PCEP is in use for path initiation it 129 makes sense for that same protocol to be used to also carry the IFIT 130 attributes that describe the IOAM or Alternate Marking procedure that 131 needs to be applied to the data that flow those paths. 133 The PCEP extension defined in this document allows to signal the IFIT 134 capabilities. In this way IFIT methods are automatically activated 135 and running. The flexibility and dynamicity of the IFIT applications 136 are given by the use of additional functions on the controller and on 137 the network nodes, but this is out of scope here. 139 The Use Case of Segment Routing (SR) is discussed considering that 140 IFIT methods are becoming mature for Segment Routing over the MPLS 141 data plane (SR-MPLS) and Segment Routing over IPv6 data plane (SRv6). 142 In this way SR policy native IFIT can facilitate the closed loop 143 control and enable the automation of SR service. 145 Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy] 146 is a set of candidate SR paths consisting of one or more segment 147 lists and necessary path attributes. It enables instantiation of an 148 ordered list of segments with a specific intent for traffic steering. 150 It is to be noted the companion document [I-D.qin-idr-sr-policy-ifit] 151 that proposes the BGP extension to enable IFIT methods for SR policy. 153 2. PCEP Extensions for IFIT Attributes 155 This document is to add IFIT attribute TLVs as PCEP Extensions. The 156 following sections will describe the requirement and usage of 157 different IFIT modes, and define the corresponding TLV encoding in 158 PCEP. 160 The IFIT attributes here described can be generalized and included as 161 TLVs carried inside the LSPA (LSP Attributes) object in order to be 162 applied for all path types, as long as they support the relevant data 163 plane telemetry method. IFIT Attributes TLVs are optional and can be 164 taken into account by the PCE during path computation and by the PCC 165 during path setup. In general, the LSPA object can be carried within 166 a PCInitiate message, a PCUpd message, or a PCRpt message in the 167 stateful PCE model. 169 In this document it is considered the case of SR Policy since IOAM 170 and Alternate Marking are more mature especially for Segment Routing 171 (SR) and for IPv6. 173 It is to be noted that, if it is needed to apply different IFIT 174 methods for each Segment List, the IFIT attributes can be added into 175 the PATH-ATTRIB object, instead of the LSPA object, according to 176 [I-D.koldychev-pce-multipath] that defines PCEP Extensions for 177 Signaling Multipath Information. 179 2.1. IFIT for SR Policies 181 RFC 8664 [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6] specify 182 extensions to the Path Computation Element Communication Protocol 183 (PCEP) that allow a stateful PCE to compute and initiate Traffic- 184 Engineering (TE) paths, as well as a Path Computation Client (PCC) to 185 request a path subject to certain constraints and optimization 186 criteria in SR networks both for SR-MPLS and SRv6. 188 IFIT attibutes, here defined as TLVs for the LSPA object, complement 189 both RFC 8664 [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 190 [I-D.ietf-pce-segment-routing-policy-cp]. 192 3. IFIT capability advertisement TLV 194 During the PCEP initialization phase, PCEP speakers (PCE or PCC) 195 SHOULD advertise their support of IFIT methods (e.g. IOAM and 196 Alternate Marking). 198 A PCEP speaker includes the IFIT-CAPABILITY TLVs in the OPEN object 199 to advertise its support for PCEP IFIT extensions. The presence of 200 the IFIT-CAPABILITY TLV in the OPEN object indicates that the IFIT 201 methods are supported. 203 RFC 8664 [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6] define a 204 new Path Setup Type (PST) for SR and also define the SR-PCE- 205 CAPABILITY sub-TLV. This document defined a new IFIT-CAPABILITY TLV, 206 that is an optional TLV for use in the OPEN Object for IFIT 207 attributes via PCEP capability advertisement. 209 0 1 2 3 210 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type | Length=4 | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Flags |P|I|D|E|M| 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Fig. 1 IFIT-CAPABILITY TLV Format 219 Where: 221 Type: to be assigned by IANA. 223 Length: 4. 225 Flags: The following flags are defined in this document: 227 P: IOAM Pre-allocated Trace Option Type-enabled flag 228 [I-D.ietf-ippm-ioam-data]. If set to 1 by a PCC, the P flag 229 indicates that the PCC allows instantiation of the IOAM Pre- 230 allocated Trace feature by a PCE. If set to 1 by a PCE, the P 231 flag indicates that the PCE supports the IOAM Pre-allocated Trace 232 feature instantiation. The P flag MUST be set by both PCC and PCE 233 in order to support the IOAM Pre-allocated Trace instantiation 235 I: IOAM Incremental Trace Option Type-enabled flag 236 [I-D.ietf-ippm-ioam-data]. If set to 1 by a PCC, the I flag 237 indicates that the PCC allows instantiation of the IOAM 238 Incremental Trace feature by a PCE. If set to 1 by a PCE, the I 239 flag indicates that the PCE supports the relative IOAM Incremental 240 Trace feature instantiation. The I flag MUST be set by both PCC 241 and PCE in order to support the IOAM Incremental Trace feature 242 instantiation 244 D: IOAM DEX Option Type-enabled flag 245 [I-D.ietf-ippm-ioam-direct-export]. If set to 1 by a PCC, the D 246 flag indicates that the PCC allows instantiation of the relative 247 IOAM DEX feature by a PCE. If set to 1 by a PCE, the D flag 248 indicates that the PCE supports the relative IOAM DEX feature 249 instantiation. The D flag MUST be set by both PCC and PCE in 250 order to support the IOAM DEX feature instantiation 252 E: IOAM E2E Option Type-enabled flag [I-D.ietf-ippm-ioam-data]. 253 If set to 1 by a PCC, the E flag indicates that the PCC allows 254 instantiation of the relative IOAM E2E feature by a PCE. If set 255 to 1 by a PCE, the E flag indicates that the PCE supports the 256 relative IOAM E2E feature instantiation. The E flag MUST be set 257 by both PCC and PCE in order to support the IOAM E2E feature 258 instantiation 260 M: Alternate Marking enabled flag RFC 8321 [RFC8321]. If set to 1 261 by a PCC, the M flag indicates that the PCC allows instantiation 262 of the relative Alternate Marking feature by a PCE. If set to 1 263 by a PCE, the M flag indicates that the PCE supports the relative 264 Alternate Marking feature instantiation. The M flag MUST be set 265 by both PCC and PCE in order to support the Alternate Marking 266 feature instantiation 268 Unassigned bits are considered reserved. They MUST be set to 0 on 269 transmission and MUST be ignored on receipt. 271 Advertisement of the IFIT-CAPABILITY TLV implies support of IFIT 272 methods (IOAM and/or Alternate Marking) as well as the objects, TLVs, 273 and procedures defined in this document. It is worth mentioning that 274 IOAM and Alternate Marking can be activated one at a time or can 275 coexist; so it is possible to have only IOAM or only Alternate 276 Marking enabled but they are recognized in general as IFIT 277 capability. 279 The IFIT Capability Advertisement can imply the following cases: 281 o The PCEP protocol extensions for IFIT MUST NOT be used if one or 282 both PCEP speakers have not included the IFIT-CAPABILITY TLV in 283 their respective OPEN message. 285 o A PCEP speaker that does not recognize the extensions defined in 286 this document would simply ignore the TLVs as per RFC 5440 287 [RFC5440]. 289 o If a PCEP speaker supports the extensions defined in this document 290 but did not advertise this capability, then upon receipt of IFIT- 291 ATTRIBUTES TLV in the LSP Attributes (LSPA) object, it SHOULD 292 generate a PCErr with Error-Type 19 (Invalid Operation) with the 293 relative Error-value "IFIT capability not advertised" and ignore 294 the IFIT-ATTRIBUTES TLV. 296 4. IFIT Attributes TLV 298 The IFIT-ATTRIBUTES TLV provides the configurable knobs of the IFIT 299 feature, and it can be included as an optional TLV in the LSPA object 300 (as described in RFC 5440 [RFC5440]). 302 For a PCE-initiated LSP RFC 8281 [RFC8281], this TLV is included in 303 the LSPA object with the PCInitiate message. For the PCC-initiated 304 delegated LSPs, this TLV is carried in the Path Computation State 305 Report (PCRpt) message in the LSPA object. This TLV is also carried 306 in the LSPA object with the Path Computation Update Request (PCUpd) 307 message to direct the PCC (LSP head-end) to make updates to IFIT 308 attributes. 310 The TLV is encoded in all PCEP messages for the LSP if IFIT feature 311 is enabled. The absence of the TLV indicates the PCEP speaker wishes 312 to disable the feature. This TLV includes multiple IFIT-ATTRIBUTES 313 sub-TLVs. The IFIT-ATTRIBUTES sub-TLVs are included if there is a 314 change since the last information sent in the PCEP message. The 315 default values for missing sub-TLVs apply for the first PCEP message 316 for the LSP. 318 The format of the IFIT-ATTRIBUTES TLV is shown in the following 319 figure: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 // sub-TLVs // 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Fig. 2 IFIT-ATTRIBUTES TLV Format 333 Where: 335 Type: to be assigned by IANA. 337 Length: The Length field defines the length of the value portion in 338 bytes as per RFC 5440 [RFC5440]. 340 Value: This comprises one or more sub-TLVs. 342 The following sub-TLVs are defined in this document: 344 Type Len Name 345 ----------------------------------------------------- 346 1 8 IOAM Pre-allocated Trace Option 348 2 8 IOAM Incremental Trace Option 350 3 12 IOAM Directly Export Option 352 4 4 IOAM Edge-to-Edge Option 354 5 4 Enhanced Alternate Marking 356 Fig. 3 Sub-TLV Types of the IFIT-ATTRIBUTES TLV 358 4.1. IOAM Sub-TLVs 360 In-situ Operations, Administration, and Maintenance (IOAM) 361 [I-D.ietf-ippm-ioam-data] records operational and telemetry 362 information in the packet while the packet traverses a path between 363 two points in the network. In terms of the classification given in 364 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 365 mechanisms can be leveraged where active OAM do not apply or do not 366 offer the desired results. 368 For the SR use case, when SR policy enables IOAM, the IOAM header 369 will be inserted into every packet of the traffic that is steered 370 into the SR paths. Since this document aims to define the control 371 plane, it is to be noted that a relevant document for the data plane 372 is [I-D.ietf-ippm-ioam-ipv6-options] for Segment Routing over IPv6 373 data plane (SRv6). 375 4.1.1. IOAM Pre-allocated Trace Option Sub-TLV 377 The IOAM tracing data is expected to be collected at every node that 378 a packet traverses to ensure visibility into the entire path a packet 379 takes within an IOAM domain. The preallocated tracing option will 380 create pre-allocated space for each node to populate its information. 382 The format of IOAM pre-allocated trace option Sub-TLV is defined as 383 follows: 385 0 1 2 3 386 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 387 +-------------------------------+-------------------------------+ 388 | Type=1 | Length=8 | 389 +---------------------------------------------------------------+ 390 | Namespace ID | Rsvd1 | 391 +-------------------------------+-----------------------+-------+ 392 | IOAM Trace Type | Flags | Rsvd2 | 393 +----------------------------------------------+--------+-------+ 395 Fig. 4 IOAM Pre-allocated Trace Option Sub-TLV 397 Where: 399 Type: 1 (to be assigned by IANA). 401 Length: 8. It is the total length of the value field not including 402 Type and Length fields. 404 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 405 definition is the same as described in section 4.4 of 406 [I-D.ietf-ippm-ioam-data]. 408 IOAM Trace Type: A 24-bit identifier which specifies which data types 409 are used in the node data list. The definition is the same as 410 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 412 Flags: A 4-bit field. The definition is the same as described in 413 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 414 [I-D.ietf-ippm-ioam-data]. 416 Rsvd1: A 16-bit field reserved for further usage. It MUST be zero 417 and ignored on receipt. 419 Rsvd2: A 4-bit field reserved for further usage. It MUST be zero and 420 ignored on receipt. 422 4.1.2. IOAM Incremental Trace Option Sub-TLV 424 The incremental tracing option contains a variable node data fields 425 where each node allocates and pushes its node data immediately 426 following the option header. 428 The format of IOAM incremental trace option Sub-TLV is defined as 429 follows: 431 0 1 2 3 432 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 433 +-------------------------------+-------------------------------+ 434 | Type=2 | Length=8 | 435 +---------------------------------------------------------------+ 436 | Namespace ID | Rsvd1 | 437 +-------------------------------+-----------------------+-------+ 438 | IOAM Trace Type | Flags | Rsvd2 | 439 +----------------------------------------------+--------+-------+ 441 Fig. 5 IOAM Incremental Trace Option Sub-TLV 443 Where: 445 Type: 2 (to be assigned by IANA). 447 Length: 8. It is the total length of the value field not including 448 Type and Length fields. 450 All the other fields definition is the same as the pre-allocated 451 trace option Sub-TLV in the previous section. 453 4.1.3. IOAM Directly Export Option Sub-TLV 455 IOAM directly export option is used as a trigger for IOAM data to be 456 directly exported to a collector without being pushed into in-flight 457 data packets. 459 The format of IOAM directly export option Sub-TLV is defined as 460 follows: 462 0 1 2 3 463 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 464 +-------------------------------+-------------------------------+ 465 | Type=3 | Length=12 | 466 +---------------------------------------------------------------+ 467 | Namespace ID | Flags | 468 +-------------------------------+---------------+---------------+ 469 | IOAM Trace Type | Rsvd | 470 +-----------------------------------------------+---------------+ 471 | Flow ID | 472 +---------------------------------------------------------------+ 474 Fig. 6 IOAM Directly Export Option Sub-TLV 476 Where: 478 Type: 3 (to be assigned by IANA). 480 Length: 12. It is the total length of the value field not including 481 Type and Length fields. 483 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 484 definition is the same as described in section 4.4 of 485 [I-D.ietf-ippm-ioam-data]. 487 IOAM Trace Type: A 24-bit identifier which specifies which data types 488 are used in the node data list. The definition is the same as 489 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 491 Flags: A 16-bit field. The definition is the same as described in 492 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 494 Flow ID: A 32-bit flow identifier. The definition is the same as 495 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 497 Rsvd: A 4-bit field reserved for further usage. It MUST be zero and 498 ignored on receipt. 500 4.1.4. IOAM Edge-to-Edge Option Sub-TLV 502 The IOAM edge to edge option is to carry data that is added by the 503 IOAM encapsulating node and interpreted by IOAM decapsulating node. 505 The format of IOAM edge-to-edge option Sub-TLV is defined as follows: 507 0 1 2 3 508 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 509 +-------------------------------+-------------------------------+ 510 | Type=4 | Length=4 | 511 +---------------------------------------------------------------+ 512 | Namespace ID | IOAM E2E Type | 513 +-------------------------------+-------------------------------+ 515 Fig. 7 IOAM Edge-to-Edge Option Sub-TLV 517 Where: 519 Type: 4 (to be assigned by IANA). 521 Length: 4. It is the total length of the value field not including 522 Type and Length fields. 524 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 525 definition is the same as described in section 4.6 of 526 [I-D.ietf-ippm-ioam-data]. 528 IOAM E2E Type: A 16-bit identifier which specifies which data types 529 are used in the E2E option data. The definition is the same as 530 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 532 4.2. Enhanced Alternate Marking Sub-TLV 534 The Alternate Marking [RFC8321]technique is an hybrid performance 535 measurement method, per RFC 7799 [RFC7799] classification of 536 measurement methods. Because this method is based on marking 537 consecutive batches of packets. It can be used to measure packet 538 loss, latency, and jitter on live traffic. 540 For the SR use case, since this document aims to define the control 541 plane, it is to be noted that a relevant document for the data plane 542 is [I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data 543 plane (SRv6). 545 The format of Enhanced Alternate Marking (EAM) Sub-TLV is defined as 546 follows: 548 0 1 2 3 549 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 550 +-------------------------------+-------------------------------+ 551 | Type=5 | Length=4 | 552 +-------------------------------+-------+---------------+-------+ 553 | FlowMonID | Period |H|E| R | 554 +---------------------------------------+---------------+-------+ 556 Fig. 8 Enhanced Alternate Marking Sub-TLV 558 Where: 560 Type: 5 (to be assigned by IANA). 562 Length: 4. It is the total length of the value field not including 563 Type and Length fields. 565 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 566 within the measurement domain. The definition is the same as 567 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. It is to 568 be noted that PCE also needs to maintain the uniqueness of FlowMonID 569 as described in [I-D.ietf-6man-ipv6-alt-mark]. 571 Period: Time interval between two alternate marking period. The unit 572 is second. 574 H: A flag indicating that the measurement is Hop-By-Hop. 576 E: A flag indicating that the measurement is end to end. 578 R: A 2-bit field reserved for further usage. It MUST be zero and 579 ignored on receipt. 581 5. PCEP Messages 583 5.1. The PCInitiate Message 585 A PCInitiate message is a PCEP message sent by a PCE to a PCC to 586 trigger LSP instantiation or deletion RFC 8281 [RFC8281]. 588 For the PCE-initiated LSP with the IFIT feature enabled, IFIT- 589 ATTRIBUTES TLV MUST be included in the LSPA object with the 590 PCInitiate message. 592 The Routing Backus-Naur Form (RBNF) definition of the PCInitiate 593 message RFC 8281 [RFC8281] is unchanged by this document. 595 5.2. The PCUpd Message 597 A PCUpd message is a PCEP message sent by a PCE to a PCC to update 598 the LSP parameters RFC 8231 [RFC8231]. 600 For PCE-initiated LSPs with the IFIT feature enabled, the IFIT- 601 ATTRIBUTES TLV MUST be included in the LSPA object with the PCUpd 602 message. The PCE can send this TLV to direct the PCC to change the 603 IFIT parameters. 605 The RBNF definition of the PCUpd message RFC 8231 [RFC8231] is 606 unchanged by this document. 608 5.3. The PCRpt Message 610 The PCRpt message RFC 8231 [RFC8231] is a PCEP message sent by a PCC 611 to a PCE to report the status of one or more LSPs. 613 For PCE-initiated LSPs RFC 8281 [RFC8281], the PCC creates the LSP 614 using the attributes communicated by the PCE and the local values for 615 the unspecified parameters. After the successful instantiation of 616 the LSP, the PCC automatically delegates the LSP to the PCE and 617 generates a PCRpt message to provide the status report for the LSP. 619 The RBNF definition of the PCRpt message RFC 8231 [RFC8231] is 620 unchanged by this document. 622 For both PCE-initiated and PCC-initiated LSPs, when the LSP is 623 instantiated the IFIT methods are applied as specified for the 624 corresponding data plane. [I-D.ietf-ippm-ioam-ipv6-options] and 625 [I-D.ietf-6man-ipv6-alt-mark] are the relevant documents for Segment 626 Routing over IPv6 data plane (SRv6). 628 6. Example of application to SR Policy 630 A PCC or PCE sets the IFIT-CAPABILITY TLV in the Open message during 631 the PCEP initialization phase to indicate that it supports the IFIT 632 procedures. 634 [I-D.ietf-pce-segment-routing-policy-cp] defines the PCEP extension 635 to support Segment Routing Policy Candidate Paths and in this regard 636 the SRPAG Association object is introduced. 638 The Examples of PCC Initiated SR Policy with single or multiple 639 candidate-paths and PCE Initiated SR Policy with single or multiple 640 candidate-paths are reported in 641 [I-D.ietf-pce-segment-routing-policy-cp]. 643 In case of PCC Initiated SR Policy, PCC sends PCReq message to the 644 PCE, encoding the SRPAG ASSOCIATION object and IFIT-ATTRIBUTES TLV 645 via the LSPA object. This is valid for both single and multiple 646 candidate-paths. Finally PCE returns the path in PCRep message, and 647 echoes back the SRPAG object that were used in the computation and 648 IFIT LSPA TLVs too. Additionally, PCC sends PCRpt message to the 649 PCE, including the LSP object and the SRPAG ASSOCIATION object and 650 IFIT-ATTRIBUTES TLV via the LSPA object. Then PCE computes path and 651 finally PCE updates the SR policy candidate path's ERO using PCUpd 652 message considering the IFIT LSPA TLVs too. 654 In case of PCE Initiated SR Policy, PCE sends PCInitiate message, 655 containing the SRPAG Association object and IFIT-ATTRIBUTES TLV via 656 the LSPA object. This is valid for both single and multiple 657 candidate-paths. Then PCC uses the color, endpoint and preference 658 from the SRPAG object to create a new candidate path considering the 659 IFIT LSPA TLVs too. Finally PCC sends a PCRpt message back to the 660 PCE to report the newly created Candidate Path. The PCRpt message 661 contains the SRPAG Association object and IFIT-ATTRIBUTES 662 information. 664 The procedure of enabling/disabling IFIT is simple, indeed the PCE 665 can update the IFIT-ATTRIBUTES of the LSP by sending subsequent Path 666 Computation Update Request (PCUpd) messages. PCE can update the 667 IFIT-ATTRIBUTES of the LSP by sending Path Computation State Report 668 (PCRpt) messages. 670 7. IANA Considerations 672 This document defines the new IFIT-CAPABILITY TLV and IFIT-ATTRIBUTES 673 TLV. IANA is requested to make the assignment from the "PCEP TLV 674 Type Indicators" subregistry of the "Path Computation Element 675 Protocol (PCEP) Numbers" registry as follows: 677 Value Description Reference 678 ------------------------------------------------------------- 679 TBD1 IFIT-CAPABILITY This document 681 TBD2 IFIT-ATTRIBUTES This document 683 This document specifies the IFIT-CAPABILITY TLV Flags field. IANA is 684 requested to create a registry to manage the value of the IFIT- 685 CAPABILITY TLV's Flags field within the "Path Computation Element 686 Protocol (PCEP) Numbers" registry. 688 New values are to be assigned by Standards Action RFC 8126 [RFC8126]. 689 Each bit should be tracked with the following qualities: 691 * Bit number (count from 0 as the most significant bit) 693 * Flag Name 695 * Reference 697 IANA is requested to set 5 new bits in the IFIT-CAPABILITY TLV Flags 698 Field registry, as follows: 700 Bit no. Flag Name Reference 701 --------------------------------------------------------------------- 702 27 P: IOAM Pre-allocated Trace Option flag This document 704 28 I: IOAM Incremental Trace Option flag This document 706 29 D: IOAM Directly Export Option flag This document 708 30 E: IOAM Edge-to-Edge Option This document 710 31 M: Alternate Marking Flag This document 712 This document also specifies the IFIT-ATTRIBUTES sub-TLVs. IANA is 713 requested to create an "IFIT-ATTRIBUTES Sub-TLV Types" subregistry 714 within the "Path Computation Element Protocol (PCEP) Numbers" 715 registry. 717 IANA is requested to set the Registration Procedure for this registry 718 to read as follows: 720 Range Registration Procedure 721 ------------------------------------------ 722 0-65503 IETF Review 724 65504-65535 Experimental Use 726 This document defines the following types: 728 Type Description Reference 729 --------------------------------------------------------------- 730 0 Reserved This document 732 1 IOAM Pre-allocated Trace Option This document 734 2 IOAM Incremental Trace Option This document 736 3 IOAM Directly Export Option This document 738 4 IOAM Edge-to-Edge Option This document 740 5 Enhanced Alternate Marking This document 742 6-65503 Unassigned This document 744 65504-65535 Experimental Use This document 746 This document defines a new Error-value for PCErr message of Error- 747 Type 19 (Invalid Operation). IANA is requested to allocate a new 748 Error-value within the "PCEP-ERROR Object Error Types and Values" 749 subregistry of the "Path Computation Element Protocol (PCEP) Numbers" 750 registry as follows: 752 Error-Type Meaning Error-value Reference 753 --------------------------------------------------------------- 754 19 Invalid TBD3: IFIT This document 755 Operation capability not 756 advertised 758 8. Security Considerations 760 This document defines the new IFIT-CAPABILITY TLV and IFIT Attributes 761 TLVs, which do not add any substantial new security concerns beyond 762 those already discussed in RFC 8231 [RFC8231] and RFC 8281 [RFC8281] 763 for stateful PCE operations. As per RFC 8231 [RFC8231], it is 764 RECOMMENDED that these PCEP extensions only be activated on 765 authenticated and encrypted sessions across PCEs and PCCs belonging 766 to the same administrative authority, using Transport Layer Security 767 (TLS) RFC 8253 [RFC8253], as per the recommendations and best current 768 practices in BCP 195 RFC 7525 [RFC7525] (unless explicitly set aside 769 in RFC 8253 [RFC8253]). 771 Implementation of IFIT methods (IOAM and Alternate Marking) are 772 mindful of security and privacy concerns, as explained in 773 [I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect 774 IFIT parameters in the IFIT-ATTRIBUTES sub-TLVs SHOULD not have an 775 adverse effect on the LSP as well as on the network, since it affects 776 only the operation of the telemetry methodology. 778 9. Contributors 780 The following people provided relevant contributions to this 781 document: 783 Dhruv Doody, Huawei Technologies, dhruv.ietf@gmail.com 785 10. Acknowledgements 787 The authors of this document would like to thank Huaimo Chen for the 788 comments and review of this document. 790 11. References 792 11.1. Normative References 794 [I-D.ietf-6man-ipv6-alt-mark] 795 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 796 Pang, "IPv6 Application of the Alternate Marking Method", 797 draft-ietf-6man-ipv6-alt-mark-02 (work in progress), 798 October 2020. 800 [I-D.ietf-ippm-ioam-data] 801 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 802 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 803 progress), November 2020. 805 [I-D.ietf-ippm-ioam-direct-export] 806 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 807 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 808 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 809 export-02 (work in progress), November 2020. 811 [I-D.ietf-ippm-ioam-flags] 812 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 813 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 814 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-03 815 (work in progress), October 2020. 817 [I-D.ietf-ippm-ioam-ipv6-options] 818 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 819 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 820 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 821 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 822 ipv6-options-04 (work in progress), November 2020. 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, 826 DOI 10.17487/RFC2119, March 1997, 827 . 829 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 830 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 831 DOI 10.17487/RFC5440, March 2009, 832 . 834 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 835 "Recommendations for Secure Use of Transport Layer 836 Security (TLS) and Datagram Transport Layer Security 837 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 838 2015, . 840 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 841 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 842 May 2016, . 844 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 845 Writing an IANA Considerations Section in RFCs", BCP 26, 846 RFC 8126, DOI 10.17487/RFC8126, June 2017, 847 . 849 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 850 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 851 May 2017, . 853 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 854 Computation Element Communication Protocol (PCEP) 855 Extensions for Stateful PCE", RFC 8231, 856 DOI 10.17487/RFC8231, September 2017, 857 . 859 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 860 "PCEPS: Usage of TLS to Provide a Secure Transport for the 861 Path Computation Element Communication Protocol (PCEP)", 862 RFC 8253, DOI 10.17487/RFC8253, October 2017, 863 . 865 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 866 Computation Element Communication Protocol (PCEP) 867 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 868 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 869 . 871 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 872 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 873 "Alternate-Marking Method for Passive and Hybrid 874 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 875 January 2018, . 877 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 878 and J. Hardwick, "Path Computation Element Communication 879 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 880 DOI 10.17487/RFC8664, December 2019, 881 . 883 11.2. Informative References 885 [I-D.ietf-pce-segment-routing-ipv6] 886 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 887 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 888 Routing leveraging the IPv6 data plane", draft-ietf-pce- 889 segment-routing-ipv6-08 (work in progress), November 2020. 891 [I-D.ietf-pce-segment-routing-policy-cp] 892 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 893 Bidgoli, "PCEP extension to support Segment Routing Policy 894 Candidate Paths", draft-ietf-pce-segment-routing-policy- 895 cp-02 (work in progress), January 2021. 897 [I-D.ietf-spring-segment-routing-policy] 898 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 899 P. Mattes, "Segment Routing Policy Architecture", draft- 900 ietf-spring-segment-routing-policy-09 (work in progress), 901 November 2020. 903 [I-D.koldychev-pce-multipath] 904 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V., 905 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 906 Signaling Multipath Information", draft-koldychev-pce- 907 multipath-04 (work in progress), October 2020. 909 [I-D.qin-idr-sr-policy-ifit] 910 Qin, F., Yuan, H., Zhou, T., Fioccola, G., and Y. Wang, 911 "BGP SR Policy Extensions to Enable IFIT", draft-qin-idr- 912 sr-policy-ifit-04 (work in progress), October 2020. 914 Appendix A. 916 Authors' Addresses 918 Huanan Chen 919 China Telecom 920 Guangzhou 921 China 923 Email: chenhuan6@chinatelecom.cn 925 Hang Yuan 926 UnionPay 927 1899 Gu-Tang Rd., Pudong 928 Shanghai 929 China 931 Email: yuanhang@unionpay.com 933 Tianran Zhou 934 Huawei 935 156 Beiqing Rd., Haidian District 936 Beijing 937 China 939 Email: zhoutianran@huawei.com 941 Weidong Li 942 Huawei 943 156 Beiqing Rd., Haidian District 944 Beijing 945 China 947 Email: poly.li@huawei.com 948 Giuseppe Fioccola 949 Huawei 950 Riesstrasse, 25 951 Munich 952 Germany 954 Email: giuseppe.fioccola@huawei.com 956 Yali Wang 957 Huawei 958 156 Beiqing Rd., Haidian District 959 Beijing 960 China 962 Email: wangyali11@huawei.com