Subject: [armd] Revised charter statement for ARMD (ARP222)

From: Linda Dunbar <[email-masked]>
Date: Fri, 03 Sep 2010 17:45:45 -0500

Based on comments I received from the email list, I made some changes and
removed the duplicated IP address requirement. 

Here are the revised Charter Statements. Please send me your comments. If I
don't get any serious comments, I will send this revised charter statement
to Internet Area Director Ralph and Jari for IESG to approve a BOF at the
79th IETF. 

ARMD: Address Resolution for Massive amount of hosts in one broadcast Domain

Description of Working Group:

As server virtualization is introduced to data centers, the number of hosts
in a data center can grow dramatically.  Each physical server, which used to
host one end-station, now can host hundreds of end-stations or virtual
machines (VMs). Virtual machines (VMs) can be easily added and/or deleted
and moved between servers.  The VM's flexible addition/deletion and moving
around make it possible to achieve better performance and utilization on
servers. These capabilities also are important building blocks for Cloud
Computing service to offer client controlled virtual subnets and virtual
hosts. The client controlled virtual subnets offered by Cloud Computing
service could allow clients to define their own subnets with its own IP
addresses and policies. 

This rapid growth of virtual hosts could tremendously impact networks and
servers. One major issue is frequent ARP (IPv4) or neighbor discovery (IPv6)
requests from hosts. All hosts send out those requests frequently due to
caches being aged out in minutes. With tens of thousands of hosts (each with
a distinct MAC address) in one Data Center, the amount of ARP (or ND)
packets per second is potentially more than 1,000 to 10,000/second. This
rate imposes tremendous computational burden on many hosts. 

Cloud Computing service could allow users to have their own subnets with IP
addresses and self defined policies among those subnets, like Amazon's
Virtual Private Cloud service (http://aws.amazon.com/vpc). Even though the
Client Controlled Virtual Subnets have the same property as real subnets,
some network design may need to allocate multiple Client Controlled Virtual
Subnets into one physical network subnet. It is important to have isolation
among different Client Controlled Virtual Subnet(s). An ARP request from a
(virtual) host from one Client Controlled Virtual Subnet should not get any
reply if the target IP doesn't exist within this Client Controlled Virtual
Subnet. 

Another characteristic of next-generation Data Center is the possibility of
one subnet spanning across multiple sites. For example, server administrator
can combine servers in multiple sites into one huge resource pool for better
resource management and easy of allocation.  Virtual hosts can be loaded to
any servers in this pool of servers. If mobility is required, like VMware's
vMotion, all hosts need to be on the same subnet.  The Cloud Computing's
virtual private cloud could also require virtual hosts in the cloud to be in
the same subnets as hosts at client's own location. Under those
circumstances, one Layer 2 network (or subnet) could span across multiple
sites. The multiple sites could be connected by any types of network, like
L2VPN, L3VPN, Ethernet network, or simple IP networks. Efficient address
resolution across multiple sites should be considered by this working group.

The goal of this working group is to develop interoperable solutions to
solve those problems with the Data Center environment and the expansion of
the Data Center Environment to cloud computing. These environments are
multi-vendor, multi-site, and multi-domain (or multi-company). 

The design should consider the following properties:

*	All solutions developed by ARMD WG should not expect any behavior
changes on hosts, applications, or Virtual Machines being deployed in the
market. 
*	All solutions developed should not break DHCP, or any other
broadcast/multicast mechanism used by applications.
*	Evaluating the impact to IPv6 ND, and develop solutions accordingly
if needed. 
*	Should consider variety of solutions, including directory based,
proxy based, or cache based solutions. 
*	Include analysis of security concerns of IPv4 ARP requests from
malicious users. Evaluating potential security solutions and conclude if the
security threat can justify solutions. 
*	ARMD assumes the direct links to individual hosts and virtual
machines are IEEE802.3 Ethernet links.  
*	Should consider scenarios of one Ethernet network being
interconnected by another network, which can be L2VPN, pure IP, Ethernet, or
others. 
*	Should consider isolation of address resolution solutions across
different client controlled virtual subnets, i.e. hosts from one client
should be limited to getting MAC addresses from virtual hosts within its own
controlled subnet(s). If the target IP doesn't exist within the client
controlled virtual subnet(s), nothing should be returned even if the same IP
exists in a different client controlled virtual subnet(s).
*	Should consider a performance analysis of proposed solutions.   

Here are the items which should not be in the scope of the working group: 

*	Re-define DHCP behavior
*	Re-define security concern to IPv6 ND 
*	Solution developed should not expect any behavior changes for the
guest OS/applications running on the VMs
*	Direct links from hosts and virtual hosts are non Ethernet links 

Goals and Milestones:

*	Problem statement 
*	Gap Analysis Statement within Data Center

*	Gaps within ARP
*	Gaps within IPv6 ND or autoconfiguration

*	Survey of Existing Solutions 

*	Survey of NHRP (RFC2332) & SCSP,  and their applicability to
Ethernet networks;
*	Survey of TRILL work as a potential solution; 
*	Survey of  other potential solutions, like MOOSE or SEATTLE; and
*	Other proposals

*	Security Analysis of Existing Solutions

*	Study existing solutions, like Dynamic ARP Inspection, Egress ARP
Inspection, etc, and evaluate if any of them or others should be included in
the solutions specified by this working group.  

*	Architectural Design for Next-Generation Data Center 
*	Protocol Documents

Time line for BOF presentations

Initial Problem Statement                August   

GAP analysis                                              October 

Survey of Existing Solutions                        October

Security Analysis of Existing Solutions         October 

Architectural Design for NG                        October 

Final Problem statement for BOF                October

Protocol Documents                                   October 

Linda Dunbar