Re: [arp222] ARP222 Charter statement and milestones

Benson Schliesser <bensons@queuefull.net> Wed, 25 August 2010 00:39 UTC

Return-Path: <bensons@queuefull.net>
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 <arp222@core3.amsl.com>; 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 <arp222@core3.amsl.com>; 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 <arp222@ietf.org>; Tue, 24 Aug 2010 17:39:02 -0700 (PDT)
Received: by iwn3 with SMTP id 3so58961iwn.31 for <arp222@ietf.org>; 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 <bensons@queuefull.net>
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 <ldunbar@huawei.com>
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." <arp222.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/arp222>, <mailto:arp222-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/arp222>
List-Post: <mailto:arp222@ietf.org>
List-Help: <mailto:arp222-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/arp222>, <mailto:arp222-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2010 00:39:07 -0000

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