Re: [arp222] ARP222 Charter statement and milestones

Linda Dunbar <ldunbar@huawei.com> Fri, 13 August 2010 19:30 UTC

Return-Path: <ldunbar@huawei.com>
X-Original-To: arp222@core3.amsl.com
Delivered-To: arp222@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5613A697A for <arp222@core3.amsl.com>; Fri, 13 Aug 2010 12:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.305
X-Spam-Level:
X-Spam-Status: No, score=-102.305 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omzwhhNF8c5T for <arp222@core3.amsl.com>; Fri, 13 Aug 2010 12:29:51 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 608903A6836 for <arp222@ietf.org>; Fri, 13 Aug 2010 12:29:51 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7300J20VIRYT@usaga02-in.huawei.com> for arp222@ietf.org; Fri, 13 Aug 2010 12:30:28 -0700 (PDT)
Received: from L735042 ([10.124.12.72]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7300MN2VIQ0N@usaga02-in.huawei.com> for arp222@ietf.org; Fri, 13 Aug 2010 12:30:27 -0700 (PDT)
Date: Fri, 13 Aug 2010 14:30:26 -0500
From: Linda Dunbar <ldunbar@huawei.com>
In-reply-to: <016D6D95AF0949478938DD97B5218DE6021802BB47CA@EXCH-CLUSTER-09.force10networks.com>
To: 'T Sridhar' <tsridhar@force10networks.com>, arp222@ietf.org
Message-id: <00b701cb3b1d$fbacb040$480c7c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_5pVYs+6z4L0tybIYkZd3OQ)"
Thread-index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQApWZ+gAADsxUA=
References: <00f901cb3a74$1bb07e80$5d0c7c0a@china.huawei.com> <016D6D95AF0949478938DD97B5218DE6021802BB47CA@EXCH-CLUSTER-09.force10networks.com>
Subject: Re: [arp222] ARP222 Charter statement and milestones
X-BeenThere: arp222@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." <arp222.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/arp222>, <mailto:arp222-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/arp222>
List-Post: <mailto:arp222@ietf.org>
List-Help: <mailto:arp222-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/arp222>, <mailto:arp222-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2010 19:30:07 -0000

Sridhar, 

 

Absolutely, other approaches should be considered.  The ones listed down
there are the ones already being published by research institutes and NHRP
is developed by IETF for ATM network. The reason we listed them is because
there are people already signed up to write the drafts. The proposed working
group is to solicit more solutions and possibly finalize to a few
interoperable ones.  

 

Linda 

 

  _____  

From: T Sridhar [mailto:tsridhar@force10networks.com] 
Sent: Friday, August 13, 2010 2:02 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

 

Linda,

 

I am not comfortable with the following bullets in the Goals & Milestones
section. There may be other approaches that could be considered once we have
the problem statement nailed down, but the specific approaches shouldn't be
part of the goals.  

 

*        Study of NHRP (RFC2332) & SCSP,  and their applicability to
Ethernet networks

*        Study and Analysis of MOOSE as a potential solution

*        Study and Analysis of SEATTLE as a potential solution.

 

 

Thoughts?

 

Thanks,

Sridhar

 

 

 

 

From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of
Linda Dunbar
Sent: Thursday, August 12, 2010 4:14 PM
To: arp222@ietf.org
Subject: [arp222] ARP222 Charter statement and milestones

 

Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving us
comments and suggestions on and between sessions. 

 

I put together the initial ARP222 Charter Statement and Milestones. Please
provide comments and suggestions.  

 

 

 

 

ARP 222: Address Resolution Protocol for Layer 2 to Anything to Layer 2

 

Description of Working Group:

As server virtualization is introduced to data centers, the number of hosts
in a data center can grow dramatically because each physical server, which
used to host one end-station, now can host many end-stations, or Virtual
Machines (20, 30, or hundreds of). Virtual Machines, with its flexible
add/delete and mobility features, not only makes it possible for achieving
better performance and better utilization on servers, they are also a very
important building block for Cloud Computing service to offer virtual
subnets and virtual hosts. The 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 to networks and
servers. One huge issue is frequent address resolution (IPv4) or neighbor
discovery (IPv6) requests from hosts. All hosts frequently send out those
requests due to their cache being aged out in minutes. With tens of
thousands of hosts (each with a distinct MAC address) in one Data Center,
the amount of address resolution packets per second is potentially more than
1,000 to 10,000/second. This rate imposes tremendous computational burden on
many hosts. 

Another big issue associated with huge number of virtual hosts in a data
center is potentially duplicated IP addresses within one VLAN which will
make traditional ARP or ND not working properly. Some load balance design
requires multiple hosts serving the same application to have the same IP
address but with different MAC addresses. Cloud Computing service could
allow users to have their own subnets with IP addresses and self defined
policies among those subnets. Some network designs need to put multiple
client subnets into one VLAN because the number of client subnets could be
in hundreds of thousands which is much more than 4095 VLANs. Under this
scenario, there could be duplicated IP addresses which are from different
client subnets ending up in one VLAN.  

The goal of this working group is to develop interoperable solutions to
solve those problems.  

The design should consider the following properties:

*        All solutions developed by ARP222 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. 

*        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. 

*        ARP222 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 address resolution solutions for one VLAN with
small number of duplicated IP addresses.  

 

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 

*        Direct links from hosts and virtual hosts are non Ethernet links 

*         

 

Goals and Milestones:

*        Charter statement

*        Problem Statements

*        Gap analysis 

*        Study of NHRP (RFC2332) & SCSP,  and their applicability to
Ethernet networks

*        Study and Analysis of MOOSE as a potential solution

*        Study and Analysis of SEATTLE as a potential solution.

 

 

Best Regards, Linda Dunbar