idnits 2.17.1 draft-ietf-bess-evpn-geneve-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 (June 12, 2020) is 1407 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7365' is defined on line 410, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-15 == Outdated reference: A later version (-12) exists of draft-ietf-nvo3-encap-05 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) Summary: 1 error (**), 0 flaws (~~), 4 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: Informational A. Sajassi 5 Expires: December 14, 2020 Cisco Systems 6 J. Drake 7 J. Rabadan 8 S. Aldrin 9 Juniper Networks 10 June 12, 2020 12 EVPN control plane for Geneve 13 draft-ietf-bess-evpn-geneve-01.txt 15 Abstract 17 This document describes how Ethernet VPN (EVPN) control plane can be 18 used with Network Virtualization Overlay over Layer 3 (NVO3) Generic 19 Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 20 solutions. 22 EVPN control plane can also be used by a Network Virtualization 23 Endpoints (NVEs) to express Geneve tunnel option TLV(s)supported in 24 transmission and/or reception of Geneve encapsulated data packets. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 14, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. GENEVE extensions . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Ethernet option TLV . . . . . . . . . . . . . . . . . . . 4 65 5. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 66 5.1. Geneve Tunnel Option Types sub-TLV . . . . . . . . . . . 6 67 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 10.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 The Network Virtualization over Layer 3 (NVO3) solutions for network 79 virtualization in data center (DC) environment are based on an IP- 80 based underlay. An NVO3 solution provides layer 2 and/or layer 3 81 overlay services for virtual networks enabling multi-tenancy and 82 workload mobility. The NVO3 working group have been working on 83 different dataplane encapsulations. The Generic Network 84 Virtualizationi Encapsulation [I-D.ietf-nvo3-geneve] have been 85 recently recommended to be the proposed standard for network 86 virtualization overlay 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 determines how 97 Network Virtualization Edge devices (NVEs) use the GENEVE option TLVs 98 when 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 a Network Virtualization 105 Edge (NVE) to express what Geneve option TLV types it is capable to 106 receive or to send over the Geneve tunnel to 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 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 extensions 146 This document adds some extensions 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 GENVE encapsulation 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 GENVE 161 encapsulation we need a 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: - Option Class is set to Ethernet (new Option Class requested 194 to IANA) - Type is set to EVPN-OPTION (new type requested to IANA) 195 and C bit must be set. - B bit is set to 1 for BUM traffic. - L bit 196 is set to 1 for Leaf-Indication. - Source-ID is a 24-bit value that 197 encodes the ESI-label value signaled on the EVPN Autodiscovery per-ES 198 routes, as described in [RFC7432] for multi-homing and [RFC8317] for 199 leaf-to-leaf BUM filtering. The ESI-label value is encoded in the 200 high-order 20 bits of the Source-ESI field. 202 The egress NVEs that make use of ESIs in the data path (because they 203 have a local multi-homed ES or support [RFC8317] SHOULD advertise 204 their Ethernet A-D per-ES routes along with the Geneve tunnel sub-TLV 205 and in addition to the ESI-label Extended Community. The ingress NVE 206 can then use the Ethernet option-TLV when sending GENEVE packets 207 based on the [RFC7432] and [RFC8317] procedures. The egress NVE will 208 use the Source-ID field in the received packets to make filtering 209 decisions. 211 Note that [I-D.ietf-bess-evpn-overlay] modifies the [RFC7432] split- 212 horizon procedures for NVO3 tunnels using the "local-bias" procedure. 213 "Local- bias" relies on tunnel IP source address checks (instead of 214 ESI- labels) to determine whether a packet can be forwarded to a 215 local ES. 217 While "local-bias" MUST be supported along with GENEVE encapsulation, 218 the use of the Ethernet option-TLV is RECOMMENDED to follow the same 219 procedures used by EVPN MPLS. 221 An ingress NVE using ingress replication to flood BUM traffic MUST 222 send B=1 in all the GENEVE packets that encapsulate BUM frames. An 223 egress NVE SHOULD determine whether a received packet encapsulates a 224 BUM frame based on the B bit. The use of the B bit is only relevant 225 to GENEVE packets with Protocol Type 0x6558 (Bridged Ethernet). 227 5. BGP Extensions 229 As per [I-D.ietf-bess-evpn-overlay] the BGP Encapsulation extended 230 community defined in [I-D.ietf-idr-tunnel-encaps] is included with 231 all EVPN routes advertised by an egress NVE. 233 This document specifies a new BGP Tunnel Encapsulation Type for 234 Geneve and a new Geneve tunnel option types sub-TLV as described 235 below. 237 5.1. Geneve Tunnel Option Types sub-TLV 239 The Geneve tunnel option types is a new BGP Tunnel Encapsulation 240 Attribute Sub-TLV. 242 +-----------------------------------+ 243 | Sub-TLV Type (1 Octet) | 244 +-----------------------------------+ 245 | Sub-TLV Length (1 or 2 Octets)| 246 +-----------------------------------+ 247 | Sub-TLV Value (Variable) | 248 | | 249 +-----------------------------------+ 251 Figure 1: Geneve tunnel option types sub-TLV 253 The Sub-TLV Type field contains a value in the range from 192-252. 254 To be allocated by IANA. 256 Sub-TLV value MUST match exactly the first 4-octets of the option TLV 257 format. For instance, if we need to signal support for two option 258 TLVs: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Option Class | Type |R|R|R| Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Option Class | Type |R|R|R| Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Where, an NVE receiving the above sub-TLV, will send GENEVE packets 269 to the originator NVE with with only the option TLVs the receiver NVE 270 is capable of receiving, and following the same order. Also the high 271 order bit in the type, is the critical bit, MUST be set accordingly. 273 The above sub-TLV(s) MAY be included with only Ethernet A-D per-ES 274 routes. 276 6. Operation 278 The following figure shows an example of an NVO3 deployment with 279 EVPN. 281 +--------------+ 282 | | 283 +---------+ | WAN | +---------+ 284 +----+ | | +----+ +----+ | | +----+ 285 |NVE1|--| | |ASBR| |ASBR| | |--|NVE3| 286 +----+ |IP Fabric|---| 1 | | 2 |--|IP Fabric| +----+ 287 +----+ | | +----+ +----+ | | +----+ 288 |NVE2|--| | | | | |--|NVE4| 289 +----+ +---------+ +--------------+ +---------+ +----+ 291 |<------ DC 1 -----> <---- DC2 ------>| 293 Figure 2: Data Center Interconnect with ASBR 295 iBGP sessions are established between NVE1, NVE2, ASBR1, possibly via 296 a BGP route-reflector. Similarly, iBGP sessions are established 297 between NVE3, NVE4, ASBR2. 299 eBGP sessions are established among ASBR1 and ASBR2. 301 All NVEs and ASBRs are enabled for the EVPN SAFI and exchange EVPN 302 routes. For inter-AS option B, the ASBRs re-advertise these routes 303 with NEXT_HOP attribute set to their IP addresses as per [RFC4271]. 305 NVE1 sets the BGP Encapsulation extended community defined in all 306 EVPN routes advertised. NVE1 sets the BGP Tunnel Encapsulation 307 Attribute Tunnel Type to Geneve tunnel encapsulation, and sets the 308 Tunnel Encapsulation Attribute Tunnel sub-TLV for the Geneve tunnel 309 option types with all the Geneve option types it can transmit and 310 receive. 312 All other NVE(s) learn what Geneve option types are supported by NVE1 313 through the EVPN control plane. In the datapath, NVE2, NVE3 and NVE4 314 only encapsulate overlay packets with the Geneve option TLV(s) that 315 NVE1 is capable of receiving. 317 A PE advertises the BGP Encapsulation extended community defined in 318 [RFC5512] if it supports any of the encapsulations defined in 319 [I-D.ietf-bess-evpn-overlay]. A PE advertises the BGP Tunnel 320 Encapsulation Attribute defined in [I-D.ietf-idr-tunnel-encaps] if it 321 supports Geneve encapsulation. 323 7. Security Considerations 325 The mechanisms in this document use EVPN control plane as defined in 326 [RFC7432]. Security considerations described in [RFC7432] are 327 equally applicable. 329 This document uses IP-based tunnel technologies to support data plane 330 transport. Security considerations described in [RFC7432] and in 331 [I-D.ietf-bess-evpn-overlay] are equally applicable. 333 8. IANA Considerations 335 IANA is requested to allocate the following: 337 BGP Tunnel Encapsulation Attribute 338 Tunnel Type: 340 XX Geneve Encapsulation 342 BGP Tunnel Encapsulation Attribute Sub-TLVs a Code point from the 343 range of 192-252 for Geneve tunnel option types sub-TLV. 345 IANA is requested to assign a new option class from the "Geneve 346 Option Class" registry for the Ethernet option TLV. 348 Option Class Description 349 ------------ --------------- 350 XXXX Ethernet option 352 9. Acknowledgements 354 The authors wish to thank T. Sridhar, for his input, feedback, and 355 helpful suggestions. 357 10. References 359 10.1. Normative References 361 [I-D.ietf-bess-evpn-overlay] 362 Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro, 363 J., and W. Henderickx, "A Network Virtualization Overlay 364 Solution using EVPN", draft-ietf-bess-evpn-overlay-12 365 (work in progress), February 2018. 367 [I-D.ietf-idr-tunnel-encaps] 368 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 369 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 370 (work in progress), December 2019. 372 [I-D.ietf-nvo3-encap] 373 Boutros, S., "NVO3 Encapsulation Considerations", draft- 374 ietf-nvo3-encap-05 (work in progress), February 2020. 376 [I-D.ietf-nvo3-geneve] 377 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 378 Network Virtualization Encapsulation", draft-ietf- 379 nvo3-geneve-16 (work in progress), March 2020. 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, 383 DOI 10.17487/RFC2119, March 1997, 384 . 386 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 387 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 388 DOI 10.17487/RFC4271, January 2006, 389 . 391 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 392 Subsequent Address Family Identifier (SAFI) and the BGP 393 Tunnel Encapsulation Attribute", RFC 5512, 394 DOI 10.17487/RFC5512, April 2009, 395 . 397 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 398 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 399 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 400 2015, . 402 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 403 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 404 Support in Ethernet VPN (EVPN) and Provider Backbone 405 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 406 January 2018, . 408 10.2. Informative References 410 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 411 Rekhter, "Framework for Data Center (DC) Network 412 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 413 2014, . 415 Authors' Addresses 417 Sami Boutros (editor) 418 Ciena 419 USA 421 Email: sboutros@ciena.com 423 Ali Sajassi 424 Cisco Systems 425 USA 427 Email: sajassi@cisco.com 429 John Drake 430 Juniper Networks 431 USA 433 Email: jdrake@juniper.net 435 Jorge Rabadan 436 Juniper Networks 437 USA 439 Email: jorge.rabadan@nokia.com 441 Sam Aldrin 442 Juniper Networks 443 USA 445 Email: aldrin.ietf@gmail.com