idnits 2.17.1 draft-boutros-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 (February 13, 2018) is 2263 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: 'EVPN-ETREE' is mentioned on line 193, but not defined == Missing Reference: 'TBD' is mentioned on line 327, but not defined == Unused Reference: 'RFC5226' is defined on line 381, 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: 2 errors (**), 0 flaws (~~), 8 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: August 17, 2018 February 13, 2018 13 EVPN control plane for Geneve 14 draft-boutros-bess-evpn-geneve-01.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 in NVO3 21 solutions. EVPN control plane can be used by a Network Virtualization 22 Endpoints (NVEs) to express as well what Geneve tunnel option TLV(s) 23 that they can transmit and/or receive. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 47 Copyright (c) 2018 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 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. GENEVE extensions . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1 Source Ethernet Segment option TLV . . . . . . . . . . . . . 4 66 2.2 BUM bit for Bridge Ethernet Protocol Type . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1 Introduction 80 The Network Virtualization over Layer 3 (NVO3) develop solutions for 81 network virtualization within a data center (DC) environment that 82 assumes an IP-based underlay. An NVO3 solution provides layer 2 83 and/or layer 3 overlay services for virtual networks enabling multi- 84 tenancy and workload mobility. The NVO3 working group have been 85 working on 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", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 Most of the terminology used in this documents comes from [RFC7432] 121 and [NVO3-FRWK]. 123 NVO3: Network Virtualization Overlay over Layer 3 125 GENEVE: Generic Network Virtualization Encapsulation. 127 NVE: Network Virtualization Edge. 129 VNI: Virtual Network Identifier. 131 MAC: Media Access Control. 133 OAM: Operations, Administration and Maintenance. 135 PE: Provide Edge Node. 137 CE: Customer Edge device e.g., host or router or switch. 139 EVPN: Ethernet VPN. 141 EVI: An EVPN instance spanning the Provider Edge (PE) devices 142 participating in that EVPN. 144 MAC-VRF: A Virtual Routing and Forwarding table for Media Access 145 Control (MAC) addresses on a PE. 146 2. GENEVE extensions 148 This document adds some extensions to the [GENEVE] encapsulation that 149 are relevant to the operation of EVPN. 151 2.1 Source Ethernet Segment option TLV 153 [RFC7432] defines the use of ESI-labels on egress NVEs that are part 154 of multi-homed Ethernet Segments (ES), so that they can determine if 155 the received packet was originated from an ES that is also locally 156 defined. Based on the ESI-label, the egress NVE can apply split- 157 horizon for the local ES'es and avoid packet duplication in all- 158 active multi-homing. In single-active multi-homing, packet 159 duplication can also happen during transient times, therefore the use 160 of ESI-labels and split-horizon checks are strongly recommended too. 162 In addition, [EVPN-ETREE] makes use of the ESI-labels to indicate BUM 163 leaf AC originated packets, so that the egress NVEs can filter BUM 164 traffic between leaf ACs. 166 In order to apply existing EVPN data plane split-horizon and E-Tree 167 filtering procedures, this document describes a new option TLV for 168 GENEVE: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Option Class=EVPN | Type=ESI |R|R|R| Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Rsvd | Source-ESI | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Where: 179 - Option Class is set to EVPN (new Option Class requested to 180 IANA) 181 - Type is set to ESI (new type requested to IANA) and C bit 182 must be set. 183 - Source-ESI is a 24-bit value that encodes the ESI-label value 184 signaled on the EVPN Autodiscovery per-ES routes, as described 185 in [RFC7432] for multi-homing and [EVPN-ETREE] for leaf-to-leaf 186 BUM filtering. 188 The egress NVEs that make use of ESIs in the data path (because they 189 have a local multi-homed ES or support [EVPN-ETREE]) SHOULD advertise 190 their AD per-ES routes along with the EVPN/ESI sub-TLV and in 191 addition to the ESI-label Extended Community. The ingress NVE can 192 then use the EVPN/ESI option-TLV when sending GENEVE packets based on 193 the [RFC7432] and [EVPN-ETREE] procedures. The egress NVE will use 194 the Source-ESI field in the received packets to make filtering 195 decisions. 197 Note that [EVPN-OVERLAY] modifies the [RFC7432] split-horizon 198 procedures for NVO3 tunnels using the "local-bias" procedure. "Local- 199 bias" relies on tunnel IP source address checks (instead of ESI- 200 labels) to determine whether a packet can be forwarded to a local ES. 202 While "local-bias" MUST be supported along with GENEVE encapsulation, 203 the use of the EVPN/ESI option-TLV is RECOMMENDED in cases where 204 local-bias does not work, for instance: single-active multi-homing, 205 multi-homing ES'es in Inter-AS option B scenarios and EVPN-ETREE. 207 2.2 BUM bit for Bridge Ethernet Protocol Type 209 As described in [EVPN-OVERLAY], in EVPN, when an ingress NVE uses 210 ingress replication to flood unknown unicast traffic to the egress 211 NVEs, the ingress NVE needs to indicate to the egress NVE that the 212 packet encapsulates an ingress replicated BUM frame. This is required 213 to avoid transient packet duplication in all-active multi-homing 214 scenarios. 216 This document defines the B bit as the ingress-replicated BUM traffic 217 indication and encodes it in Source Ethernet Segment option TLV. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Option Class=EVPN | Type=ESI |B|R|R| Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |B| Rsvd | Source-ESI | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Where: 228 - Option Class is set to EVPN. 229 - Type is set to ESI. 230 - B bit is set to 1 for BUM traffic. 231 - Source-ESI is set to 0 or to a value identifying the ingress 232 NVE. 234 An ingress NVE using ingress replication to flood BUM traffic MUST 235 send B=1 in all the GENEVE packets that encapsulate BUM frames. An 236 egress NVE SHOULD determine whether a received packet encapsulates a 237 BUM frame based on the B bit. The use of the B bit is only relevant 238 to GENEVE packets with Protocol Type 0x6558 (Bridged Ethernet). 240 3. BGP Extensions 242 As per [EVPN-OVERLAY] the BGP Encapsulation extended community 243 defined in [TUNNEL-ENCAP] is included with all EVPN routes advertised 244 by an egress NVE. 246 This document specifies a new BGP Tunnel Encapsulation Type for 247 Geneve and a new Geneve tunnel option types sub-TLV as described 248 below. 250 3.1 Geneve Tunnel Option Types sub-TLV 252 The Geneve tunnel option types is a new BGP Tunnel Encapsulation 253 Attribute Sub-TLV. 255 +-----------------------------------+ 256 | Sub-TLV Type (1 Octet) | 257 +-----------------------------------+ 258 | Sub-TLV Length (1 or 2 Octets)| 259 +-----------------------------------+ 260 | Sub-TLV Value (Variable) | 261 | | 262 +-----------------------------------+ 264 Figure 1: Geneve tunnel option types sub-TLV 266 The Sub-TLV Type field contains a value in the range from 192-252. 267 To be allocated by IANA. 269 Sub-TLV value MUST match exactly the first 4-octets of the option TLV 270 format. For instance, if we need to signal support for two option 271 TLVs: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Option Class | Type |R|R|R| Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Option Class | Type |R|R|R| Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Where, an NVE receiving the above sub-TLV, will send GENEVE packets 282 to the originator NVE with with only the option TLVs the receiver NVE 283 is capable of receiving, and following the same order. Also the high 284 order bit in the type, is the critical bit, MUST be set accordingly. 286 4. 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 only encapsulate overlay packets with the Geneve option TLV(s) that 325 NVE1 is capable of receiving. 327 [TBD] How do we propagate the signaling of GENEVE option-TLVs end to 328 end using other encaps? 330 5. Security Considerations 332 The mechanisms in this document use EVPN control plane as defined in 333 [RFC7432]. Security considerations described in [RFC7432] are equally 334 applicable. 336 This document uses IP-based tunnel technologies to support data plane 337 transport. Security considerations described in [RFC7432] and in 338 [EVPN-OVERLAY] are equally applicable. 340 6. IANA Considerations 342 IANA is requested to allocate the following: 344 BGP Tunnel Encapsulation Attribute 345 Tunnel Type: 347 XX Geneve Encapsulation 349 BGP Tunnel Encapsulation Attribute Sub-TLVs a Code point from the 350 range of 192-252 for Geneve tunnel option types sub-TLV. 352 IANA is requested to assign a new option class from the "Geneve 353 Option Class" registry for the Source Ethernet Segment option TLV. 355 Option Class Description 356 ------------ ------------------------------ 357 XXXX Source Ethernet Segment option 359 7. Acknowledgements 361 The authors wish to thank T. Sridhar, for his input, feedback, and 362 helpful suggestions. 364 8. References 366 8.1 Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 370 1997, . 372 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 373 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 374 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 377 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 378 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, . 381 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 382 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, 383 . 385 [GENEVE] Gross, et al. "Geneve: Generic Network Virtualization 386 Encapsulation", draft-ietf-nvo3-geneve-05, work in progress, 387 September, 2017. 389 [DT-ENCAP] Boutros, et al. "NVO3 Encapsulation Considerations", 390 draft-ietf-nvo3-encap-01, work in progress, October, 2017. 392 8.2 Informative References 394 [NVO3-FRWK] Lasserre et al., "Framework for DC Network 395 Virtualization", RFC 7365, October 2014. 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 Authors' Addresses 407 Sami Boutros 408 VMware, Inc. 409 Email: sboutros@vmware.com 411 Ali Sajassi 412 Cisco 413 Email: sajassi@cisco.com 415 John Drake 416 Juniper Networks 417 Email: jdrake@juniper.net 419 Jorge Rabadan 420 Nokia 421 Email: jorge.rabadan@nokia.com>