idnits 2.17.1 draft-chen-pce-sr-policy-ifit-00.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 (January 6, 2020) is 1570 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) == Unused Reference: 'RFC8321' is defined on line 400, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7799 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-06) exists of draft-barth-pce-segment-routing-policy-cp-04 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-08 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 == Outdated reference: A later version (-07) exists of draft-kumar-ippm-ifa-01 == Outdated reference: A later version (-15) exists of draft-mirsky-ippm-hybrid-two-step-04 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-06 == Outdated reference: A later version (-21) exists of draft-song-opsawg-ifit-framework-10 == Outdated reference: A later version (-14) exists of draft-zhou-ippm-enhanced-alternate-marking-04 Summary: 2 errors (**), 0 flaws (~~), 11 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: July 9, 2020 UnionPay 6 T. Zhou 7 W. Li 8 G. Fioccola 9 Huawei 10 January 6, 2020 12 PCEP SR Policy Extensions to Enable IFIT 13 draft-chen-pce-sr-policy-ifit-00 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) provides a reference framework that supports network OAM 22 applications to apply dataplane on-path telemetry techniques 23 acquiring data about a packet on its forwarding path. This document 24 defines extensions to PCEP to distribute SR policies carrying IFIT 25 information. So that IFIT behavior can be enabled automatically when 26 the SR policy is applied. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 9, 2020. 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 . . . . . . . . . . . . . . . . . . . . . 9 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) 94 [I-D.song-opsawg-ifit-framework] provides a reference framework that 95 supports network OAM applications to apply dataplane on-path 96 telemetry techniques, including In-situ OAM (IOAM) 97 [I-D.ietf-ippm-ioam-data], Postcard Based Telemetry (PBT) 98 [I-D.song-ippm-postcard-based-telemetry], In-band Flow Analyzer (IFA) 99 [I-D.kumar-ippm-ifa], Enhanced Alternate Marking (EAM) 100 [I-D.zhou-ippm-enhanced-alternate-marking], and Hybrid Two Steps 101 (HTS) [I-D.mirsky-ippm-hybrid-two-step]. It can provide flow 102 information on the entire forwarding path on a per- packet basis in 103 real time. 105 An automatic network requires the Service Level Agreement (SLA) 106 monitoring on the deployed service. So that the system can quickly 107 detect the SLA violation or the performance degradation, hence to 108 change the service deployment. The SR policy native IFIT can 109 facilitate the closed loop control, and enable the automation of SR 110 service. 112 This document defines extensions to PCEP to distribute SR policies 113 carrying IFIT information. So that IFIT behavior can be enabled 114 automatically when the SR policy is applied. 116 2. IFIT Attributes in SR Policy 118 SR Policy Association Group (SRPAG) is defined in 119 [I-D.barth-pce-segment-routing-policy-cp] to extend PCEP to support 120 association among candidate paths of a given SR policy. SR Policy 121 Identifiers TLV, SR Policy Name TLV, SR Policy Candidate Path 122 Identifiers TLV, and SR Policy Candidate Path Preference TLV are 123 introduced to construct the SR policy structure. 125 This document is to add IFIT attribute TLVs to the SRPAG. The 126 following sections will describe the requirement and usage of 127 different IFIT modes, and define the corresponding TLV encoding in 128 PCEP. 130 3. SR Policy for IOAM 132 In-situ Operations, Administration, and Maintenance (IOAM) 133 [I-D.ietf-ippm-ioam-data] records operational and telemetry 134 information in the packet while the packet traverses a path between 135 two points in the network. In terms of the classification given in 136 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 137 mechanisms can be leveraged where active OAM do not apply or do not 138 offer the desired results. 140 When SR policy enables the IOAM, the IOAM header will be inserted 141 into every packet of the traffic that is steered into the SR paths. 143 3.1. IOAM Pre-allocated Trace Option TLV 145 The IOAM tracing data is expected to be collected at every node that 146 a packet traverses to ensure visibility into the entire path a packet 147 takes within an IOAM domain. The preallocated tracing option will 148 create pre-allocated space for each node to populate its information. 150 The format of IOAM pre-allocated trace option TLV is defined as 151 follows: 153 0 1 2 3 154 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 155 +-------------------------------+-------------------------------+ 156 | Type | Length | 157 +---------------------------------------------------------------+ 158 | Namespace ID | Rsvd1 | 159 +-------------------------------+-----------------------+-------+ 160 | IOAM Trace Type | Flags | Rsvd2 | 161 +----------------------------------------------+--------+-------+ 163 Fig. 1 IOAM Pre-allocated Trace Option TLV 165 Where: 167 Type: to be assigned by IANA. 169 Length: the total length of the value field not including Type and 170 Length fields. 172 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 173 definition is the same as described in section 4.4 of 174 [I-D.ietf-ippm-ioam-data]. 176 IOAM Trace Type: A 24-bit identifier which specifies which data types 177 are used in the node data list. The definition is the same as 178 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 180 Flags: A 4-bit field. The definition is the same as described in 181 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 182 [I-D.ietf-ippm-ioam-data]. 184 Rsvd1: A 16-bit field reserved for further usage. It MUST be zero. 186 Rsvd2: A 4-bit field reserved for further usage. It MUST be zero. 188 3.2. IOAM Incremental Trace Option TLV 190 The incremental tracing option contains a variable node data fields 191 where each node allocates and pushes its node data immediately 192 following the option header. 194 The format of IOAM incremental trace option TLV is defined as 195 follows: 197 0 1 2 3 198 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 199 +-------------------------------+-------------------------------+ 200 | Type | Length | 201 +---------------------------------------------------------------+ 202 | Namespace ID | Rsvd1 | 203 +-------------------------------+-----------------------+-------+ 204 | IOAM Trace Type | Flags | Rsvd2 | 205 +----------------------------------------------+--------+-------+ 207 Fig. 2 IOAM Incremental Trace Option TLV 209 Where: 211 Type: to be assigned by IANA. 213 Length: the total length of the value field not including Type and 214 Length fields. 216 All the other fields definition is the same as the pre-allocated 217 trace option TLV in section 4.1. 219 3.3. IOAM Directly Export Option TLV 221 IOAM directly export option is used as a trigger for IOAM data to be 222 directly exported to a collector without being pushed into in-flight 223 data packets. 225 The format of IOAM directly export option TLV is defined as follows: 227 0 1 2 3 228 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 229 +-------------------------------+-------------------------------+ 230 | Type | Length | 231 +---------------------------------------------------------------+ 232 | Namespace ID | Flags | 233 +-------------------------------+---------------+---------------+ 234 | IOAM Trace Type | Rsvd | 235 +-----------------------------------------------+---------------+ 236 | Flow ID | 237 +---------------------------------------------------------------+ 239 Fig. 3 IOAM Directly Export Option TLV 241 Where: 243 Type: to be assigned by IANA. 245 Length: the total length of the value field not including Type and 246 Length fields. 248 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 249 definition is the same as described in section 4.4 of 250 [I-D.ietf-ippm-ioam-data]. 252 IOAM Trace Type: A 24-bit identifier which specifies which data types 253 are used in the node data list. The definition is the same as 254 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 256 Flags: A 16-bit field. The definition is the same as described in 257 section 3.2 of [I-D.ioamteam-ippm-ioam-direct-export]. 259 Flow ID: A 32-bit flow identifier. The definition is the same as 260 described in section 3.2 of [I-D.ioamteam-ippm-ioam-direct-export]. 262 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 264 3.4. IOAM Edge-to-Edge Option TLV 266 The IOAM edge to edge option is to carry data that is added by the 267 IOAM encapsulating node and interpreted by IOAM decapsulating node. 269 The format of IOAM edge-to-edge option TLV is defined as follows: 271 0 1 2 3 272 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 273 +-------------------------------+-------------------------------+ 274 | Type | Length | 275 +---------------------------------------------------------------+ 276 | Namespace ID | IOAM E2E Type | 277 +-------------------------------+-------------------------------+ 279 Fig. 4 IOAM Edge-to-Edge Option TLV 281 Where: 283 Type: to be assigned by IANA. 285 Length: the total length of the value field not including Type and 286 Length fields. 288 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 289 definition is the same as described in section 4.6 of 290 [I-D.ietf-ippm-ioam-data]. 292 IOAM E2E Type: A 16-bit identifier which specifies which data types 293 are used in the E2E option data. The definition is the same as 294 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 296 4. SR Policy for Enhanced Alternate Marking 298 The Alternate Marking [RFC8321]technique is an hybrid performance 299 measurement method, per RFC 7799 [RFC7799] classification of 300 measurement methods. Because this method is based on marking 301 consecutive batches of packets. It can be used to measure packet 302 loss, latency, and jitter on live traffic. 304 The Enhanced Alternate Marking (EAM) 305 [I-D.zhou-ippm-enhanced-alternate-marking] defines data fields for 306 the alternate marking with enough space, in particular for Postcard- 307 based Telemetry. More information can be considered within the 308 alternate marking field to facilitate the efficiency and ease the 309 deployment. 311 The format of EAM TLV is defined as follows: 313 0 1 2 3 314 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 315 +-------------------------------+-------------------------------+ 316 | Type | Length | 317 +-------------------------------+-------+---------------+-------+ 318 | FlowMonID | Period | Rsvd | 319 +---------------------------------------+---------------+-------+ 321 Where: 323 Type: to be assigned by IANA. 325 Length: the total length of the value field not including Type and 326 Length fields. 328 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 329 within the measurement domain. The definition is the same as 330 described in section 2 of [I-D.zhou-ippm-enhanced-alternate-marking]. 332 Period: Time interval between two alternate marking period. The unit 333 is second. 335 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 337 5. Examples 339 5.1. PCE Initiated SR Policy 341 The interactions between the PCE and PCC is the same as described in 342 [I-D.barth-pce-segment-routing-policy-cp]. The only change is to 343 take the additional optional IFIT TLVs within the SRPAG object. 345 PCE sends PCInitiate message, containing the SRPAG Association 346 object. The Association Source is set to the IP address of the PCC 347 and the Association ID is set to 0xFFFF. 349 PCC uses the color, endpoint, preference and IFIT option from the 350 SRPAG object to create a new candidate path. If no SR policy exists 351 to hold the candidate path, then a new SR policy is created to hold 352 the new candidate-path. The Originator of the candidate path is set 353 to be the address of the PCE that is sending the PCInitiate message. 355 PCC sends a PCRpt message back to the PCE to report the newly created 356 Candidate Path. The PCRpt message contains the SRPAG Association 357 object. The Association Source is set to the IP address of the PCC 358 and the Association ID is set to a number that PCC locally chose to 359 represent the SR Policy. 361 6. IANA Considerations 363 This document defines new IFIT TLVs for carrying additional 364 information about SR policy and SR candidate paths. IANA is 365 requested to make the assignment of a new value for the existing 366 "PCEP TLV Type Indicators" registry as follows: 368 Codepoint Description Reference 369 ------------------------------------------------------------- 370 TBD1 IOAM Pre-allocated Trace This document 371 Option TLV 372 TBD2 IOAM Incremental Trace This document 373 Option TLV 374 TBD3 IOAM Directly Export This document 375 Option TLV 376 TBD4 IOAM Edge-to-Edge This document 377 Option TLV 378 TBD5 Enhanced Alternate Marking This document 379 TLV 381 7. Security Considerations 383 TBD. 385 8. Acknowledgements 387 9. References 389 9.1. Normative References 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, 393 DOI 10.17487/RFC2119, March 1997, 394 . 396 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 397 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 398 May 2016, . 400 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 401 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 402 "Alternate-Marking Method for Passive and Hybrid 403 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 404 January 2018, . 406 9.2. Informative References 408 [I-D.barth-pce-segment-routing-policy-cp] 409 Koldychev, M., Sivabalan, S., Barth, C., Li, C., and H. 410 Bidgoli, "PCEP extension to support Segment Routing Policy 411 Candidate Paths", draft-barth-pce-segment-routing-policy- 412 cp-04 (work in progress), October 2019. 414 [I-D.ietf-ippm-ioam-data] 415 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 416 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 417 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 418 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 419 ietf-ippm-ioam-data-08 (work in progress), October 2019. 421 [I-D.ietf-ippm-ioam-flags] 422 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 423 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 424 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-00 425 (work in progress), October 2019. 427 [I-D.ietf-spring-segment-routing-policy] 428 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 429 P. Mattes, "Segment Routing Policy Architecture", draft- 430 ietf-spring-segment-routing-policy-06 (work in progress), 431 December 2019. 433 [I-D.ioamteam-ippm-ioam-direct-export] 434 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 435 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 436 OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct- 437 export-00 (work in progress), October 2019. 439 [I-D.kumar-ippm-ifa] 440 Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook, 441 H., Ghanwani, A., Cai, D., Ou, H., and L. Yizhou, "Inband 442 Flow Analyzer", draft-kumar-ippm-ifa-01 (work in 443 progress), February 2019. 445 [I-D.mirsky-ippm-hybrid-two-step] 446 Mirsky, G., Lingqiang, W., and G. Zhui, "Hybrid Two-Step 447 Performance Measurement Method", draft-mirsky-ippm-hybrid- 448 two-step-04 (work in progress), October 2019. 450 [I-D.song-ippm-postcard-based-telemetry] 451 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 452 "Postcard-based On-Path Flow Data Telemetry", draft-song- 453 ippm-postcard-based-telemetry-06 (work in progress), 454 October 2019. 456 [I-D.song-opsawg-ifit-framework] 457 Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "In- 458 situ Flow Information Telemetry", draft-song-opsawg-ifit- 459 framework-10 (work in progress), December 2019. 461 [I-D.zhou-ippm-enhanced-alternate-marking] 462 Zhou, T., Fioccola, G., Li, Z., Lee, S., and M. Cociglio, 463 "Enhanced Alternate Marking Method", draft-zhou-ippm- 464 enhanced-alternate-marking-04 (work in progress), October 465 2019. 467 Appendix A. 469 Authors' Addresses 471 Huanan Chen 472 China Telecom 473 Guangzhou 474 China 476 Email: chenhuan6@chinatelecom.cn 478 Hang Yuan 479 UnionPay 480 1899 Gu-Tang Rd., Pudong 481 Shanghai 482 China 484 Email: yuanhang@unionpay.com 486 Tianran Zhou 487 Huawei 488 156 Beiqing Rd., Haidian District 489 Beijing 490 China 492 Email: zhoutianran@huawei.com 493 Weidong Li 494 Huawei 495 156 Beiqing Rd., Haidian District 496 Beijing 497 China 499 Email: poly.li@huawei.com 501 Giuseppe Fioccola 502 Huawei 503 Riesstrasse, 25 504 Munich 505 Germany 507 Email: giuseppe.fioccola@huawei.com