idnits 2.17.00 (12 Aug 2021) /tmp/idnits12688/draft-hao-l2vpn-inter-nvo3-evpn-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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 301: '..."ESI Label Extended Community" MUST be...' RFC 2119 keyword, line 399: '... routes MUST be the same as the orig...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 2871 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'EVPN' on line 106 -- Looks like a reference, but probably isn't: 'EVPN-OVERLAY' on line 277 -- Looks like a reference, but probably isn't: 'RFC4364' on line 523 == Unused Reference: '1' is defined on line 540, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 543, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 546, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 549, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 552, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 556, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 560, but no explicit reference was found in the text -- No information found for draft-ietfl2vpn-evpn - is the name correct? == Outdated reference: draft-ietf-nvo3-arch has been published as RFC 8014 == Outdated reference: draft-ietf-nvo3-framework has been published as RFC 7365 == Outdated reference: draft-sridharan-virtualization-nvgre has been published as RFC 7637 Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L2VPN Weiguo Hao 2 Liang Xia 3 Shunwan Zhuang 4 Internet Draft Huawei 5 Vic Liu 6 China Mobile 7 Intended status: Informational July 4, 2014 8 Expires: January 2015 10 Inter-AS Option B between NVO3 and MPLS EVPN network 11 draft-hao-l2vpn-inter-nvo3-evpn-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 4, 2015. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. 48 Abstract 50 This draft describes option-B inter-as connection between NVO3 51 network and MPLS EVPN network. Comparing to traditional MPLS EVPN 52 Option-B inter-as connection, this draft provides enhancement for 53 heterogeneous network multi-as connection, the control plane and 54 data plane procedures in NVO3 network are described. 56 Table of Contents 58 1. Introduction ................................................ 2 59 2. Conventions used in this document............................ 3 60 3. Reference model ............................................. 5 61 4. Option-A inter-as solution overview.......................... 6 62 5. Inter-as option-B routing distribution process............... 7 63 5.1. Ethernet Tag ID conversion on ASBR...................... 7 64 5.2. Ethernet Auto-Discovery Route process................... 8 65 5.2.1. Optimized MPLS Label solution on ASBR.............. 9 66 5.3. Ethernet Segment Route process......................... 10 67 5.4. Inclusive Multicast Ethernet Tag Route process..........10 68 5.5. MAC/IP advertisement route process .....................10 69 6. Inter-as option-B data plane procedures .....................12 70 6.1. Internal DC to external DC direction ...................12 71 6.2. External DC to internal DC direction ...................12 72 7. Inter-as option-B solution between PBB-EVPN network and NVO3 73 network ....................................................... 13 74 8. Security Considerations..................................... 13 75 9. IANA Considerations ........................................ 13 76 10. References ................................................ 13 77 10.1. Normative References.................................. 13 78 10.2. Informative References................................ 13 79 11. Acknowledgments ........................................... 14 81 1. Introduction 83 In cloud computing era, multi-tenancy has become a core requirement 84 for data centers. Since NVO3 can satisfy multi-tenancy key 85 requirements, this technology is being deployed in an increasing 86 number of cloud data center network. NVO3 focuses on the 87 construction of overlay networks that operate over an IP (L3) 88 underlay transport network. It can provide layer 2 bridging and 89 layer 3 IP service for each tenant. VXLAN and NVGRE are two typical 90 NVO3 technologies. NVO3 overlay network can be controlled through 91 centralized NVE-NVA architecture or through distributed BGP VPN 92 protocol. 94 NVO3 has good scaling properties from relatively small networks to 95 networks with several million tenant systems (TSs) and hundreds of 96 thousands of virtual networks within a single administrative domain. 97 In NVO3 network, 24-bit VN ID is used to identify different virtual 98 networks, theoretically 16M virtual networks can be supported in a 99 data center. In a data center network, each tenant may include one 100 or more layer 2 virtual network and in normal cases each tenant 101 corresponds to one routing domain (RD). Normally each layer 2 102 virtual network corresponds to one or more subnets. 104 To provide cloud service to external data center client, data center 105 networks should be connected with WAN networks. BGP MPLS based 106 Ethernet VPNs(EVPN)[EVPN] is being deployed in an increasing number 107 of WAN networks. If EVPN CEs in external DC and TSs in internal DC 108 belong to same subnet of same tenant, they are in same broadcast 109 domain and can freely layer 2 communicate with each other in the 110 broadcast domain. 112 Normally internal data center and external EVPN network belongs to 113 different autonomous system(AS). This requires the setting up of 114 inter-as connections at Autonomous System Border Routers(ASBRs) 115 between NVO3 network and external EVPN network. 117 Currently, a typical connection mechanism between a data center 118 network and an MPLS EVPN network is similar to Inter-AS Option-A of 119 RFC4364, but it has scalability issue if there is huge number of 120 tenants in data center networks. To overcome the issue, inter-as 121 Option-B between NVO3 network and BGP MPLS EVPN network is proposed 122 in this draft. 124 2. Conventions used in this document 126 EVI - An EVPN instance spanning across the PEs participating in that 127 EVPN. 129 MAC-VRF - A Virtual Routing and Forwarding table for MAC addresses on 130 a PE for an EVI. 132 Network Virtualization Edge (NVE) - An NVE is the network entity that 133 sits at the edge of an underlay network and implements network 134 virtualization functions. 136 Tenant System - A physical or virtual system that can play the role 137 of a host, or a forwarding element such as a router, switch, 138 firewall, etc. It belongs to a single tenant and connects to one or 139 more VNs of that tenant. 141 VN - A VN is a logical abstraction of a physical network that 142 provides L2 network services to a set of Tenant Systems. 144 RD - Route Distinguisher. RDs are used to maintain uniqueness among 145 identical routes in different MAC-VRFs, The route distinguisher is 146 an 8-octet field prefixed to the customer's MAC address. The 147 resulting 12-octet field is a unique "VPN-MAC" address. 149 RT - Route targets. It is used to control the import and export of 150 routes between different MAC-VRFs. 152 3. Reference model 154 |---------------------------------------------------| 155 | ------ AS1 | 156 | | TS1| - | 157 | ------ - | 158 | - ------ ------ | 159 | - |NVE1| -- |TOR1|---------------- | 160 | ------ - ------ ------ | | 161 | | TS2|- | | 162 | ------ | | 163 | -------- | 164 | |------------ | ASBR1| | 165 | ------ | -------- | 166 | | TS3| - | | | 167 | ------ - | | | 168 | - ------ ------ | | 169 | - |NVE2| -- |TOR2| | | 170 | ------ - ------ ------ | | 171 | | TS4|- | | 172 | ------ | | 173 |---------------------------------------------------- 174 | | | 175 | ------ | | 176 | | CE1| - | | 177 | ------ - | | 178 | - ------ -------- | 179 | - | PE1| --------------------| ASBR2| | 180 | ------ - ------ -------- | 181 | | CE2|- | 182 | ------ AS2 | 183 |---------------------------------------------------| 185 Figure 1 Reference model 187 Figure 1 shows an arbitrary Multi-AS VPN interconnectivity scenario 188 between NVO3 network and MPLS EVPN network. NVE1, NVE2, and ASBR1 189 forms NVO3 overlay network in internal DC. TS1 and TS2 connect to 190 NVE1, TS3 and TS4 connect to NVE2. PE1 and ASBR2 forms MPLS EVPN 191 network in external DC. CE1 and CE2 connect to PE1. The NVO3 network 192 belongs to AS 1, the MPLS EVPN network belongs to AS 2. 194 There are two tenants of tenant 1 and tenant 2 in NVO3 network. MAC- 195 VRF 1 and MAC-VRF 2 are created on NVE1 and NVE2 for these two 196 tenants. TSs(TS1 and TS3) in tenant 1 and CE(CE1) in VPN-Red belongs 197 to same subnet and broadcast domain, TSs(TS2 and TS4) in tenant 2 198 and CE(CE2) in VPN-Green belongs to same subnet and broadcast domain. 199 The TSs and CEs in same broadcast domain can freely layer 2 200 communicate with each other. 202 The TS and CE information in above figure 1 are as follows: 204 +-------+----------+-------------+---------+---------+ 205 | TS | Tenant | IP Address | MAC | VN ID | 206 +-------+----------+-------------+---------+---------+ 207 | TS1 | 1 | 10.1.1.2 | MAC1 | 10 | 208 +-------+----------+-------------+---------+---------+ 209 | TS2 | 2 | 20.1.1.2 | MAC2 | 20 | 210 +-------+----------+-------------+---------+---------+ 211 | TS3 | 1 | 10.1.1.3 | MAC3 | 10 | 212 +-------+----------+-------------+---------+---------+ 213 | TS4 | 2 | 20.1.1.3 | MAC4 | 20 | 214 +-------+----------+-------------+---------+---------+ 215 Table 1 TS information in NVO3 network 217 +-------+--------------------+-------------+-------------+---------+ 218 | CE | Route Distinguisher| Route Target| IP Address | MAC | 219 +-------+--------------------+-------------+-------------+---------+ 220 | CE1 | VPN-Red1 | 1:1 | 10.1.1.4 | MAC5 | 221 +-------+--------------------+-------------+-------------+---------+ 222 | CE2 | VPN-Green1 | 2:2 | 20.1.1.4 | MAC6 | 223 +-------+--------------------+-------------+-------------+---------+ 224 Table 2 CE information in MPLS/IP VPN network 226 4. Option-A inter-as solution overview 228 In Option-A inter-as solution, peering ASBRs are connected by 229 multiple sub-interfaces, each ASBR acts as a PE, and thinks that the 230 other ASBR is a CE. EVPN instances are configured at AS border 231 routers (ASBR1 and ASBR2) so that each ASBRs associate each such 232 sub-interface with a EVPN instance. It requires MAC look up on ASBRs. 233 MAC address propagation for each EVPN instance between ASBR1 and 234 ASBR2 relies on data plane learning mechanism. In the data-plane, 235 VLANs are used for VPN traffic separation. 237 Option-A inter-as solution has following issues: 239 1. Up to 16 million (16M) sub-interfaces need to exist between the 240 ASBRs, if there are 16M VN in NVO3 network. 242 2. UP to 16M EVPN instances need to be supported on border routers. 244 3. Several million MAC routing entries need to be supported on 245 border routers. 247 Inter-as option B between NVO3 network and MPLS EVPN network can be 248 used to address these issues. Due to it is for multi-as 249 interconnection between heterogeneous networks, so there are some 250 differences from traditional homogenous EVPN Inter-AS Option-B. 252 5. Inter-as option-B routing distribution process 254 In option-B inter-as solution, an EBGP session is used to distribute 255 labeled EVPN NLRI between the ASBRs. The advantage of this option is 256 that it's more scalable, as there is no need to have one sub- 257 interface per VPN between ASBRs. 259 There are four Route Types in EVPN NLRI, they are Ethernet Segment 260 Route, Ethernet Auto-Discovery Route, Inclusive Multicast Ethernet 261 Tag Route and MAC/IP advertisement route which are used for 262 Designated Forwarder Election, fast Convergence and aliasing or 263 backup-path, multicast traffic handling and unicast traffic handling 264 respectively. 266 For inter-as option-B interconnection between EVPN and NVO3 network, 267 When a ASBR receives BGP update message carrying the routes from 268 peer PEs or NVEs in local AS, it should re-constructs these message 269 and advertises it to peer ASBR, the Next Hop field of the 270 MP_REACH_NLRI attribute should be set to a routable IP address of 271 the ASBR. When the peer ASBR receives the message, the ASBR also 272 should re-construct the message and advertise it to peer PEs or NVEs 273 in its local AS, the Next Hop field of the MP_REACH_NLRI attribute 274 also should be set to a routable IP address of the ASBR. 276 In NVO3 network, there are two options for mapping the VNI to an EVI 277 [EVPN-OVERLAY], one is single subnet per EVI, and another one is 278 multiple subnets per EVI. 280 In the following subsection, a detail explanation will be given on 281 how to re-construct EVPN update message and how to generate incoming 282 and outgoing forwarding table on ASBR. 284 5.1. Ethernet Tag ID conversion on ASBR 286 A broadcast domain can be identified by different Ethernet Tag ID in 287 NVO3 and MPLS EVPN network. The Ethernet Tag ID mapping relationship 288 between NVO3 and MPLS EVPN network should be configured on each ASBR 289 in beforehand. For example, VLAN 10 in EVPN network and VN 100 in 290 NVO3 network belong to same broadcast domain, NVO3 network uses 100 291 as Ethernet Tag ID, EVPN network uses 10 as Ethernet Tag ID. 293 When a ASBR receives BGP update message carrying EVPN NLRI from peer 294 ASBR, it should replace Ethernet Tag ID field with local 295 corresponding value and then advertise the message to peer PEs or 296 NVEs in its local AS. 298 5.2. Ethernet Auto-Discovery Route process 300 There are two Ethernet A-D route types, one is per ES route, and 301 another one is per EVI. The "ESI Label Extended Community" MUST be 302 included in the route, it is to indicate ES's redundancy mode and to 303 advertise ESI Label for split-horizon filtering. 305 When an ASBR in NVO3 network receives Ethernet A-D per ES route, the 306 ASBR learns a ES and multi-homed NVEs correspondence, the ES's 307 redundancy mode. If "Single-Active" flag in "ESI Label Extended 308 Community" is set, the ES is operating in Single-Active redundancy 309 mode. Otherwise, it is operating in All-Active redundancy mode. The 310 Ethernet A-D per EVI route can be used for Aliasing and Backup-Path, 311 aliasing is used for all-active mode, backup-path is for single- 312 active mode. 314 When an ASBR in NVO3 network receives Ethernet A-D per EVI route, 315 the ASBR should allocate new MPLS Label and advertises it to all 316 peer ASBRs in Ethernet Auto-Discovery Route MPLS Label field. In 317 NVO3 network, the MPLS Label allocation principle is: If ESI is 0, 318 MPLS label is allocated per NVE per VN(This is single-homed case). 319 Otherwise, MPLS label is allocated per ESI per VN((This is multi- 320 homed case). MPLS VPN Label and correspondence is 321 used to generate incoming forwarding table on each ASBR, traffic 322 forwarding from external to internal DC direction relies on the 323 incoming forwarding table. 325 In multi-homed scenario, when an ESI occurs link failure and lost 326 connection with a NVE, the NVE should trigger ASBR in its local AS 327 to mass update its local forwarding table by Ethernet A-D per ES 328 route. This is called fast convergence procedure. The ASBR doesn't 329 need re-allocate MPLS Label for each VN on the ESI and advertise to 330 peer AS, i.e., fast convergence process is restricted to local AS, 331 the Ethernet A-D route per ES doesn't need to be transmitted to peer 332 AS. 334 For aliasing and backup-path procedures, these procedures also don't 335 need cross different AS domain, they are only restricted in local AS, 336 each ASBR in local AS needs to process Ethernet A-D per EVI route 337 from PEs or NVEs in local AS for these procedures. 339 In aliasing case, when a ASBR in NVO3 network receives traffic data 340 from external DC to external DC, the traffic will be forwarded to 341 all-active remote NVEs in load balancing mode. For each aliasing ES 342 and VN, there is a corresponding incoming forwarding table item 343 which includes one MPLS Label and multiple pairs on ASBR, 344 the NVE is a member of remote multi-homed NVEs attaching the 345 aliasing ES. 347 In backup-path case, for each backup-path ES and VN, there is a 348 corresponding incoming forwarding table item which includes one MPLS 349 Label and one on ASBR, the NVE is primary NVE that 350 advertises the MAC/IP advertisement route in the VN. When a ASBR 351 receives first MAC/IP advertisement route from remote primary NVE, 352 it will know the primary NVE and generate the incoming forwarding 353 table item. 355 5.2.1. Optimized MPLS Label solution on ASBR 357 MPLS Label consumption on ASBR is high through the above per ESI per 358 VN solution, the optimized allocation solution is provided as 359 follows: 361 If multiple ESIs are operating in all-active mode and attached to 362 the exact same set of NVEs, then these ESIs can share same MPLS 363 Label for same VN to save MPLS Label space on ASBR. 365 If multiple ESIs are operating in single-active mode and attached to 366 the exact same set of NVEs, primary NVEs for these ESI are same NVE, 367 then the VNs on these ESIs can share same MPLS Label for same VN to 368 save MPLS VPN Label space on ASBR. 370 In this case, if a ESI occurs link failure and lost connection with 371 a NVE, the NVE advertises Ethernet Auto-Discovery Route per ES to 372 each ASBR in its local AS, the ASBRs knows that the ESI is attached 373 to a different set of NVEs, it should re-allocate new MPLS Labels 374 for each VN on the ESI, mass update its incoming forwarding table, 375 then advertise these MPLS Labels using Ethernet Auto-Discovery route 376 per EVI to peer ASBR. 378 When peer ASBR receives the Ethernet Auto-Discovery route per EVI, 379 it allocates new MPLS Label and replaces the value in Ethernet Auto- 380 Discovery Route MPLS Label field, then advertises it to all peer PEs. 382 Remote PEs in peer AS should update all its MAC entries with the new 383 MPLS Label associated with the ESI and EVI. 385 5.3. Ethernet Segment Route process 387 Due to this route is used for DF election and multi-homed PE or NVE 388 devices won't straddle between MPLS EVPN and NVO3 network, so when a 389 ASBR receives BGP update message carrying the route from peer PE or 390 NVE in its own AS, it just removes it from the message, the route 391 don't need to be transmitted to peer AS. 393 5.4. Inclusive Multicast Ethernet Tag Route process 395 Similar to regular EVPN inter-as solution, when a ASBR receives from 396 one of its IBGP neighbors a BGP Update message that carries the 397 route, it re-advertises it to peer ASBRs and these peer ASBRs re- 398 advertise it to peer PEs or NVEs in its local AS. The re-advertised 399 routes MUST be the same as the original ones, except for the PMSI 400 Tunnel attribute in Inclusive Multicast Ethernet Tag Route and 401 Ethernet Tag ID. If ingress replication is used between ASBRs, the 402 Tunnel Type in PMSI Tunnel attribute is set to Ingress Replication, 403 the Leaf Information Required flag is set to 1, the PMSI Tunnel 404 attribute carries no MPLS labels. 406 5.5. MAC/IP advertisement route process 408 Because the ASBR in NVO3 network has already assigned MPLS Label for 409 each ESI(or NVE in single-homed case) and each VN when it received 410 Ethernet Auto-Discovery Route from remote NVEs in its local AS, so 411 the ASBR receives first MAC/IP advertisement route from a , 412 it will search the already assigned MPLS Label for the , 413 generate a incoming forwarding item, fuel MPLS Label field in the 414 MAC/IP advertisement route, and then send it to peer ASBR. The 415 incoming forwarding table is used for traffic forwarding from 416 external DC to internal DC direction. 418 In above figure 1, all TSs are single-homed to a NVE, MPLS VPN Label 419 is assigned per NVE per VN, the incoming forwarding table on ASBR in 420 NVO3 network is as follows: 422 +--------------------+------------------+ 423 | MPLS VPN Label | NVE + VN ID | 424 +--------------------+------------------+ 425 | 1000 | NVE1 + 10 | 426 +--------------------+------------------+ 427 | 2000 | NVE1 + 20 | 428 +--------------------+------------------+ 429 | 1001 | NVE2 + 10 | 430 +--------------------+------------------+ 431 | 2001 | NVE2 + 20 | 432 +--------------------+------------------+ 433 Incoming forwarding table 435 When ASBR1 in NVO3 network receives from EBGP neighbors ASBR2 a BGP 436 Update message that carries MAC/IP advertisement route, it should 437 allocate VN ID per MPLS VPN Label, generate outgoing forwarding 438 table, and then advertises it to peer NVEs in its local AS. 440 In above figure 1, ASBR1 allocates VN ID for each VPN Label 441 receiving from ASBR2, and then ASBR2 advertises the MAC/IP 442 advertisement route with new allocated VN ID to each NVE (NVE1 and 443 NVE2). The role of the VN ID is similar to the role of In VPN Label 444 in ASBR1, it has local significance on ASBR1, each VN ID corresponds 445 to each MPLS VPN Label on ASBR2; The VN ID space should be assigned 446 in beforehand and should be orthogonal to the VN ID space for tenant 447 identification(for example, assuming ASBR1 has local connecting TSs 448 of tenant 1 to 100, VN ID 1 to 100 are allocated for these tenants, 449 other VN ID other than 1 to 100 can be allocated for outgoing 450 forwarding table purpose). The allocated VN ID and its corresponding 451 out VPN Label forms an outgoing forwarding table which is used to 452 forward NVO3 traffic from internal DC to external DC. The outgoing 453 forwarding table on ASBR1 is as follows: 455 +------------------+--------------------+ 456 | VN ID | Out VPN Label | 457 +------------------+--------------------+ 458 | 10000 | 3000 | 459 +------------------+--------------------+ 460 | 10001 | 4000 | 461 +------------------+--------------------+ 462 Outgoing forwarding table 464 6. Inter-as option-B data plane procedures 466 This section describes the step by step procedures of data forward 467 for either: a) internal DC to external DC data flows, or b) the 468 external DC to internal DC data flows. 470 6.1. Internal DC to external DC direction 472 1. TS1 sends traffic to NVE1, the destination MAC is CE1's MAC 473 address of MAC5. 475 2. NVE1 looks up MAC-VRF 1's MAC forwarding table, then it gets NVO3 476 tunnel encapsulation information. The destination outer address 477 is ASBR1's IP address, VN ID is 10000. NVE1 performs NVO3 478 encapsulation and sends the traffic to ASBR1. 480 3. ASBR1 decapsulates NVO3 encapsulation and gets VN ID 10000. Then 481 it looks up outgoing forwarding table based on the VN ID and gets 482 MPLS VPN label 3000. Finally it pushes MPLS VPN label for the IP 483 traffic and sends it to ASBR2. 485 4. ASBR2 swaps VPN Label, then sends the traffic to PE1 through IGP 486 tunnel. 488 5. PE1 terminates IGP tunnel, pops MPLS VPN label 3000, looks up 489 local MAC-VRF 1, and then forwards the traffic to CE1. 491 6.2. External DC to internal DC direction 493 1. CE1 sends traffic to PE1, destination MAC is TS1's MAC address of 494 MAC1. 496 2. PE1 looks up local MAC forwarding table in VPN-RED, pushes MPLS 497 VPN label 1000, then searches IGP tunnel, then the PE sends the 498 traffic to ASBR2 through IGP tunnel. 500 3. ASBR2 terminates IGP tunnel, swaps MPLS VPN label, then sends the 501 traffic to ASBR1. 503 4. ASBR1 looks up incoming forwarding table and gets NVO3 504 encapsulation, then performs NVO3 encapsulation and sends the 505 traffic to NVE1. The destination outer IP is NVE1's IP, VN ID is 506 10. 508 5. NVE1 decapsulates NVO3 encapsulation, gets local EVPN instance 1 509 relying on VN ID 10, looks up local MAC-VRF 1, then sends the 510 traffic to TS1. 512 7. Inter-as option-B solution between PBB-EVPN network and NVO3 network 514 For the further study. 516 8. Security Considerations 518 Similar to the security considerations for inter-as Option-B in 519 [RFC4364] the appropriate trust relationship must exist between NVO3 520 network and MPLS EVPN network. EVPN routes in NVO3 network should 521 neither be distributed to nor accepted from the public Internet, or 522 from any BGP peers that are not trusted. For other general VPN 523 Security Considerations, see [RFC4364]. 525 9. IANA Considerations 527 This document requires no IANA actions. RFC Editor: Please remove 528 this section before publication. 530 10. References 532 10.1. Normative References 534 [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 10.2. Informative References 540 [1] [RFC4364] E. Rosen, Y. Rekhter, " BGP/MPLS IP Virtual Private 541 Networks (VPNs)", RFC 4364, February 2006. 543 [2] [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft- 544 ietfl2vpn-evpn-02.txt, work in progress, February, 2012. 546 [3] [NVA] D.Black, etc, "An Architecture for Overlay Networks (NVO3)", 547 draft-ietf-nvo3-arch-01, February 14, 2014 549 [4] [EVPN-OVERLAY] A. Sajassi,etc, ''A Network Virtualization Overlay 550 Solution using EVPN'', draft-sd-l2vpn-evpn-overlay-03, June, 2014 552 [5] [NOV3-FRWK] Lasserre et al., "Framework for DC Network 553 Virtualization", draft-ietf-nvo3-framework-01.txt, work in 554 progress, October 2012. 556 [6] [NVGRE] Sridhavan, M., et al., "NVGRE: Network Virtualization 557 using Generic Routing Encapsulation", draft-sridharan- 558 virtualization-nvgre-01.txt, July 8, 2012. 560 [7] [VXLAN] Dutt, D., et al, "VXLAN: A Framework for Overlaying 561 Virtualized Layer 2 Networks over Layer 3 Networks", 562 draftmahalingam-dutt-dcops-vxlan-02.txt, August 22, 2012. 564 11. Acknowledgments 566 Authors like to thank Junlin Zhang for his valuable inputs. 568 Authors' Addresses 570 Weiguo Hao 571 Huawei Technologies 572 101 Software Avenue, 573 Nanjing 210012 574 China 575 Email: haoweiguo@huawei.com 577 Liang Xia (Frank) 578 Huawei Technologies 579 101 Software Avenue, 580 Nanjing 210012 581 China 582 Email: frank.xialiang@huawei.com 584 Shunwan Zhuang 585 Huawei Technologies 586 Huawei Bld., No.156 Beiqing Rd. 587 Beijing 100095 588 China 589 Email: zhuangshunwan@huawei.com 591 Vic Liu 592 China Mobile 593 32 Xuanwumen West Ave, Beijing, China 594 Email: liuzhiheng@chinamobile.com