NVO3 Working Group Y. Li INTERNET-DRAFT L. Yong Intended Status: Informational Huawei Technologies Expires: January 7, 2016 July 6, 2015 VLAN Configuration Considerations in Split-NVE draft-yizhou-nvo3-vlan-config-in-split-nve-00 Abstract In a Split-NVE structure, a control plane protocol between a hypervisor and its associated external NVE(s) to distribute the virtual machine networking state and the relevant attributes. One of the key attributes to be negotiated is VLAN ID which is the most common locally-significant tag for carrying traffic associated with a specific virtual network. This document provides the informational guides on how to configure the VLAN IDs to local networks in Split- NVE structure. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Li & Yong, et al [Page 1] INTERNET DRAFT VLAN Config Considerations in Split-NVE July 2015 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 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 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2. VLAN ID Configurations . . . . . . . . . . . . . . . . . . . . 5 2.1 VLAN ID per VM . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Private VLAN configuration per VN . . . . . . . . . . . . . 6 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1 Normative References . . . . . . . . . . . . . . . . . . . 7 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Li & Yong, et al [Page 2] INTERNET DRAFT VLAN Config Considerations in Split-NVE July 2015 1. Introduction The problem statement [RFC7364], discusses the needs for a control plane protocol (or protocols) to populate each NVE with the state needed to perform the required functions in Split-NVE scenario. The protocol requirement [I-D.ietf-nvo3-hpvr2nve-cp-req] presents one of the key requirements which allows the negotiation on a locally- significant tag for carrying traffic associated with a specific virtual network. The tag is commonly a VLAN ID [IEEE 802.1Q]. This document uses the term "VLAN ID" or VID to cover the locally- significant tag. Traffic isolation in overlay network is based on virtual network ID. Before the traffic entering the ingress point of the overlay network, isolation is based on VLAN ID. A bridged network may connect end Devices to external NVE. We refer it as indirect connection. Another case is direction connect which means end device directly connects to the external NVE without going through any intermediate device. Figure 1 shows the two connection types in local network. +--------+ +--------+ |+-----+ | |+-----+ | || VM1 | | || VM1 | | |+-----+ | |+-----+ | | |---------+ | |---------+ |+-----+ | | |+-----+ | | || VM2 | | | || VM2 | | | |+-----+ | | |+-----+ | | +--------+ +---------+ +--------+ | End Device 1 | External| End Device 1 +-------+ +---------+ | NVE1 | | Bridge| | External| +--------+ +---------+ +--------+ | B1 |----| NVE1 | |+-----+ | | |+-----+ | +-------+ +---------+ || VM3 | | | || VM3 | | | |+-----+ | | |+-----+ | | | |---------+ | |---------+ |+-----+ | |+-----+ | || VM4 | | || VM4 | | |+-----+ | |+-----+ | +--------+ +--------+ End Device 2 End Device 2 Figure 1 Direct Connection (left) and Indirect Connection (right) Li & Yong, et al [Page 3] INTERNET DRAFT VLAN Config Considerations in Split-NVE July 2015 Some scenarios require the switching among virtual machines to be always performed on the external NVE rather than on end device or an intermediate bridge (if any). It helps to ease the policy enforcement. Such forwarding mode is called reflective relay (RR) or hairpin forwarding. A received frame on a port that supports reflective relay mode can be forwarded on the same port on which it was received. Figure 2 and 3 show the expected traffic flow when RR mode is used in direct and indirect connection respectively. The numbers in brackets indicate the expected sequence and the number with a prime indicates simultaneous sequence when the multicast traffic is considered. To achieve the expected local traffic isolation could be tricky especially for that shown in figure 3 if we consider the intermediate bridge is a traditional switch that is only able to identify VLAN tags. +--------+ |+-----+ | || VM1 | | (1) |+-----+ | ****>****>****>* | |--------------+ * |+-----+ | <****<****<**| * || VM2 | | (2) *| * |+-----+ | *|\*/ +--------+ +----------+ End Device 1 | External | | NVE1 | +----------+ | * +--------+ | * |+-----+ | | * || VM3 | | | * |+-----+ | | * | |--------------+ * |+-----+ | <****<****<****< || VM4 | | (2') |+-----+ | +--------+ End Device 2 Figure 2 Reflective Relay Mode in Direct Connection Li & Yong, et al [Page 4] INTERNET DRAFT VLAN Config Considerations in Split-NVE July 2015 +--------+ |+-----+ | || VM1 | | (1) |+-----+ | ****>****>****>* | |--------------+ * |+-----+ | <****<****<**| * || VM2 | | (4) *| * |+-----+ | *| * (2) +--------+ port1 *| ****>****>****> End Device 1 +--------+ +----------+ | Bridge |port3 | External | | B1 |----------| NVE1 | +--------+ +----------+ +--------+ port2 | *****<****<**** |+-----+ | | * (3) || VM3 | | | * |+-----+ | | * | |--------------+ * |+-----+ | <****<****<****< || VM4 | | (4') |+-----+ | +--------+ End Device 2 Figure 3 Reflective Relay Mode in Indirect Connection This document provides the information on how to correctly configure the VLAN IDs to achieve the traffic isolation in local network for either direct or indirect connection and for either RR forwarding or normal forwarding mode. 1.1 Terminology 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]. This document uses the same terminology as found in [RFC7365] and [I- D.ietf-nvo3-hpvr2nve-cp-req]. RR - Reflective Relay. A received frame on a port that supports reflective relay mode can be forwarded on the same port on which it was received. 2. VLAN ID Configurations The most common approach is to configure VLAN on per VN base in the Li & Yong, et al [Page 5] INTERNET DRAFT VLAN Config Considerations in Split-NVE July 2015 local network. It works well for most scenarios. If we examine the scenarios from two dimensions, direct or indirect connection, and RR mode or traditional forwarding mode, such VLAN configuration is not applicable to indirect connection and RR mode case for both unicast and multicast. Take figure 3 as example, we assume VM1, VM2 and VM3 are all belonging to the same VN, say VN100. When local VLAN ID is configured based on per VN, the packet from VM1 to VM3 will be forwarded by intermediate bridge B1 directly without NVE1 involved. It violates the expected behaviors in RR mode. If VM1 sends a multicast packet in VN100, intermediate Bridge B1 will forward to port 2 and port 3, NVE1 receives it and hairpins it back to B1. B1 will replicate it to port 1 and port 2. Then VM3 will receive duplicate copies which is not a correct behavior expected. There are two potential ways to configure VLAN IDs in indirect connection and RR forwarding mode case to fulfil the local traffic isolation requirement. 2.1 VLAN ID per VM When configuring different VLAN IDs for each VM and let NVE associate these VLAN ID to the same VN, it naturally ensures that the frame from one VM to another is not locally switched at the intermediate bridges. It requires a lot of work at the external NVE. NVE needs to remember the VN to VLAN ID mappings and performs the VLAN ID translations for unicast packet. For multicast traffic, the external NVE needs to replicate the packet to each of the VLANs belonging to the same VN. One way to save such effort for multicast packets is to use per-VN based VLAN ID for downstream multicast traffic. Downstream traffic here refers the multicast packets forwarded by external NVE to potential recipient VMs. Per-VN based VLAN IDs should not overlap with per-VM based VLAN IDs with this approach. Number of VLANs are consumed very quickly in this case. 2.2 Private VLAN configuration per VN The intermediate bridge can be configured as private VLAN [RFC5517] deployment. Each VN consumes two VLAN IDs in this case. Primary VLAN ID needs to be configured on the uplink port of the intermediate bridge and the port type is set to be Promiscuous Port. Secondary VLAN ID needs to be configured on the down link ports of the intermediate bridge and the port type is set to be Isolated Ports to prohibit the direct communicating between any ports of them. Such setting should be per VN base. The shared VLAN learning (SVL) [IEEE 802.1Q] needs to be enabled for primary and secondary VLAN per VN. To support RR mode on NVE, the intermediate bridge MUST disable MAC learning on the uplink port. As a result, the frame from a down link Li & Yong, et al [Page 6] INTERNET DRAFT VLAN Config Considerations in Split-NVE July 2015 port of the intermediate bridge will be sent to the uplink port as an unknown unicast frame to the external NVE. Such configuration will prevent the MAC learning hopping between the uplink and downlink ports in shared VLAN learning case. 3. Summary In indirect connection scenarios, the intermediate bridge has to be carefully configured with VLAN IDs especially when RR forwarding is enabled on the external NVE and end device. The protocol running between the hypervisor of the end device and the external NVE does not have the capability to configure the intermediate bridge. Therefore the network management system is required to configure the intermediate bridge when indirect connection has to be used. The MVRP [IEEE802.1ak] may facilitate the auto VLAN ID configuration at the intermediate bridge in some cases. 4. Security Considerations TBD 5. IANA Considerations No IANA action is required. RFC Editor: please delete this section before publication. 6. References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment", RFC 5517, February 2010. 6.2 Informative References [RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", October 2014. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for DC Network Virtualization", October 2014. Li & Yong, et al [Page 7] INTERNET DRAFT VLAN Config Considerations in Split-NVE July 2015 [I-D.ietf-nvo3-nve-nva-cp-req] Kreeger, L., Dutt, D., Narten, T., and D. Black, "Network Virtualization NVE to NVA Control Protocol Requirements", draft-ietf-nvo3-nve-nva-cp-req-01 (work in progress), October 2014. [I-D.ietf-nvo3-arch] Black, D., Narten, T., et al, "An Architecture for Overlay Networks (NVO3)", draft-narten-nvo3-arch, work in progress. [I-D.ietf-nvo3-hpvr2nve-cp-req] Yizhou, L., Yong, L., Kreeger, L., Narten, T., and D. Black, "Hypervisor to NVE Control Plane Requirements", draft-ietf-nvo3-hpvr2nve-cp-req-02 (work in progress), February 2015. [IEEE 802.1Qbg] IEEE, "Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks - Amendment 21: Edge Virtual Bridging", IEEE Std 802.1Qbg, 2012. [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August, 2011. [802.1ak] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 07: Multiple Registration Protocol", IEEE Std 802.1ak- 2007, 2007. Authors' Addresses Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56624629 EMail: liyizhou@huawei.com Lucy Yong Huawei Technologies, USA Email: lucy.yong@huawei.com Li & Yong, et al [Page 8] INTERNET DRAFT VLAN Config Considerations in Split-NVE July 2015 Li & Yong, et al [Page 9]