Subject: [Int-area] Updated draft-nachum-sarp to address comments regarding to IPv6 ND applicability

From: Linda Dunbar <[email-masked]>
Date: Mon, 25 Feb 2013 20:13:24 +0000

Thanks to many people's response and comments to draft-nachum-sarp-03. 
I sent an email clarifying some issues of this draft back in early Jan. 
Now we have updated the draft to include the clarification. 

In a nutshell:

People are under the impression that the draft is to scale the flooding of ND messages on all links. MLD was brought up to say that ND messages are actually suppressed from flooding to links which don't have the target hosts. But that is the not the main intent of this draft. 

The real impact of ARP/ND in DC with massive number of hosts (or VMs) is on the L2/L3 boundary router (or Default GW). When hosts in subnet A needs to send data frames to Subnet B, the router has to 1) respond the ARP/ND requests from hosts in Subnet-A and 2) resolve target MAC for hosts in subnet-B. 

The second step is not only CPU intensive but also buffer intensive. There are some practices to alleviate the pain of Step 1) for IPv4, but not for IPv6 (https://datatracker.ietf.org/doc/draft-dunbar-armd-arp-nd-scaling-practices/).

In order to protect routers CPU being overburdened by target resolution requests,  some routers has to rate limit the Target MAC resolution requests to CPU (Glean Throttling rate in this manual). http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/unicast/configuration/guide/l3_ip.pdf , searching for "Glean Throttling". 

When the Glean Throttling rate is exceeded, the incoming data frames are dropped. 

In traditional Data Center, it is less of an issue because the number of hosts attached to one L2/L3 boundary router is limited by physical ports of switches/routers. When Servers are virtualized to support 30 plus VMs, the number of hosts under one router can grow 30 plus times. 

The solution proposed in this draft can eliminate (or reduce the likelihood of) inter-subnet data frames being dropped.  

In addition, the traditional DC has each subnet nicely placed in limited number of server racks, i.e. switches under router only need to deal with MAC addresses of those limited subnets. With subnets being spread across many server racks, the switches are exposed to VLAN/MAC of many subnets, greatly increasing the FDB. 

This draft also addresses the FDB entries explosion issue.

We are looking forward to your comments and feedback to this update. 

Thank you very much. 

Linda 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, February 24, 2013 9:01 AM
To: [email-masked]
Cc: Linda Dunbar; [email-masked]; [email-masked]
Subject: New Version Notification for draft-nachum-sarp-04.txt

A new version of I-D, draft-nachum-sarp-04.txt
has been successfully submitted by Tal Mizrahi and posted to the
IETF repository.

Filename:	 draft-nachum-sarp
Revision:	 04
Title:		 Scaling the Address Resolution Protocol for Large Data Centers (SARP)
Creation date:	 2013-02-24
Group:		 Individual Submission
Number of pages: 19
URL:             http://www.ietf.org/internet-drafts/draft-nachum-sarp-04.txt
Status:          http://datatracker.ietf.org/doc/draft-nachum-sarp
Htmlized:        http://tools.ietf.org/html/draft-nachum-sarp-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-nachum-sarp-04

Abstract:
   This  document  provides  a  recommended  architecture  and  network
   operation  named  SARP.  SARP  is  based  on  fast  proxies  that
   significantly  reduce  broadcast  domains  and  ARP/ND  broadcast
   transmissions. SARP supports smooth and fast virtual machine (VM)
   mobility without any modification to the VM, while keeping the
   connection up and running efficiently.  SARP is targeted for massive
   scaling data centers with a significant number of VMs using ARP and
   ND protocols.

The IETF Secretariat