idnits 2.17.1 draft-boutros-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In the datapath, a transmitting NVE MUST not encapsulate a packet destined to another NVE with any option TLV(s) the receiving NVE is not capable of processing. -- The document date (June 19, 2017) is 2474 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: 'RFC5512' is mentioned on line 144, but not defined ** Obsolete undefined reference: RFC 5512 (Obsoleted by RFC 9012) == Unused Reference: 'RFC5226' is defined on line 261, 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-04 == Outdated reference: A later version (-12) exists of draft-ietf-nvo3-encap-00 ** 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-03 Summary: 3 errors (**), 0 flaws (~~), 7 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 9 Expires: December 21, 2017 June 19, 2017 11 EVPN control plane for Geneve 12 draft-boutros-bess-evpn-geneve-00.txt 14 Abstract 16 This document describes how Ethernet VPN (EVPN) control plane can be 17 used with Network Virtualization Overlay over Layer 3 (NVO3) Generic 18 Network Virtualization Encapsulation (Geneve) encapsulation in NVO3 19 solutions. EVPN control plane can be used by a Network Virtualization 20 Endpoints (NVEs) to express as well what Geneve tunnel option TLV(s) 21 that they can transmit and/or receive. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1 Geneve Tunnel Option Types sub-TLV . . . . . . . . . . . . . 4 65 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1 Negotiating TLV ordering, Size and total option length . . . 6 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 70 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 72 7.2 Informative References . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1 Introduction 77 The Network Virtualization over Layer 3 (NVO3) develop solutions for 78 network virtualization within a data center (DC) environment that 79 assumes an IP-based underlay. An NVO3 solution provides layer 2 80 and/or layer 3 overlay services for virtual networks enabling multi- 81 tenancy and workload mobility. The NVO3 working group have been 82 working on different dataplane encapsulations. The Generic Network 83 Virtualization Encapsulation [GENEVE] have been recently recommended 84 to be the proposed standard for network virtualization overlay 85 encapsulation. 87 This document describes how the EVPN control plane can signals Geneve 88 encapsulation type in the BGP Tunnel Encapsulation Extended 89 Community. The also document defines how to communicate the Geneve 90 tunnel option types in a new BGP Tunnel Encapsulation Attribute sub- 91 TLV. The Geneve tunnel options are encapsulated as TLVs after the 92 Geneve base header in the Geneve packet as described in [GENEVE]. 94 The NVO3 encapsulation design team has made a recommendation in [DT- 95 ENCAP] for a control plane to negotiate a subset of option TLVs and 96 certain TLV ordering, as well can limit the total number of option 97 TLVs present in the packet, for example, to allow hardware capable of 98 processing fewer options. 100 This EVPN control plane extension will allow a Network Virtualization 101 Endpoint (NVE) to express what Geneve option TLV types it is capable 102 to receive or to send over the Geneve tunnel to its peers. 104 In the datapath, a transmitting NVE MUST not encapsulate a packet 105 destined to another NVE with any option TLV(s) the receiving NVE is 106 not capable of processing. 108 1.1 Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 Most of the terminology used in this documents comes from [RFC7432] 115 and [NVO3-FRWK]. 117 NVO3: Network Virtualization Overlay over Layer 3 119 GENEVE: Generic Network Virtualization Encapsulation. 121 NVE: Network Virtualization Endpoint. 123 VNI: Virtual Network Identifier. 125 MAC: Media Access Control. 127 OAM: Operations, Administration and Maintenance. 129 PE: Provide Edge Node. 131 CE: Customer Edge device e.g., host or router or switch. 133 EVPN: Ethernet VPN. 135 EVI: An EVPN instance spanning the Provider Edge (PE) devices 136 participating in that EVPN. 138 MAC-VRF: A Virtual Routing and Forwarding table for Media Access 139 Control (MAC) addresses on a PE. 141 2. BGP Extensions 143 As per [ietf-evpn-overlay] the BGP Encapsulation extended community 144 defined in [TUNNEL-ENCAP] and [RFC5512] is included with all EVPN 145 routes advertised by an egress NVE. 147 This document specifies a new BGP Tunnel Encapsulation Type for 148 Geneve and a new Geneve tunnel option types sub-TLV as described 149 below. 151 2.1 Geneve Tunnel Option Types sub-TLV 153 The Geneve tunnel option types is a new BGP Tunnel Encapsulation 154 Attribute Sub-TLV. 156 +-----------------------------------+ 157 | Sub-TLV Type (1 Octet) | 158 +-----------------------------------+ 159 | Sub-TLV Length (1 or 2 Octets)| 160 +-----------------------------------+ 161 | Sub-TLV Value (Variable) | 162 | | 163 +-----------------------------------+ 165 Figure 1: Geneve tunnel option types sub-TLV 167 The Sub-TLV Type field contains a value in the range from 192-252. 168 To be allocated by IANA. 170 Sub-TLV value will be the Geneve option TLV types, each type will 171 be encoded as a 24 bit value. 173 3. Operation 175 The following figure shows an example of an NVO3 deployment with 176 EVPN. 178 +--------------+ 179 | | 180 +---------+ | WAN | +---------+ 181 +----+ | | +----+ +----+ | | +----+ 182 |NVE1|--| | |ASBR| |ASBR| | |--|NVE3| 183 +----+ |IP Fabric|---| 1 | | 2 |--|IP Fabric| +----+ 184 +----+ | | +----+ +----+ | | +----+ 185 |NVE2|--| | | | | |--|NVE4| 186 +----+ +---------+ +--------------+ +---------+ +----+ 188 |<------ DC 1 -----> <---- DC2 ------>| 190 Figure 2: Data Center Interconnect with ASBR 192 iBGP sessions are established between NVE1, NVE2, ASBR1, possibly via 193 a BGP route-reflector. Similarly, iBGP sessions are established 194 between NVE3, NVE4, ASBR2. 196 eBGP sessions are established among ASBR1 and ASBR2. 198 All NVEs and ASBRs are enabled for the EVPN SAFI and exchange EVPN 199 routes. For inter-AS option B, the ASBRs re-advertise these routes 200 with NEXT_HOP attribute set to their IP addresses as per [RFC4271]. 202 NVE1 sets the BGP Encapsulation extended community defined in all 203 EVPN routes advertised. NVE1 sets the BGP Tunnel Encapsulation 204 Attribute Tunnel Type to Geneve tunnel encapsulation, and sets the 205 Tunnel Encapsulation Attribute Tunnel sub-TLV for the Geneve tunnel 206 option types with all the Geneve option types it can transmit and 207 receive. 209 All other NVE(s) learn what Geneve option types are supported by NVE1 210 through the EVPN control plane. In the datapath, NVE2, NVE3 and NVE4 211 only encapsulate overlay packets with the Geneve option TLV(s) that 212 NVE1 is capable of receiving. 214 3.1 Negotiating TLV ordering, Size and total option length 216 TBD 218 4. Security Considerations 220 The mechanisms in this document use EVPN control plane as defined in 221 [RFC7432]. Security considerations described in [RFC7432] are equally 222 applicable. 224 This document uses IP-based tunnel technologies to support data plane 225 transport. Security considerations described in [RFC7432] and in 226 [ietf-evpn-overlay] are equally applicable. 228 5. IANA Considerations 230 IANA is requested to allocate the following: 232 BGP Tunnel Encapsulation Attribute Tunnel Type: 234 XX Geneve Encapsulation 236 BGP Tunnel Encapsulation Attribute Sub-TLVs A Code point from the 237 range of 192-252 for Geneve tunnel option types sub-TLV. 239 6. Acknowledgements 241 The authors wish to thank T. Sridhar, for his input, feedback, and 242 helpful suggestions. 244 7 References 246 7.1 Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 250 1997, . 252 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 253 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 254 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 257 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 258 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, . 261 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 262 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, 263 . 265 [GENEVE] Gross, et al. "Geneve: Generic Network Virtualization 266 Encapsulation", draft-ietf-nvo3-geneve-04, work in progress, March, 267 2017. 269 [DT-ENCAP] Boutros, et al. "NVO3 Encapsulation Considerations", 270 draft-ietf-nvo3-encap-00, work in progress, June, 2017. 272 7.2 Informative References 274 [NVO3-FRWK] Lasserre et al., "Framework for DC Network 275 Virtualization", RFC 7365, October 2014. 277 [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation 278 Attribute", draft-ietf-idr-tunnel-encaps-03, work in progress, May 279 31, 2016. 281 [ietf-evpn-overlay] Sajassi-Drake et al., "A Network Virtualization 282 Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-07.txt, 283 work in progress, December, 2016 285 Authors' Addresses 287 Sami Boutros 288 VMware, Inc. 289 Email: sboutros@vmware.com 291 Ali Sajassi 292 Cisco 293 Email: sajassi@cisco.com 295 John Drake 296 Juniper Networks 297 Email: jdrake@juniper.net