From ldunbar@huawei.com Thu Sep 2 10:05:26 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8143A6813; Thu, 2 Sep 2010 10:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.257 X-Spam-Level: X-Spam-Status: No, score=-102.257 tagged_above=-999 required=5 tests=[AWL=0.341, 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 A8AzxZ0-YDVA; Thu, 2 Sep 2010 10:05:22 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 2476E3A680C; Thu, 2 Sep 2010 10:05:22 -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 <0L84007SVQ5QTB@usaga02-in.huawei.com>; Thu, 02 Sep 2010 10:05:51 -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 <0L8400F8PQ5QAN@usaga02-in.huawei.com>; Thu, 02 Sep 2010 10:05:50 -0700 (PDT) Date: Thu, 02 Sep 2010 12:05:50 -0500 From: Linda Dunbar To: arp222@ietf.org, armd@ietf.org Message-id: <008e01cb4ac1$18755f80$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_TMWAfJzkxx1KPuv+/eDIGg)" Thread-index: ActKwRhFywAO0RUXRYqUPo4uk1zLbA== Subject: [armd] arp222 email has been changed to armd@ietf.org X-BeenThere: armd@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, 02 Sep 2010 17:05:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TMWAfJzkxx1KPuv+/eDIGg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT There are more people in favor of the name ARMD as the replacement for ARP222. Some people suggest ARMD can also mean "Address Resolution Mechanisms for large broadcast Domains" Therefore, I have sent the name change request to Internet ADs (Ralph & Jari). They have approved the name change. Now the armd@ietf.org is created. All the people who were on ARP222@ietf.org should be automatically switched over to armd@ietf.org. If you have trouble using the new email list, please let me know. Thanks, Linda Dunbar 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 --Boundary_(ID_TMWAfJzkxx1KPuv+/eDIGg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

There are more people in favor of the name ARMD as = the replacement for ARP222.  Some people suggest ARMD can also mean = “Address Resolution Mechanisms for large broadcast = Domains”

 

Therefore, I have sent the name change request to = Internet ADs (Ralph & Jari). They have approved the name change. Now the armd@ietf.org is created. All the = people who were on ARP222@ietf.org should be automatically switched over to armd@ietf.org. If you have trouble using the new email list, please let me know. =

 

Thanks, Linda Dunbar

 

 

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

 

 

--Boundary_(ID_TMWAfJzkxx1KPuv+/eDIGg)-- From ldunbar@huawei.com Fri Sep 3 13:40:32 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042543A6934 for ; Fri, 3 Sep 2010 13:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 aHLuuUgs8sv6 for ; Fri, 3 Sep 2010 13:40:30 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 01C543A699A for ; Fri, 3 Sep 2010 13:40:30 -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 <0L8600IFGUSAP3@usaga02-in.huawei.com> for armd@ietf.org; Fri, 03 Sep 2010 13:40: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 <0L8600LGPUSA9B@usaga02-in.huawei.com> for armd@ietf.org; Fri, 03 Sep 2010 13:40:58 -0700 (PDT) Date: Fri, 03 Sep 2010 15:40:58 -0500 From: Linda Dunbar To: armd@ietf.org Message-id: <00db01cb4ba8$50a5e770$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_KcISJQ0HE4cLeZfG4lvsTg)" Thread-index: ActLqFB/SoTXma7ESueDkbCw8CpEWA== Subject: [armd] test X-BeenThere: armd@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, 03 Sep 2010 20:40:32 -0000 This is a multi-part message in MIME format. --Boundary_(ID_KcISJQ0HE4cLeZfG4lvsTg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Linda --Boundary_(ID_KcISJQ0HE4cLeZfG4lvsTg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Linda

 

--Boundary_(ID_KcISJQ0HE4cLeZfG4lvsTg)-- From lieven.levrau@alcatel-lucent.com Fri Sep 3 13:42:56 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFED3A6934 for ; Fri, 3 Sep 2010 13:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] 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 Wts2vM0XyXCp for ; Fri, 3 Sep 2010 13:42:55 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 9CEDB3A699A for ; Fri, 3 Sep 2010 13:42:51 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o83KhE1M013921 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 3 Sep 2010 22:43:14 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 3 Sep 2010 22:43:14 +0200 From: "LEVRAU, LIEVEN (LIEVEN)" To: "'ldunbar@huawei.com'" , "'armd@ietf.org'" Date: Fri, 3 Sep 2010 22:43:13 +0200 Thread-Topic: [armd] test Thread-Index: ActLqFB/SoTXma7ESueDkbCw8CpEWAAAFBy9 Message-ID: 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_E6E66922099CFB4391FAA7A7D3238F9F163FE1A2FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [armd] test X-BeenThere: armd@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, 03 Sep 2010 20:42:56 -0000 --_000_E6E66922099CFB4391FAA7A7D3238F9F163FE1A2FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V29ya3MgZmluZSBmb3IgbWUNClRlc3RfYWNrDQoNCi4vDQpMaWV2ZW4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IGFybWQtYm91bmNlc0BpZXRmLm9yZyA8YXJtZC1i b3VuY2VzQGlldGYub3JnPg0KVG86IGFybWRAaWV0Zi5vcmcgPGFybWRAaWV0Zi5vcmc+DQpTZW50 OiBGcmkgU2VwIDAzIDIyOjQwOjU4IDIwMTANClN1YmplY3Q6IFthcm1kXSB0ZXN0DQoNCkxpbmRh DQoNCg== --_000_E6E66922099CFB4391FAA7A7D3238F9F163FE1A2FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxucz0iaHR0 cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPE1FVEEgSFRUUC1FUVVJ Vj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0K PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVk IG1lZGl1bSkiPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2 IDAgMyAxIDEgMSAxIDE7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkFyaWFsOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0K CWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KQHBhZ2Ug U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBp biAxLjI1aW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxl Pg0KDQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48 ZGl2Pjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+DQpXb3JrcyBmaW5lIGZvciBt ZTxicj5UZXN0X2FjayA8YnI+DTxicj4uLw08YnI+TGlldmVuPC9mb250PjwvZGl2Pg0KPGJyPjxk aXY+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KPGZv bnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IGFybWQtYm91bmNlc0BpZXRmLm9y ZyAmbHQ7YXJtZC1ib3VuY2VzQGlldGYub3JnJmd0Ow08YnI+PGI+VG88L2I+OiBhcm1kQGlldGYu b3JnICZsdDthcm1kQGlldGYub3JnJmd0Ow08YnI+PGI+U2VudDwvYj46IEZyaSBTZXAgMDMgMjI6 NDA6NTggMjAxMDxicj48Yj5TdWJqZWN0PC9iPjogW2FybWRdIHRlc3QNPGJyPjwvZm9udD48YnI+ PC9kaXY+DQoNCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Ow0KZm9u dC1mYW1pbHk6QXJpYWwnPkxpbmRhIDwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9QXJp YWw+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBw dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvYm9k eT4NCg0KPC9odG1sPg0K --_000_E6E66922099CFB4391FAA7A7D3238F9F163FE1A2FRMRSSXCHMBSC3d_-- From ldunbar@huawei.com Fri Sep 3 15:45:27 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E1A3A69B2 for ; Fri, 3 Sep 2010 15:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.773 X-Spam-Level: X-Spam-Status: No, score=-100.773 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_40=-0.185, 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 ltiYnF7Q6c+L for ; Fri, 3 Sep 2010 15:45:17 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 264733A67B2 for ; Fri, 3 Sep 2010 15:45:17 -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 <0L870079Y0K9C6@usaga04-in.huawei.com> for armd@ietf.org; Fri, 03 Sep 2010 17:45:46 -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 <0L87005U90K8A1@usaga04-in.huawei.com> for armd@ietf.org; Fri, 03 Sep 2010 17:45:45 -0500 (CDT) Date: Fri, 03 Sep 2010 17:45:45 -0500 From: Linda Dunbar To: armd@ietf.org Message-id: <010a01cb4bb9$bf679260$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_MTj9lHu6vN95GT3HtU4djw)" Thread-index: ActLub73KtNSSzNxRRGJru7SUWYbUA== Subject: [armd] Revised charter statement for ARMD (ARP222) X-BeenThere: armd@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, 03 Sep 2010 22:45:27 -0000 This is a multi-part message in MIME format. --Boundary_(ID_MTj9lHu6vN95GT3HtU4djw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Based on comments I received from the email list, I made some changes and removed the duplicated IP address requirement. Here are the revised Charter Statements. Please send me your comments. If I don't get any serious comments, I will send this revised charter statement to Internet Area Director Ralph and Jari for IESG to approve a BOF at the 79th IETF. ARMD: Address Resolution for Massive amount of hosts in one broadcast Domain Description of Working Group: As server virtualization is introduced to data centers, the number of hosts in a data center can grow dramatically. Each physical server, which used to host one end-station, now can host hundreds of end-stations or virtual machines (VMs). Virtual machines (VMs) can be easily added and/or deleted and moved between servers. The VM's flexible addition/deletion and moving around make it possible to achieve better performance and utilization on servers. These capabilities also are important building blocks for Cloud Computing service to offer client controlled virtual subnets and virtual hosts. The client controlled virtual subnets offered by Cloud Computing service could allow clients to define their own subnets with its own IP addresses and policies. This rapid growth of virtual hosts could tremendously impact networks and servers. One major issue is frequent ARP (IPv4) or neighbor discovery (IPv6) requests from hosts. All hosts send out those requests frequently due to caches being aged out in minutes. With tens of thousands of hosts (each with a distinct MAC address) in one Data Center, the amount of ARP (or ND) packets per second is potentially more than 1,000 to 10,000/second. This rate imposes tremendous computational burden on many hosts. Cloud Computing service could allow users to have their own subnets with IP addresses and self defined policies among those subnets, like Amazon's Virtual Private Cloud service (http://aws.amazon.com/vpc). Even though the Client Controlled Virtual Subnets have the same property as real subnets, some network design may need to allocate multiple Client Controlled Virtual Subnets into one physical network subnet. It is important to have isolation among different Client Controlled Virtual Subnet(s). An ARP request from a (virtual) host from one Client Controlled Virtual Subnet should not get any reply if the target IP doesn't exist within this Client Controlled Virtual Subnet. Another characteristic of next-generation Data Center is the possibility of one subnet spanning across multiple sites. For example, server administrator can combine servers in multiple sites into one huge resource pool for better resource management and easy of allocation. Virtual hosts can be loaded to any servers in this pool of servers. If mobility is required, like VMware's vMotion, all hosts need to be on the same subnet. The Cloud Computing's virtual private cloud could also require virtual hosts in the cloud to be in the same subnets as hosts at client's own location. Under those circumstances, one Layer 2 network (or subnet) could span across multiple sites. The multiple sites could be connected by any types of network, like L2VPN, L3VPN, Ethernet network, or simple IP networks. Efficient address resolution across multiple sites should be considered by this working group. The goal of this working group is to develop interoperable solutions to solve those problems with the Data Center environment and the expansion of the Data Center Environment to cloud computing. These environments are multi-vendor, multi-site, and multi-domain (or multi-company). The design should consider the following properties: * All solutions developed by ARMD WG should not expect any behavior changes on hosts, applications, or Virtual Machines being deployed in the market. * All solutions developed should not break DHCP, or any other broadcast/multicast mechanism used by applications. * Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed. * Should consider variety of solutions, including directory based, proxy based, or cache based solutions. * Include analysis of security concerns of IPv4 ARP requests from malicious users. Evaluating potential security solutions and conclude if the security threat can justify solutions. * ARMD assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider isolation of address resolution solutions across different client controlled virtual subnets, i.e. hosts from one client should be limited to getting MAC addresses from virtual hosts within its own controlled subnet(s). If the target IP doesn't exist within the client controlled virtual subnet(s), nothing should be returned even if the same IP exists in a different client controlled virtual subnet(s). * Should consider a performance analysis of proposed solutions. Here are the items which should not be in the scope of the working group: * Re-define DHCP behavior * Re-define security concern to IPv6 ND * Solution developed should not expect any behavior changes for the guest OS/applications running on the VMs * Direct links from hosts and virtual hosts are non Ethernet links Goals and Milestones: * Problem statement * Gap Analysis Statement within Data Center * Gaps within ARP * Gaps within IPv6 ND or autoconfiguration * Survey of Existing Solutions * Survey of NHRP (RFC2332) & SCSP, and their applicability to Ethernet networks; * Survey of TRILL work as a potential solution; * Survey of other potential solutions, like MOOSE or SEATTLE; and * Other proposals * Security Analysis of Existing Solutions * Study existing solutions, like Dynamic ARP Inspection, Egress ARP Inspection, etc, and evaluate if any of them or others should be included in the solutions specified by this working group. * Architectural Design for Next-Generation Data Center * Protocol Documents Time line for BOF presentations Initial Problem Statement August GAP analysis October Survey of Existing Solutions October Security Analysis of Existing Solutions October Architectural Design for NG October Final Problem statement for BOF October Protocol Documents October Linda Dunbar --Boundary_(ID_MTj9lHu6vN95GT3HtU4djw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

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

 

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

 

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

 

 

Description of Working Group:

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

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

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

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

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

The design should consider the following properties:

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

 

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

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

 

Goals and Milestones:

  • Problem statement
  • Gap Analysis Statement within Data Center
    • Gaps within ARP
    • Gaps within IPv6 ND or autoconfiguration
  • Survey of Existing Solutions
    • Survey of NHRP (RFC2332) & SCSP,  and their applicability to Ethernet networks;
    • Survey of TRILL work as a potential solution;
    • Survey of  other potential solutions, like MOOSE or SEATTLE; and
    • Other proposals
  • Security Analysis of Existing Solutions
    • Study existing solutions, like Dynamic ARP Inspection, Egress ARP Inspection, etc, and evaluate if any of them or others should be included in the solutions specified by this working group.  
  • Architectural Design for Next-Generation Data Center
  • Protocol Documents

 

 

Time line for BOF presentations

 

Initial Problem Statement                August   

GAP analysis                                              October

Survey of Existing Solutions                        October

Security Analysis of Existing Solutions         October

Architectural Design for NG                        October

Final Problem statement for BOF                October

Protocol Documents                                   October

 

 

Linda Dunbar

 

--Boundary_(ID_MTj9lHu6vN95GT3HtU4djw)-- From ldunbar@huawei.com Sun Sep 12 06:53:21 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CD83A6896 for ; Sun, 12 Sep 2010 06:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.68 X-Spam-Level: X-Spam-Status: No, score=-99.68 tagged_above=-999 required=5 tests=[AWL=-0.282, 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 KJFidWIw2vUh for ; Sun, 12 Sep 2010 06:53:10 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 305FE3A683A for ; Sun, 12 Sep 2010 06:53:07 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8M000HCZX98I@usaga03-in.huawei.com> for armd@ietf.org; Sun, 12 Sep 2010 08:53:33 -0500 (CDT) Received: from L735042 (cpe-66-25-9-199.tx.res.rr.com [66.25.9.199]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8M00EL9ZX7Z5@usaga03-in.huawei.com> for armd@ietf.org; Sun, 12 Sep 2010 08:53:32 -0500 (CDT) Date: Sun, 12 Sep 2010 08:53:31 -0500 From: Linda Dunbar To: armd@ietf.org Message-id: <001801cb5281$e2dffce0$c7091942@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_UPXGC+zxc3BjcbAwDQJy4A)" Thread-index: ActRXBftmhrwaO1WSSe3MDOhfXUyPQ== Subject: [armd] another revision for ARMD charter statement X-BeenThere: armd@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: Sun, 12 Sep 2010 13:53:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_UPXGC+zxc3BjcbAwDQJy4A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT After separate discussions with Force10's Sridhar and Brocade's Anoop, we have decided to make some changes to the ARMD charter statements. Here is the revised one. Please provide your comments. We plan to submit this charter statement to Internet AD Ralph and Jari next Tuesday. ARMD: Address Resolution for Massive amount of hosts in one broadcast Domain Description of Working Group: As server virtualization is introduced to data centers, the number of hosts in a data center can grow dramatically. Each physical server, which used to host one end-station, now can host hundreds of end-stations or virtual machines (VMs). Virtual machines (VMs) can be easily added and/or deleted and moved between servers. The VM's flexible addition/deletion and moving around provide foundation for virtual hosts and virtual desktops offered by Cloud Computing services and make it possible to combine pool of servers into one single entity for ease of management and better utilization. This rapid growth of virtual hosts could tremendously impact networks and servers. One major issue is frequent ARP (IPv4) or neighbor discovery (IPv6) requests from hosts. All hosts send out those requests frequently due to host ARP caches being aged out in minutes. With tens of thousands of hosts (each with a distinct MAC address) in one Data Center, the number of ARP (or ND) packets per second from all hosts could potentially be as high as 1,000 to 10,000/second. This rate imposes tremendous computational burden on many hosts. Traditional subnet (VLAN) partitioning no longer works well when servers are virtualized. First of all, servers need to be on the same subnet for VM mobility. Secondly, when each server only has one host, there is only one VLAN enabled for the port towards the server. The switch can block all broadcast messages from other subnets (VLANs). When one physical server is supporting >100 Virtual Machines, i.e. >100 hosts, most likely the virtual hosts on one server are on different subnets (VLANs). If there are 50 subnets (VLANs) enabled on the switch port to the server, the server has to handle all the ARP broadcast messages on all 50 subnets (VLANs). The amount of ARP to be processed by each server is still too much. One characteristic of a next-generation Data Center is the possibility of one subnet spanning multiple sites. For example, a server administrator can combine servers in multiple sites into one huge resource pool for better resource management and ease of allocation. Each of the servers in this pool might be configured with one or more VMs. If mobility is required, like VMware's vMotion, all the physical servers (and associated VMs) need to be on the same IP subnet. Under those circumstances, one Layer 2 network (or subnet) could span across multiple sites. The multiple sites could be connected by any types of network, like L2VPN, L3VPN, Ethernet network, or simple IP networks. Efficient address resolution across multiple sites should be considered by this working group. The goal of this working group is to develop interoperable solutions to solve the above problems within the Data Center and multi Data Center environments. This could involve multi-domain (multi-company), multi-site and multi-vendor environments. The design should consider the following properties: * All solutions developed by ARMD WG should not require any behavior changes on hosts, applications, or Virtual Machines being deployed in the market. * All solutions developed should not break DHCP, or any other broadcast/multicast mechanism used by applications. * Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed. * Should consider variety of solutions, including directory based, proxy based, or cache based solutions. * Include analysis of security concerns of IPv4 ARP requests from malicious users. Evaluating potential security solutions and conclude if the security threat can justify solutions. * ARMD assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider isolation of address resolution solutions across different client controlled virtual subnets, i.e. hosts from one client should be limited to getting MAC addresses from virtual hosts within its own controlled subnet(s). Should consider a performance analysis of proposed solutions. Here are the items which should not be in the scope of the working group: * Re-define DHCP behavior * Re-define IPv6 ND security model * Solution developed should not expect any behavior changes for the guest OS/applications running on the VMs * Direct links from hosts and virtual hosts being non-Ethernet links. Goals and Milestones: * Problem statement * Gap Analysis Statement within Data Center * Gaps within ARP * Gaps within IPv6 ND or autoconfiguration * Survey of Existing Solutions * Survey of NHRP (RFC2332) & SCSP, and their applicability to Ethernet networks; * Survey of TRILL work as a potential solution; * Survey of other potential solutions, like MOOSE or SEATTLE; and * Other proposals * Security Analysis of Existing Solutions * Study existing solutions, like Dynamic ARP Inspection, Egress ARP Inspection, etc, and evaluate if any of them or others should be included in the solutions specified by this working group. * Architectural Design for Next-Generation Data Center * Protocol Documents Time line for BOF presentations Initial Problem Statement August GAP analysis October Survey of Existing Solutions October Security Analysis of Existing Solutions October Architectural Design for NG October Final Problem statement for BOF October Protocol Documents October Regards, Linda Dunbar --Boundary_(ID_UPXGC+zxc3BjcbAwDQJy4A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

After separate discussions with Force10’s Sridhar and Brocade’s Anoop, we have decided to make some changes to the ARMD charter statements. Here is the revised one. Please provide your comments. We plan to submit this charter statement to Internet AD Ralph and Jari next Tuesday.  

 

 

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

 

 

Description of Working Group:

As server virtualization is introduced to data centers, the number of hosts in a data center can grow dramatically.  Each physical server, which used to host one end-station, now can host hundreds of end-stations or virtual machines (VMs). Virtual machines (VMs) can be easily added and/or deleted and moved between servers.  The VM’s flexible addition/deletion and moving around provide foundation for virtual hosts and virtual desktops offered by Cloud Computing services and make it possible to combine pool of servers into one single entity for ease of management and better utilization.

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

Traditional subnet (VLAN) partitioning no longer works well when servers are virtualized. First of all, servers need to be on the same subnet for VM mobility. Secondly, when each server only has one host, there is only one VLAN enabled for the port towards the server. The switch can block all broadcast messages from other subnets (VLANs). When one physical server is supporting >100 Virtual Machines, i.e. >100 hosts, most likely the virtual hosts on one server are on different subnets (VLANs). If there are 50 subnets (VLANs) enabled on the switch port to the server, the server has to handle all the ARP broadcast messages on all 50 subnets (VLANs). The amount of ARP to be processed by each server is still too much.

One characteristic of a next-generation Data Center is the possibility of one subnet spanning  multiple sites. For example, a server administrator can combine servers in multiple sites into one huge resource pool for better resource management and ease of allocation.  Each of the servers in this pool might be configured with one or more VMs. If mobility is required, like VMware’s vMotion, all the physical servers  (and associated VMs) need to be on the same IP subnet. Under those circumstances, one Layer 2 network (or subnet) could span across multiple sites. The multiple sites could be connected by any types of network, like L2VPN, L3VPN, Ethernet network, or simple IP networks. Efficient address resolution across multiple sites should be considered by this working group.

The goal of this working group is to develop interoperable solutions to solve the above problems within the Data Center and multi Data Center environments.  This could involve multi-domain (multi-company), multi-site and multi-vendor environments.

The design should consider the following properties:

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

 

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

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

 

Goals and Milestones:

  • Problem statement
  • Gap Analysis Statement within Data Center
    • Gaps within ARP
    • Gaps within IPv6 ND or autoconfiguration
  • Survey of Existing Solutions
    • Survey of NHRP (RFC2332) & SCSP,  and their applicability to Ethernet networks;
    • Survey of TRILL work as a potential solution;
    • Survey of  other potential solutions, like MOOSE or SEATTLE; and
    • Other proposals
  • Security Analysis of Existing Solutions
    • Study existing solutions, like Dynamic ARP Inspection, Egress ARP Inspection, etc, and evaluate if any of them or others should be included in the solutions specified by this working group.  
  • Architectural Design for Next-Generation Data Center
  • Protocol Documents

 

 

Time line for BOF presentations

 

Initial Problem Statement                            August   

GAP analysis                                              October

Survey of Existing Solutions                        October

Security Analysis of Existing Solutions         October

Architectural Design for NG                        October

Final Problem statement for BOF                October

      Protocol Documents                                   October

 

 

 

Regards, Linda Dunbar

--Boundary_(ID_UPXGC+zxc3BjcbAwDQJy4A)-- From anoop@brocade.com Sun Sep 12 11:27:01 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1865B3A68B6 for ; Sun, 12 Sep 2010 11:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 A63ZK2Uju4s5 for ; Sun, 12 Sep 2010 11:26:50 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by core3.amsl.com (Postfix) with ESMTP id E4B463A68F1 for ; Sun, 12 Sep 2010 11:26:50 -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 o8CIQ48E004882; Sun, 12 Sep 2010 11:27:11 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id r8thfr5uw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 12 Sep 2010 11:27:10 -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; Sun, 12 Sep 2010 11:31:02 -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; Sun, 12 Sep 2010 11:27:09 -0700 From: Anoop Ghanwani To: Linda Dunbar , "armd@ietf.org" Date: Sun, 12 Sep 2010 11:27:08 -0700 Thread-Topic: another revision for ARMD charter statement Thread-Index: ActRXBftmhrwaO1WSSe3MDOhfXUyPQBS2q5w Message-ID: <5EB1A55E180C914BBC1A49310B762938669031AC45@HQ1-EXCH02.corp.brocade.com> References: <001801cb5281$e2dffce0$c7091942@china.huawei.com> In-Reply-To: <001801cb5281$e2dffce0$c7091942@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_5EB1A55E180C914BBC1A49310B762938669031AC45HQ1EXCH02corp_" 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-09-11_07:2010-09-10, 2010-09-11, 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-1009120060 Subject: Re: [armd] another revision for ARMD charter statement X-BeenThere: armd@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: Sun, 12 Sep 2010 18:27:01 -0000 --_000_5EB1A55E180C914BBC1A49310B762938669031AC45HQ1EXCH02corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >>>> * Should consider isolation of address resolution solutions across diffe= rent client controlled virtual subnets, i.e. hosts from one client should b= e limited to getting MAC addresses from virtual hosts within its own contro= lled subnet(s). Should consider a performance analysis of proposed solution= s. >>>> I still have a problem with the first sentence. There is not a concrete, well-accepted definition of what a "client controlled virtual subnet" is, and how forwarding takes place when something like that is defined. Unrelated to the above, I believe the second sentence is supposed to be a bullet on its own? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Sunday, September 12, 2010 6:54 AM To: armd@ietf.org Cc: Anoop Ghanwani; 'T Sridhar' Subject: another revision for ARMD charter statement After separate discussions with Force10's Sridhar and Brocade's Anoop, we h= ave decided to make some changes to the ARMD charter statements. Here is th= e revised one. Please provide your comments. We plan to submit this charter= statement to Internet AD Ralph and Jari next Tuesday. ARMD: Address Resolution for Massive amount of hosts in one broadcast Domai= n Description of Working Group: As server virtualization is introduced to data centers, the number of hosts= in a data center can grow dramatically. Each physical server, which used = to host one end-station, now can host hundreds of end-stations or virtual m= achines (VMs). Virtual machines (VMs) can be easily added and/or deleted an= d moved between servers. The VM's flexible addition/deletion and moving ar= ound provide foundation for virtual hosts and virtual desktops offered by C= loud Computing services and make it possible to combine pool of servers int= o one single entity for ease of management and better utilization. This rapid growth of virtual hosts could tremendously impact networks and s= ervers. One major issue is frequent ARP (IPv4) or neighbor discovery (IPv6)= requests from hosts. All hosts send out those requests frequently due to h= ost ARP caches being aged out in minutes. With tens of thousands of hosts (= each with a distinct MAC address) in one Data Center, the number of ARP (or= ND) packets per second from all hosts could potentially be as high as 1,00= 0 to 10,000/second. This rate imposes tremendous computational burden on ma= ny hosts. Traditional subnet (VLAN) partitioning no longer works well when servers ar= e virtualized. First of all, servers need to be on the same subnet for VM m= obility. Secondly, when each server only has one host, there is only one VL= AN enabled for the port towards the server. The switch can block all broadc= ast messages from other subnets (VLANs). When one physical server is suppor= ting >100 Virtual Machines, i.e. >100 hosts, most likely the virtual hosts = on one server are on different subnets (VLANs). If there are 50 subnets (VL= ANs) enabled on the switch port to the server, the server has to handle all= the ARP broadcast messages on all 50 subnets (VLANs). The amount of ARP to= be processed by each server is still too much. One characteristic of a next-generation Data Center is the possibility of o= ne subnet spanning multiple sites. For example, a server administrator can= combine servers in multiple sites into one huge resource pool for better r= esource management and ease of allocation. Each of the servers in this poo= l might be configured with one or more VMs. If mobility is required, like V= Mware's vMotion, all the physical servers (and associated VMs) need to be = on the same IP subnet. Under those circumstances, one Layer 2 network (or s= ubnet) could span across multiple sites. The multiple sites could be connec= ted by any types of network, like L2VPN, L3VPN, Ethernet network, or simple= IP networks. Efficient address resolution across multiple sites should be = considered by this working group. The goal of this working group is to develop interoperable solutions to sol= ve the above problems within the Data Center and multi Data Center environm= ents. This could involve multi-domain (multi-company), multi-site and mult= i-vendor environments. The design should consider the following properties: * All solutions developed by ARMD WG should not require any behavior cha= nges on hosts, applications, or Virtual Machines being deployed in the mark= et. * All solutions developed should not break DHCP, or any other broadcast/= multicast mechanism used by applications. * Evaluating the impact to IPv6 ND, and develop solutions accordingly if= needed. * Should consider variety of solutions, including directory based, proxy= based, or cache based solutions. * Include analysis of security concerns of IPv4 ARP requests from malici= ous users. Evaluating potential security solutions and conclude if the secu= rity threat can justify solutions. * ARMD assumes the direct links to individual hosts and virtual machines= are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconnected= by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider isolation of address resolution solutions across diffe= rent client controlled virtual subnets, i.e. hosts from one client should b= e limited to getting MAC addresses from virtual hosts within its own contro= lled subnet(s). Should consider a performance analysis of proposed solution= s. Here are the items which should not be in the scope of the working group: * Re-define DHCP behavior * Re-define IPv6 ND security model * Solution developed should not expect any behavior changes for the gues= t OS/applications running on the VMs * Direct links from hosts and virtual hosts being non-Ethernet links. Goals and Milestones: * Problem statement * Gap Analysis Statement within Data Center * Gaps within ARP * Gaps within IPv6 ND or autoconfiguration * Survey of Existing Solutions * Survey of NHRP (RFC2332) & SCSP, and their applicability to Ethern= et networks; * Survey of TRILL work as a potential solution; * Survey of other potential solutions, like MOOSE or SEATTLE; and * Other proposals * Security Analysis of Existing Solutions * Study existing solutions, like Dynamic ARP Inspection, Egress ARP I= nspection, etc, and evaluate if any of them or others should be included in= the solutions specified by this working group. * Architectural Design for Next-Generation Data Center * Protocol Documents Time line for BOF presentations Initial Problem Statement August GAP analysis October Survey of Existing Solutions October Security Analysis of Existing Solutions October Architectural Design for NG October Final Problem statement for BOF October Protocol Documents October Regards, Linda Dunbar --_000_5EB1A55E180C914BBC1A49310B762938669031AC45HQ1EXCH02corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>>>> 

  • Should consider is= olation of address resolution solutions across different client controlled vir= tual subnets, i.e. hosts from one client should be limited to getting MAC addresses from virtual hosts within its own controlled subnet(s). Shou= ld consider a performance analysis of proposed solutions.  

>>>> 

 

I still have a problem with the first sentence.  There = is not a concrete,

well-accepted definition of what a “client controlled = virtual subnet” is,

and how forwarding takes place when something like that is defined.

 

Unrelated to the above, I believe the second sentence is sup= posed to

be a bullet on its own?

 

Anoop

 

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Sunday, September 12, 2010 6:54 AM
To: armd@ietf.org
Cc: Anoop Ghanwani; 'T Sridhar'
Subject: another revision for ARMD charter statement

 

After separate discussions with Force10’s Sridhar and Brocade’s Anoop= , we have decided to make some changes to the ARMD charter statements. Here is the revised one. Please provide your comments. We plan to submit this charter statement to Internet AD Ralph and Jari next Tuesday.  

=  

=  

ARMD: Ad= dress Resolution for Massive amount of hosts in one broadcast Domain

 

 

Description of Working Group:

As server virtua= lization is introduced to data centers, the number of hosts in a data center can gro= w dramatically.  Each physical server, which used to host one end-statio= n, now can host hundreds of end-stations or virtual machines (VMs). Virtual machines (VMs) can be easily added and/or deleted and moved between servers.  The VM’s flexible addition/deletion and moving around = provide foundation for virtual hosts and virtual desktops offered by Cloud Computin= g services and make it possible to combine pool of servers into one single en= tity for ease of management and better utilization.

This rapid growt= h of virtual hosts could tremendously impact networks and servers. One major iss= ue is frequent ARP (IPv4) or neighbor discovery (IPv6) requests from hosts. Al= l hosts send out those requests frequently due to host ARP caches being aged = out in minutes. With tens of thousands of hosts (each with a distinct MAC addre= ss) in one Data Center, the number of ARP (or ND) packets per second from all h= osts could potentially be as high as 1,000 to 10,000/second. This rate imposes tremendous computational burden on many hosts.

Traditional subn= et (VLAN) partitioning no longer works well when servers are virtualized. Firs= t of all, servers need to be on the same subnet for VM mobility. Secondly, when = each server only has one host, there is only one VLAN enabled for the port towar= ds the server. The switch can block all broadcast messages from other subnets (VLANs). When one physical server is supporting >100 Virtual Machines, i= .e. >100 hosts, most likely the virtual hosts on one server are on different subnets (VLANs). If there are 50 subnets (VLANs) enabled on the switch port= to the server, the server has to handle all the ARP broadcast messages on all = 50 subnets (VLANs). The amount of ARP to be processed by each server is still = too much.

One characterist= ic of a next-generation Data Center is the possibility of one subnet spanning  multiple sites. For example, a server administrator can combine serve= rs in multiple sites into one huge resource pool for better resource managemen= t and ease of allocation.  Each of the servers in this pool might be con= figured with one or more VMs. If mobility is required, like VMware’s vMotion,= all the physical servers  (and associated VMs) need to be on the same IP subnet. Under those circumstances, one Layer 2 network (or subnet) cou= ld span across multiple sites. The multiple sites could be connected by any ty= pes of network, like L2VPN, L3VPN, Ethernet network, or simple IP networks. Efficient address resolution across multiple sites should be considered by = this working group.

The goal of this= working group is to develop interoperable solutions to solve the above problems wit= hin the Data Center and multi Data Center environments.  This could involv= e multi-domain (multi-company), multi-site and multi-vendor environments.

The design should consider the following properties= :

  • All solutions deve= loped by ARMD WG should not require any behavior changes on hosts, applications= , or Virtual Machines being deployed in the market.
  • All solutions deve= loped should not break DHCP, or any other broadcast/multicast mechanism used= by applications.
  • 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.
  • ARMD assumes the d= irect 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 is= olation of address resolution solutions across different client controlled vir= tual subnets, i.e. hosts from one client should be limited to getting MAC addresses from virtual hosts within its own controlled subnet(s). Shou= ld consider a performance analysis of proposed solutions.  

 

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

  • Re-define DHCP beh= avior
  • Re-define IPv6 ND = security model
  • Solution developed= should not expect any behavior changes for the guest OS/applications running = on the VMs
  • Direct links from = hosts and virtual hosts being non-Ethernet links.

 

Goals and Milestones:

  • Problem statement =
  • Gap Analysis State= ment within Data Center
    • Gaps within ARP
    • Gaps within IPv6 = ND or autoconfiguration
  • Survey of Existing Solutions
    • Survey of NHRP (R= FC2332) & SCSP,  and their applicability to Ethernet networks;<= /o:p>
    • Survey of TRILL w= ork as a potential solution;
    • Survey of  o= ther potential solutions, like MOOSE or SEATTLE; and
    • Other proposals
  • Security Analysis = of Existing Solutions
    • Study existing so= lutions, like Dynamic ARP Inspection, Egress ARP Inspection, etc, and evaluate= if any of them or others should be included in the solutions specified b= y this working group.  
  • Architectural Desi= gn for Next-Generation Data Center
  • Protocol Documents=

 

 

Time line for BOF prese= ntations

 

Initial Problem Statement             &nb= sp;              Aug= ust   

GAP analysis             &nb= sp;            =                     October =

Survey of Existing Solutio= ns             &nb= sp;          October

Security Analysis of Exist= ing Solutions         October

Architectural Design for NG            &= nbsp;           October

Final Problem statement fo= r BOF            =     October

      Protocol Documents             &nb= sp;            =          October<= /p>

=  

 

 

Regards, Linda Dunbar

--_000_5EB1A55E180C914BBC1A49310B762938669031AC45HQ1EXCH02corp_-- From ldunbar@huawei.com Mon Sep 13 08:03:16 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27553A69F8 for ; Mon, 13 Sep 2010 08:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.994 X-Spam-Level: X-Spam-Status: No, score=-100.994 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_20=-0.74, 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 7v4VF5-1WfpZ for ; Mon, 13 Sep 2010 08:03:06 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 6DC1A3A69EA for ; Mon, 13 Sep 2010 08:03:06 -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 <0L8O00HQ3XTVX4@usaga02-in.huawei.com> for armd@ietf.org; Mon, 13 Sep 2010 08:03:32 -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 <0L8O0008UXTUUR@usaga02-in.huawei.com> for armd@ietf.org; Mon, 13 Sep 2010 08:03:30 -0700 (PDT) Date: Mon, 13 Sep 2010 10:03:30 -0500 From: Linda Dunbar In-reply-to: <5EB1A55E180C914BBC1A49310B762938669031AC45@HQ1-EXCH02.corp.brocade.com> To: 'Anoop Ghanwani' , armd@ietf.org Message-id: <002b01cb5354$d41a1af0$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_Ois0DVjAZ5ETnP5TpeRAHQ)" Thread-index: ActRXBftmhrwaO1WSSe3MDOhfXUyPQBS2q5wACtDbTA= References: <001801cb5281$e2dffce0$c7091942@china.huawei.com> <5EB1A55E180C914BBC1A49310B762938669031AC45@HQ1-EXCH02.corp.brocade.com> Subject: Re: [armd] another revision for ARMD charter statement X-BeenThere: armd@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, 13 Sep 2010 15:03:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Ois0DVjAZ5ETnP5TpeRAHQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Anoop, Thanks for pointing this out. The bullet on isolation should be removed as the text for client controlled virtual subnet has been removed. The second sentence on performance will stay. Regards, Linda Dunbar _____ From: Anoop Ghanwani [mailto:anoop@brocade.com] Sent: Sunday, September 12, 2010 1:27 PM To: Linda Dunbar; armd@ietf.org Cc: 'T Sridhar' Subject: RE: another revision for ARMD charter statement >>>> * Should consider isolation of address resolution solutions across different client controlled virtual subnets, i.e. hosts from one client should be limited to getting MAC addresses from virtual hosts within its own controlled subnet(s). Should consider a performance analysis of proposed solutions. >>>> I still have a problem with the first sentence. There is not a concrete, well-accepted definition of what a "client controlled virtual subnet" is, and how forwarding takes place when something like that is defined. Unrelated to the above, I believe the second sentence is supposed to be a bullet on its own? Anoop From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Sunday, September 12, 2010 6:54 AM To: armd@ietf.org Cc: Anoop Ghanwani; 'T Sridhar' Subject: another revision for ARMD charter statement After separate discussions with Force10's Sridhar and Brocade's Anoop, we have decided to make some changes to the ARMD charter statements. Here is the revised one. Please provide your comments. We plan to submit this charter statement to Internet AD Ralph and Jari next Tuesday. ARMD: Address Resolution for Massive amount of hosts in one broadcast Domain Description of Working Group: As server virtualization is introduced to data centers, the number of hosts in a data center can grow dramatically. Each physical server, which used to host one end-station, now can host hundreds of end-stations or virtual machines (VMs). Virtual machines (VMs) can be easily added and/or deleted and moved between servers. The VM's flexible addition/deletion and moving around provide foundation for virtual hosts and virtual desktops offered by Cloud Computing services and make it possible to combine pool of servers into one single entity for ease of management and better utilization. This rapid growth of virtual hosts could tremendously impact networks and servers. One major issue is frequent ARP (IPv4) or neighbor discovery (IPv6) requests from hosts. All hosts send out those requests frequently due to host ARP caches being aged out in minutes. With tens of thousands of hosts (each with a distinct MAC address) in one Data Center, the number of ARP (or ND) packets per second from all hosts could potentially be as high as 1,000 to 10,000/second. This rate imposes tremendous computational burden on many hosts. Traditional subnet (VLAN) partitioning no longer works well when servers are virtualized. First of all, servers need to be on the same subnet for VM mobility. Secondly, when each server only has one host, there is only one VLAN enabled for the port towards the server. The switch can block all broadcast messages from other subnets (VLANs). When one physical server is supporting >100 Virtual Machines, i.e. >100 hosts, most likely the virtual hosts on one server are on different subnets (VLANs). If there are 50 subnets (VLANs) enabled on the switch port to the server, the server has to handle all the ARP broadcast messages on all 50 subnets (VLANs). The amount of ARP to be processed by each server is still too much. One characteristic of a next-generation Data Center is the possibility of one subnet spanning multiple sites. For example, a server administrator can combine servers in multiple sites into one huge resource pool for better resource management and ease of allocation. Each of the servers in this pool might be configured with one or more VMs. If mobility is required, like VMware's vMotion, all the physical servers (and associated VMs) need to be on the same IP subnet. Under those circumstances, one Layer 2 network (or subnet) could span across multiple sites. The multiple sites could be connected by any types of network, like L2VPN, L3VPN, Ethernet network, or simple IP networks. Efficient address resolution across multiple sites should be considered by this working group. The goal of this working group is to develop interoperable solutions to solve the above problems within the Data Center and multi Data Center environments. This could involve multi-domain (multi-company), multi-site and multi-vendor environments. The design should consider the following properties: * All solutions developed by ARMD WG should not require any behavior changes on hosts, applications, or Virtual Machines being deployed in the market. * All solutions developed should not break DHCP, or any other broadcast/multicast mechanism used by applications. * Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed. * Should consider variety of solutions, including directory based, proxy based, or cache based solutions. * Include analysis of security concerns of IPv4 ARP requests from malicious users. Evaluating potential security solutions and conclude if the security threat can justify solutions. * ARMD assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider isolation of address resolution solutions across different client controlled virtual subnets, i.e. hosts from one client should be limited to getting MAC addresses from virtual hosts within its own controlled subnet(s). Should consider a performance analysis of proposed solutions. Here are the items which should not be in the scope of the working group: * Re-define DHCP behavior * Re-define IPv6 ND security model * Solution developed should not expect any behavior changes for the guest OS/applications running on the VMs * Direct links from hosts and virtual hosts being non-Ethernet links. Goals and Milestones: * Problem statement * Gap Analysis Statement within Data Center o Gaps within ARP o Gaps within IPv6 ND or autoconfiguration * Survey of Existing Solutions o Survey of NHRP (RFC2332) & SCSP, and their applicability to Ethernet networks; o Survey of TRILL work as a potential solution; o Survey of other potential solutions, like MOOSE or SEATTLE; and o Other proposals * Security Analysis of Existing Solutions o Study existing solutions, like Dynamic ARP Inspection, Egress ARP Inspection, etc, and evaluate if any of them or others should be included in the solutions specified by this working group. * Architectural Design for Next-Generation Data Center * Protocol Documents Time line for BOF presentations Initial Problem Statement August GAP analysis October Survey of Existing Solutions October Security Analysis of Existing Solutions October Architectural Design for NG October Final Problem statement for BOF October Protocol Documents October Regards, Linda Dunbar --Boundary_(ID_Ois0DVjAZ5ETnP5TpeRAHQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Anoop,

 

Thanks for pointing this out. The bullet on isolation should be removed as the text for client controlled virtual subnet has been removed.

 

The second sentence on performance will stay.

 

Regards, Linda Dunbar

 

 

 


From: Anoop Ghanwani [mailto:anoop@brocade.com]
Sent: Sunday, September 12, 2010 1:27 PM
To: Linda Dunbar; armd@ietf.org
Cc: 'T Sridhar'
Subject: RE: another revision for ARMD charter statement

 

>>>> 

·        Should consider isolation of address resolution solutions across different client controlled virtual subnets, i.e. hosts from one client should be limited to getting MAC addresses from virtual hosts within its own controlled subnet(s). Should consider a performance analysis of proposed solutions.  

>>>> 

 

I still have a problem with the first sentence.  There is not a concrete,

well-accepted definition of what a “client controlled virtual subnet” is,

and how forwarding takes place when something like that is defined.

 

Unrelated to the above, I believe the second sentence is supposed to

be a bullet on its own?

 

Anoop

 

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Sunday, September 12, 2010 6:54 AM
To: armd@ietf.org
Cc: Anoop Ghanwani; 'T Sridhar'
Subject: another revision for ARMD charter statement

 

After separate discussions with Force10’s Sridhar and Brocade’s Anoop, we have decided to make some changes to the ARMD charter statements. Here is the revised one. Please provide your comments. We plan to submit this charter statement to Internet AD Ralph and Jari next Tuesday.  

 

 

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

 

 

Description of Working Group:

As server virtualization is introduced to data centers, the number of hosts in a data center can grow dramatically.  Each physical server, which used to host one end-station, now can host hundreds of end-stations or virtual machines (VMs). Virtual machines (VMs) can be easily added and/or deleted and moved between servers.  The VM’s flexible addition/deletion and moving around provide foundation for virtual hosts and virtual desktops offered by Cloud Computing services and make it possible to combine pool of servers into one single entity for ease of management and better utilization.

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

Traditional subnet (VLAN) partitioning no longer works well when servers are virtualized. First of all, servers need to be on the same subnet for VM mobility. Secondly, when each server only has one host, there is only one VLAN enabled for the port towards the server. The switch can block all broadcast messages from other subnets (VLANs). When one physical server is supporting >100 Virtual Machines, i.e. >100 hosts, most likely the virtual hosts on one server are on different subnets (VLANs). If there are 50 subnets (VLANs) enabled on the switch port to the server, the server has to handle all the ARP broadcast messages on all 50 subnets (VLANs). The amount of ARP to be processed by each server is still too much.

One characteristic of a next-generation Data Center is the possibility of one subnet spanning  multiple sites. For example, a server administrator can combine servers in multiple sites into one huge resource pool for better resource management and ease of allocation.  Each of the servers in this pool might be configured with one or more VMs. If mobility is required, like VMware’s vMotion, all the physical servers  (and associated VMs) need to be on the same IP subnet. Under those circumstances, one Layer 2 network (or subnet) could span across multiple sites. The multiple sites could be connected by any types of network, like L2VPN, L3VPN, Ethernet network, or simple IP networks. Efficient address resolution across multiple sites should be considered by this working group.

The goal of this working group is to develop interoperable solutions to solve the above problems within the Data Center and multi Data Center environments.  This could involve multi-domain (multi-company), multi-site and multi-vendor environments.

The design should consider the following properties:

·     All solutions developed by ARMD WG should not require any behavior changes on hosts, applications, or Virtual Machines being deployed in the market.

·     All solutions developed should not break DHCP, or any other broadcast/multicast mechanism used by applications.

·     Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed.

·     Should consider variety of solutions, including directory based, proxy based, or cache based solutions.

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

·     ARMD assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet links. 

·     Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure IP, Ethernet, or others.

·     Should consider isolation of address resolution solutions across different client controlled virtual subnets, i.e. hosts from one client should be limited to getting MAC addresses from virtual hosts within its own controlled subnet(s). Should consider a performance analysis of proposed solutions.  

 

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

·     Re-define DHCP behavior

·     Re-define IPv6 ND security model

·     Solution developed should not expect any behavior changes for the guest OS/applications running on the VMs

·     Direct links from hosts and virtual hosts being non-Ethernet links.

 

Goals and Milestones:

·     Problem statement

·     Gap Analysis Statement within Data Center

o    Gaps within ARP

o    Gaps within IPv6 ND or autoconfiguration

·     Survey of Existing Solutions

o    Survey of NHRP (RFC2332) & SCSP,  and their applicability to Ethernet networks;

o    Survey of TRILL work as a potential solution;

o    Survey of  other potential solutions, like MOOSE or SEATTLE; and

o    Other proposals

·     Security Analysis of Existing Solutions

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

·     Architectural Design for Next-Generation Data Center

·     Protocol Documents

 

 

Time line for BOF presentations

 

Initial Problem Statement                            August   

GAP analysis                                              October

Survey of Existing Solutions                        October

Security Analysis of Existing Solutions         October

Architectural Design for NG                        October

Final Problem statement for BOF                October

      Protocol Documents                                   October

 

 

 

Regards, Linda Dunbar

--Boundary_(ID_Ois0DVjAZ5ETnP5TpeRAHQ)-- From ldunbar@huawei.com Mon Sep 13 10:16:14 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146EB3A69F7 for ; Mon, 13 Sep 2010 10:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.691 X-Spam-Level: X-Spam-Status: No, score=-100.691 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_40=-0.185, 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 QfOlwPQ7zyZs for ; Mon, 13 Sep 2010 10:16:02 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id D101A3A6A9D for ; Mon, 13 Sep 2010 10:15:46 -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 <0L8P00GVZ3YZWK@usaga04-in.huawei.com> for armd@ietf.org; Mon, 13 Sep 2010 12:16: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 <0L8P003SJ3YX70@usaga04-in.huawei.com> for armd@ietf.org; Mon, 13 Sep 2010 12:16:11 -0500 (CDT) Date: Mon, 13 Sep 2010 12:16:08 -0500 From: Linda Dunbar To: armd@ietf.org Message-id: <005b01cb5367$5bcf4bc0$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_ELpdDCeAZGxer/wQwACZYA)" Thread-index: ActTZ1q/6Tvq8oebRfWNqbWPrSAz+w== Subject: [armd] Revised charter statements for ARMD X-BeenThere: armd@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, 13 Sep 2010 17:16:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ELpdDCeAZGxer/wQwACZYA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT It was pointed out to me that I needed to explain what are changes on the charter statements and why. Major changes include * Removing the duplicated IP address in one subnet requirement. Several people pointed out that the requirement on duplicated IP addresses within one subnet for cloud computing should not be included in the charter. * Removed the term Client Controlled Virtual Subnet because it is not a very well defined term. * Added a description to explain why there could be large amount of (virtual) hosts within one subnet. Many people have sent me separate emails asking why not use small subnet to make ARP scales well. I think it is necessary to add this description to make the problem statement more clear. Anoop also pointed out that one of the bullets which correspond to Client Controlled Virtual Subnet should also be removed from the revised charter sent out last week. I agree with him and delete the bullet. Here is the revised charter statement which I will use to request a formal BOF to Jari and Ralph. Linda ARMD: Address Resolution for Massive amount of hosts in one broadcast Domain Description of Working Group: As server virtualization is introduced to data centers, the number of hosts in a data center can grow dramatically. Each physical server, which used to host one end-station, now can host hundreds of end-stations or virtual machines (VMs). Virtual machines (VMs) can be easily added and/or deleted and moved between servers. The VM's flexible addition/deletion and moving around provide foundation for virtual hosts and virtual desktops offered by Cloud Computing services and make it possible to combine pool of servers into one single entity for ease of management and better utilization. This rapid growth of virtual hosts could tremendously impact networks and servers. One major issue is frequent ARP (IPv4) or neighbor discovery (IPv6) requests from hosts. All hosts send out those requests frequently due to host ARP caches being aged out in minutes. With tens of thousands of hosts (each with a distinct MAC address) in one Data Center, the number of ARP (or ND) packets per second from all hosts could potentially be as high as 1,000 to 10,000/second. This rate imposes tremendous computational burden on many hosts. Traditional subnet (VLAN) partitioning no longer works well when servers are virtualized. First of all, servers need to be on the same subnet for VM mobility. Secondly, when each server only has one host, there is only one VLAN enabled for the switch port towards the server. The switch can block all broadcast messages from other subnets (VLANs) from going to the server. When one physical server is supporting >100 Virtual Machines, i.e. >100 hosts, most likely the virtual hosts on one server are on different subnets (VLANs). If there are 50 subnets (VLANs) enabled on the switch port to the server, the server has to handle all the ARP broadcast messages on all 50 subnets (VLANs). The amount of ARP to be processed by each server is still too much. One characteristic of a next-generation Data Center is the possibility of one subnet spanning multiple sites. For example, a server administrator can combine servers in multiple sites into one huge resource pool for better resource management and ease of allocation. Each of the servers in this pool might be configured with one or more VMs. If mobility is required, like VMware's vMotion, all the physical servers (and associated VMs) need to be on the same IP subnet. Another example is Virtual Private Cloud offered by Amazon which allows client to have a subnet with some of the hosts on client location and others in the Amazon's cloud. Under those circumstances, one Layer 2 network (or subnet) could span across multiple sites. The multiple sites could be connected by any types of network, like L2VPN, L3VPN, Ethernet network, or simple IP networks. Efficient address resolution across multiple sites should be considered by this working group. The goal of this working group is to develop interoperable solutions to solve the above problems within a Data Center and multi-site Data Center environments. This could involve multi-domain (multi-company), multi-site and multi-vendor environments. The design should consider the following properties: * All solutions developed by ARMD WG should not require any behavior changes on hosts, applications, or Virtual Machines being deployed in the market. * All solutions developed should not break DHCP, or any other broadcast/multicast mechanism used by applications. * Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed. * Should consider variety of solutions, including directory based, proxy based, or cache based solutions. * Include analysis of security concerns of IPv4 ARP requests from malicious users. Evaluating potential security solutions and conclude if the security threat can justify solutions. * ARMD assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet links. * Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure IP, Ethernet, or others. * Should consider a performance analysis of proposed solutions. Here are the items which should not be in the scope of the working group: * Re-define DHCP behavior * Re-define IPv6 ND security model * Solution developed should not expect any behavior changes for the guest OS/applications running on the VMs * Direct links from hosts and virtual hosts being non-Ethernet links. Goals and Milestones: * Problem statement * Gap Analysis Statement within Data Center * Gaps within ARP * Gaps within IPv6 ND or autoconfiguration * Survey of Existing Solutions * Survey of NHRP (RFC2332) & SCSP, and their applicability to Ethernet networks; * Survey of TRILL work as a potential solution; * Survey of other potential solutions, like MOOSE or SEATTLE; and * Other proposals * Security Analysis of Existing Solutions * Study existing solutions, like Dynamic ARP Inspection, Egress ARP Inspection, etc, and evaluate if any of them or others should be included in the solutions specified by this working group. * Architectural Design for Next-Generation Data Center * Protocol Documents Time line for BOF presentations Initial Problem Statement August GAP analysis October Survey of Existing Solutions October Security Analysis of Existing Solutions October Architectural Design for NG October Final Problem statement for BOF October Protocol Documents 2011 _____ --Boundary_(ID_ELpdDCeAZGxer/wQwACZYA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

It was pointed out to me that I needed to explain what are changes on the charter statements and why.

 

Major changes include

  • Removing the duplicated IP address in one subnet requirement.

Several people pointed out that the requirement on duplicated IP addresses within one subnet for cloud computing should not be included in the charter.

  • Removed the term Client Controlled Virtual Subnet because it is not a very well defined term.
  • Added a description to explain why there could be large amount of (virtual) hosts within one subnet.

Many people have sent me separate emails asking why not use small subnet to make ARP scales well. I think it is necessary to add this description to make the problem statement more clear.

 

Anoop also pointed out that one of the bullets which correspond to Client Controlled Virtual Subnet should also be removed from the revised charter sent out last week. I agree with him and delete the bullet.

 

Here is the revised charter statement which I will use to request a formal BOF to Jari and Ralph.

 

Linda

 

 

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

 

 

Description of Working Group:

As server virtualization is introduced to data centers, the number of hosts in a data center can grow dramatically.  Each physical server, which used to host one end-station, now can host hundreds of end-stations or virtual machines (VMs). Virtual machines (VMs) can be easily added and/or deleted and moved between servers.  The VM’s flexible addition/deletion and moving around provide foundation for virtual hosts and virtual desktops offered by Cloud Computing services and make it possible to combine pool of servers into one single entity for ease of management and better utilization.

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

Traditional subnet (VLAN) partitioning no longer works well when servers are virtualized. First of all, servers need to be on the same subnet for VM mobility. Secondly, when each server only has one host, there is only one VLAN enabled for the switch port towards the server. The switch can block all broadcast messages from other subnets (VLANs) from going to the server. When one physical server is supporting >100 Virtual Machines, i.e. >100 hosts, most likely the virtual hosts on one server are on different subnets (VLANs). If there are 50 subnets (VLANs) enabled on the switch port to the server, the server has to handle all the ARP broadcast messages on all 50 subnets (VLANs). The amount of ARP to be processed by each server is still too much.

One characteristic of a next-generation Data Center is the possibility of one subnet spanning  multiple sites. For example, a server administrator can combine servers in multiple sites into one huge resource pool for better resource management and ease of allocation.  Each of the servers in this pool might be configured with one or more VMs. If mobility is required, like VMware’s vMotion, all the physical servers  (and associated VMs) need to be on the same IP subnet. Another example is Virtual Private Cloud offered by Amazon which allows client to have a subnet with some of the hosts on client location and others in the Amazon’s cloud. Under those circumstances, one Layer 2 network (or subnet) could span across multiple sites. The multiple sites could be connected by any types of network, like L2VPN, L3VPN, Ethernet network, or simple IP networks. Efficient address resolution across multiple sites should be considered by this working group.

The goal of this working group is to develop interoperable solutions to solve the above problems within a Data Center and multi-site Data Center environments.  This could involve multi-domain (multi-company), multi-site and multi-vendor environments.

The design should consider the following properties:

  • All solutions developed by ARMD WG should not require any behavior changes on hosts, applications, or Virtual Machines being deployed in the market.
  • All solutions developed should not break DHCP, or any other broadcast/multicast mechanism used by applications.
  • Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed.
  • Should consider variety of solutions, including directory based, proxy based, or cache based solutions.
  • Include analysis of security concerns of IPv4 ARP requests from malicious users. Evaluating potential security solutions and conclude if the security threat can justify solutions.
  • ARMD assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet links. 
  • Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure IP, Ethernet, or others.
  • Should consider a performance analysis of proposed solutions.  

 

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

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

 

Goals and Milestones:

  • Problem statement
  • Gap Analysis Statement within Data Center
    • Gaps within ARP
    • Gaps within IPv6 ND or autoconfiguration
  • Survey of Existing Solutions
    • Survey of NHRP (RFC2332) & SCSP,  and their applicability to Ethernet networks;
    • Survey of TRILL work as a potential solution;
    • Survey of  other potential solutions, like MOOSE or SEATTLE; and
    • Other proposals
  • Security Analysis of Existing Solutions
    • Study existing solutions, like Dynamic ARP Inspection, Egress ARP Inspection, etc, and evaluate if any of them or others should be included in the solutions specified by this working group.  
  • Architectural Design for Next-Generation Data Center
  • Protocol Documents

 

 

Time line for BOF presentations

 

Initial Problem Statement                                        August   

GAP analysis                                                          October

Survey of Existing Solutions                                    October

Security Analysis of Existing Solutions                     October

Architectural Design for NG                                    October

Final Problem statement for BOF                            October

Protocol Documents                                               2011

 

 

 

 

 

 

 


--Boundary_(ID_ELpdDCeAZGxer/wQwACZYA)-- From ldunbar@huawei.com Mon Sep 13 13:22:28 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4F73A68A9 for ; Mon, 13 Sep 2010 13:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.867 X-Spam-Level: X-Spam-Status: No, score=-101.867 tagged_above=-999 required=5 tests=[AWL=0.131, 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 0pUep79HqTIs for ; Mon, 13 Sep 2010 13:22: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 9056C3A6AAF for ; Mon, 13 Sep 2010 13:22: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 <0L8P00DNKCM4SA@usaga02-in.huawei.com> for armd@ietf.org; Mon, 13 Sep 2010 13:22:52 -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 <0L8P009GXCM3I3@usaga02-in.huawei.com> for armd@ietf.org; Mon, 13 Sep 2010 13:22:51 -0700 (PDT) Date: Mon, 13 Sep 2010 15:22:52 -0500 From: Linda Dunbar To: armd@ietf.org Message-id: <00a401cb5381$7132eac0$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_lV1xs3Hc3bfcbXOwGnyPug)" Thread-index: ActTgXD82SIJVrbdTEmnyenHlF9OwA== Subject: [armd] ARMD BOF at 79th IETF has been submitted X-BeenThere: armd@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, 13 Sep 2010 20:22:28 -0000 This is a multi-part message in MIME format. --Boundary_(ID_lV1xs3Hc3bfcbXOwGnyPug) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear All, Please note that the request for ARMD BoF during 79th IETF has been submitted. http://trac.tools.ietf.org/bof/trac/wiki/WikiStart If you have any comments or suggestions, please let me know. By the way, we have requested the BOF session not to be in conflict with TRILL, DHC, L2VPN, and L3VPN. If you want to make this ARMD BOF not in conflict with any other sessions, please let us know as well. Regards, Linda Dunbar --Boundary_(ID_lV1xs3Hc3bfcbXOwGnyPug) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear All,

 

Please note that the request for ARMD BoF during 79th IETF has been submitted. http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

 

 If you have any comments or suggestions, please let me know.

 

By the way, we have requested the BOF session not to be in conflict with TRILL, DHC, L2VPN, and L3VPN. If you want to make this ARMD BOF not in conflict with any other sessions, please let us know as well.

 

Regards, Linda Dunbar

 

--Boundary_(ID_lV1xs3Hc3bfcbXOwGnyPug)-- From ldunbar@huawei.com Mon Sep 13 15:44:39 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C633A67E3 for ; Mon, 13 Sep 2010 15:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.17 X-Spam-Level: X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=0.428, 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 2ud3+op8Ec1F for ; Mon, 13 Sep 2010 15:44:34 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 7C6063A681A for ; Mon, 13 Sep 2010 15:44:34 -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 <0L8P00FJTJ6WB7@usaga02-in.huawei.com> for armd@ietf.org; Mon, 13 Sep 2010 15:44:57 -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 <0L8P00HIOJ6WN0@usaga02-in.huawei.com> for armd@ietf.org; Mon, 13 Sep 2010 15:44:56 -0700 (PDT) Date: Mon, 13 Sep 2010 17:44:56 -0500 From: Linda Dunbar To: armd@ietf.org Message-id: <00e201cb5395$49fb0050$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_jYjufTfb8SgVsahQ0bmRmA)" Thread-index: ActTlUnLIYSS6iGLRDKXplu7iQlSTA== Subject: [armd] some ideas on ARP optimization for one broadcast domain spanning across multiple sites X-BeenThere: armd@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, 13 Sep 2010 22:44:39 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jYjufTfb8SgVsahQ0bmRmA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear All, Just want to check your feedback on some ideas to reduce the ARP (IPv4) storm within one broadcast domain. Many hosts frequently send out gratuitous ARP for all other hosts in the broadcast domain to be aware of correct IP/MAC-VLAN mapping for the host. When one subnet is across multiple sites (or across many top of rack switches), there are several proposals on sending consolidated IP/MAC-VLAN among sites. Cisco's OTV suggests using IS/IS to send one site's IP/MAC-VLAN mapping to all other sites which belong to the same subnet. Juniper's Ethernet VPN suggests using BGP to send one site's IP/MAC-VLAN mapping to all other sites which belong to the same subnet. What if each site keeps their hosts' MAC address as private? The site gateway switches (or Top of Rack switches) can proxy the ARP requests from other sites with its own MAC address. By doing so, site gateway switch (or Top of Rack Switches) only need to send a group of IP addresses together with its own MAC to all other sites. Since IP addresses can be summarized, the amount of information to be sent to other sites is much smaller. Even if after many rounds of moving around and the IP addresses in one site can't be summarized anymore, you still get the saving by not sending all the MAC addresses. If Layer 2 switches enable Source Address learning only from ports towards server, but disable learning from ports towards network side, then all hosts can still use their individual SA for data frames. By doing so, Source Addresses of data frames are all original, which will not break DHCP behavior. Your comments are appreciated. I think writing a draft on this idea is worthwhile. Regards, Linda Dunbar --Boundary_(ID_jYjufTfb8SgVsahQ0bmRmA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear All,

 

Just want to check your feedback on some ideas to reduce the ARP (IPv4) storm within one broadcast domain.

 

Many hosts frequently send out gratuitous ARP for all other hosts in the broadcast domain to be aware of correct IP/MAC-VLAN mapping for the host. When one subnet is across multiple sites (or across many top of rack switches), there are several proposals on sending consolidated IP/MAC-VLAN among sites. Cisco’s OTV suggests using IS/IS to send one site’s IP/MAC-VLAN mapping to all other sites which belong to the same subnet. Juniper’s Ethernet VPN suggests using BGP to send one site’s IP/MAC-VLAN mapping to all other sites which belong to the same subnet.

 

What if each site keeps their hosts’ MAC address as private? The site gateway switches (or Top of Rack switches) can proxy the ARP requests from other sites with its own MAC address. By doing so, site gateway switch (or Top of Rack Switches) only need to send a group of IP addresses together with its own MAC to all other sites. Since IP addresses can be summarized, the amount of information to be sent to other sites is much smaller. Even if after many rounds of moving around and the IP addresses in one site can’t be summarized anymore, you still get the saving by not sending all the MAC addresses.

 

If Layer 2 switches enable Source Address learning only from ports towards server, but disable learning from ports towards network side, then all hosts can still use their individual SA for data frames. By doing so, Source Addresses of data frames are all original, which will not break DHCP behavior.

 

Your comments are appreciated. I think writing a draft on this idea is worthwhile.

 

Regards, Linda Dunbar

 

 

--Boundary_(ID_jYjufTfb8SgVsahQ0bmRmA)-- From ning.so@verizonbusiness.com Wed Sep 15 12:05:01 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1C73A6A2C for ; Wed, 15 Sep 2010 12:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 WAszGqNlL5+w for ; Wed, 15 Sep 2010 12:04:56 -0700 (PDT) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id C307F3A69B4 for ; Wed, 15 Sep 2010 12:04:56 -0700 (PDT) Received: from pdcismtp01.vzbi.com ([unknown] [166.40.77.67]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0L8S00L1YYCXAC60@firewall.verizonbusiness.com> for armd@ietf.org; Wed, 15 Sep 2010 19:05:21 +0000 (GMT) Received: from pdcismtp01.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0L8S00LJPYCX3F00@pdcismtp01.vzbi.com> for armd@ietf.org; Wed, 15 Sep 2010 19:05:21 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([unknown] [153.39.68.167]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0L8S00L56YCX3X00@pdcismtp01.vzbi.com> for armd@ietf.org; Wed, 15 Sep 2010 19:05:21 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Sep 2010 19:05:21 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CB5508.F1353906" Date: Wed, 15 Sep 2010 19:05:19 +0000 Message-id: <14584D6EE26B314187A4F68BA2060600052600C3@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Suggestion for ARMD charter and scope Thread-index: ActVCPCg3UOA3JU0TMOqGvENjGSCdA== From: "So, Ning" To: armd@ietf.org X-OriginalArrivalTime: 15 Sep 2010 19:05:21.0024 (UTC) FILETIME=[F183D800:01CB5508] Subject: [armd] Suggestion for ARMD charter and scope X-BeenThere: armd@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, 15 Sep 2010 19:05:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB5508.F1353906 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, =20 As discussed, here are some of the work I believe should be included in the ARMD scope of work from a carrier's perspective. =20 =20 * Address scalability and mobility: Service provider's data centers offering cloud storage and computing services are much larger than the traditional enterprise data centers. The number of hosts (virtual hosts sold to clients) to be supported by the servers in those data centers will be in the magnitude of tens or hundreds of thousands. For ease of resource management (computing, power, etc), it is necessary to have the flexibility of loading virtual hosts to any physical servers in the resource pool and being able to move them to different physical servers. Moving virtual machines while maintaining MAC-VLAN & IP addresses among servers are much easier if those servers to be on the same subnet. Therefore, service provider data centers need to have highly scalable addresses in one subnet.=20 =20 * Traditional VPN (L3VPN or L2VPN) connects multiple customer routers in multiple locations into one secure private network. The customer routers as well as service provider VPNs often have private IP address scheme in IPv4. Address conflicts can occur when private IP addresses are not resolved correctly within a data center when multiple network accessing the same data center. Proper address resolution and traffic separation among different customer VPN within one data center is very important to service providers and to the existing enterprise customers.=20 =20 =20 =20 Best regrads, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 =20 ------_=_NextPart_001_01CB5508.F1353906 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda,

=

 

=

As discussed, here are some of the = work I believe should be included in the ARMD scope of work from a = carrier’s perspective. 

 

=

·         Address scalability and mobility:  Service provider’s data centers = offering cloud storage and computing services are much larger than the = traditional enterprise data centers. The number of hosts (virtual hosts sold to = clients) to be supported by the servers in those data centers will be in the = magnitude of tens or hundreds of thousands.   For ease of resource = management (computing, power, etc), it is necessary to have the flexibility of = loading virtual hosts to any physical servers in the resource pool and being = able to move them to different physical servers. Moving virtual machines while maintaining MAC-VLAN & IP addresses among servers are much easier if = those servers to be on the same subnet.  Therefore, service provider data centers need to have highly scalable addresses in one subnet. =

 

·         Traditional VPN (L3VPN or L2VPN) connects multiple customer routers in multiple = locations into one secure private network. The customer routers as well as service provider VPNs often have private IP address scheme in IPv4. =   Address conflicts can occur when private IP addresses are not resolved correctly = within a data center when multiple network accessing the same data = center.  Proper address resolution and traffic separation among different customer VPN = within one data center is very important to service providers and to the = existing enterprise customers.

 

=

 

=

 

=

Best regrads,

 

=

Ning So

Network Evolution = Planning

Verizon, Inc.

(office) = 972-729-7905

(Cell) = 972-955-0914

 

 

------_=_NextPart_001_01CB5508.F1353906-- From rdroms@cisco.com Thu Sep 16 12:15:22 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B903A6A02; Thu, 16 Sep 2010 12:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.406 X-Spam-Level: X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 1sAqPXH2VCfW; Thu, 16 Sep 2010 12:15:09 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B46EB3A69B6; Thu, 16 Sep 2010 12:15:06 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJIJkkyrR7Hu/2dsb2JhbACiDnGpIJxGhUEEii+FXw X-IronPort-AV: E=Sophos;i="4.56,378,1280707200"; d="scan'208";a="187771057" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 16 Sep 2010 19:15:30 +0000 Received: from sjc-vpnasa-226.cisco.com (sjc-vpnasa-226.cisco.com [10.21.104.226]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o8GJFTEO028311; Thu, 16 Sep 2010 19:15:29 GMT From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Sep 2010 21:15:25 +0200 References: <30B6EA90-0136-4D53-AB00-449AD2778848@gmail.com> To: IESG IESG , armd@ietf.org Message-Id: <4789B967-837F-4719-897B-0A43AB485EB6@cisco.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Thu, 16 Sep 2010 12:29:31 -0700 Subject: [armd] Fwd: IETF 79 scheduling reuest: ARMD BoF X-BeenThere: armd@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, 16 Sep 2010 19:15:23 -0000 FYI... - Ralph Begin forwarded message: > From: Ralph Droms > Date: September 16, 2010 9:14:25 PM GMT+02:00 > To: IETF Agenda > Subject: IETF 79 scheduling reuest: ARMD BoF >=20 > ITEF Agenda, >=20 > The Address Resolution for Massive amount of hosts in one broadcast = Domain (ARMD) BoF request has been approved. >=20 > - Ralph >=20 From lichenyj@chinamobile.com Sat Sep 18 18:32:11 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 816943A6900 for ; Sat, 18 Sep 2010 18:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.861 X-Spam-Level: **** X-Spam-Status: No, score=4.861 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222] 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 b1KCgiqrLgxX for ; Sat, 18 Sep 2010 18:32:10 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id 856083A6966 for ; Sat, 18 Sep 2010 18:32:09 -0700 (PDT) Received: from lichen ([10.2.0.208]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with ESMTP id 2010091909322584-1579 ; Sun, 19 Sep 2010 09:32:25 +0800 Date: Sun, 19 Sep 2010 09:32:10 +0800 From: "lichenyj" To: "armd" Message-ID: <201009190932099680867@chinamobile.com> X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2010-09-19 09:32:25, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2010-09-19 09:32:33, Serialize complete at 2010-09-19 09:32:33 Content-Type: multipart/alternative; boundary="=====003_Dragon035776454645_=====" Cc: zhoulinlang , =?gb2312?B?wO7BrNS0?= Subject: [armd] Fw: Re:seeking your input on Address resolution in Service Provider DataCenters for Cloud service X-BeenThere: armd@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: Sun, 19 Sep 2010 01:32:11 -0000 This is a multi-part message in MIME format. --=====003_Dragon035776454645_===== Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="gb2312" We really appreciate ARMD's work. It's useful for sloving the next generation data center problem, such as ARP and VM mobility problem. We hope you could continue your research and we'll focus on issues related to the cloud data center, either. Best regrads, 2010-09-18 Li Chen Research Institute of China Mobile Floor 11, Door 2, Dacheng Plaza No.28 Xuanwumen West Ave, Xuanwu District Beijing 100053, China Mobile: +86 13911677949 Email: lichenyj@chinamobile.com --=====003_Dragon035776454645_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1HQjIzMTIiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuNjAw MC4xNzA4MCIgbmFtZT1HRU5FUkFUT1I+PExJTksgDQpocmVmPSJCTE9DS1FVT1RFe21hcmdpbi1U b3A6IDBweDsgbWFyZ2luLUJvdHRvbTogMHB4OyBtYXJnaW4tTGVmdDogMmVtfSIgDQpyZWw9c3R5 bGVzaGVldD4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5F UkFUT1I+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IMvOzOU7DQp9DQpAZm9u dC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFuYTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiBAy87M5TsNCn0NCkBwYWdlIFNlY3Rpb24xIHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7 IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0 OyB9DQpQLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQt U0laRTogMTAuNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5l dyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkNCn0NCkxJLk1zb05vcm1hbCB7DQoJVEVYVC1K VVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQtU0laRTogMTAuNXB0OyBNQVJHSU46IDBjbSAw Y20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3Rp ZnkNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBG T05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1l cyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpBOmxpbmsgew0KCUNPTE9SOiBi bHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0K CUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsN CglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29I eXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglGT05ULVdFSUdIVDogbm9ybWFsOyBDT0xP Ujogd2luZG93dGV4dDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULUZBTUlMWTogVmVyZGFuYTsg VEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28tc3R5bGUtdHlwZTogcGVyc29uYWwtY29tcG9zZQ0K fQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9uMQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1T SVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RU T006IDBweDsgTUFSR0lOLUxFRlQ6IDJlbQ0KfQ0KT0wgew0KCU1BUkdJTi1UT1A6IDBweDsgTUFS R0lOLUJPVFRPTTogMHB4DQp9DQpVTCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9N OiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hIj48Rk9OVCANCmZhY2U9VmVyZGFu YSBjb2xvcj0jMDAwMDAwIHNpemU9Mj4NCjxESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBz aXplPTI+PEZPTlQgZmFjZT1WZXJkYW5hIA0Kc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+Jm5ic3A7PC9ESVY+PC9ESVY+DQo8 RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTj4mbmJzcDsmbmJzcDsmbmJz cDsgV2UgcmVhbGx5IGFwcHJlY2lhdGUgDQpBUk1EJ3Mgd29yay4gSXQncyB1c2VmdWwmbmJzcDtm b3Igc2xvdmluZyZuYnNwO3RoZSBuZXh0IGdlbmVyYXRpb24gZGF0YSBjZW50ZXIgDQpwcm9ibGVt LCBzdWNoJm5ic3A7YXMmbmJzcDsmbmJzcDtBUlAgYW5kIFZNIG1vYmlsaXR5IA0KcHJvYmxlbS48 L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTj48 L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 U1BBTj4mbmJzcDsmbmJzcDsmbmJzcDsgV2UgaG9wZSB5b3UgY291bGQgY29udGludWUgDQp5b3Vy IHJlc2VhcmNoIGFuZCZuYnNwOyZuYnNwO3dlJ2xsIGZvY3VzIG9uIGlzc3VlcyByZWxhdGVkIHRv IHRoZSBjbG91ZCBkYXRhIA0KY2VudGVyLCBlaXRoZXIuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGxhbmc9 RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPkJl c3QgDQpyZWdyYWRzLDxvOnA+PC9vOnA+PC9TUEFOPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVYgYWxpZ249bGVmdD48Rk9OVCBm YWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+MjAxMC0wOS0xOCANCjwvRk9OVD48L0RJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0KPEhSIHN0eWxlPSJXSURUSDogMTIycHg7IEhF SUdIVDogMnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEg Y29sb3I9I2MwYzBjMCBzaXplPTI+PFNQQU4+DQo8RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+TGkgQ2hlbjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj5SZXNl YXJjaCBJbnN0aXR1dGUgb2YgQ2hpbmEgTW9iaWxlPEJSPkZsb29yIDExLCBEb29yIA0KMiwgRGFj aGVuZyBQbGF6YTxCUj5Oby4yOCBYdWFud3VtZW4gV2VzdCBBdmUsIFh1YW53dSBEaXN0cmljdDxC Uj5CZWlqaW5nIDEwMDA1MywgDQpDaGluYTxCUj5Nb2JpbGU6ICs4NiAxMzkxMTY3Nzk0OTxCUj5F bWFpbDombmJzcDsgPFU+bGljaGVueWo8L1U+PC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmhAY2hp bmFtb2JpbGUuY29tIj48Rk9OVCBmYWNlPcvOzOUgDQpzaXplPTI+QGNoaW5hbW9iaWxlLmNvbTwv Rk9OVD48L0E+PC9ESVY+PC9ESVY+PC9ESVY+PC9TUEFOPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9G T05UPjwvRElWPjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K --=====003_Dragon035776454645_=====-- From ronc.ntear@gmail.com Sun Sep 19 04:30:58 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB443A6890 for ; Sun, 19 Sep 2010 04:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.204 X-Spam-Level: X-Spam-Status: No, score=-100.204 tagged_above=-999 required=5 tests=[AWL=1.772, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FVdwH9zgmIJA for ; Sun, 19 Sep 2010 04:30:57 -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 A0F5E3A6830 for ; Sun, 19 Sep 2010 04:30:56 -0700 (PDT) Received: by vws10 with SMTP id 10so2903084vws.31 for ; Sun, 19 Sep 2010 04:31:20 -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=nwutWo3Y2yslMZ647syQHWVb7Dtj99QDPgvsKONW5/Q=; b=bMMmUiTAqWbuQNWHubPfUB0ycpXLJoOf7TyYLSnbFDo1I0JUJ8yuxeQX6HBqGij5dA 0uderyan42MZ8Os6WL5D/Az7bQWYkrNO3oN/jfvZKp8awO/VQdXUq5qFUd8E+FAppg24 ayDyJAbi/qXXdpICizZSt8zGG4SF5d6BjJdto= 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=lFd+bKbFNvRhd/7T09I/LFSKQW2opvINfiNLnliO++INU0dmgB/ByneCFq194SmMSF 12Hg5Gjr9hEiEkmJoxrmISaBtgV8kcY0eJ3YVJVQ7k4EbuwemUjyRG2KSJd5zOX3ykPL YtQ44UKfMFlO733W1Cwp67hYpXSfIjBRx0x38= MIME-Version: 1.0 Received: by 10.220.168.213 with SMTP id v21mr4324455vcy.274.1284895880161; Sun, 19 Sep 2010 04:31:20 -0700 (PDT) Sender: ronc.ntear@gmail.com Received: by 10.220.178.7 with HTTP; Sun, 19 Sep 2010 04:31:20 -0700 (PDT) In-Reply-To: <00e201cb5395$49fb0050$4b0c7c0a@china.huawei.com> References: <00e201cb5395$49fb0050$4b0c7c0a@china.huawei.com> Date: Sun, 19 Sep 2010 13:31:20 +0200 X-Google-Sender-Auth: YxfnLgxq14jlQeK1IH6iGFCeix0 Message-ID: From: Ron Cohen To: Linda Dunbar Content-Type: multipart/alternative; boundary=0016e65ae5a082ae0204909b223b Cc: armd@ietf.org Subject: Re: [armd] some ideas on ARP optimization for one broadcast domain spanning across multiple sites X-BeenThere: armd@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: Sun, 19 Sep 2010 11:30:58 -0000 --0016e65ae5a082ae0204909b223b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Linda, My comments: 1. Need to take into account more than one gateway per site, for both resiliency and load balancing. 2. I'm not convinced that the complexity of summarizing parts-of subnets is worth the potential bandwidth saving. We need to look at the entire protoco= l (including updates upon move etc.) to determine whether summarizing doesn't consume more bandwidth due to triggered updates. 3. It is not clear from the proposal how each gateway learns the IP addresses of connected hosts. That is, if a new VM boots up, how is the gateway notified/learns of its IP/MAC assignment. How does aging work, etc. 4. Please explain which DHCP concerns you refer to and why the proposal of disabling source learning from uplink ports solves it. Thank you Ron On Tue, Sep 14, 2010 at 12:44 AM, Linda Dunbar wrote: > Dear All, > > > > Just want to check your feedback on some ideas to reduce the ARP (IPv4) > storm within one broadcast domain. > > > > Many hosts frequently send out gratuitous ARP for all other hosts in the > broadcast domain to be aware of correct IP/MAC-VLAN mapping for the host. > When one subnet is across multiple sites (or across many top of rack > switches), there are several proposals on sending consolidated IP/MAC-VLA= N > among sites. Cisco=92s OTV suggests using IS/IS to send one site=92s IP/M= AC-VLAN > mapping to all other sites which belong to the same subnet. Juniper=92s > Ethernet VPN suggests using BGP to send one site=92s IP/MAC-VLAN mapping = to > all other sites which belong to the same subnet. > > > > What if each site keeps their hosts=92 MAC address as private? The site > gateway switches (or Top of Rack switches) can proxy the ARP requests fro= m > other sites with its own MAC address. By doing so, site gateway switch (o= r > Top of Rack Switches) only need to send a group of IP addresses together > with its own MAC to all other sites. Since IP addresses can be summarized= , > the amount of information to be sent to other sites is much smaller. Even= if > after many rounds of moving around and the IP addresses in one site can= =92t be > summarized anymore, you still get the saving by not sending all the MAC > addresses. > > > > If Layer 2 switches enable Source Address learning only from ports toward= s > server, but disable learning from ports towards network side, then all ho= sts > can still use their individual SA for data frames. By doing so, Source > Addresses of data frames are all original, which will not break DHCP > behavior. > > > > Your comments are appreciated. I think writing a draft on this idea is > worthwhile. > > > > Regards, Linda Dunbar > > > > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > --0016e65ae5a082ae0204909b223b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Linda,

My comments:

1. Need to take into account more than one gateway per site, for b= oth resiliency and load balancing.=A0

2. I'm n= ot convinced that the complexity of summarizing parts-of subnets is worth t= he potential bandwidth saving. We need to look at the entire protocol (incl= uding updates upon move etc.) to determine whether summarizing doesn't = consume more bandwidth due to triggered updates.

3. It is not clear from the proposal how each gateway l= earns the IP addresses of connected hosts. That is, if a new VM boots up, h= ow is the gateway notified/learns of its IP/MAC assignment. How does aging = work, etc.

4.=A0Please explain which DHCP concerns you refer to an= d why the proposal of disabling source learning from uplink ports solves it= .=A0

Thank you
Ron



On Tue, Sep 14, 2010 at 12:44 AM, Linda = Dunbar <ldunbar@huawei.com> wrote:

Dear All,

=A0

Just want to check your feedback on some ide= as to reduce the ARP (IPv4) storm within one broadcast domain.

=A0

Many hosts frequently send out gratuitous AR= P for all other hosts in the broadcast domain to be aware of correct IP/MAC-VLAN mapping fo= r the host. When one subnet is across multiple sites (or across many top of r= ack switches), there are several proposals on sending consolidated IP/MAC-VLAN among sites. Cisco=92s OTV suggests using IS/IS to send one site=92s IP/MAC-VLAN mapping to all other sites which belong to the same subnet. Jun= iper=92s Ethernet VPN suggests using BGP to send one site=92s IP/MAC-VLAN mapping to all other sites which belong to the same subnet.

=A0

What if each site keeps their hosts=92 MAC a= ddress as private? The site gateway switches (or Top of Rack switches) can proxy the = ARP requests from other sites with its own MAC address. By doing so, site gatew= ay switch (or Top of Rack Switches) only need to send a group of IP addresses = together with its own MAC to all other sites. Since IP addresses can be summarized, = the amount of information to be sent to other sites is much smaller. Even if after man= y rounds of moving around and the IP addresses in one site can=92t be summari= zed anymore, you still get the saving by not sending all the MAC addresses.

=A0

If Layer 2 switches enable Source Address le= arning only from ports towards server, but disable learning from ports towards network side, then all hosts can still use their individual SA for data frames. By doing = so, Source Addresses of data frames are all original, which will not break DHCP behavior.

=A0

Your comments are appreciated. I think writi= ng a draft on this idea is worthwhile.

=A0

Regards, Linda Dunbar

=A0

=A0


_______________________________________________
armd mailing list
armd@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/armd


--0016e65ae5a082ae0204909b223b-- From ldunbar@huawei.com Mon Sep 20 10:01:59 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4C63A6AF2 for ; Mon, 20 Sep 2010 10:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.369, 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 XnMHZzYt9tsV for ; Mon, 20 Sep 2010 10:01:48 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id A0FC53A6AFC for ; Mon, 20 Sep 2010 09:57: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 <0L9200C171S14Y@usaga02-in.huawei.com> for armd@ietf.org; Mon, 20 Sep 2010 09:57:38 -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 <0L92000KP1S14W@usaga02-in.huawei.com> for armd@ietf.org; Mon, 20 Sep 2010 09:57:37 -0700 (PDT) Date: Mon, 20 Sep 2010 11:57:37 -0500 From: Linda Dunbar In-reply-to: To: 'Ron Cohen' Message-id: <00c001cb58e4$edc74b40$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_7P5e4b/mTKMagIPp6dLs6Q)" Thread-index: ActX7jTOTKbRExxdQQC5nJavo8+GuAA6TRog References: <00e201cb5395$49fb0050$4b0c7c0a@china.huawei.com> Cc: armd@ietf.org Subject: Re: [armd] some ideas on ARP optimization for one broadcast domain spanning across multiple sites X-BeenThere: armd@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, 20 Sep 2010 17:01:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_7P5e4b/mTKMagIPp6dLs6Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Ron, Thank you for the suggestions. Detailed answers to your questions are inserted below: _____ From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Ron Cohen Sent: Sunday, September 19, 2010 6:31 AM To: Linda Dunbar Cc: armd@ietf.org Subject: Re: [armd] some ideas on ARP optimization for one broadcast domain spanning across multiple sites Hi Linda, My comments: 1. Need to take into account more than one gateway per site, for both resiliency and load balancing. [Linda] Yes, that is a good suggestion. 2. I'm not convinced that the complexity of summarizing parts-of subnets is worth the potential bandwidth saving. We need to look at the entire protocol (including updates upon move etc.) to determine whether summarizing doesn't consume more bandwidth due to triggered updates. [Linda] Bandwidth saving is not the main issue. We are suggesting the possibility of having private MAC addresses. Just like private IP address, each domain (or all hosts under one Top of Rack switch) have a handful of "public" MAC addresses which are used by core or other TORs. Under this scenario, the MAC addresses to be exposed to other domains are the public MAC addresses. The private MAC addresses are solely relevant within the domain. This is just a primitive idea. We can discuss merit of doing this. 3. It is not clear from the proposal how each gateway learns the IP addresses of connected hosts. That is, if a new VM boots up, how is the gateway notified/learns of its IP/MAC assignment. How does aging work, etc. [Linda] When a VM boots up, the very first thing most VMs do is to send a gratuitous ARP to announce them. The latest IEEE802.1Qag will require VMs to send a port profile to the directly attached switch. 4. Please explain which DHCP concerns you refer to and why the proposal of disabling source learning from uplink ports solves it. [Linda] At the ARMD bar BOF in 78th IETF, researchers from Cambridge University presented MOOSE architecture, which requires the first (or directly attached) switch to replace both SA and DA. Internet AD Ralph Droms commented that the host's SA needs to stay with the data frame, otherwise, DHCP will be broken. Thank you Ron On Tue, Sep 14, 2010 at 12:44 AM, Linda Dunbar wrote: Dear All, Just want to check your feedback on some ideas to reduce the ARP (IPv4) storm within one broadcast domain. Many hosts frequently send out gratuitous ARP for all other hosts in the broadcast domain to be aware of correct IP/MAC-VLAN mapping for the host. When one subnet is across multiple sites (or across many top of rack switches), there are several proposals on sending consolidated IP/MAC-VLAN among sites. Cisco's OTV suggests using IS/IS to send one site's IP/MAC-VLAN mapping to all other sites which belong to the same subnet. Juniper's Ethernet VPN suggests using BGP to send one site's IP/MAC-VLAN mapping to all other sites which belong to the same subnet. What if each site keeps their hosts' MAC address as private? The site gateway switches (or Top of Rack switches) can proxy the ARP requests from other sites with its own MAC address. By doing so, site gateway switch (or Top of Rack Switches) only need to send a group of IP addresses together with its own MAC to all other sites. Since IP addresses can be summarized, the amount of information to be sent to other sites is much smaller. Even if after many rounds of moving around and the IP addresses in one site can't be summarized anymore, you still get the saving by not sending all the MAC addresses. If Layer 2 switches enable Source Address learning only from ports towards server, but disable learning from ports towards network side, then all hosts can still use their individual SA for data frames. By doing so, Source Addresses of data frames are all original, which will not break DHCP behavior. Your comments are appreciated. I think writing a draft on this idea is worthwhile. Regards, Linda Dunbar _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd --Boundary_(ID_7P5e4b/mTKMagIPp6dLs6Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Ron,

 

Thank you for the suggestions.

Detailed answers to your questions are inserted below:

 


From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Ron Cohen
Sent: Sunday, September 19, 2010 6:31 AM
To: Linda Dunbar
Cc: armd@ietf.org
Subject: Re: [armd] some ideas on ARP optimization for one broadcast domain spanning across multiple sites

 

Hi Linda,

 

My comments:

 

1. Need to take into account more than one gateway per site, for both resiliency and load balancing. 

[Linda] Yes, that is a good suggestion.

 

2. I'm not convinced that the complexity of summarizing parts-of subnets is worth the potential bandwidth saving. We need to look at the entire protocol (including updates upon move etc.) to determine whether summarizing doesn't consume more bandwidth due to triggered updates.

[Linda] Bandwidth saving is not the main issue. We are suggesting the possibility of having private MAC addresses. Just like private IP address, each domain (or all hosts under one Top of Rack switch) have a handful of “public” MAC addresses which are used by core or other TORs. Under this scenario, the MAC addresses to be exposed to other domains are the public MAC addresses. The private MAC addresses are solely relevant within the domain.

 

This is just a primitive idea. We can discuss merit of doing this.

 

3. It is not clear from the proposal how each gateway learns the IP addresses of connected hosts. That is, if a new VM boots up, how is the gateway notified/learns of its IP/MAC assignment. How does aging work, etc.

 

[Linda]  When a VM boots up, the very first thing most VMs do is to send a gratuitous ARP to announce them.

 

The latest IEEE802.1Qag will require VMs to send a port profile to the directly attached switch.

 

4. Please explain which DHCP concerns you refer to and why the proposal of disabling source learning from uplink ports solves it. 

[Linda] At the ARMD bar BOF in 78th IETF, researchers from Cambridge University presented MOOSE architecture, which requires the first (or directly attached) switch to replace both SA and DA. Internet AD Ralph Droms commented that the host’s SA needs to stay with the data frame, otherwise, DHCP will be broken.

 

Thank you

Ron

 

 

On Tue, Sep 14, 2010 at 12:44 AM, Linda Dunbar <ldunbar@huawei.com> wrote:

Dear All,

 

Just want to check your feedback on some ideas to reduce the ARP (IPv4) storm within one broadcast domain.

 

Many hosts frequently send out gratuitous ARP for all other hosts in the broadcast domain to be aware of correct IP/MAC-VLAN mapping for the host. When one subnet is across multiple sites (or across many top of rack switches), there are several proposals on sending consolidated IP/MAC-VLAN among sites. Cisco’s OTV suggests using IS/IS to send one site’s IP/MAC-VLAN mapping to all other sites which belong to the same subnet. Juniper’s Ethernet VPN suggests using BGP to send one site’s IP/MAC-VLAN mapping to all other sites which belong to the same subnet.

 

What if each site keeps their hosts’ MAC address as private? The site gateway switches (or Top of Rack switches) can proxy the ARP requests from other sites with its own MAC address. By doing so, site gateway switch (or Top of Rack Switches) only need to send a group of IP addresses together with its own MAC to all other sites. Since IP addresses can be summarized, the amount of information to be sent to other sites is much smaller. Even if after many rounds of moving around and the IP addresses in one site can’t be summarized anymore, you still get the saving by not sending all the MAC addresses.

 

If Layer 2 switches enable Source Address learning only from ports towards server, but disable learning from ports towards network side, then all hosts can still use their individual SA for data frames. By doing so, Source Addresses of data frames are all original, which will not break DHCP behavior.

 

Your comments are appreciated. I think writing a draft on this idea is worthwhile.

 

Regards, Linda Dunbar

 

 


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

 

--Boundary_(ID_7P5e4b/mTKMagIPp6dLs6Q)-- From ronc.ntear@gmail.com Sun Sep 26 07:32:36 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ADED3A6B37 for ; Sun, 26 Sep 2010 07:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.647 X-Spam-Level: X-Spam-Status: No, score=-100.647 tagged_above=-999 required=5 tests=[AWL=1.329, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 KMGf17J2jPkM for ; Sun, 26 Sep 2010 07:32:34 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 944633A6AA2 for ; Sun, 26 Sep 2010 07:32:34 -0700 (PDT) Received: by qyk2 with SMTP id 2so4578586qyk.10 for ; Sun, 26 Sep 2010 07:33:11 -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=NJd155fTBL6vP6QXg9mFLVti1/yEWO0TgMKQ3j36iAk=; b=kJBNZSzLwj6aqaL3Wq5Ot6cds1q5Rwnynl2mJchlFKDmwOb/1vbUUTkeZMtE5rI6uF mdCrvmK+XcrZJZd2i1T7PNOLKTm/cDjyTl244ScqxrhV3hIa3LaWH9HCSnc0/tq5IIGX YAl9XeD27u7czspR+RXxlRpPu8NVbNA5a7fBo= 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=Tam1J4a+P8oThwLnSfh4umZVt96FGt5EsA8Mk5AbyvGPAa2B71NVwEamSIz33y5NbS h6iDNVz8ssuV/c91glINW76Y0nBLBuA/qG/zJ3i2izw0f7s9i95AW/1PN9mWYwW2uU7T VCvlUxR6kvnWo6bQIUrgpzQ77k4k2aM4VPIPA= MIME-Version: 1.0 Received: by 10.229.224.146 with SMTP id io18mr4591705qcb.171.1285511590824; Sun, 26 Sep 2010 07:33:10 -0700 (PDT) Sender: ronc.ntear@gmail.com Received: by 10.220.178.7 with HTTP; Sun, 26 Sep 2010 07:33:10 -0700 (PDT) In-Reply-To: <00c001cb58e4$edc74b40$4b0c7c0a@china.huawei.com> References: <00e201cb5395$49fb0050$4b0c7c0a@china.huawei.com> <00c001cb58e4$edc74b40$4b0c7c0a@china.huawei.com> Date: Sun, 26 Sep 2010 16:33:10 +0200 X-Google-Sender-Auth: tZIlvPubf0Xqkel9ZmYUyJDFrTk Message-ID: From: Ron Cohen To: Linda Dunbar Content-Type: multipart/alternative; boundary=0016364ec9cab9cb7c04912a7d0d Cc: armd@ietf.org Subject: Re: [armd] some ideas on ARP optimization for one broadcast domain spanning across multiple sites X-BeenThere: armd@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: Sun, 26 Sep 2010 14:32:36 -0000 --0016364ec9cab9cb7c04912a7d0d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Linda, The potential conflict with DHCP that I'm familiar with is that DHCP client= s usually send an ARP request to figure out whether an IP addressed offered t= o them is indeed free. Some implementation place 0.0.0.0 as the IP address of the requesting node in these situations. If a proxy-ARP server answers such an ARP request, the DHCP client will assume the address is already taken an= d decline the DHCP offer. I was hoping that Ralph would clarify his concern with breaking DHCP. However unless we can all understand the details of the potential problem I don't see any other choice but to ignore it. Best, Ron On Mon, Sep 20, 2010 at 6:57 PM, Linda Dunbar wrote: > Ron, > > > > Thank you for the suggestions. > > Detailed answers to your questions are inserted below: > > > ------------------------------ > > *From:* armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] *On Behalf O= f > *Ron Cohen > *Sent:* Sunday, September 19, 2010 6:31 AM > *To:* Linda Dunbar > *Cc:* armd@ietf.org > *Subject:* Re: [armd] some ideas on ARP optimization for one broadcast > domain spanning across multiple sites > > > > Hi Linda, > > > > My comments: > > > > 1. Need to take into account more than one gateway per site, for both > resiliency and load balancing. > > [Linda] Yes, that is a good suggestion. > > > > 2. I'm not convinced that the complexity of summarizing parts-of subnets = is > worth the potential bandwidth saving. We need to look at the entire proto= col > (including updates upon move etc.) to determine whether summarizing doesn= 't > consume more bandwidth due to triggered updates. > > [Linda] Bandwidth saving is not the main issue. We are suggesting the > possibility of having private MAC addresses. Just like private IP address= , > each domain (or all hosts under one Top of Rack switch) have a handful of > =93public=94 MAC addresses which are used by core or other TORs. Under th= is > scenario, the MAC addresses to be exposed to other domains are the public > MAC addresses. The private MAC addresses are solely relevant within the > domain. > > > > This is just a primitive idea. We can discuss merit of doing this. > > > > 3. It is not clear from the proposal how each gateway learns the IP > addresses of connected hosts. That is, if a new VM boots up, how is the > gateway notified/learns of its IP/MAC assignment. How does aging work, et= c. > > > > [Linda] When a VM boots up, the very first thing most VMs do is to send = a > gratuitous ARP to announce them. > > > > The latest IEEE802.1Qag will require VMs to send a port profile to the > directly attached switch. > > > > 4. Please explain which DHCP concerns you refer to and why the proposal o= f > disabling source learning from uplink ports solves it. > > [Linda] At the ARMD bar BOF in 78th IETF, researchers from Cambridge > University presented MOOSE architecture, which requires the first (or > directly attached) switch to replace both SA and DA. Internet AD Ralph Dr= oms > commented that the host=92s SA needs to stay with the data frame, otherwi= se, > DHCP will be broken. > > > > Thank you > > Ron > > > > > > On Tue, Sep 14, 2010 at 12:44 AM, Linda Dunbar wrote= : > > Dear All, > > > > Just want to check your feedback on some ideas to reduce the ARP (IPv4) > storm within one broadcast domain. > > > > Many hosts frequently send out gratuitous ARP for all other hosts in the > broadcast domain to be aware of correct IP/MAC-VLAN mapping for the host. > When one subnet is across multiple sites (or across many top of rack > switches), there are several proposals on sending consolidated IP/MAC-VLA= N > among sites. Cisco=92s OTV suggests using IS/IS to send one site=92s IP/M= AC-VLAN > mapping to all other sites which belong to the same subnet. Juniper=92s > Ethernet VPN suggests using BGP to send one site=92s IP/MAC-VLAN mapping = to > all other sites which belong to the same subnet. > > > > What if each site keeps their hosts=92 MAC address as private? The site > gateway switches (or Top of Rack switches) can proxy the ARP requests fro= m > other sites with its own MAC address. By doing so, site gateway switch (o= r > Top of Rack Switches) only need to send a group of IP addresses together > with its own MAC to all other sites. Since IP addresses can be summarized= , > the amount of information to be sent to other sites is much smaller. Even= if > after many rounds of moving around and the IP addresses in one site can= =92t be > summarized anymore, you still get the saving by not sending all the MAC > addresses. > > > > If Layer 2 switches enable Source Address learning only from ports toward= s > server, but disable learning from ports towards network side, then all ho= sts > can still use their individual SA for data frames. By doing so, Source > Addresses of data frames are all original, which will not break DHCP > behavior. > > > > Your comments are appreciated. I think writing a draft on this idea is > worthwhile. > > > > Regards, Linda Dunbar > > > > > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > > --0016364ec9cab9cb7c04912a7d0d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Linda,

The potential conflict with D= HCP that I'm familiar with is that DHCP clients usually send an ARP req= uest to figure out whether an IP addressed offered to them is indeed free. = Some implementation place 0.0.0.0 as the IP address of the requesting node = in these situations. If a proxy-ARP server answers such an ARP request, the= DHCP client will assume the address is already taken and decline the DHCP = offer.

I was hoping that Ralph would clarify his concern with = breaking DHCP. However unless we can all understand the details of the pote= ntial problem I don't see any other choice but to ignore it.=A0

Best,
Ron


On Mon, Sep 20, 2010 at 6:57 PM, Linda Dunbar <ldunbar@huawei.com&= gt; wrote:

Ron,

=A0<= /p>

Thank you for the = suggestions.

Detailed answers t= o your questions are inserted below:

=A0<= /p>


From: armd-bounces@iet= f.org [mailto:armd-bounces@ietf.org] On Behalf = Of Ron Cohen
Sent: Sunday, September 19, = 2010 6:31 AM
To: Linda Dunbar
Cc: armd@ietf.org
Subject: Re: [armd] some ide= as on ARP optimization for one broadcast domain spanning across multiple sites

=A0

Hi Linda,

=A0

My comments:

=A0

1. Need to take into acco= unt more than one gateway per site, for both resiliency and load balancing.=A0

[Linda] Yes, that is a goo= d suggestion.

=A0<= /p>

2. I'm not convinced = that the complexity of summarizing parts-of subnets is worth the potential bandwidth saving. We ne= ed to look at the entire protocol (including updates upon move etc.) to determ= ine whether summarizing doesn't consume more bandwidth due to triggered upd= ates.

[Linda] Band= width saving is not the main issue. We are suggesting the possibility of having private MAC addresses. J= ust like private IP address, each domain (or all hosts under one Top of Rack switch) have a handful of =93public=94 MAC addresses which are used by core or other TORs. Under this scenario, the MAC addresses to be exposed to other domains are the public MAC addresses. The private MAC addresses are solely relevant within the domain.

=A0<= /p>

This is just a pri= mitive idea. We can discuss merit of doing this.

=A0

3. It is not clear from t= he proposal how each gateway learns the IP addresses of connected hosts. That is, if a new VM boots up, = how is the gateway notified/learns of its IP/MAC assignment. How does aging wor= k, etc.

=A0<= /p>

[Linda] =A0W= hen a VM boots up, the very first thing most VMs do is to send a gratuitous ARP to announce them.

=A0<= /p>

The latest IEEE802= .1Qag will require VMs to send a port profile to the directly attached switch.

=A0

4.=A0Please explain which= DHCP concerns you refer to and why the proposal of disabling source learning from uplink ports solv= es it.=A0

[Linda] At the ARMD bar BO= F in 78th IETF, researchers from Cambridge University presented MOOSE architecture, w= hich requires the first (or directly attached) switch to replace both SA and DA.= Internet AD Ralph Droms commented that the host=92s SA needs to stay with the data frame, otherwise, DHCP will be broken.

=A0<= /p>

Thank you

Ron

=A0

=A0

On Tue, Sep 14, 2010 at 1= 2:44 AM, Linda Dunbar <ldunbar@huawei.com> wrote:

Dear All, =

=A0=

Just want to chec= k your feedback on some ideas to reduce the ARP (IPv4) storm within one broadcast domain.

=A0=

Many hosts freque= ntly send out gratuitous ARP for all other hosts in the broadcast domain to be aware of correct IP/MAC-VLAN mapping fo= r the host. When one subnet is across multiple sites (or across many top of r= ack switches), there are several proposals on sending consolidated IP/MAC-VLAN among sites. Cisco=92s OTV suggests using IS/IS to send one site=92s IP/MAC-VLAN mapping to all other sites which belong to the same subnet. Juniper=92s Ethernet VPN suggests using BGP to send one site=92s IP/MAC-VLAN mapping to all other sites which belong to the same subnet.

=A0=

What if each site= keeps their hosts=92 MAC address as private? The site gateway switches (or Top of Rack switches) can proxy the = ARP requests from other sites with its own MAC address. By doing so, site gatew= ay switch (or Top of Rack Switches) only need to send a group of IP addresses together with its own MAC to all other sites. Since IP addresses can be summarized, the amount of information to be sent to other sites is much smaller. Even if after many rounds of moving around and the IP addresses in= one site can=92t be summarized anymore, you still get the saving by not sending all the MAC addresses.

=A0=

If Layer 2 switch= es enable Source Address learning only from ports towards server, but disable learning from ports towards network side, then all hosts can still use their individual SA for data frames. By doing = so, Source Addresses of data frames are all original, which will not break DHCP behavior.

=A0=

Your comments are= appreciated. I think writing a draft on this idea is worthwhile.

=A0=

Regards, Linda Du= nbar

=A0=

=A0=


_______________________________________________
armd mailing list
armd@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/armd

=A0


--0016364ec9cab9cb7c04912a7d0d--