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