idnits 2.17.1 draft-wang-idr-bgp-ifit-capabilities-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 (October 28, 2020) is 1275 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) == Outdated reference: A later version (-08) exists of draft-ietf-idr-next-hop-capability-06 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 3 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: May 1, 2021 Huawei 6 October 28, 2020 8 BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) 9 Capabilities 10 draft-wang-idr-bgp-ifit-capabilities-01 12 Abstract 14 This document defines extensions to BGP to advertise the In-situ Flow 15 Information Telemetry (IFIT) capabilities. Within an IFIT domain, 16 IFIT-capability advertisement from the tail node to the head node 17 assists the head node to determine whether a particular IFIT Option 18 type can be encapsulated in data packets. Such advertisement would 19 be useful for mitigating the leakage threat and facilitating the 20 deployment of IFIT measurements on a per-service and 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 May 1, 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 . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Option 1: Extension to BGP Extended Community for IFIT- 66 Capability Advertisement . . . . . . . . . . . . . . . . . . 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: Extension to BGP Next-Hop Capability for IFIT- 70 Capability Advertisement . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 In-situ Flow Information Telemetry (IFIT) denotes a family of flow- 83 oriented on-path telemetry techniques, including In-situ OAM (IOAM) 84 [I-D.ietf-ippm-ioam-data] and Alternate Marking [RFC8321], which can 85 provide flow information on the entire forwarding path on a per- 86 packet basis in real time (e.g., jitter, latency, packet loss). 88 The IFIT model describes how service flows are measured to obtain 89 packet loss and latency. Specifically, IFIT measures the packet loss 90 and latency of service flows on the ingress and egress of the transit 91 network, and summarizes desired performance indicators. The IFIT 92 model is composed of three objects: target flow, transit network, and 93 measurement system. The transit network only bears target flows. 94 The target flows are not generated or terminated on the transit 95 network. The transit network can be a Layer 2 (L2), Layer 3 (L3), or 96 L2+L3 hybrid network. Each node on the transit network must be 97 reachable at the network layer. The measurement system consists of 98 the ingress (configured with IFIT and IFIT parameters) and multiple 99 IFIT-capable devices. 101 IFIT is a solution focusing on network domains. The "network domain" 102 consists of a set of network devices or entities within a single 103 administration. One network domain MAY consists of multiple IFIT 104 domain. The family of emerging on-path flow telemetry techniques MAY 105 be selectively or partially implemented in different vendors' devices 106 as an emerging feature for various use cases of application-aware 107 network operations, in addition, for some usecases, the IFIT Features 108 are deployed on a per-service and on-demand basis. Within the IFIT 109 domain, one or more IFIT-options are added into packet at the IFIT- 110 enabled head node that is referred to as the IFIT encapsulating node. 111 Then IFIT data fields MAY be updated by IFIT transit nodes that the 112 packet traverses. Finally, the data fields are removed at a device 113 that is referred to as the IFIT decapsulating node. Hence, a head 114 node needs to know if the IFIT decapsulating node is able to support 115 the IFIT capabilities. 117 This document defines extensions to BGP to advertise the IFIT 118 capabilities of a tail node to a head node in an IFIT domain. Then 119 the head node can learn the IFIT capabilities and determine whether a 120 particular IFIT Option type can be encapsulated in traffic packets. 121 Such advertisement would be useful for avoiding IFIT data leaking 122 from the IFIT domain and facilitating the deployment of IFIT 123 measurements on a per-service and on-demand basis. 125 2. Definitions and Acronyms 127 o IFIT: In-situ Flow Information Telemetry 129 o OAM: Operation Administration and Maintenance 131 o NLRI: Network Layer Reachable Information, the NLRI advertised in 132 the BGP UPDATE as defined in [RFC4271] and [RFC4760] . 134 3. IFIT Capabilities 136 This document defines the IFIT Capabilities formed of a 16-bit 137 bitmap. The following format is used: 139 0 1 140 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |P|I|D|E|M| Reserved | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 1. IFIT Capabilities 147 o P-Flag: IOAM Pre-allocated Trace Option Type flag. When set, this 148 indicates that the router is capable of IOAM Pre-allocated Trace 149 [I-D.ietf-ippm-ioam-data]. 151 o I-Flag: IOAM Incremental Trace Option Type flag. When set, this 152 indicates that the router is capable of IOAM Incremental Tracing 153 [I-D.ietf-ippm-ioam-data]. 155 o D-Flag: IOAM DEX Option Type flag. When set, this indicates that 156 the router is capable of IOAM DEX 157 [I-D.ioamteam-ippm-ioam-direct-export]. 159 o E-Flag: IOAM E2E Option Type flag. When set, this indicates that 160 the router is capable of IOAM E2E processing 161 [I-D.ietf-ippm-ioam-data]. 163 o M-Flag: Alternate Marking flag. When set, this indicates that the 164 router is capable of processing Alternative Marking packets 165 [RFC8321]. 167 o Reserved: Reserved for future use. They MUST be set to zero upon 168 transmission and ignored upon receipt. 170 4. Option 1: Extension to BGP Extended Community for IFIT-Capability 171 Advertisement 173 4.1. IPv4-Address-Specific IFIT Extended Community 175 For IPv4 networks, this section defines a new type of BGP extended 176 community [RFC4360] called IPv4-Address-Specific IFIT Extended 177 Community. The IPv4-Address-Specific IFIT Extended Community can be 178 used by the IFIT decapsulation node to notify the IFIT Capabilities 179 to its parterner (as the IFIT encapsulation node). It is a 180 transitive extended community with type 0x01 and sub-type TBA. 182 The format of this extended community is shown in Figure 2. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type (0x01) | Sub-Type (TBA)| IFIT Capabilities | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Originating IPv4 Address | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 2. IPv4-Address-Specific IFIT Extended Community 194 o IFIT Capabilities: as defined in previous setion. 196 o Originating IPv4 Address field: A IPv4 address of the IFIT 197 decapsulation node. 199 4.2. IPv6-Address-Specific IFIT Extended Community 201 For IPv6 networks, this section defines a new type of BGP extended 202 community[RFC4360] called IPv6-Address-Specific IFIT Extended 203 Community. The IPv6-Address-Specific IFIT Extended Community can be 204 used by the IFIT decapsulation node to notify the IFIT Capabilities 205 to its parterner (as the IFIT encapsulation node). It is a 206 transitive IPv6 address specific extended community with type 0x00 207 and sub-type TBA. 209 The format of this extended community is shown in Figure 3. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type (0x00) | Sub-Type (TBA)| IFIT Capabilities | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Originating IPv6 Address | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Originating IPv6 Address (cont.) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Originating IPv6 Address (cont.) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Originating IPv6 Address (cont.) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 3. IPv6-Address-Specific IFIT Extended Community 227 o IFIT Capabilities: as defined in previous setion. 229 o Originating IPv6 Address field: A IPv6 address of the IFIT 230 decapsulation node. 232 In this option, the Originating IP Address (inclue IPv4 and IPv6) in 233 the extended community attribute is used as the IFIT decapsulation 234 node. 236 5. Option 2: Extension to BGP Next-Hop Capability for IFIT-Capability 237 Advertisement 239 The BGP Next-Hop Capability Attribute 240 [I-D.ietf-idr-next-hop-capability] is a non-transitive BGP attribute, 241 which is modified or deleted when the next-hop is changed, to reflect 242 the capabilities of the new next-hop. The attribute consists of a 243 set of Next-Hop Capabilities. 245 A Next-Hop Capability is a triple (Capability Code, Capability 246 Length, Capability Value) aka a TLV: 248 0 1 249 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Capability Code (2 octets) | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Capability Length (2 octets) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Capability Value (variable) | 256 ~ ~ 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 4. BGP Next-Hop Capability 261 o Capability Code: a two-octets unsigned binary integer which 262 indicates the type of "Next-Hop Capability" advertised and 263 unambiguously identifies an individual capability. This document 264 defines a new Next-Hop Capability, which is called IFIT Next-Hop 265 Capability. The Capability Code is TBD1. 267 o Capability Length: a two-octets unsigned binary integer which 268 indicates the length, in octets, of the Capability Value field. A 269 length of 0 indicates that no Capability Value field is present. 271 o Capability Value: a variable-length field. It is interpreted 272 according to the value of the Capability Code. For the IFIT Next- 273 Hop Capability, Capability Value contains IFIT Capabilities and 274 Originate IP Address, as shown in the following figure. 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | IFIT Capabilities (2 octets) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Originate IP Address | 280 | (4 or 16 octets) | 281 ~ ~ 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 5. BGP Capability Value for IFIT 286 o IFIT Capabilities: as defined in previous setion. 288 o Originate IP Address: An IPv4 or IPv6 Address of the IFIT 289 decapsulation node. 291 A BGP speaker S that sends an UPDATE with the BGP Next-Hop Capability 292 Attribute MAY include the IFIT Next-Hop Capability. The inclusion of 293 the IFIT Next-Hop Capability with the NLRI advertised in the BGP 294 UPDATE indicates that the BGP Next-Hop can act as the IFIT 295 decapsulating node and it can process the specific IFIT encapsulation 296 format indicated per the capability value. This is applied for all 297 routes indicated in the same NRLI. 299 6. IANA Considerations 301 TBD 303 7. Security Considerations 305 This document defines extensions to BGP Extended Community and BGP 306 Next-Hop Capability to advertise the IFIT capabilities. It does not 307 introduce any new security risks to BGP. 309 8. Contributors 311 The following people made significant contributions to this document: 313 Weidong Li 314 Huawei 315 Email: poly.li@huawei.com 317 Haibo Wang 318 Huawei 319 Email: rainsword.wang@huawei.com 321 Tianran Zhou 322 Huawei 323 Email: zhoutianran@huawei.com 325 9. Acknowledgements 327 TBD 329 10. References 331 10.1. Normative References 333 [I-D.ietf-idr-next-hop-capability] 334 Decraene, B., Kompella, K., and W. Henderickx, "BGP Next- 335 Hop dependent capabilities", draft-ietf-idr-next-hop- 336 capability-06 (work in progress), October 2020. 338 [I-D.ietf-ippm-ioam-data] 339 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 340 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 341 progress), July 2020. 343 [I-D.ioamteam-ippm-ioam-direct-export] 344 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 345 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 346 OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct- 347 export-00 (work in progress), October 2019. 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, 351 DOI 10.17487/RFC2119, March 1997, 352 . 354 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 355 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 356 "Alternate-Marking Method for Passive and Hybrid 357 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 358 January 2018, . 360 10.2. Informative References 362 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 363 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 364 DOI 10.17487/RFC4271, January 2006, 365 . 367 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 368 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 369 February 2006, . 371 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 372 "Multiprotocol Extensions for BGP-4", RFC 4760, 373 DOI 10.17487/RFC4760, January 2007, 374 . 376 Authors' Addresses 378 Yali Wang 379 Huawei 380 Beijing 381 China 383 Email: wangyali11@huawei.com 385 Shunwan Zhuang 386 Huawei 387 Beijing 388 China 390 Email: zhuangshunwan@huawei.com 392 Yunan Gu 393 Huawei 394 Beijing 395 China 397 Email: guyunan@huawei.com