idnits 2.17.1 draft-chen-pce-pcep-ifit-01.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 741 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 (September 22, 2020) is 1283 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-01 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-01 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-02 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-03 ** 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 (-22) exists of draft-ietf-pce-segment-routing-ipv6-06 == Outdated reference: A later version (-15) 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-03 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: March 26, 2021 UnionPay 6 T. Zhou 7 W. Li 8 G. Fioccola 9 Y. Wang 10 Huawei 11 September 22, 2020 13 Path Computation Element Communication Protocol (PCEP) Extensions to 14 Enable IFIT 15 draft-chen-pce-pcep-ifit-01 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 March 26, 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 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 14 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 2.1. IFIT for SR Policies 175 RFC 8664 [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6] specify 176 extensions to the Path Computation Element Communication Protocol 177 (PCEP) that allow a stateful PCE to compute and initiate Traffic- 178 Engineering (TE) paths, as well as a Path Computation Client (PCC) to 179 request a path subject to certain constraints and optimization 180 criteria in SR networks both for SR-MPLS and SRv6. 182 IFIT attibutes, here defined as TLVs for the LSPA object, complement 183 both RFC 8664 [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 184 [I-D.ietf-pce-segment-routing-policy-cp]. 186 3. IFIT capability advertisement TLV 188 During the PCEP initialization phase, PCEP speakers (PCE or PCC) 189 SHOULD advertise their support of IFIT methods (e.g. IOAM and 190 Alternate Marking). 192 A PCEP speaker includes the IFIT-CAPABILITY TLVs in the OPEN object 193 to advertise its support for PCEP IFIT extensions. The presence of 194 the IFIT-CAPABILITY TLV in the OPEN object indicates that the IFIT 195 methods are supported. 197 RFC 8664 [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6] define a 198 new Path Setup Type (PST) for SR and also define the SR-PCE- 199 CAPABILITY sub-TLV. This document defined a new IFIT-CAPABILITY TLV, 200 that is an optional TLV for use in the OPEN Object for IFIT 201 attributes via PCEP capability advertisement. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length=4 | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Flags |P|I|D|E|M| 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Fig. 1 IFIT-CAPABILITY TLV Format 213 Where: 215 Type: to be assigned by IANA. 217 Length: 4. 219 Flags: The following flags are defined in this document: 221 P: IOAM Pre-allocated Trace Option Type-enabled flag 222 [I-D.ietf-ippm-ioam-data]. If set to 1 by a PCC, the P flag 223 indicates that the PCC allows instantiation of the IOAM Pre- 224 allocated Trace feature by a PCE. If set to 1 by a PCE, the P 225 flag indicates that the PCE supports the IOAM Pre-allocated Trace 226 feature instantiation. The P flag MUST be set by both PCC and PCE 227 in order to support the IOAM Pre-allocated Trace instantiation 229 I: IOAM Incremental Trace Option Type-enabled flag 230 [I-D.ietf-ippm-ioam-data]. If set to 1 by a PCC, the I flag 231 indicates that the PCC allows instantiation of the IOAM 232 Incremental Trace feature by a PCE. If set to 1 by a PCE, the I 233 flag indicates that the PCE supports the relative IOAM Incremental 234 Trace feature instantiation. The I flag MUST be set by both PCC 235 and PCE in order to support the IOAM Incremental Trace feature 236 instantiation 238 D: IOAM DEX Option Type-enabled flag 239 [I-D.ietf-ippm-ioam-direct-export]. If set to 1 by a PCC, the D 240 flag indicates that the PCC allows instantiation of the relative 241 IOAM DEX feature by a PCE. If set to 1 by a PCE, the D flag 242 indicates that the PCE supports the relative IOAM DEX feature 243 instantiation. The D flag MUST be set by both PCC and PCE in 244 order to support the IOAM DEX feature instantiation 246 E: IOAM E2E Option Type-enabled flag [I-D.ietf-ippm-ioam-data]. 247 If set to 1 by a PCC, the E flag indicates that the PCC allows 248 instantiation of the relative IOAM E2E feature by a PCE. If set 249 to 1 by a PCE, the E flag indicates that the PCE supports the 250 relative IOAM E2E feature instantiation. The E flag MUST be set 251 by both PCC and PCE in order to support the IOAM E2E feature 252 instantiation 254 M: Alternate Marking enabled flag RFC 8321 [RFC8321]. If set to 1 255 by a PCC, the M flag indicates that the PCC allows instantiation 256 of the relative Alternate Marking feature by a PCE. If set to 1 257 by a PCE, the M flag indicates that the PCE supports the relative 258 Alternate Marking feature instantiation. The M flag MUST be set 259 by both PCC and PCE in order to support the Alternate Marking 260 feature instantiation 262 Unassigned bits are considered reserved. They MUST be set to 0 on 263 transmission and MUST be ignored on receipt. 265 Advertisement of the IFIT-CAPABILITY TLV implies support of IFIT 266 methods (IOAM and/or Alternate Marking) as well as the objects, TLVs, 267 and procedures defined in this document. It is worth mentioning that 268 IOAM and Alternate Marking can be activated one at a time or can 269 coexist; so it is possible to have only IOAM or only Alternate 270 Marking enabled but they are recognized in general as IFIT 271 capability. 273 The IFIT Capability Advertisement can imply the following cases: 275 o The PCEP protocol extensions for IFIT MUST NOT be used if one or 276 both PCEP speakers have not included the IFIT-CAPABILITY TLV in 277 their respective OPEN message. 279 o A PCEP speaker that does not recognize the extensions defined in 280 this document would simply ignore the TLVs as per RFC 5440 281 [RFC5440]. 283 o If a PCEP speaker supports the extensions defined in this document 284 but did not advertise this capability, then upon receipt of IFIT- 285 ATTRIBUTES TLV in the LSP Attributes (LSPA) object, it SHOULD 286 generate a PCErr with Error-Type 19 (Invalid Operation) with the 287 relative Error-value "IFIT capability not advertised" and ignore 288 the IFIT-ATTRIBUTES TLV. 290 4. IFIT Attributes TLV 292 The IFIT-ATTRIBUTES TLV provides the configurable knobs of the IFIT 293 feature, and it can be included as an optional TLV in the LSPA object 294 (as described in RFC 5440 [RFC5440]). 296 For a PCE-initiated LSP RFC 8281 [RFC8281], this TLV is included in 297 the LSPA object with the PCInitiate message. For the PCC-initiated 298 delegated LSPs, this TLV is carried in the Path Computation State 299 Report (PCRpt) message in the LSPA object. This TLV is also carried 300 in the LSPA object with the Path Computation Update Request (PCUpd) 301 message to direct the PCC (LSP head-end) to make updates to IFIT 302 attributes. 304 The TLV is encoded in all PCEP messages for the LSP if IFIT feature 305 is enabled. The absence of the TLV indicates the PCEP speaker wishes 306 to disable the feature. This TLV includes multiple IFIT-ATTRIBUTES 307 sub-TLVs. The IFIT-ATTRIBUTES sub-TLVs are included if there is a 308 change since the last information sent in the PCEP message. The 309 default values for missing sub-TLVs apply for the first PCEP message 310 for the LSP. 312 The format of the IFIT-ATTRIBUTES TLV is shown in the following 313 figure: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 // sub-TLVs // 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Fig. 2 IFIT-ATTRIBUTES TLV Format 327 Where: 329 Type: to be assigned by IANA. 331 Length: The Length field defines the length of the value portion in 332 bytes as per RFC 5440 [RFC5440]. 334 Value: This comprises one or more sub-TLVs. 336 The following sub-TLVs are defined in this document: 338 Type Len Name 339 ----------------------------------------------------- 340 1 8 IOAM Pre-allocated Trace Option 342 2 8 IOAM Incremental Trace Option 344 3 12 IOAM Directly Export Option 346 4 4 IOAM Edge-to-Edge Option 348 5 4 Enhanced Alternate Marking 350 Fig. 3 Sub-TLV Types of the IFIT-ATTRIBUTES TLV 352 4.1. IOAM Sub-TLVs 354 In-situ Operations, Administration, and Maintenance (IOAM) 355 [I-D.ietf-ippm-ioam-data] records operational and telemetry 356 information in the packet while the packet traverses a path between 357 two points in the network. In terms of the classification given in 358 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 359 mechanisms can be leveraged where active OAM do not apply or do not 360 offer the desired results. 362 For the SR use case, when SR policy enables IOAM, the IOAM header 363 will be inserted into every packet of the traffic that is steered 364 into the SR paths. Since this document aims to define the control 365 plane, it is to be noted that a relevant document for the data plane 366 is [I-D.ietf-ippm-ioam-ipv6-options] for Segment Routing over IPv6 367 data plane (SRv6). 369 4.1.1. IOAM Pre-allocated Trace Option Sub-TLV 371 The IOAM tracing data is expected to be collected at every node that 372 a packet traverses to ensure visibility into the entire path a packet 373 takes within an IOAM domain. The preallocated tracing option will 374 create pre-allocated space for each node to populate its information. 376 The format of IOAM pre-allocated trace option Sub-TLV is defined as 377 follows: 379 0 1 2 3 380 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 381 +-------------------------------+-------------------------------+ 382 | Type=1 | Length=8 | 383 +---------------------------------------------------------------+ 384 | Namespace ID | Rsvd1 | 385 +-------------------------------+-----------------------+-------+ 386 | IOAM Trace Type | Flags | Rsvd2 | 387 +----------------------------------------------+--------+-------+ 389 Fig. 4 IOAM Pre-allocated Trace Option Sub-TLV 391 Where: 393 Type: 1 (to be assigned by IANA). 395 Length: 8. It is the total length of the value field not including 396 Type and Length fields. 398 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 399 definition is the same as described in section 4.4 of 400 [I-D.ietf-ippm-ioam-data]. 402 IOAM Trace Type: A 24-bit identifier which specifies which data types 403 are used in the node data list. The definition is the same as 404 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 406 Flags: A 4-bit field. The definition is the same as described in 407 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 408 [I-D.ietf-ippm-ioam-data]. 410 Rsvd1: A 16-bit field reserved for further usage. It MUST be zero. 412 Rsvd2: A 4-bit field reserved for further usage. It MUST be zero. 414 4.1.2. IOAM Incremental Trace Option Sub-TLV 416 The incremental tracing option contains a variable node data fields 417 where each node allocates and pushes its node data immediately 418 following the option header. 420 The format of IOAM incremental trace option Sub-TLV is defined as 421 follows: 423 0 1 2 3 424 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 425 +-------------------------------+-------------------------------+ 426 | Type=2 | Length=8 | 427 +---------------------------------------------------------------+ 428 | Namespace ID | Rsvd1 | 429 +-------------------------------+-----------------------+-------+ 430 | IOAM Trace Type | Flags | Rsvd2 | 431 +----------------------------------------------+--------+-------+ 433 Fig. 5 IOAM Incremental Trace Option Sub-TLV 435 Where: 437 Type: 2 (to be assigned by IANA). 439 Length: 8. It is the total length of the value field not including 440 Type and Length fields. 442 All the other fields definition is the same as the pre-allocated 443 trace option Sub-TLV in the previous section. 445 4.1.3. IOAM Directly Export Option Sub-TLV 447 IOAM directly export option is used as a trigger for IOAM data to be 448 directly exported to a collector without being pushed into in-flight 449 data packets. 451 The format of IOAM directly export option Sub-TLV is defined as 452 follows: 454 0 1 2 3 455 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 456 +-------------------------------+-------------------------------+ 457 | Type=3 | Length=12 | 458 +---------------------------------------------------------------+ 459 | Namespace ID | Flags | 460 +-------------------------------+---------------+---------------+ 461 | IOAM Trace Type | Rsvd | 462 +-----------------------------------------------+---------------+ 463 | Flow ID | 464 +---------------------------------------------------------------+ 466 Fig. 6 IOAM Directly Export Option Sub-TLV 468 Where: 470 Type: 3 (to be assigned by IANA). 472 Length: 12. It is the total length of the value field not including 473 Type and Length fields. 475 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 476 definition is the same as described in section 4.4 of 477 [I-D.ietf-ippm-ioam-data]. 479 IOAM Trace Type: A 24-bit identifier which specifies which data types 480 are used in the node data list. The definition is the same as 481 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 483 Flags: A 16-bit field. The definition is the same as described in 484 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 486 Flow ID: A 32-bit flow identifier. The definition is the same as 487 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 489 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 491 4.1.4. IOAM Edge-to-Edge Option Sub-TLV 493 The IOAM edge to edge option is to carry data that is added by the 494 IOAM encapsulating node and interpreted by IOAM decapsulating node. 496 The format of IOAM edge-to-edge option Sub-TLV is defined as follows: 498 0 1 2 3 499 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 500 +-------------------------------+-------------------------------+ 501 | Type=4 | Length=4 | 502 +---------------------------------------------------------------+ 503 | Namespace ID | IOAM E2E Type | 504 +-------------------------------+-------------------------------+ 506 Fig. 7 IOAM Edge-to-Edge Option Sub-TLV 508 Where: 510 Type: 4 (to be assigned by IANA). 512 Length: 4. It is the total length of the value field not including 513 Type and Length fields. 515 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 516 definition is the same as described in section 4.6 of 517 [I-D.ietf-ippm-ioam-data]. 519 IOAM E2E Type: A 16-bit identifier which specifies which data types 520 are used in the E2E option data. The definition is the same as 521 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 523 4.2. Enhanced Alternate Marking Sub-TLV 525 The Alternate Marking [RFC8321]technique is an hybrid performance 526 measurement method, per RFC 7799 [RFC7799] classification of 527 measurement methods. Because this method is based on marking 528 consecutive batches of packets. It can be used to measure packet 529 loss, latency, and jitter on live traffic. 531 For the SR use case, since this document aims to define the control 532 plane, it is to be noted that a relevant document for the data plane 533 is [I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data 534 plane (SRv6). 536 The format of Enhanced Alternate Marking (EAM) Sub-TLV is defined as 537 follows: 539 0 1 2 3 540 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 541 +-------------------------------+-------------------------------+ 542 | Type=5 | Length=4 | 543 +-------------------------------+-------+---------------+-------+ 544 | FlowMonID | Period | Rsvd | 545 +---------------------------------------+---------------+-------+ 547 Fig. 8 Enhanced Alternate Marking Sub-TLV 549 Where: 551 Type: 5 (to be assigned by IANA). 553 Length: 4. It is the total length of the value field not including 554 Type and Length fields. 556 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 557 within the measurement domain. The definition is the same as 558 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. It is to 559 be noted that PCE also needs to maintain the uniqueness of FlowMonID 560 as described in [I-D.ietf-6man-ipv6-alt-mark]. 562 Period: Time interval between two alternate marking period. The unit 563 is second. 565 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 567 5. PCEP Messages 569 5.1. The PCInitiate Message 571 A PCInitiate message is a PCEP message sent by a PCE to a PCC to 572 trigger LSP instantiation or deletion RFC 8281 [RFC8281]. 574 For the PCE-initiated LSP with the IFIT feature enabled, IFIT- 575 ATTRIBUTES TLV MUST be included in the LSPA object with the 576 PCInitiate message. 578 The Routing Backus-Naur Form (RBNF) definition of the PCInitiate 579 message RFC 8281 [RFC8281] is unchanged by this document. 581 5.2. The PCUpd Message 583 A PCUpd message is a PCEP message sent by a PCE to a PCC to update 584 the LSP parameters RFC 8231 [RFC8231]. 586 For PCE-initiated LSPs with the IFIT feature enabled, the IFIT- 587 ATTRIBUTES TLV MUST be included in the LSPA object with the PCUpd 588 message. The PCE can send this TLV to direct the PCC to change the 589 IFIT parameters. 591 The RBNF definition of the PCUpd message RFC 8231 [RFC8231] is 592 unchanged by this document. 594 5.3. The PCRpt Message 596 The PCRpt message RFC 8231 [RFC8231] is a PCEP message sent by a PCC 597 to a PCE to report the status of one or more LSPs. 599 For PCE-initiated LSPs RFC 8281 [RFC8281], the PCC creates the LSP 600 using the attributes communicated by the PCE and the local values for 601 the unspecified parameters. After the successful instantiation of 602 the LSP, the PCC automatically delegates the LSP to the PCE and 603 generates a PCRpt message to provide the status report for the LSP. 605 The RBNF definition of the PCRpt message RFC 8231 [RFC8231] is 606 unchanged by this document. 608 For both PCE-initiated and PCC-initiated LSPs, when the LSP is 609 instantiated the IFIT methods are applied as specified for the 610 corresponding data plane. [I-D.ietf-ippm-ioam-ipv6-options] and 611 [I-D.ietf-6man-ipv6-alt-mark] are the relevant documents for Segment 612 Routing over IPv6 data plane (SRv6). 614 6. Example of application to SR Policy 616 A PCC or PCE sets the IFIT-CAPABILITY TLV in the Open message during 617 the PCEP initialization phase to indicate that it supports the IFIT 618 procedures. 620 [I-D.ietf-pce-segment-routing-policy-cp] defines the PCEP extension 621 to support Segment Routing Policy Candidate Paths and in this regard 622 the SRPAG Association object is introduced. 624 The Examples of PCC Initiated SR Policy with single or multiple 625 candidate-paths and PCE Initiated SR Policy with single or multiple 626 candidate-paths are reported in 627 [I-D.ietf-pce-segment-routing-policy-cp]. 629 In case of PCC Initiated SR Policy, PCC sends PCReq message to the 630 PCE, encoding the SRPAG ASSOCIATION object and IFIT-ATTRIBUTES TLV 631 via the LSPA object. This is valid for both single and multiple 632 candidate-paths. Finally PCE returns the path in PCRep message, and 633 echoes back the SRPAG object that were used in the computation and 634 IFIT LSPA TLVs too. Additionally, PCC sends PCRpt message to the 635 PCE, including the LSP object and the SRPAG ASSOCIATION object and 636 IFIT-ATTRIBUTES TLV via the LSPA object. Then PCE computes path and 637 finally PCE updates the SR policy candidate path's ERO using PCUpd 638 message considering the IFIT LSPA TLVs too. 640 In case of PCE Initiated SR Policy, PCE sends PCInitiate message, 641 containing the SRPAG Association object and IFIT-ATTRIBUTES TLV via 642 the LSPA object. This is valid for both single and multiple 643 candidate-paths. Then PCC uses the color, endpoint and preference 644 from the SRPAG object to create a new candidate path considering the 645 IFIT LSPA TLVs too. Finally PCC sends a PCRpt message back to the 646 PCE to report the newly created Candidate Path. The PCRpt message 647 contains the SRPAG Association object and IFIT-ATTRIBUTES 648 information. 650 The procedure of enabling/disabling IFIT is simple, indeed the PCE 651 can update the IFIT-ATTRIBUTES of the LSP by sending subsequent Path 652 Computation Update Request (PCUpd) messages. PCE can update the 653 IFIT-ATTRIBUTES of the LSP by sending Path Computation State Report 654 (PCRpt) messages. 656 7. IANA Considerations 658 This document defines the new IFIT-CAPABILITY TLV and IFIT-ATTRIBUTES 659 TLV. IANA is requested to make the assignment from the "PCEP TLV 660 Type Indicators" subregistry of the "Path Computation Element 661 Protocol (PCEP) Numbers" registry as follows: 663 Value Description Reference 664 ------------------------------------------------------------- 665 TBD1 IFIT-CAPABILITY This document 667 TBD2 IFIT-ATTRIBUTES This document 669 This document specifies the IFIT-CAPABILITY TLV Flags field. IANA is 670 requested to create a registry to manage the value of the IFIT- 671 CAPABILITY TLV's Flags field within the "Path Computation Element 672 Protocol (PCEP) Numbers" registry. 674 New values are to be assigned by Standards Action RFC 8126 [RFC8126]. 675 Each bit should be tracked with the following qualities: 677 * Bit number (count from 0 as the most significant bit) 679 * Flag Name 681 * Reference 683 IANA is requested to set 5 new bits in the IFIT-CAPABILITY TLV Flags 684 Field registry, as follows: 686 Bit no. Flag Name Reference 687 --------------------------------------------------------------------- 688 27 P: IOAM Pre-allocated Trace Option flag This document 690 28 I: IOAM Incremental Trace Option flag This document 692 29 D: IOAM Directly Export Option flag This document 694 30 E: IOAM Edge-to-Edge Option This document 696 31 M: Alternate Marking Flag This document 698 This document also specifies the IFIT-ATTRIBUTES sub-TLVs. IANA is 699 requested to create an "IFIT-ATTRIBUTES Sub-TLV Types" subregistry 700 within the "Path Computation Element Protocol (PCEP) Numbers" 701 registry. 703 IANA is requested to set the Registration Procedure for this registry 704 to read as follows: 706 Range Registration Procedure 707 ------------------------------------------ 708 0-65503 IETF Review 710 65504-65535 Experimental Use 712 This document defines the following types: 714 Type Description Reference 715 --------------------------------------------------------------- 716 0 Reserved This document 718 1 IOAM Pre-allocated Trace Option This document 720 2 IOAM Incremental Trace Option This document 722 3 IOAM Directly Export Option This document 724 4 IOAM Edge-to-Edge Option This document 726 5 Enhanced Alternate Marking This document 728 6-65503 Unassigned This document 730 65504-65535 Experimental Use This document 732 This document defines a new Error-value for PCErr message of Error- 733 Type 19 (Invalid Operation). IANA is requested to allocate a new 734 Error-value within the "PCEP-ERROR Object Error Types and Values" 735 subregistry of the "Path Computation Element Protocol (PCEP) Numbers" 736 registry as follows: 738 Error-Type Meaning Error-value Reference 739 --------------------------------------------------------------- 740 19 Invalid TBD3: IFIT This document 741 Operation capability not 742 advertised 744 8. Security Considerations 746 This document defines the new IFIT-CAPABILITY TLV and IFIT Attributes 747 TLVs, which do not add any substantial new security concerns beyond 748 those already discussed in RFC 8231 [RFC8231] and RFC 8281 [RFC8281] 749 for stateful PCE operations. As per RFC 8231 [RFC8231], it is 750 RECOMMENDED that these PCEP extensions only be activated on 751 authenticated and encrypted sessions across PCEs and PCCs belonging 752 to the same administrative authority, using Transport Layer Security 753 (TLS) RFC 8253 [RFC8253], as per the recommendations and best current 754 practices in BCP 195 RFC 7525 [RFC7525] (unless explicitly set aside 755 in RFC 8253 [RFC8253]). 757 Implementation of IFIT methods (IOAM and Alternate Marking) are 758 mindful of security and privacy concerns, as explained in 759 [I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect 760 IFIT parameters in the IFIT-ATTRIBUTES sub-TLVs SHOULD not have an 761 adverse effect on the LSP as well as on the network, since it affects 762 only the operation of the telemetry methodology. 764 9. Contributors 766 The following people provided relevant contributions to this 767 document: 769 Dhruv Doody, Huawei Technologies, dhruv.ietf@gmail.com 771 10. Acknowledgements 773 The authors of this document would like to thank Huaimo Chen for the 774 comments and review of this document. 776 11. References 778 11.1. Normative References 780 [I-D.ietf-6man-ipv6-alt-mark] 781 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 782 Pang, "IPv6 Application of the Alternate Marking Method", 783 draft-ietf-6man-ipv6-alt-mark-01 (work in progress), June 784 2020. 786 [I-D.ietf-ippm-ioam-data] 787 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 788 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 789 progress), July 2020. 791 [I-D.ietf-ippm-ioam-direct-export] 792 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 793 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 794 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 795 export-01 (work in progress), August 2020. 797 [I-D.ietf-ippm-ioam-flags] 798 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 799 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 800 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-02 801 (work in progress), July 2020. 803 [I-D.ietf-ippm-ioam-ipv6-options] 804 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 805 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 806 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 807 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 808 ipv6-options-03 (work in progress), September 2020. 810 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 811 Requirement Levels", BCP 14, RFC 2119, 812 DOI 10.17487/RFC2119, March 1997, 813 . 815 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 816 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 817 DOI 10.17487/RFC5440, March 2009, 818 . 820 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 821 "Recommendations for Secure Use of Transport Layer 822 Security (TLS) and Datagram Transport Layer Security 823 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 824 2015, . 826 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 827 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 828 May 2016, . 830 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 831 Writing an IANA Considerations Section in RFCs", BCP 26, 832 RFC 8126, DOI 10.17487/RFC8126, June 2017, 833 . 835 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 836 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 837 May 2017, . 839 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 840 Computation Element Communication Protocol (PCEP) 841 Extensions for Stateful PCE", RFC 8231, 842 DOI 10.17487/RFC8231, September 2017, 843 . 845 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 846 "PCEPS: Usage of TLS to Provide a Secure Transport for the 847 Path Computation Element Communication Protocol (PCEP)", 848 RFC 8253, DOI 10.17487/RFC8253, October 2017, 849 . 851 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 852 Computation Element Communication Protocol (PCEP) 853 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 854 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 855 . 857 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 858 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 859 "Alternate-Marking Method for Passive and Hybrid 860 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 861 January 2018, . 863 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 864 and J. Hardwick, "Path Computation Element Communication 865 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 866 DOI 10.17487/RFC8664, December 2019, 867 . 869 11.2. Informative References 871 [I-D.ietf-pce-segment-routing-ipv6] 872 Li, C., Negi, M., Koldychev, M., Kaladharan, P., and Y. 873 Zhu, "PCEP Extensions for Segment Routing leveraging the 874 IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-06 875 (work in progress), July 2020. 877 [I-D.ietf-pce-segment-routing-policy-cp] 878 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 879 Bidgoli, "PCEP extension to support Segment Routing Policy 880 Candidate Paths", draft-ietf-pce-segment-routing-policy- 881 cp-00 (work in progress), June 2020. 883 [I-D.ietf-spring-segment-routing-policy] 884 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 885 P. Mattes, "Segment Routing Policy Architecture", draft- 886 ietf-spring-segment-routing-policy-08 (work in progress), 887 July 2020. 889 [I-D.qin-idr-sr-policy-ifit] 890 Qin, F., Yuan, H., Zhou, T., Fioccola, G., and Y. Wang, 891 "BGP SR Policy Extensions to Enable IFIT", draft-qin-idr- 892 sr-policy-ifit-03 (work in progress), September 2020. 894 Appendix A. 896 Authors' Addresses 898 Huanan Chen 899 China Telecom 900 Guangzhou 901 China 903 Email: chenhuan6@chinatelecom.cn 905 Hang Yuan 906 UnionPay 907 1899 Gu-Tang Rd., Pudong 908 Shanghai 909 China 911 Email: yuanhang@unionpay.com 913 Tianran Zhou 914 Huawei 915 156 Beiqing Rd., Haidian District 916 Beijing 917 China 919 Email: zhoutianran@huawei.com 921 Weidong Li 922 Huawei 923 156 Beiqing Rd., Haidian District 924 Beijing 925 China 927 Email: poly.li@huawei.com 929 Giuseppe Fioccola 930 Huawei 931 Riesstrasse, 25 932 Munich 933 Germany 935 Email: giuseppe.fioccola@huawei.com 936 Yali Wang 937 Huawei 938 156 Beiqing Rd., Haidian District 939 Beijing 940 China 942 Email: wangyali11@huawei.com