draft-nachum-sarp has been presented at InterArea WG 3 times. As the motivation
for the scheme wasn't clearly stated, many people in the WG have been debating
on the necessity of the scheme during the meeting and over the mailing list.
We updated the draft to address the issues that WG have brought up:
http://www.ietf.org/internet-drafts/draft-nachum-sarp-05.txt
The proposed scheme is more like proxy gateway to address the following issues
facing Data Centers with large number virtual machines that don't have fixed
association with access switches:
1) intermediate switches’ MAC address table (FDB) explosion:
When hosts in a VLAN (or subnet) span across many locations (or Access
Switches) and each Access Switch has many VLANs enabled, the Access switches
are exposed to all MAC addresses among all the VLANs enabled.
For example, for an Access switch with 40 physical servers attached, and each
server has 100 VMs, there are 4000 hosts under the Access Switch. If it is
truly that hosts/VMs can be moved anywhere, the worst case for the Access
Switch is when all those 4000 VMs belong to different VLANs, i.e. the access
switch has 4000 VLANs enabled. If each of VLANs has 200 hosts, this access
switch’s MAC table potentially has 200*4000 = 800,000 entries.
Although above case is rare, but could happen regardless IPv4 or IPv6.
This is worse than what today’s L2/3 Gateway has to face. In today’s
environment where each subnet is limited to a few access switches, only the
limited ports facing those access switches are exposed to MAC address of the
subnet.
2) the ARP/ND processing load impact on the L2/L3 boundary routers;
All VMs periodically send NDs to their corresponding Gateway nodes to get
gateway nodes’ MAC addresses. When the combined VMs across all the VLANs are
large, processing the responses to the ND requests from those VMs can easily
knock down the gateway’s CPU utilization.
A L2/L3 boundary router could be hit with ARP/ND twice when the originating and
destination stations are in different subnets attached to the same router and
when those hosts don’t communicate with external peers very often. The first
hit is when the originating station in subnet-A initiates ARP/ND request to the
L2/L3 boundary router if the router’s MAC is not in the host’s cache; and the
second hit is when the L2/L3 boundary router initiates ARP/ND requests to the
target in subnet-B if the target is not in router’s ARP/ND cache.
3) In IPv4, every end station in a subnet receives ARP broadcast messages
from all other end stations in the subnet. IPv6 ND has eliminated this issue by
using multicast.
However, most devices have limited number of Multicast filtering. Once the
number of multicast addresses goes beyond the multicast filter limit, the
multicast addresses have to be processed by devices’ CPU (i.e. the slow path).
It is less of an issue in DC without VM mobility because each port is only
dedicated to one (or a few number of) VLANs. So the number of multicast
addresses hitting each port is much less.
4) the ARP/ND messages being flooded to many physical link segments which
can reduce bandwidth utilization for user traffic;
ARP/ND flooding is probably an insignificant issue in today’s data center
because the majority of data center servers are moving towards 1G or 10G ports.
The bandwidth taken by ARP/ND, even with them flooded to all physical links,
becomes negligible comparing with the link bandwidth. In addition, the IGMP/MLD
snooping [RFC4541] can further reduce the ND multicast traffic to some physical
link segments.
Hope those points are more clear.
Linda
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, July 11, 2013 3:13 PM
To: Linda Dunbar; Youval Nachum; Ilan Yerushalmi; Tal Mizrahi
Subject: New Version Notification for draft-nachum-sarp-05.txt
A new version of I-D, draft-nachum-sarp-05.txt
has been successfully submitted by Youval Nachum and posted to the
IETF repository.
Filename:draft-nachum-sarp
Revision:05
Title: Scaling the Address Resolution Protocol for Large Data Centers
(SARP)
Creation date: 2013-07-11
Group: Individual Submission
Number of pages: 20
URL: http://www.ietf.org/internet-drafts/draft-nachum-sarp-05.txt
Status: http://datatracker.ietf.org/doc/draft-nachum-sarp
Htmlized:http://tools.ietf.org/html/draft-nachum-sarp-05
Diff:http://www.ietf.org/rfcdiff?url2=draft-nachum-sarp-05
Abstract:
This document introduces SARP, an architecture that uses proxy
gateways and allows to scale data center networks. SARP is based on
fast proxies that significantly reduce switches' FDB (MAC table)
sizes and ARP/ND impact on network elements in an environment that
hosts within one subnet (or VLAN) can spread over various locations.
SARP supports smooth and fast virtual machine (VM)
