idnits 2.17.1 draft-ietf-bess-evpn-geneve-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 == Line 174 has weird spacing: '...so that a) ...' == Line 175 has weird spacing: '...pes and b) t...' -- The document date (August 7, 2019) is 1717 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) == Missing Reference: 'RFC8174' is mentioned on line 123, but not defined == Missing Reference: 'RFC5512' is mentioned on line 327, but not defined ** Obsolete undefined reference: RFC 5512 (Obsoleted by RFC 9012) == Unused Reference: 'RFC5226' is defined on line 386, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-05 == Outdated reference: A later version (-12) exists of draft-ietf-nvo3-encap-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-encap (ref. 'DT-ENCAP') == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-07 == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-overlay-10 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Sami Boutros 3 Intended Status: Standard Track VMware 4 Ali Sajassi 5 Cisco Systems 6 John Drake 7 Juniper Networks 8 Jorge Rabadan 9 Nokia 10 Sam Aldrin 11 Google 12 Expires: February 8, 2020 August 7, 2019 14 EVPN control plane for Geneve 15 draft-ietf-bess-evpn-geneve-00.txt 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. EVPN control plane can also be used by a Network 23 Virtualization Endpoints (NVEs) to express Geneve tunnel option 24 TLV(s)supported in transmission and/or reception of Geneve 25 encapsulated data packets. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. GENEVE extensions . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1 Ethernet option TLV . . . . . . . . . . . . . . . . . . . . 4 69 3. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1 Geneve Tunnel Option Types sub-TLV . . . . . . . . . . . . . 6 71 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 77 8.2 Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1 Introduction 82 The Network Virtualization over Layer 3 (NVO3) solutions for network 83 virtualization in data center (DC) environment are based on an IP- 84 based underlay. An NVO3 solution provides layer 2 and/or layer 3 85 overlay services for virtual networks enabling multi-tenancy and 86 workload mobility. The NVO3 working group have been working on 87 different dataplane encapsulations. The Generic Network 88 Virtualization Encapsulation [GENEVE] have been recently recommended 89 to be the proposed standard for network virtualization overlay 90 encapsulation. 92 This document describes how the EVPN control plane can signal Geneve 93 encapsulation type in the BGP Tunnel Encapsulation Extended Community 94 defined in [TUNNEL-ENCAP]. In addition, this document defines how to 95 communicate the Geneve tunnel option types in a new BGP Tunnel 96 Encapsulation Attribute sub-TLV. The Geneve tunnel options are 97 encapsulated as TLVs after the Geneve base header in the Geneve 98 packet as described in [GENEVE]. 100 [DT-ENCAP] recommends that a control plane determines how Network 101 Virtualization Edge devices (NVEs) use the GENEVE option TLVs when 102 sending/receiving packets. In particular, the control plane 103 negotiates the subset of option TLVs supported, their order and the 104 total number of option TLVs allowed in the packets. This negotiation 105 capability allows, for example, interoperability with hardware-based 106 NVEs that can process fewer options than software-based NVEs. 108 This EVPN control plane extension will allow a Network Virtualization 109 Edge (NVE) to express what Geneve option TLV types it is capable to 110 receive or to send over the Geneve tunnel to its peers. 112 In the datapath, a transmitting NVE MUST NOT encapsulate a packet 113 destined to another NVE with any option TLV(s) the receiving NVE is 114 not capable of processing. 116 1.1 Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 Most of the terminology used in this documents comes from [RFC7432] 125 and [NVO3-FRWK]. 127 NVO3: Network Virtualization Overlay over Layer 3 128 GENEVE: Generic Network Virtualization Encapsulation. 130 NVE: Network Virtualization Edge. 132 VNI: Virtual Network Identifier. 134 MAC: Media Access Control. 136 OAM: Operations, Administration and Maintenance. 138 PE: Provide Edge Node. 140 CE: Customer Edge device e.g., host or router or switch. 142 EVPN: Ethernet VPN. 144 EVI: An EVPN instance spanning the Provider Edge (PE) devices 145 participating in that EVPN. 147 MAC-VRF: A Virtual Routing and Forwarding table for Media Access 148 Control (MAC) addresses on a PE. 150 2. GENEVE extensions 152 This document adds some extensions to the [GENEVE] encapsulation that 153 are relevant to the operation of EVPN. 155 2.1 Ethernet option TLV 157 [EVPN-OVERLAY] describes when an ingress NVE uses ingress replication 158 to flood unknown unicast traffic to the egress NVEs, the ingress NVE 159 needs to indicate to the egress NVE that the Encapsulated packet is a 160 BUM traffic type. This is required to avoid transient packet 161 duplication in all-active multi-homing scenarios. For GENVE 162 encapsulation we need a bit to for this purpose. 164 [RFC8317] uses MPLS label for leaf indication of BUM traffic 165 originated from a leaf AC in an ingress NVE so that the egress NVEs 166 can filter BUM traffic toward their leaf ACs. For GENVE encapsulation 167 we need a bit for this purpose. 169 Although the default mechanism for split-horizon filtering of BUM 170 traffic on an Ethernet segment for IP-based ecnapsulations such as 171 VxLAN, GPE, NVGRE, and GENVE, is local-bias as defined in section 172 8.3.1 of [EVPN-OVERLAY], there can be an incentive to leverage the 173 same split-horizon filtering mechanism of [RFC7432] that uses a 20- 174 bit MPLS label so that a) the a single filtering mechanism is used 175 for all encapsulation types and b) the same PE can participate in a 176 mix of MPLS and IP encapsulations. For this purpose a 20-bit label 177 field MAY be defined for GENVE encapsulation. The support for this 178 label is optional. 180 If an NVE wants to use local-bias procedure, then it sends the new 181 option TLV without ESI-label (e.g., length=4): 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Option Class=Ethernet |Type=0 |B|L|R| Len=0x1 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 If an NVE wants to use ESI-label, then it sends the new option TLV 189 with ESI-label (e.g., length=8) 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Option Class=Ethernet |Typ=EVPN-OPTION|B|L|R| Len=0x2 | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Rsvd | Source-ID | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Where: 200 - Option Class is set to Ethernet (new Option Class requested 201 to IANA) 202 - Type is set to EVPN-OPTION (new type requested to IANA) and 203 C bit must be set. 204 - B bit is set to 1 for BUM traffic. 205 - L bit is set to 1 for Leaf-Indication. 206 - Source-ID is a 24-bit value that encodes the ESI-label value 207 signaled on the EVPN Autodiscovery per-ES routes, as described 208 in [RFC7432] for multi-homing and [RFC8317] for leaf-to-leaf 209 BUM filtering. The ESI-label value is encoded in the high-order 210 20 bits of the Source-ESI field. 212 The egress NVEs that make use of ESIs in the data path (because they 213 have a local multi-homed ES or support [RFC8317]) SHOULD advertise 214 their Ethernet A-D per-ES routes along with the Geneve tunnel sub-TLV 215 and in addition to the ESI-label Extended Community. The ingress NVE 216 can then use the Ethernet option-TLV when sending GENEVE packets 217 based on the [RFC7432] and [RFC8317] procedures. The egress NVE will 218 use the Source-ID field in the received packets to make filtering 219 decisions. 221 Note that [EVPN-OVERLAY] modifies the [RFC7432] split-horizon 222 procedures for NVO3 tunnels using the "local-bias" procedure. "Local- 223 bias" relies on tunnel IP source address checks (instead of ESI- 224 labels) to determine whether a packet can be forwarded to a local ES. 226 While "local-bias" MUST be supported along with GENEVE encapsulation, 227 the use of the Ethernet option-TLV is RECOMMENDED to follow the same 228 procedures used by EVPN MPLS. 230 An ingress NVE using ingress replication to flood BUM traffic MUST 231 send B=1 in all the GENEVE packets that encapsulate BUM frames. An 232 egress NVE SHOULD determine whether a received packet encapsulates a 233 BUM frame based on the B bit. The use of the B bit is only relevant 234 to GENEVE packets with Protocol Type 0x6558 (Bridged Ethernet). 236 3. BGP Extensions 238 As per [EVPN-OVERLAY] the BGP Encapsulation extended community 239 defined in [TUNNEL-ENCAP] is included with all EVPN routes advertised 240 by an egress NVE. 242 This document specifies a new BGP Tunnel Encapsulation Type for 243 Geneve and a new Geneve tunnel option types sub-TLV as described 244 below. 246 3.1 Geneve Tunnel Option Types sub-TLV 248 The Geneve tunnel option types is a new BGP Tunnel Encapsulation 249 Attribute Sub-TLV. 251 +-----------------------------------+ 252 | Sub-TLV Type (1 Octet) | 253 +-----------------------------------+ 254 | Sub-TLV Length (1 or 2 Octets)| 255 +-----------------------------------+ 256 | Sub-TLV Value (Variable) | 257 | | 258 +-----------------------------------+ 260 Figure 1: Geneve tunnel option types sub-TLV 262 The Sub-TLV Type field contains a value in the range from 192-252. 263 To be allocated by IANA. 265 Sub-TLV value MUST match exactly the first 4-octets of the option TLV 266 format. For instance, if we need to signal support for two option 267 TLVs: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Option Class | Type |R|R|R| Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Option Class | Type |R|R|R| Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Where, an NVE receiving the above sub-TLV, will send GENEVE packets 278 to the originator NVE with with only the option TLVs the receiver NVE 279 is capable of receiving, and following the same order. Also the high 280 order bit in the type, is the critical bit, MUST be set accordingly. 282 The above sub-TLV(s) MAY be included with only Ethernet A-D per-ES 283 routes. 285 4. Operation 287 The following figure shows an example of an NVO3 deployment with 288 EVPN. 290 +--------------+ 291 | | 292 +---------+ | WAN | +---------+ 293 +----+ | | +----+ +----+ | | +----+ 294 |NVE1|--| | |ASBR| |ASBR| | |--|NVE3| 295 +----+ |IP Fabric|---| 1 | | 2 |--|IP Fabric| +----+ 296 +----+ | | +----+ +----+ | | +----+ 297 |NVE2|--| | | | | |--|NVE4| 298 +----+ +---------+ +--------------+ +---------+ +----+ 300 |<------ DC 1 -----> <---- DC2 ------>| 302 Figure 2: Data Center Interconnect with ASBR 304 iBGP sessions are established between NVE1, NVE2, ASBR1, possibly via 305 a BGP route-reflector. Similarly, iBGP sessions are established 306 between NVE3, NVE4, ASBR2. 308 eBGP sessions are established among ASBR1 and ASBR2. 310 All NVEs and ASBRs are enabled for the EVPN SAFI and exchange EVPN 311 routes. For inter-AS option B, the ASBRs re-advertise these routes 312 with NEXT_HOP attribute set to their IP addresses as per [RFC4271]. 314 NVE1 sets the BGP Encapsulation extended community defined in all 315 EVPN routes advertised. NVE1 sets the BGP Tunnel Encapsulation 316 Attribute Tunnel Type to Geneve tunnel encapsulation, and sets the 317 Tunnel Encapsulation Attribute Tunnel sub-TLV for the Geneve tunnel 318 option types with all the Geneve option types it can transmit and 319 receive. 321 All other NVE(s) learn what Geneve option types are supported by NVE1 322 through the EVPN control plane. In the datapath, NVE2, NVE3 and NVE4 323 only encapsulate overlay packets with the Geneve option TLV(s) that 324 NVE1 is capable of receiving. 326 A PE advertises the BGP Encapsulation extended community defined in 327 [RFC5512] if it supports any of the encapsulations defined in [EVPN- 328 OVERLAY]. A PE advertises the BGP Tunnel Encapsulation Attribute 329 defined in [TUNNEL-ENCAP] if it supports Geneve encapsulation. 331 5. Security Considerations 333 The mechanisms in this document use EVPN control plane as defined in 334 [RFC7432]. Security considerations described in [RFC7432] are equally 335 applicable. 337 This document uses IP-based tunnel technologies to support data plane 338 transport. Security considerations described in [RFC7432] and in 339 [EVPN-OVERLAY] are equally applicable. 341 6. IANA Considerations 343 IANA is requested to allocate the following: 345 BGP Tunnel Encapsulation Attribute 346 Tunnel Type: 348 XX Geneve Encapsulation 350 BGP Tunnel Encapsulation Attribute Sub-TLVs a Code point from the 351 range of 192-252 for Geneve tunnel option types sub-TLV. 353 IANA is requested to assign a new option class from the "Geneve 354 Option Class" registry for the Ethernet option TLV. 356 Option Class Description 357 ------------ --------------- 358 XXXX Ethernet option 360 7. Acknowledgements 362 The authors wish to thank T. Sridhar, for his input, feedback, and 363 helpful suggestions. 365 8. References 367 8.1 Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 371 1997, . 373 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 374 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 375 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 378 [RFC8317] Sajassi, et al. "Ethernet-Tree (E-Tree) Support in Ethernet 379 VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)", RFC 8317, 380 January 2018, . 382 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 383 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, . 386 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 387 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, 388 . 390 [GENEVE] Gross, et al. "Geneve: Generic Network Virtualization 391 Encapsulation", draft-ietf-nvo3-geneve-05, work in progress, 392 September, 2017. 394 [DT-ENCAP] Boutros, et al. "NVO3 Encapsulation Considerations", 395 draft-ietf-nvo3-encap-01, work in progress, October, 2017. 397 [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation 398 Attribute", draft-ietf-idr-tunnel-encaps-07, work in progress, July, 399 2017. 401 [EVPN-OVERLAY] Sajassi-Drake et al., "A Network Virtualization 402 Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-10.txt, 403 work in progress, December, 2017 405 8.2 Informative References 407 [NVO3-FRWK] Lasserre et al., "Framework for DC Network 408 Virtualization", RFC 7365, October 2014. 410 Authors' Addresses 412 Sami Boutros 413 VMware, Inc. 414 Email: boutross@vmware.com 416 Ali Sajassi 417 Cisco 418 Email: sajassi@cisco.com 420 John Drake 421 Juniper Networks 422 Email: jdrake@juniper.net 424 Jorge Rabadan 425 Nokia 426 Email: jorge.rabadan@nokia.com 428 Sam Aldrin 429 Google 430 Email: aldrin.ietf@gmail.com