idnits 2.17.1 draft-chen-pce-sr-policy-ifit-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2020) is 1379 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-08 == Outdated reference: A later version (-04) exists of draft-qin-idr-sr-policy-ifit-01 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 11, 2021 UnionPay 6 T. Zhou 7 W. Li 8 G. Fioccola 9 Y. Wang 10 Huawei 11 July 10, 2020 13 PCEP SR Policy Extensions to Enable IFIT 14 draft-chen-pce-sr-policy-ifit-02 16 Abstract 18 Segment Routing (SR) policy is a set of candidate SR paths consisting 19 of one or more segment lists and necessary path attributes. It 20 enables instantiation of an ordered list of segments with a specific 21 intent for traffic steering. In-situ Flow Information Telemetry 22 (IFIT) refers to network OAM applications that apply dataplane on- 23 path telemetry techniques. This document defines extensions to PCEP 24 to distribute SR policies carrying IFIT information. So that IFIT 25 behavior can be enabled automatically when the SR policy is applied. 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 RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 11, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. IFIT Attributes in SR Policy . . . . . . . . . . . . . . . . 3 69 3. SR Policy for IOAM . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. IOAM Pre-allocated Trace Option TLV . . . . . . . . . . . 4 71 3.2. IOAM Incremental Trace Option TLV . . . . . . . . . . . . 5 72 3.3. IOAM Directly Export Option TLV . . . . . . . . . . . . . 5 73 3.4. IOAM Edge-to-Edge Option TLV . . . . . . . . . . . . . . 6 74 4. SR Policy for Enhanced Alternate Marking . . . . . . . . . . 7 75 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5.1. PCE Initiated SR Policy . . . . . . . . . . . . . . . . . 8 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 9.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy] 89 is a set of candidate SR paths consisting of one or more segment 90 lists and necessary path attributes. It enables instantiation of an 91 ordered list of segments with a specific intent for traffic steering. 93 In-situ Flow Information Telemetry (IFIT) refers to network OAM 94 applications that apply dataplane on-path telemetry techniques, 95 including In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] and Alternate 96 Marking [RFC8321]. It can provide flow information on the entire 97 forwarding path on a per- packet basis in real time. 99 An automatic network requires the Service Level Agreement (SLA) 100 monitoring on the deployed service. So that the system can quickly 101 detect the SLA violation or the performance degradation, hence to 102 change the service deployment. The SR policy native IFIT can 103 facilitate the closed loop control, and enable the automation of SR 104 service. 106 This document defines extensions to PCEP to distribute SR policies 107 carrying IFIT information. So that IFIT behavior can be enabled 108 automatically when the SR policy is applied. 110 This PCEP extension allows to signal the IFIT capabilities together 111 with the SR-policy. In this way IFIT methods are automatically 112 activated and running. The flexibility and dynamicity of the IFIT 113 applications are given by the use of additional functions on the 114 controller and on the network nodes, but this is out of scope here. 116 It is to be noted the companion document [I-D.qin-idr-sr-policy-ifit] 117 that proposes the BGP extension to enable IFIT applications for SR 118 policy. 120 2. IFIT Attributes in SR Policy 122 SR Policy Association Group (SRPAG) is defined in 123 [I-D.ietf-pce-segment-routing-policy-cp] to extend PCEP to support 124 association among candidate paths of a given SR policy. SR Policy 125 Identifiers TLV, SR Policy Name TLV, SR Policy Candidate Path 126 Identifiers TLV, and SR Policy Candidate Path Preference TLV are 127 introduced to construct the SR policy structure. 129 This document is to add IFIT attribute TLVs to the SRPAG. The 130 following sections will describe the requirement and usage of 131 different IFIT modes, and define the corresponding TLV encoding in 132 PCEP. 134 Note that the IFIT attributes here described can also be generalized 135 and included as TLVs for other Association Groups. In this regard 136 RFC 8697 [RFC8697] defines the generic mechanism to associate sets of 137 LSPs and a set of attributes, for example IFIT. 139 3. SR Policy for IOAM 141 In-situ Operations, Administration, and Maintenance (IOAM) 142 [I-D.ietf-ippm-ioam-data] records operational and telemetry 143 information in the packet while the packet traverses a path between 144 two points in the network. In terms of the classification given in 145 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 146 mechanisms can be leveraged where active OAM do not apply or do not 147 offer the desired results. 149 When SR policy enables the IOAM, the IOAM header will be inserted 150 into every packet of the traffic that is steered into the SR paths. 152 This document aims to define the control plane. While a relevant 153 document for the data plane is [I-D.ietf-ippm-ioam-ipv6-options] for 154 Segment Routing over IPv6 data plane (SRv6). 156 3.1. IOAM Pre-allocated Trace Option TLV 158 The IOAM tracing data is expected to be collected at every node that 159 a packet traverses to ensure visibility into the entire path a packet 160 takes within an IOAM domain. The preallocated tracing option will 161 create pre-allocated space for each node to populate its information. 163 The format of IOAM pre-allocated trace option TLV is defined as 164 follows: 166 0 1 2 3 167 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 168 +-------------------------------+-------------------------------+ 169 | Type | Length | 170 +---------------------------------------------------------------+ 171 | Namespace ID | Rsvd1 | 172 +-------------------------------+-----------------------+-------+ 173 | IOAM Trace Type | Flags | Rsvd2 | 174 +----------------------------------------------+--------+-------+ 176 Fig. 1 IOAM Pre-allocated Trace Option TLV 178 Where: 180 Type: to be assigned by IANA. 182 Length: the total length of the value field not including Type and 183 Length fields. 185 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 186 definition is the same as described in section 4.4 of 187 [I-D.ietf-ippm-ioam-data]. 189 IOAM Trace Type: A 24-bit identifier which specifies which data types 190 are used in the node data list. The definition is the same as 191 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 193 Flags: A 4-bit field. The definition is the same as described in 194 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 195 [I-D.ietf-ippm-ioam-data]. 197 Rsvd1: A 16-bit field reserved for further usage. It MUST be zero. 199 Rsvd2: A 4-bit field reserved for further usage. It MUST be zero. 201 3.2. IOAM Incremental Trace Option TLV 203 The incremental tracing option contains a variable node data fields 204 where each node allocates and pushes its node data immediately 205 following the option header. 207 The format of IOAM incremental trace option TLV is defined as 208 follows: 210 0 1 2 3 211 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 212 +-------------------------------+-------------------------------+ 213 | Type | Length | 214 +---------------------------------------------------------------+ 215 | Namespace ID | Rsvd1 | 216 +-------------------------------+-----------------------+-------+ 217 | IOAM Trace Type | Flags | Rsvd2 | 218 +----------------------------------------------+--------+-------+ 220 Fig. 2 IOAM Incremental Trace Option TLV 222 Where: 224 Type: to be assigned by IANA. 226 Length: the total length of the value field not including Type and 227 Length fields. 229 All the other fields definition is the same as the pre-allocated 230 trace option TLV in section 4.1. 232 3.3. IOAM Directly Export Option TLV 234 IOAM directly export option is used as a trigger for IOAM data to be 235 directly exported to a collector without being pushed into in-flight 236 data packets. 238 The format of IOAM directly export option TLV is defined as follows: 240 0 1 2 3 241 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 242 +-------------------------------+-------------------------------+ 243 | Type | Length | 244 +---------------------------------------------------------------+ 245 | Namespace ID | Flags | 246 +-------------------------------+---------------+---------------+ 247 | IOAM Trace Type | Rsvd | 248 +-----------------------------------------------+---------------+ 249 | Flow ID | 250 +---------------------------------------------------------------+ 252 Fig. 3 IOAM Directly Export Option TLV 254 Where: 256 Type: to be assigned by IANA. 258 Length: the total length of the value field not including Type and 259 Length fields. 261 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 262 definition is the same as described in section 4.4 of 263 [I-D.ietf-ippm-ioam-data]. 265 IOAM Trace Type: A 24-bit identifier which specifies which data types 266 are used in the node data list. The definition is the same as 267 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 269 Flags: A 16-bit field. The definition is the same as described in 270 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 272 Flow ID: A 32-bit flow identifier. The definition is the same as 273 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 275 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 277 3.4. IOAM Edge-to-Edge Option TLV 279 The IOAM edge to edge option is to carry data that is added by the 280 IOAM encapsulating node and interpreted by IOAM decapsulating node. 282 The format of IOAM edge-to-edge option TLV is defined as follows: 284 0 1 2 3 285 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 286 +-------------------------------+-------------------------------+ 287 | Type | Length | 288 +---------------------------------------------------------------+ 289 | Namespace ID | IOAM E2E Type | 290 +-------------------------------+-------------------------------+ 292 Fig. 4 IOAM Edge-to-Edge Option TLV 294 Where: 296 Type: to be assigned by IANA. 298 Length: the total length of the value field not including Type and 299 Length fields. 301 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 302 definition is the same as described in section 4.6 of 303 [I-D.ietf-ippm-ioam-data]. 305 IOAM E2E Type: A 16-bit identifier which specifies which data types 306 are used in the E2E option data. The definition is the same as 307 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 309 4. SR Policy for Enhanced Alternate Marking 311 The Alternate Marking [RFC8321]technique is an hybrid performance 312 measurement method, per RFC 7799 [RFC7799] classification of 313 measurement methods. Because this method is based on marking 314 consecutive batches of packets. It can be used to measure packet 315 loss, latency, and jitter on live traffic. 317 This document aims to define the control plane. While a relevant 318 document for the data plane is [I-D.ietf-6man-ipv6-alt-mark] for 319 Segment Routing over IPv6 data plane (SRv6). 321 The format of EAM TLV is defined as follows: 323 0 1 2 3 324 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 325 +-------------------------------+-------------------------------+ 326 | Type | Length | 327 +-------------------------------+-------+---------------+-------+ 328 | FlowMonID | Period | Rsvd | 329 +---------------------------------------+---------------+-------+ 331 Where: 333 Type: to be assigned by IANA. 335 Length: the total length of the value field not including Type and 336 Length fields. 338 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 339 within the measurement domain. The definition is the same as 340 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. 342 Period: Time interval between two alternate marking period. The unit 343 is second. 345 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 347 5. Examples 349 5.1. PCE Initiated SR Policy 351 The interactions between the PCE and PCC is the same as described in 352 [I-D.ietf-pce-segment-routing-policy-cp]. The only change is to take 353 the additional optional IFIT TLVs within the SRPAG object. 355 PCE sends PCInitiate message, containing the SRPAG Association 356 object. The Association Source is set to the IP address of the PCC 357 and the Association ID is set to 0xFFFF. 359 PCC uses the color, endpoint, preference and IFIT option from the 360 SRPAG object to create a new candidate path. If no SR policy exists 361 to hold the candidate path, then a new SR policy is created to hold 362 the new candidate-path. The Originator of the candidate path is set 363 to be the address of the PCE that is sending the PCInitiate message. 365 PCC sends a PCRpt message back to the PCE to report the newly created 366 Candidate Path. The PCRpt message contains the SRPAG Association 367 object. The Association Source is set to the IP address of the PCC 368 and the Association ID is set to a number that PCC locally chose to 369 represent the SR Policy. 371 6. IANA Considerations 373 This document defines new IFIT TLVs for carrying additional 374 information about SR policy and SR candidate paths. IANA is 375 requested to make the assignment of a new value for the existing 376 "PCEP TLV Type Indicators" registry as follows: 378 Codepoint Description Reference 379 ------------------------------------------------------------- 380 TBD1 IOAM Pre-allocated Trace This document 381 Option TLV 382 TBD2 IOAM Incremental Trace This document 383 Option TLV 384 TBD3 IOAM Directly Export This document 385 Option TLV 386 TBD4 IOAM Edge-to-Edge This document 387 Option TLV 388 TBD5 Enhanced Alternate Marking This document 389 TLV 391 7. Security Considerations 393 TBD. 395 8. Acknowledgements 397 9. References 399 9.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, 403 DOI 10.17487/RFC2119, March 1997, 404 . 406 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 407 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 408 May 2016, . 410 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 411 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 412 "Alternate-Marking Method for Passive and Hybrid 413 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 414 January 2018, . 416 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 417 Dhody, D., and Y. Tanaka, "Path Computation Element 418 Communication Protocol (PCEP) Extensions for Establishing 419 Relationships between Sets of Label Switched Paths 420 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 421 . 423 9.2. Informative References 425 [I-D.ietf-6man-ipv6-alt-mark] 426 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 427 Pang, "IPv6 Application of the Alternate Marking Method", 428 draft-ietf-6man-ipv6-alt-mark-01 (work in progress), June 429 2020. 431 [I-D.ietf-ippm-ioam-data] 432 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 433 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 434 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 435 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 436 ietf-ippm-ioam-data-09 (work in progress), March 2020. 438 [I-D.ietf-ippm-ioam-direct-export] 439 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 440 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 441 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 442 export-00 (work in progress), February 2020. 444 [I-D.ietf-ippm-ioam-flags] 445 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 446 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 447 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-01 448 (work in progress), January 2020. 450 [I-D.ietf-ippm-ioam-ipv6-options] 451 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 452 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 453 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 454 "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 455 ipv6-options-01 (work in progress), March 2020. 457 [I-D.ietf-pce-segment-routing-policy-cp] 458 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 459 Bidgoli, "PCEP extension to support Segment Routing Policy 460 Candidate Paths", draft-ietf-pce-segment-routing-policy- 461 cp-00 (work in progress), June 2020. 463 [I-D.ietf-spring-segment-routing-policy] 464 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 465 P. Mattes, "Segment Routing Policy Architecture", draft- 466 ietf-spring-segment-routing-policy-08 (work in progress), 467 July 2020. 469 [I-D.qin-idr-sr-policy-ifit] 470 Qin, F., Yuan, H., Zhou, T., Min, L., and G. Fioccola, 471 "BGP SR Policy Extensions to Enable IFIT", draft-qin-idr- 472 sr-policy-ifit-01 (work in progress), July 2020. 474 Appendix A. 476 Authors' Addresses 478 Huanan Chen 479 China Telecom 480 Guangzhou 481 China 483 Email: chenhuan6@chinatelecom.cn 485 Hang Yuan 486 UnionPay 487 1899 Gu-Tang Rd., Pudong 488 Shanghai 489 China 491 Email: yuanhang@unionpay.com 493 Tianran Zhou 494 Huawei 495 156 Beiqing Rd., Haidian District 496 Beijing 497 China 499 Email: zhoutianran@huawei.com 501 Weidong Li 502 Huawei 503 156 Beiqing Rd., Haidian District 504 Beijing 505 China 507 Email: poly.li@huawei.com 508 Giuseppe Fioccola 509 Huawei 510 Riesstrasse, 25 511 Munich 512 Germany 514 Email: giuseppe.fioccola@huawei.com 516 Yali Wang 517 Huawei 518 156 Beiqing Rd., Haidian District 519 Beijing 520 China 522 Email: wangyali11@huawei.com