idnits 2.17.1 draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-00.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 222 has weird spacing: '...obility we ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 18, 2013) is 4056 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 275, but not defined == Unused Reference: 'EVPN' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'DC-MOBILITY' is defined on line 421, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-00 == Outdated reference: A later version (-02) exists of draft-sajassi-l2vpn-evpn-ipvpn-interop-01 == Outdated reference: A later version (-07) exists of draft-raggarwa-data-center-mobility-03 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2VPN Workgroup Ali Sajassi 3 INTERNET-DRAFT Samer Salam 4 Intended Status: Standards Track Cisco 6 Yakov Rekhter 7 John Drake 8 Juniper 10 Expires: August 18, 2013 February 18, 2013 12 IP Inter-Subnet Forwarding in E-VPN 13 draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-00 15 Abstract 17 E-VPN provides an extensible and flexible multi-homing VPN solution 18 for intra-subnet connectivity among hosts/VMs over an MPLS/IP 19 network. However, there are scenarios in which inter-subnet 20 forwarding among hosts/VMs across different IP subnets is required, 21 while maintaining the multi-homing capabilities of E-VPN. This 22 document describes an IRB solution based on E-VPN to address such 23 requirements. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2 Inter-Subnet Forwarding Scenarios . . . . . . . . . . . . . . . 4 65 2.1 Connecting E-VPN NVEs within a DC . . . . . . . . . . . . . 5 66 2.2 Connecting E-VPN NVEs in different DCs without route 67 aggregation . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.3 Connecting E-VPN NVEs in different DCs with route 69 aggregation . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.4 Connecting IP-VPN sites and E-VPN NVEs with route 71 aggregation . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3 Concepts needed before solution description . . . . . . . . . . 6 73 4 Operational Models for Inter-Subnet Forwarding . . . . . . . . 7 74 4.1 Among E-VPN NVEs within a DC . . . . . . . . . . . . . . . . 7 75 4.2 Among E-VPN NVEs in Different DCs Without Route 76 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.3 Among E-VPN NVEs in Different DCs with Route Aggregation . . 8 78 4.4 Among IP-VPN Sites and E-VPN NVEs with Route Aggregation . . 9 79 5 VM Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 10 81 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 82 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 83 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 85 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 88 Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 1 Introduction 96 E-VPN provides an extensible and flexible multi-homing VPN solution 97 for intra-subnet connectivity among hosts/VMs over an MPLS/IP 98 network. However, there are scenarios where, in addition to intra- 99 subnet forwarding, inter-subnet forwarding is required among 100 hosts/VMs across different IP subnets, while maintaining the multi- 101 homing capabilities of E-VPN. This document describes an IRB solution 102 based on E-VPN to address such requirements. 104 2 Inter-Subnet Forwarding Scenarios 106 The inter-subnet forwarding scenarios for E-VPN can be divided into 107 six categories. The first two scenarios, along with their 108 corresponding solutions, are described in [EVPN-IPVPN-INTEROP]. The 109 solutions for scenarios 3 through 6 are the focus of this document. 111 1. Connecting IP-VPN sites and E-VPN NVEs without route aggregation 112 2. Connecting IP-VPN NVEs and E-VPN NVEs without route aggregation 113 3. Connecting E-VPN NVEs within a DC 114 4. Connecting E-VPN NVEs in different DCs without route aggregation 115 5. Connecting E-VPN NVEs in different DCs with route aggregation 116 6. Connecting IP-VPN sites and E-VPN NVEs with route aggregation 118 In the above scenarios, the term "route aggregation" refers to the 119 case where a node situated at the edge of the data center network 120 behaves as a default gateway for all VM addresses that are unknown to 121 the data center switches. Effectively, this WAN edge switch 122 implements a gateway functionality. The absence of route aggregation 123 refers to the scenario where all data center switches are aware of 124 all VM addresses (in a given EVI/VRF context), for both VMs in the 125 local as well as remote data centers. 127 +---+ Enterprise Site 1 128 |PE1|----- H1 129 +---+ 130 / 131 ,---------. Enterprise Site 2 132 ,' `. +---+ 133 ,---------. /( MPLS/IP )---|PE2|----- H2 134 ' DCN 3 `./ `. Core ,' +---+ 135 `-+------+' `-+------+' 136 __/__ / / \ \ 137 :NVE4 : +---+ \ \ 138 '-----' ,----|GW |. \ \ 139 | ,' +---+ `. ,---------. 140 VM6 ( DCN 1 ) ,' `. 141 `. ,' ( DCN 2 ) 142 `-+------+' `. ,' 143 __/__ `-+------+' 144 :NVE1 : __/__ __\__ 145 '-----' :NVE2 : :NVE3 : 146 | | '-----' '-----' 147 VM1 VM2 | | | 148 VM3 VM4 VM5 150 Figure 2: Interoperability Use-Cases 152 In what follows, we will describe scenarios 3 through 6 in more 153 detail. 155 2.1 Connecting E-VPN NVEs within a DC 157 In this scenario, connectivity is required between hosts (e.g. VMs) 158 in the same data center, and those hosts belong to different IP 159 subnets. Each subnet is associated with a single EVI on the NVEs. 160 Furthermore, all the EVIs in question belong to the same VRF. 162 As an example, consider VM3 and VM5 of Figure 2 above. Assume that 163 connectivity is required between these two VMs where VM3 belongs to 164 the IP3 subnet whereas VM5 belongs to the IP5 subnet. NVE2 has an 165 EVI3 associated with IP3 subnet and NVE3 has an EVI5 associated with 166 the IP5 subnet. Both EVI3 and EVI5 are associated with the same VRFa. 168 2.2 Connecting E-VPN NVEs in different DCs without route aggregation 170 This case is similar to that of section 2.1 above albeit for the fact 171 that the hosts belong to different data centers that are 172 interconnected over a WAN (e.g. MPLS/IP PSN). The data centers in 173 question here are seamlessly interconnected to the WAN, i.e. no 174 gateways are used on the data center WAN edge. 176 As an example, consider VM3 and VM6 of Figure 2 above. Assume that 177 connectivity is required between these two VMs where VM3 belongs to 178 the IP3 subnet whereas VM6 belongs to the IP6 subnet. NVE2 has an 179 EVI3 associated with IP3 subnet and NVE4 has an EVI6 associated with 180 the IP6 subnet. Both EVI3 and EVI6 are associated with the same VRFa. 182 2.3 Connecting E-VPN NVEs in different DCs with route aggregation 184 In this scenario, connectivity is required between hosts (e.g. VMs) 185 in different data centers, and those hosts belong to different IP 186 subnets. What makes this case different from that of Section 2.2 is 187 that at least one of the data centers in question has a gateway as 188 the WAN edge switch. Because of that, the NVEs in the data centers 189 with gateways do not have the addresses of the hosts situated in 190 remote data centers. 192 As an example, consider VM1 and VM5 of Figure 2 above. Assume that 193 connectivity is required between these two VMs where VM1 belongs to 194 the IP1 subnet whereas VM5 belongs to the IP5 subnet. NVE3 has an 195 EVI5 associated with the IP5 subnet and NVE1 has an EVI1 associated 196 with the IP1 subnet. Both EVI1 and EVI5 are associated with the same 197 VRFa. Due to the gateway at the edge of DCN 1, NVE1 does not have the 198 address of VM5 in its VRFa table. 200 2.4 Connecting IP-VPN sites and E-VPN NVEs with route aggregation 202 In this scenario, connectivity is required between hosts (e.g. VMs) 203 in a data center and hosts in an enterprise site connected through 204 IP-VPN. The NVE within the data center is an E-VPN NVE, whereas the 205 NVE in the enterprise site is an IP-VPN NVE. Furthermore, the data 206 center in question has a gateway as the WAN edge switch. Because of 207 that, the NVE in the data center does not have the addresses of the 208 hosts situated in the enterprise site. 210 As an example, consider end-station H1 and VM2 of Figure 2. Assume 211 that connectivity is required between the end-station and the VM, 212 where VM2 belongs to the IP2 subnet whereas H1 belongs to the IP1 213 subnet. NVE1 has and EVI2 associated with the IP2 subnet. EVI2 is 214 associated with VRFa. On IP-VPN PE1, the IP1 subnet is in VRFa as 215 well. Due to the gateway at the edge of DCN 1, NVE1 does not have 216 the address of H1 in its VRFa table. 218 3 Concepts needed before solution description 220 3.1 Default GW & MAC address aliasing versus single MAC/IP 222 3.2 VM Mobility we can go from scenarios 2.2 to scenario 2.4 223 (describe how E-VPN provides capability 225 4 Operational Models for Inter-Subnet Forwarding 227 4.1 Among E-VPN NVEs within a DC 229 When an E-VPN MAC advertisement route is received by the NVE, the IP 230 address associated with the route is used to populate the VRF, 231 whereas the MAC address associated with the route is used to populate 232 both the bridge-domain MAC table, as well as the adjacency associated 233 with the IP route in the VRF. 235 When an Ethernet frame is received by an ingress NVE, it performs a 236 lookup on the destination MAC address in the associated EVI. If the 237 MAC address corresponds to its IRB Interface MAC address, the ingress 238 NVE deduces that the packet must be inter-subnet routed. Hence, the 239 ingress NVE performs an IP lookup in the associated VRF table. The 240 lookup identifies both the next-hop (i.e. egress) NVE to which the 241 packet must be forwarded, in addition to an adjacency that contains a 242 MAC rewrite and an MPLS label stack. The MAC rewrite holds the MAC 243 address associated with the destination host (as populated by the E- 244 VPN MAC route), instead of the MAC address of the next-hop NVE. The 245 ingress NVE then rewrites the destination MAC address in the packet 246 with the address specified in the adjacency. It also rewrites the 247 source MAC address with its IRB Interface MAC address. The ingress 248 NVE, then, forwards the frame to the next-hop (i.e. egress) NVE after 249 encapsulating it with the MPLS label stack. Note that this label 250 stack includes the LSP label as well as the EVI label that was 251 advertised by the egress NVE. When the MPLS encapsulated packet is 252 received by the egress NVE, it uses the EVI label to identify the 253 bridge-domain table. It then performs a MAC lookup in that table, 254 which yields the outbound interface to which the Ethernet frame must 255 be forwarded. Figure 2 below depicts the packet flow, where NVE1 and 256 NVE2 are the ingress and egress NVEs, respectively. 258 NVE1 NVE2 259 +------------+ +------------+ 260 | ... ... | | ... ... | 261 |(EVI)-[VRF] | |[VRF]-(EVI) | 262 | .|. .|. | | ... |..| | 263 +------------+ +------------+ 264 ^ v ^ V 265 | | | | 266 VM1->-+ +-->--------------+ +->-VM2 268 Figure 2: Inter-Subnet Forwarding Among E-VPN NVEs within a DC 270 Note that the forwarding behavior on the egress NVE is similar to E- 271 VPN intra-subnet forwarding. In other words, all the packet 272 processing associated with the inter-subnet forwarding semantics is 273 confined to the ingress NVE. 275 It should also be noted that [E-VPN] provides different level of 276 granularity for the EVI label. Besides identifying bridge domain 277 table, it can be used to identify the egress interface or a 278 destination MAC address on that interface. If EVI label is used for 279 egress interface or destination MAC address identification, then no 280 MAC lookup is needed in the egress EVI and the packet can be directly 281 forwarded to the egress interface just based on EVI label lookup. 283 4.2 Among E-VPN NVEs in Different DCs Without Route Aggregation 285 [This section will be expanded in the future revision]. 287 4.3 Among E-VPN NVEs in Different DCs with Route Aggregation 289 In this scenario, the NVEs within a given data center do not have 290 entries for the MAC/IP addresses of hosts in remote data centers. 291 Rather, the NVEs have a default IP route pointing to the WAN gateway 292 for each VRF. This is accomplished by the WAN gateway advertising for 293 a given E-VPN that spans multiple DC a default VPN-IP route that is 294 imported by the NVEs of that E-VPN that are in the gateway's own DC. 296 When an Ethernet frame is received by an ingress NVE, it performs a 297 lookup on the destination MAC address in the associated EVI. If the 298 MAC address corresponds to the IRB Interface MAC address, the ingress 299 NVE deduces that the packet must be inter-subnet routed. Hence, the 300 ingress NVE performs an IP lookup in the associated VRF table. The 301 lookup, in this case, matches the default route which points to the 302 local WAN gateway. The ingress NVE then rewrites the destination MAC 303 address in the packet with the IRB Interface MAC address of the local 304 WAN gateway. It also rewrites the source MAC address with its own IRB 305 Interface MAC address. The ingress NVE, then, forwards the frame to 306 the WAN gateway after encapsulating it with the MPLS label stack. 307 Note that this label stack includes the LSP label as well as the IP- 308 VPN label that was advertised by the local WAN gateway. When the MPLS 309 encapsulated packet is received by the local WAN gateway, it uses the 310 IP-VPN label to identify the VRF table. It then performs an IP lookup 311 in that table. The lookup identifies both the remote WAN gateway (of 312 the remote data center) to which the packet must be forwarded, in 313 addition to an adjacency that contains a MAC rewrite and an MPLS 314 label stack. The MAC rewrite holds the MAC address associated with 315 the ultimate destination host (as populated by the E-VPN MAC route). 316 The local WAN gateway then rewrites the destination MAC address in 317 the packet with the address specified in the adjacency. It also 318 rewrites the source MAC address with its IRB Interface MAC address. 320 The local WAN gateway, then, forwards the frame to the remote WAN 321 gateway after encapsulating it with the MPLS label stack. Note that 322 this label stack includes the LSP label as well as a VPN label that 323 was advertised by the remote WAN gateway. When the MPLS encapsulated 324 packet is received by the remote WAN gateway, it simply swaps the VPN 325 label with the EVI label advertised by the egress NVE. This implies 326 that the remote WAN gateway must allocate the VPN label at least at 327 the granularity of a (VRF, egress NVE) tuple. The remote WAN gateway 328 then forward the packet to the egress NVE. The egress NVE then 329 performs a MAC lookup in the EVI (identified by the received EVI 330 label) to determine the outbound port to send the traffic on. 332 Figure 4 below depicts the forwarding model. 334 NVE1 GW1 GW2 NVE2 335 +------------+ +------------+ +------------+ +------------+ 336 | ... ... | | ... ... | | ... | | ... ... | 337 |(EVI)-[VRF] | |[VRF]-(EVI) | | [LS ] | |[VRF]-(EVI) | 338 | .|. .|. | | |..| | | |...| | | ... |..| | 339 +------------+ +------------+ +------------+ +------------+ 340 ^ v ^ V ^ V ^ V 341 | | | | | | | | 342 VM1->-+ +-->-----+ +--------------+ +---------------+ +->-VM2 344 Figure 4: Inter-Subnet Forwarding Among E-VPN NVEs in Different DCs 345 with Route Aggregation 347 4.4 Among IP-VPN Sites and E-VPN NVEs with Route Aggregation 349 In this scenario, the NVEs within a given data center do not have 350 entries for the IP addresses of hosts in remote enterprise sites. 351 Rather, the NVEs have a default IP route pointing to the WAN gateway 352 for each VRF. 354 When an Ethernet frame is received by an ingress NVE, it performs a 355 lookup on the destination MAC address in the associated EVI. If the 356 MAC address corresponds to the IRB Interface MAC address, the ingress 357 NVE deduces that the packet must be inter-subnet routed. Hence, the 358 ingress NVE performs an IP lookup in the associated VRF table. The 359 lookup, in this case, matches the default route which points to the 360 local WAN gateway. The ingress NVE then rewrites the destination MAC 361 address in the packet with the IRB Interface MAC address of the local 362 WAN gateway. It also rewrites the source MAC address with its own IRB 363 Interface MAC address. The ingress NVE, then, forwards the frame to 364 the WAN gateway after encapsulating it with the MPLS label stack. 365 Note that this label stack includes the LSP label as well as the IP- 366 VPN label that was advertised by the local WAN gateway. When the MPLS 367 encapsulated packet is received by the local WAN gateway, it uses the 368 IP-VPN label to identify the VRF table. It then performs an IP lookup 369 in that table. The lookup identifies the next hop ASBR to which the 370 packet must be forwarded. The local gateway in this case strips the 371 Ethernet encapsulation and forwards the IP packet to the ASBR using a 372 label stack comprising of an LSP label and a VPN label that was 373 advertised by the ASBR. When the MPLS encapsulated packet is received 374 by the ASBR, it simply swaps the VPN label with the IP-VPN label 375 advertised by the egress PE. This implies that the remote WAN gateway 376 must allocate the VPN label at least at the granularity of a (VRF, 377 egress PE) tuple. The ASBR then forwards the packet to the egress PE. 378 The egress PE then performs an IP lookup in the VRF (identified by 379 the received IP-VPN label) to determine where to forward the traffic. 381 Figure 5 below depicts the forwarding model. 383 NVE1 GW1 ASBR PE 384 +------------+ +------------+ +------------+ +------------+ 385 | ... ... | | ... ... | | ... | | ... | 386 |(EVI)-[VRF] | |[VRF]-(EVI) | | [LS ] | | [VRF]| 387 | .|. .|. | | |..| | | |...| | | |..| | 388 +------------+ +------------+ +------------+ +------------+ 389 ^ v ^ V ^ V ^ V 390 | | | | | | | | 391 VM1->-+ +-->-----+ +--------------+ +---------------+ +->-H1 393 Figure 5: Inter-Subnet Forwarding Among IP-VPN Sites and E-VPN NVEs 394 with Route Aggregation 396 5 VM Mobility 398 describe how mobility works 400 5 Acknowledgement 402 6 Security Considerations 404 7 IANA Considerations 406 8 References 407 8.1 Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 8.2 Informative References 414 [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 415 l2vpn-evpn-00.txt, work in progress, February, 2012. 417 [EVPN-IPVPN-INTEROP] Sajassi et al., "E-VPN Seamless Interoperability 418 with IP-VPN", draft-sajassi-l2vpn-evpn-ipvpn-interop-01, work in 419 progress, October, 2012. 421 [DC-MOBILITY] Aggarwal et al., "Data Center Mobility based on 422 BGP/MPLS, IP Routing and NHRP", draft-raggarwa-data-center-mobility- 423 03.txt, work in progress, June, 2012. 425 Authors' Addresses 427 Ali Sajassi 428 Cisco 429 Email: sajassi@cisco.com 431 Samer Salam 432 Cisco 433 Email: ssalam@cisco.com 435 Yakov Rekhter 436 Juniper Networks 437 Email: yakov@juniper.net 439 John E. Drake 440 Juniper Networks 441 Email: jdrake@juniper.net