idnits 2.17.1 draft-hao-bess-inter-nvo3-vpn-optionc-03.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 245 has weird spacing: '...g table betwe...' == Line 269 has weird spacing: '...DP port and G...' == Line 430 has weird spacing: '...cquired by pe...' -- The document date (September 10, 2015) is 3144 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) -- Looks like a reference, but probably isn't: 'RFC7348' on line 292 -- Looks like a reference, but probably isn't: 'NVGRE' on line 94 -- Looks like a reference, but probably isn't: 'RFC7510' on line 292 -- Looks like a reference, but probably isn't: 'RFC4364' on line 445 -- Looks like a reference, but probably isn't: 'RFC3107' on line 300 -- Looks like a reference, but probably isn't: 'TUNNELENCAP' on line 302 == 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 551, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 555, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 559, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-nvo3-arch-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-arch (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 7047 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-03) exists of draft-rosen-idr-tunnel-encaps-00 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 BESS Working Group W. Hao 2 L. Yong 3 S. Hares 4 Internet Draft Huawei 5 Osama Zia 6 Microsoft 7 Muhammad Durrani 8 Cisco 9 Intended status: Standard Track September 10, 2015 10 Expires: March 10, 2016 12 Inter-AS Option C between NVO3 and BGP/MPLS IP VPN network 13 draft-hao-bess-inter-nvo3-vpn-optionc-03.txt 15 Abstract 17 This draft describes inter-as option-C solution between NVO3 network 18 and MPLS/IP VPN network. Transport layer stitching solution should 19 be provided. Also to ensure VPNv4 route exchange correctly between 20 local NVE and remote PE, VNID space should be partitioned, only the 21 VNIDs of lower 1 Million can be used for interconnection with outer 22 MPLS VPN network using option-C solution, the rest 15 Million VNIDs 23 can only be used for intra DC. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with 28 the 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 Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any 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/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Copyright Notice 48 Copyright (c) 2015 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 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction ................................................ 2 64 2. Conventions used in this document............................ 4 65 3. Reference model ............................................. 5 66 4. Traditional Option-C [RFC4364] Recap......................... 6 67 5. Inter-As Option-C Solution................................... 6 68 5.1. EBGP process for transport layer stitching.............. 7 69 5.1.1. UDP based overlay network.......................... 7 70 5.1.2. GRE based overlay network.......................... 8 71 5.2. VPN routes exchange..................................... 9 72 5.3. Data forwarding process................................. 9 73 5.3.1. Data flow from TS1 to CE1.......................... 9 74 5.3.2. Data flow from CE1 to TS1......................... 10 75 6. NVE-NVA architecture........................................ 10 76 6.1. EBGP process for transport layer stitching............. 11 77 6.2. VPN route exchange..................................... 11 78 7. Security Considerations..................................... 12 79 8. IANA Considerations ........................................ 12 80 9. References ................................................. 12 81 9.1. Normative References................................... 12 82 9.2. Informative References................................. 13 83 10. Acknowledgments ........................................... 13 85 1. Introduction 87 In cloud computing era, multi-tenancy has become a core requirement 88 for data centers. Since Network Virtualization Overlays (NVO3) can 89 satisfy multi-tenancy key requirements, this technology is being 90 deployed in an increasing number of cloud data center network. NVO3 91 focuses on the construction of overlay networks that operate over an 92 IP (L3) underlay transport network. It can provide layer 2 bridging 93 and layer 3 IP service for each tenant. VXLAN [RFC7348] and NVGRE 94 [NVGRE] are two typical NVO3 technologies. In NVO3 network, 24-bit 95 VNID (or VSID) is used to identify different virtual networks, 96 theoretically 16M virtual networks can be supported in a data center. 97 MPLS Over GRE and MPLS In UDP [RFC7510] are another two technologies 98 to construct the overlay network, 20-bit MPLS Label is used as 99 virtual networks identification. NVO3 overlay network can be 100 controlled through centralized NVE-NVA architecture or through 101 distributed BGP VPN protocol. 103 NVO3 has good scaling properties from relatively small networks to 104 networks with several million tenant systems (TSs) and hundreds of 105 thousands of virtual networks within a single administrative domain. 106 In a data center network, each tenant may include one or more layer 107 2 virtual network. In normal case, each tenant corresponds to one 108 routing domain (RD), each layer 2 virtual network corresponds to one 109 or more subnets. 111 To provide cloud service to external data center customers, data 112 center networks should be connected to the WAN network. BGP MPLS/IP 113 VPN are widely deployed technologies on WAN networks. Normally 114 internal data center and external MPLS/IP VPN network are different 115 Autonomous System (AS). 117 In multiple NVO3 data center inter-connecting scenario, the traffic 118 across data center normally are carried over BGP MPLS/IP VPN network. 119 This also requires an applicable inter-as solution between NVO3 120 network and external MPLS/IP network which can meet scale demands on 121 existing and future NVO3 data center. 123 Similar to the Inter-as connection method defined in RFC4364, there 124 are three different ways of handling this case, they are option-A, 125 option-B and option-C respectively in order of increasing 126 scalability. 128 Option-A is a back-to-back VRFs solution. Using option-A, EBGP 129 session per VPN is created on peering ASBRs. In the data-plane, 130 VLANs are used for tenant traffic separation. It has the lowest 131 scalability among the three solutions. Compared to option-A solution, 132 option-B solution has more scalability. But using option-B, ASBRs 133 need to maintain and distribute all VPN prefixes. In the data plane, 134 ASBRs need to perform MPLS VPN Label switching. Because MPLS VPN 135 Label switching table space on ASBRs is limited, it still has 136 scalability limitation for large VPN network. Option-C solution is a 137 most scalable option through separating VPNv4 and PE prefixes 138 exchange, the ASBRs don't need to maintain and distribute the 139 customers VPN prefixes. The ASBR is only used to exchange the 140 service provider(SP) internal IP. 142 This draft is to propose inter-as option-C solution between NVO3 143 network and external BGP MPLS/IP VPN network. Compared to the 144 traditional option-C solution defined in [RFC4364], it is for 145 heterogeneous network interconnection, the control plane and data 146 plane procedures in NVO3 network should be newly specified. 148 2. Conventions used in this document 150 Network Virtualization Edge (NVE) - An NVE is the network entity that 151 sits at the edge of an underlay network and implements network 152 virtualization functions. 154 Tenant System - A physical or virtual system that can play the role 155 of a host, or a forwarding element such as a router, switch, 156 firewall, etc. It belongs to a single tenant and connects to one or 157 more VNs of that tenant. 159 VNID - Virtual Network Identifier (for VxLAN) 161 VSID - Virtual Subnet Identifier (for NVGRE) 163 RD - Route Distinguisher. RDs are used to maintain uniqueness among 164 identical routes in different VRFs, The route distinguisher is an 8- 165 octet field prefixed to the customer's IP address. The resulting 12- 166 octet field is a unique "VPN-IPv4" address. 168 RT - Route targets. It is used to control the import and export of 169 routes between different VRFs. 171 3. Reference model 173 +---------------------------------------------------+ 174 | +----+ AS1 | 175 | | TS1| - | 176 | +----+ - | 177 | - +----+ +----+ | 178 | - |NVE1| -- |TOR1|---------------+ | 179 | +----+ - +----+ +----+ | | 180 | | TS2|- | | 181 | +----+ | | 182 | +-------+ | 183 | +------------ | ASBR-d|-|--| 184 | +----+ | +-------+ | | 185 | | TS3| - | | | 186 | +----+ - | | | 187 | - +----+ +----+ | | 188 | - |NVE2| -- |TOR2| | | 189 | +----+ - +----+ +----+ | | 190 | | TS4|- | | 191 | +----+ | | 192 ----------------------------------------------------| | 193 | 194 |---------------------------------------------------| | 195 | AS2 | | 196 | +----+ | | 197 | | CE1| - | | 198 | +----+ - | | 199 | - +----+ +-------+ | | 200 | - | PE1| --------------------| ASBR-w|-|--| 201 | +----+ - +----+ +-------+ | 202 | | CE2|- | 203 | +----+ | 204 |---------------------------------------------------| 205 Figure 1 Reference model 207 Figure 1 shows an arbitrary Multi-AS VPN interconnectivity scenario 208 between NVO3 network and BGP MPLS/IP VPN network. NVE1, NVE2, and 209 ASBR-d forms NVO3 overlay network in internal DC. TS1 and TS2 210 connect to NVE1, TS3 and TS4 connect to NVE2. PE1 and ASBR-w forms 211 MPLS IP/VPN network in external DC. CE1 and CE2 connect to PE1. The 212 NVO3 network is in AS 1, the MPLS/IP VPN network is in AS 2. 214 There are two tenants in NVO3 network, TSs in tenant 1 can freely 215 communicate with CEs in VPN-Red, TSs in tenant 2 can freely 216 communicate with CEs in VPN-Green. TS1 and TS3 belong to tenant 1, 217 TS2 and TS4 belong to tenant 2. CE1 belongs to VPN-Red, CE2 belongs 218 to VPN-Green. VNID 10 and VNID 20 are used to identify tenant1 and 219 tenant2 respectively. PE1 assigned MPLS VPN Label 1000 and 2000 for 220 the routes from CE1 and CE2 respectively. 222 4. Traditional Option-C [RFC4364] Recap 224 In traditional Option-C defined in [RFC4364], an MP-EBGP session 225 between the end PEs in source and destination ASs is used for the 226 redistribution of VPN-IPv4 routes. Labeled IPv4 routes are 227 redistributed by EBGP between neighboring autonomous systems , 228 inter-AS Option-C uses BGP as the label distribution protocol. 229 Through this solution, VPN connectivity is maintained while keeping 230 VPN-IPv4 routes out of the ASBRs, an ASBR only need maintain labeled 231 IPv4/32 routes to the PE routers within its AS. If the /32 routes 232 for the PE routers are NOT made known to the P routers(other than 233 the ASBRs), then a packet's ingress PE need to put a three-label 234 stack on it. The bottom label is assigned by the egress PE, 235 corresponding to the packet's destination address in a particular 236 VRF. The middle label is assigned by the ASBR, corresponding to the 237 /32 route to the egress PE. The top label is assigned by the 238 ingress PE's IGP Next Hop, corresponding to the /32 route to the 239 ASBR. 241 5. Inter-As Option-C Solution 243 Each NVE operates as default layer 3 gateway to connect locally 244 attached TS(s). VRFs are created on each NVE to isolate IP data 245 plane forwarding table between various attached tenants. The 246 VNID(or VSID and MPLS Label) is used as Tenant identification . 248 Similar to traditional Option-C defined in [RFC4364], an end to end 249 tunnel path from NVE to PE as transport layer should be established 250 through EBGPs (ASBR-ASBR) and two IBGPs in local DCs (between ASBR- 251 PE and ASBR-NVE), and MP-BGP will be established over the tunnel so 252 that VPN-IPv4 routes can be exchanged between the NVE and PE without 253 AS awareness. Unlike traditional Option-C BGP label switched path, 254 the tunnel path has two segments, one segment is the NVO3 tunnel 255 from NVE to ASBR-d in NVO3 network, another segment is traditional 256 BGP LSP from ASBR-d to PE in WAN network, the two segments should be 257 stitched together at ASBR-d as per recommended implementation. The 258 behavior on ASBR-w and PEs in MPLS VPN network has no implementation 259 differences compared to the behavior of ASBR and PEs in traditional 260 RFC4364 based MPLS VPN Option-C network. 262 5.1. EBGP process for transport layer stitching 264 This section will describe the EBGP procedures for the transport 265 layer forwarding path stitching. 267 In WAN to DC direction, when ASBR-d receives labeled IPv4/32 routes 268 from ASBR-w, one of the several allocation methods can be used for 269 tunnel stitching among them few are IP, UDP port and GRE key 270 allocation method . The method chosen by operator depends on the 271 data center network type and the network scale. For the UDP based 272 network of VXLAN [RFC7348] and MPLS In UDP [RFC7510], either IP 273 allocation method or UDP port allocation method can be used. UDP 274 port allocation should be within UDP ephemeral port range and one 275 UDP port maps to a label. For NVGRE network, only IP allocation 276 method can be used. For MPLS Over GRE network, either IP allocation 277 method or GRE key allocation method can be used. 279 In DC to WAN direction, the transport layer stitching solution is 280 same for all kinds of NVO3 network. In this solution, ASBR-d 281 announces labeled IPv4/32 routes to ASBR-w for each NVE where unique 282 MPLS Label is allocated. . The allocated MPLS Label and NVE IP 283 address mapping forms incoming forwarding table which is used to 284 stitch BGP LSP and NVO3 tunnel for inbound traffic forwarding, i.e., 285 from external DC to internal DC. 287 5.1.1. UDP based overlay network 289 Both VXLAN and MPLS In UDP are UDP based encapsulations. For the 290 outbound traffic from NVE to ASBR-d, there are two options at ASBR-d, 291 i.e., the ASBR-d only accepts the traffic with standard destination 292 UDP port(4789 for VXLAN [RFC7348], 6635 for MPLS In UDP [RFC7510]) 293 or non-standardized destination UDP port in outer UDP header 294 encapsulation. 296 In WAN to DC direction, if standard destination UDP port solution is 297 used, when ASBR-d receives labeled IPv4/32 routes from ASBR-w, IP 298 address allocation method should be used. The ASBR allocates an IP 299 address per MPLS Label specified for a particular route defined in 300 [RFC3107] to identify each remote PE, and then advertises the 301 IPv4/32 route(indicating remote PE reachability) to all local NVEs 302 with the VXLAN or MPLS In UDP tunnel attribute. [TUNNELENCAP] 303 defines the relevant TLVs and sub-TLVs for the Tunnel Encapsulation 304 Attribute. The local NVEs will encapsulate transport layer header 305 using the Tunnel Encapsulation Attribute for the outbound traffic 306 from internal DC to external DC, the ASBR-d generated IP is the 307 destination IP in NVO3 tunnel outer header, the UDP port is the 308 standard well-known port for VXLAN and MPLS In UDP. The IP pool 309 should be configured beforehand on ASBR-d. The new allocated IP and 310 MPLS Label mapping forms outgoing forwarding table on ASBR-d which 311 is used to stitch NVO3 tunnel and BGP LSP for outbound traffic 312 forwarding . If non-standard destination UDP port is used, ASBR-d 313 can allocate the combination of IP and UDP port(or only UDP port) 314 per MPLS Label to identify each remote PE, and then advertises the 315 IPv4/32 route received from ASBR-w to all local NVEs with the Tunnel 316 Encapsulation Attribute. For each NVE, the destination IP and the 317 destination port in NVO3 tunnel outer header is the new allocated IP 318 and the new allocated port respectively. The new allocated IP and 319 UDP port combination (or only UDP port) and MPLS Label mapping 320 forms outgoing forwarding table on ASBR-d. This method is called UDP 321 allocation method, the allocated UDP port range should be configured 322 beforehand on ASBR-d. 324 In summary, IP allocation method has more IP address consumption 325 than the UDP allocation method. If there is large number of remote 326 PEs in WAN network, the UDP allocation method is suggested to be 327 used to enhance network scalability. 329 5.1.2. GRE based overlay network 331 Both NVGRE and MPLS Over GRE are GRE based encapsulations. The GRE 332 key field can be used to convey application-specific key value. In 333 NVGRE, the key field has been used to convey 24-bit Virtual Subnet 334 Identifier (VSID) as tenant identification, so for NVGRE, the GRE 335 key field can't be used for the stitching purpose and only IP 336 allocation method can be used. In MPLS Over GRE, the GRE key field 337 has not been used explicitly by an application and can be used for 338 the transport layer stitching at ASBR-d, i.e., GRE key allocation 339 method can be used to conserve IP address space. 341 In WAN to DC direction, for MPLS Over GRE, when ASBR-d receives 342 labeled IPv4/32 routes from ASBR-w, the ASBR can allocate a GRE key 343 per MPLS Label to identify each remote PE, and then advertises the 344 IPv4/32 route to all local NVEs with the Tunnel Encapsulation 345 Attribute. The new allocated GRE key and MPLS Label correspondence 346 forms outgoing forwarding table on ASBR-d. This method is called GRE 347 key allocation method. 349 If ASBR-d needs to change IP address, UDP port or GRE key for a 350 particular /32 route, it should advertising a new route with the 351 same NLRI and a new Tunnel Encapsulation Attribute to refresh all 352 NVEs's local information. 354 5.2. VPN routes exchange 356 Each NVE and remote PE should establish MP-EBGP session for the 357 announcement of VPN-IPv4 routes through RFC4364. Route 358 distinguishers (RD) and RT are specified for each VRF on each NVE 359 and PE. 361 Each NVE advertises all local VPN route to remote PEs using tenant 362 identification VNID (or VSID and MPLS Label) as MPLS VPN Label. 363 These remote PEs deal with the NVE as regular PE, they match RT and 364 populates these VPN route to local VRF. For the traffic from remote 365 CE to local TS, ingress PE uses the VNID as bottom label in MPLS 366 encapsulation. Because VNID field is 24 bits, to ensure these NVEs 367 and PEs interworking, VNID length should not be beyond 20 bits, i.e., 368 VNID value must not be larger than 1 Million. In proposed 369 implementation NVO3 network the VNID space should be partitioned, 370 only the VNIDs of lower 1 Million can be used for interconnection 371 with outer MPLS VPN network, the rest 15 Million VNIDs can only be 372 used for intra DC. 374 Each MPLS VPN PE also advertises all local VPN route to peer NVEs, 375 these NVEs match RT and populates these VPN route to local VRF. For 376 the traffic from local TS to remote CE, because ingress NVE doesn't 377 support MPLS encapsulation, it encoded the MPLS VPN Label advertised 378 from remote PE as VNID in NVO3 encapsulation. 380 5.3. Data forwarding process 382 When VXLAN network and UDP port allocation method are used in data 383 center, the procedures of data forwarding between TS1 and CE1 in 384 figure 1 will be described step by step as follows. 386 5.3.1. Data flow from TS1 to CE1 388 1. TS1 sends a packet to NVE1, destination IP is CE1's IP. 390 2. NVE1 acquires local VRF relying on packet input interface, then 391 looks up the VRF's routing table corresponding to tenant 1, 392 performs NVO3 encapsulation, and sends the encapsulated packet 393 out to ASBR-d. The MPLS VPN Label associated with the packet's 394 destination address is encoded in VNID field. VXLAN tunnel 395 destination IP and destination UDP port are the IP address and 396 UDP port allocated on ASBR-d associated with the /32 routes for 397 the remote PE routers that the remote CE attached to. 399 3. ASBR-d decapsulates the VXLAN received packet and performs MPLS 400 encapsulation. Two Labels should be pushed in the MPLS 401 encapsulation, BGP LSP Label as top Label and MPLS VPN Label as 402 bottom Label. BGP LSP Label is acquired by looking up outgoing 403 stitching table, MPLS VPN Label is copied from VNID. 405 4. ASBR-w swaps BGP MPLS Label, and push IGP Label and sends the 406 packet out to PE1. MPLS VPN Label remains unchanged. 408 5. PE1 pops all MPLS Label, finds local VRF relying on bottom MPLS 409 VPN Label, performs looks up in local VRF IP forwarding table , 410 and then sends the packet out to CE1. 412 5.3.2. Data flow from CE1 to TS1 414 1. CE1 sends a packet to PE1, destination IP is TS1's IP. 416 2. PE1 acquires local VRF interface relying on packet input 417 interface where CE1 egress out the packet, then launches a lookup 418 in VRF's routing table. It pushes three-label stack on the 419 outgoing packet. The bottom label is the tenant VNID corresponds 420 to TS1, the VNID is 10. The middle label is assigned by the ASBR- 421 w, associating with the /32 route for the egress NVE1. The top 422 label is assigned by the ingress PE's IGP Next Hop, corresponding 423 to the /32 route to ASBR-w. 425 3. ASBR-w pops top IGP Label, swaps middle BGP Label, and then sends 426 the packet out to ASBR-d. 428 4. ASBR-d decapsulates MPL packet, performs VXLAN encapsulation and 429 then sends the packet to egress NVE1. The egress NVE's IP address 430 is acquired by performing a looking up in the stitching table, 431 VNID is copied from the bottom MPLS VPN Label. 433 5. NVE1 decapsulates incoming NVO3 encapsulated packet, looks up 434 local VRF interface based on VNID, then performs a look up in the 435 routing table and forwards the packet out to destination TS1. 437 6. NVE-NVA architecture 439 In this architecture, the NVE control plane and forwarding 440 functionality are decoupled. All NVEs in NVO3 network don't need to 441 support BGP protocol; these NVEs have only data plane functionality 442 and are controlled by centralized NVA using openflow, ovsdb, i2rs, 443 etc. The NVA runs BGP with ASBR-d to exchange plain IP route to 444 IPv4/32 of each WAN PE associated with the BGP tunnel encapsulation 445 attribute. The NVA also runs MP-BGP protocol [RFC4364] with peer PE 446 for all the NVEs to exchange VPNv4 route, VNID is used as MPLS VPN 447 Label. ASBR-d can choose IP allocation, UDP allocation or GRE key 448 allocation method for the transport stitching. 450 NVA maintains all tenant information, and originates BGP routes with 451 the appropriate RD and RT. The NVA tenant information includes 452 VNID(or VSID and MPLS Label) to identify each tenant and the 453 corresponding RD and RT. This information can be statically 454 configured by operators or dynamically allocated. This information 455 also includes all TS's MAC/IP address and its attached NVE 456 information. 458 6.1. EBGP process for transport layer stitching 460 DC to WAN direction: 462 1. ASBR-d allocates BGP MPLS Label per NVE. 464 2. ASBR-d advertises BGP Label routing information to peer ASBR-w. 465 ASBR-d generates incoming stitching table . 468 WAN to DC direction: 470 1. ASBR-d receives BGP Label routing information from peer ASBR-w. 472 2. ASBR-d allocates NVO3 Tunnel IP, UDP port or GRE key for each 473 MPLS Label received from ASBR-w, the ASBR-d announces the IPv4/32 474 Route to NVA with the Tunnel Encapsulation Attribute. 476 3. ASBR-d generates outgoing stitching table. 479 6.2. VPN route exchange 481 NVA advertises all internal data center tenant routing information 482 to remote PEs using RFC 4364, which includes RD, RT, IP prefix, 483 and MPLS VPN Label, the tenant identification of VNID is used as 484 MPLS VPN Label. 486 Each remote MPLS VPN PE also advertises local VPN routes to NVA. 487 NVA acquires NVO3 Tunnel IP(or UDP port and GRE key) allocated by 488 ASBR-d corresponding to the PE, matches RT attribute and populates 489 the VPN routes to local VRF. 491 Then the NVA downloads corresponding VPN forwarding table 492 including to each NVE. 495 VPN route exchange 496 ------------------------------------------------- 497 | | 498 ------ IBGP -------- EBGP -------- ----- 499 |NVA | -----|ASBR-d |-------- |ASBR-w |--------|PE | 500 ------ -------- -------- ----- 501 . 502 . Southbound interface(Openflow,OVSDB,I2RS,etc) 503 ............ 504 . . 505 . . 506 . . 507 ------ ------ 508 |NVE1| |NVE2| 509 ------ ------ 510 Figure 2 NVE-NVA Architecture 512 7. Security Considerations 514 Internal IP (Loopback IP for PE/NVE) addresses a network is 515 advertised and visible in another network, which is a security risk. 516 Most operators wants to prevent any external visibility and access 517 into their internal devices IP. option C is suggested to be deployed 518 within a single SP or enterprise with both MPLS and NVO3 networks. 520 8. IANA Considerations 522 NA. 524 9. References 526 9.1. Normative References 528 [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, March 1997. 532 [2] [RFC4364] E. Rosen, Y. Rekhter, " BGP/MPLS IP Virtual Private 533 Networks (VPNs)", RFC 4364, February 2006. 535 [3] [RFC3107] Y. Rekhter,E. Rosen, ''Carrying Label Information in 536 BGP-4'', RFC 3107, May 2001 538 9.2. Informative References 540 [1] [NVA] D.Black, etc, "An Architecture for Overlay Networks 541 (NVO3)", draft-ietf-nvo3-arch-01, February 14, 2014 543 [2] [RFC7047] B. Pfaff, B. Davie,''The Open vSwitch Database 544 Management Protocol'', RFC 7047, December 2013 546 [3] [OpenFlow1.3]OpenFlow Switch Specification Version 1.3.0 (Wire 547 Protocol 0x04). June 25, 2012. 548 (https://www.opennetworking.org/images/stories/downloads/sdn- 549 resources/onf-specifications/openflow/openflow-spec-v1.3.0.pdf) 551 [4] [RFC7348] M. Mahalingam, etc, "Virtual eXtensible Local Area 552 Network (VXLAN): A Framework for Overlaying Virtualized Layer 553 2 Networks over Layer 3 Networks", RFC7348, August 2014. 555 [5] [NVGRE] P. Garg, etc, "NVGRE: Network Virtualization using 556 Generic Routing Encapsulation", draft-sridharan- 557 virtualization-nvgre-08, April 13, 2015. 559 [6] [TUNNELENCAP] E. Rosen, etc, "Using the BGP Tunnel 560 Encapsulation Attribute without the BGP Encapsulation SAFI", 561 draft-rosen-idr-tunnel-encaps-00, June, 2015. 563 10. Acknowledgments 565 Authors like to thank Thomas Morin, Shunwan Zhuang, Haibo Wang, Jie 566 Dong for their valuable inputs. 568 Authors' Addresses 570 Weiguo Hao 571 Huawei Technologies 572 101 Software Avenue, 573 Nanjing 210012 574 China 575 Phone: +86-25-56623144 576 Email: haoweiguo@huawei.com 577 Lucy Yong 578 Huawei Technologies 579 Phone: +1-918-808-1918 580 Email: lucy.yong@huawei.com 582 Susan Hares 583 Huawei Technologies 584 Phone: +1-734-604-0323 585 Email: shares@ndzh.com. 587 Osama Zia 588 Microsoft 589 Email: osamaz@microsoft.com 591 Muhammad Durrani 592 Cisco 593 Phone: +1-408-527-6921 594 Email: mdurrani@cisco.com