idnits 2.17.1 draft-qin-idr-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 1386 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 (-02) exists of draft-chen-pce-sr-policy-ifit-00 == Outdated reference: A later version (-17) exists of draft-ietf-6man-ipv6-alt-mark-01 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 == 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 (-22) exists of draft-ietf-spring-segment-routing-policy-07 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR F. Qin 3 Internet-Draft China Mobile 4 Intended status: Standards Track H. Yuan 5 Expires: January 9, 2021 UnionPay 6 T. Zhou 7 M. Liu 8 G. Fioccola 9 Huawei 10 July 8, 2020 12 BGP SR Policy Extensions to Enable IFIT 13 draft-qin-idr-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 BGP 23 to distribute SR policies carrying IFIT information. So that IFIT 24 methods 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 . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. IOAM Pre-allocated Trace Option Sub-TLV . . . . . . . . . 4 70 3.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . . . 5 71 3.3. IOAM Directly Export Option Sub-TLV . . . . . . . . . . . 6 72 3.4. IOAM Edge-to-Edge Option Sub-TLV . . . . . . . . . . . . 7 73 4. SR Policy for Enhanced Alternate Marking . . . . . . . . . . 8 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 8.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy] 86 is a set of candidate SR paths consisting of one or more segment 87 lists and necessary path attributes. It enables instantiation of an 88 ordered list of segments with a specific intent for traffic steering. 90 In-situ Flow Information Telemetry (IFIT) refers to network OAM 91 applications that apply dataplane on-path telemetry techniques, 92 including In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] and Alternate 93 Marking [RFC8321]. It can provide flow information on the entire 94 forwarding path on a per- packet basis in real time. 96 An automatic network requires the Service Level Agreement (SLA) 97 monitoring on the deployed service. So that the system can quickly 98 detect the SLA violation or the performance degradation, hence to 99 change the service deployment. The SR policy native IFIT can 100 facilitate the closed loop control, and enable the automation of SR 101 service. 103 This document defines extensions to BGP to distribute SR policies 104 carrying IFIT information. So that IFIT behavior can be enabled 105 automatically when the SR policy is applied. 107 This BGP extension allows to signal the IFIT capabilities together 108 with the SR-policy. In this way IFIT methods are automatically 109 activated and running. The flexibility and dynamicity of the IFIT 110 applications are given by the use of additional functions on the 111 controller and on the network nodes, but this is out of scope here. 113 It is to be noted the companion document 114 [I-D.chen-pce-sr-policy-ifit] that proposes the PCEP extension to 115 enable IFIT applications for SR policy. 117 2. IFIT Attributes in SR Policy 119 As defined in [I-D.ietf-idr-segment-routing-te-policy], the SR Policy 120 encoding structure is as follows: 122 SR Policy SAFI NLRI: 123 Attributes: 124 Tunnel Encaps Attribute (23) 125 Tunnel Type: SR Policy 126 Binding SID 127 Preference 128 Priority 129 Policy Name 130 Explicit NULL Label Policy (ENLP) 131 Segment List 132 Weight 133 Segment 134 Segment 135 ... 136 ... 138 A candidate path includes multiple SR paths, each of which is 139 specified by a segment list. IFIT can be applied to the candidate 140 path, so that all the SR paths can be monitored in the same way. The 141 new SR Policy encoding structure is expressed as below: 143 SR Policy SAFI NLRI: 144 Attributes: 145 Tunnel Encaps Attribute (23) 146 Tunnel Type: SR Policy 147 Binding SID 148 Preference 149 Priority 150 Policy Name 151 Explicit NULL Label Policy (ENLP) 152 IFIT Attributes 153 Segment List 154 Weight 155 Segment 156 Segment 157 ... 158 ... 160 IFIT attributes can be attached at the candidate path level as sub- 161 TLVs. There may be different IFIT tools. The following sections 162 will describe the requirement and usage of different IFIT tools, and 163 define the corresponding sub-TLV encoding in BGP. 165 Note that the IFIT attributes here described can also be generalized 166 and included as sub-TLVs for other SAFIs and NLRIs. 168 3. SR Policy for IOAM 170 In-situ Operations, Administration, and Maintenance (IOAM) 171 [I-D.ietf-ippm-ioam-data] records operational and telemetry 172 information in the packet while the packet traverses a path between 173 two points in the network. In terms of the classification given in 174 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 175 mechanisms can be leveraged where active OAM do not apply or do not 176 offer the desired results. 178 When SR policy enables the IOAM, the IOAM header will be inserted 179 into every packet of the traffic that is steered into the SR paths. 181 This document aims to define the control plane. While a relevant 182 document for the data plane is [I-D.ietf-ippm-ioam-ipv6-options] for 183 Segment Routing over IPv6 data plane (SRv6). 185 3.1. IOAM Pre-allocated Trace Option Sub-TLV 187 The IOAM tracing data is expected to be collected at every node that 188 a packet traverses to ensure visibility into the entire path a packet 189 takes within an IOAM domain. The preallocated tracing option will 190 create pre-allocated space for each node to populate its information. 192 The format of IOAM pre-allocated trace option sub-TLV is defined as 193 follows: 195 0 1 2 3 196 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 197 +---------------+---------------+-------------------------------+ 198 | Type | Length | Namespace ID | 199 +---------------+---------------+--------------+--------+-------+ 200 | IOAM Trace Type | Flags | Rsvd | 201 +----------------------------------------------+--------+-------+ 203 Fig. 1 IOAM Pre-allocated Trace Option Sub-TLV 205 Where: 207 Type: to be assigned by IANA. 209 Length: the total length of the value field not including Type and 210 Length fields. 212 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 213 definition is the same as described in section 4.4 of 214 [I-D.ietf-ippm-ioam-data]. 216 IOAM Trace Type: A 24-bit identifier which specifies which data types 217 are used in the node data list. The definition is the same as 218 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 220 Flags: A 4-bit field. The definition is the same as described in 221 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 222 [I-D.ietf-ippm-ioam-data]. 224 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 226 3.2. IOAM Incremental Trace Option Sub-TLV 228 The incremental tracing option contains a variable node data fields 229 where each node allocates and pushes its node data immediately 230 following the option header. 232 The format of IOAM incremental trace option sub-TLV is defined as 233 follows: 235 0 1 2 3 236 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 237 +---------------+---------------+-------------------------------+ 238 | Type | Length | Namespace ID | 239 +---------------+---------------+--------------+--------+-------+ 240 | IOAM Trace Type | Flags | Rsvd | 241 +----------------------------------------------+--------+-------+ 243 Fig. 2 IOAM Incremental Trace Option Sub-TLV 245 Where: 247 Type: to be assigned by IANA. 249 Length: the total length of the value field not including Type and 250 Length fields. 252 All the other fields definistion is the same as the pre-allocated 253 trace option sub-TLV in section 4.1. 255 3.3. IOAM Directly Export Option Sub-TLV 257 IOAM directly export option is used as a trigger for IOAM data to be 258 directly exported to a collector without being pushed into in-flight 259 data packets. 261 The format of IOAM directly export option sub-TLV is defined as 262 follows: 264 0 1 2 3 265 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 266 +---------------+---------------+ 267 | Type | Length | 268 +-----------------------------------------------+---------------+ 269 | Namespace ID | Flags | 270 +-------------------------------+---------------+---------------+ 271 | IOAM Trace Type | Rsvd | 272 +-----------------------------------------------+---------------+ 273 | Flow ID | 274 +---------------------------------------------------------------+ 276 Fig. 3 IOAM Directly Export Option Sub-TLV 278 Where: 280 Type: to be assigned by IANA. 282 Length: the total length of the value field not including Type and 283 Length fields. 285 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 286 definition is the same as described in section 4.4 of 287 [I-D.ietf-ippm-ioam-data]. 289 IOAM Trace Type: A 24-bit identifier which specifies which data types 290 are used in the node data list. The definition is the same as 291 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 293 Flags: A 16-bit field. The definition is the same as described in 294 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 296 Flow ID: A 32-bit flow identifier. The definition is the same as 297 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 299 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 301 3.4. IOAM Edge-to-Edge Option Sub-TLV 303 The IOAM edge to edge option is to carry data that is added by the 304 IOAM encapsulating node and interpreted by IOAM decapsulating node. 306 The format of IOAM edge-to-edge option sub-TLV is defined as follows: 308 0 1 2 3 309 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 310 +---------------+---------------+ 311 | Type | Length | 312 +-----------------------------------------------+---------------+ 313 | Namespace ID | IOAM E2E Type | 314 +-------------------------------+-------------------------------+ 316 Fig. 4 IOAM Edge-to-Edge Option Sub-TLV 318 Where: 320 Type: to be assigned by IANA. 322 Length: the total length of the value field not including Type and 323 Length fields. 325 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 326 definition is the same as described in section 4.6 of 327 [I-D.ietf-ippm-ioam-data]. 329 IOAM E2E Type: A 16-bit identifier which specifies which data types 330 are used in the E2E option data. The definition is the same as 331 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 333 4. SR Policy for Enhanced Alternate Marking 335 The Alternate Marking [RFC8321]technique is an hybrid performance 336 measurement method, per RFC 7799 [RFC7799] classification of 337 measurement methods. Because this method is based on marking 338 consecutive batches of packets. It can be used to measure packet 339 loss, latency, and jitter on live traffic. 341 This document aims to define the control plane. While a relevant 342 document for the data plane is [I-D.ietf-6man-ipv6-alt-mark] for 343 Segment Routing over IPv6 data plane (SRv6). 345 The format of EAM sub-TLV is defined as follows: 347 0 1 2 3 348 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 349 +---------------+---------------+ 350 | Type | Length | 351 +-------------------------------+-------+-------+-------+-------+ 352 | FlowMonID | Period | Rsvd | 353 +---------------------------------------+---------------+-------+ 355 Where: 357 Type: to be assigned by IANA. 359 Length: the total length of the value field not including Type and 360 Length fields. 362 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 363 within the measurement domain. The definition is the same as 364 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. 366 Period: Time interval between two alternate marking period. The unit 367 is second. 369 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 371 5. IANA Considerations 373 This document defines new sub-TLVs in the registry "BGP Tunnel 374 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 376 Codepoint Description Reference 377 ------------------------------------------------------------- 378 TBD1 IOAM Pre-allocated Trace This document 379 Option Sub-TLV 380 TBD2 IOAM Incremental Trace This document 381 Option Sub-TLV 382 TBD3 IOAM Directly Export This document 383 Option Sub-TLV 384 TBD4 IOAM Edge-to-Edge This document 385 Option Sub-TLV 386 TBD5 Enhanced Alternate Marking This document 387 Sub-TLV 389 6. Security Considerations 391 TBD. 393 7. Acknowledgements 395 8. References 397 8.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 405 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 406 May 2016, . 408 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 409 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 410 "Alternate-Marking Method for Passive and Hybrid 411 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 412 January 2018, . 414 8.2. Informative References 416 [I-D.chen-pce-sr-policy-ifit] 417 Chen, H., Yuan, H., Zhou, T., Li, W., and G. Fioccola, 418 "PCEP SR Policy Extensions to Enable IFIT", draft-chen- 419 pce-sr-policy-ifit-00 (work in progress), January 2020. 421 [I-D.ietf-6man-ipv6-alt-mark] 422 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 423 Pang, "IPv6 Application of the Alternate Marking Method", 424 draft-ietf-6man-ipv6-alt-mark-01 (work in progress), June 425 2020. 427 [I-D.ietf-idr-segment-routing-te-policy] 428 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 429 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 430 Routing Policies in BGP", draft-ietf-idr-segment-routing- 431 te-policy-09 (work in progress), May 2020. 433 [I-D.ietf-ippm-ioam-data] 434 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 435 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 436 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 437 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 438 ietf-ippm-ioam-data-09 (work in progress), March 2020. 440 [I-D.ietf-ippm-ioam-direct-export] 441 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 442 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 443 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 444 export-00 (work in progress), February 2020. 446 [I-D.ietf-ippm-ioam-flags] 447 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 448 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 449 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-01 450 (work in progress), January 2020. 452 [I-D.ietf-ippm-ioam-ipv6-options] 453 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 454 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 455 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 456 "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 457 ipv6-options-01 (work in progress), March 2020. 459 [I-D.ietf-spring-segment-routing-policy] 460 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 461 P. Mattes, "Segment Routing Policy Architecture", draft- 462 ietf-spring-segment-routing-policy-07 (work in progress), 463 May 2020. 465 Appendix A. 467 Authors' Addresses 469 Fengwei Qin 470 China Mobile 471 No. 32 Xuanwumenxi Ave., Xicheng District 472 Beijing 473 China 475 Email: qinfengwei@chinamobile.com 477 Hang Yuan 478 UnionPay 479 1899 Gu-Tang Rd., Pudong 480 Shanghai 481 China 483 Email: yuanhang@unionpay.com 485 Tianran Zhou 486 Huawei 487 156 Beiqing Rd., Haidian District 488 Beijing 489 China 491 Email: zhoutianran@huawei.com 493 Min Liu 494 Huawei 495 156 Beiqing Rd., Haidian District 496 Beijing 497 China 499 Email: lucy.liumin@huawei.com 501 Giuseppe Fioccola 502 Huawei 503 Riesstrasse, 25 504 Munich 505 Germany 507 Email: giuseppe.fioccola@huawei.com