idnits 2.17.1 draft-wang-idr-bgp-ifit-capabilities-05.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 9, 2022) is 719 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 (-17) exists of draft-ietf-6man-ipv6-alt-mark-14 == Outdated reference: A later version (-08) exists of draft-ietf-idr-next-hop-capability-07 == Outdated reference: A later version (-08) exists of draft-ietf-idr-sr-policy-ifit-03 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Fioccola 3 Internet-Draft Huawei 4 Intended status: Standards Track R. Pang 5 Expires: November 10, 2022 China Unicom 6 S. Zhuang 7 H. Wang 8 Huawei 9 May 9, 2022 11 BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) 12 Capabilities 13 draft-wang-idr-bgp-ifit-capabilities-05 15 Abstract 17 This document defines extensions to BGP [RFC4271] to advertise the 18 In-situ Flow Information Telemetry (IFIT) capabilities. Within an 19 IFIT domain, IFIT-capability advertisement from the tail node to the 20 head node assists the head node to determine whether a particular 21 IFIT Option type can be encapsulated in data packets. Such 22 advertisement would be useful for mitigating the leakage threat and 23 facilitating the deployment of IFIT measurements on a per-service and 24 on-demand basis. 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 November 10, 2022. 49 Copyright Notice 51 Copyright (c) 2022 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 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 68 2. IFIT Domain . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. IFIT Capabilities . . . . . . . . . . . . . . . . . . . . . . 4 70 4. BGP Next-Hop IFIT Capability Advertisement . . . . . . . . . 5 71 5. Hop-by-Hop and Head-to-Tail Mechanisms . . . . . . . . . . . 6 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 10.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 In-situ Flow Information Telemetry (IFIT) denotes a family of flow- 84 oriented on-path telemetry techniques, including In-situ OAM (IOAM) 85 [I-D.ietf-ippm-ioam-data] and Alternate Marking [RFC8321]. It can 86 provide flow information on the entire forwarding path on a per- 87 packet basis in real time. 89 IFIT is a solution focusing on network domains according to [RFC8799] 90 that introduces the concept of specific domain solutions. A network 91 domain consists of a set of network devices or entities within a 92 single administration. As mentioned in [RFC8799], for a number of 93 reasons, such as policies, options supported, style of network 94 management and security requirements, it is suggested to limit 95 applications including the emerging IFIT techniques to a controlled 96 domain. 98 Hence, the family of emerging on-path flow telemetry techniques MUST 99 be typically deployed in such controlled domains. The IFIT solution 100 MAY be selectively or partially implemented in different vendors' 101 devices as an emerging feature for various use cases of application- 102 aware network operations. In addition, for some use cases, the IFIT 103 are deployed on a per-service and on-demand basis. 105 This document introduces extensions to Border Gateway Protocol (BGP) 106 to advertise the supported IFIT capabilities of the egress node to 107 the ingress node in an IFIT domain when the egress node distributes a 108 route, such as EVPNv4, EVPNv6, L2EVPN(EVPN VPWS and EVPN VPLS) 109 routes, etc. Then the ingress node can learn the IFIT node 110 capabilities associated to the routing information distributed 111 between BGP peers and determine whether a particular IFIT Option type 112 can be encapsulated in traffic packets which are forwarded along the 113 path. Such advertisement would be useful for avoiding IFIT data 114 leaking from the IFIT domain and measuring performance metrics on a 115 per-service basis through steering packets of flow into a path where 116 IFIT application are supported. 118 This document defines an IFIT Next-Hop Capability Attribute according 119 to [I-D.ietf-idr-next-hop-capability]. It allows a distributed 120 solution that does not require the participation of centralized 121 control element, while [I-D.ietf-idr-sr-policy-ifit] allows to 122 centrally distribute SR policies and can be considered as a 123 centralized control solution. Therefore, this document enables the 124 IFIT application in networks where no controller is introduced and it 125 helps network operators to deploy IFIT in their networks. 127 1.1. Definitions and Acronyms 129 o IFIT: In-situ Flow Information Telemetry 131 o OAM: Operation Administration and Maintenance 133 o NLRI: Network Layer Reachable Information, the NLRI advertised in 134 the BGP UPDATE as defined in [RFC4271] and [RFC4760]. 136 2. IFIT Domain 138 IFIT deployment modes can include monitoring at node-level, tunnel- 139 level, and service-level. The requirement of this document is to 140 provide IFIT deployment at service-level, since different services 141 may have different IFIT requirements. With the service-level 142 solution, different IFIT methods can be deployed for different VPN 143 services. 145 The figure shows an implementation example of IFIT application in a 146 VPN scenario. 148 +----+ +----+ 149 +----+ | | +----+ | | +----+ 150 |CE1 |------|PE1 |==========|RR/P|==========|PE2 |------|CE2 | 151 +----+ | | +----+ | | +----+ 152 +----+ +----+ 153 |<------------IFIT Domain--------->| 154 |<---------------BGP-------------->| 155 |<----------------------------VPN--------------------------->| 157 Figure 1. Example of IFIT application in a VPN scenario 159 As the figure shows, a traffic flow is sent out from the customer 160 edge node CE1 to another customer edge node CE2. In order to enable 161 IFIT application for this flow, the IFIT header must be encapsulated 162 in the packet at the ingress provider edge node PE1, referred to as 163 the IFIT encapsulating node. Then, transit nodes in the IFIT domain 164 may be able to support the IFIT capabilities in order to inspect IFIT 165 extensions and, if needed, to update the IFIT data fields in the 166 packet. Finally, the IFIT data fields must be exported and removed 167 at egress provider edge node PE2 that is referred to as the IFIT 168 decapsulating node. This is essential to avoid IFIT data leakage 169 outside the controlled domain. 171 Since the IFIT decapsulating node MUST be able to handle and remove 172 the IFIT header, the IFIT encapsulating node MUST know if the IFIT 173 decapsulating node supports the IFIT application and, more 174 specifically, which capabilities can be enabled. 176 3. IFIT Capabilities 178 This document defines the IFIT Capabilities formed of a 16-bit 179 bitmap. The following format is used: 181 0 1 182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |P|I|D|E|M| Reserved | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 2. IFIT Capabilities 189 o P-Flag: IOAM Pre-allocated Trace Option Type flag. When set, this 190 indicates that the router is capable of IOAM Pre-allocated Trace 191 [I-D.ietf-ippm-ioam-data]. 193 o I-Flag: IOAM Incremental Trace Option Type flag. When set, this 194 indicates that the router is capable of IOAM Incremental Tracing 195 [I-D.ietf-ippm-ioam-data]. 197 o D-Flag: IOAM DEX Option Type flag. When set, this indicates that 198 the router is capable of IOAM DEX 199 [I-D.ioamteam-ippm-ioam-direct-export]. 201 o E-Flag: IOAM E2E Option Type flag. When set, this indicates that 202 the router is capable of IOAM E2E processing 203 [I-D.ietf-ippm-ioam-data]. 205 o M-Flag: Alternate Marking flag. When set, this indicates that the 206 router is capable of processing Alternative Marking packets 207 [RFC8321]. 209 o Reserved: Reserved for future use. They MUST be set to zero upon 210 transmission and ignored upon receipt. 212 4. BGP Next-Hop IFIT Capability Advertisement 214 The BGP Next-Hop Capability Attribute 215 [I-D.ietf-idr-next-hop-capability] is a non-transitive BGP attribute 216 and consists of a set of Next-Hop Capabilities. It is modified or 217 deleted when the next-hop is changed, to reflect the capabilities of 218 the new next-hop. 220 The IFIT Capabilities described above can be encoded as a BGP Next- 221 Hop IFIT Capability Attribute. It can be included in a BGP UPDATE 222 message and indicates that the BGP Next-Hop supports the IFIT 223 capability for the NLRI advertised in this BGP UPDATE. 225 The IFIT Next-Hop Capability is defined below and is a triple 226 (Capability Code, Capability Length, Capability Value) aka a TLV: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Capability Code (TBA1) | Capability Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | IFIT Capabilities | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | ORIG. IP Address(4/16 octets) | 236 | ... | 237 | | 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 3. BGP Next-Hop Capability 243 o Capability Code: a two-octets unsigned binary integer which 244 indicates the type of "Next-Hop Capability" advertised and 245 unambiguously identifies an individual capability. This document 246 defines a new Next-Hop Capability, which is called IFIT Next-Hop 247 Capability. The Capability Code is TBA1. 249 o Capability Length: a two-octets unsigned binary integer which 250 indicates the length, in octets, of the Capability Value field. A 251 length of 0 indicates that no Capability Value field is present. 253 o IFIT Capabilities: as defined in previous section. 255 o ORIG. IP Address: An IPv4 or IPv6 Address of the IFIT 256 decapsulation node. It is an IPv4 or IPv6 unicast address 257 assigned by one of the Internet registries. 259 A BGP speaker S that sends an UPDATE with the BGP Next-Hop Capability 260 Attribute MAY include the IFIT Next-Hop Capability. The inclusion of 261 the IFIT Next-Hop Capability with the NLRI advertised in the BGP 262 UPDATE indicates that the BGP Next-Hop can act as the IFIT 263 decapsulating node and it can process the specific IFIT encapsulation 264 format indicated per the capability value. This is applied for all 265 routes indicated in the same NRLI. 267 5. Hop-by-Hop and Head-to-Tail Mechanisms 269 When all devices are upgraded to support IFIT, the hop-by-hop 270 mechanism can be suitable. In the current stage, where new and old 271 devices are deployed together, we must first ensure that the tail 272 node can properly decapsulate the IFIT header, so we need an 273 advertisement mechanism from the head node to the tail node. 275 Further, different services on the egress node may have different 276 IFIT requirements, so the capability advertisement from the head node 277 to the tail node is always required. 279 However, hop-by-hop and head-to-tail mechanisms can eventually be 280 used together without conflict. 282 6. IANA Considerations 284 The IANA is requested to make the assignments for IFIT Next-Hop 285 Capability: 287 +-------+-------------------+---------------+ 288 | Value | Description | Reference | 289 +-------+-------------------+---------------+ 290 | TBA1 | IFIT Capabilities | This document | 291 +-------+-------------------+---------------+ 293 7. Security Considerations 295 This document defines extensions to BGP Next-Hop Capability to 296 advertise the IFIT capabilities. It does not introduce any new 297 security risks to BGP, as also mentioned in 298 [I-D.ietf-idr-next-hop-capability]. 300 IFIT methods are applied within a controlled domain and solutions 301 MUST be taken to ensure that the IFIT data are properly propagated to 302 avoid malicious attacks. Both IOAM method [I-D.ietf-ippm-ioam-data] 303 and Alternate Marking method [I-D.ietf-6man-ipv6-alt-mark] 304 respectively discussed that the implementation of both methods MUST 305 be within a controlled domain. 307 8. Contributors 309 The following people made significant contributions to this document: 311 Yali Wang 312 Huawei 313 Email: wangyali11@huawei.com 315 Yunan Gu 316 Huawei 317 Email: guyunan@huawei.com 319 Tianran Zhou 320 Huawei 321 Email: zhoutianran@huawei.com 323 Weidong Li 324 Huawei 325 Email: poly.li@huawei.com 327 9. Acknowledgements 329 The authors would like to thank Ketan Talaulikar, Haoyu Song, Jie 330 Dong, Robin Li, Jeffrey Haas, Robert Raszuk, Zongpeng Du, Yisong Liu, 331 Yongqing Zhu, Aijun Wang, Fan Yang for their reviews and suggestions 333 10. References 335 10.1. Normative References 337 [I-D.ietf-6man-ipv6-alt-mark] 338 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 339 Pang, "IPv6 Application of the Alternate Marking Method", 340 draft-ietf-6man-ipv6-alt-mark-14 (work in progress), April 341 2022. 343 [I-D.ietf-idr-next-hop-capability] 344 Decraene, B., Kompella, K., and W. Henderickx, "BGP Next- 345 Hop dependent capabilities", draft-ietf-idr-next-hop- 346 capability-07 (work in progress), December 2021. 348 [I-D.ietf-idr-sr-policy-ifit] 349 Qin, F., Yuan, H., Zhou, T., Fioccola, G., and Y. Wang, 350 "BGP SR Policy Extensions to Enable IFIT", draft-ietf-idr- 351 sr-policy-ifit-03 (work in progress), January 2022. 353 [I-D.ietf-ippm-ioam-data] 354 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 355 for In-situ OAM", draft-ietf-ippm-ioam-data-17 (work in 356 progress), December 2021. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, 360 DOI 10.17487/RFC2119, March 1997, 361 . 363 10.2. Informative References 365 [I-D.ioamteam-ippm-ioam-direct-export] 366 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 367 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 368 OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct- 369 export-00 (work in progress), October 2019. 371 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 372 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 373 DOI 10.17487/RFC4271, January 2006, 374 . 376 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 377 "Multiprotocol Extensions for BGP-4", RFC 4760, 378 DOI 10.17487/RFC4760, January 2007, 379 . 381 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 382 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 383 "Alternate-Marking Method for Passive and Hybrid 384 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 385 January 2018, . 387 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 388 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 389 . 391 Authors' Addresses 393 Giuseppe Fioccola 394 Huawei 395 Munich 396 Germany 398 Email: giuseppe.fioccola@huawei.com 399 Ran Pang 400 China Unicom 401 Beijing 402 China 404 Email: pangran@chinaunicom.cn 406 Shunwan Zhuang 407 Huawei 408 Beijing 409 China 411 Email: zhuangshunwan@huawei.com 413 Hiabo Wang 414 Huawei 415 Beijing 416 China 418 Email: rainsword.wang@huawei.com