Virtual Subnet : A L3VPN-based Subnet Extension Solution for Cloud Data Center Interconnect

Transcription

1 Virtual Subnet : A L3VPN-based Solution for Cloud Data Center Interconnect draft-xu-virtual-subnet-09 Xiaohu Xu (Huawei) Susan Hares (Huawei) Yongbing Fan (China Telecom) Christian Jacquenet (France Telecom) IETF85, Atlanta

2 Cloud Data Center Interconnect Requirements Subnet extension p To allow VM migration across data centers without renumbering. Forwarding table scalability p Prevent the forwarding table size of DC switches and PEs from growing as the number of data centers to be connected increases. /ND cache table scalability p Avoid /ND cache table size of DC gateways from growing as the number of data centers to be connected increases. Eliminate /ND and unknown unicast impact p Confine the flooding of /ND broadcast/multicast and unknown unicast traffic within data centers. Path optimization p Avoid the traffic between cloud users and cloud data centers from travelling along suboptimal paths.

3 Why VPLS not a Good Choice for DCI Cloud User 3 DC GW needs to store entries of both local and remote CE hosts. VRF: /24 BGP /24 BGP / Direct / Direct PE-3 PE-3 L3VPN PE 5 L3VPN traffic between cloud users and cloud data centers may travel along sub-optimal paths and therefore waste the DCI bandwidth unnecessarily. L3VPN PE (DC GW) L2VPN PE L2VPN PE L3VPN PE (DC GW) 1 DC SW needs to store MAC addresses of both local and remote CE hosts. DC SW CE Host A: /24 2 PE-4 VPLS for DCI VPLS PE needs to store MAC addresses of both local and remote CE hosts. PE-5 4 DC SW CE Host B: /24 DC #1 broadcast and unknown unicast DC #2 would flood across data centers.

4 Virtual Subnet at a Glance: Control Plane VRF: / Direct / Direct /32 BGP / Direct 2 Exchange host routes via L3VPN signaling VRF: / Direct /32 BGP / Direct / Direct 1 Local CE hosts are auto-discovered via or interaction with orchestration system / /24 1 Local CE hosts are auto-discovered via or interaction with orchestration system. Host A: /24 Host B: /24 DC #1 DC #2 Host routes for local CE hosts are created dynamically by PE routers and then propagated to remote PE routers via the existing L3VPN signaling.

5 Virtual Subnet at a Glance: Data Plane 2 Route look-up VRF: / Direct / Direct /32 BGP / Direct 4 Route look-up VRF: / Direct /32 BGP / Direct / Direct 3 IP(A)->IP(B) VPN Label Tunnel to 1 IP(A)->IP(B) VLAN ID MAC(A)->MAC() / /24 5 IP(A)->IP(B) VLAN ID MAC()->MAC(B) Host A: /24 Table: Host B: /24 0 IP IP(B) MAC MAC() DC #1 DC #2 Intra-subnet customer traffic across data centers is forwarded by PE routers in accordance with the current L3VPN forwarding procedures.

6 Scale MAC Tables of DC Switches IP(A)->IP(B) VLAN ID MAC(A)->MAC() DC Switch DC Switch IP(A)->IP(B) VLAN ID MAC()->MAC(B) MAC learning domain #1 Host A Host C Host B Host D MAC learning domain #2 DC #1 DC #2 learn MAC addresses of local CE hosts, but not those of remote CE hosts.

7 Scale FIB Tables of PE Routers VRF FIB: 1 By default, PE as a client only needs to FIB-install host routes for local CE hosts and the subnet routes advertised by RR. VRF FIB: /32 BGP /32 BGP /25 Null /25 Null0 - RR 0 RR advertises multiple more specific subnet routes for the extended subnet to its clients / Direct / Direct /25 RR BGP /25 RR BGP / Direct / /24 Host A: /24 Host B: /24 DC #1 DC #2 PE routers only FIB-install host routes for local CE hosts and the subnet routes advertised by RR while remaining remote host routes still in RIB. requests received from local CE hosts could trigger PE routers to FIB-install the corresponding host routes for the requested CE hosts from RIB.

8 Scale /ND Cache Tables of DC Gateways VPN Subnet: /24 Cloud User Table IP MAC MAC(A) PE-3 Table IP MAC MAC(B) Host A: /24 Host B: /24 DC #1 DC #2 PE routers acting as DC gateways as well only need to learn entries of local CE hosts.

9 Avoid /ND Broadcast/Multicast Flooding across Data Centers 2 IP(B)->MAC() 1 B MAC=? broadcast domain #1 Host A Host C Host B DC #1 DC #2 Host D broadcast domain #2 Due to the use of /ND proxy, /ND broadcast/multicast traffic would not be flooded across data centers.

10 Avoid Unknown Unicast (UU) Flooding across Data Centers UU flood domain #1 Host A Host C Host B Host D UU flood domain #2 DC #1 DC #2 Since PE routers forward customer packets according to the associated VRF, there is no need for unknown unicast flood across data centers anymore.

11 Path Optimization for L3VPN Traffic between Cloud Users and Cloud DC VRF: /32 BGP /32 BGP / Direct / Direct Cloud User PE-3 Host A: /24 Host B: /24 DC #1 DC #2 Host routes for local CE hosts within data centers are propagated to remote PE routers to which cloud users are attached. Therefore, the inbound traffic would be forwarded according to host routes, rather than subnet route.

12 Next Step WG adoption as an informational draft?