idnits 2.17.00 (12 Aug 2021) /tmp/idnits51093/draft-boutros-l2vpn-evpn-vpws-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 251 has weird spacing: '...d using a mec...' -- The document date (October 21, 2013) is 3133 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: 'MEF' is mentioned on line 93, but not defined == Missing Reference: 'RFC2119' is mentioned on line 122, but not defined == Missing Reference: 'RFC4448' is mentioned on line 213, but not defined == Unused Reference: 'KEYWORDS' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'EVPN-REQ' is defined on line 283, but no explicit reference was found in the text == Outdated reference: draft-ietf-l2vpn-evpn-req has been published as RFC 7209 == Outdated reference: draft-ietf-l2vpn-evpn has been published as RFC 7432 == Outdated reference: draft-ietf-l2vpn-pbb-evpn has been published as RFC 7623 Summary: 0 errors (**), 0 flaws (~~), 10 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 Ali Sajassi 4 Samer Salam 5 Cisco Systems 7 John Drake 8 Juniper Networks 10 Jeff Tantsura 11 Ericsson 12 Expires: April 24, 2014 October 21, 2013 14 VPWS support in E-VPN 15 draft-boutros-l2vpn-evpn-vpws-02.txt 17 Abstract 19 This document describes how E-VPN can be used to support virtual 20 private wire service (VPWS) in MPLS/IP networks. E-VPN enables the 21 following characteristics for VPWS: single-active as well as all- 22 active multi-homing with flow-based load-balancing, eliminates the 23 need for single-segment and multi-segment PW signaling, and provides 24 fast protection using data-plane prefix independent convergence upon 25 node or link failure. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4 EVPN Comparison to PW Signaling . . . . . . . . . . . . . . . . 5 70 5 ESI Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6 ESI value derivation . . . . . . . . . . . . . . . . . . . . . . 6 72 7 VPWS with multiple sites . . . . . . . . . . . . . . . . . . . . 6 73 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 74 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 75 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 10.1 Normative References . . . . . . . . . . . . . . . . . . . 7 77 10.2 Informative References . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1 Introduction 82 This document describes how EVPN can be used to support virtual 83 private wire service (VPWS) in MPLS/IP networks. The use of EVPN 84 mechanisms for VPWS brings the benefits of EVPN to p2p services. 85 These benefits include single-active redundancy as well as all-active 86 redundancy with flow-based load-balancing. Furthermore, the use of 87 EVPN for VPWS eliminates the need for signaling single-segment and 88 multi-segment PWs for p2p Ethernet services. 90 [EVPN] has the ability to forward customer traffic to/from a given 91 customer Attachment Circuit (AC), aka Ethernet Segment in EVPN 92 terminology, without any MAC lookup. This capability is ideal in 93 providing p2p services (aka VPWS services). [MEF] defines Ethernet 94 Virtual Private Line (EVPL) service as p2p service between a pair of 95 ACs (designated by VLANs). EVPL can be considered as a VPWS with only 96 two ACs. In delivering an EVPL service, the traffic forwarding 97 capability of EVPN based on the exchange of a pair of Ethernet AD 98 routes is used; whereas, for more general VPWS, traffic forwarding 99 capability of EVPN based on the exchange of a group of Ethernet AD 100 routes (one Ethernet AD route per AC/segment) is used. In a VPWS 101 service, the traffic from an originating Ethernet Segment can be 102 forwarded only to a single destination Ethernet Segment; hence, no 103 MAC lookup is needed and the MPLS label associated with the per-EVI 104 Ethernet AD route can be used in forwarding user traffic to the 105 destination AC. 107 In current PW redundancy mechanisms, convergence time is a function 108 of control plane convergence characteristics. However, with EVPN it 109 is possible to attain faster convergence through the use of data- 110 plane prefix independent convergence, upon node or link failure. 112 This document proposes the use of the Ethernet AD route to signal 113 labels for P2P Ethernet services. As with EVPN, the Ethernet Segment 114 route can be used to synchronize state between the PEs attached to 115 the same multi-homed Ethernet Segment. 117 1.1 Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 MAC: Media Access Control 125 MPLS: Multi Protocol Label Switching. 127 OAM: Operations, Administration and Maintenance. 129 PE: Provide Edge Node. 131 CE: Customer Edge device e.g., host or router or switch. 133 EVI: EVPN Instance. 135 Single-Active Mode: When a device or a network is multi-homed to two 136 or more PEs and when only a single PE in such redundancy group can 137 forward traffic to/from the multi-homed device or network for a given 138 VLAN, then such multi-homing or redundancy is referred to as "Single- 139 Active". 141 All-Active: When a device is multi-homed to two or more PEs and when 142 all PEs in such redundancy group can forward traffic to/from the 143 multi-homed device for a given VLAN, then such multi-homing or 144 redundancy is referred to as "All-Active". 146 2. BGP Extensions 148 [EVPN] defines a new BGP NLRI for advertising different route types 149 for EVPN operation. This document does not define any new BGP 150 messages, but rather re-purposes one of the routes as described next. 152 This document proposes the use of the per EVI Ethernet AD route to 153 signal P2P services. The Ethernet Segment Identifier field is set to 154 the ESI of the attachment circuit of the VPWS service instance. The 155 Ethernet Tag field is set to 0 in the case of an Ethernet Private 156 Wire service, and to the VLAN identifier associated with the service 157 for Ethernet Virtual Private Wire service. The route is associated 158 with a Route-Target (RT) extended community attribute that identifies 159 the service instance (together with the Ethernet Tag field when non- 160 zero). 162 3 Operation 164 The following figure shows an example of a P2P service deployed with 165 EVPN. 166 Ethernet Ethernet 167 Native |<--------- EVPN Instance ----------->| Native 168 Service | | Service 169 (AC) | |<-PSN1->| |<-PSN2->| | (AC) 170 | V V V V V V | 171 | +-----+ +-----+ +-----+ +-----+ | 172 +----+ | | PE1 |======|ASBR1|==|ASBR2|===| PE3 | | +----+ 173 | |-------+-----+ +-----+ +-----+ +-----+-------| | 174 | CE1| | | |CE2 | 175 | |-------+-----+ +-----+ +-----+ +-----+-------| | 176 +----+ | | PE2 |======|ASBR3|==|ASBR4|===| PE4 | | +----+ 177 ^ +-----+ +-----+ +-----+ +-----+ ^ 178 | Provider Edge 1 ^ Provider Edge 2 | 179 | | | 180 | | | 181 | EVPN Inter-provider point | 182 | | 183 |<---------------- Emulated Service -------------------->| 185 iBGP sessions are established between PE1, PE2, ASBR1 and ASBR3, 186 possibly via a BGP route-reflector. Similarly, iBGP sessions are 187 established between PE3, PE4, ASBR2 and ASBR4. eBGP sessions are 188 established among ASBR1, ASBR2, ASBR3, and ASBR4. 190 All PEs and ASBRs are enabled for the EVPN SAFI, and exchange EVPN 191 Ethernet A-D routes - one route per AC. The ASBRs re-advertise the 192 Ethernet A-D routes with Next Hop attribute set to their IP 193 addresses. The link between the CE and the PE is either a C-tagged or 194 S-tagged interface, as described in [802.1Q], that can carry a single 195 VLAN tag or two nested VLAN tags. This interface is set up as a trunk 196 with multiple VLANs. 198 A VPWS with multiple sites or multiple EVPL services on the same CE 199 port can be included in one EVI between 2 or more PEs. An Ethernet 200 Tag corresponding to each P2P connection and known to both PEs is 201 used to identify the services multiplexed in the same EVI. 203 For CE multi-homing, the Ethernet AD Route encodes the ESI associated 204 with the CE. This allows flow-based load-balancing of traffic between 205 PEs connected to the same multi-homed CE. The VPN ID MUST be the same 206 on both PEs attached to the site. The Ethernet Segment route may be 207 used too, for discovery of multi-homed CEs. In all cases traffic 208 follows the transport paths, which may be asymmetric. 210 4 EVPN Comparison to PW Signaling 212 In EVPN, service endpoint discovery and label signaling are done 213 concurrently using BGP. Whereas, with VPWS based on [RFC4448], label 214 signaling is done via LDP and service endpoint discovery is either 215 through manual provisioning or through BGP. In existing 216 implementation of VPWS using pseudowires(PWs), redundancy is limited 217 to single-active mode, while with EVPN implementation of VPWS both 218 single-active and all-active redundancy modes can be supported. In 219 existing implementation with PWs, backup PWs are not used to carry 220 traffic, while with EVPN, traffic can be load-balanced among primary 221 and secondary PEs. Upon link or node failure, EVPN can trigger 222 failover with the withdrawal of a single BGP route per service, 223 whereas with VPWS PW redundancy, the failover sequence requires 224 exchange of two control plane messages: one message to deactivate the 225 group of primary PWs and a second message to activate the group of 226 backup PWs associated with the access link. Finally, EVPN may employ 227 data plane local repair mechanisms not available in VPWS. 229 5 ESI Bandwidth 231 The ESI Bandwidth will be encoded using the Link Bandwidth Extended 232 community defined in [draft-ietf-idr-link-bandwidth] and associated 233 with the Ethernet AD route used to realize the EVPL services. 235 When a PE receives this attribute for a given EVPL it MUST request 236 the required bandwidth from the PSN towards the other EVPL service 237 destination PE originating the message. When resources are allocated 238 from the PSN for a given EVPL service, then the PSN SHOULD account 239 for the Bandwidth requested by this EVPL service. 241 In the case where PSN resources are not available, the PE receiving 242 this attribute MUST re-send its local Ethernet AD routes for this 243 EVPL service with the ESI Bandwidth = All FFs to declare that the 244 "PSN Resources Unavailable". 246 6 ESI value derivation 248 The 10 bytes ESI value will contain:- 250 1) 6-byte System-ID that is globally unique. These 6 bytes can be 251 auto derived using a mechanism similar to the one used for 252 automating B-MAC Address Assignment in [PBB-EVPN]. 254 2) 4-byte Local-AC-ID that is unique within each PE. 256 The combination of System-ID and Local-AC-ID makes the associated AC- 257 ID globally unique. A pair of such globally unique AC-ID identifies a 258 point-to-point service (EVPL or EPL) uniquely in the provider 259 network. 261 7 VPWS with multiple sites 263 The future revision of this draft will describe how a VPWS among 264 multiple sites (full mesh of P2P connections - one per pair of sites) 265 can be setup automatically without any explicit provisioning of P2P 266 connections among the sites. 268 8 Security Considerations 269 This document does not introduce any additional security constraints. 270 9 IANA Considerations 272 TBD 274 10 References 276 10.1 Normative References 278 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 10.2 Informative References 283 [EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for 284 Ethernet VPN", draft-ietf-l2vpn-evpn-req-00.txt. 286 [EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet 287 VPN", draft-ietf-l2vpn-evpn-04.txt. 289 [PBB-EVPN] A. Sajassi et. al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- 290 05.txt. 292 [draft-ietf-idr-link-bandwidth] P. Mohapatra, R. Fernando, "BGP Link 293 Bandwidth Extended Community", draft-ietf-idr-link-bandwidth-06.txt 295 Authors' Addresses 297 Sami Boutros 298 Cisco 299 170 West Tasman Drive 300 San Jose, CA 95134, US 301 Email: sboutros@cisco.com 303 Ali Sajassi 304 Cisco 305 170 West Tasman Drive 306 San Jose, CA 95134, US 307 Email: sajassi@cisco.com 309 Samer Salam 310 Cisco 311 595 Burrard Street, Suite 2123 312 Vancouver, BC V7X 1J1, Canada 313 Email: ssalam@cisco.com 314 John Drake 315 Juniper Networks 316 Email: jdrake@juniper.net 318 Jeff Tantsura 319 Ericsson 320 Email: jeff.tantsura@ericsson.com