Internet DRAFT - draft-zhang-mac-forced-forwarding-vepa
draft-zhang-mac-forced-forwarding-vepa
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]
