--- 1/draft-ietf-bess-evpn-virtual-eth-segment-00.txt 2019-01-06 20:13:09.101209014 -0800 +++ 2/draft-ietf-bess-evpn-virtual-eth-segment-01.txt 2019-01-06 20:13:09.145210067 -0800 @@ -2,24 +2,42 @@ Internet Working Group A. Sajassi Internet Draft P. Brissette Category: Standards Track Cisco R. Schell Verizon J. Drake Juniper J. Rabadan Nokia -Expires: December 18, 2016 June 18, 2018 +Expires: July 06, 2019 January 06, 2019 EVPN Virtual Ethernet Segment - draft-ietf-bess-evpn-virtual-eth-segment-00 + draft-ietf-bess-evpn-virtual-eth-segment-01 + +Abstract + + EVPN and PBB-EVPN introduce a family of solutions for multipoint + Ethernet services over MPLS/IP network with many advanced + capabilities among which their multi-homing capabilities. These + solutions define two types of multi-homing for an Ethernet Segment + (ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment + is defined as a set of links between the multi-homed device/network + and the set of PE devices that they are connected to. + + Some Service Providers want to extend the concept of the physical + links in an ES to Ethernet Virtual Circuits (EVCs) where many of such + EVCs can be aggregated on a single physical External Network-to- + Network Interface (ENNI). An ES that consists of a set of EVCs + instead of physical links is referred to as a virtual ES (vES). This + draft describes the requirements and the extensions needed to support + vES in EVPN and PBB-EVPN. 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. @@ -43,38 +60,20 @@ 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. -Abstract - - EVPN and PBB-EVPN introduce a family of solutions for multipoint - Ethernet services over MPLS/IP network with many advanced - capabilities among which their multi-homing capabilities. These - solutions define two types of multi-homing for an Ethernet Segment - (ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment - is defined as a set of links between the multi-homed device/network - and the set of PE devices that they are connected to. - - Some Service Providers want to extend the concept of the physical - links in an ES to Ethernet Virtual Circuits (EVCs) where many of such - EVCs can be aggregated on a single physical External Network-to- - Network Interface (ENNI). An ES that consists of a set of EVCs - instead of physical links is referred to as a virtual ES (vES). This - draft describes the requirements and the extensions needed to support - vES in EVPN and PBB-EVPN. - Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Virtual Ethernet Segments in Access Ethernet Networks . . . 4 @@ -86,58 +85,58 @@ 3.3. Local Switching . . . . . . . . . . . . . . . . . . . . . . 9 3.4. EVC Service Types . . . . . . . . . . . . . . . . . . . . . 9 3.5. Designated Forwarder (DF) Election . . . . . . . . . . . . 10 3.6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Failure & Recovery . . . . . . . . . . . . . . . . . . . . 10 3.8. Fast Convergence . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. EVPN DF Election for vES . . . . . . . . . . . . . . . . . 13 5. Failure Handling & Recovery . . . . . . . . . . . . . . . . . . 14 5.1. Failure Handling for Single-Active vES in EVPN . . . . . . 15 - 5.2. EVC Failure Handling for Single-Active vES in PBB-EVPN . . 15 - 5.3. Port Failure Handling for Single-Active vES's in EVPN . . . 16 + 5.2. EVC Failure Handling for Single-Active vES in PBB-EVPN . . 16 + 5.3. Port Failure Handling for Single-Active vES's in EVPN . . . 17 5.4. Port Failure Handling for Single-Active vES's in PBB-EVPN . 17 5.5. Fast Convergence in PBB-EVPN . . . . . . . . . . . . . . . 18 6. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 6.1. I-SID Extended Community . . . . . . . . . . . . . . . . . 20 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 + 6.1. I-SID Extended Community . . . . . . . . . . . . . . . . . 21 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 10. Intellectual Property Considerations . . . . . . . . . . . . . 21 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21 - 12. Informative References . . . . . . . . . . . . . . . . . . . . 21 - 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 + 12. Informative References . . . . . . . . . . . . . . . . . . . . 22 + 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction [RFC7432] and [RFC7623] introduce a family of solutions for multipoint Ethernet services over MPLS/IP network with many advanced capabilities among which their multi-homing capabilities. These solutions define two types of multi-homing for an Ethernet Segment (ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment is defined as a set of links between the multi-homed device/network and the set of PE devices that they are connected to. This document extends the Ethernet Segment concept so that an ES can - be associated to a set of EVCs or other objects such as MPLS Label - Switch Paths (LSP) or Pseudowires (PW). + be associated to a set of EVCs (e.g., VLANs) or other objects such as + MPLS Label Switch Paths (LSPs) or Pseudowires (PWs). 1.1 Virtual Ethernet Segments in Access Ethernet Networks Some Service Providers (SPs) want to extend the concept of the physical links in an ES to Ethernet Virtual Circuits (EVCs) where - many of such EVCs can be aggregated on a single physical External - Network-to-Network Interface (ENNI). An ES that consists of a set of - EVCs instead of physical links is referred to as a virtual ES (vES). - Figure below depicts two PE devices (PE1 and PE2) each with an ENNI - where a number of vES's are aggregated on - each of which through its - associated EVC. + many of such EVCs (e.g., VLANs) can be aggregated on a single + physical External Network-to-Network Interface (ENNI). An ES that + consists of a set of EVCs instead of physical links is referred to as + a virtual ES (vES). Figure below depicts two PE devices (PE1 and PE2) + each with an ENNI where a number of vES's are aggregated on - each of + which through its associated EVC. Carrier Ethernet +-----+ Network | CE11|EVC1 +---------+ +-----+ \ | | +---+ Cust. A \-0=========0--ENNI1| | +-----+ | | ENNI1| | +-------+ +---+ | CE12|EVC2--0=========0--ENNI1|PE1|---| | | | +-----+ | | ENNI1| | | |---|PE3|- @@ -172,21 +171,21 @@ two or more ENNIs) via their associated EVCs. Just like physical ES's in [RFC7432] and [RFC7623] solutions, these vES's can be single-homed or multi-homed ES's and when multi-homed, then can operate in either Single-Active or All-Active redundancy modes. In a typical SP off- network scenario, an ENNI can be associated with several thousands of single-homed vES's, several hundreds of Single-Active vES's and it may also be associated with tens or hundreds of All-Active vES's. 1.2 Virtual Ethernet Segments in Access MPLS Networks Other Service Providers (SPs) want to extend the concept of the - physical links in an ES to individual Pseudowires (PW) or to MPLS + physical links in an ES to individual Pseudowires (PWs) or to MPLS Label Switched Paths (LSPs) per [EVPN-VPWS] in Access MPLS networks. Figure 2 illustrates this concept. MPLS Aggregation Network +-----+ +----------------+ <----EVPN Network-----> | CE11|EVC1 | | +-----+ \+AG1--+ PW1 +-----+ Cust. A -0----|===========| | +-----+ | ---+===========| | +-------+ +---+ @@ -207,68 +206,73 @@ EVCs <--802.1Q---><------MPLS-------> <-802.1Q-> Figure 2: DHN and SH on Access MPLS networks In some cases, Service Providers use Access MPLS Networks that belong to separate administrative entities or third parties as a way to get access to the their own IP/MPLS network infrastructure. This is the case illustrated in Figure 2. - An ES is defined as a set of individual PWs if they cannot be - aggregated into a common LSP. If the aggregation of PWs is possible, - the ES can be associated to an LSP in a given PE. In the example of - Figure 2, EVC3 is connected to a VPWS instance in AG2 that is - connected to PE1 and PE2 via PW3 and PW5 respectively. EVC4 is - connected to a separate VPWS instance on AG2 that gets connected to - an EVI on PE1 and PE2 via PW4 and PW6, respectively. Since the PWs - for the two VPWS instances can be aggregated into the same LSPs going - to the EVPN network, a common virtual ES can be defined for LSP1 and - LSP2. This ES will be shared by two separate EVIs in the EVPN - network. + In such scenarios, a virtual ES (vES) is defined as a set of + individual PWs if they cannot be aggregated into a common LSP. If the + aggregation of PWs is possible, the vES can be associated to an LSP + in a given PE. In the example of Figure 2, EVC3 is connected to a + VPWS instance in AG2 that is connected to PE1 and PE2 via PW3 and PW5 + respectively. EVC4 is connected to a separate VPWS instance on AG2 + that gets connected to an EVI on PE1 and PE2 via PW4 and PW6, + respectively. Since the PWs for the two VPWS instances can be + aggregated into the same LSPs going to the EVPN network, a common + virtual ES can be defined for LSP1 and LSP2. This vES will be shared + by two separate EVIs in the EVPN network. In some cases, this aggregation of PWs into common LSPs may not be possible. For instance, if PW3 were terminated into a third PE, e.g. - PE3, instead of PE1, the ES would need to be defined on a per + PE3, instead of PE1, the vES would need to be defined on a per individual PW on each PE, i.e. PW3 and PW5 would belong to ES-1, whereas PW4 and PW6 would be associated to ES-2. - An ES that consists of a set of LSPs or individual PWs is also - referred as virtual ES (vES) in this document." + For MPLS/IP access networks where a vES represents a set of PWs or + LSPs, this document extended Single-Active multi-homing procedures of + [RFC7432] and [7623] to vES. The vES extension to All-Active multi- + homing is outside of the scope of this document for MPLS/IP access + networks. This draft describes requirements and the extensions needed to support vES in [RFC7432] and [RFC7623]. Section 3 lists the set of - requirements for Virtual ES's. Section 4 describes the solution for - [RFC7623] to meet these requirements. Section 5 describes the failure - handling and recovery for Virtual ES's in [RFC7623]. Section 6 covers - scalability and fast convergence required for Virtual ES's in - [RFC7623]. + requirements for virtual ES's. Section 4 describes the solution for + [RFC7432] and [RFC7623] to meet these requirements. Section 5 + describes the failure handling and recovery for Virtual ES's in + [RFC7432] and [RFC7623]. Section 6 covers scalability and fast + convergence required for Virtual ES's in [RFC7432] and [RFC7623]. 2. Terminology AC: Attachment Circuit BEB: Backbone Edge Bridge B-MAC: Backbone MAC Address CE: Customer Edge CFM: Connectivity Fault Management C-MAC: Customer/Client MAC Address DHD: Dual-homed Device DHN: Dual-homed Network ENNI: External Network-Network Interface ES: Ethernet Segment ESI: Ethernet-Segment Identifier EVC: Ethernet Virtual Circuit EVPN: Ethernet VPN + I-SID: Service Instance Identifier (24 bits and global within a PBB + network see [RFC7080]) LACP: Link Aggregation Control Protocol + PBB: Provider Backbone Bridge PE: Provider Edge SH: Single-Homed - Single-Active Redundancy Mode (SA): When only a single PE, among a group of PEs attached to an Ethernet-Segment, is allowed to forward traffic to/from that Ethernet Segment, then the Ethernet segment is defined to be operating in Single-Active redundancy mode. All-Active Redundancy Mode (AA): When all PEs attached to an Ethernet segment are allowed to forward traffic to/from that Ethernet-Segment, then the Ethernet segment is defined to be operating in All-Active redundancy mode. @@ -300,29 +304,30 @@ (R1e) A Multi-Homed vES (Single-Active or All-Active) can be spread across any two or more PEs (on two or more ENNIs) 3.2. Scalability A single physical port (e.g., ENNI) can be associated with many vES's. The following requirements give a quantitative measure for each vES type. - (R2a) A PE MUST handle thousands or tens of thousands of Single-homed - vES's on a single physical port (e.g., single ENNI) + (R2a) A PE SHOULD handle very large number of Single-Homed vES's on a + single physical port (e.g., thousands of vES's on a single ENNI) - (R2b) A PE MUST handle hundreds of Single-Active vES's on a single - physical port (e.g., single ENNI) - (R2c) A PE MAY handle tens or hundreds of All-Active Multi-Homed - vES's on a single physical port (e.g., single ENNI) + (R2b) A PE SHOULD handle large number of Single-Active vES's on a + single physical port (e.g., hundreds of vES's on a single ENNI) - (R2d) A PE MUST handle the above scale for a mix of Single-homed + (R2c) A PE MAY handle large number of All-Active Multi-Homed vES's on + a single physical port (e.g., hundreds of vES's on a single ENNI) + + (R2d) A PE SHOULD handle the above scale for a mix of Single-homed vES's and Single-Active vES's simultaneously on a single physical port (e.g., single ENNI) (R4e) A PE MAY handle the above sale for a mixed of All-Active Multi- Homed vES's along with other types of vES's on a single physical port 3.3. Local Switching Many vES's of different types can be aggregated on a single physical port on a PE device and some of these vES can belong to the same @@ -438,23 +442,23 @@ (R8a) There SHOULD be a mechanism equivalent to EVPN mass-withdraw such that upon an ENNI failure, only a single BGP message is needed to indicate to the remote PEs to trigger DF election for all impacted vES associated with that ENNI. 4. Solution Overview The solutions described in [RFC7432] and [RFC7623] are leveraged as is with one simple modification and that is the ESI assignment is - performed for a group of EVCs instead of a group of links. In other - words, the ESI is associated with a virtual ES (vES) and that's why - it will be referred to as vESI. + performed for a group of EVCs or LSPs/PWs instead of a group of + links. In other words, the ESI is associated with a virtual ES (vES) + and that's why it will be referred to as vESI. For EVPN solution, everything basically remains the same except for the handling of physical port failure where many vES's can be impacted. Section 5.1 and 5.3 below describe the handling of physical port/link failure for EVPN. In a typical multi-homed operation, MAC addresses are learned behind a vES are advertised with the ESI corresponding to the vES (i.e., vESI). EVPN aliasing and mass- withdraw operations are performed with respect to vES. In other words, the Ethernet A-D routes for these operations are advertised with vESI instead of ESI. @@ -500,21 +504,21 @@ Figure 2: PBB-EVPN Network 4.1. EVPN DF Election for vES The procedure for service carving for virtual Ethernet Segments is the same as the one outlined in section 8.5 of [RFC7432] except for the fact that ES is replaced with vES. For the sake of clarity and completeness, this procedure is repeated below: - 1. When a PE discovers the ESI or is configured with the ESI + 1. When a PE discovers the vESI or is configured with the vESI associated with its attached vES, it advertises an Ethernet Segment route with the associated ES-Import extended community attribute. 2. The PE then starts a timer (default value = 3 seconds) to allow the reception of Ethernet Segment routes from other PE nodes connected to the same vES. This timer value MUST be same across all PEs connected to the same vES. 3. When the timer expires, each PE builds an ordered list of the IP addresses of all the PE nodes connected to the vES (including @@ -540,29 +544,31 @@ vES and unblocks multi-destination in egress direction for All-Active Multi-homed vES. All non-DF PEs block all traffic in both ingress and egress directions for Single-Active vES and block multi-destination traffic in the egress direction for All-Active multi-homed vES. In the case of an EVC failure, the affected PE withdraws its Ethernet Segment route. This will re-trigger the service carving procedures on all the PEs in the RG. For PE node failure, or upon PE commissioning or decommissioning, the PEs re-trigger the service carving across all affected vES's. In case of a Single-Active multi-homing, when a - service moves from one PE in the RG to another PE as a result of re- - carving, the PE, which ends up being the elected DF for the service, - SHOULD trigger a MAC address flush notification towards the - associated vES. This can be done, for e.g. using IEEE 802.1ak MVRP - 'new' declaration. + service moves from one PE in the Redundancy Group to another PE as a + result of re-carving, the PE, which ends up being the elected DF for + the service, SHOULD trigger a MAC address flush notification towards + the associated vES. This can be done, for e.g. using IEEE 802.1ak + MVRP 'new' declaration. For LSP and PW based vES, the non-DF PE SHOULD signal PW-status 'standby' signaling to the AG PE, and the new DF MAY send an LDP MAC - withdraw message as a MAC address flush notification. + withdraw message as a MAC address flush notification. It should be + noted that the PW-status is signaled for the scenarios where there is + a one-to-one mapping between EVI and the PW. 5. Failure Handling & Recovery There are a number of failure scenarios to consider such as: A: CE Uplink Port Failure B: Ethernet Access Network Failure C: PE Access-facing Port or link Failure D: PE Node Failure E: PE isolation from IP/MPLS network @@ -891,20 +897,24 @@ February 2015. [RFC7623] Sajassi, et al., "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, September 2015. 12. Informative References [RFC7209] Sajassi, et al., "Requirements for Ethernet VPN (EVPN)", RFC 7209, May 2014. + [RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual + Private LAN Service (VPLS) Interoperability with Provider + Backbone Bridges", RFC 7080, December 2013. + 13. Authors' Addresses Ali Sajassi Cisco Systems Email: sajassi@cisco.com Patrice Brissette Cisco Systems Email: pbrisset@cisco.com