idnits 2.17.1 draft-boutros-bess-evpn-auto-provisoning-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 97 has weird spacing: '...thernet port ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2016) is 2745 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: 'RFC2119' is mentioned on line 117, but not defined == Missing Reference: 'EVPN-REQ' is mentioned on line 121, but not defined == Unused Reference: 'KEYWORDS' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC7209' is defined on line 267, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-vpws-00 Summary: 1 error (**), 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 Rex Fernando 5 Ali Sajassi 6 Cisco Systems 8 Kitty Pang 9 Alibaba 11 Tapraj Singh 12 Juniper 14 Expires: April 24, 2017 October 21, 2016 16 EVPN auto provisioning using a controller 17 draft-boutros-bess-evpn-auto-provisoning-02 19 Abstract 21 In some datacenter use cases, priori knowledge of what PE/NVE to be 22 configured for a given L2 or L3 service may not be available. This 23 document describes how EVPN can be extended to discover what L2 or L3 24 services to be enabled on a given PE/NVE, based on first sign of life 25 FSOL packets received on the PE/NVE ports. An EVPN route based on the 26 FSOL packets will be sent to a controller to trigger a push of the 27 related L2/L3 or subscriber service configuration to be provisioned 28 on the PE/NVE and on the switch ports. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.1 Auto-Provisioning . . . . . . . . . . . . . . . . . . . . . 3 71 2.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2.3 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.4 Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.5 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 77 5 Ethernet Segment identifier encoding . . . . . . . . . . . . . . 6 78 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 79 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 80 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 81 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 83 9.2 Informative References . . . . . . . . . . . . . . . . . . 7 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 86 1 Introduction 88 This document describes how EVPN can be extended by access PE/NVE 89 nodes and a controller in a data center to auto provision the L2 or 90 L3 services needed to be enabled on the PE/NVE nodes. 92 Initially, all the PE/NVE nodes are configured with a default EVPN 93 service that includes all Ethernet access ports. Based on the FSOL 94 packets received on any of the Ethernet trunk ports, an EVPN MAC/IP 95 Advertisement route is sent to the controller containing the MAC and 96 IP information associated with this FSOL packet. The ESI field of the 97 route encodes both the Ethernet port information as well as the 98 Ethernet Tag associated with the FSOL packet. 100 Once the controller receives the MAC/IP Advertisement route from the 101 PE/NVE node, it consults a pre-configured policy for any L2 or L3 102 services that need to be enabled on this PE/NVE node based on the 103 information in the route. Any combination of fields encoded in the 104 EVPN route may be used to that effect. If such service is required to 105 be pushed to the PE/NVE node, the controller pushes the provisioning 106 information to the access PE/NVE node and other PE/NVE nodes involved 107 in this L2/L3 or subscriber service. 109 The alternative is to configure every EVPN instance on all PE/NVEs 110 and that poses a scale concern on the PE/NVEs deployed in the DC. 112 1.1 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 RFC 2119 [RFC2119]. 118 2. Requirements 120 This section describes the requirements specific to this draft. These 121 requirements are in addition to the ones described in [EVPN-REQ], 122 [EVPN], and [EVPN-VPWS]. 124 2.1 Auto-Provisioning 126 Auto provisioning of L2/L3 and subscriber services on PE/NVE nodes 127 connected to a IP/MPLS fabric based on the FSOL packets received by 128 the PE/NVE nodes. 130 2.2 Scalability 131 A single controller node can provision many access PE/NVE nodes. 133 A single controller node must be able to handle all EVPN routes 134 received from all the access PE/NVE nodes that it is controlling. 136 2.3 Redundancy 138 TBD 140 2.4 Multi-homing 142 TBD 144 2.5 Fast Convergence 146 TBD 148 3. Benefits 150 This section describes some of the major benefits of EVPN Auto- 151 provisioning. 153 Majors benefits are: 155 - An easy and scalable mechanism for auto provisioning access 156 PE/NVE nodes connected to a DC fabric based on FSOL using 157 EVPN control plane. 159 - Auto-provision features such as QOS access lists (ACL), tunnel 160 preference, bandwidth, L3VPN, EVPN, etc.. based on the policy plane 161 previously available to the controller. 163 4. Solution Overview 164 +----------+ 165 |Controller| 166 +----------+ 168 +---------+ 169 | | 170 +-------+ +--------+ | IP/MPLS | +--------+ +-------+ 171 |Server1|---|access |-| Access |-|access |---|Server2| 172 +-------+ |PE-1 | | Network | |PE-2 | +-------+ 173 +--------+ | | +--------+ 174 +---------+ 176 Figure 1: 178 EVPN-Auto provisioning Operation 180 Initially all the access PE/NVE nodes trunk ports will be associated 181 with a default bridge and will be associated with a default EVPN 182 instance that all PE/NVE node(s) and the controller are part of. 184 Based on FSOL packet received from Server1, an EVPN MAC/IP 185 Advertisement route will be sent by PE-1 to the controller, the ESI 186 value will be encoded to contain the access port number and the 187 Ethernet Tag(s) associated with the FSOL packet, the IP and MAC 188 fields will be set based on the source IP and MAC information on the 189 FSOL packet. 191 Assuming for example, an operator previously provisioned a policy to 192 associate a VLAN identifier on a given PE or set of PE(s) with a L2 193 or L3 service. 195 An operator may as well have previously provisioned an IPoE, MAC 196 session or an unclassified VLAN or MAC service associated on with a 197 given port on the access PE/NVE. 199 When the BGP EVPN advertisement is received by the controller, the 200 controller checks the policy, and pushes down to the PE/NVE node or 201 set of PE/NVE nodes(s) the L2/L3 or subscriber service to be 202 provisioned on those access routers/switches. 204 A controller may as well based on the type of service, do 205 authentication and authorization of service first before pushing the 206 configuration associated with the service to the access PE/NVE. 208 When the service configured by the controller is an EVPN service, the 209 provisioned access PE/NVE will advertise to other BGP Peers Inclusive 210 Multicast route, the receiving PE/NVE(s) will check if an EVPN 211 service/EVI is configured with same RT or not. If the service is not 212 configured with received RT the receiving PE may send the received 213 Inclusive Mcast route to the controller. The Inclusive Mcast route 214 may have the Ethernet Tag field set. Upon receiving the Inclusive 215 Mcast route a controller may do authentication and authorization 216 service and may push service configuration associated with the 217 service to the PE/NVE. 219 Please note that controller's capability is outside of the scope of 220 this draft. 222 5 Ethernet Segment identifier encoding 224 This document proposes a new ESI type to encode the Ethernet port on 225 which the FSOL packet was received, and the Ethernet Tag(s) that are 226 encoded on the FSOL packet. 228 +---+---+---+---+---+---+---+---+---+---+ 229 | T | ESI Value | 230 +---+---+---+---+---+---+---+---+---+---+ 232 The ESI 9 octets value will be as follow: 234 +---+---+---+---+---+---+---+---+---+---+ 235 | T |Ethernet Port #|Vlan-1 |Vlan-2 |0's| 236 +---+---+---+---+---+---+---+---+---+---+ 238 Ethernet Port number encoded on the 1st 4 bytes, this Ethernet port 239 number will be used on the controller to infer the actual physical 240 port on the access node/router. 242 The Vlan-1 and Vlan-2 values are used to encode the Ethernet Tag 243 identifiers found on the FSOL packet received on the Ethernet port. 245 6 Acknowledgements 247 The authors would like to thank Samer Salam for his valuable 248 comments. 250 7 Security Considerations 252 This document does not introduce any additional security constraints. 254 8 IANA Considerations 255 New ESI type need to be allocated to specify the encoding in section 256 5. 258 9 References 260 9.1 Normative References 262 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 9.2 Informative References 267 [RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet 268 VPN". 270 [EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet 271 VPN", draft-ietf-l2vpn-evpn-11.txt. 273 [EVPN-VPWS] S. Boutros et. al., "EVPN-VPWS", draft-ietf-bess-evpn- 274 vpws-00.txt. 276 Authors' Addresses 278 Sami Boutros 279 VMware 280 Email: sboutros@vmware.com 282 Rex Fernando 283 Cisco 284 Email: rex@cisco.com 286 Ali Sajassi 287 Cisco 288 Email: sajassi@cisco.com 290 Kitty Pang 291 Alibaba 292 Email: kittypang@alibaba-inc.com 294 Tapraj Singh 295 Juniper 296 Email: tsingh@juniper.net