idnits 2.17.00 (12 Aug 2021) /tmp/idnits49892/draft-boutros-l2vpn-evpn-vpws-01.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 (February 24, 2013) is 3372 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: 'E-VPN' is mentioned on line 133, but not defined == Missing Reference: 'MEF' is mentioned on line 91, but not defined == Missing Reference: 'RFC2119' is mentioned on line 118, but not defined == Missing Reference: 'RFC4448' is mentioned on line 198, but not defined == Unused Reference: 'KEYWORDS' is defined on line 263, but no explicit reference was found in the text == Unused Reference: 'EVPN-REQ' is defined on line 271, but no explicit reference was found in the text == Unused Reference: 'EVPN' is defined on line 274, 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 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 6 John Drake 7 Juniper Networks 8 Jeff Tantsura 9 Ericsson 10 Expires: August 28, 2013 February 24, 2013 12 VPWS support in E-VPN 13 draft-boutros-l2vpn-evpn-vpws-01.txt 15 Abstract 17 This document describes how E-VPN can be used to support virtual 18 private wire service (VPWS) in MPLS/IP networks. E-VPN enables the 19 following characteristics for VPWS: active/standby as well as 20 active/active multi-homing with flow-based load-balancing, eliminates 21 the need for single-segment and multi-segment PW signaling, and 22 provides fast protection using data-plane prefix independent 23 convergence upon node or link failure. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4 E-VPN Comparison to PW Signaling . . . . . . . . . . . . . . . . 5 68 5 ESI Bandwidth Attribute . . . . . . . . . . . . . . . . . . . . 5 69 6 VPWS with multiple sites . . . . . . . . . . . . . . . . . . . . 6 70 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 72 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 9.1 Normative References . . . . . . . . . . . . . . . . . . . 6 74 9.2 Informative References . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1 Introduction 79 This document describes how E-VPN can be used to support virtual 80 private wire service (VPWS) in MPLS/IP networks. The use of E-VPN 81 mechanisms for VPWS applies the benefits of E-VPN to p2p services. 82 These benefits include active/standby AC redundancy as well as 83 active/active multi-homing with flow-based load-balancing. 84 Furthermore, the use of E-VPN for VPWS eliminates the need for 85 signaling single-segment and multi-segment PWs for p2p Ethernet 86 services. 88 [E-VPN] has the ability to forward customer traffic to/from a given 89 customer Attachment Circuit (AC), aka Ethernet Segment in E-VPN 90 terminology, without any MAC lookup. This capability is ideal in 91 providing p2p services (aka VPWS services). [MEF] defines EVPL 92 service as p2p service between a pair of ACs (designated by VLANs). 93 EVPL can be considered as a VPWS with only two ACs. In delivering an 94 EVPL service, the traffic forwarding capability of E-VPN using only a 95 pair of Ethernet AD routes is used; whereas, for more general VPWS, 96 traffic forwarding capability of E-VPN using a group of Ethernet AD 97 routes (one Ethernet AD route per AC/segment) is used. Since in VPWS 98 services, the traffic from an originating Ethernet Segment can go 99 only to a single destination Ethernet Segment, no MAC lookup is 100 needed and the MPLS label associated with the per-EVI Ethernet AD 101 route can be used in forwarding user traffic to the destination AC. 103 In current PW redundancy mechanisms, convergence time is a function 104 of control plane convergence characteristics. However, with E-VPN it 105 is possible to attain faster convergence through the use of data- 106 plane prefix independent convergence upon node or link failure. 108 This document proposes the use of the Ethernet AD route to signal 109 labels for P2P Ethernet services. As with E-VPN, the Ethernet Segment 110 route can be used to synchronize state between the PEs attached to 111 the same multi-homed Segment. 113 1.1 Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 MAC: Media Access Control 121 MPLS: Multi Protocol Label Switching. 123 OAM: Operations, Administration and Maintenance. 125 PE: Provide Edge Node. 127 CE: Customer Edge device e.g., host or router or switch. 129 EVI: E-VPN Instance. 131 2. BGP Extensions 133 [E-VPN] defines a new BGP NLRI for advertising different route types 134 for E-VPN operation. This document does not define any new BGP 135 messages, but rather re-purposes one of the routes as described next. 137 This document proposes the use of the per EVI Ethernet AD route to 138 signal P2P services. The Ethernet Segment Identifier field is set to 139 the ESI of the attachment circuit of the VPWS service instance. The 140 Ethernet Tag field is set to 0 in the case of an Ethernet Private 141 Wire service, and to the VLAN identifier associated with the service 142 for Ethernet Virtual Private Wire service. The route is associated 143 with a Route-Target (RT) extended community attribute that identifies 144 the service instance (together with the Ethernet Tag field when non- 145 zero). 147 3 Operation 149 The following figure shows an example of a P2P service deployed with 150 E-VPN. 151 Ethernet Ethernet 152 Native |<---------E-VPN Instance------------>| Native 153 Service | | Service 154 (AC) | |<-PSN1->| |<-PSN2->| | (AC) 155 | V V V V V V | 156 | +-----+ +-----+ +-----+ +-----+ | 157 +----+ | | PE1 |======|ASBR1|==|ASBR2|===| PE3 | | +----+ 158 | |-------+-----+ +-----+ +-----+ +-----+-------| | 159 | CE1| | | |CE2 | 160 | |-------+-----+ +-----+ +-----+ +-----+-------| | 161 +----+ | | PE2 |======|ASBR3|==|ASBR4|===| PE4 | | +----+ 162 ^ +-----+ +-----+ +-----+ +-----+ ^ 163 | Provider Edge 1 ^ Provider Edge 2 | 164 | | | 165 | | | 166 | E-VPN Inter-provider point | 167 | | 168 |<---------------- Emulated Service -------------------->| 170 iBGP sessions will be established between PE1, PE2, ASBR1 and ASBR3, 171 possibly via a BGP route-reflector. Similarly, iBGP sessions will be 172 established between PE3, PE4, ASBR2 and ASBR4. eBGP sessions will be 173 established among ASBR1, ASBR2, ASBR3, and ASBR4. 175 All PEs and ASBRs are enabled for the E-VPN SAFI, and exchange E-VPN 176 Ethernet A-D routes - one route per AC. The ASBRs re-advertise the 177 Ethernet A-D routes with Next Hop attribute set to their IP 178 addresses. The link between the CE and the PE is either a C-tagged or 179 S-tagged interface, as described in [802.1Q], that can carry a single 180 VLAN tag or two nested VLAN tags. This interface is set up as a trunk 181 with multiple VLANs. 183 A VPWS with multiple sites or multiple EVPL services on the same CE 184 port can be included in one EVI between 2 or more PEs. An Ethernet 185 Tag corresponding to each P2P connection and known to both PEs is 186 used to identify the services multiplexed in the same EVI. 188 For CE multi-homing, the Ethernet AD Route encodes the ESI associated 189 with the CE. This allows flow-based load-balancing of traffic between 190 PEs connected to the same multi-homed CE. The VPN ID MUST be the same 191 on both PEs attached to the site. The Ethernet Segment route may be 192 used too, for discovery of multi-homed CEs. In all cases traffic 193 follows the transport paths, which may be asymmetric. 195 4 E-VPN Comparison to PW Signaling 197 In E-VPN, service endpoint discovery and label signaling are done 198 concurrently using BGP. Whereas, with VPWS based on [RFC4448], label 199 signaling is done via LDP and service endpoint discovery is either 200 through manual provisioning or through BGP. In VPWS, redundancy is 201 limited to Active/Standby mode, while with E-VPN both Active/Active 202 and Active/Standby redundancy modes can be supported. In VPWS, backup 203 PWs are not used to carry traffic, while E-VPN traffic can be load- 204 balanced among primary and secondary PEs. On link or node failure, E- 205 VPN can trigger failover with the withdrawal of a single BGP route 206 per service, whereas with VPWS PW redundancy, the failover sequence 207 requires exchange of two control plane messages: one message to 208 deactivate the group of primary PWs and a second message to activate 209 the group of backup PWs associated with the access link. Finally, E- 210 VPN may employ data plane local repair mechanisms not available in 211 VPWS. 213 5 ESI Bandwidth Attribute 215 The ESI Bandwidth Attribute is a new optional BGP attribute that will 216 be associated with the Ethernet AD route used to realize the EVPL 217 services. 219 +---------------------------------------+ 220 | Type (2 octets) | 221 +---------------------------------------+ 222 | Length (2 octets) | 223 +---------------------------------------+ 224 | Flags (1 Octet) | 225 +---------------------------------------+ 226 | Reserved=0(1 Octet) | 227 +---------------------------------------+ 228 | Reverse SENDER_TSPEC | 229 +---------------------------------------+ 230 The content of the SENDER_TSPEC are as defined in [RFC 2210] section 231 3.1. 233 When a PE receives this attribute for a given EVPL it MUST request 234 the appropriate resources described in the SENDER_TSPEC from the PSN 235 towards the other EVPL service destination PE originating the 236 message. When resources are allocated from the PSN for a given EVPL 237 service, then the PSN SHOULD account for the Bandwidth requested by 238 this EVPL service. 240 In the case where PSN resources are not available, the PE receiving 241 this attribute MUST re-send its local Ethernet AD routes for this 242 EVPL service with the ESI Bandwidth attribute and with the Flags set 243 to 1 "PSN Resources Unavailable". 245 6 VPWS with multiple sites 247 The future revision of this draft will describe how a VPWS among 248 multiple sites (full mesh of P2P connections - one per pair of sites) 249 can be setup automatically without any explicit provisioning of P2P 250 connections among the sites. 252 7 Security Considerations 254 This document does not introduce any additional security constraints. 255 8 IANA Considerations 257 TBD 259 9 References 261 9.1 Normative References 263 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC 2210] Wroclawski, J. "The Use of RSVP with IETF Integrated 267 Services", RFC 2210, September 1997 269 9.2 Informative References 271 [EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for 272 Ethernet VPN", draft-ietf-l2vpn-evpn-req-00.txt. 274 [EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet 275 VPN", draft-ietf-l2vpn-evpn-00.txt. 277 Authors' Addresses 279 Sami Boutros 280 Cisco 281 170 West Tasman Drive 282 San Jose, CA 95134, US 283 Email: sboutros@cisco.com 285 Ali Sajassi 286 Cisco 287 170 West Tasman Drive 288 San Jose, CA 95134, US 289 Email: sajassi@cisco.com 291 Samer Salam 292 Cisco 293 595 Burrard Street, Suite 2123 294 Vancouver, BC V7X 1J1, Canada 295 Email: ssalam@cisco.com 297 John Drake 298 Juniper Networks 299 Email: jdrake@juniper.net 301 Jeff Tantsura 302 Ericsson 303 Email: jeff.tantsura@ericsson.com