idnits 2.17.1 draft-wang-idr-bgp-ifit-capabilities-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 (July 14, 2020) is 1382 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: 'I-D.ietf-bess-srv6-services' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'I-D.wang-idr-bgp-ls-ifit-node-capability' is defined on line 366, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-03 == Outdated reference: A later version (-08) exists of draft-ietf-idr-next-hop-capability-05 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-07 ** Downref: Normative reference to an Informational draft: draft-song-ippm-postcard-based-telemetry (ref. 'I-D.song-ippm-postcard-based-telemetry') == Outdated reference: A later version (-14) exists of draft-zhou-ippm-enhanced-alternate-marking-05 == Outdated reference: A later version (-21) exists of draft-song-opsawg-ifit-framework-12 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Wang 3 Internet-Draft S. Zhuang 4 Intended status: Standards Track Y. Gu 5 Expires: January 15, 2021 Huawei 6 July 14, 2020 8 BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) 9 Capabilities 10 draft-wang-idr-bgp-ifit-capabilities-00 12 Abstract 14 This document defines extensions to BGP to advertise the In-situ Flow 15 Information Telemetry (IFIT) capabilities. Within an IFIT 16 measurement domain, the capability is meant to be advertised from the 17 IFIT tail node to the head node to assist the head node to determine 18 whether a particular IFIT Option type can be enabled. This 19 facilitates the deployment of IFIT measurements on a per-service and 20 on-demand basis. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 15, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 64 3. IFIT Capabilities . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Option 1: Extending BGP Extended Community for IFIT 66 Capability . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. IPv4-Address-Specific IFIT Extended Community . . . . . . 4 68 4.2. IPv6-Address-Specific IFIT Extended Community . . . . . . 5 69 5. Option 2: Extendng BGP Next-Hop Capability for IFIT 70 Capability . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 10.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 At present, a family of on-path flow telemetry techniques referred in 83 [I-D.song-opsawg-ifit-framework] are emerging, including In-situ OAM 84 (IOAM) [I-D.ietf-ippm-ioam-data], Postcard-Based Telemetry (PBT) 85 [I-D.song-ippm-postcard-based-telemetry], IOAM Direct Export (DEX) 86 [I-D.ioamteam-ippm-ioam-direct-export], Enhanced Alternate Marking 87 (EAM) [I-D.zhou-ippm-enhanced-alternate-marking]. 89 In-situ Flow Information Telemetry (IFIT) determines network 90 performance by measuring the packet loss and latency of service 91 packets transmitted in an IP network. This feature is easy to deploy 92 and provides an accurate assessment of network performance. 94 The IFIT model describes how service flows are measured to obtain 95 packet loss and latency. Specifically, IFIT measures the packet loss 96 and latency of service flows on the ingress and egress of the transit 97 network, and summarizes desired performance indicators. The IFIT 98 model is composed of three objects: target flow, transit network, and 99 measurement system. The transit network only bears target flows. 100 The target flows are not generated or terminated on the transit 101 network. The transit network can be a Layer 2 (L2), Layer 3 (L3), or 102 L2+L3 hybrid network. Each node on the transit network must be 103 reachable at the network layer. The measurement system consists of 104 the ingress (configured with IFIT and IFIT parameters) and multiple 105 IFIT-capable devices. 107 IFIT is a solution focusing on network domains. The "network domain" 108 consists of a set of network devices or entities within a single 109 administration. One network domain MAY consists of multiple IFIT 110 domain. The family of emerging on-path flow telemetry techniques MAY 111 be selectively or partially implemented in different vendors' devices 112 as an emerging feature for various use cases of application-aware 113 network operations, in addition, for some usecases, the IFIT Features 114 are deployed on a per-service and on-demand basis. Within the IFIT 115 domain, one or more IFIT-options are added into packet at the IFIT- 116 enabled head node that is referred to as the IFIT encapsulating node. 117 Then IFIT data fields MAY be updated by IFIT transit nodes that the 118 packet traverses. Finally, the data fields are removed at a device 119 that is referred to as the IFIT decapsulating node. Hence, a head 120 node needs to know if the IFIT decapsulating node is able to support 121 the IFIT capabilities. 123 This document defines extensions to BGP to advertise the IFIT 124 capabilities to a head node, then the head node can learn the IFIT 125 capabilities and determine whether a particular IFIT Option type can 126 be supported by the sending side as the decapsulating node. This 127 facilitates the deployment of IFIT measurements on a per-service and 128 on-demand basis. 130 2. Definitions and Acronyms 132 o IFIT: In-situ Flow Information Telemetry 134 o OAM: Operation Administration and Maintenance 136 o NLRI: Network Layer Reachable Information, the NLRI advertised in 137 the BGP UPDATE as defined in [RFC4271] and [RFC4760] . 139 3. IFIT Capabilities 141 This document defines the IFIT Capabilities formed of a 16-bit 142 bitmap. The following format is used: 144 0 1 145 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |p|i|d|e|m| Reserved | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Figure 1. IFIT Capabilities 152 o p-Flag: IOAM Pre-allocated Trace Option Type flag. When set, this 153 indicates that the router is capable of IOAM Pre-allocated Trace 154 [I-D.ietf-ippm-ioam-data]. 156 o i-Flag: IOAM Incremental Trace Option Type flag. When set, this 157 indicates that the router is capable of IOAM Incremental Tracing 158 [I-D.ietf-ippm-ioam-data]. 160 o d-Flag: IOAM DEX Option Type flag. When set, this indicates that 161 the router is capable of IOAM DEX 162 [I-D.ioamteam-ippm-ioam-direct-export]. 164 o e-Flag: IOAM E2E Option Type flag. When set, this indicates that 165 the router is capable of IOAM E2E processing 166 [I-D.ietf-ippm-ioam-data]. 168 o m-Flag: EAM flag. When set, this indicates that the router is 169 capable of processing Enhanced Alternative Marking packets 170 [I-D.zhou-ippm-enhanced-alternate-marking]. 172 o Reserved: Must be set to zero upon transmission and ignored upon 173 receipt. 175 4. Option 1: Extending BGP Extended Community for IFIT Capability 177 4.1. IPv4-Address-Specific IFIT Extended Community 179 For IPv4 networks, this section defines a new type of BGP extended 180 community [RFC4360] called IPv4-Address-Specific IFIT Extended 181 Community. The IPv4-Address-Specific IFIT Extended Community can be 182 used by the IFIT decapsulation node to notify the IFIT Capabilities 183 to its parterner (as the IFIT encapsulation node). It is a 184 transitive extended community with type 0x01 and sub-type TBA. 186 The format of this extended community is shown in Figure 2. 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type (0x01) | Sub-Type (TBA)| IFIT Capabilities | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Originating IPv4 Address | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 2. IPv4-Address-Specific IFIT Extended Community 198 o IFIT Capabilities: as defined in previous setion. 200 o Originating IPv4 Address field: A IPv4 address of the IFIT 201 decapsulation node. 203 4.2. IPv6-Address-Specific IFIT Extended Community 205 For IPv6 networks, this section defines a new type of BGP extended 206 community[RFC4360] called IPv6-Address-Specific IFIT Extended 207 Community. The IPv6-Address-Specific IFIT Extended Community can be 208 used by the IFIT decapsulation node to notify the IFIT Capabilities 209 to its parterner (as the IFIT encapsulation node). It is a 210 transitive IPv6 address specific extended community with type 0x00 211 and sub-type TBA. 213 The format of this extended community is shown in Figure 3. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type (0x00) | Sub-Type (TBA)| IFIT Capabilities | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Originating IPv6 Address | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Originating IPv6 Address (cont.) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Originating IPv6 Address (cont.) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Originating IPv6 Address (cont.) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Figure 3. IPv6-Address-Specific IFIT Extended Community 231 o IFIT Capabilities: as defined in previous setion. 233 o Originating IPv6 Address field: A IPv6 address of the IFIT 234 decapsulation node. 236 In this mode, the Originating IP Address (inclue IPv4 and IPv6) in 237 the extended community attribute is used as the IFIT decapsulation 238 node 240 5. Option 2: Extendng BGP Next-Hop Capability for IFIT Capability 242 The BGP Next-Hop Capability Attribute 243 [I-D.ietf-idr-next-hop-capability] is a non-transitive BGP attribute 244 which is modified or deleted when the next-hop is changed to reflect 245 the capabilities of the new next-hop. The attribute consists of a 246 set of Next-Hop Capabilities. 248 A Next-Hop Capability is a triple (Capability Code, Capability 249 Length, Capability Value) aka a TLV: 251 0 1 252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Capability Code (2 octets) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Capability Length (2 octets) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Capability Value (variable) | 259 ~ ~ 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 4. BGP Next-Hop Capability 264 o Capability Code: a two-octets unsigned binary integer which 265 indicates the type of "Next-Hop Capability" advertised and 266 unambiguously identifies an individual capability. This document 267 defines a new Next-Hop Capability, which is called IFIT Next-Hop 268 Capability. The Capability Code is TBD1. 270 o Capability Length: a two-octets unsigned binary integer which 271 indicates the length, in octets, of the Capability Value field. A 272 length of 0 indicates that no Capability Value field is present. 274 o Capability Value: a variable-length field. It is interpreted 275 according to the value of the Capability Code. For the IFIT Next- 276 Hop Capability, Capability Value contains IFIT Capabilities and 277 Originate IP Address, as shown in the following figure. 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | IFIT Capabilities (2 octets) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Originating IP Address | 283 | (4 or 16 octets) | 284 ~ ~ 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 5. BGP Capability Value for IFIT 289 o IFIT Capabilities: as defined in previous setion. 291 o Originating IP Address: An IPv4 or IPv6 Address of the IFIT 292 decapsulation node. 294 A BGP speaker S that sends an UPDATE with the BGP Next-Hop Capability 295 Attribute MAY include the IFIT Next-Hop Capability. The inclusion of 296 the iFIT Next-Hop Capability with the NLRI advertised in the BGP 297 UPDATE indicates that the BGP Next-Hop can act as the IFIT 298 decapsulating node and it can process the specific iFIT encapsulation 299 format indicated per the capability value. This is applied for all 300 routes indicated in the same NRLI. 302 A BGP speaker receiving an IFIT Next-Hop Capability containing the 303 IFIT options that it can supports behaves as defined in the document 304 defining these iFIT options. 306 6. IANA Considerations 308 TBD 310 7. Security Considerations 312 TBD 314 8. Contributors 316 The following people made significant contributions to this document: 318 Weidong Li 319 Huawei 320 Email: poly.li@huawei.com 322 Haibo Wang 323 Huawei 324 Email: rainsword.wang@huawei.com 326 Tianran Zhou 327 Huawei 328 Email: zhoutianran@huawei.com 330 9. Acknowledgements 332 TBD 334 10. References 336 10.1. Normative References 338 [I-D.ietf-bess-srv6-services] 339 Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, 340 S., and J. Rabadan, "SRv6 BGP based Overlay services", 341 draft-ietf-bess-srv6-services-03 (work in progress), July 342 2020. 344 [I-D.ietf-idr-next-hop-capability] 345 Decraene, B., Kompella, K., and W. Henderickx, "BGP Next- 346 Hop dependent capabilities", draft-ietf-idr-next-hop- 347 capability-05 (work in progress), June 2019. 349 [I-D.ietf-ippm-ioam-data] 350 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 351 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 352 progress), July 2020. 354 [I-D.ioamteam-ippm-ioam-direct-export] 355 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 356 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 357 OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct- 358 export-00 (work in progress), October 2019. 360 [I-D.song-ippm-postcard-based-telemetry] 361 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 362 "Postcard-based On-Path Flow Data Telemetry", draft-song- 363 ippm-postcard-based-telemetry-07 (work in progress), April 364 2020. 366 [I-D.wang-idr-bgp-ls-ifit-node-capability] 367 Wang, Y., Zhou, T., and R. Pang, "Extensions to BGP-LS for 368 Advertising In-situ Flow Information Telemetry (IFIT) Node 369 Capability", draft-wang-idr-bgp-ls-ifit-node-capability-03 370 (work in progress), March 2020. 372 [I-D.zhou-ippm-enhanced-alternate-marking] 373 Zhou, T., Fioccola, G., Lee, S., Cociglio, M., and W. Li, 374 "Enhanced Alternate Marking Method", draft-zhou-ippm- 375 enhanced-alternate-marking-05 (work in progress), July 376 2020. 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, 380 DOI 10.17487/RFC2119, March 1997, 381 . 383 10.2. Informative References 385 [I-D.song-opsawg-ifit-framework] 386 Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "In- 387 situ Flow Information Telemetry", draft-song-opsawg-ifit- 388 framework-12 (work in progress), April 2020. 390 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 391 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 392 DOI 10.17487/RFC4271, January 2006, 393 . 395 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 396 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 397 February 2006, . 399 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 400 "Multiprotocol Extensions for BGP-4", RFC 4760, 401 DOI 10.17487/RFC4760, January 2007, 402 . 404 Authors' Addresses 406 Yali Wang 407 Huawei 408 Beijing 409 China 411 Email: wangyali11@huawei.com 412 Shunwan Zhuang 413 Huawei 414 Beijing 415 China 417 Email: zhuangshunwan@huawei.com 419 Yunan Gu 420 Huawei 421 Beijing 422 China 424 Email: guyunan@huawei.com