idnits 2.17.1 draft-liu-idr-flowspec-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 23, 2020) is 1488 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) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Routing Working Group M. Liu 3 Internet-Draft Y. Wang 4 Intended status: Standards Track Huawei 5 Expires: September 24, 2020 R. Pang 6 China Unicom 7 March 23, 2020 9 BGP Flow Specification Extensions to Enable In-situ Flow Information 10 Telemetry (IFIT) 11 draft-liu-idr-flowspec-ifit-04 13 Abstract 15 BGP Flowspec mechanism propogates both traffic Flow Specifications 16 and Traffic Filtering Actions by making use of the Border Gateway 17 Protocol Network Layer Reachability Information (BGP NLRI) and the 18 BGP Extended Community encoding formats. In order to address the 19 automatic deployment of IPv4 unicast and VPNv4 unicast on-path flow 20 telemetry as well as IPv6 families, this document specifies a new BGP 21 Extended Community named IFIT Action Specific Extended Community to 22 distribute In-situ Flow Information Telemetry (IFIT) actions. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 24, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. IFIT Action Specific Extended Community . . . . . . . . . . . 4 68 4.1. IOAM Pre-allocated Trace Option sub-type . . . . . . . . 5 69 4.2. IOAM Incremental Trace Option sub-type . . . . . . . . . 6 70 4.3. IOAM DEX Option sub-type . . . . . . . . . . . . . . . . 6 71 4.4. IOAM Edge-to-Edge Option sub-type . . . . . . . . . . . . 7 72 4.5. Enhanced Alternate Marking Option sub-type . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 8.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 At present, a family of on-path flow telemetry techniques referred in 84 [I-D.song-opsawg-ifit-framework] are emerging, including In-situ OAM 85 (IOAM) [I-D.ietf-ippm-ioam-data], Postcard-Based Telemetry (PBT) 86 [I-D.song-ippm-postcard-based-telemetry], IOAM Direct Export (DEX) 87 [I-D.ioamteam-ippm-ioam-direct-export], Enhanced Alternate Marking 88 (EAM) [I-D.zhou-ippm-enhanced-alternate-marking]. we categorize these 89 on-path telemetry echniques as the hybrid OAM type I according to the 90 classification defined in [RFC7799]. These techniques provide flow 91 information on the entire forwarding path on a per-packet basis in 92 real time, which are useful for application-aware network operations 93 not only in data center and enterprise networks but also in carrier 94 networks which may cross multiple domains. The data provided by on- 95 path telemetry are especially useful for network operations in 96 aspects of SLA compliance, service path enforcement, fault diagnosis, 97 and network resource optimization, etc. In IFIT reflection-loop 98 architecture [I-D.song-opsawg-ifit-framework], an IFIT functionality 99 needs to choose a suite of telemetry tecchniques and enable initial 100 techniques to the data plane in accordance to the monitoring and 101 measurement requirements. Then the IFIT head nodes need to determine 102 the target flows and packets to apply the IFIT-specific functions and 103 the telemetry data sets. 105 However, enabling only a single underlying on-path telemetry 106 technique may lead to defective result. A comprehensive solution 107 needs the flexibility to switch between different underlying 108 techniques and enable different IFIT option types to adapt to 109 different network conditions and different application requirements. 110 It's useful for application-aware network operations to enable 111 desired IFIT option types to the target flows dynamically. 113 As we know, Dissemination of Flow Specification Rules 114 [I-D.ietf-idr-rfc5575bis] provides a protocol extension for 115 propagation of traffic flow information for the purpose of rate 116 limiting, filtering, shaping, classifying or redirecting. And BGP 117 extended community encoding formats can be used to propagate traffic 118 filtering actions along with the flow specification NLRI. Those 119 traffic filtering actions encode actions a routing system can take if 120 the packet matches the flow specifications. And the other document 121 [I-D.ietf-idr-flow-spec-v6] extends BGP Flowspec 122 [I-D.ietf-idr-rfc5575bis] and to make it also usable and applicable 123 to IPv6 data packets. 125 From an operational perspective, the utilization of BGP Flowspec as 126 the carrier for the specific flow information allows a network 127 service provider to reuse BGP route distribute infrastructure. 128 Therefore, this document defines the IFIT Action Specific Extended 129 Community to enable the application of IPv4 unicast and VPNv4 unicast 130 on-path flow telemetry as well as IPv6 families. 132 2. Terminologies 134 IFIT: In-situ Flow Information Telemetry 136 NLRI: Network Layer Reachability Information 138 3. Motivation 140 The IFIT functionality, which enables the future autonomous network 141 operation, will pick one of proper In-situ Flow Information Telemetry 142 techniques and apply a flow, packet, and data selection policy to 143 monitor the specific traffic flow for application-aware network 144 operation. In current deployments, there have been relatively static 145 methods, ACL-like CLI and NETCONF with YANG model to configure the 146 specific flows or packets to be monitored on the relevant IFIT- 147 capable nodes. However, with the evolution of Intent-based and 148 autonomous network operation, and the trends of network 149 virtualization, network convergence, and packet-optical integration, 150 the future data plane telemetry will support an on-demand and 151 interactive fashion. Flexibility and extensibility of telemetry data 152 defining and acquiring must be considered. Therefore, flexible 153 deployment of IFIT option types based on the real-time telemetry data 154 analysis results and telemetry requirements of different applications 155 is needed. 157 BGP Flowspec mechanism is preferred in the reflective-loop network 158 telemetry system. This document defines IFIT Action Specific 159 Extended Community to enable IFIT functionality for the relevant 160 flows that match the Traffic Flow Specifications along with the BGP 161 NLRI defined in [I-D.ietf-idr-rfc5575bis] and 162 [I-D.ietf-idr-flow-spec-v6]. The IFIT Action Specific Extended 163 Community instructs a routing system to add the IFIT-Option-Types 164 into packets of flows and update relevant IFIT-Data-Fields in packets 165 that traverse. 167 4. IFIT Action Specific Extended Community 169 This section defines a new BGP Extended Community and different sub- 170 types in accordance with different IFIT option types. 172 Traffic Filtering Actions that are standardized as BGP Extended 173 Community, which is encoded as an 8-octet quantity containing Type 174 field and Value field [RFC4360]. The Types are to be assigned by 175 IANA registry. The Value field contains Traffic Filtering Action 176 values. 178 In the IFIT framework architecture, there are a few of available 179 option types for the specified traffic flow, e.g. IOAM pre- 180 allocated/incremental trace [I-D.ietf-ippm-ioam-data], IOM Edge-to- 181 Edge [I-D.ietf-ippm-ioam-data], IOAM Direct Export (DEX) 182 [I-D.ioamteam-ippm-ioam-direct-export], Enhanced Alternate Marking 183 (EAM) [I-D.zhou-ippm-enhanced-alternate-marking], etc. As different 184 IFIT option types have different formats of parameters, following 185 defines the Type and various sub-types of Extended Communities in 186 accordance with different IFIT option types. 188 o Type tt: IFIT Action 190 o Sub-type ss1: IOAM Pre-allocated Trace Option 191 o Sub-type ss2: IOAM Incremental Trace Option 193 o Sub-type ss3: IOAM DEX Option 195 o Sub-type ss4: IOAM Edge-to-Edge Option 197 o Sub-type ss5: Enhanced Alternate Marking Option 199 IFIT Action do not interfere with other BGP Flow Specification 200 Traffic Filtering Action defined in [I-D.ietf-idr-rfc5575bis] and 201 [I-D.ietf-idr-flow-spec-v6]. 203 In the following sections, the different IFIT Action Specific Extened 204 Communities encoding formats are presented. 206 4.1. IOAM Pre-allocated Trace Option sub-type 208 The IOAM tracing data is expected to be collected at every node that 209 a packet traverses to ensure visibility into the entire path a packet 210 takes within an IOAM domain. The pre-allocated tracing option will 211 create pre-allocated space for each node to populate its information. 213 The format of IOAM pre-allocated trace option Extended Community is 214 defined as follows: 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 | Sub-type | NamespaceID | 220 +---------------------------------------------------------------+ 221 | Flags | IOAM-Trace-Type | Rsvd | 222 +---------------------------------------------------------------+ 224 Fig. 1 IOAM Pre-allocated Trace Option Extended Community Encoding 226 Where: 228 Type: to be assigned by IANA. 230 Sub-type: to be assigned by IANA. 232 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 233 definition is the same as described in section 4.4 234 of[I-D.ietf-ippm-ioam-data] . 236 Flags: A 4-bit field. The definition is the same as described in [I- 237 D.ietf-ippm-ioam-flags] and section 4.4 of [I-D.ietf-ippm-ioam-data]. 239 IOAM-Trace-Type: A 24-bit identifier which specifies which data types 240 are used in the node data list. The definition is the same as 241 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 243 Rsvd: A 4-bit field reserved for further usage. It should be set to 244 zero and must be ignored during decoding. 246 4.2. IOAM Incremental Trace Option sub-type 248 The incremental tracing option contains a variable node data fields 249 where each node allocates and pushes its node data immediately 250 following the option header. 252 The format of IOAM incremental trace option Extended Community is 253 defined as follows: 255 0 1 2 3 256 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 257 +-------------------------------+-------------------------------+ 258 | Type | Sub-type | NamespaceID | 259 +---------------------------------------------------------------+ 260 | Flags | IOAM-Trace-Type | Rsvd | 261 +---------------------------------------------------------------+ 263 Fig. 2 IOAM Incremental Trace Option Extended Community Encoding 265 Where: 267 Type: to be assigned by IANA. 269 Sub-type: to be assigned by IANA. 271 All the other fields definistion is the same as the pre-allocated 272 trace option Extended Community in section 3.2.1. 274 4.3. IOAM DEX Option sub-type 276 The DEX option is used as a trigger to export IOAM data to a 277 collector. Moreover, IOAM nodes may send exported data for all 278 traversing packets that carry the DEX option, or may selectively 279 export data only for a subset of these packets. The DEX option 280 specifies which data fields should be exported to the collector, as 281 specified in Section 3.2 of [I-D.ioamteam-ippm-ioam-direct-export]. 283 The format of IOAM DEX option Extended Community is defined as 284 follows: 286 0 1 2 3 287 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 288 +-------------------------------+-------------------------------+ 289 | Type | Sub-type | NamespaceID | 290 +---------------------------------------------------------------+ 291 | IOAM-Trace-Type | Flags | 292 +---------------------------------------------------------------+ 294 Fig. 3 IOAM DEX Option Extended Community Encoding 296 Where: 298 Type: to be assigned by IANA. 300 Sub-type: to be assigned by IANA. 302 Namespace-ID: a 16-bit identifier of the IOAM namespace, as defined 303 in section 4.4 of [I-D.ietf-ippm-ioam-data]. 305 IOAM-Trace-Type: a 24-bit identifier which specifies which data 306 fields should be exported. The format of this field is as defined in 307 section 4.4 of[I-D.ietf-ippm-ioam-data]. 309 Flags: A 8-bit field, comprised of 8 one-bit subfields. Flags are 310 allocated by IANA. 312 4.4. IOAM Edge-to-Edge Option sub-type 314 The IOAM edge to edge option is to carry data that is added by the 315 IOAM encapsulating node and interpreted by IOAM decapsulating node. 317 The format of IOAM edge-to-edge option Extended Community is defined 318 as follows: 320 0 1 2 3 321 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 322 +-------------------------------+-------------------------------+ 323 | Type | Sub-type | Rsvd | 324 +---------------------------------------------------------------+ 325 | NamespaceID | IOAM-E2E-Type | 326 +---------------------------------------------------------------+ 328 Fig. 4 IOAM Edge-to-Edge Option Extended Community Encoding 330 Where: 332 Type: to be assigned by IANA. 334 Sub-type: to be assigned by IANA. 336 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 337 definition is the same as described in section 4.6 338 of[I-D.ietf-ippm-ioam-data]. 340 IOAM-E2E-Type: A 16-bit identifier which specifies which data types 341 are used in the E2E option data. The definition is the same as 342 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 344 Rsvd: A 16-bit field reserved for further usage. It should be set to 345 zero. 347 4.5. Enhanced Alternate Marking Option sub-type 349 The Alternate Marking [RFC8321] technique is an hybrid performance 350 measurement method and can be used to measure packet loss, latency, 351 and jitter on live traffic because it is based on marking consecutive 352 batches of packets. 354 The Enhanced Alternate Marking (EAM) 355 [I-D.zhou-ippm-enhanced-alternate-marking] defines data fields for 356 the alternate marking with enough space, in particular for Postcard- 357 based Telemetry. More information can be considered within the 358 alternate marking field to facilitate the efficiency and ease the 359 deployment. 361 The format of EAM Option Extended Community is defined as follows: 363 0 1 2 3 364 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 365 +-------------------------------+-------------------------------+ 366 | Type | Sub-type | Rsvd | 367 +---------------+---------------+-------+---------------+-------+ 368 | FlowMonID | Period | Rsvd | 369 +---------------------------------------+---------------+-------+ 371 Fig. 5 Enhanced Alternate Marking Option Extended Community Encoding 373 Where: 375 Type: to be assigned by IANA. 377 Sub-type: to be assigned by IANA. 379 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 380 within the measurement domain. The definition is the same as 381 described in section 2 of [I-D.zhou-ippm-enhanced-alternate-marking]. 383 Period: A 8-bit field. Time interval between two alternate marking 384 period. The unit is second. 386 Rsvd: A 4-bit field reserved for further usage. It should be set to 387 zero. 389 5. IANA Considerations 391 This document requests a new Transitive Extended Community Type and 392 five new registery sub-types. The new Transitive Extended Community 393 Type name shall be "IFIT Action Extended Community (Sub-Types are 394 defined in the "IFIT Action Extended Community Sub-Type" registery)". 396 Type Value Name 397 --------- ---------- 398 TBD IFIT Action 400 Sub-type Value Name 401 -------------- ---------- 402 TBD IOAM Pre-allocated Trace Option 403 TBD IOAM Incremental Trace Option 404 TBD IOAM DEX Option 405 TBD IOAM E2E Option 406 TBD Enhanced Alternate Marking 408 6. Security Considerations 410 No new security issues are introduced to the BGP Flow Specifications 411 and Traffic Filtering Action in [I-D.ietf-idr-flow-spec-v6] and 412 [I-D.ietf-idr-rfc5575bis]. 414 7. Acknowledgements 416 TBD. 418 8. References 419 8.1. Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, 423 DOI 10.17487/RFC2119, March 1997, 424 . 426 [RFC4360] "BGP Extended Communities Attribute", 427 . 429 [RFC7799] "Active and Passive Metrics and Methods (with Hybrid Types 430 In-Between)", . 432 [RFC8321] "Alternate-Marking Method for Passive and Hybrid 433 Performance Monitoring", 434 . 436 8.2. Informative References 438 [I-D.ietf-idr-flow-spec-v6] 439 "Dissemination of Flow Specification Rules for IPv6", 440 . 443 [I-D.ietf-idr-rfc5575bis] 444 "Dissemination of Flow Specification Rules", 445 . 448 [I-D.ietf-ippm-ioam-data] 449 "Data Fields for In-situ OAM", 450 . 453 [I-D.ioamteam-ippm-ioam-direct-export] 454 "In-situ OAM Direct Exporting", 455 . 458 [I-D.song-ippm-postcard-based-telemetry] 459 "Postcard-based On-Path Flow Data Telemetry", 460 . 463 [I-D.song-opsawg-ifit-framework] 464 "In-situ Flow Information Telemetry Framework", 465 . 468 [I-D.zhou-ippm-enhanced-alternate-marking] 469 "Enhanced Alternate Marking Method", 470 . 473 Authors' Addresses 475 Min Liu 476 Huawei 477 156 Beiqing Rd., Haidian District 478 Beijing 479 China 481 Email: lucy_liumin@huawei.com 483 Yali Wang 484 Huawei 485 156 Beiqing Rd., Haidian District 486 Beijing 487 China 489 Email: wangyali11@huawei.com 491 Ran Pang 492 China Unicom 493 9 Shouti South Rd., Haidian District 494 Beijing 495 China 497 Email: pangran@chinaunicom.cn