Cloud Networking: Framework and VPN Applicability draft-bitar-nvo3-vpn-applicability-00.txt

1. Cloud Networking: Framework and VPN Applicabilitydraft-bitar-nvo3-vpn-applicability-00.txt Nabil Bitar (Verizon) Florin Balus, Marc Lasserre, and Wim Henderickx (Alcatel-Lucent) Ali Sajassi and Luyuan Fang (Cisco) Yuichi Ikejiri(NTT Communications) Mircea Pisica(BT)

2. Scope • Applicability of existing and evolving Ethernet, L2VPN, and L3VPN technologies to multi-tenant cloud networking and tradeoffs: • Addressing requirements for large scale multi-tenant data centers and cloud-networks • Intra-Data Center networks • Inter-data center connectivity • Data centers can belong to the same data center service provider, different data center providers, the tenant, and any hybrid • Tenant vpn and public access to data centers • Scenarios– cloud networks • Challenges/Gaps that still require work

3. Typical Cloud Networking Architecture • DC GW – gateway to the outside world providing DC Interconnect and connectivity to Internet and VPN customers. • Core Switch/Router – high capacity core node, usually a cost effective Ethernet switch; may support routing capabilities. • ToR or Top of Rack – hardware-based Ethernet switch; may perform IP routing. • VSw or virtual switch – software based Ethernet switch running inside the server blades Customers with Application Requirements DC DC VPN PEs/xGW IP/MPLS Network DC GW Core Multi-tenant Data Center VM VM ToR VSw Storage LB NAT FW VMs on Server Blades VM-based Appliances

4. VPN applicability to Cloud Networking • Layer 3 option • BGP/MPLS IP VPN • Layer 2 options • VLANs and L2VPN toolset • PBB and L2VPN toolset • TRILL and L2VPN toolset

5. BGP/MPLS IP VPN Applicability to Cloud Networking • Use full fledge IP VPN for L3 Virtualization inside a DC • IP VPN advantages • Interoperates with existing WAN VPN technology • Deployment tested, provides a full networking toolset • Scalable core routing – only one BGP-MP routing instance is required compared with one per customer/tenant in the Virtual Routing case • Service Auto-discovery - automatic discovery and route distribution between related service instances • Well defined and deployed Inter-Provider/Inter-AS models • Supports a variety of VRF-to-VRF tunneling options accommodating different operational models: MPLS [RFC4364], IP or GRE [RFC4797] • Connectivity models for customer IP VPN instances located in the WAN • DC GW may participate directly in the WAN IP VPN • Inter-AS Options A, B or C - applicability to both Intra and Inter-Provider use cases • Integrated routing and bridging provides for L2 and L3 services – bridge in same bridging domain & route across LAN segments for same tenant

6. 802.1q + L2VPN applicability to Cloud Networking • 12b VLAN tag used for Tenant identification • Standardized by IEEE – (QoS, OAM, control plane etc…) • Supported in merchant silicon, proven vendor interoperability • Limits the number of services depending on the extent of the VLAN and the location of the L2VPN PE functionality • Very widely deployed • L2VPN (VPLS/E-VPN) provides for emulation of LAN technology over IP/MPLS core and provide for service scale

7. PBB + L2VPN applicability to Cloud Networking • 24b ISID tag vs. 12b VLAN tag used for Tenant identification • Expands L2 domains from 4K VLANs to 16M ISIDs • Standardized in 2008 by IEEE – inherits current and future IEEE specs (QoS, OAM, control plane etc…) • Supported in merchant silicon, proven vendor interoperability • Deployed in a number of large service provider networks • L2VPN (PBB-VPLS/PBB-E-VPN) provides for PBB transport over IP/MPLS core and provide for service scale

8. NV03 – VPLS Functional Mapping

9. NV03 – IP VPN Functional Mapping

10. NV03 – E-VPN Functional Mapping

11. Other work in progress • VM Mobility and Optimal traffic forwarding based on E-VPN, BGP/MPLS IP VPN and IP routing – see draft-rekhter-vm-mobility-solutions • Request by authors to integrate into the vpn applicability draft • ARP suppression discussed in PBB-EVPN (draft-ietf-l2vpn-pbb-evpn) and EVPN (draft-ietf-l2vpn-evpn) • End-system support for BGP-signaled IP/VPNs, “draft-marques-l3vpn-end-system-02” • Handling ARP scale – armd drafts

12. Gaps/Considerations • Auto-discovery and dynamic network service instantiation end-to-end as a result of VM instantiation or move • Current VPN models do not address this requirement • New protocols/mechanisms • NVE Location and existing solutions’ practical applicability – scalability/complexity • Differences between the NVE being on the server vs. hardware appliance. It maybe argued as being an implementation issue but needs to be considered • Depending on the requirements, this may require new protocol(s) – gap • NVI: • Size: number of service instances supported – L2VPN and L3VPN practically do not limit the number of services supported • Globality of the identifier vs. locality for tenant and service identification and any Implication of mobility – consideration • Traffic path optimization and traffic loss minimization upon VM move – new mechanisms/BCP • New DC protocols (e.g., VXLAN) and interworking with existing WAN technologies (e.g., L2VPN and L3VPN)

13. Next steps • Merge materials from draft-rekhter-vm-mobility-solutions addressing VM mobility with existing solutions • Address private comments from Sue Hares related to ARMD references • Include nvo3-vpn mapping functional mapping tables • Potential re-organization of some sections in the draft • New co-authors • Authors of draft-hy-nvo3-vpn-protocol-gap-analysis will be co-authoring/contribution to this draft and materials will be leveraged/merged as applicable • John Drake