idnits 2.17.1 draft-chen-pce-sr-policy-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 -- The document date (July 8, 2020) is 1387 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) ** Downref: Normative reference to an Informational RFC: RFC 7799 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) == 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-09 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-00 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-01 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-01 == 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-07 == Outdated reference: A later version (-04) exists of draft-qin-idr-sr-policy-ifit-00 Summary: 2 errors (**), 0 flaws (~~), 9 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 9, 2021 UnionPay 6 T. Zhou 7 W. Li 8 G. Fioccola 9 Huawei 10 July 8, 2020 12 PCEP SR Policy Extensions to Enable IFIT 13 draft-chen-pce-sr-policy-ifit-01 15 Abstract 17 Segment Routing (SR) policy is a set of candidate SR paths consisting 18 of one or more segment lists and necessary path attributes. It 19 enables instantiation of an ordered list of segments with a specific 20 intent for traffic steering. In-situ Flow Information Telemetry 21 (IFIT) refers to network OAM applications that apply dataplane on- 22 path telemetry techniques. This document defines extensions to PCEP 23 to distribute SR policies carrying IFIT information. So that IFIT 24 behavior can be enabled automatically when the SR policy is applied. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 9, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. IFIT Attributes in SR Policy . . . . . . . . . . . . . . . . 3 68 3. SR Policy for IOAM . . . . . . . . . . . . . . . . . . . . . 3 69 3.1. IOAM Pre-allocated Trace Option TLV . . . . . . . . . . . 4 70 3.2. IOAM Incremental Trace Option TLV . . . . . . . . . . . . 5 71 3.3. IOAM Directly Export Option TLV . . . . . . . . . . . . . 5 72 3.4. IOAM Edge-to-Edge Option TLV . . . . . . . . . . . . . . 6 73 4. SR Policy for Enhanced Alternate Marking . . . . . . . . . . 7 74 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 5.1. PCE Initiated SR Policy . . . . . . . . . . . . . . . . . 8 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 9.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy] 88 is a set of candidate SR paths consisting of one or more segment 89 lists and necessary path attributes. It enables instantiation of an 90 ordered list of segments with a specific intent for traffic steering. 92 In-situ Flow Information Telemetry (IFIT) refers to network OAM 93 applications that apply dataplane on-path telemetry techniques, 94 including In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] and Alternate 95 Marking [RFC8321]. It can provide flow information on the entire 96 forwarding path on a per- packet basis in real time. 98 An automatic network requires the Service Level Agreement (SLA) 99 monitoring on the deployed service. So that the system can quickly 100 detect the SLA violation or the performance degradation, hence to 101 change the service deployment. The SR policy native IFIT can 102 facilitate the closed loop control, and enable the automation of SR 103 service. 105 This document defines extensions to PCEP to distribute SR policies 106 carrying IFIT information. So that IFIT behavior can be enabled 107 automatically when the SR policy is applied. 109 This PCEP extension allows to signal the IFIT capabilities together 110 with the SR-policy. In this way IFIT methods are automatically 111 activated and running. The flexibility and dynamicity of the IFIT 112 applications are given by the use of additional functions on the 113 controller and on the network nodes, but this is out of scope here. 115 It is to be noted the companion document [I-D.qin-idr-sr-policy-ifit] 116 that proposes the BGP extension to enable IFIT applications for SR 117 policy. 119 2. IFIT Attributes in SR Policy 121 SR Policy Association Group (SRPAG) is defined in 122 [I-D.ietf-pce-segment-routing-policy-cp] to extend PCEP to support 123 association among candidate paths of a given SR policy. SR Policy 124 Identifiers TLV, SR Policy Name TLV, SR Policy Candidate Path 125 Identifiers TLV, and SR Policy Candidate Path Preference TLV are 126 introduced to construct the SR policy structure. 128 This document is to add IFIT attribute TLVs to the SRPAG. The 129 following sections will describe the requirement and usage of 130 different IFIT modes, and define the corresponding TLV encoding in 131 PCEP. 133 Note that the IFIT attributes here described can also be generalized 134 and included as TLVs for other Association Groups. In this regard 135 RFC 8697 [RFC8697] defines the generic mechanism to associate sets of 136 LSPs and a set of attributes, for example IFIT. 138 3. SR Policy for IOAM 140 In-situ Operations, Administration, and Maintenance (IOAM) 141 [I-D.ietf-ippm-ioam-data] records operational and telemetry 142 information in the packet while the packet traverses a path between 143 two points in the network. In terms of the classification given in 144 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 145 mechanisms can be leveraged where active OAM do not apply or do not 146 offer the desired results. 148 When SR policy enables the IOAM, the IOAM header will be inserted 149 into every packet of the traffic that is steered into the SR paths. 151 This document aims to define the control plane. While a relevant 152 document for the data plane is [I-D.ietf-ippm-ioam-ipv6-options] for 153 Segment Routing over IPv6 data plane (SRv6). 155 3.1. IOAM Pre-allocated Trace Option TLV 157 The IOAM tracing data is expected to be collected at every node that 158 a packet traverses to ensure visibility into the entire path a packet 159 takes within an IOAM domain. The preallocated tracing option will 160 create pre-allocated space for each node to populate its information. 162 The format of IOAM pre-allocated trace option TLV is defined as 163 follows: 165 0 1 2 3 166 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 167 +-------------------------------+-------------------------------+ 168 | Type | Length | 169 +---------------------------------------------------------------+ 170 | Namespace ID | Rsvd1 | 171 +-------------------------------+-----------------------+-------+ 172 | IOAM Trace Type | Flags | Rsvd2 | 173 +----------------------------------------------+--------+-------+ 175 Fig. 1 IOAM Pre-allocated Trace Option TLV 177 Where: 179 Type: to be assigned by IANA. 181 Length: the total length of the value field not including Type and 182 Length fields. 184 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 185 definition is the same as described in section 4.4 of 186 [I-D.ietf-ippm-ioam-data]. 188 IOAM Trace Type: A 24-bit identifier which specifies which data types 189 are used in the node data list. The definition is the same as 190 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 192 Flags: A 4-bit field. The definition is the same as described in 193 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 194 [I-D.ietf-ippm-ioam-data]. 196 Rsvd1: A 16-bit field reserved for further usage. It MUST be zero. 198 Rsvd2: A 4-bit field reserved for further usage. It MUST be zero. 200 3.2. IOAM Incremental Trace Option TLV 202 The incremental tracing option contains a variable node data fields 203 where each node allocates and pushes its node data immediately 204 following the option header. 206 The format of IOAM incremental trace option TLV is defined as 207 follows: 209 0 1 2 3 210 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 211 +-------------------------------+-------------------------------+ 212 | Type | Length | 213 +---------------------------------------------------------------+ 214 | Namespace ID | Rsvd1 | 215 +-------------------------------+-----------------------+-------+ 216 | IOAM Trace Type | Flags | Rsvd2 | 217 +----------------------------------------------+--------+-------+ 219 Fig. 2 IOAM Incremental Trace Option TLV 221 Where: 223 Type: to be assigned by IANA. 225 Length: the total length of the value field not including Type and 226 Length fields. 228 All the other fields definition is the same as the pre-allocated 229 trace option TLV in section 4.1. 231 3.3. IOAM Directly Export Option TLV 233 IOAM directly export option is used as a trigger for IOAM data to be 234 directly exported to a collector without being pushed into in-flight 235 data packets. 237 The format of IOAM directly export option TLV is defined as follows: 239 0 1 2 3 240 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 241 +-------------------------------+-------------------------------+ 242 | Type | Length | 243 +---------------------------------------------------------------+ 244 | Namespace ID | Flags | 245 +-------------------------------+---------------+---------------+ 246 | IOAM Trace Type | Rsvd | 247 +-----------------------------------------------+---------------+ 248 | Flow ID | 249 +---------------------------------------------------------------+ 251 Fig. 3 IOAM Directly Export Option TLV 253 Where: 255 Type: to be assigned by IANA. 257 Length: the total length of the value field not including Type and 258 Length fields. 260 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 261 definition is the same as described in section 4.4 of 262 [I-D.ietf-ippm-ioam-data]. 264 IOAM Trace Type: A 24-bit identifier which specifies which data types 265 are used in the node data list. The definition is the same as 266 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 268 Flags: A 16-bit field. The definition is the same as described in 269 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 271 Flow ID: A 32-bit flow identifier. The definition is the same as 272 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 274 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 276 3.4. IOAM Edge-to-Edge Option TLV 278 The IOAM edge to edge option is to carry data that is added by the 279 IOAM encapsulating node and interpreted by IOAM decapsulating node. 281 The format of IOAM edge-to-edge option TLV is defined as follows: 283 0 1 2 3 284 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 285 +-------------------------------+-------------------------------+ 286 | Type | Length | 287 +---------------------------------------------------------------+ 288 | Namespace ID | IOAM E2E Type | 289 +-------------------------------+-------------------------------+ 291 Fig. 4 IOAM Edge-to-Edge Option TLV 293 Where: 295 Type: to be assigned by IANA. 297 Length: the total length of the value field not including Type and 298 Length fields. 300 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 301 definition is the same as described in section 4.6 of 302 [I-D.ietf-ippm-ioam-data]. 304 IOAM E2E Type: A 16-bit identifier which specifies which data types 305 are used in the E2E option data. The definition is the same as 306 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 308 4. SR Policy for Enhanced Alternate Marking 310 The Alternate Marking [RFC8321]technique is an hybrid performance 311 measurement method, per RFC 7799 [RFC7799] classification of 312 measurement methods. Because this method is based on marking 313 consecutive batches of packets. It can be used to measure packet 314 loss, latency, and jitter on live traffic. 316 This document aims to define the control plane. While a relevant 317 document for the data plane is [I-D.ietf-6man-ipv6-alt-mark] for 318 Segment Routing over IPv6 data plane (SRv6). 320 The format of EAM TLV is defined as follows: 322 0 1 2 3 323 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 324 +-------------------------------+-------------------------------+ 325 | Type | Length | 326 +-------------------------------+-------+---------------+-------+ 327 | FlowMonID | Period | Rsvd | 328 +---------------------------------------+---------------+-------+ 330 Where: 332 Type: to be assigned by IANA. 334 Length: the total length of the value field not including Type and 335 Length fields. 337 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 338 within the measurement domain. The definition is the same as 339 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. 341 Period: Time interval between two alternate marking period. The unit 342 is second. 344 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 346 5. Examples 348 5.1. PCE Initiated SR Policy 350 The interactions between the PCE and PCC is the same as described in 351 [I-D.ietf-pce-segment-routing-policy-cp]. The only change is to take 352 the additional optional IFIT TLVs within the SRPAG object. 354 PCE sends PCInitiate message, containing the SRPAG Association 355 object. The Association Source is set to the IP address of the PCC 356 and the Association ID is set to 0xFFFF. 358 PCC uses the color, endpoint, preference and IFIT option from the 359 SRPAG object to create a new candidate path. If no SR policy exists 360 to hold the candidate path, then a new SR policy is created to hold 361 the new candidate-path. The Originator of the candidate path is set 362 to be the address of the PCE that is sending the PCInitiate message. 364 PCC sends a PCRpt message back to the PCE to report the newly created 365 Candidate Path. The PCRpt message contains the SRPAG Association 366 object. The Association Source is set to the IP address of the PCC 367 and the Association ID is set to a number that PCC locally chose to 368 represent the SR Policy. 370 6. IANA Considerations 372 This document defines new IFIT TLVs for carrying additional 373 information about SR policy and SR candidate paths. IANA is 374 requested to make the assignment of a new value for the existing 375 "PCEP TLV Type Indicators" registry as follows: 377 Codepoint Description Reference 378 ------------------------------------------------------------- 379 TBD1 IOAM Pre-allocated Trace This document 380 Option TLV 381 TBD2 IOAM Incremental Trace This document 382 Option TLV 383 TBD3 IOAM Directly Export This document 384 Option TLV 385 TBD4 IOAM Edge-to-Edge This document 386 Option TLV 387 TBD5 Enhanced Alternate Marking This document 388 TLV 390 7. Security Considerations 392 TBD. 394 8. Acknowledgements 396 9. References 398 9.1. Normative References 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, 402 DOI 10.17487/RFC2119, March 1997, 403 . 405 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 406 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 407 May 2016, . 409 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 410 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 411 "Alternate-Marking Method for Passive and Hybrid 412 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 413 January 2018, . 415 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 416 Dhody, D., and Y. Tanaka, "Path Computation Element 417 Communication Protocol (PCEP) Extensions for Establishing 418 Relationships between Sets of Label Switched Paths 419 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 420 . 422 9.2. Informative References 424 [I-D.ietf-6man-ipv6-alt-mark] 425 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 426 Pang, "IPv6 Application of the Alternate Marking Method", 427 draft-ietf-6man-ipv6-alt-mark-01 (work in progress), June 428 2020. 430 [I-D.ietf-ippm-ioam-data] 431 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 432 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 433 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 434 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 435 ietf-ippm-ioam-data-09 (work in progress), March 2020. 437 [I-D.ietf-ippm-ioam-direct-export] 438 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 439 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 440 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 441 export-00 (work in progress), February 2020. 443 [I-D.ietf-ippm-ioam-flags] 444 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 445 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 446 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-01 447 (work in progress), January 2020. 449 [I-D.ietf-ippm-ioam-ipv6-options] 450 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 451 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 452 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 453 "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 454 ipv6-options-01 (work in progress), March 2020. 456 [I-D.ietf-pce-segment-routing-policy-cp] 457 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 458 Bidgoli, "PCEP extension to support Segment Routing Policy 459 Candidate Paths", draft-ietf-pce-segment-routing-policy- 460 cp-00 (work in progress), June 2020. 462 [I-D.ietf-spring-segment-routing-policy] 463 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 464 P. Mattes, "Segment Routing Policy Architecture", draft- 465 ietf-spring-segment-routing-policy-07 (work in progress), 466 May 2020. 468 [I-D.qin-idr-sr-policy-ifit] 469 Qin, F., Yuan, H., Zhou, T., Min, L., and G. Fioccola, 470 "BGP SR Policy Extensions to Enable IFIT", draft-qin-idr- 471 sr-policy-ifit-00 (work in progress), January 2020. 473 Appendix A. 475 Authors' Addresses 477 Huanan Chen 478 China Telecom 479 Guangzhou 480 China 482 Email: chenhuan6@chinatelecom.cn 484 Hang Yuan 485 UnionPay 486 1899 Gu-Tang Rd., Pudong 487 Shanghai 488 China 490 Email: yuanhang@unionpay.com 492 Tianran Zhou 493 Huawei 494 156 Beiqing Rd., Haidian District 495 Beijing 496 China 498 Email: zhoutianran@huawei.com 500 Weidong Li 501 Huawei 502 156 Beiqing Rd., Haidian District 503 Beijing 504 China 506 Email: poly.li@huawei.com 507 Giuseppe Fioccola 508 Huawei 509 Riesstrasse, 25 510 Munich 511 Germany 513 Email: giuseppe.fioccola@huawei.com