Network Working Group L. Jin Internet-Draft ZTE Intended status: Standards Track B. Khasnabish Expires: June 16, 2013 ZTE USA, Inc. December 13, 2012 Virtualized Integrated Routing & Bridging with centralized control plane draft-jin-nvo3-virb-centralized-00.txt Abstract The network in datacenter is required to provide a tenant network, which should be virtualized, and be able to provide L2 switching or L3 routing capability. A combined L2&L3 solution could provide great scalability for both Layer2 and Layer3 switching. In this document, we propose to apply centralized server to be the control plane of the combined L2&L3 solution, to provide better scalability for the control plane. The combined L2&L3 solution in this draft is named Virtualized Integrated Routing&Bridging (shorted as VIRB). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 16, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Jin, et al. Expires June 16, 2013 [Page 1] Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3 1.2. General terminology . . . . . . . . . . . . . . . . . . . 4 2. VIRB model on NVE . . . . . . . . . . . . . . . . . . . . . . 4 3. VIRB Dataplane Format . . . . . . . . . . . . . . . . . . . . 5 4. Control Plane with Centralized Server . . . . . . . . . . . . 5 4.1. Layer2 information distribution . . . . . . . . . . . . . 6 4.2. Layer3 information distribution . . . . . . . . . . . . . 7 4.3. Gateway selection for L2VNI . . . . . . . . . . . . . . . 7 4.4. Designated Virtual Routing Instance Selection for Multicast . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Interoperating with MPLS Layer3/2 VPN . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Jin, et al. Expires June 16, 2013 [Page 2] Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012 1. Introduction The network in datacenter is required to provide a tenant network, which should be virtualized, and be able to provide L2 switching or L3 routing capability. Within one tenant, there is case the customer requires on bridge domain, and there is also case that the customer requires multiple bridge domains separated by customer VLAN. Then the virtualized network or tenant network provided by NVO3 should have at least following capability: 1. Provide traffic segregation between different virtualized network. 2. Provide multiple bridge domains within one tenant by customer VLAN. 3. Provide Layer2 traffic segregation between different bridge domain within one tenant. 4. Provide Layer3 routing between different bridge domain within one tenant. 5. Provide seamless interconnection between the virtualized network and already defined L2VPN, e.g, BGP/LDP-based VPLS, E-VPN. 6. Provide seamless interconnection between the virtualized network and already defined L3VPN, e.g, BGP MPLS VPN. [I-D.sajassi-l2vpn-evpn-ipvpn-interop] proposes an E-VPN based combined L2&L3 solution, named IRB, to address the shortcomings of L2-only as well as L3-only solutions, and provide optimum forwarding for both inter and intra subnet switching. In this document, we propose to apply centralized server to be the control plane of the combined L2&L3 solution. The combined L2&L3 solution in this draft is named Virtualized Integrated Routing& Bridging (shorted as VIRB). 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation Jin, et al. Expires June 16, 2013 [Page 3] Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012 only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 1.2. General terminology The terminology defined in [I-D.ietf-nvo3-framework] is used throughout this document. Terminology specific to this memo is defined here and is introduced as needed in later sections. VIRB: Virtualized Integrated Routing and Bridging 2. VIRB model on NVE VIRB will provide both virtualized Routing and Bridging in one virtual instance, and the dataplane behavior is similar with a Layer3 switch box or IRB(Integrated Routing and Bridging). The functional model of VIRB will be like below: | | Tunnel Overlay +------------------------------|----------------------------+ | +------------------------+----------------------+ | | | Overlay Modual | | | +-.-------------.---------------.-------------.-+ | | /--|-------------|--\ /--|-------------|--\ | | | | +---------+ | | | | +---------+ | | | | | | | Routing | | | | | | Routing | | | | | | | +-.-----.-+ | | | | +-.-----.-+ | | | | | | | | | | | | | | | | | | | +-----+ +-----+ | | +-----+ +-----+ | | | | | BD | | BD | | | | BD | | BD | | | | | +-----+ +-----+ | | +-----+ +-----+ | | | | |VIRB Instance| | | |VIRB Instance| | | | \--|-------------|--/ \--|-------------|--/ | +-------|-------------|---------------|-------------|-------+ | VAPs | | VAPs | ---------+-------------+---------------+-------------+--------- | | | | Tenant Systems Tenant Systems Figure 1 One tenant will include a Layer2 instance and Layer3 instance. The Layer2 instance will include multiple bridge domain. The virtual routing module is responsible for IP forwarding for VIRB instance, Jin, et al. Expires June 16, 2013 [Page 4] Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012 while virtual bridge module is responsible for MAC based forwarding within one VLAN. One VIRB instance could contain only one virtual routing module and multiple virtual bridges, each of which is separated by VLAN. Both the virtual routing and virtual bridge has interface to the overlay module. Each virtual bridge module has a virtual interface to virtual routing module, and every IP subnet is associated with this virtual interface. Within every tenant, the virtual bridge and corresponding bridge domain is uniquely identified by VLAN ID, while different tenants could have duplicated VLAN ID to identify the bridge domain. When a frame received by an ingress NVE from tenant system, it needs to be parsed in order to identify which VIRB instance it belongs to. The parsing function can examine various fields in the data frame (e.g., Service Delimiting VLAN-ID) and/or associated interface/port the frame came from. Once the VIRB instance is identified, the customer VLAN-ID+MAC should be used to do Layer2 forwarding. If the customer VLAN-ID does not exist, a default VLAN-ID configured locally could be used instead. The frame with destination MAC address owned by virtual routing instance should be subjected to do Layer 3 forwarding by virtual routing module. 3. VIRB Dataplane Format The general format of the VIRB protocol layering model is same as the format defined for L2VNI and L3VNI in [I-D.bl-nvo3-dataplane-requirements]. One VIRB instances include a Layer2 instance and a Layer3 instance. In order to be fully compatible with existing MPLS Layer3/2 VPN, this document suggests using MPLS label as both the L2/L3 encapsulation indicator and VNID. Different bridge domains within one tenant are identified by the VLAN ID, while the Layer2 and Layer3 instance is identified by the MPLS label. Other format of VNID for VIRB will be studied in furture version 4. Control Plane with Centralized Server Due to the requirement described in [I-D.kreeger-nvo3-overlay-cp]section 4, it is high cost for every NVE to accommodate the whole forwarding table, including MAC forwarding table for virtual bridge module and IP forwarding table for virtual routing module. We propose to use centralized server to control the MAC forwarding Jin, et al. Expires June 16, 2013 [Page 5] Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012 table and IP forwarding table. The framework would be shown in following figure. This document only specifies the interaction specification between NVE and centralized server. How the centralized server is organized or implemented is out of the scope of this draft. Every NVE will learn the local VAP, VM/Host MAC address, VLAN and IP address, by e.g, snooping ARP packets, or by Server-NVE protocol, or by getting information from virtualization software if NVE resides on hypervisor. And then NVE SHOULD send the learned MAC, VLAN, IP address and VNI to the centralized server. The centralized server SHOULD generate the Layer2 MAC information, and Layer3 IP information. And these information would be advertised to other NVE and centralized servers. The signaling session between NVE and centralized server could be OpenFlow or XMPP which has already been supported on Linux package, and would specified in future version of this draft. 4.1. Layer2 information distribution Each bridge domain within one tenant is identified by the VLAN unique within tenant, and the Layer2 MAC forwarding information should include at least the following: 1. VM/Host MAC address 2. VLAN ID 3. MPLS label for Layer2 4. VIRB ID for control plane 5. NVE Address The Layer2 MAC information SHOULD be distributed by centralized server to other NVE or other centralized server. The NVE receiving the Layer2 MAC information should import this information only to the bridge domain with same VLAN ID and VIRB ID. The MAC forwarding table generated by the centralized server would be following: 1. Forwarding entry for Packet to local VAP: 2. Forwarding entry for Packet to remote NVE: Jin, et al. Expires June 16, 2013 [Page 6] Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012 4.2. Layer3 information distribution Before generating the Layer3 IP information, the IP address SHOULD be summarized within one VLAN one tenant if possible for each NVE. The Layer3 IP information should include at least the following: 1. IP Prefix (summarized from VM/Host IP address) 2. MPLS label for Layer 3 3. VIRB ID for control plane 4. NVE Address 5. Node Priority The node priority is used for gateway selection for unicast traffic and designated virtual routing instance selection for multicast traffic, see details in section 4.3 and 4.4. Note that the IP prefix on virtual interface between virtual routing and bridge instance should not be advertised. The Layer3 IP information SHOULD be distributed by centralized server to other NVE or other centralized server. The NVE receiving the Layer3 IP information should import this information only to the virtual routing instance with same VIRB ID. The IP routing table generated by the centralized server would be following: 1. Forwarding entry for Packet to bridge domain: 2. Forwarding entry for Packet to remote NVE: Note that, the VIRB ID for control plane in Layer2 and Layer3 information MUST be the same, and this value is only used for control plane to identify each VIRB instance. 4.3. Gateway selection for L2VNI In the virtual network with both VIRB instance and L2-only Virtual Network Instance (short for L2VNI), the NVE in L2VNI should find the best virtual routing instance as a gateway. The centralized server has all the IP address information of the VM/Host attached to VIRB or L2VNI, then the gateway selection for L2VNI should consider the following factors: Jin, et al. Expires June 16, 2013 [Page 7] Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012 1. IP address summarization: virtual routing instance which has the maximum capability to summarize the IP address from L2VNI should be selected as the gateway. 2. Processing load: the virtual routing instance on the NVE which has lower processing load should be selected as the gateway. Different bridge domain could have different gateway, so as to achieve load balance. 3. Path cost: the virtual routing instance nearest to the L2VNI should be selected as the gateway. 4. Priority: the virtual routing instance with high priority should be selected as the gateway. The specific gateway selection mechanism is a local policy on the centralized server, and is not specified in this draft. 4.4. Designated Virtual Routing Instance Selection for Multicast The multicast traffic within one bridge domain should be distributed through the Layer2 overlay. Then there should be a designated virtual routing instance to be selected from the routing instances within one bridge domain. The selection of designated virtual routing instance should be performed by centralized server in following steps: 1. Discover the virtual routing instance within the same bridge domain, by checking if these virtual routing instances have been attached with same VLAN. 2. Discover the virtual routing instance where its attached local bridge domain is requested to join the same multicast group. 3. Select the designated virtual routing instance which is nearest to multicast source. Note that the assumption here is the centralized server has the cost information among the NVEs. 4. Select the designated virtual routing instance by the priority and NVE address. The centralized server could apply pull or push or combined pull and push to send the forwarding table to each NVE. This depends on the NVE forwarding memory capability. Jin, et al. Expires June 16, 2013 [Page 8] Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012 5. Interoperating with MPLS Layer3/2 VPN The seamless interoperability with MPLS Layer3/2 VPN has been described in [I-D.sajassi-l2vpn-evpn-ipvpn-interop] section 2. In this section, we will only describe the specific behavior of centralized server for the seamless interoperability. The signaling session between centralized server and MPLS Layer3/2 VPN PE MUST be MP-BGP session, and the centralized server SHOULD support the signaling function of MPLS Layer3/2 VPN. The centralized server SHOULD learn the L3VPN IP forwarding information through MP-BGP session. The routing information received from L3VPN PE will also be advertised to each VIRB instance, and then corresponding IP routing entry will be generated on virtual routing module. The centralized server SHOULD learn the Layer2 MAC forwarding information from L2VPN through MP-BGP session. And the Layer2 MAC forwarding information received should be imported to a bridge domain, and which is assigned by a locally designated VLAN. The MAC information from L2VPN PE will be also advertised to each VIRB instance, and imported to the corresponding bridge domain. 6. Security Considerations Will be added in future. 7. IANA Considerations Will be added in future. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.bl-nvo3-dataplane-requirements] Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L., and B. Khasnabish, "NVO3 Data Plane Requirements", draft-bl-nvo3-dataplane-requirements-03 (work in Jin, et al. Expires June 16, 2013 [Page 9] Internet-Draft draft-jin-nvo3-virb-centralized-00 December 2012 progress), November 2012. [I-D.ietf-nvo3-framework] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for DC Network Virtualization", draft-ietf-nvo3-framework-01 (work in progress), October 2012. [I-D.kreeger-nvo3-overlay-cp] Kreeger, L., Dutt, D., Narten, T., and M. Sridharan, "Network Virtualization Overlay Control Protocol Requirements", draft-kreeger-nvo3-overlay-cp-02 (work in progress), October 2012. [I-D.sajassi-l2vpn-evpn-ipvpn-interop] Sajassi, A., Salam, S., Patel, K., Bitar, N., and A. Isaac, "E-VPN Seamless Interoperability with IP-VPN", draft-sajassi-l2vpn-evpn-ipvpn-interop-01 (work in progress), October 2012. Authors' Addresses Lizhong Jin ZTE 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn, lizho.jin@gmail.com Bhumip Khasnabish ZTE USA, Inc. 55 Madison Avenue, Suite 160 Morristown, NJ 07960 USA Email: bhumip.khasnabish@zteusa.com, vumip1@gmail.com Jin, et al. Expires June 16, 2013 [Page 10]