idnits 2.17.1 draft-ietf-bess-evpn-geneve-03.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 (18 September 2021) is 944 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: 'RFC7365' is defined on line 430, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-nvo3-encap-07 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-encap (ref. 'I-D.ietf-nvo3-encap') ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup S. Boutros, Ed. 3 Internet-Draft Ciena 4 Intended status: Standards Track A. Sajassi 5 Expires: 22 March 2022 Cisco Systems 6 J. Drake 7 Juniper Networks 8 J. Rabadan 9 Nokia 10 S. Aldrin 11 Google 12 18 September 2021 14 EVPN control plane for Geneve 15 draft-ietf-bess-evpn-geneve-03 17 Abstract 19 This document describes how Ethernet VPN (EVPN) control plane can be 20 used with Network Virtualization Overlay over Layer 3 (NVO3) Generic 21 Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 22 solutions. 24 EVPN control plane can also be used by Network Virtualization Edges 25 (NVEs) to express Geneve tunnel option TLV(s) supported in the 26 transmission and/or reception of Geneve encapsulated data packets. 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 22 March 2022. 45 Copyright Notice 47 Copyright (c) 2021 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 (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3 64 4. GENEVE extension . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. Ethernet option TLV . . . . . . . . . . . . . . . . . . . 4 66 5. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Geneve Tunnel Option Types sub-TLV . . . . . . . . . . . 6 68 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 10.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The Network Virtualization over Layer 3 (NVO3) solutions for network 80 virtualization in data center (DC) environment are based on an IP- 81 based underlay. An NVO3 solution provides layer 2 and/or layer 3 82 overlay services for virtual networks enabling multi-tenancy and 83 workload mobility. The NVO3 working group has evaluated different 84 dataplane encapsulations. The Generic Network Virtualization 85 Encapsulation [I-D.ietf-nvo3-geneve] has been recently recommended to 86 be the proposed standard for NVO3 encapsulation. 88 This document describes how the EVPN control plane can signal Geneve 89 encapsulation type in the BGP Tunnel Encapsulation Extended Community 90 defined in [I-D.ietf-idr-tunnel-encaps]. In addition, this document 91 defines how to communicate the Geneve tunnel option types in a new 92 BGP Tunnel Encapsulation Attribute sub-TLV. The Geneve tunnel 93 options are encapsulated as TLVs after the Geneve base header in the 94 Geneve packet as described in [I-D.ietf-nvo3-geneve]. 96 [I-D.ietf-nvo3-encap] recommends that a control plane determine how 97 Network Virtualization Edges (NVEs) use the GENEVE option TLVs when 98 sending/receiving packets. In particular, the control plane 99 negotiates the subset of option TLVs supported, their order and the 100 total number of option TLVs allowed in the packets. This negotiation 101 capability allows, for example, interoperability with hardware-based 102 NVEs that can process fewer options than software-based NVEs. 104 This EVPN control plane extension will allow an NVE to express what 105 Geneve option TLV types it is capable of receiving from, or sending 106 to, over the Geneve tunnel with its peers. 108 In the datapath, a transmitting NVE MUST NOT encapsulate a packet 109 destined to another NVE with any option TLV(s) the receiving NVE is 110 not capable of processing. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Abbreviations and Terminology 120 NVO3: Network Virtualization Overlays over Layer 3 122 GENEVE: Generic Network Virtualization Encapsulation. 124 NVE: Network Virtualization Edge. 126 VNI: Virtual Network Identifier. 128 MAC: Media Access Control. 130 OAM: Operations, Administration and Maintenance. 132 PE: Provide Edge Node. 134 CE: Customer Edge device e.g., host or router or switch. 136 EVPN: Ethernet VPN. 138 EVI: An EVPN instance spanning the Provider Edge (PE) devices 139 participating in that EVPN. 141 MAC-VRF: A Virtual Routing and Forwarding table for Media Access 142 Control (MAC) addresses on a PE. 144 4. GENEVE extension 146 This document adds an extension to the [I-D.ietf-nvo3-geneve] 147 encapsulation that are relevant to the operation of EVPN. 149 4.1. Ethernet option TLV 151 [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses 152 ingress replication to flood unknown unicast traffic to the egress 153 NVEs, the ingress NVE needs to indicate to the egress NVE that the 154 Encapsulated packet is a BUM traffic type. This is required to avoid 155 transient packet duplication in all-active multi-homing scenarios. 156 For GENEVE, we need a bit to for this purpose. 158 [RFC8317] uses MPLS label for leaf indication of BUM traffic 159 originated from a leaf AC in an ingress NVE so that the egress NVEs 160 can filter BUM traffic toward their leaf ACs. For GENEVE, we need a 161 bit for this purpose. 163 Although the default mechanism for split-horizon filtering of BUM 164 traffic on an Ethernet segment for IP-based ecnapsulations such as 165 VxLAN, GPE, NVGRE, and GENVE, is local-bias as defined in section 166 8.3.1 of [I-D.ietf-bess-evpn-overlay], there can be an incentive to 167 leverage the same split-horizon filtering mechanism of [RFC7432] that 168 uses a 20- bit MPLS label so that a) the a single filtering mechanism 169 is used for all encapsulation types and b) the same PE can 170 participate in a mix of MPLS and IP encapsulations. For this purpose 171 a 20-bit label field MAY be defined for GENVE encapsulation. The 172 support for this label is optional. 174 If an NVE wants to use local-bias procedure, then it sends the new 175 option TLV without ESI-label (e.g., length=4): 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Option Class=Ethernet |Type=0 |B|L|R| Len=0x1 | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 If an NVE wants to use ESI-label, then it sends the new option TLV 184 with ESI-label (e.g., length=8) 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Option Class=Ethernet |Typ=EVPN-OPTION|B|L|R| Len=0x2 | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Rsvd | Source-ID | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Where: 195 - Option Class is set to Ethernet (new Option Class requested to 196 IANA) 198 - Type is set to EVPN-OPTION (new type requested to IANA) and C bit 199 must be set. 201 - B bit is set to 1 for BUM traffic. 203 - L bit is set to 1 for Leaf-Indication. 205 - R bit is set to 1 for Root-Indication. 207 - Source-ID is a 24-bit value that encodes the ESI-label value 208 signaled on the EVPN Autodiscovery per-ES routes, as described in 209 [RFC7432] for multi-homing and [RFC8317] for leaf-to-leaf BUM 210 filtering. The ESI-label value is encoded in the high-order 20 bits 211 of the Source-ESI field. 213 The egress NVEs that make use of ESIs in the data path because they 214 have a local multi-homed ES or support [RFC8317] SHOULD advertise 215 their Ethernet A-D per-ES routes along with the Geneve tunnel sub-TLV 216 and in addition to the ESI-label Extended Community. The ingress NVE 217 can then use the Ethernet option-TLV when sending GENEVE packets 218 based on the [RFC7432] and [RFC8317] procedures. The egress NVE will 219 use the Source-ID field in the received packets to make filtering 220 decisions. 222 Note that [I-D.ietf-bess-evpn-overlay] modifies the [RFC7432] split- 223 horizon procedures for NVO3 tunnels using the "local-bias" procedure. 224 "Local-bias" relies on tunnel IP source address checks (instead of 225 ESI-labels) to determine whether a packet can be forwarded to a local 226 ES. 228 While "local-bias" MUST be supported along with GENEVE encapsulation, 229 the use of the Ethernet option-TLV is RECOMMENDED to follow the same 230 procedures used by EVPN MPLS. 232 An ingress NVE using ingress replication to flood BUM traffic MUST 233 send B=1 in all the GENEVE packets that encapsulate BUM frames. An 234 egress NVE SHOULD determine whether a received packet encapsulates a 235 BUM frame based on the B bit. The use of the B bit is only relevant 236 to GENEVE packets with Protocol Type 0x6558 (Bridged Ethernet). 238 5. BGP Extensions 240 As per [I-D.ietf-bess-evpn-overlay] the BGP Encapsulation extended 241 community defined in [I-D.ietf-idr-tunnel-encaps] is included with 242 all EVPN routes advertised by an egress NVE. 244 This document specifies a new BGP Tunnel Encapsulation Type for 245 Geneve and a new Geneve tunnel option types sub-TLV as described 246 below. 248 5.1. Geneve Tunnel Option Types sub-TLV 250 The Geneve tunnel option types is a new BGP Tunnel Encapsulation 251 Attribute Sub-TLV. 253 +-----------------------------------+ 254 | Sub-TLV Type (1 Octet) | 255 +-----------------------------------+ 256 | Sub-TLV Length (1 or 2 Octets)| 257 +-----------------------------------+ 258 | Sub-TLV Value (Variable) | 259 | | 260 +-----------------------------------+ 262 Figure 1: Geneve tunnel option types sub-TLV 264 The Sub-TLV Type field contains a value in the range from 192-252. 265 To be allocated by IANA. 267 Sub-TLV value MUST match exactly the first 4-octets of the option TLV 268 format. For instance, if we need to signal support for two option 269 TLVs: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Option Class | Type |R|R|R| Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Option Class | Type |R|R|R| Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 An NVE receiving the above sub-TLV, MUST send GENEVE packets to the 280 originator NVE with only the option TLVs the receiver NVE is capable 281 of receiving, and following the same order. 283 The above sub-TLV(s) MAY be included with only Ethernet A-D per-ES 284 routes. 286 6. Operation 288 The following figure shows an example of an NVO3 deployment with 289 EVPN. 291 +--------------+ 292 | | 293 +---------+ | WAN | +---------+ 294 +----+ | | +----+ +----+ | | +----+ 295 |NVE1|--| | |ASBR| |ASBR| | |--|NVE3| 296 +----+ |IP Fabric|---| 1 | | 2 |--|IP Fabric| +----+ 297 +----+ | | +----+ +----+ | | +----+ 298 |NVE2|--| | | | | |--|NVE4| 299 +----+ +---------+ +--------------+ +---------+ +----+ 301 |<------ DC 1 -----> <---- DC2 ------>| 303 Figure 2: Data Center Interconnect with ASBR 305 iBGP sessions are established between NVE1, NVE2, ASBR1, possibly via 306 a BGP route-reflector. Similarly, iBGP sessions are established 307 between NVE3, NVE4, ASBR2. 309 eBGP sessions are established among ASBR1 and ASBR2. 311 All NVEs and ASBRs are enabled for the EVPN SAFI and exchange EVPN 312 routes. For inter-AS option B, the ASBRs re-advertise these routes 313 with NEXT_HOP attribute set to their IP addresses as per [RFC4271]. 315 NVE1 sets the BGP Encapsulation extended community defined in all 316 EVPN routes advertised. NVE1 sets the BGP Tunnel Encapsulation 317 Attribute Tunnel Type to Geneve tunnel encapsulation, and sets the 318 Tunnel Encapsulation Attribute Tunnel sub-TLV for the Geneve tunnel 319 option types with all the Geneve option types it can transmit and 320 receive. 322 All other NVE(s) learn what Geneve option types are supported by NVE1 323 through the EVPN control plane. In the datapath, NVE2, NVE3 and NVE4 324 MUST only encapsulate overlay packets with the Geneve option TLV(s) 325 that NVE1 is capable of receiving, and in case more than one option 326 TLV is being used, they MUST be in the order specified by NVE1. 328 A PE advertises the BGP Encapsulation extended community defined in 329 [RFC5512] if it supports any of the encapsulations defined in 330 [I-D.ietf-bess-evpn-overlay]. A PE advertises the BGP Tunnel 331 Encapsulation Attribute defined in [I-D.ietf-idr-tunnel-encaps] if it 332 supports Geneve encapsulation. 334 7. Security Considerations 336 The mechanisms in this document use EVPN control plane as defined in 337 [RFC7432]. Security considerations described in [RFC7432] are 338 equally applicable. 340 This document uses IP-based tunnel technologies to support data plane 341 transport. Security considerations described in [RFC7432] and in 342 [I-D.ietf-bess-evpn-overlay] are equally applicable. 344 8. IANA Considerations 346 IANA is requested to allocate the following: 348 BGP Tunnel Encapsulation Attribute 349 Tunnel Type: 351 XX Geneve Encapsulation 353 BGP Tunnel Encapsulation Attribute Sub-TLVs a Code point from the 354 range of 192-252 for Geneve tunnel option types sub-TLV. 356 IANA is requested to assign a new option class from the "Geneve 357 Option Class" registry for the Ethernet option TLV. 359 Option Class Description 360 ------------ --------------- 361 XXXX Ethernet option 363 9. Acknowledgements 365 The authors wish to thank T. Sridhar, for his input, feedback, and 366 helpful suggestions. 368 10. References 370 10.1. Normative References 372 [I-D.ietf-bess-evpn-overlay] 373 Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro, 374 J., and W. Henderickx, "A Network Virtualization Overlay 375 Solution Using Ethernet VPN (EVPN)", Work in Progress, 376 Internet-Draft, draft-ietf-bess-evpn-overlay-12, 9 377 February 2018, . 380 [I-D.ietf-idr-tunnel-encaps] 381 Patel, K., Velde, G. V. D., Sangli, S. R., and J. Scudder, 382 "The BGP Tunnel Encapsulation Attribute", Work in 383 Progress, Internet-Draft, draft-ietf-idr-tunnel-encaps-22, 384 7 January 2021, . 387 [I-D.ietf-nvo3-encap] 388 Boutros, S. and D. E. Eastlake, "NVO3 Encapsulation 389 Considerations", Work in Progress, Internet-Draft, draft- 390 ietf-nvo3-encap-07, 29 July 2021, 391 . 394 [I-D.ietf-nvo3-geneve] 395 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 396 Network Virtualization Encapsulation", Work in Progress, 397 Internet-Draft, draft-ietf-nvo3-geneve-16, 7 March 2020, 398 . 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, 403 DOI 10.17487/RFC2119, March 1997, 404 . 406 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 407 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 408 DOI 10.17487/RFC4271, January 2006, 409 . 411 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 412 Subsequent Address Family Identifier (SAFI) and the BGP 413 Tunnel Encapsulation Attribute", RFC 5512, 414 DOI 10.17487/RFC5512, April 2009, 415 . 417 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 418 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 419 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 420 2015, . 422 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 423 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 424 Support in Ethernet VPN (EVPN) and Provider Backbone 425 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 426 January 2018, . 428 10.2. Informative References 430 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 431 Rekhter, "Framework for Data Center (DC) Network 432 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 433 2014, . 435 Authors' Addresses 437 Sami Boutros (editor) 438 Ciena 439 United States of America 441 Email: sboutros@ciena.com 443 Ali Sajassi 444 Cisco Systems 445 United States of America 447 Email: sajassi@cisco.com 449 John Drake 450 Juniper Networks 451 United States of America 453 Email: jdrake@juniper.net 454 Jorge Rabadan 455 Nokia 456 United States of America 458 Email: jorge.rabadan@nokia.com 460 Sam Aldrin 461 Google 462 United States of America 464 Email: aldrin.ietf@gmail.com