idnits 2.17.1 draft-boutros-bess-evpn-vpws-service-edge-gateway-04.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 (June 29, 2017) is 2490 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 141, but not defined == Missing Reference: 'EVPN-REQ' is mentioned on line 145, but not defined == Unused Reference: 'KEYWORDS' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC7209' is defined on line 347, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-vpws-00 Summary: 0 errors (**), 0 flaws (~~), 6 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 5 Patrice Brissette 6 Ali Sajassi 7 Cisco Systems 9 Daniel Voyer 10 Bell Canada 12 John Drake 13 Juniper Networks 15 Expires: December 31, 2017 June 29, 2017 17 EVPN-VPWS Service Edge Gateway 18 draft-boutros-bess-evpn-vpws-service-edge-gateway-04 20 Abstract 22 This document describes how a service node can dynamically terminate 23 EVPN virtual private wire transport service (VPWS) from access nodes 24 and offer Layer 2, Layer 3 and Ethernet VPN overlay services to 25 Customer edge devices connected to the access nodes. Service nodes 26 using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN 27 overlay services it can offer for the terminated EVPN VPWS transport 28 service. On an access node an operator can specify the L2 or L3 or 29 Ethernet VPN overlay service needed by the customer edge device 30 connected to the access node that will be transported over the EVPN- 31 VPWS service between access node and service node. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 Copyright and License Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1 Auto-Discovery . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.3 Head-end . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.5 Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2.5 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 5 80 4.1 Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . 7 81 4.2 Applicability to IP-VPN . . . . . . . . . . . . . . . . . . 8 82 5 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 8 83 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 84 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 85 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 86 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 88 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 91 1 Introduction 93 This document describes how a service node can act as a gateway 94 terminating dynamically EVPN virtual private wire service (VPWS) from 95 access nodes and offering Layer 2, EVPN and Layer 3 VPN overlay 96 services to Customer edge devices connected to the access nodes. 98 The service node would initially advertise using EVPN the different 99 L2, L3 and Ethernet VPN overlay services that can be transported from 100 access nodes over an EVPN-VPWS transport service. 102 The service node would advertise EVPN-VPWS per EVI Ethernet A-D 103 routes with the Ethernet Segment Identifier field set to 0 and the 104 Ethernet tag ID set to (0xFFFFFFFF wildcard), all those routes will 105 be associated with the EVPN-VPWS service edge RT that will be 106 imported by other service edge PEs, each route will have a unique RD 107 and will be associated with another RT corresponding to the L2, L3 or 108 Ethernet VPN overlay service that can be transported over the EVPN- 109 VPWS transport service. 111 The access nodes will advertise EVPN-VPWS per EVI Ethernet A-D with 112 the Ethernet Segment Identifier field set to 0 for single home 113 customer edge CE device and set to the CE's ESI and the Ethernet Tag 114 field is set to the VPWS service instance identifier. The route will 115 have a unique RD and will be associated with an RT corresponding to 116 the L2, L3 or Ethernet VPN overlay service that will be transported 117 over the EVPN-VPWS transport service. 119 If more than one service node advertise the ability to terminate the 120 EVPN-VPWS transport service and offer the L2, L3 or Ethernet VPN 121 service required by CE device connected to a given access node, then 122 all service node(s) will perform a DF election based on HWR algorithm 123 using {Ethernet tag-id, Service node IP addresses} to determine which 124 service node will be the primary service node to to terminate the 125 VPWS service and offer the L2, L3 or Ethernet overlay service for the 126 customer edge, All active and single active redundancy can be 127 offered. 129 The Service PE node that is a DF for a given VPWS service ID MUST 130 respond to the Eth A-D route per EVI from the access node by sending 131 its own Eth A-D per EVI route and by setting the same VPWS service 132 instance ID and downstream assigned MPLS label to be used by Access 133 node. When access node receives this Eth A-D route per EVI from the 134 service node, it binds the two side of EVCs together. 136 1.1 Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2. Requirements 144 This section describes the requirements specific to this draft. These 145 requirements are in addition to the ones described in [EVPN-REQ], 146 [EVPN], and [EVPN-VPWS]. 148 2.1 Auto-Discovery 150 A service node needs to support the following functionality of auto- 151 discovery: 153 (R1a) A service node PE MUST be agnostic of all access nodes PEs 154 connected on the same access network. 156 (R1b) A service node PE MUST advertise its associated overlay VRF(L2 157 and/or L3) to all service nodes PEs connected on the same network. 159 (R1c) A service node PE MUST resolve received overlay VRF(L2 and/or 160 L3) from other service nodes with local configuration. The 161 information is used to select proper service node PE for a given 162 EVPN-VPWS connection from an access PE. 164 (R1d) A service node PE MUST accept EVPN-VPWS connection from any 165 access node PE which require one of the service node PE available L2 166 or L3 overlay service. 168 2.2 Scalability 170 (R2a) A single service node PE can be associated with many access 171 node PEs. The following requirements give a quantitative measure. 173 (R2b) A service node PE MUST support thousand(s) head-end connections 174 for a a given access node PE connecting to different overlay VRF 175 services on that service node. 177 (R2c) A service node PE MUST support thousand(s) head-end connections 178 to many access node PEs. 180 2.3 Head-end 182 (R3a) A service node PE MUST support L2 and/or L3 head-end 183 functionality. 185 (R3b) A service node PE SHALL support auto-configuration of L2 and/or 186 L3 head-end functionality. 188 2.5 Multi-homing 190 TBD 192 2.5 Fast Convergence 194 TBD 196 3. Benefits 198 This section describes some of the major benefits of EVPN-VPWS 199 service edge gateway solution. This list is not considered as 200 exhaustive. 202 Majors benefits are: 204 - An easy and scalable mechanism for tunneling (head-end) 205 customer traffic into a common IP/MPLS network infra structure 207 - Auto-provision features such as QOS access lists (ACL), tunnel 208 preference, bandwidth, L3VPN on a per head-end interface basis 210 - reduces CAPEX in the access or aggregation network and 211 service PE 213 - Auto configuration of head-end functionality: 215 Configuring other Layer3 parameters, such as VRF and IP 216 addresses, are optional for the head-end to be 217 functional. However, they are required for Layer3 services 218 to be operational (head-end L3 termination). 220 - Auto-discovery of access nodes by service nodes. Hence, there 221 is no need to change any service node configuration when a new 222 access node is being added to the access network. 224 4. Solution Overview 225 +---------+ +---------+ 226 | | | | 227 +----+ +-----+ | IP/MPLS | +-----+ | IP/MPLS | 228 | CE |---| PE1 |-| Access |-| PE2 |-| Core | 229 +----+ +-----+ | Network | +-----+ | Network | 230 | | | | 231 +---------+ +---------+ 232 <---- EVPN-VPWS ----><---- IP/MAC VRF ---> 234 Figure 1: EVPN-VPWS Service Edge Gateway. 235 AN: Access node 236 SE: Service Edge node. 238 EVPN-VPWS Service Edge Gateway Operation 240 At the service edge node, the EVPN Per-EVI Ethernet A-D routes will 241 be advertised with the ESI set to 0 and the Ethernet tag-id set to 242 (wildcard 0xFFFFFFF). The Ethernet A-D routes will have a unique RD 243 and will be associated with 2 BGP RT(s), one RT corresponding to the 244 underlay EVI i.e. the EVPN VPWS transport service that's configured 245 only among the service edge nodes, and one corresponding to the L2, 246 L3 or EVPN overlay service. 248 At the access nodes, the EVPN per-EVI Ethernet A-D routes will be 249 advertised as described in [draft-ietf-bess-evpn-vpws] with the ESI 250 field is set to 0 and for single homed CEs and to the CE's ESI for 251 multi-homed CE's and the Ethernet Tag field will be set to the VPWS 252 service instance identifier that identifies the EVPL or EPL service. 253 The Ethernet-AD route will have a unique RD and will be associated 254 with one BGP RT corresponding to the L2, L3 or EVPN overlay service 255 that will be transported over this EVPN VPWS transport service. 257 Service edge nodes on the underlay EVI will determine the primary 258 service node terminating the VPWS transport service and offering the 259 L2, L3 or Ethernet VPN service by running the on HWR algorithm as 260 described in [draft-mohanty-l2vpn-evpn-df-election] using weight 261 [VPWS service identifier, Service Edge Node IP address]. This ensure 262 that service node(s) will consistently pick the primary service node 263 even after service node failure. Upon primary service node failure, 264 all other remaining services nodes will choose another service node 265 correctly and consistently. 267 Single-sided signaling mechanism is used. The Service PE node that is 268 a DF for accepts to terminate the VPWS transport service from an 269 access node, the primary service edge node shall:- Dynamically create 270 an interface to terminate the service and shall attach this interface 271 to the overlay VPN service required by the access node to service its 272 customer edge device.- Responds to the Eth A-D route per EVI from the 273 access node by sending its own Eth A-D per EVI route by setting the 274 same VPWS service instance ID and downstream assigned MPLS label to 275 be used by the access node. 277 When access node receives this Eth A-D route per EVI from the service 278 edge node, it binds the two side of EVCs together and it now knows 279 what primary/backup service nodes to forward the traffic to. 281 The service edge node shall support per features such as QoS, ACL, 282 etc. for the EVPN VPWS transport service it terminates. 284 4.1 Multi-homing 286 +---------+ +---------+ 287 +----+ +-----+ | | +-----+ | | 288 | CE |---| AN1 |-| |-| SE2 |-| | 289 +----+ +-----+ | IP/MPLS | +-----+ | IP/MPLS | 290 | Access | | Core | 291 | Network | +-----+ | Network | 292 | |-| SE3 |-| | 293 | | +-----+ | | 294 +---------+ +---------+ 295 <---- EVPN-VPWS ----><---- IP/MAC VRF ---> 297 Figure 2: EVPN-VPWS SEG Multi-homing (same ASN) 298 AN: Access node 299 SE: Service Edge node. 301 +---------+ +---------+ 302 +----+ +-----+ | | +-----+ | ASN-A | 303 | CE |---| AN1 |-| |-| SE2 |-| Core | 304 +----+ +-----+ | IP/MPLS | +-----+ | Network | 305 | Access | +---------+ 306 | Network | +---------+ 307 | | +-----+ | ASN-B | 308 | |-| SE3 |-| Core | 309 | | +-----+ | Network | 310 +---------+ +---------+ 311 <---- EVPN-VPWS ----><---- IP/MAC VRF ---> 313 Figure 3: EVPN-VPWS SEG Multi-homing (different ASN) 314 AN: Access node 315 SE: Service Edge node. 317 Both All-active and single active redundancy can be supported. 319 A backup service node can be preprogrammed in data plane on an access 320 node in order to switch traffic and based on how fast the data plane 321 detect the failure of the primary service node traffic on an access 322 node can switch to the backup node. 324 4.2 Applicability to IP-VPN TBD 326 5 Failure Scenarios TBD 328 6 Acknowledgements TBD. 330 7 Security Considerations 332 This document does not introduce any additional security constraints. 334 8 IANA Considerations 336 TBD. 338 9 References 340 9.1 Normative References 342 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 9.2 Informative References 347 [RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet 348 VPN". 350 [EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet 351 VPN", draft-ietf-l2vpn-evpn-11.txt. 353 [EVPN-VPWS] S. Boutros et. al., "EVPN-VPWS", draft-ietf-bess-evpn- 354 vpws-00.txt. 356 Authors' Addresses 358 Sami Boutros 359 VMware, Inc. 360 Email: sboutros@vmware.com 361 Patrice Brissette 362 Cisco 363 Email: pbrisset@cisco.com 365 Ali Sajassi 366 Cisco 367 Email: sajassi@cisco.com 369 Daniel Voyer 370 Bell Canada 371 Email: daniel.voyer@bell.ca 373 John Drake 374 Juniper Networks 375 Email: jdrake@juniper.net