INTERNET-DRAFT Mingui Zhang Intended Status: Proposed Standard Xingjian He Expires: April 25, 2013 Huawei October 22, 2012 MAC-Forced Forwarding Inter-operates with VEPA draft-zhang-mac-forced-forwarding-vepa-01.txt Abstract If MAC Forced Forwarding (RFC4562) is enabled on Top Of Rack switches, ARPing messages exchanged within a Customer Premises Network should be discarded. However, when Virtual Ethernet Port Aggregator is deployed in the Customer Premises Network, this kind of discarding may disconnect VMs within the same subnet. This document suggests interfaces should be differentiated to address this problem. 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) 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 Mingui Zhang Expires April 25, 2013 [Page 1] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 22, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Customer Premises Networks Deploy VEPA . . . . . . . . . . . . 3 2.1. Intercommunication Between Customers . . . . . . . . . . . 4 2.2. VMs from the Same Customer . . . . . . . . . . . . . . . . 5 3. Interface Classification . . . . . . . . . . . . . . . . . . . 5 3.1. Network Interface . . . . . . . . . . . . . . . . . . . . . 5 3.2. Normal User Interface . . . . . . . . . . . . . . . . . . . 5 3.3. Isolated User Interface . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Mingui Zhang Expires April 25, 2013 [Page 2] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 22, 2012 1. Introduction MAC Forced Forwarding (MFF) is specified in RFC 4562. According to it, MFF does not reply an ARP request destined to a VM located in the same Customer Premises Network (CPN) since it is assumed that this ARP request should have been replied within the CPN. However, this mechanism does not work any more when Virtual Ethernet Port Aggregator (VEPA) is deployed in this CPN. According to 802.1Qbg, when VEPA is used on servers, upstream frames via the same interface may come from different customers or different subnet from a same customer. All ARPing messages will be output to the external switch (i.e., the Ethernet Access Node as specified in RFC 4562. It corresponds to the Top Of Rack switches in Data Center Networks) via this interface. The ARP request should also be replied by the ARP proxy of this external switch, or else VMs attached to this VEPA will be disconnected. This document introduces 'isolated user interfaces' for VEPA. ARP request received via this kind of interface SHOULD NOT be discarded. The Ethernet Access Node's (EAN) ARP proxy MUST reply to it with the MAC address of the target Access Router (AR). 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]. 1.2. Terminology ARP: Address Resolution Protocol VM: Virtual Machine VEPA: Virtual Ethernet Port Aggregator MFF: The MAC Forced Forwarding technique provided in RFC 4562 CPN: Customer Premises Network EAN: Ethernet Access Node AR: Access Router 2. Customer Premises Networks Deploy VEPA A Virtual Ethernet Port Aggregator (VEPA) outputs switching traffic to external switches and external switches provide layer 2 connectivity for VMs. Customer Premises Networks may deploy VEPA therefore the Access Control List, Quality of Service, security and filtering, etc, can be executed on the external switch. This kind of offloading also frees up servers' resources consumed by switching functions. Mingui Zhang Expires April 25, 2013 [Page 3] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 22, 2012 The following two sections analyzes the connectivity issues that may happen when VEPA inter-operates with MAC Forced Forwarding. Access Aggregation Access Subscriber Customer Routers Network Nodes Lines Premises Networks +----+ | ************* --+ AR +-----------| +----+ +-*[]-------- * +----+ | | |(2) VEPA| ************* |--------+ AN1+=============+ | (1)| | | | +----+ | ############# | +-#[]-------- # | +----+(4) # # | | +---------------#[]-------- # |--------+ AN2| # # | (3)| +---------------#[]-------- # | +----+(5) ############# | | +----+ @@@@@@@@@@@@@ | | |(7) VEPA+-@[]-------- @ |--------+ AN3+=============+ @ @ +----+ | (6)| | +-@[]-------- @ --+ AR +-----------| +----+ @@@@@@@@@@@@@ +----+ Figure 2.1: VEPA is deployed on the subscriber line. 2.1. Intercommunication Between Customers When an ARP request is sent to query a MAC address of a VM located in a different CPN, the EAN's ARP proxy will reply the request with the MAC address of an AR [RFC4562]. When VEPA is deployed on Customer Premises servers, multiple CPNs may share the same subscribe line to communicate with each other [802.1Qbg]. Therefore an ARP request may need be answered by a VM from another CPN connected by the same subscribe line. According to RFC 4562, EANs never answer an ARP request message via the same interface where it is received. MFF takes it for granted that the ARP request for a VM connected by the same subscribe line should have been answered by the target host. Therefore, the EAN will discard the ARPing messages directly thus these VMs will be disconnected. In Figure 2.1, the subscriber line attached to interface (2) faces the above problem. Mingui Zhang Expires April 25, 2013 [Page 4] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 22, 2012 2.2. VMs from the Same Customer Without VEPA, an ARP request to a target VM located in the same CPN is assumed to be directly answered by this VM. Therefore the attached EAN SHOULD discard this ARP request [RFC4562]. However, when VEPA is deployed, the ARP request will not be answered within the CPN. VEPA will output the ARPing to the external switch. If the EAN discard the ARPing messages received from the subscriber line, VMs of this CPN will be disconnected. In Figure 2.1, the subscriber line attached to interface (7) faces the above problem. 3. Interface Classification According to the analysis in Section 2, whether an ARP request from a subscriber line should be answered by the ARP proxy depends on whether VEPA is used on this line. Interfaces connected to subscriber lines are distinguished to address this difference in this section. 3.1. Network Interface The interface where an EAN is connected to ARs is called the 'network interface'. In Figure 2.1, interface (1) (3) (6) are network interfaces. 3.2. Normal User Interface By default, the interface attached to a subscriber line will be set to be a 'normal user interface'. Legacy MAC Forced Forwarding rules apply to this kind of interfaces. In Figure 2.1, interfaces (4) and (5) are normal user interfaces. 3.3. Isolated User Interface When VEPA is used on a subscriber line, the interface SHOULD be set to be an 'isolated user interface'. EANs MUST use ARP proxy to reply ARP requests received on this kind of interfaces. In Figure 2.1, interfaces (2) and (7) are isolated user interfaces. 4. Security Considerations This document raises no new security issues. Mingui Zhang Expires April 25, 2013 [Page 5] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 22, 2012 5. IANA Considerations No new registry is requested to be assigned by IANA. RFC Editor: please remove this section before publication. 6. References 6.1. Normative References [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network", RFC 4562, June 2006. 6.2. Informative References [802.1Qbg]"IEEE Standard for Local and Metropolitan Area Networks--- Virtual Bridged Local Area Networks - Amendment: Edge Virtual Bridging.". IEEE Std 802.1 Qbg-2009, December 9, 2009. Mingui Zhang Expires April 25, 2013 [Page 6] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 22, 2012 Author's Addresses Mingui Zhang Huawei Email: zhangmingui@huawei.com Xingjian He Huawei xingjian.he@huawei.com Mingui Zhang Expires April 25, 2013 [Page 7]