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