INTERNET-DRAFT Sami Boutros Intended Status: Standard Track VMware Patrice Brissette Ali Sajassi Cisco Systems Daniel Voyer Bell Canada John Drake Juniper Networks Expires: September 17, 2016 March 16, 2016 EVPN-VPWS Service Edge Gateway draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Abstract This document describes how a service node can dynamically terminate EVPN virtual private wire transport service (VPWS) from access nodes and offer Layer 2, Layer 3 and Ethernet VPN overlay services to Customer edge devices connected to the access nodes. Service nodes using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN overlay services it can offer for the terminated EVPN VPWS transport service. On an access node an operator can specify the L2 or L3 or Ethernet VPN overlay service needed by the customer edge device connected to the access node that will be transported over the EVPN- VPWS service between access node and service node. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Boutros Expires September 17, 2016 [Page 1] INTERNET DRAFT EVPN-VPWS Service Edge Gateway March 16, 2016 The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Auto-Discovery . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Head-end . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.5 Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 5 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 Applicability to IP-VPN . . . . . . . . . . . . . . . . . . 8 5 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 8 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Boutros Expires September 17, 2016 [Page 2] INTERNET DRAFT EVPN-VPWS Service Edge Gateway March 16, 2016 1 Introduction This document describes how a service node can act as a gateway terminating dynamically EVPN virtual private wire service (VPWS) from access nodes and offering Layer 2, EVPN and Layer 3 VPN overlay services to Customer edge devices connected to the access nodes. The service node would initially advertise using EVPN the different L2, L3 and Ethernet VPN overlay services that can be transported from access nodes over an EVPN-VPWS transport service. The service node would advertise EVPN-VPWS per EVI Ethernet A-D routes with the Ethernet Segment Identifier field set to 0 and the Ethernet tag ID set to (0xFFFFFFFF wildcard), all those routes will be associated with the EVPN-VPWS service edge RT that will be imported by other service edge PEs, each route will have a unique RD and will be associated with another RT corresponding to the L2, L3 or Ethernet VPN overlay service that can be transported over the EVPN- VPWS transport service. The access nodes will advertise EVPN-VPWS per EVI Ethernet A-D with the Ethernet Segment Identifier field set to 0 for single home customer edge CE device and set to the CE's ESI and the Ethernet Tag field is set to the VPWS service instance identifier. The route will have a unique RD and will be associated with an RT corresponding to the L2, L3 or Ethernet VPN overlay service that will be transported over the EVPN-VPWS transport service. If more than one service node advertise the ability to terminate the EVPN-VPWS transport service and offer the L2, L3 or Ethernet VPN service required by CE device connected to a given access node, then all service node(s) will perform a DF election based on HWR algorithm using {Ethernet tag-id, Service node IP addresses} to determine which service node will be the primary service node to to terminate the VPWS service and offer the L2, L3 or Ethernet overlay service for the customer edge, All active and single active redundancy can be offered. The Service PE node that is a DF for a given VPWS service ID MUST respond to the Eth A-D route per EVI from the access node by sending its own Eth A-D per EVI route and by setting the same VPWS service instance ID and downstream assigned MPLS label to be used by Access node. When access node receives this Eth A-D route per EVI from the service node, it binds the two side of EVCs together. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Boutros Expires September 17, 2016 [Page 3] INTERNET DRAFT EVPN-VPWS Service Edge Gateway March 16, 2016 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Requirements This section describes the requirements specific to this draft. These requirements are in addition to the ones described in [EVPN-REQ], [EVPN], and [EVPN-VPWS]. 2.1 Auto-Discovery A service node needs to support the following functionality of auto- discovery: (R1a) A service node PE MUST be agnostic of all access nodes PEs connected on the same access network. (R1b) A service node PE MUST advertise its associated overlay VRF(L2 and/or L3) to all service nodes PEs connected on the same network. (R1c) A service node PE MUST resolve received overlay VRF(L2 and/or L3) from other service nodes with local configuration. The information is used to select proper service node PE for a given EVPN-VPWS connection from an access PE. (R1d) A service node PE MUST accept EVPN-VPWS connection from any access node PE which require one of the service node PE available L2 or L3 overlay service. 2.2 Scalability (R2a) A single service node PE can be associated with many access node PEs. The following requirements give a quantitative measure. (R2b) A service node PE MUST support thousand(s) head-end connections for a a given access node PE connecting to different overlay VRF services on that service node. (R2c) A service node PE MUST support thousand(s) head-end connections to many access node PEs. 2.3 Head-end (R3a) A service node PE MUST support L2 and/or L3 head-end functionality. (R3b) A service node PE SHALL support auto-configuration of L2 and/or Boutros Expires September 17, 2016 [Page 4] INTERNET DRAFT EVPN-VPWS Service Edge Gateway March 16, 2016 L3 head-end functionality. 2.5 Multi-homing TBD 2.5 Fast Convergence TBD 3. Benefits This section describes some of the major benefits of EVPN-VPWS service edge gateway solution. This list is not considered as exhaustive. Majors benefits are: - An easy and scalable mechanism for tunneling (head-end) customer traffic into a common IP/MPLS network infra structure - Auto-provision features such as QOS access lists (ACL), tunnel preference, bandwidth, L3VPN on a per head-end interface basis - reduces CAPEX in the access or aggregation network and service PE - Auto configuration of head-end functionality: Configuring other Layer3 parameters, such as VRF and IP addresses, are optional for the head-end to be functional. However, they are required for Layer3 services to be operational (head-end L3 termination). - Auto-discovery of access nodes by service nodes. Hence, there is no need to change any service node configuration when a new access node is being added to the access network. 4. Solution Overview Boutros Expires September 17, 2016 [Page 5] INTERNET DRAFT EVPN-VPWS Service Edge Gateway March 16, 2016 +---------+ +---------+ | | | | +----+ +-----+ | IP/MPLS | +-----+ | IP/MPLS | | CE |---| PE1 |-| Access |-| PE2 |-| Core | +----+ +-----+ | Network | +-----+ | Network | | | | | +---------+ +---------+ <---- EVPN-VPWS ----><---- IP/MAC VRF ---> Figure 1: EVPN-VPWS Service Edge Gateway. AN: Access node SE: Service Edge node. EVPN-VPWS Service Edge Gateway Operation At the service edge node, the EVPN Per-EVI Ethernet A-D routes will be advertised with the ESI set to 0 and the Ethernet tag-id set to (wildcard 0xFFFFFFF). The Ethernet A-D routes will have a unique RD and will be associated with 2 BGP RT(s), one RT corresponding to the underlay EVI i.e. the EVPN VPWS transport service that's configured only among the service edge nodes, and one corresponding to the L2, L3 or EVPN overlay service. At the access nodes, the EVPN per-EVI Ethernet A-D routes will be advertised as described in [draft-ietf-bess-evpn-vpws] with the ESI field is set to 0 and for single homed CEs and to the CE's ESI for multi-homed CE's and the Ethernet Tag field will be set to the VPWS service instance identifier that identifies the EVPL or EPL service. The Ethernet-AD route will have a unique RD and will be associated with one BGP RT corresponding to the L2, L3 or EVPN overlay service that will be transported over this EVPN VPWS transport service. Service edge nodes on the underlay EVI will determine the primary service node terminating the VPWS transport service and offering the L2, L3 or Ethernet VPN service by running the on HWR algorithm as described in [draft-mohanty-l2vpn-evpn-df-election] using weight [VPWS service identifier, Service Edge Node IP address]. This ensure that service node(s) will consistently pick the primary service node even after service node failure. Upon primary service node failure, all other remaining services nodes will choose another service node correctly and consistently. Single-sided signaling mechanism is used. The Service PE node that is a DF for accepts to terminate the VPWS transport service from an access node, the primary service edge node shall:- Dynamically create an interface to terminate the service and shall attach this interface to the overlay VPN service required by the access node to service its Boutros Expires September 17, 2016 [Page 6] INTERNET DRAFT EVPN-VPWS Service Edge Gateway March 16, 2016 customer edge device.- Responds to the Eth A-D route per EVI from the access node by sending its own Eth A-D per EVI route by setting the same VPWS service instance ID and downstream assigned MPLS label to be used by the access node. When access node receives this Eth A-D route per EVI from the service edge node, it binds the two side of EVCs together and it now knows what primary/backup service nodes to forward the traffic to. The service edge node shall support per features such as QoS, ACL, etc. for the EVPN VPWS transport service it terminates. 4.1 Multi-homing +---------+ +---------+ +----+ +-----+ | | +-----+ | | | CE |---| AN1 |-| |-| SE2 |-| | +----+ +-----+ | IP/MPLS | +-----+ | IP/MPLS | | Access | | Core | | Network | +-----+ | Network | | |-| SE3 |-| | | | +-----+ | | +---------+ +---------+ <---- EVPN-VPWS ----><---- IP/MAC VRF ---> Figure 2: EVPN-VPWS SEG Multi-homing (same ASN) AN: Access node SE: Service Edge node. +---------+ +---------+ +----+ +-----+ | | +-----+ | ASN-A | | CE |---| AN1 |-| |-| SE2 |-| Core | +----+ +-----+ | IP/MPLS | +-----+ | Network | | Access | +---------+ | Network | +---------+ | | +-----+ | ASN-B | | |-| SE3 |-| Core | | | +-----+ | Network | +---------+ +---------+ <---- EVPN-VPWS ----><---- IP/MAC VRF ---> Figure 3: EVPN-VPWS SEG Multi-homing (different ASN) AN: Access node SE: Service Edge node. Boutros Expires September 17, 2016 [Page 7] INTERNET DRAFT EVPN-VPWS Service Edge Gateway March 16, 2016 Both All-active and single active redundancy can be supported. A backup service node can be preprogrammed in data plane on an access node in order to switch traffic and based on how fast the data plane detect the failure of the primary service node traffic on an access node can switch to the backup node. 4.2 Applicability to IP-VPN TBD 5 Failure Scenarios TBD 6 Acknowledgements TBD. 7 Security Considerations This document does not introduce any additional security constraints. 8 IANA Considerations TBD. 9 References 9.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2 Informative References [RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet VPN". [EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-evpn-11.txt. [EVPN-VPWS] S. Boutros et. al., "EVPN-VPWS", draft-ietf-bess-evpn- vpws-00.txt. Authors' Addresses Sami Boutros VMware, Inc. Email: sboutros@vmware.com Boutros Expires September 17, 2016 [Page 8] INTERNET DRAFT EVPN-VPWS Service Edge Gateway March 16, 2016 Patrice Brissette Cisco Email: pbrisset@cisco.com Ali Sajassi Cisco Email: sajassi@cisco.com Daniel Voyer Bell Canada Email: daniel.voyer@bell.ca John Drake Juniper Networks Email: jdrake@juniper.net Boutros Expires September 17, 2016 [Page 9]