INTERNET-DRAFT Mingui Zhang Intended Status: Proposed Standard Xingjian He Expires: April 18, 2013 Huawei October 15, 2012 MAC-Forced Forwarding Inter-operates with VEPA draft-zhang-mac-forced-forwarding-vepa-00.txt Abstract MAC Forced Forwarding discards ARPing messages exchanged within a Customer Premises Network (CPN). When Virtual Ethernet Port Aggregator (VEPA) is deployed in the CPN, this kind of discarding may cause a connectivity problem. This document analyzes the cause of this connectivity problem and suggests interfaces should be classified to avoid the 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 Mingui Zhang Expires April 18, 2013 [Page 1] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 15, 2012 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. 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 . . . . . . . . . . . . . . . . 4 3. Interface Classification . . . . . . . . . . . . . . . . . . . 5 3.1. Network Interface . . . . . . . . . . . . . . . . . . . . . 5 3.2. Normal User Interface . . . . . . . . . . . . . . . . . . . 5 3.3. Separated 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 18, 2013 [Page 2] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 15, 2012 1. Introduction MAC Forced Forwarding (MFF) is defined in RFC 4562. MFF does not reply an ARP request destined to a VM located in the same Customer Premises Network (CPN). Because 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 used in the 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 via this interface. The ARP request should also be replied by the ARP proxy by this external switch (i.e., the Ethernet Access Node, see RFC 4562), or else the VMs connected by this VEPA will be disconnected. This document defines separated user interface for VEPA. ARP request received via this kind of interface should never be discarded. The EAN's ARP proxy MUST reply to it with the MAC address of the target 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 VM: Virtual Machine VEPA: Virtual Ethernet Port Aggregator MFF: The MAC Forced Forwarding technique provided in RFC 4562 2. Customer Premises Networks Deploy VEPA A Virtual Ethernet Port Aggregator (VEPA) outputs switching traffic to external switches (EANs) and EANs provide layer 2 connectivity for VMs. Customer Premises Networks may deploy VEPA therefore the Access Control List, Quality of Service, security and filtering can be performed on the external switch. This kind of offloading also frees up servers' resources cost by the switching function. The following two section list the connectivity issues that may happen when VEPA is deployed in Customer Premises Networks. Mingui Zhang Expires April 18, 2013 [Page 3] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 15, 2012 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 For a VM located in a different CPN, when ARP request are sent to query this its MAC address, the EAN's ARP proxy will reply the request with the MAC address of an AR. When VEPA is deployed on Customer Premises servers, multiple CPNs may share the same subscribe line to send upstream traffic and communicate with each other [802.1Qbg]. Therefore an ARP request may need be answered by another VM within 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 be answered by the target host. Therefore, the EAN will discard the ARPing messages directly. Thus these VMs will be wrongly disconnected. In Figure 2.1, the subscriber line attached to the interface (2) faces the above problem. 2.2. VMs from the Same Customer Mingui Zhang Expires April 18, 2013 [Page 4] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 15, 2012 Without VEPA, for VMs from the same customer premises network, an ARP request to a target VM is assumed to be directly answered by this VM within the premises network. Therefore the attached EAN SHOULD discard this ARP request [RFC 4562]. However, when VEPA is deployed, the ARP request will not be answered within the customer premises network. 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 the interface (7) faces the above problem. 3. Interface Classification In order to solve the connectivity issues described in Section 2, EANs should answer all ARP requests got from a subscriber line when VEPA is used on this line. In this section, interfaces of EANs are classified into three categories: network interface, normal user interface and separated user interface. 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 normal user interface. Legacy MAC Forced Forwarding rules applies on this kind of interface. In Figure 2.1, interfaces (4) and (5) are the normal user interfaces. 3.3. Separated User Interface When VEPA is used on a subscriber line, the interface SHOULD be set to separated user interface. EANs MUST use ARP proxy to reply ARP requests received via this kind of interface. In Figure 2.1, interfaces (2) and (7) are the separated user interfaces. 4. Security Considerations This document raises no new security issues. Mingui Zhang Expires April 18, 2013 [Page 5] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 15, 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 18, 2013 [Page 6] INTERNET-DRAFT MAC-Forced Forwarding & VEPA October 15, 2012 Author's Addresses Mingui Zhang Huawei Email: zhangmingui@huawei.com Xingjian He Huawei xingjian.he@huawei.com Mingui Zhang Expires April 18, 2013 [Page 7]