Thank you all for coming to ARP222 Bar BOF at the 78^th 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

--Boundary_(ID_/vr2nMQ0sdAcrRk3pS9VSQ)-- From tsridhar@force10networks.com Fri Aug 13 12:01:14 2010 Return-Path: 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 AE1B03A6A18 for ; Fri, 13 Aug 2010 12:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.393 X-Spam-Level: X-Spam-Status: No, score=-5.393 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 I4SvEbIXEbIQ for ; Fri, 13 Aug 2010 12:01:06 -0700 (PDT) Received: from mx.force10networks.com (corp.force10networks.com [64.186.164.204]) by core3.amsl.com (Postfix) with ESMTP id 64E503A68D5 for ; Fri, 13 Aug 2010 12:01:00 -0700 (PDT) Received: from EXCH-CLUSTER-09.force10networks.com ([10.11.10.113]) by exch7-sjc-fe.force10networks.com ([10.11.0.87]) with mapi; Fri, 13 Aug 2010 12:01:38 -0700 From: T Sridhar To: Linda Dunbar , "arp222@ietf.org" Date: Fri, 13 Aug 2010 12:01:36 -0700 Thread-Topic: [arp222] ARP222 Charter statement and milestones Thread-Index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQApWZ+g Message-ID: <016D6D95AF0949478938DD97B5218DE6021802BB47CA@EXCH-CLUSTER-09.force10networks.com> References: <00f901cb3a74$1bb07e80$5d0c7c0a@china.huawei.com> In-Reply-To: <00f901cb3a74$1bb07e80$5d0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_016D6D95AF0949478938DD97B5218DE6021802BB47CAEXCHCLUSTER_" MIME-Version: 1.0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:01:14 -0000 --_000_016D6D95AF0949478938DD97B5218DE6021802BB47CAEXCHCLUSTER_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, I am not comfortable with the following bullets in the Goals & Milestones s= ection. There may be other approaches that could be considered once we have= the problem statement nailed down, but the specific approaches shouldn't b= e part of the goals. * Study of NHRP (RFC2332) & SCSP, and their applicability to Ethernet n= etworks * 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 c= omments 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 M= achines (20, 30, or hundreds of). Virtual Machines, with its flexible add/d= elete and mobility features, not only makes it possible for achieving bette= r performance and better utilization on servers, they are also a very impor= tant building block for Cloud Computing service to offer virtual subnets an= d virtual hosts. The virtual subnets offered by Cloud Computing service cou= ld 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 an= d 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 thousan= ds of hosts (each with a distinct MAC address) in one Data Center, the amou= nt 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 ce= nter is potentially duplicated IP addresses within one VLAN which will make= traditional ARP or ND not working properly. Some load balance design requi= res multiple hosts serving the same application to have the same IP address= but with different MAC addresses. Cloud Computing service could allow user= s to have their own subnets with IP addresses and self defined policies amo= ng 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 co= uld be duplicated IP addresses which are from different client subnets endi= ng up in one VLAN. The goal of this working group is to develop interoperable solutions to sol= ve those problems. The design should consider the following properties: * All solutions developed by ARP222 WG should not expect any behavior ch= anges on hosts, applications, or Virtual Machines being deployed in the mar= ket. * 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 malici= ous users. Evaluating potential security solutions and conclude if the secu= rity threat can justify solutions. * ARP222 assumes the direct links to individual hosts and virtual machin= es 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 n= umber 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 n= etworks * Study and Analysis of MOOSE as a potential solution * Study and Analysis of SEATTLE as a potential solution. Best Regards, Linda Dunbar --_000_016D6D95AF0949478938DD97B5218DE6021802BB47CAEXCHCLUSTER_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda,

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

Study of NHRP (RFC= 2332) & 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 78^th IETF and giving us comm= ents and suggestions on and between sessions.

=

I put together the initial ARP222 Charter Statement and Milestones. Please provid= e 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 performa= nce and better utilization on servers, they are also a very important building block for Cloud Computing service to offer virtual subnets and virtual host= s. 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 thousan= ds 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 ho= sts.

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 traditi= onal 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 whic= h is much more than 4095 VLANs. Under this scenario, there could be duplicated I= P addresses which are from different client subnets ending up in one VLAN.&nb= sp;

The goal of this working group is to develop interoperable solutions to solve t= hose problems.

The design should consider the following properties= :

All solutions deve= loped by ARP222 WG should not expect any behavior changes on hosts, application= s, or Virtual Machines being deployed in the market.

All solutions deve= loped should not break DHCP.

Evaluating the imp= act to IPv6 ND, and develop solutions accordingly if needed.

Should consider va= riety of solutions, including directory based, proxy based, or cache based solutions.

Include analysis o= f security concerns of IPv4 ARP requests from malicious users. Evaluatin= g 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 sc= enarios of one Ethernet network being interconnected by another network, which= can be L2VPN, pure IP, Ethernet, or others.

Should consider ad= dress 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 beh= avior

Re-define security= concern to IPv6 ND

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

<= /li>

Goals and Milestones:

Charter statement<= o:p>

Problem Statements=

Gap analysis =

Study of NHRP (RFC= 2332) & 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

--_000_016D6D95AF0949478938DD97B5218DE6021802BB47CAEXCHCLUSTER_-- From ldunbar@huawei.com Fri Aug 13 12:30:07 2010 Return-Path: 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 ; 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 ; 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 ; 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 In-reply-to: <016D6D95AF0949478938DD97B5218DE6021802BB47CA@EXCH-CLUSTER-09.force10networks.com> To: 'T Sridhar' , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:30:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5pVYs+6z4L0tybIYkZd3OQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT 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 --Boundary_(ID_5pVYs+6z4L0tybIYkZd3OQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

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,<= /o:p>

<= /o:p>

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.

<= /o:p>

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

<= /o:p>

<= /o:p>

Thoughts?

<= /o:p>

Thanks,=

Sridhar=

<= /o:p>

<= /o:p>

<= /o:p>

<= /o:p>

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 78^th 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

--Boundary_(ID_5pVYs+6z4L0tybIYkZd3OQ)-- From ldunbar@huawei.com Fri Aug 13 12:41:39 2010 Return-Path: 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 556F93A6914 for ; Fri, 13 Aug 2010 12:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=0.275, 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 gq-WMtLF9Oa4 for ; Fri, 13 Aug 2010 12:41:38 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id A015D3A63D3 for ; Fri, 13 Aug 2010 12:41:37 -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 <0L7300JHMW2EYT@usaga02-in.huawei.com> for arp222@ietf.org; Fri, 13 Aug 2010 12:42:14 -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 <0L7300MXXW2D0N@usaga02-in.huawei.com> for arp222@ietf.org; Fri, 13 Aug 2010 12:42:14 -0700 (PDT) Date: Fri, 13 Aug 2010 14:42:14 -0500 From: Linda Dunbar In-reply-to: To: arp222@ietf.org Message-id: <00bc01cb3b1f$a12fa3f0$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_iyFBPYb0VACqEfDcSJOd8Q)" Thread-index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3Aw References: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:41:39 -0000 This is a multi-part message in MIME format. --Boundary_(ID_iyFBPYb0VACqEfDcSJOd8Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80. Linda Dunbar _____ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: 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 --Boundary_(ID_iyFBPYb0VACqEfDcSJOd8Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80.

Linda Dunbar

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Thursday, August 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78^th 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

--Boundary_(ID_iyFBPYb0VACqEfDcSJOd8Q)-- From anoop@brocade.com Fri Aug 13 14:03:04 2010 Return-Path: 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 CDF443A691A for ; Fri, 13 Aug 2010 14:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 QXxZF-DDjzVH for ; Fri, 13 Aug 2010 14:03:03 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 3502E3A6840 for ; Fri, 13 Aug 2010 14:03:03 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o7DKxUHg023226; Fri, 13 Aug 2010 14:03:32 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id qnbb8832d-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Aug 2010 14:03:31 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 13 Aug 2010 14:05:30 -0700 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Fri, 13 Aug 2010 14:03:30 -0700 From: Anoop Ghanwani To: Linda Dunbar , "arp222@ietf.org" Date: Fri, 13 Aug 2010 14:02:13 -0700 Thread-Topic: [arp222] ARP222 Charter statement and milestones Thread-Index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPA= Message-ID: <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> In-Reply-To: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5EB1A55E180C914BBC1A49310B76293863830E1558HQ1EXCH02corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-13_05:2010-08-13, 2010-08-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1008130168 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 21:03:05 -0000 --_000_5EB1A55E180C914BBC1A49310B76293863830E1558HQ1EXCH02corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of= Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and mil= estones posted is for soliciting feedback before submitting to IESG to requ= est for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get= your feedback, I will send the Charter Statement and milestones to the Int= ernet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Ou= r target is to have a working group by IETF 80. Linda Dunbar ________________________________ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: ARP222 Charter statement and milestones Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving us c= omments 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 M= achines (20, 30, or hundreds of). Virtual Machines, with its flexible add/d= elete and mobility features, not only makes it possible for achieving bette= r performance and better utilization on servers, they are also a very impor= tant building block for Cloud Computing service to offer virtual subnets an= d virtual hosts. The virtual subnets offered by Cloud Computing service cou= ld 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 an= d 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 thousan= ds of hosts (each with a distinct MAC address) in one Data Center, the amou= nt 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 ce= nter is potentially duplicated IP addresses within one VLAN which will make= traditional ARP or ND not working properly. Some load balance design requi= res multiple hosts serving the same application to have the same IP address= but with different MAC addresses. Cloud Computing service could allow user= s to have their own subnets with IP addresses and self defined policies amo= ng 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 co= uld be duplicated IP addresses which are from different client subnets endi= ng up in one VLAN. The goal of this working group is to develop interoperable solutions to sol= ve those problems. The design should consider the following properties: * All solutions developed by ARP222 WG should not expect any behavi= or changes on hosts, applications, or Virtual Machines being deployed in th= e market. * All solutions developed should not break DHCP. * Evaluating the impact to IPv6 ND, and develop solutions according= ly 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 m= alicious users. Evaluating potential security solutions and conclude if the= security threat can justify solutions. * ARP222 assumes the direct links to individual hosts and virtual m= achines are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconn= ected by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider address resolution solutions for one VLAN with sm= all 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 Ether= net networks * Study and Analysis of MOOSE as a potential solution * Study and Analysis of SEATTLE as a potential solution. Best Regards, Linda Dunbar --_000_5EB1A55E180C914BBC1A49310B76293863830E1558HQ1EXCH02corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

Would it be possible to provide references to actual protoco= ls

that require duplicate IP addresses behind different MAC addresses?

Anoop

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

I forgot to clarify in my previous email that the charter statement and miles= tones posted is for soliciting feedback before submitting to IESG to request for = a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore, once I get yo= ur feedback, I will send the Charter Statement and milestones to the Internet = ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target i= s to have a working group by IETF 80.

Linda Dunbar

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Thursday, August 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78^th 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 Resolut= ion Protocol for Layer 2 to Anything to Layer 2

Description of Working G= roup:

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 performa= nce and better utilization on servers, they are also a very important building block for Cloud Computing service to offer virtual subnets and virtual host= s. 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 thousan= ds 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 ho= sts.

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 traditi= onal 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 whic= h is much more than 4095 VLANs. Under this scenario, there could be duplicated I= P addresses which are from different client subnets ending up in one VLAN.&nb= sp;

The goal of this working group is to develop interoperable solutions to solve t= hose problems.

The design should consid= er the following properties:

·      =    All solutions developed by ARP222 WG should = not expect any behavior changes on hosts, applications, or Virtual Machines bei= ng deployed in the market.

·      =    All solutions developed should not break DHC= P.

·      =    Evaluating the impact to IPv6 ND, and develo= p solutions accordingly if needed.

·      =    Should consider variety of solutions, includ= ing directory based, proxy based, or cache based solutions.

·      =    Include analysis of security concerns of IPv= 4 ARP requests from malicious users. Evaluating potential security solutions = and conclude if the security threat can justify solutions.

·      =    ARP222 assumes the direct links to individua= l hosts and virtual machines are IEEE802.3 Ethernet links. <= /p>
·      =    Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure I= P, 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 <= /o:p>

·      =    Direct links from hosts and virtual hosts ar= e non Ethernet links

·      =

Goals and Milestones:

·      =    Charter statement

·      =    Problem Statements

·      =    Gap analysis

·      =    Study of NHRP (RFC2332) & SCSP, an= d their applicability to Ethernet networks

·      =    Study and Analysis of MOOSE as a potential s= olution

·      =    Study and Analysis of SEATTLE as a potential solution.

Best Regards, Linda Dunbar

--_000_5EB1A55E180C914BBC1A49310B76293863830E1558HQ1EXCH02corp_-- From ldunbar@huawei.com Fri Aug 13 14:43:03 2010 Return-Path: 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 F08883A67F2 for ; Fri, 13 Aug 2010 14:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.259, 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 W6CanpBRQjTW for ; Fri, 13 Aug 2010 14:43:01 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 1B1FC3A67F0 for ; Fri, 13 Aug 2010 14:43:01 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L74003I01OPXC@usaga04-in.huawei.com> for arp222@ietf.org; Fri, 13 Aug 2010 16:43:37 -0500 (CDT) Received: from L735042 ([10.124.12.72]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L74008161ONUB@usaga04-in.huawei.com> for arp222@ietf.org; Fri, 13 Aug 2010 16:43:36 -0500 (CDT) Date: Fri, 13 Aug 2010 16:43:35 -0500 From: Linda Dunbar In-reply-to: <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> To: 'Anoop Ghanwani' , arp222@ietf.org Message-id: <010401cb3b30$95a41aa0$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_2EQpxMk/zpkI8FpeqoprzA)" Thread-index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPAAATqjsA== References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 21:43:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_2EQpxMk/zpkI8FpeqoprzA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Anoop, The scenario is Cloud Computing service selling client controlled (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among those (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address). Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80. Linda Dunbar _____ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: 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 --Boundary_(ID_2EQpxMk/zpkI8FpeqoprzA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Anoop,

The scenario is Cloud Computing service selling client controlled (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among those (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address).

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, 2010 4:02 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Hi Linda,

Would it be possible to provide references to actual protocols

that require duplicate IP addresses behind different MAC addresses?

Anoop

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

I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80.

Linda Dunbar

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Thursday, August 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78^th 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

--Boundary_(ID_2EQpxMk/zpkI8FpeqoprzA)-- From anoop@brocade.com Fri Aug 13 16:18:59 2010 Return-Path: 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 BDF603A6A1E for ; Fri, 13 Aug 2010 16:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 chVPYc+Z3T1d for ; Fri, 13 Aug 2010 16:18:58 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id B309E3A699A for ; Fri, 13 Aug 2010 16:18:57 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o7DNF0AK025895; Fri, 13 Aug 2010 16:19:20 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id qnbb885c9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Aug 2010 16:19:19 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 13 Aug 2010 16:21:18 -0700 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Fri, 13 Aug 2010 16:19:17 -0700 From: Anoop Ghanwani To: Linda Dunbar , "arp222@ietf.org" Date: Fri, 13 Aug 2010 16:19:16 -0700 Thread-Topic: [arp222] ARP222 Charter statement and milestones Thread-Index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPAAATqjsAADikNw Message-ID: <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> In-Reply-To: <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5EB1A55E180C914BBC1A49310B76293863830E1610HQ1EXCH02corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-13_06:2010-08-14, 2010-08-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1008130199 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 23:18:59 -0000 --_000_5EB1A55E180C914BBC1A49310B76293863830E1610HQ1EXCH02corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, Do broadcasts from one client controlled subnet show up in a different client controlled subnet? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Friday, August 13, 2010 2:44 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The scenario is Cloud Computing service selling client controlled (virtual)= subnets to clients. All the (virtual) hosts within the client controlled s= ubnets have their own IP addresses. The communications among those (virtual= ) hosts are client specific. There might be same IP addresses in different = client controlled subnets. All those hosts will be assigned as a virtual ma= chine to a physical server and assigned to a VLAN in the actual network in = data center(s). There will be cases when one VLAN ends up having (virtual) = hosts with same IP address (but different MAC address). Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of= Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and mil= estones posted is for soliciting feedback before submitting to IESG to requ= est for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get= your feedback, I will send the Charter Statement and milestones to the Int= ernet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Ou= r target is to have a working group by IETF 80. Linda Dunbar ________________________________ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: ARP222 Charter statement and milestones Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving us c= omments 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 M= achines (20, 30, or hundreds of). Virtual Machines, with its flexible add/d= elete and mobility features, not only makes it possible for achieving bette= r performance and better utilization on servers, they are also a very impor= tant building block for Cloud Computing service to offer virtual subnets an= d virtual hosts. The virtual subnets offered by Cloud Computing service cou= ld 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 an= d 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 thousan= ds of hosts (each with a distinct MAC address) in one Data Center, the amou= nt 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 ce= nter is potentially duplicated IP addresses within one VLAN which will make= traditional ARP or ND not working properly. Some load balance design requi= res multiple hosts serving the same application to have the same IP address= but with different MAC addresses. Cloud Computing service could allow user= s to have their own subnets with IP addresses and self defined policies amo= ng 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 co= uld be duplicated IP addresses which are from different client subnets endi= ng up in one VLAN. The goal of this working group is to develop interoperable solutions to sol= ve those problems. The design should consider the following properties: * All solutions developed by ARP222 WG should not expect any behavi= or changes on hosts, applications, or Virtual Machines being deployed in th= e market. * All solutions developed should not break DHCP. * Evaluating the impact to IPv6 ND, and develop solutions according= ly 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 m= alicious users. Evaluating potential security solutions and conclude if the= security threat can justify solutions. * ARP222 assumes the direct links to individual hosts and virtual m= achines are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconn= ected by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider address resolution solutions for one VLAN with sm= all 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 Ether= net networks * Study and Analysis of MOOSE as a potential solution * Study and Analysis of SEATTLE as a potential solution. Best Regards, Linda Dunbar --_000_5EB1A55E180C914BBC1A49310B76293863830E1610HQ1EXCH02corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda,

Do broadcasts from one client controlled subnet show up=

in a different client controlled subnet?

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Friday, August 13, 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The scenario is Cloud Computing service selling client controlled (virtual) sub= nets to clients. All the (virtual) hosts within the client controlled subnets ha= ve their own IP addresses. The communications among those (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine t= o a physical server and assigned to a VLAN in the actual network in data center= (s). There will be cases when one VLAN ends up having (virtual) hosts with same = IP address (but different MAC address).

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Friday, August 13, 2010 4:02 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Hi Linda,

<= /p>
Would it be possible to provide references to actual protocols

that require duplicate IP addresses behind different MAC addresses?

<= /p>
Anoop
<= /p>

From: arp222-bounces@ietf.org [mailto:arp222-= bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Friday, August 13, 2010 12:42 PM
To: arp222@ietf.org
Subject: Re: [arp222] ARP222 Charter statement and milestones

I forgot to clarify in my previous email that the charter state= ment and milestones posted is for soliciting feedback before submitting to IESG = to request for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore= , once I get your feedback, I will send the Charter Statement and milestones = to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beiji= ng). Our target is to have a working group by IETF 80.

Linda Dunbar

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Thursday, August 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78^th 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 Resolu= tion 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 performa= nce and better utilization on servers, they are also a very important building block for Cloud Computing service to offer virtual subnets and virtual host= s. 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 thousan= ds 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 ho= sts.

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 traditi= onal 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 whic= h is much more than 4095 VLANs. Under this scenario, there could be duplicated I= P addresses which are from different client subnets ending up in one VLAN.&nb= sp;

The goal of this working group is to develop interoperable solutions to solve t= hose problems.

The design should consi= der the following properties:

·      =    All solutions developed by ARP222 WG should = not expect any behavior changes on hosts, applications, or Virtual Machines bei= ng deployed in the market.

·      =    All solutions developed should not break DHC= P.

·      =    Evaluating the impact to IPv6 ND, and develo= p solutions accordingly if needed.

·      =    Should consider variety of solutions, includ= ing directory based, proxy based, or cache based solutions.

·      =    Include analysis of security concerns of IPv= 4 ARP requests from malicious users. Evaluating potential security solutions = and conclude if the security threat can justify solutions.

·      =    ARP222 assumes the direct links to individua= l hosts and virtual machines are IEEE802.3 Ethernet links. <= /p>
·      =    Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure I= P, Ethernet, or others.

·      =    Should consider address resolution solutions= for one VLAN with small number of duplicated IP addresses.

Here are the items whic= h should not be in the scope of the working group:

·      =    Re-define DHCP behavior

·      =    Re-define security concern to IPv6 ND <= /o:p>

·      =    Direct links from hosts and virtual hosts ar= e non Ethernet links

·      =

Goals and Milestones:

·      =    Charter statement

·      =    Problem Statements

·      =    Gap analysis

·      =    Study of NHRP (RFC2332) & SCSP, an= d 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

--_000_5EB1A55E180C914BBC1A49310B76293863830E1610HQ1EXCH02corp_-- From ldunbar@huawei.com Mon Aug 23 14:32:41 2010 Return-Path: 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 0AE143A68F0 for ; Mon, 23 Aug 2010 14:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.054 X-Spam-Level: X-Spam-Status: No, score=-101.054 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_50=0.001, 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 Ypy8H9pFRXX6 for ; Mon, 23 Aug 2010 14:32:27 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id B9EEE3A67B2 for ; Mon, 23 Aug 2010 14:32:26 -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 <0L7M00K4NJUXFI@usaga02-in.huawei.com> for arp222@ietf.org; Mon, 23 Aug 2010 14:32:59 -0700 (PDT) Received: from L735042 ([10.124.12.75]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7M00JEPJURYG@usaga02-in.huawei.com> for arp222@ietf.org; Mon, 23 Aug 2010 14:32:57 -0700 (PDT) Date: Mon, 23 Aug 2010 16:32:51 -0500 From: Linda Dunbar In-reply-to: <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> To: 'Anoop Ghanwani' , arp222@ietf.org Message-id: <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_4ReXmzFnB6lmpBWnlknINA)" Thread-index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPAAATqjsAADikNwAfM9QQA= References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 21:32:41 -0000 This is a multi-part message in MIME format. --Boundary_(ID_4ReXmzFnB6lmpBWnlknINA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Anoop, No, it shouldn't. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 6:19 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Do broadcasts from one client controlled subnet show up in a different client controlled subnet? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Friday, August 13, 2010 2:44 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The scenario is Cloud Computing service selling client controlled (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among those (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address). Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80. Linda Dunbar _____ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: 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 --Boundary_(ID_4ReXmzFnB6lmpBWnlknINA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Anoop, =

No, it shouldn’t. =

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 6:19 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,<= /o:p>

<= /o:p>

Do broadcasts from one client controlled subnet show = up

in a different client controlled subnet?

<= /o:p>

Anoop

<= /o:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Friday, August 13, = 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =

=

The scenario is = Cloud Computing service selling client controlled (virtual) subnets to = clients. All the (virtual) hosts within the client controlled subnets have their own = IP addresses. The communications among those (virtual) hosts are client = specific. There might be same IP addresses in different client controlled subnets. = All those hosts will be assigned as a virtual machine to a physical server = and assigned to a VLAN in the actual network in data center(s). There will = be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address).

=

Linda =

=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 4:02 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Hi Linda,

<= /o:p>

Would it be possible to provide references to actual = protocols

that require duplicate IP addresses behind different MAC = addresses?

<= /o:p>

Anoop

<= /o:p>

From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Friday, August 13, = 2010 12:42 PM
To: arp222@ietf.org
Subject: Re: [arp222] = ARP222 Charter statement and milestones

I forgot to clarify in my previous email that the charter statement and = milestones posted is for soliciting feedback before submitting to IESG to request for a = BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the = Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a = working group by IETF 80.

=

Linda Dunbar

=

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Thursday, August = 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter = statement and milestones

Thank you all for coming to = ARP222 Bar BOF at the 78^th 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

--Boundary_(ID_4ReXmzFnB6lmpBWnlknINA)-- From anoop@brocade.com Mon Aug 23 14:36:07 2010 Return-Path: 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 408F03A6910 for ; Mon, 23 Aug 2010 14:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 VgV7NHxGtMfH for ; Mon, 23 Aug 2010 14:35:57 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id 1023B3A6B0F for ; Mon, 23 Aug 2010 14:35:51 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o7NLTQRP003875; Mon, 23 Aug 2010 14:36:19 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id qv0g400ua-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Aug 2010 14:36:19 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 23 Aug 2010 14:39:27 -0700 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Mon, 23 Aug 2010 14:36:18 -0700 From: Anoop Ghanwani To: Linda Dunbar , "arp222@ietf.org" Date: Mon, 23 Aug 2010 14:36:15 -0700 Thread-Topic: [arp222] ARP222 Charter statement and milestones Thread-Index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPAAATqjsAADikNwAfM9QQAAABBf8A== Message-ID: <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.com> References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> In-Reply-To: <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5EB1A55E180C914BBC1A49310B762938638616B395HQ1EXCH02corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-23_07:2010-08-23, 2010-08-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1008230179 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 21:36:07 -0000 --_000_5EB1A55E180C914BBC1A49310B762938638616B395HQ1EXCH02corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, If it broadcasts from one client controlled subnet do not show up in another client controlled subnet, then this should be a non-issue, no? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Monday, August 23, 2010 2:33 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, No, it shouldn't. Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 6:19 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Do broadcasts from one client controlled subnet show up in a different client controlled subnet? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Friday, August 13, 2010 2:44 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The scenario is Cloud Computing service selling client controlled (virtual)= subnets to clients. All the (virtual) hosts within the client controlled s= ubnets have their own IP addresses. The communications among those (virtual= ) hosts are client specific. There might be same IP addresses in different = client controlled subnets. All those hosts will be assigned as a virtual ma= chine to a physical server and assigned to a VLAN in the actual network in = data center(s). There will be cases when one VLAN ends up having (virtual) = hosts with same IP address (but different MAC address). Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of= Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and mil= estones posted is for soliciting feedback before submitting to IESG to requ= est for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get= your feedback, I will send the Charter Statement and milestones to the Int= ernet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Ou= r target is to have a working group by IETF 80. Linda Dunbar ________________________________ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: ARP222 Charter statement and milestones Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving us c= omments 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 M= achines (20, 30, or hundreds of). Virtual Machines, with its flexible add/d= elete and mobility features, not only makes it possible for achieving bette= r performance and better utilization on servers, they are also a very impor= tant building block for Cloud Computing service to offer virtual subnets an= d virtual hosts. The virtual subnets offered by Cloud Computing service cou= ld 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 an= d 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 thousan= ds of hosts (each with a distinct MAC address) in one Data Center, the amou= nt 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 ce= nter is potentially duplicated IP addresses within one VLAN which will make= traditional ARP or ND not working properly. Some load balance design requi= res multiple hosts serving the same application to have the same IP address= but with different MAC addresses. Cloud Computing service could allow user= s to have their own subnets with IP addresses and self defined policies amo= ng 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 co= uld be duplicated IP addresses which are from different client subnets endi= ng up in one VLAN. The goal of this working group is to develop interoperable solutions to sol= ve those problems. The design should consider the following properties: * All solutions developed by ARP222 WG should not expect any behavi= or changes on hosts, applications, or Virtual Machines being deployed in th= e market. * All solutions developed should not break DHCP. * Evaluating the impact to IPv6 ND, and develop solutions according= ly 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 m= alicious users. Evaluating potential security solutions and conclude if the= security threat can justify solutions. * ARP222 assumes the direct links to individual hosts and virtual m= achines are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconn= ected by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider address resolution solutions for one VLAN with sm= all 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 Ether= net networks * Study and Analysis of MOOSE as a potential solution * Study and Analysis of SEATTLE as a potential solution. Best Regards, Linda Dunbar --_000_5EB1A55E180C914BBC1A49310B762938638616B395HQ1EXCH02corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda,

If it broadcasts from one client controlled subnet do not

show up in another client controlled subnet, then this<= /o:p>

should be a non-issue, no?

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Monday, August 23, 2010 2:33 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

No, it shouldn’t.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Friday, August 13, 2010 6:19 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Linda,<= /p>
<= /p>
Do broadcasts from one cl= ient controlled subnet show up

in a different client controlled subnet?

<= /p>
Anoop
<= /p>

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Friday, August 13, 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The scenario is Cloud Computing service selling client controll= ed (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among th= ose (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address).

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Friday, August 13, 2010 4:02 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Hi Linda,

<= /p>
Would it be possible to provide references to actual protocols

that require duplicate IP addresses behind different MAC addresses?

<= /p>
Anoop
<= /p>

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

I forgot to clarify in my previous email that the charter state= ment and milestones posted is for soliciting feedback before submitting to IESG = to request for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore= , once I get your feedback, I will send the Charter Statement and milestones = to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beiji= ng). Our target is to have a working group by IETF 80.

Linda Dunbar

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Thursday, August 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78^th 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 Resolu= tion 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 performa= nce and better utilization on servers, they are also a very important building block for Cloud Computing service to offer virtual subnets and virtual host= s. 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 thousan= ds 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 ho= sts.

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 traditi= onal 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 whic= h is much more than 4095 VLANs. Under this scenario, there could be duplicated I= P addresses which are from different client subnets ending up in one VLAN.&nb= sp;

The goal of this working group is to develop interoperable solutions to solve t= hose problems.

The design should consi= der the following properties:

·      =    All solutions developed by ARP222 WG should = not expect any behavior changes on hosts, applications, or Virtual Machines bei= ng deployed in the market.

·      =    All solutions developed should not break DHC= P.

·      =    Evaluating the impact to IPv6 ND, and develo= p solutions accordingly if needed.

·      =    Should consider variety of solutions, includ= ing directory based, proxy based, or cache based solutions.

·      =    Include analysis of security concerns of IPv= 4 ARP requests from malicious users. Evaluating potential security solutions = and conclude if the security threat can justify solutions.

·      =    ARP222 assumes the direct links to individua= l hosts and virtual machines are IEEE802.3 Ethernet links. <= /p>
·      =    Should consider scenarios of one Ethernet ne= twork being interconnected by another network, which can be L2VPN, pure IP, Ether= net, or others.

·      =    Should consider address resolution solutions= for one VLAN with small number of duplicated IP addresses.

Here are the items whic= h should not be in the scope of the working group:

·      =    Re-define DHCP behavior

·      =    Re-define security concern to IPv6 ND <= /o:p>

·      =    Direct links from hosts and virtual hosts ar= e non Ethernet links

·      =

Goals and Milestones:

·      =    Charter statement

·      =    Problem Statements

·      =    Gap analysis

·      =    Study of NHRP (RFC2332) & SCSP, an= d 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

--_000_5EB1A55E180C914BBC1A49310B762938638616B395HQ1EXCH02corp_-- From ldunbar@huawei.com Tue Aug 24 12:31:50 2010 Return-Path: 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 5A40D3A69D4 for ; Tue, 24 Aug 2010 12:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 kPV8xyA5FlxX for ; Tue, 24 Aug 2010 12:31:26 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 0C3853A688F for ; Tue, 24 Aug 2010 12:31:26 -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 <0L7O00IBK8XAQC@usaga02-in.huawei.com> for arp222@ietf.org; Tue, 24 Aug 2010 12:31:59 -0700 (PDT) Received: from L735042 ([10.124.12.75]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7O00LQX8X9TP@usaga02-in.huawei.com> for arp222@ietf.org; Tue, 24 Aug 2010 12:31:58 -0700 (PDT) Date: Tue, 24 Aug 2010 14:31:58 -0500 From: Linda Dunbar In-reply-to: <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.com> To: 'Anoop Ghanwani' , arp222@ietf.org Message-id: <000201cb43c3$04a5ce90$4b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_dWz7uX2ZS9ZSzGrTOwNkIQ)" Thread-index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPAAATqjsAADikNwAfM9QQAAABBf8AAt2HcQ References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 19:31:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_dWz7uX2ZS9ZSzGrTOwNkIQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Anoop, The issue of duplicated IP addresses comes up when there are more client controlled subnets than the number of VLANs. The number of client controlled subnets could be in hundreds of thousands, but there are only 4095 VLANs within one Layer 2. Then you might need to assign multiple client controlled subnets in one VLAN. Under this scenario, duplicated IP will be an issue. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Monday, August 23, 2010 4:36 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, If it broadcasts from one client controlled subnet do not show up in another client controlled subnet, then this should be a non-issue, no? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Monday, August 23, 2010 2:33 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, No, it shouldn't. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 6:19 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Do broadcasts from one client controlled subnet show up in a different client controlled subnet? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Friday, August 13, 2010 2:44 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The scenario is Cloud Computing service selling client controlled (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among those (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address). Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80. Linda Dunbar _____ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: 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 --Boundary_(ID_dWz7uX2ZS9ZSzGrTOwNkIQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Anoop, =

The issue of duplicated IP = addresses comes up when there are more client controlled subnets than the number of = VLANs. The number of client controlled subnets could be in hundreds of thousands, = but there are only 4095 VLANs within one Layer 2. Then you might need to = assign multiple client controlled subnets in one VLAN. Under this scenario, = duplicated IP will be an issue.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Monday, August 23, = 2010 4:36 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,<= /o:p>

<= /o:p>

If it broadcasts from one client controlled subnet do = not

show up in another client controlled subnet, then = this

should be a non-issue, no?

<= /o:p>

Anoop

<= /o:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Monday, August 23, = 2010 2:33 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =

=

No, it = shouldn’t.

=

Linda<= /span>

=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 6:19 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,<= /o:p>

<= /o:p>

Do broadcasts from one client controlled subnet show = up

in a different client controlled subnet?

<= /o:p>

Anoop

<= /o:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Friday, August 13, = 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =

=

The scenario is Cloud Computing service selling client controlled (virtual) = subnets to clients. All the (virtual) hosts within the client controlled subnets = have their own IP addresses. The communications among those (virtual) hosts = are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual = machine to a physical server and assigned to a VLAN in the actual network in data = center(s). There will be cases when one VLAN ends up having (virtual) hosts with = same IP address (but different MAC address).

=

Linda =

=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 4:02 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Hi Linda,

<= /o:p>

Would it be possible to provide references to actual = protocols

that require duplicate IP addresses behind different MAC = addresses?

<= /o:p>

Anoop

<= /o:p>

From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Friday, August 13, = 2010 12:42 PM
To: arp222@ietf.org
Subject: Re: [arp222] = ARP222 Charter statement and milestones

I forgot to clarify in my previous email that the charter statement and = milestones posted is for soliciting feedback before submitting to IESG to request = for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the = Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a = working group by IETF 80.

=

Linda Dunbar

=

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Thursday, August = 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter = statement and milestones

Thank you all for coming to = ARP222 Bar BOF at the 78^th 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

--Boundary_(ID_dWz7uX2ZS9ZSzGrTOwNkIQ)-- From anoop@brocade.com Tue Aug 24 13:37:56 2010 Return-Path: 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 5A4973A683E for ; Tue, 24 Aug 2010 13:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 3B6vUDj+UsIS for ; Tue, 24 Aug 2010 13:37:19 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 842653A6A65 for ; Tue, 24 Aug 2010 13:36:46 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o7OKZ15Z002779; Tue, 24 Aug 2010 13:37:02 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id qvmw2g0mc-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Aug 2010 13:37:00 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 24 Aug 2010 13:39:49 -0700 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Tue, 24 Aug 2010 13:36:59 -0700 From: Anoop Ghanwani To: Linda Dunbar , "arp222@ietf.org" Date: Tue, 24 Aug 2010 13:36:56 -0700 Thread-Topic: [arp222] ARP222 Charter statement and milestones Thread-Index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPAAATqjsAADikNwAfM9QQAAABBf8AAt2HcQAAJNoXA= Message-ID: <5EB1A55E180C914BBC1A49310B762938638616B6AB@HQ1-EXCH02.corp.brocade.com> References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.com> <000201cb43c3$04a5ce90$4b0c7c0a@china.huawei.com> In-Reply-To: <000201cb43c3$04a5ce90$4b0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5EB1A55E180C914BBC1A49310B762938638616B6ABHQ1EXCH02corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-24_10:2010-08-24, 2010-08-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1008240145 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 20:37:57 -0000 --_000_5EB1A55E180C914BBC1A49310B762938638616B6ABHQ1EXCH02corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, I think the key piece of information that I'm missing is how the layer 2 forwarding takes place in a particular client-controlled subnet. If it's just regular bridging, we will have leakage of traffic between subnets that are in the same VLAN. In that case, I think it would be hard to solve the duplicate address problem. If there is some kind of new forwarding happens that ensures that there is never leakage between the subnets, and the two subnets never need to talk to each other unless they use a NAT, then there is nothing to be solved...that problem already exists today with VRFs. But I don't know of such a layer 2 device and that's why I was asking for more details. Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Tuesday, August 24, 2010 12:32 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The issue of duplicated IP addresses comes up when there are more client co= ntrolled subnets than the number of VLANs. The number of client controlled = subnets could be in hundreds of thousands, but there are only 4095 VLANs wi= thin one Layer 2. Then you might need to assign multiple client controlled = subnets in one VLAN. Under this scenario, duplicated IP will be an issue. Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Monday, August 23, 2010 4:36 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, If it broadcasts from one client controlled subnet do not show up in another client controlled subnet, then this should be a non-issue, no? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Monday, August 23, 2010 2:33 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, No, it shouldn't. Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 6:19 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Do broadcasts from one client controlled subnet show up in a different client controlled subnet? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Friday, August 13, 2010 2:44 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The scenario is Cloud Computing service selling client controlled (virtual)= subnets to clients. All the (virtual) hosts within the client controlled s= ubnets have their own IP addresses. The communications among those (virtual= ) hosts are client specific. There might be same IP addresses in different = client controlled subnets. All those hosts will be assigned as a virtual ma= chine to a physical server and assigned to a VLAN in the actual network in = data center(s). There will be cases when one VLAN ends up having (virtual) = hosts with same IP address (but different MAC address). Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of= Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and mil= estones posted is for soliciting feedback before submitting to IESG to requ= est for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get= your feedback, I will send the Charter Statement and milestones to the Int= ernet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Ou= r target is to have a working group by IETF 80. Linda Dunbar ________________________________ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: ARP222 Charter statement and milestones Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving us c= omments 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 M= achines (20, 30, or hundreds of). Virtual Machines, with its flexible add/d= elete and mobility features, not only makes it possible for achieving bette= r performance and better utilization on servers, they are also a very impor= tant building block for Cloud Computing service to offer virtual subnets an= d virtual hosts. The virtual subnets offered by Cloud Computing service cou= ld 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 an= d 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 thousan= ds of hosts (each with a distinct MAC address) in one Data Center, the amou= nt 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 ce= nter is potentially duplicated IP addresses within one VLAN which will make= traditional ARP or ND not working properly. Some load balance design requi= res multiple hosts serving the same application to have the same IP address= but with different MAC addresses. Cloud Computing service could allow user= s to have their own subnets with IP addresses and self defined policies amo= ng 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 co= uld be duplicated IP addresses which are from different client subnets endi= ng up in one VLAN. The goal of this working group is to develop interoperable solutions to sol= ve those problems. The design should consider the following properties: * All solutions developed by ARP222 WG should not expect any behavi= or changes on hosts, applications, or Virtual Machines being deployed in th= e market. * All solutions developed should not break DHCP. * Evaluating the impact to IPv6 ND, and develop solutions according= ly 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 m= alicious users. Evaluating potential security solutions and conclude if the= security threat can justify solutions. * ARP222 assumes the direct links to individual hosts and virtual m= achines are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconn= ected by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider address resolution solutions for one VLAN with sm= all 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 Ether= net networks * Study and Analysis of MOOSE as a potential solution * Study and Analysis of SEATTLE as a potential solution. Best Regards, Linda Dunbar --_000_5EB1A55E180C914BBC1A49310B762938638616B6ABHQ1EXCH02corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda,

I think the key piece of information that I’m missing = is how

the layer 2 forwarding takes place in a particular client-controlled

subnet. If it’s just regular bridging, we will h= ave leakage of traffic

between subnets that are in the same VLAN. In that cas= e, I think

it would be hard to solve the duplicate address problem.&nbs= p; If there

is some kind of new forwarding happens that ensures that the= re

is never leakage between the subnets, and the two subnets ne= ver

need to talk to each other unless they use a NAT, then there=

is nothing to be solved...that problem already exists today = with

VRFs. But I don’t know of such a layer 2 device = and that’s why

I was asking for more details.

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Tuesday, August 24, 2010 12:32 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The issue of duplicated IP addresses comes up when there are more client contro= lled subnets than the number of VLANs. The number of client controlled subnets c= ould be in hundreds of thousands, but there are only 4095 VLANs within one Layer= 2. Then you might need to assign multiple client controlled subnets in one VLA= N. Under this scenario, duplicated IP will be an issue.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Monday, August 23, 2010 4:36 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Linda,<= /p>
<= /p>
If it broadcasts from one client controlled subnet do not

show up in another client controlled subnet, then this

should be a non-issue, no= ?

<= /p>
Anoop
<= /p>

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Monday, August 23, 2010 2:33 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

No, it shouldn’t.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Friday, August 13, 2010 6:19 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Linda,<= /p>
<= /p>
Do broadcasts from one cl= ient controlled subnet show up

in a different client controlled subnet?

<= /p>
Anoop
<= /p>

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Friday, August 13, 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The scenario is Cloud Computing service selling client controll= ed (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among th= ose (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address).

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Friday, August 13, 2010 4:02 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Hi Linda,

<= /p>
Would it be possible to provide references to actual protocols

that require duplicate IP addresses behind different MAC addresses?

<= /p>
Anoop
<= /p>

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

I forgot to clarify in my previous email that the charter state= ment and milestones posted is for soliciting feedback before submitting to IESG = to request for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore= , once I get your feedback, I will send the Charter Statement and milestones = to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beiji= ng). Our target is to have a working group by IETF 80.

Linda Dunbar

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Thursday, August 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78^th 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 Resolu= tion 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 performa= nce and better utilization on servers, they are also a very important building block for Cloud Computing service to offer virtual subnets and virtual host= s. 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 d= iscovery (IPv6) requests from hosts. All hosts frequently send out those requests du= e to their cache being aged out in minutes. With tens of thousands of hosts (eac= h 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/seco= nd. 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 traditi= onal 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 beca= use the number of client subnets could be in hundreds of thousands which is muc= h more than 4095 VLANs. Under this scenario, there could be duplicated IP addresses which are from different client subnets ending up in one VLAN.&nb= sp;

The goal of this working group is to develop interoperable solutions to solve t= hose problems.

The design should consi= der the following properties:

·      =    All solutions developed by ARP222 WG should = not expect any behavior changes on hosts, applications, or Virtual Machines bei= ng deployed in the market.

·      =    All solutions developed should not break DHC= P.

·      =    Evaluating the impact to IPv6 ND, and develo= p solutions accordingly if needed.

·      =    Should consider variety of solutions, includ= ing directory based, proxy based, or cache based solutions.

·      =    Include analysis of security concerns of IPv= 4 ARP requests from malicious users. Evaluating potential security solutions = and conclude if the security threat can justify solutions.

·      =    ARP222 assumes the direct links to individua= l hosts and virtual machines are IEEE802.3 Ethernet links. <= /p>
·      =    Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure I= P, Ethernet, or others.

·      =    Should consider address resolution solutions= for one VLAN with small number of duplicated IP addresses.

Here are the items whic= h should not be in the scope of the working group:

·      =    Re-define DHCP behavior

·      =    Re-define security concern to IPv6 ND <= /o:p>

·      =    Direct links from hosts and virtual hosts ar= e non Ethernet links

·      =

Goals and Milestones:

·      =    Charter statement

·      =    Problem Statements

·      =    Gap analysis

·      =    Study of NHRP (RFC2332) & SCSP, an= d 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

--_000_5EB1A55E180C914BBC1A49310B762938638616B6ABHQ1EXCH02corp_-- From ldunbar@huawei.com Tue Aug 24 15:28:26 2010 Return-Path: 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 012FF3A68C3 for ; Tue, 24 Aug 2010 15:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.285, 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 KzHfyP77aRMa for ; Tue, 24 Aug 2010 15:28:14 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 3DC7D3A688B for ; Tue, 24 Aug 2010 15:28:14 -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 <0L7O00BC0H3YJA@usaga02-in.huawei.com> for arp222@ietf.org; Tue, 24 Aug 2010 15:28:47 -0700 (PDT) Received: from L735042 ([10.124.12.75]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7O00BX2H3TS4@usaga02-in.huawei.com> for arp222@ietf.org; Tue, 24 Aug 2010 15:28:46 -0700 (PDT) Date: Tue, 24 Aug 2010 17:28:39 -0500 From: Linda Dunbar In-reply-to: <5EB1A55E180C914BBC1A49310B762938638616B6AB@HQ1-EXCH02.corp.brocade.com> To: 'Anoop Ghanwani' , arp222@ietf.org Message-id: <005901cb43db$b59523a0$4b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_eByi1fNLs0HuJ+X03OFjKw)" Thread-index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPAAATqjsAADikNwAfM9QQAAABBf8AAt2HcQAAJNoXAAA/KkgA== References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.com> <000201cb43c3$04a5ce90$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B6AB@HQ1-EXCH02.corp.brocade.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 22:28:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_eByi1fNLs0HuJ+X03OFjKw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Anoop, I am referring to duplicated IP addresses but with different MAC addresses. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Tuesday, August 24, 2010 3:37 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, I think the key piece of information that I'm missing is how the layer 2 forwarding takes place in a particular client-controlled subnet. If it's just regular bridging, we will have leakage of traffic between subnets that are in the same VLAN. In that case, I think it would be hard to solve the duplicate address problem. If there is some kind of new forwarding happens that ensures that there is never leakage between the subnets, and the two subnets never need to talk to each other unless they use a NAT, then there is nothing to be solved...that problem already exists today with VRFs. But I don't know of such a layer 2 device and that's why I was asking for more details. Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Tuesday, August 24, 2010 12:32 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The issue of duplicated IP addresses comes up when there are more client controlled subnets than the number of VLANs. The number of client controlled subnets could be in hundreds of thousands, but there are only 4095 VLANs within one Layer 2. Then you might need to assign multiple client controlled subnets in one VLAN. Under this scenario, duplicated IP will be an issue. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Monday, August 23, 2010 4:36 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, If it broadcasts from one client controlled subnet do not show up in another client controlled subnet, then this should be a non-issue, no? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Monday, August 23, 2010 2:33 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, No, it shouldn't. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 6:19 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Do broadcasts from one client controlled subnet show up in a different client controlled subnet? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Friday, August 13, 2010 2:44 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The scenario is Cloud Computing service selling client controlled (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among those (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address). Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80. Linda Dunbar _____ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: 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 --Boundary_(ID_eByi1fNLs0HuJ+X03OFjKw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Anoop, =

I am referring to duplicated IP = addresses but with different MAC addresses.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Tuesday, August 24, = 2010 3:37 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,<= /o:p>

<= /o:p>

I think the key piece of information that I’m missing is = how

the layer 2 forwarding takes place in a particular = client-controlled

subnet. = ; If it’s just regular bridging, we will have leakage of = traffic

between subnets that are in the same VLAN. In that case, I = think

it would be hard to solve the duplicate address problem. If = there

is some kind of new forwarding happens that ensures that = there

is never leakage between the subnets, and the two subnets = never

need to talk to each other unless they use a NAT, then = there

is nothing to be solved...that problem already exists today = with

VRFs. But I don’t know of such a layer 2 device and that’s = why

I was asking for more details.

<= /o:p>

Anoop

<= /o:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Tuesday, August 24, = 2010 12:32 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =

=

The issue of = duplicated IP addresses comes up when there are more client controlled subnets than = the number of VLANs. The number of client controlled subnets could be in = hundreds of thousands, but there are only 4095 VLANs within one Layer 2. Then you = might need to assign multiple client controlled subnets in one VLAN. Under = this scenario, duplicated IP will be an issue.

=

Linda =

=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Monday, August 23, = 2010 4:36 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,<= /o:p>

<= /o:p>

If it broadcasts from one client controlled subnet do = not

show up in another client controlled subnet, then = this

should be a non-issue, no?

<= /o:p>

Anoop

<= /o:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Monday, August 23, = 2010 2:33 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =

=

No, it shouldn’t.

=

Linda<= /span>

=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 6:19 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,<= /o:p>

<= /o:p>

Do broadcasts from one client controlled subnet show = up

in a different client controlled subnet?

<= /o:p>

Anoop

<= /o:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Friday, August 13, = 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =

=

The scenario is Cloud Computing service selling client controlled (virtual) = subnets to clients. All the (virtual) hosts within the client controlled subnets = have their own IP addresses. The communications among those (virtual) hosts = are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual = machine to a physical server and assigned to a VLAN in the actual network in data = center(s). There will be cases when one VLAN ends up having (virtual) hosts with = same IP address (but different MAC address).

=

Linda =

=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 4:02 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Hi Linda,

<= /o:p>

Would it be possible to provide references to actual = protocols

that require duplicate IP addresses behind different MAC = addresses?

<= /o:p>

Anoop

<= /o:p>

From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Friday, August 13, = 2010 12:42 PM
To: arp222@ietf.org
Subject: Re: [arp222] = ARP222 Charter statement and milestones

I forgot to clarify in my previous email that the charter statement and = milestones posted is for soliciting feedback before submitting to IESG to request = for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the = Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a = working group by IETF 80.

=

Linda Dunbar

=

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Thursday, August = 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter = statement and milestones

Thank you all for coming to = ARP222 Bar BOF at the 78^th 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

--Boundary_(ID_eByi1fNLs0HuJ+X03OFjKw)-- From anoop@brocade.com Tue Aug 24 15:30:32 2010 Return-Path: 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 433BD3A68D2 for ; Tue, 24 Aug 2010 15:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 hWAQhkNkK1l3 for ; Tue, 24 Aug 2010 15:30:19 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id E34433A6967 for ; Tue, 24 Aug 2010 15:30:17 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o7OMUd3d011692; Tue, 24 Aug 2010 15:30:39 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id qvp72016j-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Aug 2010 15:30:38 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 24 Aug 2010 15:33:45 -0700 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 24 Aug 2010 15:30:37 -0700 From: Anoop Ghanwani To: Linda Dunbar , "arp222@ietf.org" Date: Tue, 24 Aug 2010 15:30:35 -0700 Thread-Topic: [arp222] ARP222 Charter statement and milestones Thread-Index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPAAATqjsAADikNwAfM9QQAAABBf8AAt2HcQAAJNoXAAA/KkgAAAHlOQ Message-ID: <5EB1A55E180C914BBC1A49310B762938638616B740@HQ1-EXCH02.corp.brocade.com> References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.com> <000201cb43c3$04a5ce90$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B6AB@HQ1-EXCH02.corp.brocade.com> <005901cb43db$b59523a0$4b0c7c0a@china.huawei.com> In-Reply-To: <005901cb43db$b59523a0$4b0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5EB1A55E180C914BBC1A49310B762938638616B740HQ1EXCH02corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-24_12:2010-08-25, 2010-08-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1008240164 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 22:30:32 -0000 --_000_5EB1A55E180C914BBC1A49310B762938638616B740HQ1EXCH02corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, Yes, I understand...and the concerns in my previous reply are with that in mind. Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Tuesday, August 24, 2010 3:29 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, I am referring to duplicated IP addresses but with different MAC addresses. Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Tuesday, August 24, 2010 3:37 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, I think the key piece of information that I'm missing is how the layer 2 forwarding takes place in a particular client-controlled subnet. If it's just regular bridging, we will have leakage of traffic between subnets that are in the same VLAN. In that case, I think it would be hard to solve the duplicate address problem. If there is some kind of new forwarding happens that ensures that there is never leakage between the subnets, and the two subnets never need to talk to each other unless they use a NAT, then there is nothing to be solved...that problem already exists today with VRFs. But I don't know of such a layer 2 device and that's why I was asking for more details. Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Tuesday, August 24, 2010 12:32 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The issue of duplicated IP addresses comes up when there are more client co= ntrolled subnets than the number of VLANs. The number of client controlled = subnets could be in hundreds of thousands, but there are only 4095 VLANs wi= thin one Layer 2. Then you might need to assign multiple client controlled = subnets in one VLAN. Under this scenario, duplicated IP will be an issue. Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Monday, August 23, 2010 4:36 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, If it broadcasts from one client controlled subnet do not show up in another client controlled subnet, then this should be a non-issue, no? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Monday, August 23, 2010 2:33 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, No, it shouldn't. Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 6:19 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Do broadcasts from one client controlled subnet show up in a different client controlled subnet? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Friday, August 13, 2010 2:44 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The scenario is Cloud Computing service selling client controlled (virtual)= subnets to clients. All the (virtual) hosts within the client controlled s= ubnets have their own IP addresses. The communications among those (virtual= ) hosts are client specific. There might be same IP addresses in different = client controlled subnets. All those hosts will be assigned as a virtual ma= chine to a physical server and assigned to a VLAN in the actual network in = data center(s). There will be cases when one VLAN ends up having (virtual) = hosts with same IP address (but different MAC address). Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of= Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and mil= estones posted is for soliciting feedback before submitting to IESG to requ= est for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get= your feedback, I will send the Charter Statement and milestones to the Int= ernet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Ou= r target is to have a working group by IETF 80. Linda Dunbar ________________________________ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: ARP222 Charter statement and milestones Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving us c= omments 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 M= achines (20, 30, or hundreds of). Virtual Machines, with its flexible add/d= elete and mobility features, not only makes it possible for achieving bette= r performance and better utilization on servers, they are also a very impor= tant building block for Cloud Computing service to offer virtual subnets an= d virtual hosts. The virtual subnets offered by Cloud Computing service cou= ld 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 an= d 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 thousan= ds of hosts (each with a distinct MAC address) in one Data Center, the amou= nt 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 ce= nter is potentially duplicated IP addresses within one VLAN which will make= traditional ARP or ND not working properly. Some load balance design requi= res multiple hosts serving the same application to have the same IP address= but with different MAC addresses. Cloud Computing service could allow user= s to have their own subnets with IP addresses and self defined policies amo= ng 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 co= uld be duplicated IP addresses which are from different client subnets endi= ng up in one VLAN. The goal of this working group is to develop interoperable solutions to sol= ve those problems. The design should consider the following properties: * All solutions developed by ARP222 WG should not expect any behavi= or changes on hosts, applications, or Virtual Machines being deployed in th= e market. * All solutions developed should not break DHCP. * Evaluating the impact to IPv6 ND, and develop solutions according= ly 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 m= alicious users. Evaluating potential security solutions and conclude if the= security threat can justify solutions. * ARP222 assumes the direct links to individual hosts and virtual m= achines are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconn= ected by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider address resolution solutions for one VLAN with sm= all 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 Ether= net networks * Study and Analysis of MOOSE as a potential solution * Study and Analysis of SEATTLE as a potential solution. Best Regards, Linda Dunbar --_000_5EB1A55E180C914BBC1A49310B762938638616B740HQ1EXCH02corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda,

Yes, I understand...and the concerns in my previous reply

are with that in mind.

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Tuesday, August 24, 2010 3:29 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

I am referring to duplicated IP addresses but with different MAC addresses. <= o:p>

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Tuesday, August 24, 2010 3:37 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Linda,<= /p>
<= /p>
I think the key piece of information that I’m missing is how

the layer 2 forwarding ta= kes place in a particular client-controlled

subnet. If it’= ;s just regular bridging, we will have leakage of traffic

between subnets that are = in the same VLAN. In that case, I think

it would be hard to solve= the duplicate address problem. If there

is some kind of new forwarding happens that ensures that there

is never leakage between = the subnets, and the two subnets never

need to talk to each othe= r unless they use a NAT, then there

is nothing to be solved...that problem already exists today with

VRFs. But I donR= 17;t know of such a layer 2 device and that’s why

I was asking for more details.

<= /p>
Anoop
<= /p>

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Tuesday, August 24, 2010 12:32 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The issue of duplicated IP addresses comes up when there are mo= re client controlled subnets than the number of VLANs. The number of client controlled subnets could be in hundreds of thousands, but there are only 40= 95 VLANs within one Layer 2. Then you might need to assign multiple client controlled subnets in one VLAN. Under this scenario, duplicated IP will be = an issue.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Monday, August 23, 2010 4:36 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Linda,<= /p>
<= /p>
If it broadcasts from one client controlled subnet do not

show up in another client controlled subnet, then this

should be a non-issue, no= ?

<= /p>
Anoop
<= /p>

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Monday, August 23, 2010 2:33 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

No, it shouldn’t.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Friday, August 13, 2010 6:19 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Linda,<= /p>
<= /p>
Do broadcasts from one cl= ient controlled subnet show up

in a different client controlled subnet?

<= /p>
Anoop
<= /p>

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Friday, August 13, 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The scenario is Cloud Computing service selling client controll= ed (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among th= ose (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address).

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Friday, August 13, 2010 4:02 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Hi Linda,

<= /p>
Would it be possible to provide references to actual protocols

that require duplicate IP addresses behind different MAC addresses?

<= /p>
Anoop
<= /p>

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

I forgot to clarify in my previous email that the charter state= ment and milestones posted is for soliciting feedback before submitting to IESG = to request for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore= , once I get your feedback, I will send the Charter Statement and milestones = to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beiji= ng). Our target is to have a working group by IETF 80.

Linda Dunbar

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Thursday, August 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78^th 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 Resolu= tion 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 performa= nce and better utilization on servers, they are also a very important building block for Cloud Computing service to offer virtual subnets and virtual host= s. 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 thousan= ds 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 traditi= onal 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 whic= h is much more than 4095 VLANs. Under this scenario, there could be duplicated I= P addresses which are from different client subnets ending up in one VLAN.&nb= sp;

The goal of this working group is to develop interoperable solutions to solve t= hose problems.

The design should consi= der the following properties:

·      =    All solutions developed by ARP222 WG should = not expect any behavior changes on hosts, applications, or Virtual Machines bei= ng deployed in the market.

·      =    All solutions developed should not break DHC= P.

·      =    Evaluating the impact to IPv6 ND, and develo= p solutions accordingly if needed.

·      =    Should consider variety of solutions, includ= ing directory based, proxy based, or cache based solutions.

·      =    Include analysis of security concerns of IPv= 4 ARP requests from malicious users. Evaluating potential security solutions = and conclude if the security threat can justify solutions.

·      =    ARP222 assumes the direct links to individua= l hosts and virtual machines are IEEE802.3 Ethernet links. <= /p>
·      =    Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure I= P, Ethernet, or others.

·      =    Should consider address resolution solutions= for one VLAN with small number of duplicated IP addresses.

Here are the items whic= h should not be in the scope of the working group:

·      =    Re-define DHCP behavior

·      =    Re-define security concern to IPv6 ND <= /o:p>

·      =    Direct links from hosts and virtual hosts ar= e non Ethernet links

·      =

Goals and Milestones:

·      =    Charter statement

·      =    Problem Statements

·      =    Gap analysis

·      =    Study of NHRP (RFC2332) & SCSP, an= d 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

--_000_5EB1A55E180C914BBC1A49310B762938638616B740HQ1EXCH02corp_-- From bensons@queuefull.net Tue Aug 24 17:39:07 2010 Return-Path: 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 7F8443A688E for ; Tue, 24 Aug 2010 17:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 66nB3T7QPyWg for ; Tue, 24 Aug 2010 17:39:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BC0443A696B for ; Tue, 24 Aug 2010 17:39:02 -0700 (PDT) Received: by iwn3 with SMTP id 3so58961iwn.31 for ; Tue, 24 Aug 2010 17:39:35 -0700 (PDT) Received: by 10.231.149.12 with SMTP id r12mr9229980ibv.185.1282696775141; Tue, 24 Aug 2010 17:39:35 -0700 (PDT) Received: from [192.168.1.105] (24-241-105-11.static.stls.mo.charter.com [24.241.105.11]) by mx.google.com with ESMTPS id n20sm631266ibe.11.2010.08.24.17.39.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 17:39:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-27--553106133 From: Benson Schliesser In-Reply-To: <005901cb43db$b59523a0$4b0c7c0a@china.huawei.com> Date: Tue, 24 Aug 2010 19:39:31 -0500 Message-Id: <5B40D077-0171-4316-8606-4F26DC611EA1@queuefull.net> References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.com> <000201cb43c3$04a5ce90$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B6AB@HQ1-EXCH02.corp.brocade.com> <005901cb43db$b59523a0$4b0c7c0a@china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1081) Cc: arp222@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 00:39:07 -0000 --Apple-Mail-27--553106133 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is pretty much what a VLAN solves for you; it multiplexes = link-layer segments. The scenario you've described is missing an abstraction layer. You're = apparently trying to get around the need for VLANs, rather than improve = their scale. I'd suggest this really is not the right way to think = about VLAN scale limitations. Cheers, -Benson On 24 Aug 10, at 5:28 PM, Linda Dunbar wrote: > Anoop, > =20 > I am referring to duplicated IP addresses but with different MAC = addresses. > =20 > Linda > =20 > From: Anoop Ghanwani [mailto:anoop@brocade.com]=20 > Sent: Tuesday, August 24, 2010 3:37 PM > To: Linda Dunbar; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Linda, > =20 > I think the key piece of information that I=92m missing is how > the layer 2 forwarding takes place in a particular client-controlled > subnet. If it=92s just regular bridging, we will have leakage of = traffic > between subnets that are in the same VLAN. In that case, I think > it would be hard to solve the duplicate address problem. If there > is some kind of new forwarding happens that ensures that there > is never leakage between the subnets, and the two subnets never > need to talk to each other unless they use a NAT, then there > is nothing to be solved...that problem already exists today with > VRFs. But I don=92t know of such a layer 2 device and that=92s why > I was asking for more details. > =20 > Anoop > =20 > From: Linda Dunbar [mailto:ldunbar@huawei.com]=20 > Sent: Tuesday, August 24, 2010 12:32 PM > To: Anoop Ghanwani; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Anoop, > =20 > The issue of duplicated IP addresses comes up when there are more = client controlled subnets than the number of VLANs. The number of client = controlled subnets could be in hundreds of thousands, but there are only = 4095 VLANs within one Layer 2. Then you might need to assign multiple = client controlled subnets in one VLAN. Under this scenario, duplicated = IP will be an issue. > =20 > Linda > =20 > From: Anoop Ghanwani [mailto:anoop@brocade.com]=20 > Sent: Monday, August 23, 2010 4:36 PM > To: Linda Dunbar; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Linda, > =20 > If it broadcasts from one client controlled subnet do not > show up in another client controlled subnet, then this > should be a non-issue, no? > =20 > Anoop > =20 > From: Linda Dunbar [mailto:ldunbar@huawei.com]=20 > Sent: Monday, August 23, 2010 2:33 PM > To: Anoop Ghanwani; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Anoop, > =20 > No, it shouldn=92t. > =20 > Linda > =20 > From: Anoop Ghanwani [mailto:anoop@brocade.com]=20 > Sent: Friday, August 13, 2010 6:19 PM > To: Linda Dunbar; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Linda, > =20 > Do broadcasts from one client controlled subnet show up > in a different client controlled subnet? > =20 > Anoop > =20 > From: Linda Dunbar [mailto:ldunbar@huawei.com]=20 > Sent: Friday, August 13, 2010 2:44 PM > To: Anoop Ghanwani; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Anoop, > =20 > The scenario is Cloud Computing service selling client controlled = (virtual) subnets to clients. All the (virtual) hosts within the client = controlled subnets have their own IP addresses. The communications among = those (virtual) hosts are client specific. There might be same IP = addresses in different client controlled subnets. All those hosts will = be assigned as a virtual machine to a physical server and assigned to a = VLAN in the actual network in data center(s). There will be cases when = one VLAN ends up having (virtual) hosts with same IP address (but = different MAC address). > =20 > Linda > =20 > From: Anoop Ghanwani [mailto:anoop@brocade.com]=20 > Sent: Friday, August 13, 2010 4:02 PM > To: Linda Dunbar; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Hi Linda, > =20 > Would it be possible to provide references to actual protocols > that require duplicate IP addresses behind different MAC addresses? > =20 > Anoop > =20 > From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On = Behalf Of Linda Dunbar > Sent: Friday, August 13, 2010 12:42 PM > To: arp222@ietf.org > Subject: Re: [arp222] ARP222 Charter statement and milestones > =20 > I forgot to clarify in my previous email that the charter statement = and milestones posted is for soliciting feedback before submitting to = IESG to request for a BOF for IETF79 (Beijing). =20 > We think the problem domain belongs to Internet Area. Therefore, once = I get your feedback, I will send the Charter Statement and milestones to = the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 = (Beijing). Our target is to have a working group by IETF 80. =20 > =20 > Linda Dunbar > =20 > From: Linda Dunbar [mailto:ldunbar@huawei.com]=20 > Sent: Thursday, August 12, 2010 6:14 PM > To: 'arp222@ietf.org' > Subject: ARP222 Charter statement and milestones > =20 > Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving = us comments and suggestions on and between sessions. > =20 > I put together the initial ARP222 Charter Statement and Milestones. = Please provide comments and suggestions. =20 > =20 > =20 > =20 > =20 > ARP 222: Address Resolution Protocol for Layer 2 to Anything to Layer = 2 > =20 > 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. >=20 > 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. >=20 > 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.=20 >=20 > The goal of this working group is to develop interoperable solutions = to solve those problems.=20 >=20 > The design should consider the following properties: > =B7 All solutions developed by ARP222 WG should not expect any = behavior changes on hosts, applications, or Virtual Machines being = deployed in the market. > =B7 All solutions developed should not break DHCP. > =B7 Evaluating the impact to IPv6 ND, and develop solutions = accordingly if needed. > =B7 Should consider variety of solutions, including directory = based, proxy based, or cache based solutions. > =B7 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. > =B7 ARP222 assumes the direct links to individual hosts and = virtual machines are IEEE802.3 Ethernet links.=20 > =B7 Should consider scenarios of one Ethernet network being = interconnected by another network, which can be L2VPN, pure IP, = Ethernet, or others. > =B7 Should consider address resolution solutions for one VLAN = with small number of duplicated IP addresses.=20 > =20 > Here are the items which should not be in the scope of the working = group: > =B7 Re-define DHCP behavior > =B7 Re-define security concern to IPv6 ND > =B7 Direct links from hosts and virtual hosts are non Ethernet = links > =B7 =20 > =20 > Goals and Milestones: > =B7 Charter statement > =B7 Problem Statements > =B7 Gap analysis > =B7 Study of NHRP (RFC2332) & SCSP, and their applicability to = Ethernet networks > =B7 Study and Analysis of MOOSE as a potential solution > =B7 Study and Analysis of SEATTLE as a potential solution. > =20 > =20 > Best Regards, Linda Dunbar > =20 > _______________________________________________ > arp222 mailing list > arp222@ietf.org > https://www.ietf.org/mailman/listinfo/arp222 --Apple-Mail-27--553106133 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 This = is pretty much what a VLAN solves for you; it multiplexes link-layer = segments.

The scenario you've described is missing an = abstraction layer. You're apparently trying to get around the need = for VLANs, rather than improve their scale. I'd suggest this = really is not the right way to think about VLAN scale = limitations.

Cheers,
-Benson

On 24 Aug 10, at 5:28 PM, Linda = Dunbar wrote:

=

Anoop, =

I am referring to duplicated IP = addresses but with different MAC addresses.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Tuesday, August 24, = 2010 3:37 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,

I think the key piece of information that I=92m missing is = how
the layer 2 forwarding takes place in a particular = client-controlled
subnet. = If it=92s just regular bridging, we will have leakage of = traffic
between subnets that are in the same VLAN. In that case, I = think
it would be hard to solve the duplicate address problem. If = there
is some kind of new forwarding happens that ensures that = there
is never leakage between the subnets, and the two subnets = never
need to talk to each other unless they use a NAT, then = there
is nothing to be solved...that problem already exists today = with
VRFs. But I don=92t know of such a layer 2 device and that=92s = why
I was asking for more details.

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Tuesday, August 24, = 2010 12:32 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =
<= /span>
The issue of = duplicated IP addresses comes up when there are more client controlled subnets than = the number of VLANs. The number of client controlled subnets could be in = hundreds of thousands, but there are only 4095 VLANs within one Layer 2. Then you = might need to assign multiple client controlled subnets in one VLAN. Under = this scenario, duplicated IP will be an issue. =
<= /span>
Linda =
<= /span>

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Monday, August 23, = 2010 4:36 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,

If it broadcasts from one client controlled subnet do = not
show up in another client controlled subnet, then = this
should be a non-issue, no?

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Monday, August 23, = 2010 2:33 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =
<= /span>
No, it shouldn=92t.
<= /span>
Linda
<= /span>

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 6:19 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,

Do broadcasts from one client controlled subnet show = up
in a different client controlled subnet?

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Friday, August 13, = 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =
<= /span>
The scenario is Cloud Computing service selling client controlled (virtual) = subnets to clients. All the (virtual) hosts within the client controlled subnets = have their own IP addresses. The communications among those (virtual) hosts = are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual = machine to a physical server and assigned to a VLAN in the actual network in data = center(s). There will be cases when one VLAN ends up having (virtual) hosts with = same IP address (but different MAC address).
<= /span>
Linda =
<= /span>

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 4:02 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Hi Linda,

Would it be possible to provide references to actual = protocols
that require duplicate IP addresses behind different MAC = addresses?

Anoop

From: arp222-bounces@ietf.org = [mailto:arp222-bounces@ietf.org] On = Behalf Of Linda Dunbar
Sent: Friday, August 13, = 2010 12:42 PM
To: arp222@ietf.org
Subject: Re: [arp222] = ARP222 Charter statement and milestones

I forgot to clarify in my previous email that the charter statement and = milestones posted is for soliciting feedback before submitting to IESG to request = for a BOF for IETF79 (Beijing).
We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the = Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our = target is to have a working group by IETF 80.
<= /span>
Linda Dunbar
<= /span>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Thursday, August = 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter = statement and milestones

Thank you all for coming to = ARP222 Bar BOF at the 78^th 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:
=B7        All solutions developed by ARP222 WG should not expect any behavior changes on hosts, applications, or = Virtual Machines being deployed in the market.
=B7        All solutions developed should not break DHCP.
=B7        Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed.
=B7        Should consider variety of solutions, including directory based, proxy based, or cache based = solutions.
=B7        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.
=B7        ARP222 assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet = links.
=B7        Should consider scenarios of one Ethernet network being interconnected by another network, which can be = L2VPN, pure IP, Ethernet, or others.
=B7        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: =
=B7        Re-define DHCP = behavior
=B7        Re-define security concern to IPv6 ND
=B7        Direct links from hosts and virtual hosts are non Ethernet links
=B7

Goals and Milestones:
=B7        Charter statement
=B7        Problem Statements
=B7        Gap analysis
=B7        Study of NHRP (RFC2332) & SCSP, and their applicability to Ethernet = networks
=B7        Study and Analysis of MOOSE as a potential solution
=B7        Study and Analysis of SEATTLE as a potential solution.

Best Regards, Linda Dunbar
=

_______________________________________________
arp222 mailing = list
arp222@ietf.org
https://www.ietf.or= g/mailman/listinfo/arp222

= --Apple-Mail-27--553106133-- From ldunbar@huawei.com Thu Aug 26 08:03:55 2010 Return-Path: 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 C83E33A697D for ; Thu, 26 Aug 2010 08:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.12 X-Spam-Level: X-Spam-Status: No, score=-101.12 tagged_above=-999 required=5 tests=[AWL=-0.936, BAYES_40=-0.185, 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 gS5OHOMVKenl for ; Thu, 26 Aug 2010 08:03:41 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 971923A67ED for ; Thu, 26 Aug 2010 08:03:41 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7R009JGLV09N@usaga04-in.huawei.com> for arp222@ietf.org; Thu, 26 Aug 2010 10:04:12 -0500 (CDT) Received: from L735042 ([10.124.12.75]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7R00BO8LUY8D@usaga04-in.huawei.com> for arp222@ietf.org; Thu, 26 Aug 2010 10:04:12 -0500 (CDT) Date: Thu, 26 Aug 2010 10:04:09 -0500 From: Linda Dunbar In-reply-to: <5EB1A55E180C914BBC1A49310B762938638616B740@HQ1-EXCH02.corp.brocade.com> To: 'Anoop Ghanwani' , arp222@ietf.org Message-id: <000f01cb452f$f00ceef0$4b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_u2SR3kgcRHd6wxFkU4cQKA)" Thread-index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPAAATqjsAADikNwAfM9QQAAABBf8AAt2HcQAAJNoXAAA/KkgAAAHlOQAFRasuA= References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.com> <000201cb43c3$04a5ce90$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B6AB@HQ1-EXCH02.corp.brocade.com> <005901cb43db$b59523a0$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B740@HQ1-EXCH02.corp.brocade.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 15:03:56 -0000 This is a multi-part message in MIME format. --Boundary_(ID_u2SR3kgcRHd6wxFkU4cQKA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Anoop, First of all, the main objective of ARP222 is to develop interoperable solution(s) for address resolution for massive number of (virtual) hosts (or nodes) in one broadcast domain. The possible occurrence of duplicated IP addresses among some hosts is by no means the main objective. It is from our cloud computing group indicating that it would make their resource management much easier if occasional duplicated IP addresses among some hosts are allowed within one VLAN. Here are their reasons: * There could be many Client Controlled subnets; the number could be in the magnitude of tens or hundreds of thousands. There is huge difference in the number of (virtual) hosts which client subnets have; Some client subnets can have a few virtual hosts, all of them require very low computation demand, and some client subnets can have very large number of (virtual) hosts and require very high computation power. * If each client subnet is only mapped to one VLAN, then each layer 2 can only support up to 4095 clients. The physical servers and network gears in each layer 2 don't change very often. But the client subnets come and go very frequently. With virtualized servers, you can easily have more than 5000 VMs under each Top of Rack Switch. Requiring each TOR to support NAT is not realistic. * Therefore, restricting one dedicated VLAN for each client can cause some L2 network & servers under utilized and others over utilized. Making it difficult for Resource Management. Back in ATM days, there were RFC2333 (NHRP) and RFC2334 (SCSP) which use distributed servers to resolve addresses. If the similar approach is used for resolving MAC addresses, then duplicated IP address within one VLAN shouldn't be an issue (as long as they all have distinct MAC addresses). Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Tuesday, August 24, 2010 5:31 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Yes, I understand...and the concerns in my previous reply are with that in mind. Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Tuesday, August 24, 2010 3:29 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, I am referring to duplicated IP addresses but with different MAC addresses. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Tuesday, August 24, 2010 3:37 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, I think the key piece of information that I'm missing is how the layer 2 forwarding takes place in a particular client-controlled subnet. If it's just regular bridging, we will have leakage of traffic between subnets that are in the same VLAN. In that case, I think it would be hard to solve the duplicate address problem. If there is some kind of new forwarding happens that ensures that there is never leakage between the subnets, and the two subnets never need to talk to each other unless they use a NAT, then there is nothing to be solved...that problem already exists today with VRFs. But I don't know of such a layer 2 device and that's why I was asking for more details. Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Tuesday, August 24, 2010 12:32 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The issue of duplicated IP addresses comes up when there are more client controlled subnets than the number of VLANs. The number of client controlled subnets could be in hundreds of thousands, but there are only 4095 VLANs within one Layer 2. Then you might need to assign multiple client controlled subnets in one VLAN. Under this scenario, duplicated IP will be an issue. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Monday, August 23, 2010 4:36 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, If it broadcasts from one client controlled subnet do not show up in another client controlled subnet, then this should be a non-issue, no? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Monday, August 23, 2010 2:33 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, No, it shouldn't. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 6:19 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Do broadcasts from one client controlled subnet show up in a different client controlled subnet? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Friday, August 13, 2010 2:44 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The scenario is Cloud Computing service selling client controlled (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among those (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address). Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80. Linda Dunbar _____ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: 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 --Boundary_(ID_u2SR3kgcRHd6wxFkU4cQKA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Anoop, =

First of all, the main objective of = ARP222 is to develop interoperable solution(s) for address resolution for = massive number of (virtual) hosts (or nodes) in one broadcast domain. The = possible occurrence of duplicated IP addresses among some hosts is by no means the main = objective.

It is from our cloud computing = group indicating that it would make their resource management much easier if = occasional duplicated IP addresses among some hosts are allowed within one VLAN. = Here are their reasons:

There could be many Client Controlled subnets; the number could be in the magnitude of tens or hundreds of thousands. There is huge = difference in the number of (virtual) hosts which client subnets have; Some = client subnets can have a few virtual hosts, all of them require very low computation demand, and some client subnets can have very large = number of (virtual) hosts and require very high computation power. =

If each client subnet is only mapped to one VLAN, then each layer 2 = can only support up to 4095 clients. The physical servers and network gears = in each layer 2 don’t change very often. But the client subnets come = and go very frequently. With virtualized servers, you can easily have more = than 5000 VMs under each Top of Rack Switch. Requiring each TOR to = support NAT is not realistic.

Therefore, restricting one dedicated VLAN for each client can cause some L2 = network & servers under utilized and others over utilized. Making it = difficult for Resource Management.

Back in ATM days, there were = RFC2333 (NHRP) and RFC2334 (SCSP) which use distributed servers to resolve = addresses. If the similar approach is used for resolving MAC addresses, then = duplicated IP address within one VLAN shouldn’t be an issue (as long as they all = have distinct MAC addresses).

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Tuesday, August 24, = 2010 5:31 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,<= /o:p>

<= /o:p>

Yes, I understand...and the concerns in my previous = reply

are with that in mind.

<= /o:p>

Anoop

<= /o:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Tuesday, August 24, = 2010 3:29 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =

=

I am referring = to duplicated IP addresses but with different MAC addresses. =

=

Linda<= /span>

=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Tuesday, August 24, = 2010 3:37 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,<= /o:p>

<= /o:p>

I think the key piece of information that I’m missing is = how

the layer 2 forwarding takes place in a particular = client-controlled

subnet. = ; If it’s just regular bridging, we will have leakage of = traffic

between subnets that are in the same VLAN. In that case, I = think

it would be hard to solve the duplicate address problem. If = there

is some kind of new forwarding happens that ensures that = there

is never leakage between the subnets, and the two subnets = never

need to talk to each other unless they use a NAT, then = there

is nothing to be solved...that problem already exists today = with

VRFs. But I don’t know of such a layer 2 device and that’s = why

I was asking for more details.

<= /o:p>

Anoop

<= /o:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Tuesday, August 24, = 2010 12:32 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =

=

The issue of duplicated IP addresses comes up when there are more client = controlled subnets than the number of VLANs. The number of client controlled = subnets could be in hundreds of thousands, but there are only 4095 VLANs within one = Layer 2. Then you might need to assign multiple client controlled subnets in one = VLAN. Under this scenario, duplicated IP will be an issue. =

=

Linda =

=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Monday, August 23, = 2010 4:36 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,<= /o:p>

<= /o:p>

If it broadcasts from one client controlled subnet do = not

show up in another client controlled subnet, then = this

should be a non-issue, no?

<= /o:p>

Anoop

<= /o:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Monday, August 23, = 2010 2:33 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =

=

No, it shouldn’t.

=

Linda<= /span>

=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 6:19 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Linda,<= /o:p>

<= /o:p>

Do broadcasts from one client controlled subnet show = up

in a different client controlled subnet?

<= /o:p>

Anoop

<= /o:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Friday, August 13, = 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Anoop, =

=

The scenario is Cloud Computing service selling client controlled (virtual) = subnets to clients. All the (virtual) hosts within the client controlled subnets = have their own IP addresses. The communications among those (virtual) hosts = are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual = machine to a physical server and assigned to a VLAN in the actual network in data = center(s). There will be cases when one VLAN ends up having (virtual) hosts with = same IP address (but different MAC address).

=

Linda =

=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 4:02 PM
To: Linda Dunbar; = arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and milestones

Hi Linda,

<= /o:p>

Would it be possible to provide references to actual = protocols

that require duplicate IP addresses behind different MAC = addresses?

<= /o:p>

Anoop

<= /o:p>

From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Friday, August 13, = 2010 12:42 PM
To: arp222@ietf.org
Subject: Re: [arp222] = ARP222 Charter statement and milestones

I forgot to clarify in my previous email that the charter statement and = milestones posted is for soliciting feedback before submitting to IESG to request = for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the = Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a = working group by IETF 80.

=

Linda Dunbar

=

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Thursday, August = 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter = statement and milestones

Thank you all for coming to = ARP222 Bar BOF at the 78^th 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

--Boundary_(ID_u2SR3kgcRHd6wxFkU4cQKA)-- From ldunbar@huawei.com Thu Aug 26 08:38:39 2010 Return-Path: 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 826AD3A69E4 for ; Thu, 26 Aug 2010 08:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.284 X-Spam-Level: X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[AWL=0.314, 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 ViP2XgK+TA9R for ; Thu, 26 Aug 2010 08:38:25 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id B50403A6994 for ; Thu, 26 Aug 2010 08:38:22 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7R009YDNGU9N@usaga04-in.huawei.com> for arp222@ietf.org; Thu, 26 Aug 2010 10:38:55 -0500 (CDT) Received: from L735042 ([10.124.12.75]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7R00BC8NGS8D@usaga04-in.huawei.com> for arp222@ietf.org; Thu, 26 Aug 2010 10:38:54 -0500 (CDT) Date: Thu, 26 Aug 2010 10:38:52 -0500 From: Linda Dunbar In-reply-to: <5B40D077-0171-4316-8606-4F26DC611EA1@queuefull.net> To: 'Benson Schliesser' Message-id: <003001cb4534$c9f629c0$4b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_/Q+pMqBtmkHHw9ePGWC8zA)" Thread-index: ActD7iRFQr0cG+XoTPqjf5ef4htkIwBPwHWQ References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.com> <000201cb43c3$04a5ce90$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B6AB@HQ1-EXCH02.corp.brocade.com> <005901cb43db$b59523a0$4b0c7c0a@china.huawei.com> <5B40D077-0171-4316-8606-4F26DC611EA1@queuefull.net> Cc: arp222@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 15:38:39 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/Q+pMqBtmkHHw9ePGWC8zA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Benson, Definitely VLAN should be used to differentiate different subnets. In the Cloud Computing environment, client subnets are added and removed very frequently and the number of (virtual) hosts in client subnets is very different. If each client subnet is mapped to one VLAN, then each layer 2 can only support up to 4095 clients The physical servers and network gears in each Layer 2 don't change very often. But the client subnets come and go very frequently. Therefore, restricting one dedicated VLAN for each client can cause some servers/network under utilized and others over loaded. Linda _____ From: Benson Schliesser [mailto:bensons@queuefull.net] Sent: Tuesday, August 24, 2010 7:40 PM To: Linda Dunbar Cc: 'Anoop Ghanwani'; arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones This is pretty much what a VLAN solves for you; it multiplexes link-layer segments. The scenario you've described is missing an abstraction layer. You're apparently trying to get around the need for VLANs, rather than improve their scale. I'd suggest this really is not the right way to think about VLAN scale limitations. Cheers, -Benson On 24 Aug 10, at 5:28 PM, Linda Dunbar wrote: Anoop, I am referring to duplicated IP addresses but with different MAC addresses. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Tuesday, August 24, 2010 3:37 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, I think the key piece of information that I'm missing is how the layer 2 forwarding takes place in a particular client-controlled subnet. If it's just regular bridging, we will have leakage of traffic between subnets that are in the same VLAN. In that case, I think it would be hard to solve the duplicate address problem. If there is some kind of new forwarding happens that ensures that there is never leakage between the subnets, and the two subnets never need to talk to each other unless they use a NAT, then there is nothing to be solved...that problem already exists today with VRFs. But I don't know of such a layer 2 device and that's why I was asking for more details. Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Tuesday, August 24, 2010 12:32 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The issue of duplicated IP addresses comes up when there are more client controlled subnets than the number of VLANs. The number of client controlled subnets could be in hundreds of thousands, but there are only 4095 VLANs within one Layer 2. Then you might need to assign multiple client controlled subnets in one VLAN. Under this scenario, duplicated IP will be an issue. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Monday, August 23, 2010 4:36 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, If it broadcasts from one client controlled subnet do not show up in another client controlled subnet, then this should be a non-issue, no? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Monday, August 23, 2010 2:33 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, No, it shouldn't. Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 6:19 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Do broadcasts from one client controlled subnet show up in a different client controlled subnet? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Friday, August 13, 2010 2:44 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The scenario is Cloud Computing service selling client controlled (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among those (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address). Linda _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80. Linda Dunbar _____ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: 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 _______________________________________________ arp222 mailing list arp222@ietf.org https://www.ietf.org/mailman/listinfo/arp222 --Boundary_(ID_/Q+pMqBtmkHHw9ePGWC8zA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Benson,

Definitely VLAN should be used to differentiate different subnets.

In the Cloud Computing environment, client subnets are added and removed very frequently and the number of (virtual) hosts in client subnets is very different.

If each client subnet is mapped to one VLAN, then each layer 2 can only support up to 4095 clients

The physical servers and network gears in each Layer 2 don’t change very often. But the client subnets come and go very frequently.

Therefore, restricting one dedicated VLAN for each client can cause some servers/network under utilized and others over loaded.

Linda

From: Benson Schliesser [mailto:bensons@queuefull.net]
Sent: Tuesday, August 24, 2010 7:40 PM
To: Linda Dunbar
Cc: 'Anoop Ghanwani'; arp222@ietf.org
Subject: Re: [arp222] ARP222 Charter statement and milestones

This is pretty much what a VLAN solves for you; it multiplexes link-layer segments.

The scenario you've described is missing an abstraction layer. You're apparently trying to get around the need for VLANs, rather than improve their scale. I'd suggest this really is not the right way to think about VLAN scale limitations.

Cheers,

-Benson

On 24 Aug 10, at 5:28 PM, Linda Dunbar wrote:

Anoop,

I am referring to duplicated IP addresses but with different MAC addresses.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Tuesday, August 24, 2010 3:37 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Linda,

I think the key piece of information that I’m missing is how

the layer 2 forwarding takes place in a particular client-controlled

subnet. If it’s just regular bridging, we will have leakage of traffic

between subnets that are in the same VLAN. In that case, I think

it would be hard to solve the duplicate address problem. If there

is some kind of new forwarding happens that ensures that there

is never leakage between the subnets, and the two subnets never

need to talk to each other unless they use a NAT, then there

is nothing to be solved...that problem already exists today with

VRFs. But I don’t know of such a layer 2 device and that’s why

I was asking for more details.

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Tuesday, August 24, 2010 12:32 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The issue of duplicated IP addresses comes up when there are more client controlled subnets than the number of VLANs. The number of client controlled subnets could be in hundreds of thousands, but there are only 4095 VLANs within one Layer 2. Then you might need to assign multiple client controlled subnets in one VLAN. Under this scenario, duplicated IP will be an issue.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Monday, August 23, 2010 4:36 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Linda,

If it broadcasts from one client controlled subnet do not

show up in another client controlled subnet, then this

should be a non-issue, no?

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Monday, August 23, 2010 2:33 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

No, it shouldn’t.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, 2010 6:19 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Linda,

Do broadcasts from one client controlled subnet show up

in a different client controlled subnet?

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Friday, August 13, 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The scenario is Cloud Computing service selling client controlled (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among those (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address).

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, 2010 4:02 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Hi Linda,

Would it be possible to provide references to actual protocols

that require duplicate IP addresses behind different MAC addresses?

Anoop

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

I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80.

Linda Dunbar

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Thursday, August 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78^th 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

_______________________________________________
arp222 mailing list
arp222@ietf.org
https://www.ietf.org/mailman/listinfo/arp222

--Boundary_(ID_/Q+pMqBtmkHHw9ePGWC8zA)-- From ldunbar@huawei.com Thu Aug 26 08:45:53 2010 Return-Path: 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 1A70E3A6994 for ; Thu, 26 Aug 2010 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 kbqLUUOFQ0Wo for ; Thu, 26 Aug 2010 08:45:52 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 4A4073A6843 for ; Thu, 26 Aug 2010 08:45:52 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7R00958NT29N@usaga04-in.huawei.com> for arp222@ietf.org; Thu, 26 Aug 2010 10:46:14 -0500 (CDT) Received: from L735042 ([10.124.12.75]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7R00BMBNSW8D@usaga04-in.huawei.com> for arp222@ietf.org; Thu, 26 Aug 2010 10:46:08 -0500 (CDT) Date: Thu, 26 Aug 2010 10:46:03 -0500 From: Linda Dunbar To: arp222@ietf.org Message-id: <004201cb4535$cd451130$4b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_NJUKCbca9Ho7cuwk/Twqvg)" Thread-index: ActFNcoOlonQryKGTsKJPvIV7C/iVQ== Subject: [arp222] Considering to change ARP222 name 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 15:45:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_NJUKCbca9Ho7cuwk/Twqvg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT It has been pointed to us by several people that the name ARP222 is a little misleading. The main objective is to resolve issues associated with Address Resolution for Massive amount of VMs or virtual hosts/Nodes in one broadcast Domain. What do you think if we change the name to ARMD or ARMND? Your opinion is appreciated. Linda Dunbar --Boundary_(ID_NJUKCbca9Ho7cuwk/Twqvg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

It has been pointed to us by several people that the name ARP222 is a little misleading. The main objective is to resolve issues associated with Address Resolution for Massive amount of VMs or virtual hosts/Nodes in one broadcast Domain.

What do you think if we change the name to ARMD or ARMND?

Your opinion is appreciated.

Linda Dunbar

--Boundary_(ID_NJUKCbca9Ho7cuwk/Twqvg)-- From anoop@brocade.com Thu Aug 26 10:59:33 2010 Return-Path: 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 DCC283A68DA for ; Thu, 26 Aug 2010 10:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 PsM08tTPr-HF for ; Thu, 26 Aug 2010 10:59:19 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 16D0A3A67F8 for ; Thu, 26 Aug 2010 10:59:18 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o7QHtsfQ024546; Thu, 26 Aug 2010 10:59:43 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id qwvw7r0cc-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Aug 2010 10:59:41 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 26 Aug 2010 11:02:45 -0700 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 26 Aug 2010 10:59:39 -0700 From: Anoop Ghanwani To: Linda Dunbar , "arp222@ietf.org" Date: Thu, 26 Aug 2010 10:59:38 -0700 Thread-Topic: [arp222] ARP222 Charter statement and milestones Thread-Index: Acs6dBuMagc9vRG/Qk2FSSD7saK5HQAqe3AwAAMnKPAAATqjsAADikNwAfM9QQAAABBf8AAt2HcQAAJNoXAAA/KkgAAAHlOQAFRasuAABnlGcA== Message-ID: <5EB1A55E180C914BBC1A49310B762938638616BCB2@HQ1-EXCH02.corp.brocade.com> References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.com> <000201cb43c3$04a5ce90$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B6AB@HQ1-EXCH02.corp.brocade.com> <005901cb43db$b59523a0$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B740@HQ1-EXCH02.corp.brocade.com> <000f01cb452f$f00ceef0$4b0c7c0a@china.huawei.com> In-Reply-To: <000f01cb452f$f00ceef0$4b0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5EB1A55E180C914BBC1A49310B762938638616BCB2HQ1EXCH02corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-26_12:2010-08-26, 2010-08-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1008260122 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 17:59:34 -0000 --_000_5EB1A55E180C914BBC1A49310B762938638616BCB2HQ1EXCH02corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, I'm not disputing the main objective of this work (looking for methods to scale the number of ARPs). I'm only questioning the relevance of the last bullet under the design goals which is to support duplicate IP addresses within the same VLAN. Even in the presence of something like NHRP, I still don't see how it is not an issue. If you ever need to route _to_ that IP address, there will be no way to know which MAC address to put on the packet. Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 26, 2010 8:04 AM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, First of all, the main objective of ARP222 is to develop interoperable solu= tion(s) for address resolution for massive number of (virtual) hosts (or no= des) in one broadcast domain. The possible occurrence of duplicated IP addr= esses among some hosts is by no means the main objective. It is from our cloud computing group indicating that it would make their re= source management much easier if occasional duplicated IP addresses among s= ome hosts are allowed within one VLAN. Here are their reasons: * There could be many Client Controlled subnets; the number could be in = the magnitude of tens or hundreds of thousands. There is huge difference in= the number of (virtual) hosts which client subnets have; Some client subne= ts can have a few virtual hosts, all of them require very low computation d= emand, and some client subnets can have very large number of (virtual) host= s and require very high computation power. * If each client subnet is only mapped to one VLAN, then each layer 2 ca= n only support up to 4095 clients. The physical servers and network gears i= n each layer 2 don't change very often. But the client subnets come and go = very frequently. With virtualized servers, you can easily have more than 50= 00 VMs under each Top of Rack Switch. Requiring each TOR to support NAT is = not realistic. * Therefore, restricting one dedicated VLAN for each client can cause so= me L2 network & servers under utilized and others over utilized. Making it = difficult for Resource Management. Back in ATM days, there were RFC2333 (NHRP) and RFC2334 (SCSP) which use di= stributed servers to resolve addresses. If the similar approach is used for= resolving MAC addresses, then duplicated IP address within one VLAN should= n't be an issue (as long as they all have distinct MAC addresses). Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Tuesday, August 24, 2010 5:31 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Yes, I understand...and the concerns in my previous reply are with that in mind. Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Tuesday, August 24, 2010 3:29 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, I am referring to duplicated IP addresses but with different MAC addresses. Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Tuesday, August 24, 2010 3:37 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, I think the key piece of information that I'm missing is how the layer 2 forwarding takes place in a particular client-controlled subnet. If it's just regular bridging, we will have leakage of traffic between subnets that are in the same VLAN. In that case, I think it would be hard to solve the duplicate address problem. If there is some kind of new forwarding happens that ensures that there is never leakage between the subnets, and the two subnets never need to talk to each other unless they use a NAT, then there is nothing to be solved...that problem already exists today with VRFs. But I don't know of such a layer 2 device and that's why I was asking for more details. Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Tuesday, August 24, 2010 12:32 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The issue of duplicated IP addresses comes up when there are more client co= ntrolled subnets than the number of VLANs. The number of client controlled = subnets could be in hundreds of thousands, but there are only 4095 VLANs wi= thin one Layer 2. Then you might need to assign multiple client controlled = subnets in one VLAN. Under this scenario, duplicated IP will be an issue. Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Monday, August 23, 2010 4:36 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, If it broadcasts from one client controlled subnet do not show up in another client controlled subnet, then this should be a non-issue, no? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Monday, August 23, 2010 2:33 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, No, it shouldn't. Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 6:19 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Linda, Do broadcasts from one client controlled subnet show up in a different client controlled subnet? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Friday, August 13, 2010 2:44 PM To: Anoop Ghanwani; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Anoop, The scenario is Cloud Computing service selling client controlled (virtual)= subnets to clients. All the (virtual) hosts within the client controlled s= ubnets have their own IP addresses. The communications among those (virtual= ) hosts are client specific. There might be same IP addresses in different = client controlled subnets. All those hosts will be assigned as a virtual ma= chine to a physical server and assigned to a VLAN in the actual network in = data center(s). There will be cases when one VLAN ends up having (virtual) = hosts with same IP address (but different MAC address). Linda ________________________________ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Friday, August 13, 2010 4:02 PM To: Linda Dunbar; arp222@ietf.org Subject: RE: [arp222] ARP222 Charter statement and milestones Hi Linda, Would it be possible to provide references to actual protocols that require duplicate IP addresses behind different MAC addresses? Anoop From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of= Linda Dunbar Sent: Friday, August 13, 2010 12:42 PM To: arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones I forgot to clarify in my previous email that the charter statement and mil= estones posted is for soliciting feedback before submitting to IESG to requ= est for a BOF for IETF79 (Beijing). We think the problem domain belongs to Internet Area. Therefore, once I get= your feedback, I will send the Charter Statement and milestones to the Int= ernet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Ou= r target is to have a working group by IETF 80. Linda Dunbar ________________________________ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Thursday, August 12, 2010 6:14 PM To: 'arp222@ietf.org' Subject: ARP222 Charter statement and milestones Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving us c= omments 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 M= achines (20, 30, or hundreds of). Virtual Machines, with its flexible add/d= elete and mobility features, not only makes it possible for achieving bette= r performance and better utilization on servers, they are also a very impor= tant building block for Cloud Computing service to offer virtual subnets an= d virtual hosts. The virtual subnets offered by Cloud Computing service cou= ld 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 an= d 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 thousan= ds of hosts (each with a distinct MAC address) in one Data Center, the amou= nt 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 ce= nter is potentially duplicated IP addresses within one VLAN which will make= traditional ARP or ND not working properly. Some load balance design requi= res multiple hosts serving the same application to have the same IP address= but with different MAC addresses. Cloud Computing service could allow user= s to have their own subnets with IP addresses and self defined policies amo= ng 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 co= uld be duplicated IP addresses which are from different client subnets endi= ng up in one VLAN. The goal of this working group is to develop interoperable solutions to sol= ve those problems. The design should consider the following properties: * All solutions developed by ARP222 WG should not expect any behavi= or changes on hosts, applications, or Virtual Machines being deployed in th= e market. * All solutions developed should not break DHCP. * Evaluating the impact to IPv6 ND, and develop solutions according= ly 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 m= alicious users. Evaluating potential security solutions and conclude if the= security threat can justify solutions. * ARP222 assumes the direct links to individual hosts and virtual m= achines are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconn= ected by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider address resolution solutions for one VLAN with sm= all 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 Ether= net networks * Study and Analysis of MOOSE as a potential solution * Study and Analysis of SEATTLE as a potential solution. Best Regards, Linda Dunbar --_000_5EB1A55E180C914BBC1A49310B762938638616BCB2HQ1EXCH02corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda,

I’m not disputing the main objective of this work (loo= king

for methods to scale the number of ARPs).<= /p>

I’m only questioning the relevance of the last bullet<= o:p>

under the design goals which is to support duplicate IP=

addresses within the same VLAN.

Even in the presence of something like NHRP, I still

don’t see how it is not an issue. If you e= ver need to

route _to_ that IP address, there will be no way to k= now

which MAC address to put on the packet.

Anoop

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Thursday, August 26, 2010 8:04 AM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

First of all, the main objective of ARP222 is to develop interoperable solution(s= ) for address resolution for massive number of (virtual) hosts (or nodes) in = one broadcast domain. The possible occurrence of duplicated IP addresses among = some hosts is by no means the main objective.

It is from our cloud computing group indicating that it would make their resou= rce management much easier if occasional duplicated IP addresses among some hos= ts are allowed within one VLAN. Here are their reasons:

There could be many Client Controlled subnets; the number could be in the magnitude of tens or hundreds of thousands. There is huge difference in the number of (virt= ual) hosts which client subnets have; Some client subnets can have a few virtual hosts, all of them require very low computation demand, and so= me client subnets can have very large number of (virtual) hosts and requi= re very high computation power.

If each client subnet is on= ly mapped to one VLAN, then each layer 2 can only support up to 4095 clie= nts. The physical servers and network gears in each layer 2 don’t cha= nge very often. But the client subnets come and go very frequently. With virtualized servers, you can easily have more than 5000 VMs under each= Top of Rack Switch. Requiring each TOR to support NAT is not realistic.

Therefore, restricting one dedicated VLAN for each client can cause some L2 network & servers under utilized and others over utilized. Making it difficult for Resou= rce Management.

Back in ATM days, there were RFC2333 (NHRP) and RFC2334 (SCSP) which use distrib= uted servers to resolve addresses. If the similar approach is used for resolving= MAC addresses, then duplicated IP address within one VLAN shouldn’t be an issue (as long as they all have distinct MAC addresses). <= /span>

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Tuesday, August 24, 2010 5:31 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Linda,<= /p>
<= /p>
Yes, I understand...and t= he concerns in my previous reply

are with that in mind.

<= /p>
Anoop
<= /p>

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Tuesday, August 24, 2010 3:29 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

I am referring to duplicated IP addresses but with different MA= C addresses.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Tuesday, August 24, 2010 3:37 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Linda,<= /p>
<= /p>
I think the key piece of information that I’m missing is how

the layer 2 forwarding ta= kes place in a particular client-controlled

subnet. If it’= ;s just regular bridging, we will have leakage of traffic
between subnets that are = in the same VLAN. In that case, I think

it would be hard to solve= the duplicate address problem. If there

is some kind of new forwarding happens that ensures that there

is never leakage between = the subnets, and the two subnets never

need to talk to each othe= r unless they use a NAT, then there

is nothing to be solved...that problem already exists today with

VRFs. But I donR= 17;t know of such a layer 2 device and that’s why

I was asking for more details.

<= /p>
Anoop
<= /p>

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Tuesday, August 24, 2010 12:32 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The issue of duplicated IP addresses comes up when there are mo= re client controlled subnets than the number of VLANs. The number of client controlled subnets could be in hundreds of thousands, but there are only 40= 95 VLANs within one Layer 2. Then you might need to assign multiple client controlled subnets in one VLAN. Under this scenario, duplicated IP will be = an issue.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Monday, August 23, 2010 4:36 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Linda,<= /p>
<= /p>
If it broadcasts from one= client controlled subnet do not

show up in another client controlled subnet, then this

should be a non-issue, no= ?

<= /p>
Anoop
<= /p>

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Monday, August 23, 2010 2:33 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

No, it shouldn’t.

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Friday, August 13, 2010 6:19 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Linda,<= /p>
<= /p>
Do broadcasts from one cl= ient controlled subnet show up

in a different client controlled subnet?

<= /p>
Anoop
<= /p>

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Friday, August 13, 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The scenario is Cloud Computing service selling client controll= ed (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among th= ose (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address).

Linda

From: Anoop Ghanwani [mailto:anoop@brocade.co= m]
Sent: Friday, August 13, 2010 4:02 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] ARP222 Charter statement and milestones=

Hi Linda,

<= /p>
Would it be possible to provide references to actual protocols

that require duplicate IP addresses behind different MAC addresses?

<= /p>
Anoop
<= /p>

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

I forgot to clarify in my previous email that the charter state= ment and milestones posted is for soliciting feedback before submitting to IESG = to request for a BOF for IETF79 (Beijing).

We think the problem domain belongs to Internet Area. Therefore= , once I get your feedback, I will send the Charter Statement and milestones = to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beiji= ng). Our target is to have a working group by IETF 80.

Linda Dunbar

From: Linda Dunbar [mailto:ldunbar@huawei.com= ]
Sent: Thursday, August 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78^th 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 Resolu= tion 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 performa= nce and better utilization on servers, they are also a very important building block for Cloud Computing service to offer virtual subnets and virtual host= s. 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 thousan= ds 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 traditi= onal 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 whic= h is much more than 4095 VLANs. Under this scenario, there could be duplicated I= P addresses which are from different client subnets ending up in one VLAN.&nb= sp;

The goal of this working group is to develop interoperable solutions to solve t= hose problems.

The design should consi= der the following properties:

·      =    All solutions developed by ARP222 WG should = not expect any behavior changes on hosts, applications, or Virtual Machines bei= ng deployed in the market.

·      =    All solutions developed should not break DHC= P.

·      =    Evaluating the impact to IPv6 ND, and develo= p solutions accordingly if needed.

·      =    Should consider variety of solutions, includ= ing directory based, proxy based, or cache based solutions.

·      =    Include analysis of security concerns of IPv= 4 ARP requests from malicious users. Evaluating potential security solutions = and conclude if the security threat can justify solutions.

·      =    ARP222 assumes the direct links to individua= l hosts and virtual machines are IEEE802.3 Ethernet links. <= /p>
·      =    Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure I= P, Ethernet, or others.

·      =    Should consider address resolution solutions= for one VLAN with small number of duplicated IP addresses.

Here are the items whic= h should not be in the scope of the working group:

·      =    Re-define DHCP behavior

·      =    Re-define security concern to IPv6 ND <= /o:p>

·      =    Direct links from hosts and virtual hosts ar= e non Ethernet links

·      =

Goals and Milestones:

·      =    Charter statement

·      =    Problem Statements

·      =    Gap analysis

·      =    Study of NHRP (RFC2332) & SCSP, an= d 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

--_000_5EB1A55E180C914BBC1A49310B762938638616BCB2HQ1EXCH02corp_-- From bensons@queuefull.net Thu Aug 26 12:57:20 2010 Return-Path: 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 B944F3A69B4 for ; Thu, 26 Aug 2010 12:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 UZez7dqtwrAq for ; Thu, 26 Aug 2010 12:57:18 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D7C753A6922 for ; Thu, 26 Aug 2010 12:57:17 -0700 (PDT) Received: by gwb20 with SMTP id 20so998729gwb.31 for ; Thu, 26 Aug 2010 12:57:50 -0700 (PDT) Received: by 10.150.148.16 with SMTP id v16mr743501ybd.268.1282852669829; Thu, 26 Aug 2010 12:57:49 -0700 (PDT) Received: from [192.168.1.105] (24-241-105-11.static.stls.mo.charter.com [24.241.105.11]) by mx.google.com with ESMTPS id m11sm3077365ybn.16.2010.08.26.12.57.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Aug 2010 12:57:48 -0700 (PDT) From: Benson Schliesser Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-43--397211275 Date: Thu, 26 Aug 2010 14:57:46 -0500 In-Reply-To: <003001cb4534$c9f629c0$4b0c7c0a@china.huawei.com> To: Linda Dunbar , arp222@ietf.org References: <00bc01cb3b1f$a12fa3f0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1558@HQ1-EXCH02.corp.brocade.com> <010401cb3b30$95a41aa0$480c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B76293863830E1610@HQ1-EXCH02.corp.brocade.com> <005d01cb430a$be756650$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B395@HQ1-EXCH02.corp.brocade.com> <000201cb43c3$04a5ce90$4b0c7c0a@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938638616B6AB@HQ1-EXCH02.corp.brocade.com> <005901cb43db$b59523a0$4b0c7c0a@china.huawei.com> <5B40D077-0171-4316-8606-4F26DC611EA1@queuefull.net> <003001cb4534$c9f629c0$4b0c7c0a@china.huawei.com> Message-Id: <94D79230-386C-43FD-A412-F79452D6D71C@queuefull.net> X-Mailer: Apple Mail (2.1081) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 19:57:20 -0000 --Apple-Mail-43--397211275 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Linda - I agree with the concerns you outline: existing layer 2 segmentation = techniques (i.e. 802.1Q) don't scale well for large datacenter / cloud = environments. However, accepting those concerns doesn't lead to the = conclusion you've reached. Your view, as I understand it, is that conflicting use of IP addresses = within the same broadcast domain should be supported. I gather that you = propose to enable this by somehow fixing ARP. But I fear that you're = conflating the issues of segmented broadcast domains and improved = address resolution. (After all, ARP isn't the only consumer of = broadcast or multicast forwarding.) My suggestion is that we either focus on an ARP alternative that works = with VLANs, or an ARP alternative that depends on a VLAN alternative. I = don't consider it a reasonable goal to develop an ARP alternative that = works with a shared broadcast domain. Cheers, -Benson On 26 Aug 10, at 10:38 AM, Linda Dunbar wrote: > Benson, > =20 > Definitely VLAN should be used to differentiate different subnets. > =20 > In the Cloud Computing environment, client subnets are added and = removed very frequently and the number of (virtual) hosts in client = subnets is very different. > If each client subnet is mapped to one VLAN, then each layer 2 can = only support up to 4095 clients > The physical servers and network gears in each Layer 2 don=92t change = very often. But the client subnets come and go very frequently. > Therefore, restricting one dedicated VLAN for each client can cause = some servers/network under utilized and others over loaded. > =20 > Linda > =20 > =20 > From: Benson Schliesser [mailto:bensons@queuefull.net]=20 > Sent: Tuesday, August 24, 2010 7:40 PM > To: Linda Dunbar > Cc: 'Anoop Ghanwani'; arp222@ietf.org > Subject: Re: [arp222] ARP222 Charter statement and milestones > =20 > This is pretty much what a VLAN solves for you; it multiplexes = link-layer segments. > =20 > The scenario you've described is missing an abstraction layer. You're = apparently trying to get around the need for VLANs, rather than improve = their scale. I'd suggest this really is not the right way to think = about VLAN scale limitations. > =20 > Cheers, > -Benson > =20 > =20 > On 24 Aug 10, at 5:28 PM, Linda Dunbar wrote: >=20 >=20 > Anoop, > =20 > I am referring to duplicated IP addresses but with different MAC = addresses. > =20 > Linda > =20 > From: Anoop Ghanwani [mailto:anoop@brocade.com]=20 > Sent: Tuesday, August 24, 2010 3:37 PM > To: Linda Dunbar; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Linda, > =20 > I think the key piece of information that I=92m missing is how > the layer 2 forwarding takes place in a particular client-controlled > subnet. If it=92s just regular bridging, we will have leakage of = traffic > between subnets that are in the same VLAN. In that case, I think > it would be hard to solve the duplicate address problem. If there > is some kind of new forwarding happens that ensures that there > is never leakage between the subnets, and the two subnets never > need to talk to each other unless they use a NAT, then there > is nothing to be solved...that problem already exists today with > VRFs. But I don=92t know of such a layer 2 device and that=92s why > I was asking for more details. > =20 > Anoop > =20 > From: Linda Dunbar [mailto:ldunbar@huawei.com]=20 > Sent: Tuesday, August 24, 2010 12:32 PM > To: Anoop Ghanwani; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Anoop, > =20 > The issue of duplicated IP addresses comes up when there are more = client controlled subnets than the number of VLANs. The number of client = controlled subnets could be in hundreds of thousands, but there are only = 4095 VLANs within one Layer 2. Then you might need to assign multiple = client controlled subnets in one VLAN. Under this scenario, duplicated = IP will be an issue. > =20 > Linda > =20 > From: Anoop Ghanwani [mailto:anoop@brocade.com]=20 > Sent: Monday, August 23, 2010 4:36 PM > To: Linda Dunbar; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Linda, > =20 > If it broadcasts from one client controlled subnet do not > show up in another client controlled subnet, then this > should be a non-issue, no? > =20 > Anoop > =20 > From: Linda Dunbar [mailto:ldunbar@huawei.com]=20 > Sent: Monday, August 23, 2010 2:33 PM > To: Anoop Ghanwani; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Anoop, > =20 > No, it shouldn=92t. > =20 > Linda > =20 > From: Anoop Ghanwani [mailto:anoop@brocade.com]=20 > Sent: Friday, August 13, 2010 6:19 PM > To: Linda Dunbar; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Linda, > =20 > Do broadcasts from one client controlled subnet show up > in a different client controlled subnet? > =20 > Anoop > =20 > From: Linda Dunbar [mailto:ldunbar@huawei.com]=20 > Sent: Friday, August 13, 2010 2:44 PM > To: Anoop Ghanwani; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Anoop, > =20 > The scenario is Cloud Computing service selling client controlled = (virtual) subnets to clients. All the (virtual) hosts within the client = controlled subnets have their own IP addresses. The communications among = those (virtual) hosts are client specific. There might be same IP = addresses in different client controlled subnets. All those hosts will = be assigned as a virtual machine to a physical server and assigned to a = VLAN in the actual network in data center(s). There will be cases when = one VLAN ends up having (virtual) hosts with same IP address (but = different MAC address). > =20 > Linda > =20 > From: Anoop Ghanwani [mailto:anoop@brocade.com]=20 > Sent: Friday, August 13, 2010 4:02 PM > To: Linda Dunbar; arp222@ietf.org > Subject: RE: [arp222] ARP222 Charter statement and milestones > =20 > Hi Linda, > =20 > Would it be possible to provide references to actual protocols > that require duplicate IP addresses behind different MAC addresses? > =20 > Anoop > =20 > From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On = Behalf Of Linda Dunbar > Sent: Friday, August 13, 2010 12:42 PM > To: arp222@ietf.org > Subject: Re: [arp222] ARP222 Charter statement and milestones > =20 > I forgot to clarify in my previous email that the charter statement = and milestones posted is for soliciting feedback before submitting to = IESG to request for a BOF for IETF79 (Beijing). =20 > We think the problem domain belongs to Internet Area. Therefore, once = I get your feedback, I will send the Charter Statement and milestones to = the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 = (Beijing). Our target is to have a working group by IETF 80. =20 > =20 > Linda Dunbar > =20 > From: Linda Dunbar [mailto:ldunbar@huawei.com]=20 > Sent: Thursday, August 12, 2010 6:14 PM > To: 'arp222@ietf.org' > Subject: ARP222 Charter statement and milestones > =20 > Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving = us comments and suggestions on and between sessions. > =20 > I put together the initial ARP222 Charter Statement and Milestones. = Please provide comments and suggestions.=20 > =20 > =20 > =20 > =20 > ARP 222: Address Resolution Protocol for Layer 2 to Anything to Layer = 2 > =20 > 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. >=20 > 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. >=20 > 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.=20 >=20 > The goal of this working group is to develop interoperable solutions = to solve those problems.=20 >=20 > The design should consider the following properties: > =B7 All solutions developed by ARP222 WG should not expect any = behavior changes on hosts, applications, or Virtual Machines being = deployed in the market. > =B7 All solutions developed should not break DHCP. > =B7 Evaluating the impact to IPv6 ND, and develop solutions = accordingly if needed. > =B7 Should consider variety of solutions, including directory = based, proxy based, or cache based solutions. > =B7 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. > =B7 ARP222 assumes the direct links to individual hosts and = virtual machines are IEEE802.3 Ethernet links.=20 > =B7 Should consider scenarios of one Ethernet network being = interconnected by another network, which can be L2VPN, pure IP, = Ethernet, or others. > =B7 Should consider address resolution solutions for one VLAN = with small number of duplicated IP addresses.=20 > =20 > Here are the items which should not be in the scope of the working = group: > =B7 Re-define DHCP behavior > =B7 Re-define security concern to IPv6 ND > =B7 Direct links from hosts and virtual hosts are non Ethernet = links > =B7 =20 > =20 > Goals and Milestones: > =B7 Charter statement > =B7 Problem Statements > =B7 Gap analysis > =B7 Study of NHRP (RFC2332) & SCSP, and their applicability to = Ethernet networks > =B7 Study and Analysis of MOOSE as a potential solution > =B7 Study and Analysis of SEATTLE as a potential solution. > =20 > =20 > Best Regards, Linda Dunbar > =20 > _______________________________________________ > arp222 mailing list > arp222@ietf.org > https://www.ietf.org/mailman/listinfo/arp222 >=20 > =20 --Apple-Mail-43--397211275 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Linda = -

I agree with the concerns you outline: existing = layer 2 segmentation techniques (i.e. 802.1Q) don't scale well for large = datacenter / cloud environments. However, accepting those concerns = doesn't lead to the conclusion you've = reached.

Your view, as I understand it, is that = conflicting use of IP addresses within the same broadcast domain should = be supported. I gather that you propose to enable this by somehow = fixing ARP. But I fear that you're conflating the issues of = segmented broadcast domains and improved address resolution. = (After all, ARP isn't the only consumer of broadcast or multicast = forwarding.)

My suggestion is that we either = focus on an ARP alternative that works with VLANs, or an ARP alternative = that depends on a VLAN alternative. I don't consider it a = reasonable goal to develop an ARP alternative that works with a shared = broadcast = domain.

Cheers,
-Benson

<= /div>

On 26 Aug 10, at 10:38 AM, Linda = Dunbar wrote:

=

Benson, =

Definitely VLAN should be used to differentiate different subnets.

In the Cloud Computing environment, = client subnets are added and removed very frequently and the number of = (virtual) hosts in client subnets is very different.
If each client subnet is mapped to = one VLAN, then each layer 2 can only support up to 4095 = clients
The physical servers and network = gears in each Layer 2 don=92t change very often. But the client subnets come and = go very frequently.
Therefore, restricting one = dedicated VLAN for each client can cause some servers/network under utilized and others = over loaded.

Linda

From: Benson Schliesser [mailto:bensons@queuefull.net]
Sent: Tuesday, August 24, = 2010 7:40 PM
To: Linda Dunbar
Cc: 'Anoop Ghanwani'; arp222@ietf.org
Subject: Re: [arp222] = ARP222 Charter statement and milestones

This is pretty = much what a VLAN solves for you; it multiplexes link-layer segments.

The scenario = you've described is missing an abstraction layer. You're apparently trying to get around the need = for VLANs, rather than improve their scale. I'd suggest this really is = not the right way to think about VLAN scale = limitations.

Cheers,

-Benson

On 24 Aug 10, = at 5:28 PM, Linda Dunbar wrote:

Anoop, =

I am referring = to duplicated IP addresses but with different MAC addresses. =

Linda=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Tuesday, August 24, = 2010 3:37 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and = milestones

Linda,<= /u1:p>
<= /u1:p>
I think the key piece of information that I=92m missing is = how
the layer 2 forwarding takes place in a particular = client-controlled
subnet. = If it=92s just regular bridging, we will have leakage of = traffic
between subnets that are in the same VLAN. In that case, I = think
it would be hard to solve the duplicate address problem. If = there
is some kind of new forwarding happens that ensures that = there
is never leakage between the subnets, and the two subnets = never
need to talk to each other unless they use a NAT, then = there
is nothing to be solved...that problem already exists today = with
VRFs. But I don=92t know of such a layer 2 device and that=92s = why
I was asking for more details.
<= /u1:p>
Anoop
<= /u1:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Tuesday, August 24, = 2010 12:32 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and = milestones

Anoop, =

The issue of duplicated IP addresses comes up when there are more client = controlled subnets than the number of VLANs. The number of client controlled = subnets could be in hundreds of thousands, but there are only 4095 VLANs within one = Layer 2. Then you might need to assign multiple client controlled subnets in one = VLAN. Under this scenario, duplicated IP will be an issue. =

Linda =

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Monday, August 23, = 2010 4:36 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and = milestones

Linda,<= /u1:p>
<= /u1:p>
If it broadcasts from one client controlled subnet do = not
show up in another client controlled subnet, then = this
should be a non-issue, no?
<= /u1:p>
Anoop
<= /u1:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Monday, August 23, = 2010 2:33 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and = milestones

Anoop, =

No, it shouldn=92t.

Linda=

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 6:19 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and = milestones

Linda,<= /u1:p>
<= /u1:p>
Do broadcasts from one client controlled subnet show = up
in a different client controlled = subnet?
<= /u1:p>
Anoop
<= /u1:p>

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Friday, August 13, = 2010 2:44 PM
To: Anoop Ghanwani; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and = milestones

Anoop, =

The scenario is Cloud Computing service selling client controlled (virtual) = subnets to clients. All the (virtual) hosts within the client controlled subnets = have their own IP addresses. The communications among those (virtual) hosts = are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual = machine to a physical server and assigned to a VLAN in the actual network in data = center(s). There will be cases when one VLAN ends up having (virtual) hosts with = same IP address (but different MAC address). =

Linda =

From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Friday, August 13, = 2010 4:02 PM
To: Linda Dunbar; arp222@ietf.org
Subject: RE: [arp222] = ARP222 Charter statement and = milestones

Hi Linda,
<= /u1:p>
Would it be possible to provide references to actual = protocols
that require duplicate IP addresses behind different MAC = addresses?
<= /u1:p>
Anoop
<= /u1:p>

From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On = Behalf Of Linda Dunbar
Sent: Friday, August 13, = 2010 12:42 PM
To: arp222@ietf.org
Subject: Re: [arp222] = ARP222 Charter statement and = milestones

I forgot to clarify in my previous email that the charter statement and = milestones posted is for soliciting feedback before submitting to IESG to request = for a BOF for IETF79 (Beijing). =
We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the = Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80. =

Linda Dunbar

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Thursday, August = 12, 2010 6:14 PM
To: 'arp222@ietf.org'
Subject: ARP222 Charter = statement and milestones

Thank you all for coming to = ARP222 Bar BOF at the 78^th 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:
=B7        All solutions developed by ARP222 WG should not expect any behavior changes on hosts, applications, or = Virtual Machines being deployed in the market.
=B7        All solutions developed should not break DHCP.
=B7        Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed. =
=B7        Should consider variety of solutions, including directory based, proxy based, or cache based = solutions.
=B7        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.
=B7        ARP222 assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet = links.
=B7        Should consider scenarios of one Ethernet network being interconnected by another network, which can be = L2VPN, pure IP, Ethernet, or others.
=B7        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: =
=B7        Re-define DHCP = behavior
=B7        Re-define security concern to IPv6 ND
=B7        Direct links from hosts and virtual hosts are non Ethernet links
=B7

Goals and Milestones:
=B7        Charter = statement
=B7        Problem = Statements
=B7        Gap analysis =
=B7        Study of NHRP (RFC2332) & SCSP, and their applicability to Ethernet = networks
=B7        Study and Analysis of MOOSE as a potential solution
=B7        Study and Analysis of SEATTLE as a potential solution.

Best Regards, Linda Dunbar

_______________________________________________=
arp222 mailing list
arp222@ietf.org
https://www.ietf.org= /mailman/listinfo/arp222

=

=

= --Apple-Mail-43--397211275-- From bensons@queuefull.net Thu Aug 26 13:11:23 2010 Return-Path: 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 5649C3A68F3 for ; Thu, 26 Aug 2010 13:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 cuUgjqcGa3o9 for ; Thu, 26 Aug 2010 13:11:22 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id B74B23A69AD for ; Thu, 26 Aug 2010 13:11:21 -0700 (PDT) Received: by gwb20 with SMTP id 20so1005365gwb.31 for ; Thu, 26 Aug 2010 13:11:54 -0700 (PDT) Received: by 10.151.141.12 with SMTP id t12mr860508ybn.89.1282853513954; Thu, 26 Aug 2010 13:11:53 -0700 (PDT) Received: from [192.168.1.105] (24-241-105-11.static.stls.mo.charter.com [24.241.105.11]) by mx.google.com with ESMTPS id q21sm3094757ybk.23.2010.08.26.13.11.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Aug 2010 13:11:52 -0700 (PDT) From: Benson Schliesser Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-44--396367245 Date: Thu, 26 Aug 2010 15:11:50 -0500 In-Reply-To: <00f901cb3a74$1bb07e80$5d0c7c0a@china.huawei.com> To: Linda Dunbar , arp222@ietf.org References: <00f901cb3a74$1bb07e80$5d0c7c0a@china.huawei.com> Message-Id: <1188AC2B-0E47-45FD-8CA3-F755B24A0E2E@queuefull.net> X-Mailer: Apple Mail (2.1081) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 20:11:23 -0000 --Apple-Mail-44--396367245 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Linda - I'd like to see a few modifications to the charter you've outlined: 1) I've already explained why I think the last design goal (overlapping = IP addresses within a single VLAN) should be removed. I won't reiterate = that here. 2) The goal to "not break DHCP" should be modified to include any = broadcast and/or multicast protocols. (Alternatively, broadcast and = multicast support can be required by a new goal to be added.) 3) The goal of supporting interconnect scenarios should explicitly = include L3VPN. In case it isn't clear, that implies a goal of support = for overlapping IP addresses within the datacenter. (Albeit in different = broadcast domains, my comments in #1 above notwithstanding.) 4) A new goal should include a performance analysis of all solutions = considered. This might explicitly acknowledge a role for negative = caching approaches, but that shouldn't be a requirement. Cheers, -Benson On 12 Aug 10, at 6:14 PM, Linda Dunbar wrote: > Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving = us comments and suggestions on and between sessions. > =20 > I put together the initial ARP222 Charter Statement and Milestones. = Please provide comments and suggestions. =20 > =20 > =20 > =20 > =20 > ARP 222: Address Resolution Protocol for Layer 2 to Anything to Layer = 2 > =20 > 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. >=20 > 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. >=20 > 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.=20 >=20 > The goal of this working group is to develop interoperable solutions = to solve those problems.=20 >=20 > 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.=20 > 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. =20 > =20 > 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 > =20 > =20 > 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. > =20 > =20 > Best Regards, Linda Dunbar > =20 > _______________________________________________ > arp222 mailing list > arp222@ietf.org > https://www.ietf.org/mailman/listinfo/arp222 --Apple-Mail-44--396367245 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Linda = -

I'd like to see a few modifications to the charter = you've outlined:

1) I've already explained why = I think the last design goal (overlapping IP addresses within a single = VLAN) should be removed. I won't reiterate that = here.

2) The goal to "not break DHCP" should be = modified to include any broadcast and/or multicast protocols. = (Alternatively, broadcast and multicast support can be required by = a new goal to be added.)

3) The goal of = supporting interconnect scenarios should explicitly include L3VPN. = In case it isn't clear, that implies a goal of support for = overlapping IP addresses within the datacenter. (Albeit in different = broadcast domains, my comments in #1 above = notwithstanding.)

4) A new goal should include = a performance analysis of all solutions considered. This might = explicitly acknowledge a role for negative caching approaches, but that = shouldn't be a = requirement.

Cheers,
-Benson
=

On 12 Aug 10, at 6:14 PM, = Linda Dunbar wrote:

Thank you all for coming to = ARP222 Bar BOF at the 78^th 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
=

_______________________________________________
arp222 mailing = list
arp222@ietf.org
https://www.ietf.or= g/mailman/listinfo/arp222

= --Apple-Mail-44--396367245-- From ldunbar@huawei.com Thu Aug 26 14:16:53 2010 Return-Path: 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 5EB723A6B15 for ; Thu, 26 Aug 2010 14:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.01 X-Spam-Level: X-Spam-Status: No, score=-102.01 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 83hSdvNvIED5 for ; Thu, 26 Aug 2010 14:16:44 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id BCA193A68BC for ; Thu, 26 Aug 2010 14:16:43 -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 <0L7S0052V34RHJ@usaga02-in.huawei.com> for arp222@ietf.org; Thu, 26 Aug 2010 14:17:16 -0700 (PDT) Received: from L735042 ([10.124.12.75]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7S00DPG34RNN@usaga02-in.huawei.com> for arp222@ietf.org; Thu, 26 Aug 2010 14:17:15 -0700 (PDT) Date: Thu, 26 Aug 2010 16:17:13 -0500 From: Linda Dunbar In-reply-to: <1188AC2B-0E47-45FD-8CA3-F755B24A0E2E@queuefull.net> To: 'Benson Schliesser' , arp222@ietf.org Message-id: <00ea01cb4564$0dbff080$4b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_rAdzWObBxlwJc0bl4weFKw)" Thread-index: ActFWv3xp+XjX57bSOG93ZaeKZhbrQACMa/g References: <00f901cb3a74$1bb07e80$5d0c7c0a@china.huawei.com> <1188AC2B-0E47-45FD-8CA3-F755B24A0E2E@queuefull.net> 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 21:16:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rAdzWObBxlwJc0bl4weFKw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Benson, Thank you very much for the suggestion. Let's see if other people have similar comments or other suggestions. The goal of circulating the tentative Charter statement is to make needed changes before submitting to the IESG in mid Sept. Linda _____ From: Benson Schliesser [mailto:bensons@queuefull.net] Sent: Thursday, August 26, 2010 3:12 PM To: Linda Dunbar; arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones Linda - I'd like to see a few modifications to the charter you've outlined: 1) I've already explained why I think the last design goal (overlapping IP addresses within a single VLAN) should be removed. I won't reiterate that here. 2) The goal to "not break DHCP" should be modified to include any broadcast and/or multicast protocols. (Alternatively, broadcast and multicast support can be required by a new goal to be added.) 3) The goal of supporting interconnect scenarios should explicitly include L3VPN. In case it isn't clear, that implies a goal of support for overlapping IP addresses within the datacenter. (Albeit in different broadcast domains, my comments in #1 above notwithstanding.) 4) A new goal should include a performance analysis of all solutions considered. This might explicitly acknowledge a role for negative caching approaches, but that shouldn't be a requirement. Cheers, -Benson On 12 Aug 10, at 6:14 PM, Linda Dunbar wrote: 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 _______________________________________________ arp222 mailing list arp222@ietf.org https://www.ietf.org/mailman/listinfo/arp222 --Boundary_(ID_rAdzWObBxlwJc0bl4weFKw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Benson,

Thank you very much for the suggestion. Let’s see if other people have similar comments or other suggestions.

The goal of circulating the tentative Charter statement is to make needed changes before submitting to the IESG in mid Sept.

Linda

From: Benson Schliesser [mailto:bensons@queuefull.net]
Sent: Thursday, August 26, 2010 3:12 PM
To: Linda Dunbar; arp222@ietf.org
Subject: Re: [arp222] ARP222 Charter statement and milestones

Linda -

I'd like to see a few modifications to the charter you've outlined:

1) I've already explained why I think the last design goal (overlapping IP addresses within a single VLAN) should be removed. I won't reiterate that here.

2) The goal to "not break DHCP" should be modified to include any broadcast and/or multicast protocols. (Alternatively, broadcast and multicast support can be required by a new goal to be added.)

3) The goal of supporting interconnect scenarios should explicitly include L3VPN. In case it isn't clear, that implies a goal of support for overlapping IP addresses within the datacenter. (Albeit in different broadcast domains, my comments in #1 above notwithstanding.)

4) A new goal should include a performance analysis of all solutions considered. This might explicitly acknowledge a role for negative caching approaches, but that shouldn't be a requirement.

Cheers,

-Benson

On 12 Aug 10, at 6:14 PM, Linda Dunbar wrote:

Thank you all for coming to ARP222 Bar BOF at the 78^th 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

_______________________________________________
arp222 mailing list
arp222@ietf.org
https://www.ietf.org/mailman/listinfo/arp222

--Boundary_(ID_rAdzWObBxlwJc0bl4weFKw)-- From liyizhou@huawei.com Thu Aug 26 17:40:22 2010 Return-Path: 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 0BC5D3A6964 for ; Thu, 26 Aug 2010 17:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.079 X-Spam-Level: *** X-Spam-Status: No, score=3.079 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1] 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 D2yv4lejdUUk for ; Thu, 26 Aug 2010 17:40:21 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3D82C3A68A7 for ; Thu, 26 Aug 2010 17:40:20 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7S0027FCJU3T@szxga05-in.huawei.com> for arp222@ietf.org; Fri, 27 Aug 2010 08:40:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7S00GW3CJTB8@szxga05-in.huawei.com> for arp222@ietf.org; Fri, 27 Aug 2010 08:40:41 +0800 (CST) Received: from l63746 ([10.138.84.67]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7S00G2XCJSCI@szxml06-in.huawei.com> for arp222@ietf.org; Fri, 27 Aug 2010 08:40:41 +0800 (CST) Date: Fri, 27 Aug 2010 08:40:48 +0800 From: Li Yizhou In-reply-to: <004201cb4535$cd451130$4b0c7c0a@china.huawei.com> To: 'Linda Dunbar' , arp222@ietf.org Message-id: <004401cb4580$7ebdf5e0$43548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_8HV5YCl7qMuhop0C5WN3rQ)" Thread-index: ActFNcoOlonQryKGTsKJPvIV7C/iVQASmCJw Subject: Re: [arp222] Considering to change ARP222 name 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 00:40:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_8HV5YCl7qMuhop0C5WN3rQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT How about just ARM(address resolution for massive nodes) or Armed(address resolution for massive end-nodes)? :) Yizhou _____ From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, August 26, 2010 11:46 PM To: arp222@ietf.org Subject: [arp222] Considering to change ARP222 name It has been pointed to us by several people that the name ARP222 is a little misleading. The main objective is to resolve issues associated with Address Resolution for Massive amount of VMs or virtual hosts/Nodes in one broadcast Domain. What do you think if we change the name to ARMD or ARMND? Your opinion is appreciated. Linda Dunbar --Boundary_(ID_8HV5YCl7qMuhop0C5WN3rQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
How about just ARM(address resolution for massive nodes) or Armed(address resolution for massive end-nodes)? :)

Yizhou

From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, August 26, 2010 11:46 PM
To: arp222@ietf.org
Subject: [arp222] Considering to change ARP222 name

It has been pointed to us by several people that the name ARP222 is a little misleading. The main objective is to resolve issues associated with Address Resolution for Massive amount of VMs or virtual hosts/Nodes in one broadcast Domain.

What do you think if we change the name to ARMD or ARMND?

Your opinion is appreciated.

Linda Dunbar

--Boundary_(ID_8HV5YCl7qMuhop0C5WN3rQ)-- From ronc.ntear@gmail.com Mon Aug 30 07:48:36 2010 Return-Path: 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 093903A6844 for ; Mon, 30 Aug 2010 07:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.705 X-Spam-Level: X-Spam-Status: No, score=-97.705 tagged_above=-999 required=5 tests=[AWL=-4.271, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_57=0.6, MANGLED_DOMAIN=2.3, MANGLED_FORM=2.3, 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 gGryp867J0lQ for ; Mon, 30 Aug 2010 07:48:35 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A40613A6842 for ; Mon, 30 Aug 2010 07:48:34 -0700 (PDT) Received: by fxm18 with SMTP id 18so3748373fxm.31 for ; Mon, 30 Aug 2010 07:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=WGBxIulZJvWJvSbNxCQaFyvE+FaKoRW9ElYAlZbpZhI=; b=W+EigebC6eeWdlbEzo4m2wsHV/F3me4qrSZK87k0sKApBqeb9tQ0jTANrCmKRqiGyy qADAn6pUy/QSjLLDaKdFpWXGJL3RlsRs+cMP10NNo60XkBFdLo71eaO/BzhpVx4NsAK0 l94GNjjPCt9U6holPDBrg2frlbK5bRMYxKouM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=AypgwzAhuUX0cHi3PerBB70tHDdgMlHMwSOITh61lZiQv4iWt/C2TDI03CD4LVs9Wb yS7WluspEJ8qyzlM8HqAvyiRY8n85Wwe52rcMmBpkMYto1kSa1cVBiNtXrn/wnNJzXYQ zDB8LiGgaSkbtrChCqILPxawqGAwNBdhfMfNU= MIME-Version: 1.0 Received: by 10.239.190.76 with SMTP id w12mr156058hbh.175.1283179745063; Mon, 30 Aug 2010 07:49:05 -0700 (PDT) Sender: ronc.ntear@gmail.com Received: by 10.220.177.3 with HTTP; Mon, 30 Aug 2010 07:49:04 -0700 (PDT) In-Reply-To: <004401cb4580$7ebdf5e0$43548a0a@china.huawei.com> References: <004201cb4535$cd451130$4b0c7c0a@china.huawei.com> <004401cb4580$7ebdf5e0$43548a0a@china.huawei.com> Date: Mon, 30 Aug 2010 17:49:04 +0300 X-Google-Sender-Auth: YmTjzNmAbGUlbmRTXYechoTt22k Message-ID: From: Ron Cohen To: Li Yizhou Content-Type: multipart/alternative; boundary=001485f1ebdee3355b048f0b902d Cc: arp222@ietf.org Subject: Re: [arp222] Considering to change ARP222 name 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 14:48:36 -0000 --001485f1ebdee3355b048f0b902d Content-Type: text/plain; charset=ISO-8859-1 How about SAR4VAN: Scalable Address Resolution For Virtualization Aware Networking? On Fri, Aug 27, 2010 at 3:40 AM, Li Yizhou wrote: > How about just ARM(address resolution for massive nodes) or Armed(address > resolution for massive end-nodes)? :) > > > > Yizhou > > > ------------------------------ > *From:* arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] *On > Behalf Of *Linda Dunbar > *Sent:* Thursday, August 26, 2010 11:46 PM > *To:* arp222@ietf.org > *Subject:* [arp222] Considering to change ARP222 name > > It has been pointed to us by several people that the name ARP222 is a > little misleading. The main objective is to resolve issues associated with > *A*ddress *R*esolution for *M*assive amount of VMs or virtual hosts/*N*odes > in one broadcast *D*omain. > > > > What do you think if we change the name to *ARMD* or *ARMND*? > > > > Your opinion is appreciated. > > > > Linda Dunbar > > > > > _______________________________________________ > arp222 mailing list > arp222@ietf.org > https://www.ietf.org/mailman/listinfo/arp222 > > --001485f1ebdee3355b048f0b902d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about SAR4VAN: Scalable Address Resolution For Virtual= ization Aware Networking?

On Fri, Aug 27,= 2010 at 3:40 AM, Li Yizhou <liyizhou@huawei.com> wrote:

How about just ARM(address resolution for massive= =20 nodes)=C2=A0or Armed(address resolution for massive end-nodes)?=20 :)

= =C2=A0

=C2=A0

Yizhou =

=C2=A0

From: arp222-bounces@ietf.org=20 [mailto:arp2= 22-bounces@ietf.org] On Behalf Of Linda=20 Dunbar
Sent: Thursday, August 26, 2010 11:46 PM
To:= =20 arp222@ietf.org<= br>Subject: [arp222] Considering to change ARP222=20 name

It has been pointed to us by=20 several people that the name ARP222 is a little misleading. The main obje= ctive=20 is to resolve issues associated with Resol= ution for Massive amount o= f VMs or virtual=20 hosts/Nodes in one broad= cast=20 Domain.=20

=C2=A0

What do you think if we change the=20 name to ARMD or ARMND?

=C2=A0

Your opinion is appreciated.=20

=C2=A0

Linda=20 Dunbar

=C2=A0

_______________________________________________
arp222 mailing list
arp222@ietf.org = https://www.ietf.org/mailman/listinfo/arp222

--001485f1ebdee3355b048f0b902d-- From ronc.ntear@gmail.com Mon Aug 30 09:42:39 2010 Return-Path: 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 1A6023A67E5 for ; Mon, 30 Aug 2010 09:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.796 X-Spam-Level: X-Spam-Status: No, score=-98.796 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 9kq1jSyVqBbJ for ; Mon, 30 Aug 2010 09:42:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A3CB43A682B for ; Mon, 30 Aug 2010 09:42:36 -0700 (PDT) Received: by vws10 with SMTP id 10so5663963vws.31 for ; Mon, 30 Aug 2010 09:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=iOno/rGlxeqHwx+6BglxFfk5zlnf6+xE0H1uUxcKgOE=; b=wEplfq6fl/GJsAeMPoxtcMk0Y830qkqgsOtDKeNivSPxUSSM0A5JdvztEYS8C4RXCY GPLtlIM31qCXTGhG4RwC6L1ifvlQc+ameW5FbQUGixXD0qQUfEbvb1RLju/8NT6gTth1 W00WQ3b4BpI6NwDeRK85hNbVcFjWqQ51q/Oz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=uXYsRnXhFL0JQC8GrEaQAFKELqrWaNcCYmVpbcssinLHXcZKgxO9VTD6bBqpYwU5pW alRMHxBSTcuSWeNpBByyFVR/wj+AKc6Rt9PhCtt49eQ/9t9HKP0Yix6wjJlUWTle1W3P njeFNsGL8JjeR0Osn/bxkQJsbkK/ojt/jay7A= MIME-Version: 1.0 Received: by 10.220.62.72 with SMTP id w8mr2883474vch.172.1283186586711; Mon, 30 Aug 2010 09:43:06 -0700 (PDT) Sender: ronc.ntear@gmail.com Received: by 10.220.177.3 with HTTP; Mon, 30 Aug 2010 09:43:04 -0700 (PDT) In-Reply-To: <00ea01cb4564$0dbff080$4b0c7c0a@china.huawei.com> References: <00f901cb3a74$1bb07e80$5d0c7c0a@china.huawei.com> <1188AC2B-0E47-45FD-8CA3-F755B24A0E2E@queuefull.net> <00ea01cb4564$0dbff080$4b0c7c0a@china.huawei.com> Date: Mon, 30 Aug 2010 19:43:04 +0300 X-Google-Sender-Auth: 4EcmZeHlOXUH3X6abEGonSnCK6I Message-ID: From: Ron Cohen To: Linda Dunbar Content-Type: multipart/alternative; boundary=e0cb4e887811b026e1048f0d2836 Cc: arp222@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 16:42:39 -0000 --e0cb4e887811b026e1048f0d2836 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, My comments - I'm going to echo some of Benson's and Anoop's points. Separate the problem scope into: 1. Singe Data Center (DC) 2. Distributed Data Center (DDC) 3. Cloud Computing (CC) I'm concerned that we don't have sufficient understanding of the cloud computing networking environment, and at this point in time we should include an action item or goal to study the requirements of cloud computing in this area. We should have CC providers participating in the discussion, clarifying current practice and outstanding issues. I do not think that any CC service allows multiple clients on the same broadcast domain due to security concerns, and all services include some form of built-in firewalls in the hypervisor level to enforce traffic separation. Until this is clarified all mention of duplicate IP addresses of multiple clients on the same VLAN, exhaustion of VLANs, etc should be removed from the charter. The current problem scope does not mention DDC explicitly, and it should. I= f ARP222 becomes a working group some standardized version of Cisco's OTV or similar will need to worked on. I think that behavior changes within the hypervisor level should be considered by ARP222. It is not clear to me whether this is in conflict with 'All solutions developed by ARP222 WG should not expect any behavior changes on hosts, applications, or Virtual Machines being deployed in the market.' I think that study of MOOSE or SEATLE should not be part of the goals and milestones. This is not to say that these solutions are not adequate or tha= t they will not be considered. I'm not clear why it should be explicitly mentioned that it is not allowed to re-define DHCP. I suggest to remove. Best, Ron On Fri, Aug 27, 2010 at 12:17 AM, Linda Dunbar wrote: > Benson, > > > > Thank you very much for the suggestion. Let=92s see if other people have > similar comments or other suggestions. > > The goal of circulating the tentative Charter statement is to make needed > changes before submitting to the IESG in mid Sept. > > > > Linda > > > ------------------------------ > > *From:* Benson Schliesser [mailto:bensons@queuefull.net] > *Sent:* Thursday, August 26, 2010 3:12 PM > > *To:* Linda Dunbar; arp222@ietf.org > *Subject:* Re: [arp222] ARP222 Charter statement and milestones > > > > Linda - > > > > I'd like to see a few modifications to the charter you've outlined: > > > > 1) I've already explained why I think the last design goal (overlapping I= P > addresses within a single VLAN) should be removed. I won't reiterate tha= t > here. > > > > 2) The goal to "not break DHCP" should be modified to include any broadca= st > and/or multicast protocols. (Alternatively, broadcast and multicast supp= ort > can be required by a new goal to be added.) > > > > 3) The goal of supporting interconnect scenarios should explicitly includ= e > L3VPN. In case it isn't clear, that implies a goal of support for > overlapping IP addresses within the datacenter. (Albeit in different > broadcast domains, my comments in #1 above notwithstanding.) > > > > 4) A new goal should include a performance analysis of all solutions > considered. This might explicitly acknowledge a role for negative cachin= g > approaches, but that shouldn't be a requirement. > > > > Cheers, > > -Benson > > > > > > > > On 12 Aug 10, at 6:14 PM, Linda Dunbar wrote: > > > > 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. Pleas= e > 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 hos= ts > in a data center can grow dramatically because each physical server, whic= h > 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 achievin= g > better performance and better utilization on servers, they are also a ver= y > 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 t= han > 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 b= e > 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:* > > =B7 All solutions developed by ARP222 WG should not expect any > behavior changes on hosts, applications, or Virtual Machines being deploy= ed > in the market. > > =B7 All solutions developed should not break DHCP. > > =B7 Evaluating the impact to IPv6 ND, and develop solutions > accordingly if needed. > > =B7 Should consider variety of solutions, including directory base= d, > proxy based, or cache based solutions. > > =B7 Include analysis of security concerns of IPv4 ARP requests fro= m > malicious users. Evaluating potential security solutions and conclude if = the > security threat can justify solutions. > > =B7 ARP222 assumes the direct links to individual hosts and virtua= l > machines are IEEE802.3 Ethernet links. > > =B7 Should consider scenarios of one Ethernet network being > interconnected by another network, which can be L2VPN, pure IP, Ethernet,= or > others. > > =B7 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= : > * > > =B7 Re-define DHCP behavior > > =B7 Re-define security concern to IPv6 ND > > =B7 Direct links from hosts and virtual hosts are non Ethernet lin= ks > > =B7 > > > > *Goals and Milestones:* > > =B7 Charter statement > > =B7 Problem Statements > > =B7 Gap analysis > > =B7 Study of NHRP (RFC2332) & SCSP, and their applicability to > Ethernet networks > > =B7 Study and Analysis of MOOSE as a potential solution > > =B7 Study and Analysis of SEATTLE as a potential solution. > > > > > > Best Regards, Linda Dunbar > > > > _______________________________________________ > arp222 mailing list > arp222@ietf.org > https://www.ietf.org/mailman/listinfo/arp222 > > > > _______________________________________________ > arp222 mailing list > arp222@ietf.org > https://www.ietf.org/mailman/listinfo/arp222 > > --e0cb4e887811b026e1048f0d2836 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

My comments - I'm going to echo some of Benson's and Anoop= 's points.

Separate the problem scope into:

1. Singe Data Center (DC)
2.=A0Distributed= Data Center (DDC)

3.=A0Cloud Computing (CC)

I'm concer= ned that we don't have sufficient understanding of the cloud computing = networking environment, and at this point in time we should include an acti= on item or goal to study the requirements of cloud computing in this area. = We should have CC providers participating in the discussion, clarifying cur= rent practice and outstanding issues. I do not think that any CC service al= lows multiple clients on the same broadcast domain due to security concerns= , and all services include some form of built-in firewalls in the hyperviso= r level to enforce traffic separation. Until this is clarified all mention = of duplicate IP addresses of multiple clients on the same VLAN, exhaustion = of VLANs, etc should be removed from the charter.=A0

The current problem scope does not mention DDC ex= plicitly, and it should. If ARP222 becomes a working group some standardize= d version of Cisco's OTV or similar will need to worked on.=A0

I think that behavior changes within the hypervisor level sh= ould be considered by ARP222. It is not clear to me whether this is in conf= lict with=A0=A0'All solutions developed by ARP222 WG should not expect = any behavior changes on hosts, applications, or Virtual Machines being depl= oyed in the market.'=A0

=A0
I think that study of MOOSE or SEATLE should not be part= of the goals and milestones. This is not to say that these solutions are n= ot adequate or that they will not be considered.

I'm not clear why it should be explicitly mentioned that it is not allo= wed to re-define DHCP. I suggest to remove.

Best,<= /div>
Ron

On Fri, Aug 27, 2010 at 12:17 AM, Linda = Dunbar <ldunbar@= huawei.com> wrote:

Benson,

=A0

Thank you very= much for the suggestion. Let=92s see if other people have similar comments or other suggestions.

The goal of ci= rculating the tentative Charter statement is to make needed changes before submitting to the IESG i= n mid Sept.

=A0

Linda <= /font>

=A0

From: Benson Schliesser [mailto:bensons@queuefull.net]
Sent: Thursday, August 26,= 2010 3:12 PM

To: Linda Dunbar; arp222@ietf.org

Subject: Re: [arp222] ARP222 Charter statement and milestones

=A0

Linda -=

=A0

I'd like to see a= few modifications to the charter you've outlined:

=A0

1) I've already e= xplained why I think the last design goal (overlapping IP addresses within a single VLAN) should be removed. =A0= I won't reiterate that here.

=A0

2) The goal to "= not break DHCP" should be modified to include any broadcast and/or multicast protocols. =A0(Alternatively, broadcast and multicast support can be required by a new goal to be added.)

=A0

3) The goal of suppor= ting interconnect scenarios should explicitly include L3VPN. =A0In case it isn't clear, that implie= s a goal of support for overlapping IP addresses within the datacenter. (Albeit= in different broadcast domains, my comments in #1 above notwithstanding.)

=A0

4) A new goal should = include a performance analysis of all solutions considered. =A0This might explicitly acknowledge a role for negative caching approaches, but that shouldn't be a requirement.

=A0

Cheers,=

-Benson=

=A0

=A0

=A0

On 12 Aug 10, at 6:14= PM, Linda Dunbar wrote:

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

=A0<= /font>

I put toget= her the initial ARP222 Charter Statement and Milestones. Please provide comments and suggestions. =A0

=A0<= /font>

=A0<= /font>

=A0<= /font>

=A0<= /font>

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

=A0

= Description of Working Group:

As server v= irtualization 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 Machine= s, with its flexible add/delete and mobility features, not only makes it possi= ble for achieving better performance and better utilization on servers, they ar= e 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 add= ress resolution (IPv4) or neighbor discovery (IPv6) requests from hosts. All hos= ts 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 tha= n 1,000 to 10,000/second. This rate imposes tremendous computational burden o= n many hosts.

Another big= issue associated with huge number of virtual hosts in a data center is potentially duplicated IP addre= sses within one VLAN which will make traditional ARP or ND not working properly. Some load balance design requires multiple hosts serving the same applicati= on to have the same IP address but with different MAC addresses. Cloud Computi= ng service could allow users to have their own subnets with IP addresses and s= elf defined policies among those subnets. Some network designs need to put mult= iple 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 scenar= io, there could be duplicated IP addresses which are from different client subn= ets ending up in one VLAN.=A0

The goal of= this working group is to develop interoperable solutions to solve those problems.=A0 <= /p>
= The design should consider the following properties:

=B7=A0=A0=A0=A0=A0=A0=A0 All solutions developed by ARP222 WG should not expect any behavior changes on hosts, applications, or Virtua= l Machines being deployed in the market.

=B7=A0=A0=A0=A0=A0=A0=A0 All solutions developed should not break DHCP.

=B7=A0=A0=A0=A0=A0=A0=A0 Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed.

=B7=A0=A0=A0=A0=A0=A0=A0 Should consider variety of solutions, including directory based, proxy based, or cache based solutions= .

=B7=A0=A0=A0=A0=A0=A0=A0 Include analysis of security concerns of IPv4 ARP requests from malicious users. Evaluating potential security solutions and conclude if the security threat can justify solution= s.

=B7=A0=A0=A0=A0=A0=A0=A0 ARP222 assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet links.=A0

=B7=A0=A0=A0=A0=A0=A0=A0 Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VP= N, pure IP, Ethernet, or others.

=B7=A0=A0=A0=A0=A0=A0=A0 Should consider address resolution solutions for one VLAN with small number of duplicated IP addresses.=A0
= =A0

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

=B7=A0=A0=A0=A0=A0=A0=A0 Re-define DHCP behavior

=B7=A0=A0=A0=A0=A0=A0=A0 Re-define security concern to IPv6 ND

=B7=A0=A0=A0=A0=A0=A0=A0 Direct links from hosts and virtual hosts are non Ethernet links

=B7=A0=A0=A0=A0=A0=A0=A0 =A0

=A0

= Goals and Milestones:

=B7=A0=A0=A0=A0=A0=A0=A0 Charter statement

=B7=A0=A0=A0=A0=A0=A0=A0 Problem Statements

=B7=A0=A0=A0=A0=A0=A0=A0 Gap analysis

=B7=A0=A0=A0=A0=A0=A0=A0 Study of NHRP (RFC2332) & SCSP, =A0and their applicability to Ethernet networks

=B7=A0=A0=A0=A0=A0=A0=A0 Study and Analysis of MOOSE as a potential solution

=B7=A0=A0=A0=A0=A0=A0=A0 Study and Analysis of SEATTLE as a potential solution.

=A0

=A0<= /font>

Best Regards, Linda Dunbar

=A0

_____________________= __________________________
arp222 mailing list
arp222@ietf.org = https://www.ietf.org/mailman/listinfo/arp222

=A0

_______________________________________________
arp222 mailing list
arp222@ietf.org
= https://www.ietf.org/mailman/listinfo/arp222

--e0cb4e887811b026e1048f0d2836-- From tsridhar@force10networks.com Mon Aug 30 12:36:31 2010 Return-Path: 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 AF4F93A696B for ; Mon, 30 Aug 2010 12:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.865 X-Spam-Level: X-Spam-Status: No, score=-4.865 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 AsXMM3sjRXgB for ; Mon, 30 Aug 2010 12:36:22 -0700 (PDT) Received: from mx.force10networks.com (corp.force10networks.com [64.186.164.204]) by core3.amsl.com (Postfix) with ESMTP id 3247D3A6814 for ; Mon, 30 Aug 2010 12:36:22 -0700 (PDT) Received: from EXCH-CLUSTER-09.force10networks.com ([10.11.10.113]) by exch7-sjc-fe.force10networks.com ([10.11.0.87]) with mapi; Mon, 30 Aug 2010 12:36:52 -0700 From: T Sridhar To: "arp222@ietf.org" Date: Mon, 30 Aug 2010 12:36:51 -0700 Thread-Topic: [arp222] Considering to change ARP222 name Thread-Index: ActFNcoOlonQryKGTsKJPvIV7C/iVQAD/E5gAC92TFAAnbY5sA== Message-ID: <016D6D95AF0949478938DD97B5218DE6021802D06175@EXCH-CLUSTER-09.force10networks.com> References: <004201cb4535$cd451130$4b0c7c0a@china.huawei.com> <016D6D95AF0949478938DD97B5218DE6021802C60760@EXCH-CLUSTER-09.force10networks.com> <00bc01cb4603$f11fcb30$4b0c7c0a@china.huawei.com> In-Reply-To: <00bc01cb4603$f11fcb30$4b0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_016D6D95AF0949478938DD97B5218DE6021802D06175EXCHCLUSTER_" MIME-Version: 1.0 Subject: Re: [arp222] Considering to change ARP222 name 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 19:36:32 -0000 --_000_016D6D95AF0949478938DD97B5218DE6021802D06175EXCHCLUSTER_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in favor of ARMD which could expand to "Address Resolution Mechanism= s for large broadcast Domains". Thanks, Sridhar From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of= Linda Dunbar Sent: Thursday, August 26, 2010 8:46 AM To: arp222@ietf.org Subject: [arp222] Considering to change ARP222 name It has been pointed to us by several people that the name ARP222 is a littl= e misleading. The main objective is to resolve issues associated with Addre= ss Resolution for Massive amount of VMs or virtual hosts/Nodes in one broad= cast Domain. What do you think if we change the name to ARMD or ARMND? Your opinion is appreciated. Linda Dunbar --_000_016D6D95AF0949478938DD97B5218DE6021802D06175EXCHCLUSTER_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in favor of ARMD which could expand to R= 20;Address Resolution Mechanisms for large broadcast Domains”.=

Thanks,

Sridhar

<= /p>

From: arp222-bounces@ietf.org [mailto:arp222-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, August 26, 2010 8:46 AM
To: arp222@ietf.org
Subject: [arp222] Considering to change ARP222 name

It has been pointed to us by several people that the name ARP222 is a little misleading. The main objective is to resolve issues associated with Address Resolution for Massive amount of VMs or virtual hosts/Nodes in one broadcast Domain.

What do you think if we change the name to ARMD or ARMND?

Your opinion is appreciated.

Linda Dunbar

--_000_016D6D95AF0949478938DD97B5218DE6021802D06175EXCHCLUSTER_-- From ldunbar@huawei.com Mon Aug 30 16:12:25 2010 Return-Path: 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 683393A69F9 for ; Mon, 30 Aug 2010 16:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.692 X-Spam-Level: X-Spam-Status: No, score=-100.692 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 es+XHUegYkFJ for ; Mon, 30 Aug 2010 16:12:10 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 4C9063A68CE for ; Mon, 30 Aug 2010 16:12:10 -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 <0L7Z00GL7N53GD@usaga02-in.huawei.com> for arp222@ietf.org; Mon, 30 Aug 2010 16:12:40 -0700 (PDT) Received: from L735042 ([10.124.12.75]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7Z004C8N53SN@usaga02-in.huawei.com> for arp222@ietf.org; Mon, 30 Aug 2010 16:12:39 -0700 (PDT) Date: Mon, 30 Aug 2010 18:12:39 -0500 From: Linda Dunbar In-reply-to: To: 'Ron Cohen' Message-id: <00d801cb4898$d7748e40$4b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_YQZlR3cRhP442hdQha0izg)" Thread-index: ActIYpCWnYOX1rvdSx+snKId6i/UOAAEo6FA References: <00f901cb3a74$1bb07e80$5d0c7c0a@china.huawei.com> <1188AC2B-0E47-45FD-8CA3-F755B24A0E2E@queuefull.net> <00ea01cb4564$0dbff080$4b0c7c0a@china.huawei.com> Cc: arp222@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 23:12:25 -0000 This is a multi-part message in MIME format. --Boundary_(ID_YQZlR3cRhP442hdQha0izg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Ron, Ron, Thank you very much for the suggestions. My comments are inserted below: _____ From: ronc.ntear@gmail.com [mailto:ronc.ntear@gmail.com] On Behalf Of Ron Cohen Sent: Monday, August 30, 2010 11:43 AM To: Linda Dunbar Cc: Benson Schliesser; arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones Hi, My comments - I'm going to echo some of Benson's and Anoop's points. Separate the problem scope into: 1. Singe Data Center (DC) 2. Distributed Data Center (DDC) 3. Cloud Computing (CC) [Linda] The first 2 bullets are valid scenarios for DC. But I don't see the 3rd one as an independent category for the ARP222 (or soon to be renamed ARMD). I see that the Cloud computing could be some applications loaded to Data Center. I'm concerned that we don't have sufficient understanding of the cloud computing networking environment, and at this point in time we should include an action item or goal to study the requirements of cloud computing in this area. We should have CC providers participating in the discussion, clarifying current practice and outstanding issues. I do not think that any CC service allows multiple clients on the same broadcast domain due to security concerns, and all services include some form of built-in firewalls in the hypervisor level to enforce traffic separation. Until this is clarified all mention of duplicate IP addresses of multiple clients on the same VLAN, exhaustion of VLANs, etc should be removed from the charter. [Linda] First of all, including duplicated IP in one VLAN is not a main objective. We can definitely remove it from the Charter. We are working together with our company's Cloud service BU on requirement. Amazon's Virtual Private Cloud (http://aws.amazon.com/vpc/) allows client to use their own IP addresses. It is definitely true that they won't allow communication across different VPCs. As of now, Amazon doesn't even allow any multicast among hosts within one VPC (http://developer.amazonwebservices.com/connect/thread.jspa?messageID=150951 ). There is distinction between Client Controlled subnets (e.g. Amazon's VPC) and the actual subnets which connect all the physical servers. The Client Controlled subnets are virtual subnets. When they are assigned to servers, many of them will be assigned to one physical subnet in order to have the VMmobility. You can use VLAN to distinguish VPCs. But, you will quickly used up all the VLANs. That is my original intention. The current problem scope does not mention DDC explicitly, and it should. If ARP222 becomes a working group some standardized version of Cisco's OTV or similar will need to worked on. [Linda] The original name ARP222 (Address Resolution for Layer 2 to Anything to Layer 2) intends to emphasize that one large Layer 2 could consists of many pockets of Layer 2 which are interconnected by Layer 3 or MPLS. So it does want to include DDC. Once we change the name to ARMD, we need to bring it up in the Charter. I think that behavior changes within the hypervisor level should be considered by ARP222. It is not clear to me whether this is in conflict with 'All solutions developed by ARP222 WG should not expect any behavior changes on hosts, applications, or Virtual Machines being deployed in the market.' [Linda] I don't think the behavior changes within the Hypervisor should be addressed by ARP222. I think that study of MOOSE or SEATLE should not be part of the goals and milestones. This is not to say that these solutions are not adequate or that they will not be considered. [Linda] Agree. They are just some available solutions on the table which people agreed to write a draft on. We should lump it together to GAP analysis or existing solution analysis. I'm not clear why it should be explicitly mentioned that it is not allowed to re-define DHCP. I suggest to remove. [Linda] We were told by the ADs to state clearly what is in the scope and what is not in the scope. That is why we have those statements. We don't anticipate any changes to DHCP. Best, Ron On Fri, Aug 27, 2010 at 12:17 AM, Linda Dunbar wrote: Benson, Thank you very much for the suggestion. Let's see if other people have similar comments or other suggestions. The goal of circulating the tentative Charter statement is to make needed changes before submitting to the IESG in mid Sept. Linda _____ From: Benson Schliesser [mailto:bensons@queuefull.net] Sent: Thursday, August 26, 2010 3:12 PM To: Linda Dunbar; arp222@ietf.org Subject: Re: [arp222] ARP222 Charter statement and milestones Linda - I'd like to see a few modifications to the charter you've outlined: 1) I've already explained why I think the last design goal (overlapping IP addresses within a single VLAN) should be removed. I won't reiterate that here. 2) The goal to "not break DHCP" should be modified to include any broadcast and/or multicast protocols. (Alternatively, broadcast and multicast support can be required by a new goal to be added.) 3) The goal of supporting interconnect scenarios should explicitly include L3VPN. In case it isn't clear, that implies a goal of support for overlapping IP addresses within the datacenter. (Albeit in different broadcast domains, my comments in #1 above notwithstanding.) 4) A new goal should include a performance analysis of all solutions considered. This might explicitly acknowledge a role for negative caching approaches, but that shouldn't be a requirement. Cheers, -Benson On 12 Aug 10, at 6:14 PM, Linda Dunbar wrote: 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 _______________________________________________ arp222 mailing list arp222@ietf.org https://www.ietf.org/mailman/listinfo/arp222 _______________________________________________ arp222 mailing list arp222@ietf.org https://www.ietf.org/mailman/listinfo/arp222 --Boundary_(ID_YQZlR3cRhP442hdQha0izg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Ron,

Ron,

Thank you very much for the suggestions.

My comments are inserted below:

From: ronc.ntear@gmail.com [mailto:ronc.ntear@gmail.com] On Behalf Of Ron Cohen
Sent: Monday, August 30, 2010 11:43 AM
To: Linda Dunbar
Cc: Benson Schliesser; arp222@ietf.org
Subject: Re: [arp222] ARP222 Charter statement and milestones

Hi,

My comments - I'm going to echo some of Benson's and Anoop's points.

Separate the problem scope into:

1. Singe Data Center (DC)

2. Distributed Data Center (DDC)

3. Cloud Computing (CC)

[Linda] The first 2 bullets are valid scenarios for DC. But I don’t see the 3^rd one as an independent category for the ARP222 (or soon to be renamed ARMD). I see that the Cloud computing could be some applications loaded to Data Center.

I'm concerned that we don't have sufficient understanding of the cloud computing networking environment, and at this point in time we should include an action item or goal to study the requirements of cloud computing in this area. We should have CC providers participating in the discussion, clarifying current practice and outstanding issues. I do not think that any CC service allows multiple clients on the same broadcast domain due to security concerns, and all services include some form of built-in firewalls in the hypervisor level to enforce traffic separation. Until this is clarified all mention of duplicate IP addresses of multiple clients on the same VLAN, exhaustion of VLANs, etc should be removed from the charter.

[Linda] First of all, including duplicated IP in one VLAN is not a main objective. We can definitely remove it from the Charter.

We are working together with our company’s Cloud service BU on requirement. Amazon’s Virtual Private Cloud (http://aws.amazon.com/vpc/) allows client to use their own IP addresses. It is definitely true that they won’t allow communication across different VPCs. As of now, Amazon doesn’t even allow any multicast among hosts within one VPC (http://developer.amazonwebservices.com/connect/thread.jspa?messageID=150951).

There is distinction between Client Controlled subnets (e.g. Amazon’s VPC) and the actual subnets which connect all the physical servers. The Client Controlled subnets are virtual subnets. When they are assigned to servers, many of them will be assigned to one physical subnet in order to have the VMmobility. You can use VLAN to distinguish VPCs. But, you will quickly used up all the VLANs.

That is my original intention.

The current problem scope does not mention DDC explicitly, and it should. If ARP222 becomes a working group some standardized version of Cisco's OTV or similar will need to worked on.

[Linda] The original name ARP222 (Address Resolution for Layer 2 to Anything to Layer 2) intends to emphasize that one large Layer 2 could consists of many pockets of Layer 2 which are interconnected by Layer 3 or MPLS. So it does want to include DDC. Once we change the name to ARMD, we need to bring it up in the Charter.

I think that behavior changes within the hypervisor level should be considered by ARP222. It is not clear to me whether this is in conflict with  'All solutions developed by ARP222 WG should not expect any behavior changes on hosts, applications, or Virtual Machines being deployed in the market.'

[Linda] I don’t think the behavior changes within the Hypervisor should be addressed by ARP222.

I think that study of MOOSE or SEATLE should not be part of the goals and milestones. This is not to say that these solutions are not adequate or that they will not be considered.

[Linda] Agree. They are just some available solutions on the table which people agreed to write a draft on. We should lump it together to GAP analysis or existing solution analysis.

I'm not clear why it should be explicitly mentioned that it is not allowed to re-define DHCP. I suggest to remove.

[Linda] We were told by the ADs to state clearly what is in the scope and what is not in the scope. That is why we have those statements. We don’t anticipate any changes to DHCP.

Best,

Ron

On Fri, Aug 27, 2010 at 12:17 AM, Linda Dunbar <ldunbar@huawei.com> wrote:

Benson,

Thank you very much for the suggestion. Let’s see if other people have similar comments or other suggestions.

The goal of circulating the tentative Charter statement is to make needed changes before submitting to the IESG in mid Sept.

Linda

From: Benson Schliesser [mailto:bensons@queuefull.net]
Sent: Thursday, August 26, 2010 3:12 PM

To: Linda Dunbar; arp222@ietf.org

Subject: Re: [arp222] ARP222 Charter statement and milestones

Linda -

I'd like to see a few modifications to the charter you've outlined:

1) I've already explained why I think the last design goal (overlapping IP addresses within a single VLAN) should be removed. I won't reiterate that here.

2) The goal to "not break DHCP" should be modified to include any broadcast and/or multicast protocols. (Alternatively, broadcast and multicast support can be required by a new goal to be added.)

3) The goal of supporting interconnect scenarios should explicitly include L3VPN. In case it isn't clear, that implies a goal of support for overlapping IP addresses within the datacenter. (Albeit in different broadcast domains, my comments in #1 above notwithstanding.)

4) A new goal should include a performance analysis of all solutions considered. This might explicitly acknowledge a role for negative caching approaches, but that shouldn't be a requirement.

Cheers,

-Benson

On 12 Aug 10, at 6:14 PM, Linda Dunbar wrote:

Thank you all for coming to ARP222 Bar BOF at the 78^th 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

_______________________________________________
arp222 mailing list
arp222@ietf.org
https://www.ietf.org/mailman/listinfo/arp222

_______________________________________________
arp222 mailing list
arp222@ietf.org
https://www.ietf.org/mailman/listinfo/arp222

--Boundary_(ID_YQZlR3cRhP442hdQha0izg)-- From ronc.ntear@gmail.com Tue Aug 31 00:44:02 2010 Return-Path: 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 8F8B53A691D for ; Tue, 31 Aug 2010 00:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.746 X-Spam-Level: X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 puHNH-4X3WPg for ; Tue, 31 Aug 2010 00:43:59 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 7D1133A690A for ; Tue, 31 Aug 2010 00:43:59 -0700 (PDT) Received: by gwb20 with SMTP id 20so2891499gwb.31 for ; Tue, 31 Aug 2010 00:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=9C+wWX6HMv2a6DltB+Fnss6AWgrSixqfDIc2Oq4xdkY=; b=uJSEluWm3kCUA2peEaHANvlH6fuDLEFPUHlwxOEaufzD3WSCZEhXnP0KAZj7kiodnc BOjp96fyFY3pKNrIOrnmTx7PSiX0SS41c8KpQ/MYWcWQDeovrFWzp8vzNDbQTXt7Yn97 q6VipXYjuqmWHrpZAcPOM3iTeeLmsBAXQCeH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=YsTEg9oWITRsVWOovLtKRbma3YzP/JxiDBYqZrUJGUqLEN3EzraSq7HQ5eoYh7ffWx Z+E44WOCgvVbBZ3y3UF4OZ6AtHum1A7nHS9a5CuhwkOGocO/eZmLYEgJe7inVGFjDNP4 s0874oMAdJEYXZB3UVYjvvxacsahZhW6hbHu0= MIME-Version: 1.0 Received: by 10.220.122.103 with SMTP id k39mr3210581vcr.67.1283240669982; Tue, 31 Aug 2010 00:44:29 -0700 (PDT) Sender: ronc.ntear@gmail.com Received: by 10.220.177.3 with HTTP; Tue, 31 Aug 2010 00:44:29 -0700 (PDT) In-Reply-To: <00d801cb4898$d7748e40$4b0c7c0a@china.huawei.com> References: <00f901cb3a74$1bb07e80$5d0c7c0a@china.huawei.com> <1188AC2B-0E47-45FD-8CA3-F755B24A0E2E@queuefull.net> <00ea01cb4564$0dbff080$4b0c7c0a@china.huawei.com> <00d801cb4898$d7748e40$4b0c7c0a@china.huawei.com> Date: Tue, 31 Aug 2010 10:44:29 +0300 X-Google-Sender-Auth: bGf-dbVfZKjeyuKYFwnjBDexpv8 Message-ID: From: Ron Cohen To: Linda Dunbar Content-Type: multipart/alternative; boundary=0016e68ea5064bb070048f19c0a5 Cc: arp222@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 07:44:02 -0000 --0016e68ea5064bb070048f19c0a5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Linda, I'm glad I read your reply twice before answering. I hope I didn't have to read it thrice... Please see inline On Tue, Aug 31, 2010 at 2:12 AM, Linda Dunbar wrote: > Hi Ron, > > > > Ron, > > > > Thank you very much for the suggestions. > > My comments are inserted below: > > > > > ------------------------------ > > *From:* ronc.ntear@gmail.com [mailto:ronc.ntear@gmail.com] *On Behalf Of = *Ron > Cohen > *Sent:* Monday, August 30, 2010 11:43 AM > *To:* Linda Dunbar > *Cc:* Benson Schliesser; arp222@ietf.org > > *Subject:* Re: [arp222] ARP222 Charter statement and milestones > > > > Hi, > > My comments - I'm going to echo some of Benson's and Anoop's points. > > > > Separate the problem scope into: > > > > 1. Singe Data Center (DC) > > 2. Distributed Data Center (DDC) > > 3. Cloud Computing (CC) > > > > [Linda] The first 2 bullets are valid scenarios for DC. But I don=92t see= the > 3rd one as an independent category for the ARP222 (or soon to be renamed > ARMD). I see that the Cloud computing could be some applications loaded t= o > Data Center. > ronc: I understand your approach. I agree that this is a desired architecture: separate infrastructure and application. A clear layer separation would in principle allow us to implement DDC over CC etc. Howeve= r it is not clear to me how you achieve this desired goal in practice, and whether such clean separation is not in conflict with practical considerations. Unless we fully understand how CC is overlaid on top of a DDC, it is hard to draw any useful requirements from the CC application to ARMD. I'm concerned that we don't have sufficient understanding of the cloud > computing networking environment, and at this point in time we should > include an action item or goal to study the requirements of cloud computi= ng > in this area. We should have CC providers participating in the discussion= , > clarifying current practice and outstanding issues. I do not think that a= ny > CC service allows multiple clients on the same broadcast domain due to > security concerns, and all services include some form of built-in firewal= ls > in the hypervisor level to enforce traffic separation. Until this is > clarified all mention of duplicate IP addresses of multiple clients on th= e > same VLAN, exhaustion of VLANs, etc should be removed from the charter. > > [Linda] First of all, including duplicated IP in one VLAN is not a main > objective. We can definitely remove it from the Charter. > > We are working together with our company=92s Cloud service BU on requirem= ent. > Amazon=92s Virtual Private Cloud (http://aws.amazon.com/vpc/) allows clie= nt > to use their own IP addresses. It is definitely true that they won=92t al= low > communication across different VPCs. As of now, Amazon doesn=92t even all= ow > any multicast among hosts within one VPC ( > http://developer.amazonwebservices.com/connect/thread.jspa?messageID=3D15= 0951). > > > > > There is distinction between Client Controlled subnets (e.g. Amazon=92s V= PC) > and the actual subnets which connect all the physical servers. The Client > Controlled subnets are virtual subnets. When they are assigned to servers= , > many of them will be assigned to one physical subnet in order to have the > VMmobility. You can use VLAN to distinguish VPCs. But, you will quickly u= sed > up all the VLANs. > > That is my original intention. > > ronc: What do you mean by 'assigned to one physical subnet in order to have VMmobility'? Does each VM have two interfaces, one attached to the client controlled subnet and one connected to the internal CC provider subnet for VMmobility? > > > > The current problem scope does not mention DDC explicitly, and it should. > If ARP222 becomes a working group some standardized version of Cisco's OT= V > or similar will need to worked on. > > > > [Linda] The original name ARP222 (Address Resolution for Layer 2 to > Anything to Layer 2) intends to emphasize that one large Layer 2 could > consists of many pockets of Layer 2 which are interconnected by Layer 3 o= r > MPLS. So it does want to include DDC. Once we change the name to ARMD, we > need to bring it up in the Charter. > > > > I think that behavior changes within the hypervisor level should be > considered by ARP222. It is not clear to me whether this is in conflict > with 'All solutions developed by ARP222 WG should not expect any behavio= r > changes on hosts, applications, or Virtual Machines being deployed in the > market.' > > > > [Linda] I don=92t think the behavior changes within the Hypervisor should= be > addressed by ARP222. > ronc: What I meant to say is that once the problem scope is known, and assuming that a solution requires implementing (part of) it in the hypervisor, there is no point in rejecting it. The main requirement in my opinion is that the solution developed should not expect any behavior changes for the guest OS/applications running on the VMs. > > I think that study of MOOSE or SEATLE should not be part of the goals and > milestones. This is not to say that these solutions are not adequate or t= hat > they will not be considered. > > > > [Linda] Agree. They are just some available solutions on the table which > people agreed to write a draft on. We should lump it together to GAP > analysis or existing solution analysis. > > > > I'm not clear why it should be explicitly mentioned that it is not allowe= d > to re-define DHCP. I suggest to remove. > > > > [Linda] We were told by the ADs to state clearly what is in the scope and > what is not in the scope. That is why we have those statements. We don=92= t > anticipate any changes to DHCP. > > > > > > > Best, > > Ron > > > > On Fri, Aug 27, 2010 at 12:17 AM, Linda Dunbar > wrote: > > Benson, > > > > Thank you very much for the suggestion. Let=92s see if other people have > similar comments or other suggestions. > > The goal of circulating the tentative Charter statement is to make needed > changes before submitting to the IESG in mid Sept. > > > > Linda > > > ------------------------------ > > *From:* Benson Schliesser [mailto:bensons@queuefull.net] > *Sent:* Thursday, August 26, 2010 3:12 PM > > > *To:* Linda Dunbar; arp222@ietf.org > > *Subject:* Re: [arp222] ARP222 Charter statement and milestones > > > > Linda - > > > > I'd like to see a few modifications to the charter you've outlined: > > > > 1) I've already explained why I think the last design goal (overlapping I= P > addresses within a single VLAN) should be removed. I won't reiterate tha= t > here. > > > > 2) The goal to "not break DHCP" should be modified to include any broadca= st > and/or multicast protocols. (Alternatively, broadcast and multicast supp= ort > can be required by a new goal to be added.) > > > > 3) The goal of supporting interconnect scenarios should explicitly includ= e > L3VPN. In case it isn't clear, that implies a goal of support for > overlapping IP addresses within the datacenter. (Albeit in different > broadcast domains, my comments in #1 above notwithstanding.) > > > > 4) A new goal should include a performance analysis of all solutions > considered. This might explicitly acknowledge a role for negative cachin= g > approaches, but that shouldn't be a requirement. > > > > Cheers, > > -Benson > > > > > > > > On 12 Aug 10, at 6:14 PM, Linda Dunbar wrote: > > > > 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. Pleas= e > 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 hos= ts > in a data center can grow dramatically because each physical server, whic= h > 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 achievin= g > better performance and better utilization on servers, they are also a ver= y > 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 t= han > 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 b= e > 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:* > > =B7 All solutions developed by ARP222 WG should not expect any > behavior changes on hosts, applications, or Virtual Machines being deploy= ed > in the market. > > =B7 All solutions developed should not break DHCP. > > =B7 Evaluating the impact to IPv6 ND, and develop solutions > accordingly if needed. > > =B7 Should consider variety of solutions, including directory base= d, > proxy based, or cache based solutions. > > =B7 Include analysis of security concerns of IPv4 ARP requests fro= m > malicious users. Evaluating potential security solutions and conclude if = the > security threat can justify solutions. > > =B7 ARP222 assumes the direct links to individual hosts and virtua= l > machines are IEEE802.3 Ethernet links. > > =B7 Should consider scenarios of one Ethernet network being > interconnected by another network, which can be L2VPN, pure IP, Ethernet,= or > others. > > =B7 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= : > * > > =B7 Re-define DHCP behavior > > =B7 Re-define security concern to IPv6 ND > > =B7 Direct links from hosts and virtual hosts are non Ethernet lin= ks > > =B7 > > > > *Goals and Milestones:* > > =B7 Charter statement > > =B7 Problem Statements > > =B7 Gap analysis > > =B7 Study of NHRP (RFC2332) & SCSP, and their applicability to > Ethernet networks > > =B7 Study and Analysis of MOOSE as a potential solution > > =B7 Study and Analysis of SEATTLE as a potential solution. > > > > > > Best Regards, Linda Dunbar > > > > _______________________________________________ > arp222 mailing list > arp222@ietf.org > https://www.ietf.org/mailman/listinfo/arp222 > > > > > _______________________________________________ > arp222 mailing list > arp222@ietf.org > https://www.ietf.org/mailman/listinfo/arp222 > > > --0016e68ea5064bb070048f19c0a5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Linda,

I'm glad I read your repl= y twice before answering. I hope I didn't have to read it thrice...

Please see inline

On Tue, Aug 31, 2010 at 2:12 AM, Linda Dunbar <ldunbar@huawei.com> wrote:
=

Hi Ron,

=A0<= /p>
Ron,

=A0<= /p>
Thank you very muc= h for the suggestions.

My comments are in= serted below:

=A0<= /p>
=A0<= /p>

From: ronc.ntear@gmail.= com [mailto:r= onc.ntear@gmail.com] On Behalf Of <= /span>Ron Cohen
Sent: Monday, August 30, 201= 0 11:43 AM
To: Linda Dunbar
Cc: Benson Schliesser; arp222@ietf.org

Subject: Re: [arp222] ARP222 Charter statement and milestones

=A0

Hi,

My comments - I'm going to echo some of Benson's and Anoop's point= s.

=A0

Separate the problem scope into:

=A0

1. Singe Data Center (DC)

2.=A0Distributed Data Center (DDC)

3.=A0Cloud Computing (CC)

=A0

[Linda] The first = 2 bullets are valid scenarios for DC. But I don=92t see the 3^rd one as an independent category for the ARP222 (or soon to be renamed ARMD). I see tha= t the Cloud computing could be some applications loaded to Data Center.

ronc: = I understand your approach. I agree that this is a desired architecture: se= parate infrastructure and application. A clear layer separation would in pr= inciple allow us to implement DDC over CC etc. However it is not clear to m= e how you achieve this desired goal in practice, and whether such clean sep= aration is not in conflict with practical considerations. Unless we fully u= nderstand how CC is overlaid on top of a DDC, it is hard to draw any useful= requirements from the CC application to ARMD.

I'm concerned that we don't have sufficient understanding of the cloud comp= uting networking environment, and at this point in time we should include an acti= on item or goal to study the requirements of cloud computing in this area. We should have CC providers participating in the discussion, clarifying curren= t practice and outstanding issues. I do not think that any CC service allows multiple clients on the same broadcast domain due to security concerns, and= all services include some form of built-in firewalls in the hypervisor level to enforce traffic separation. Until this is clarified all mention of duplicat= e IP addresses of multiple clients on the same VLAN, exhaustion of VLANs, etc sh= ould be removed from the charter.=A0

[Linda] Firs= t of all, including duplicated IP in one VLAN is not a main objective. We can definitely remove it from th= e Charter.

We are working tog= ether with our company=92s Cloud service BU on requirement. Amazon=92s Virtual Private Cloud (<= /font>http://aws.amazon.com/vpc/) allows client to use their own IP addresses. It is definitely true that they won= =92t allow communication across different VPCs. As of now, Amazon doesn=92t even allow any multicast among hosts within one VPC (http://developer.amazonwebservices.c= om/connect/thread.jspa?messageID=3D150951).

=A0

There is distincti= on between Client Controlled subnets (e.g. Amazon=92s VPC) and the actual subnets which connect all the physical servers. The Client Controlled subnets are virtual subnets. When they are assigned to servers, many of them will be assigned t= o one physical subnet in order to have the VMmobility. You can use VLAN to di= stinguish VPCs. But, you will quickly used up all the VLANs.

That is my origina= l intention.

=

ronc: What d= o you mean by 'assigned to one physical subnet in order to have VMmobil= ity'? Does each VM have two interfaces, one attached to the client cont= rolled subnet and one connected to the internal CC provider subnet for VMmo= bility?

=A0

=A0

The current problem scope does not mention DDC explicitly, and it should. If AR= P222 becomes a working group some standardized version of Cisco's OTV or sim= ilar will need to worked on.=A0

=A0<= /p>
[Linda] The = original name ARP222 (Address Resolution for Layer 2 to Anything to Layer 2) intends to emphasize that on= e large Layer 2 could consists of many pockets of Layer 2 which are interconnected by Layer 3 or MPLS. So it does want to include DDC. Once we change the name to ARMD, we need to bring it up in the Charter.

=A0

I think that behavior changes within the hypervisor level should be considered by ARP222. It is not clear to me whether this is in conflict with=A0=A0'Al= l solutions developed by ARP222 WG should not expect any behavior changes on hosts, applications, or Virtual Machines being deployed in the market.'= =A0

=A0<= /p>
[Linda] I do= n=92t think the behavior changes within the Hypervisor should be addressed by ARP222.<= /p>

ronc: What I me= ant to say is that once the problem scope is known, and assuming that a sol= ution requires implementing (part of) it in the hypervisor, there is no poi= nt in rejecting it. The main requirement in my opinion is that the solution= developed should not expect any behavior changes for the guest OS/applicat= ions running on the VMs.

=A0

I think that study of MOOSE or SEATLE should not be part of the goals and milestone= s. This is not to say that these solutions are not adequate or that they will = not be considered.

=A0<= /p>
[Linda] Agre= e. They are just some available solutions on the table which people agreed to write a draft on. W= e should lump it together to GAP analysis or existing solution analysis.

=A0

I'm not clear why it should be explicitly mentioned that it is not allowed to re-de= fine DHCP. I suggest to remove.

=A0<= /p>
[Linda] We w= ere told by the ADs to state clearly what is in the scope and what is not in the scope. That is why we h= ave those statements. We don=92t anticipate any changes to DHCP.

=A0<= /p>

=A0<= /p>

=A0

Best,

Ron

On Fri, Aug 27, 2010 at 1= 2:17 AM, Linda Dunbar <ldunbar@huawei.com> wrote:

Benson,

=A0

Thank you very much for the suggestion. Let=92s see if other people have similar comments or other suggestions.

The goal of circulating the tentative Charter statement is to make needed changes before submitting to the IESG i= n mid Sept.

=A0

Linda

=A0

From: Benson Schliesser [mailto:bensons@queuefull.net]
Sent: Thursday, August 26, 2= 010 3:12 PM

To: Linda Dunbar; arp222@ietf.org

Subject: Re: [arp222] ARP222 Charter statement and milestones

=A0

Linda -

=A0

I'd like to see a fe= w modifications to the charter you've outlined:

=A0

1) I've already expl= ained why I think the last design goal (overlapping IP addresses within a single VLAN) should be removed. =A0I won't reiter= ate that here.

=A0

2) The goal to "not= break DHCP" should be modified to include any broadcast and/or multicast protocols. =A0(Alternatively, broadcast and multicast support can be required by a new goal to be added.)=

=A0

3) The goal of supportin= g interconnect scenarios should explicitly include L3VPN. =A0In case it isn't clear, that implies a goal of suppor= t for overlapping IP addresses within the datacenter. (Albeit in different broadc= ast domains, my comments in #1 above notwithstanding.)

=A0

4) A new goal should inc= lude a performance analysis of all solutions considered. =A0This might explicitly acknowledge a role for negative cachin= g approaches, but that shouldn't be a requirement.

=A0

Cheers,

-Benson

=A0

=A0

=A0

On 12 Aug 10, at 6:14 PM= , Linda Dunbar wrote:

=A0=

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

=A0

I put together t= he initial ARP222 Charter Statement and Milestones. Please provide comments and suggestions. =A0

=A0

=A0

=A0

=A0

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

=A0

Desc= ription of Working Group:

As server virtu= alization 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 h= ost many end-stations, or Virtual Machines (20, 30, or hundreds of). Virtual Machines, with its flexible add/delete and mobility features, not only make= s it possible for achieving better performance and better utilization on servers= , they are also a very important building block for Cloud Computing service t= o offer virtual subnets and virtual hosts. The virtual subnets offered by Clo= ud Computing service could allow clients to define their own subnets with its = own IP addresses and policies.

This rapid grow= th of virtual hosts could tremendously impact to networks and servers. One huge issue is frequent add= ress resolution (IPv4) or neighbor discovery (IPv6) requests from hosts. All hos= ts 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 ra= te imposes tremendous computational burden on many hosts.

Another big iss= ue associated with huge number of virtual hosts in a data center is potentially duplicated IP addre= sses within one VLAN which will make traditional ARP or ND not working properly. Some load balance design requires multiple hosts serving the same applicati= on to have the same IP address but with different MAC addresses. Cloud Computi= ng service could allow users to have their own subnets with IP addresses and s= elf defined policies among those subnets. Some network designs need to put mult= iple 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 scenar= io, there could be duplicated IP addresses which are from different client subn= ets ending up in one VLAN.=A0

The goal of thi= s working group is to develop interoperable solutions to solve those problems.=A0 <= /p>
The = design should consider the following properties:

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>All solutions developed by ARP222 WG should not expect any behavior changes on hosts, applications, or Virtual Machines being deployed in the market.

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>All solutions developed should not break DHCP.

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed.

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Should consider variety of solutions, including directory based, proxy based, or cache base= d solutions.

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>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.

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>ARP222 assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet links.=A0

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure IP, Ethernet, or others.

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Should consider address resolution solutions for one VLAN with small number of duplicated I= P addresses.=A0

=A0<= /span>

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

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Re-define DHCP behavior

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Re-define security concern to IPv6 ND

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Direct links from hosts and virtual hosts are non Ethernet links

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>=A0

=A0

Goal= s and Milestones:

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Charter statement

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Problem Statements

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Gap analysis

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Study of NHRP (RFC2332) & SCSP, =A0and their applicability to Ethernet networks

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Study and Analysis of MOOSE as a potential solution

=B7=A0=A0=A0=A0=A0=A0=A0 <= /span>Study and Analysis of SEATTLE as a potential solution.

=A0

=A0

Best Regards, Linda Dunbar

=A0

___= ____________________________________________
arp222 mailing list
arp222@ietf.org = https://www.ietf.org/mailman/listinfo/arp222

=A0

_______________________________________________
arp222 mailing list
arp222@ietf.org = https://www.ietf.org/mailman/listinfo/arp222

=A0

--0016e68ea5064bb070048f19c0a5--