idnits 2.17.1 draft-chen-pce-pcep-ifit-03.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 765 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 (July 9, 2021) is 1020 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-04 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-12 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-03 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-04 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-05 ** 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) ** Downref: Normative reference to an Informational RFC: RFC 8799 == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-09 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 Summary: 4 errors (**), 0 flaws (~~), 12 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: January 10, 2022 UnionPay 6 T. Zhou 7 W. Li 8 G. Fioccola 9 Y. Wang 10 Huawei 11 July 9, 2021 13 Path Computation Element Communication Protocol (PCEP) Extensions to 14 Enable IFIT 15 draft-chen-pce-pcep-ifit-03 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 January 10, 2022. 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 . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . 9 78 4.1.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . 14 85 5.3. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 14 86 6. Example of application to SR Policy . . . . . . . . . . . . . 14 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 93 11.2. Informative References . . . . . . . . . . . . . . . . . 20 94 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 IFIT is a solution focusing on network domains according to [RFC8799] 140 that introduces the concept of specific domain solutions. A network 141 domain consists of a set of network devices or entities within a 142 single administration. As mentioned in [RFC8799], for a number of 143 reasons, such as policies, options supported, style of network 144 management and security requirements, it is suggested to limit 145 applications including the emerging IFIT techniques to a controlled 146 domain. Hence, the IFIT methods MUST be typically deployed in such 147 controlled domains. 149 The Use Case of Segment Routing (SR) is also discussed considering 150 that IFIT methods are becoming mature for Segment Routing over the 151 MPLS data plane (SR-MPLS) and Segment Routing over IPv6 data plane 152 (SRv6). SR policy [I-D.ietf-spring-segment-routing-policy] is a set 153 of candidate SR paths consisting of one or more segment lists and 154 necessary path attributes. It enables instantiation of an ordered 155 list of segments with a specific intent for traffic steering. The 156 PCEP extension defined in this document also enables SR policy with 157 native IFIT, that can facilitate the closed loop control and enable 158 the automation of SR service. 160 It is to be noted the companion document [I-D.qin-idr-sr-policy-ifit] 161 that proposes the BGP extension to enable IFIT methods for SR policy. 163 2. PCEP Extensions for IFIT Attributes 165 This document is to add IFIT attribute TLVs as PCEP Extensions. The 166 following sections will describe the requirement and usage of 167 different IFIT modes, and define the corresponding TLV encoding in 168 PCEP. 170 The IFIT attributes here described can be generalized and included as 171 TLVs carried inside the LSPA (LSP Attributes) object in order to be 172 applied for all path types, as long as they support the relevant data 173 plane telemetry method. IFIT Attributes TLVs are optional and can be 174 taken into account by the PCE during path computation and by the PCC 175 during path setup. In general, the LSPA object can be carried within 176 a PCInitiate message, a PCUpd message, or a PCRpt message in the 177 stateful PCE model. 179 In this document it is considered the case of SR Policy since IOAM 180 and Alternate Marking are more mature especially for Segment Routing 181 (SR) and for IPv6. 183 It is to be noted that, if it is needed to apply different IFIT 184 methods for each Segment List, the IFIT attributes can be added into 185 the PATH-ATTRIB object, instead of the LSPA object, according to 186 [I-D.koldychev-pce-multipath] that defines PCEP Extensions for 187 Signaling Multipath Information. 189 2.1. IFIT for SR Policies 191 RFC 8664 [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6] specify 192 extensions to the Path Computation Element Communication Protocol 193 (PCEP) that allow a stateful PCE to compute and initiate Traffic- 194 Engineering (TE) paths, as well as a Path Computation Client (PCC) to 195 request a path subject to certain constraints and optimization 196 criteria in SR networks both for SR-MPLS and SRv6. 198 IFIT attibutes, here defined as TLVs for the LSPA object, complement 199 both RFC 8664 [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 200 [I-D.ietf-pce-segment-routing-policy-cp]. 202 3. IFIT capability advertisement TLV 204 During the PCEP initialization phase, PCEP speakers (PCE or PCC) 205 SHOULD advertise their support of IFIT methods (e.g. IOAM and 206 Alternate Marking). 208 A PCEP speaker includes the IFIT-CAPABILITY TLVs in the OPEN object 209 to advertise its support for PCEP IFIT extensions. The presence of 210 the IFIT-CAPABILITY TLV in the OPEN object indicates that the IFIT 211 methods are supported. 213 RFC 8664 [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6] define a 214 new Path Setup Type (PST) for SR and also define the SR-PCE- 215 CAPABILITY sub-TLV. This document defined a new IFIT-CAPABILITY TLV, 216 that is an optional TLV for use in the OPEN Object for IFIT 217 attributes via PCEP capability advertisement. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type | Length=4 | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Flags |P|I|D|E|M| 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Fig. 1 IFIT-CAPABILITY TLV Format 229 Where: 231 Type: to be assigned by IANA. 233 Length: 4. 235 Flags: The following flags are defined in this document: 237 P: IOAM Pre-allocated Trace Option Type-enabled flag 238 [I-D.ietf-ippm-ioam-data]. If set to 1 by a PCC, the P flag 239 indicates that the PCC allows instantiation of the IOAM Pre- 240 allocated Trace feature by a PCE. If set to 1 by a PCE, the P 241 flag indicates that the PCE supports the IOAM Pre-allocated Trace 242 feature instantiation. The P flag MUST be set by both PCC and PCE 243 in order to support the IOAM Pre-allocated Trace instantiation 245 I: IOAM Incremental Trace Option Type-enabled flag 246 [I-D.ietf-ippm-ioam-data]. If set to 1 by a PCC, the I flag 247 indicates that the PCC allows instantiation of the IOAM 248 Incremental Trace feature by a PCE. If set to 1 by a PCE, the I 249 flag indicates that the PCE supports the relative IOAM Incremental 250 Trace feature instantiation. The I flag MUST be set by both PCC 251 and PCE in order to support the IOAM Incremental Trace feature 252 instantiation 254 D: IOAM DEX Option Type-enabled flag 255 [I-D.ietf-ippm-ioam-direct-export]. If set to 1 by a PCC, the D 256 flag indicates that the PCC allows instantiation of the relative 257 IOAM DEX feature by a PCE. If set to 1 by a PCE, the D flag 258 indicates that the PCE supports the relative IOAM DEX feature 259 instantiation. The D flag MUST be set by both PCC and PCE in 260 order to support the IOAM DEX feature instantiation 262 E: IOAM E2E Option Type-enabled flag [I-D.ietf-ippm-ioam-data]. 263 If set to 1 by a PCC, the E flag indicates that the PCC allows 264 instantiation of the relative IOAM E2E feature by a PCE. If set 265 to 1 by a PCE, the E flag indicates that the PCE supports the 266 relative IOAM E2E feature instantiation. The E flag MUST be set 267 by both PCC and PCE in order to support the IOAM E2E feature 268 instantiation 270 M: Alternate Marking enabled flag RFC 8321 [RFC8321]. If set to 1 271 by a PCC, the M flag indicates that the PCC allows instantiation 272 of the relative Alternate Marking feature by a PCE. If set to 1 273 by a PCE, the M flag indicates that the PCE supports the relative 274 Alternate Marking feature instantiation. The M flag MUST be set 275 by both PCC and PCE in order to support the Alternate Marking 276 feature instantiation 278 Unassigned bits are considered reserved. They MUST be set to 0 on 279 transmission and MUST be ignored on receipt. 281 Advertisement of the IFIT-CAPABILITY TLV implies support of IFIT 282 methods (IOAM and/or Alternate Marking) as well as the objects, TLVs, 283 and procedures defined in this document. It is worth mentioning that 284 IOAM and Alternate Marking can be activated one at a time or can 285 coexist; so it is possible to have only IOAM or only Alternate 286 Marking enabled but they are recognized in general as IFIT 287 capability. 289 The IFIT Capability Advertisement can imply the following cases: 291 o The PCEP protocol extensions for IFIT MUST NOT be used if one or 292 both PCEP speakers have not included the IFIT-CAPABILITY TLV in 293 their respective OPEN message. 295 o A PCEP speaker that does not recognize the extensions defined in 296 this document would simply ignore the TLVs as per RFC 5440 297 [RFC5440]. 299 o If a PCEP speaker supports the extensions defined in this document 300 but did not advertise this capability, then upon receipt of IFIT- 301 ATTRIBUTES TLV in the LSP Attributes (LSPA) object, it SHOULD 302 generate a PCErr with Error-Type 19 (Invalid Operation) with the 303 relative Error-value "IFIT capability not advertised" and ignore 304 the IFIT-ATTRIBUTES TLV. 306 4. IFIT Attributes TLV 308 The IFIT-ATTRIBUTES TLV provides the configurable knobs of the IFIT 309 feature, and it can be included as an optional TLV in the LSPA object 310 (as described in RFC 5440 [RFC5440]). 312 For a PCE-initiated LSP RFC 8281 [RFC8281], this TLV is included in 313 the LSPA object with the PCInitiate message. For the PCC-initiated 314 delegated LSPs, this TLV is carried in the Path Computation State 315 Report (PCRpt) message in the LSPA object. This TLV is also carried 316 in the LSPA object with the Path Computation Update Request (PCUpd) 317 message to direct the PCC (LSP head-end) to make updates to IFIT 318 attributes. 320 The TLV is encoded in all PCEP messages for the LSP if IFIT feature 321 is enabled. The absence of the TLV indicates the PCEP speaker wishes 322 to disable the feature. This TLV includes multiple IFIT-ATTRIBUTES 323 sub-TLVs. The IFIT-ATTRIBUTES sub-TLVs are included if there is a 324 change since the last information sent in the PCEP message. The 325 default values for missing sub-TLVs apply for the first PCEP message 326 for the LSP. 328 The format of the IFIT-ATTRIBUTES TLV is shown in the following 329 figure: 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type | Length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | | 337 // sub-TLVs // 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Fig. 2 IFIT-ATTRIBUTES TLV Format 343 Where: 345 Type: to be assigned by IANA. 347 Length: The Length field defines the length of the value portion in 348 bytes as per RFC 5440 [RFC5440]. 350 Value: This comprises one or more sub-TLVs. 352 The following sub-TLVs are defined in this document: 354 Type Len Name 355 ----------------------------------------------------- 356 1 8 IOAM Pre-allocated Trace Option 358 2 8 IOAM Incremental Trace Option 360 3 12 IOAM Directly Export Option 362 4 4 IOAM Edge-to-Edge Option 364 5 4 Enhanced Alternate Marking 366 Fig. 3 Sub-TLV Types of the IFIT-ATTRIBUTES TLV 368 4.1. IOAM Sub-TLVs 370 In-situ Operations, Administration, and Maintenance (IOAM) 371 [I-D.ietf-ippm-ioam-data] records operational and telemetry 372 information in the packet while the packet traverses a path between 373 two points in the network. In terms of the classification given in 374 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 375 mechanisms can be leveraged where active OAM do not apply or do not 376 offer the desired results. 378 For the SR use case, when SR policy enables IOAM, the IOAM header 379 will be inserted into every packet of the traffic that is steered 380 into the SR paths. Since this document aims to define the control 381 plane, it is to be noted that a relevant document for the data plane 382 is [I-D.ietf-ippm-ioam-ipv6-options] for Segment Routing over IPv6 383 data plane (SRv6). 385 4.1.1. IOAM Pre-allocated Trace Option Sub-TLV 387 The IOAM tracing data is expected to be collected at every node that 388 a packet traverses to ensure visibility into the entire path a packet 389 takes within an IOAM domain. The preallocated tracing option will 390 create pre-allocated space for each node to populate its information. 392 The format of IOAM pre-allocated trace option Sub-TLV is defined as 393 follows: 395 0 1 2 3 396 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 397 +-------------------------------+-------------------------------+ 398 | Type=1 | Length=8 | 399 +---------------------------------------------------------------+ 400 | Namespace ID | Rsvd1 | 401 +-------------------------------+-----------------------+-------+ 402 | IOAM Trace Type | Flags | Rsvd2 | 403 +----------------------------------------------+--------+-------+ 405 Fig. 4 IOAM Pre-allocated Trace Option Sub-TLV 407 Where: 409 Type: 1 (to be assigned by IANA). 411 Length: 8. It is the total length of the value field not including 412 Type and Length fields. 414 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 415 definition is the same as described in section 4.4 of 416 [I-D.ietf-ippm-ioam-data]. 418 IOAM Trace Type: A 24-bit identifier which specifies which data types 419 are used in the node data list. The definition is the same as 420 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 422 Flags: A 4-bit field. The definition is the same as described in 423 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 424 [I-D.ietf-ippm-ioam-data]. 426 Rsvd1: A 16-bit field reserved for further usage. It MUST be zero 427 and ignored on receipt. 429 Rsvd2: A 4-bit field reserved for further usage. It MUST be zero and 430 ignored on receipt. 432 4.1.2. IOAM Incremental Trace Option Sub-TLV 434 The incremental tracing option contains a variable node data fields 435 where each node allocates and pushes its node data immediately 436 following the option header. 438 The format of IOAM incremental trace option Sub-TLV is defined as 439 follows: 441 0 1 2 3 442 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 443 +-------------------------------+-------------------------------+ 444 | Type=2 | Length=8 | 445 +---------------------------------------------------------------+ 446 | Namespace ID | Rsvd1 | 447 +-------------------------------+-----------------------+-------+ 448 | IOAM Trace Type | Flags | Rsvd2 | 449 +----------------------------------------------+--------+-------+ 451 Fig. 5 IOAM Incremental Trace Option Sub-TLV 453 Where: 455 Type: 2 (to be assigned by IANA). 457 Length: 8. It is the total length of the value field not including 458 Type and Length fields. 460 All the other fields definition is the same as the pre-allocated 461 trace option Sub-TLV in the previous section. 463 4.1.3. IOAM Directly Export Option Sub-TLV 465 IOAM directly export option is used as a trigger for IOAM data to be 466 directly exported to a collector without being pushed into in-flight 467 data packets. 469 The format of IOAM directly export option Sub-TLV is defined as 470 follows: 472 0 1 2 3 473 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 474 +-------------------------------+-------------------------------+ 475 | Type=3 | Length=12 | 476 +---------------------------------------------------------------+ 477 | Namespace ID | Flags | 478 +-------------------------------+---------------+---------------+ 479 | IOAM Trace Type | Rsvd | 480 +-----------------------------------------------+---------------+ 481 | Flow ID | 482 +---------------------------------------------------------------+ 484 Fig. 6 IOAM Directly Export Option Sub-TLV 486 Where: 488 Type: 3 (to be assigned by IANA). 490 Length: 12. It is the total length of the value field not including 491 Type and Length fields. 493 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 494 definition is the same as described in section 4.4 of 495 [I-D.ietf-ippm-ioam-data]. 497 IOAM Trace Type: A 24-bit identifier which specifies which data types 498 are used in the node data list. The definition is the same as 499 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 501 Flags: A 16-bit field. The definition is the same as described in 502 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 504 Flow ID: A 32-bit flow identifier. The definition is the same as 505 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 507 Rsvd: A 4-bit field reserved for further usage. It MUST be zero and 508 ignored on receipt. 510 4.1.4. IOAM Edge-to-Edge Option Sub-TLV 512 The IOAM edge to edge option is to carry data that is added by the 513 IOAM encapsulating node and interpreted by IOAM decapsulating node. 515 The format of IOAM edge-to-edge option Sub-TLV is defined as follows: 517 0 1 2 3 518 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 519 +-------------------------------+-------------------------------+ 520 | Type=4 | Length=4 | 521 +---------------------------------------------------------------+ 522 | Namespace ID | IOAM E2E Type | 523 +-------------------------------+-------------------------------+ 525 Fig. 7 IOAM Edge-to-Edge Option Sub-TLV 527 Where: 529 Type: 4 (to be assigned by IANA). 531 Length: 4. It is the total length of the value field not including 532 Type and Length fields. 534 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 535 definition is the same as described in section 4.6 of 536 [I-D.ietf-ippm-ioam-data]. 538 IOAM E2E Type: A 16-bit identifier which specifies which data types 539 are used in the E2E option data. The definition is the same as 540 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 542 4.2. Enhanced Alternate Marking Sub-TLV 544 The Alternate Marking [RFC8321]technique is an hybrid performance 545 measurement method, per RFC 7799 [RFC7799] classification of 546 measurement methods. Because this method is based on marking 547 consecutive batches of packets. It can be used to measure packet 548 loss, latency, and jitter on live traffic. 550 For the SR use case, since this document aims to define the control 551 plane, it is to be noted that a relevant document for the data plane 552 is [I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data 553 plane (SRv6). 555 The format of Enhanced Alternate Marking (EAM) Sub-TLV is defined as 556 follows: 558 0 1 2 3 559 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 560 +-------------------------------+-------------------------------+ 561 | Type=5 | Length=4 | 562 +-------------------------------+-------+---------------+-------+ 563 | FlowMonID | Period |H|E| R | 564 +---------------------------------------+---------------+-------+ 566 Fig. 8 Enhanced Alternate Marking Sub-TLV 568 Where: 570 Type: 5 (to be assigned by IANA). 572 Length: 4. It is the total length of the value field not including 573 Type and Length fields. 575 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 576 within the measurement domain. The definition is the same as 577 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. It is to 578 be noted that PCE also needs to maintain the uniqueness of FlowMonID 579 as described in [I-D.ietf-6man-ipv6-alt-mark]. 581 Period: Time interval between two alternate marking period. The unit 582 is second. 584 H: A flag indicating that the measurement is Hop-By-Hop. 586 E: A flag indicating that the measurement is end to end. 588 R: A 2-bit field reserved for further usage. It MUST be zero and 589 ignored on receipt. 591 5. PCEP Messages 593 5.1. The PCInitiate Message 595 A PCInitiate message is a PCEP message sent by a PCE to a PCC to 596 trigger LSP instantiation or deletion RFC 8281 [RFC8281]. 598 For the PCE-initiated LSP with the IFIT feature enabled, IFIT- 599 ATTRIBUTES TLV MUST be included in the LSPA object with the 600 PCInitiate message. 602 The Routing Backus-Naur Form (RBNF) definition of the PCInitiate 603 message RFC 8281 [RFC8281] is unchanged by this document. 605 5.2. The PCUpd Message 607 A PCUpd message is a PCEP message sent by a PCE to a PCC to update 608 the LSP parameters RFC 8231 [RFC8231]. 610 For PCE-initiated LSPs with the IFIT feature enabled, the IFIT- 611 ATTRIBUTES TLV MUST be included in the LSPA object with the PCUpd 612 message. The PCE can send this TLV to direct the PCC to change the 613 IFIT parameters. 615 The RBNF definition of the PCUpd message RFC 8231 [RFC8231] is 616 unchanged by this document. 618 5.3. The PCRpt Message 620 The PCRpt message RFC 8231 [RFC8231] is a PCEP message sent by a PCC 621 to a PCE to report the status of one or more LSPs. 623 For PCE-initiated LSPs RFC 8281 [RFC8281], the PCC creates the LSP 624 using the attributes communicated by the PCE and the local values for 625 the unspecified parameters. After the successful instantiation of 626 the LSP, the PCC automatically delegates the LSP to the PCE and 627 generates a PCRpt message to provide the status report for the LSP. 629 The RBNF definition of the PCRpt message RFC 8231 [RFC8231] is 630 unchanged by this document. 632 For both PCE-initiated and PCC-initiated LSPs, when the LSP is 633 instantiated the IFIT methods are applied as specified for the 634 corresponding data plane. [I-D.ietf-ippm-ioam-ipv6-options] and 635 [I-D.ietf-6man-ipv6-alt-mark] are the relevant documents for Segment 636 Routing over IPv6 data plane (SRv6). 638 6. Example of application to SR Policy 640 A PCC or PCE sets the IFIT-CAPABILITY TLV in the Open message during 641 the PCEP initialization phase to indicate that it supports the IFIT 642 procedures. 644 [I-D.ietf-pce-segment-routing-policy-cp] defines the PCEP extension 645 to support Segment Routing Policy Candidate Paths and in this regard 646 the SRPAG Association object is introduced. 648 The Examples of PCC Initiated SR Policy with single or multiple 649 candidate-paths and PCE Initiated SR Policy with single or multiple 650 candidate-paths are reported in 651 [I-D.ietf-pce-segment-routing-policy-cp]. 653 In case of PCC Initiated SR Policy, PCC sends PCReq message to the 654 PCE, encoding the SRPAG ASSOCIATION object and IFIT-ATTRIBUTES TLV 655 via the LSPA object. This is valid for both single and multiple 656 candidate-paths. Finally PCE returns the path in PCRep message, and 657 echoes back the SRPAG object that were used in the computation and 658 IFIT LSPA TLVs too. Additionally, PCC sends PCRpt message to the 659 PCE, including the LSP object and the SRPAG ASSOCIATION object and 660 IFIT-ATTRIBUTES TLV via the LSPA object. Then PCE computes path and 661 finally PCE updates the SR policy candidate path's ERO using PCUpd 662 message considering the IFIT LSPA TLVs too. 664 In case of PCE Initiated SR Policy, PCE sends PCInitiate message, 665 containing the SRPAG Association object and IFIT-ATTRIBUTES TLV via 666 the LSPA object. This is valid for both single and multiple 667 candidate-paths. Then PCC uses the color, endpoint and preference 668 from the SRPAG object to create a new candidate path considering the 669 IFIT LSPA TLVs too. Finally PCC sends a PCRpt message back to the 670 PCE to report the newly created Candidate Path. The PCRpt message 671 contains the SRPAG Association object and IFIT-ATTRIBUTES 672 information. 674 The procedure of enabling/disabling IFIT is simple, indeed the PCE 675 can update the IFIT-ATTRIBUTES of the LSP by sending subsequent Path 676 Computation Update Request (PCUpd) messages. PCE can update the 677 IFIT-ATTRIBUTES of the LSP by sending Path Computation State Report 678 (PCRpt) messages. 680 7. IANA Considerations 682 This document defines the new IFIT-CAPABILITY TLV and IFIT-ATTRIBUTES 683 TLV. IANA is requested to make the assignment from the "PCEP TLV 684 Type Indicators" subregistry of the "Path Computation Element 685 Protocol (PCEP) Numbers" registry as follows: 687 Value Description Reference 688 ------------------------------------------------------------- 689 TBD1 IFIT-CAPABILITY This document 691 TBD2 IFIT-ATTRIBUTES This document 693 This document specifies the IFIT-CAPABILITY TLV Flags field. IANA is 694 requested to create a registry to manage the value of the IFIT- 695 CAPABILITY TLV's Flags field within the "Path Computation Element 696 Protocol (PCEP) Numbers" registry. 698 New values are to be assigned by Standards Action RFC 8126 [RFC8126]. 699 Each bit should be tracked with the following qualities: 701 * Bit number (count from 0 as the most significant bit) 703 * Flag Name 705 * Reference 707 IANA is requested to set 5 new bits in the IFIT-CAPABILITY TLV Flags 708 Field registry, as follows: 710 Bit no. Flag Name Reference 711 --------------------------------------------------------------------- 712 27 P: IOAM Pre-allocated Trace Option flag This document 714 28 I: IOAM Incremental Trace Option flag This document 716 29 D: IOAM Directly Export Option flag This document 718 30 E: IOAM Edge-to-Edge Option This document 720 31 M: Alternate Marking Flag This document 722 This document also specifies the IFIT-ATTRIBUTES sub-TLVs. IANA is 723 requested to create an "IFIT-ATTRIBUTES Sub-TLV Types" subregistry 724 within the "Path Computation Element Protocol (PCEP) Numbers" 725 registry. 727 IANA is requested to set the Registration Procedure for this registry 728 to read as follows: 730 Range Registration Procedure 731 ------------------------------------------ 732 0-65503 IETF Review 734 65504-65535 Experimental Use 736 This document defines the following types: 738 Type Description Reference 739 --------------------------------------------------------------- 740 0 Reserved This document 742 1 IOAM Pre-allocated Trace Option This document 744 2 IOAM Incremental Trace Option This document 746 3 IOAM Directly Export Option This document 748 4 IOAM Edge-to-Edge Option This document 750 5 Enhanced Alternate Marking This document 752 6-65503 Unassigned This document 754 65504-65535 Experimental Use This document 756 This document defines a new Error-value for PCErr message of Error- 757 Type 19 (Invalid Operation). IANA is requested to allocate a new 758 Error-value within the "PCEP-ERROR Object Error Types and Values" 759 subregistry of the "Path Computation Element Protocol (PCEP) Numbers" 760 registry as follows: 762 Error-Type Meaning Error-value Reference 763 --------------------------------------------------------------- 764 19 Invalid TBD3: IFIT This document 765 Operation capability not 766 advertised 768 8. Security Considerations 770 This document defines the new IFIT-CAPABILITY TLV and IFIT Attributes 771 TLVs, which do not add any substantial new security concerns beyond 772 those already discussed in RFC 8231 [RFC8231] and RFC 8281 [RFC8281] 773 for stateful PCE operations. As per RFC 8231 [RFC8231], it is 774 RECOMMENDED that these PCEP extensions only be activated on 775 authenticated and encrypted sessions across PCEs and PCCs belonging 776 to the same administrative authority, using Transport Layer Security 777 (TLS) RFC 8253 [RFC8253], as per the recommendations and best current 778 practices in BCP 195 RFC 7525 [RFC7525] (unless explicitly set aside 779 in RFC 8253 [RFC8253]). 781 Implementation of IFIT methods (IOAM and Alternate Marking) are 782 mindful of security and privacy concerns, as explained in 783 [I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect 784 IFIT parameters in the IFIT-ATTRIBUTES sub-TLVs SHOULD not have an 785 adverse effect on the LSP as well as on the network, since it affects 786 only the operation of the telemetry methodology. 788 IFIT data MUST be propagated in a limited domain in order to avoid 789 malicious attacks and solutions to ensure this requirement are 790 respectively discussed in [I-D.ietf-ippm-ioam-data] and 791 [I-D.ietf-6man-ipv6-alt-mark]. 793 IFIT methods (IOAM and Alternate Marking) are applied within a 794 controlled domain where the network nodes are locally administered. 795 A limited administrative domain provides the network administrator 796 with the means to select, monitor and control the access to the 797 network, making it a trusted domain also for the PCEP extensions 798 defined in this document. 800 9. Contributors 802 The following people provided relevant contributions to this 803 document: 805 Dhruv Doody, Huawei Technologies, dhruv.ietf@gmail.com 807 10. Acknowledgements 809 The authors of this document would like to thank Huaimo Chen for the 810 comments and review of this document. 812 11. References 814 11.1. Normative References 816 [I-D.ietf-6man-ipv6-alt-mark] 817 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 818 Pang, "IPv6 Application of the Alternate Marking Method", 819 draft-ietf-6man-ipv6-alt-mark-04 (work in progress), March 820 2021. 822 [I-D.ietf-ippm-ioam-data] 823 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 824 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 825 progress), February 2021. 827 [I-D.ietf-ippm-ioam-direct-export] 828 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 829 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 830 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 831 export-03 (work in progress), February 2021. 833 [I-D.ietf-ippm-ioam-flags] 834 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 835 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 836 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-04 837 (work in progress), February 2021. 839 [I-D.ietf-ippm-ioam-ipv6-options] 840 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 841 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 842 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 843 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 844 ipv6-options-05 (work in progress), February 2021. 846 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 847 Requirement Levels", BCP 14, RFC 2119, 848 DOI 10.17487/RFC2119, March 1997, 849 . 851 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 852 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 853 DOI 10.17487/RFC5440, March 2009, 854 . 856 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 857 "Recommendations for Secure Use of Transport Layer 858 Security (TLS) and Datagram Transport Layer Security 859 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 860 2015, . 862 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 863 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 864 May 2016, . 866 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 867 Writing an IANA Considerations Section in RFCs", BCP 26, 868 RFC 8126, DOI 10.17487/RFC8126, June 2017, 869 . 871 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 872 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 873 May 2017, . 875 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 876 Computation Element Communication Protocol (PCEP) 877 Extensions for Stateful PCE", RFC 8231, 878 DOI 10.17487/RFC8231, September 2017, 879 . 881 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 882 "PCEPS: Usage of TLS to Provide a Secure Transport for the 883 Path Computation Element Communication Protocol (PCEP)", 884 RFC 8253, DOI 10.17487/RFC8253, October 2017, 885 . 887 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 888 Computation Element Communication Protocol (PCEP) 889 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 890 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 891 . 893 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 894 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 895 "Alternate-Marking Method for Passive and Hybrid 896 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 897 January 2018, . 899 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 900 and J. Hardwick, "Path Computation Element Communication 901 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 902 DOI 10.17487/RFC8664, December 2019, 903 . 905 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 906 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 907 . 909 11.2. Informative References 911 [I-D.ietf-pce-segment-routing-ipv6] 912 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 913 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 914 Routing leveraging the IPv6 data plane", draft-ietf-pce- 915 segment-routing-ipv6-09 (work in progress), May 2021. 917 [I-D.ietf-pce-segment-routing-policy-cp] 918 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 919 Bidgoli, "PCEP extension to support Segment Routing Policy 920 Candidate Paths", draft-ietf-pce-segment-routing-policy- 921 cp-04 (work in progress), March 2021. 923 [I-D.ietf-spring-segment-routing-policy] 924 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 925 P. Mattes, "Segment Routing Policy Architecture", draft- 926 ietf-spring-segment-routing-policy-11 (work in progress), 927 April 2021. 929 [I-D.koldychev-pce-multipath] 930 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 931 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 932 Signaling Multipath Information", draft-koldychev-pce- 933 multipath-05 (work in progress), February 2021. 935 [I-D.qin-idr-sr-policy-ifit] 936 Qin, F., Yuan, H., Zhou, T., Fioccola, G., and Y. Wang, 937 "BGP SR Policy Extensions to Enable IFIT", draft-qin-idr- 938 sr-policy-ifit-04 (work in progress), October 2020. 940 Appendix A. 942 Authors' Addresses 944 Huanan Chen 945 China Telecom 946 Guangzhou 947 China 949 Email: chenhuan6@chinatelecom.cn 951 Hang Yuan 952 UnionPay 953 1899 Gu-Tang Rd., Pudong 954 Shanghai 955 China 957 Email: yuanhang@unionpay.com 959 Tianran Zhou 960 Huawei 961 156 Beiqing Rd., Haidian District 962 Beijing 963 China 965 Email: zhoutianran@huawei.com 967 Weidong Li 968 Huawei 969 156 Beiqing Rd., Haidian District 970 Beijing 971 China 973 Email: poly.li@huawei.com 974 Giuseppe Fioccola 975 Huawei 976 Riesstrasse, 25 977 Munich 978 Germany 980 Email: giuseppe.fioccola@huawei.com 982 Yali Wang 983 Huawei 984 156 Beiqing Rd., Haidian District 985 Beijing 986 China 988 Email: wangyali11@huawei.com