From thomas.morin@orange.com Thu Mar 1 07:48:47 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E909221E81FF for ; Thu, 1 Mar 2012 07:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRcf4KFj0CJS for ; Thu, 1 Mar 2012 07:48:47 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3886421E81F2 for ; Thu, 1 Mar 2012 07:48:47 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B7E33E303A7 for ; Thu, 1 Mar 2012 16:49:48 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B245BE303A6 for ; Thu, 1 Mar 2012 16:49:48 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 16:48:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.193.21.179 ([10.193.21.179]) by ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) via Exchange Front-End Server owa.rd.francetelecom.fr ([10.192.128.53]) with Microsoft Exchange Server HTTP-DAV ; Thu, 1 Mar 2012 15:48:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Content-class: urn:content-classes:message Date: Thu, 1 Mar 2012 16:49:14 +0100 Message-ID: In-Reply-To: <201202151407.q1FE7cWW022379@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [armd] Multicast in the data center [was Re: address resolution requirement from hosts to overlay edge nodes. Any opinion?] Thread-Index: Acz3wskxMVduSQ2fTTGuY7xPO9vfnQ== References: <7AE6A4247B044C4ABE0A5B6BF427F8E291E1A5@dfweml503-mbx> <60C093A41B5E45409A19D42CF7786DFD522A9BE1F1@EUSAACMS0703.eamcs.ericsson.se> <201202151407.q1FE7cWW022379@cichlid.raleigh.ibm.com> From: To: X-OriginalArrivalTime: 01 Mar 2012 15:48:46.0140 (UTC) FILETIME=[C9641FC0:01CCF7C2] Subject: Re: [armd] Multicast in the data center [was Re: address resolution requirement from hosts to overlay edge nodes. Any opinion?] X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 15:48:48 -0000 SGkgVGhvbWFzLA0KDQpUaG9tYXMgTmFydGVuIDoNCj4gTXkgaW1wcmVzc2lvbiBpcyB0aGF0IG1h bnkgZGF0YSBjZW50ZXJzIGRvIG5vdCBlbmFibGUgSVAgbXVsdGljYXN0IG9uIA0KPiB0aGVpciBy b3V0ZXJzLiBUaGF0IG1lYW5zIHlvdSBjYW4gdXNlIGxpbmstbG9jYWwgbXVsdGljYXN0ICh3aGlj aCANCj4gd29ya3MgZmluZSB3aXRoaW4gb25lIElQIHN1Ym5ldCBhbmQgZG9lc24ndCByZWFsbHkg aGF2ZSBzY2FsaW5nIGlzc3VlcykuDQoNCkp1c3QgYSBzaWRlIG5vdGU6IHVzaW5nIGxpbmstbG9j YWwgbXVsdGljYXN0IG92ZXIgYSAoVilMQU4gbWF5IGltcGx5IHRoZSANCnVzZSBvZiBJR01QIHNu b29waW5nLCB3aGljaCBtYXkgbm90IGJlIGVhc2llciB0byBtYW5hZ2UgdGhhbiBJUCANCm11bHRp Y2FzdCAodGhpcyBpcyBhIGV1cGhlbWlzbSkgYW5kIGRvZXMgaW1wbHkgcGVyLW11bHRpY2FzdC1m bG93IHN0YXRlIA0KbWFpbnRlbmFuY2Ugb24gc3dpdGNoZXMsIGxpa2VseSB0byBhbHNvIGludm9s dmUgc2ltaWxhciBzY2FsaW5nIA0KY2hhbGxlbmdlIChzdGF0ZSBncm93aW5nIGxpbmVhcmx5IHdp dGggdGhlIGFtb3VudCBvZiBmbG93cykuDQoNCi1UaG9tYXMNCg0K From linda.dunbar@huawei.com Thu Mar 1 08:43:55 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F8621E828B for ; Thu, 1 Mar 2012 08:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksh714Ihw5ED for ; Thu, 1 Mar 2012 08:43:55 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C658E21E8286 for ; Thu, 1 Mar 2012 08:43:54 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEA33470; Thu, 01 Mar 2012 11:43:54 -0500 (EST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Mar 2012 08:43:07 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 1 Mar 2012 08:42:48 -0800 From: Linda Dunbar To: "Gary Berger (gaberger)" , Vishwas Manral Thread-Topic: Multi-homing in data center Thread-Index: AQHM98pVjFy5PNM2Z0itrt9VXTKwig== Date: Thu, 1 Mar 2012 16:42:40 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F632E26CF0@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F610CAB74A@dfweml503-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F632E2495E@dfweml505-mbx> <151901ccf660$5175f500$f461df00$@mac.com> <4159FD35-265B-4A76-A858-D6AE0884290A@cisco.com> In-Reply-To: <4159FD35-265B-4A76-A858-D6AE0884290A@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: B82k DEHR DGVz F5q5 GSTy GwZD OtKE QBN2 QmgO SYNC WlLn ZOX0 azwd ieIg j7Tg kb+/; 4; YQByAG0AZABAAGkAZQB0AGYALgBvAHIAZwA7AGcAYQBiAGUAcgBnAGUAcgBAAGMAaQBzAGMAbwAuAGMAbwBtADsAbQBrAHMAbQBpAHQAaABAAG0AYQBjAC4AYwBvAG0AOwB2AGkAcwBoAHcAYQBzAC4AaQBlAHQAZgBAAGcAbQBhAGkAbAAuAGMAbwBtAA==; Sosha1_v1; 7; {55DABCE3-56C6-407F-9A58-EDB5063D5C27}; bABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 01 Mar 2012 16:42:40 GMT; TQB1AGwAdABpAC0AaABvAG0AaQBuAGcAIABpAG4AIABkAGEAdABhACAAYwBlAG4AdABlAHIA x-cr-puzzleid: {55DABCE3-56C6-407F-9A58-EDB5063D5C27} x-originating-ip: [10.192.11.97] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F632E26CF0dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "armd@ietf.org" Subject: [armd] Multi-homing in data center X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 16:43:56 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F632E26CF0dfweml505mbx_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2FyeSwNCg0KRG9lcyB0aGUg4oCcbXVsdGktaG9taW5n4oCdIHJlZmVycmVkIGluIHlvdXIgc3Rh dGVtZW50ICBtZWFuIHRoYXQgZWFjaCBzZXZlciBoYXZlIG11bHRpcGxlIHVwbGlua3MgKHNheSBk dWFsKSB0byBkaWZmZXJlbnQgVG9SIHN3aXRjaGVzIGluIGRhdGEgY2VudGVyPyBJcyBpdCBtb3Jl IGNvbW1vbiB0aGFuIHRoZSBzaW5nbGUgdXBsaW5rIGluIERhdGEgQ2VudGVyIGVudmlyb25tZW50 Pw0KDQpMaW5kYQ0KDQpGcm9tOiBHYXJ5IEJlcmdlciAoZ2FiZXJnZXIpIFttYWlsdG86Z2FiZXJn ZXJAY2lzY28uY29tXQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyOSwgMjAxMiA2OjI0IFBN DQpUbzogVmlzaHdhcyBNYW5yYWwNCkNjOiBNaWNoYWVsIFNtaXRoOyBMaW5kYSBEdW5iYXI7IGFy bWRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbYXJtZF0gaG93IGRvZXMgImRyYWZ0LXNyaWRoYXJh bi12aXJ0dWFsaXphdGlvbi1udmdyZS0wMCJhZHZlcnRpc2UgaXRzIGV4dGVybmFsIGZhY2luZyBo b3N0cycgSVAgYWRkcmVzc2VzIHRvIGV4dGVybmFsIHdvcmxkPw0KW3NuaXBdDQpJIHRoaW5rIHdl IGFyZSBqdXN0IHNpbXBseSBzYXlpbmcgdGhhdCBtdWx0aS1ob21pbmcgc2hvdWxkIGJlIGEgbmF0 aXZlIGFyY2hpdGVjdHVyYWwgZWxlbWVudCByZWdhcmRsZXNzIHRvIHdoaWNoIG5ldHdvcmsgeW91 IGF0dGFjaCB0by4NCg0KDQpHDQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F632E26CF0dfweml505mbx_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1z dHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1 aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ R2FyeSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+RG9lcyB0aGUg4oCcbXVsdGktaG9taW5n4oCdIHJlZmVycmVkIGlu IHlvdXIgc3RhdGVtZW50ICZuYnNwO21lYW4gdGhhdCBlYWNoIHNldmVyIGhhdmUgbXVsdGlwbGUg dXBsaW5rcyAoc2F5IGR1YWwpIHRvIGRpZmZlcmVudCBUb1Igc3dpdGNoZXMgaW4gZGF0YSBjZW50 ZXI/IElzIGl0IG1vcmUNCiBjb21tb24gdGhhbiB0aGUgc2luZ2xlIHVwbGluayBpbiBEYXRhIENl bnRlciBlbnZpcm9ubWVudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpbmRhPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEdhcnkgQmVyZ2VyIChnYWJlcmdlcikgW21haWx0bzpnYWJl cmdlckBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAy OSwgMjAxMiA2OjI0IFBNPGJyPg0KPGI+VG86PC9iPiBWaXNod2FzIE1hbnJhbDxicj4NCjxiPkNj OjwvYj4gTWljaGFlbCBTbWl0aDsgTGluZGEgRHVuYmFyOyBhcm1kQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbYXJtZF0gaG93IGRvZXMgJnF1b3Q7ZHJhZnQtc3JpZGhhcmFuLXZp cnR1YWxpemF0aW9uLW52Z3JlLTAwJnF1b3Q7YWR2ZXJ0aXNlIGl0cyBleHRlcm5hbCBmYWNpbmcg aG9zdHMnIElQIGFkZHJlc3NlcyB0byBleHRlcm5hbCB3b3JsZD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPltzbmlwXTwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPkkgdGhpbmsgd2UgYXJlIGp1c3Qgc2lt cGx5IHNheWluZyB0aGF0IG11bHRpLWhvbWluZyBzaG91bGQgYmUgYSBuYXRpdmUgYXJjaGl0ZWN0 dXJhbCBlbGVtZW50IHJlZ2FyZGxlc3MgdG8gd2hpY2ggbmV0d29yayB5b3UgYXR0YWNoIHRvLiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPkc8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F632E26CF0dfweml505mbx_-- From gaberger@cisco.com Thu Mar 1 08:48:51 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7B721E82B5 for ; Thu, 1 Mar 2012 08:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.866 X-Spam-Level: X-Spam-Status: No, score=-8.866 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22Ro4Zjb2IEd for ; Thu, 1 Mar 2012 08:48:50 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id E0A3921E82B3 for ; Thu, 1 Mar 2012 08:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gaberger@cisco.com; l=11175; q=dns/txt; s=iport; t=1330620529; x=1331830129; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=ChRFZyJkIQ3Yv4PNiWlkQ3JazMu7SG7dk4CQnOerDNs=; b=FS4CsVsjJWK4Z0wF0TzoE/Z6yXSnfLCgT+USHTFlJMvIR8Xzx6IcjUv6 FfjvQCzIhPe92p/6Ts41TVBAQqKOfQ2SAoqhYWCxSSADvMDOnOiSmIpbC mwqpLdKXFClKpsxhmW4vYexfrJLFlcwY14aiRTTC33wuJtc3ks16X5Yv0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAGABWoT09Io8UY/2dsb2JhbABDgkRCsAyBdYF9AQEBAwESARoQPAUOCBEDAQEBKCglCQgGAQ0FIodfBZl8AZ55iRuDaxUMSA4BCQEJAoRkGA4DAzQOEQQUgzEEiBwzjGyFX4U8h3U X-IronPort-AV: E=Sophos;i="4.73,511,1325462400"; d="scan'208,217";a="6824022" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 01 Mar 2012 16:48:47 +0000 Received: from [10.82.240.250] (rtp-vpn2-250.cisco.com [10.82.240.250]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q21Gmfko008864; Thu, 1 Mar 2012 16:48:44 GMT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Thu, 01 Mar 2012 11:48:45 -0500 From: Gary Berger To: Linda Dunbar , Vishwas Manral Message-ID: Thread-Topic: Multi-homing in data center In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F632E26CF0@dfweml505-mbx> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3413447331_49171581" Cc: "armd@ietf.org" Subject: Re: [armd] Multi-homing in data center X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 16:48:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3413447331_49171581 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I just characterize mobility as the need to move possible a state-full service from one network to another without topological restrictions.. You are leaving one network and joining another that could mean one interface t= o another, WiFi to GSM or network to network. I am just saying multi-homing i= s the canonical example.. -g From: Linda Dunbar Date: Thu, 1 Mar 2012 16:42:40 +0000 To: Gary Berger , Vishwas Manral Cc: Michael Smith , "armd@ietf.org" Subject: Multi-homing in data center > Gary,=20 > =20 > Does the =B3multi-homing=B2 referred in your statement mean that each sever = have > multiple uplinks (say dual) to different ToR switches in data center? Is = it > more common than the single uplink in Data Center environment? > =20 > Linda > =20 >=20 > From: Gary Berger (gaberger) [mailto:gaberger@cisco.com] > Sent: Wednesday, February 29, 2012 6:24 PM > To: Vishwas Manral > Cc: Michael Smith; Linda Dunbar; armd@ietf.org > Subject: Re: [armd] how does > "draft-sridharan-virtualization-nvgre-00"advertise its external facing ho= sts' > IP addresses to external world? > [snip] >=20 > I think we are just simply saying that multi-homing should be a native > architectural element regardless to which network you attach to. >=20 >=20 >=20 > G >=20 > =20 --B_3413447331_49171581 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
I just characteriz= e mobility as the need to move possible a state-full service from one networ= k to another without topological restrictions.. You are leaving one network = and joining another that could mean one interface to another, WiFi to GSM or= network to network. I am just saying multi-homing is the canonical example.= .

-g


From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Thu, 1 Mar 2012 16:42:40 +0000
To: Gary Berger <gaberger@cisco.com>, Vishwas Manral <vishwas.ietf@gmail.com>
Cc: Michael Smith <mksmith= @mac.com>, "armd@ietf.org" <armd@ietf.org>
Subject: Multi-homing in data center

Gary,

 =

Does the “multi-homing&= #8221; referred in your statement  mean that each sever have multiple u= plinks (say dual) to different ToR switches in data center? Is it more common than the single uplink in Data Center environment?

 

Linda

 

From= : Gary Berger (gaberger) [mailto:gaberge= r@cisco.com]
Sent: Wednesday, February 29, 2012 6:24 PM
To: Vishwas= Manral
Cc: Michael Smith; Linda Dunbar; armd@ietf.org
Subject: Re: [armd] how does "draft-sridha= ran-virtualization-nvgre-00"advertise its external facing hosts' IP addresse= s to external world?

<= span style=3D"color:#1F497D">[snip]

I think we are just simply saying that multi-homing= should be a native architectural element regardless to which network you at= tach to. 



=

G

 

--B_3413447331_49171581-- From mksmith@mac.com Thu Mar 1 13:20:23 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA2221E8085 for ; Thu, 1 Mar 2012 13:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Uj57qaDojTv for ; Thu, 1 Mar 2012 13:20:17 -0800 (PST) Received: from nk11p99mm-asmtpout003.mac.com (nk11p99mm-asmtpout003.mac.com [17.158.233.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2E62921E803E for ; Thu, 1 Mar 2012 13:20:16 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_f2/dNnGhsysTS7MFseepjw)" Received: from adwks52 (unknown [216.211.143.124]) by nk11p03mm-asmtp993.mac.com (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTPSA id <0M0800JSC5XLJZ20@nk11p03mm-asmtp993.mac.com> for armd@ietf.org; Thu, 01 Mar 2012 13:20:11 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-03-01_04:2012-03-01, 2012-03-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1203010209 From: Michael Smith Sender: Michael Smith To: 'Vishwas Manral' , 'Michael Smith' References: <4A95BA014132FF49AE685FAB4B9F17F610CAB74A@dfweml503-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F632E2495E@dfweml505-mbx> <151901ccf660$5175f500$f461df00$@mac.com> In-reply-to: Date: Thu, 01 Mar 2012 13:20:09 -0800 Message-id: <170701ccf7f1$152f1d50$3f8d57f0$@mac.com> X-Mailer: Microsoft Outlook 14.0 Thread-index: AQFBgImgjHc9GOBNhB03d9UiBPUVDgIidqOuAoKhqSYCXK5zlgH0hEGxASKNSNSXHBpIQA== Content-language: en-us Cc: armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world? X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 21:20:23 -0000 This is a multipart message in MIME format. --Boundary_(ID_f2/dNnGhsysTS7MFseepjw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello Vishwas: Yes, an asynchronous event can cause VM movement. The Management Entity is involved in the move, but the move can be to any number of N hosts. As an example: - 3 Hosts with lots of VM's (Host A, Host B, Host C) - Host A has a failure - VM's from Host A are moved to Host B and Host C using the Management Entities internal decision algorithm. Mike From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Wednesday, February 29, 2012 3:32 PM To: Michael Smith Cc: Linda Dunbar; Gary Berger; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world? Hi Michael, Please forgive my ignorance here. I guess what you are saying is that the trigger could be some asynchronous event not initiated by the operator. However isn't the management entity (not manual intervention) involved in actually moving the VM and any storage/ state associated with it? If it is the management entity knows of the movement. Thanks, Vishwas On Tue, Feb 28, 2012 at 1:31 PM, Michael Smith wrote: VM migration can be planned or unplanned, either manually or automatically. In the event of a host failing that is configured for automatic migration, the VM's on the host will migrate to another host as configured. There is some internal intelligence that will allow for best placement of VM's, so they can move to any one of a number of available hosts. Mike From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, February 28, 2012 1:17 PM To: Vishwas Manral; Gary Berger Cc: armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world? Gary, Can you elaborate why "vm migration may not be planned"? I thought that VM migration is orchestrated by some entity, like vMotion or VM managers. Linda From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 27, 2012 6:49 PM To: Gary Berger Cc: Linda Dunbar; Murari Sridharan; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world? Hi Gary, I guess what Linda was trying to say is that the station moves autonomously, however there is some entity moving the VM (which can in turn could move the state on the switch). An example of this could be VEPA. Thanks, Vishwas On Fri, Feb 24, 2012 at 2:22 PM, Gary Berger wrote: Protocols have been developed for IP mobility between Home Gateway and Remote Gateway. The question is if we want similar protocols among TORs or among vSwitches. Handset mobility is random, but VM migration is planned. I wouldn't put such a restriction, vm migration may not be planned.. They both degenerate into a multi-homing problem. Linda From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Thursday, September 22, 2011 9:38 PM To: Murari Sridharan Cc: armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise its external facing hosts' IP addresses to external world? Murari think IP mobility. :) On Thu, Sep 22, 2011 at 5:00 PM, Murari Sridharan wrote: Do you have a scenario in mind? _____ From: Vishwas Manral Sent: 9/22/2011 4:55 PM To: Murari Sridharan Cc: Narasimhan Venkataramaiah; Linda Dunbar; david.black@emc.com; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise its external facing hosts' IP addresses to external world? Hi Murari, Yes that is what I mean. Thanks, Vishwas On Thu, Sep 22, 2011 at 4:50 PM, Murari Sridharan wrote: You mean not an Ethernet frame but some IP payload? From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Thursday, September 22, 2011 4:49 PM To: Murari Sridharan Cc: Narasimhan Venkataramaiah; Linda Dunbar; david.black@emc.com; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise its external facing hosts' IP addresses to external world? Murari, What I am saying is the inner header should be allowed to be L3. >From the diagram you have that does not seem to be the case. Am I missing it totally? Thanks, Vishwas On Thu, Sep 22, 2011 at 4:43 PM, Murari Sridharan wrote: Vishwas, Thanks for the feedback we will definitely consider adding that. I am not sure what you mean by doing L3 instead of L2. We allow any arbitrary virtual topology including L3. Thanks From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Thursday, September 22, 2011 4:19 PM To: Narasimhan Venkataramaiah Cc: Linda Dunbar; Murari Sridharan; david.black@emc.com; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise its external facing hosts' IP addresses to external world? Hi Simha, I see this as the only difference between VXLAN and the NVGRE solution (besides ofcourse that TNI needs to be parsed in the intermediate device for hashing and using lesser number of bytes). I would think you should add it to your draft immediately. With tunneling you consolidate the addresses visible to the core and by providing a hash mechanism, you are providing some level of randomness. The other thing you should look at is L3 (IPv4/ IPv6) over NVGRE instead of L2 alone. I guess it would be the same comment for the VXLAN proposal too. Thanks, Vishwas On Thu, Sep 22, 2011 at 4:11 PM, Narasimhan Venkataramaiah wrote: The draft mentions exactly this as one use of the reserved 8 bits in Section 4. An NVGRE endpoint could use the 8 bits to further distribute flows belonging to a particular TNI and the switches use all 32 bits to get entropy. One step further would be for the switches to get full entropy from the inner Ethernet frame. I take it that your comment would be to make it explicit in the draft. Right? One such example could be to use the upper 8 bits of the Key field to add flow based entropy and tag all the packets from a flow with an entropy label. Simha From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Thursday, September 22, 2011 4:04 PM To: Narasimhan Venkataramaiah Cc: Linda Dunbar; Murari Sridharan; david.black@emc.com; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise its external facing hosts' IP addresses to external world? Hi Simha, The main (Standards Track) change in your draft is the addition of TNI. A question I have is a TNI identifies a particular tenant and all flows from/to a tenant will be hashed to the same path (even with the changes in switches to do hashing to use TNI). Why do you not use the last 8 bits which you have kept as reserved for providing the randomization for hashing flows between same to/from on different paths? Thanks, Vishwas On Sun, Sep 18, 2011 at 11:01 AM, Narasimhan Venkataramaiah wrote: The easiest from the point of view of configuration would be to route everything back through the enterprise - not necessarily the optimal from the enterprise point of view. Are you referring to a scenario where the VMs subnet is split between the cloud and the enterprise? Otherwise I don't see the implication on virtualization as its no different than getting the traffic routed to the enterprise in the first case. Simha ________________________________________ From: armd-bounces@ietf.org [armd-bounces@ietf.org] on behalf of Linda Dunbar [linda.dunbar@huawei.com] Sent: Sunday, September 18, 2011 7:06 AM To: Murari Sridharan; david.black@emc.com; armd@ietf.org Subject: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertise its external facing hosts' IP addresses to external world? Hi Murari, Thank you very much for sharing the presentation. One question: For a host within an Enterprise site which needs to communicate with external peers, the host either uses public IP address which is visible to external peers or uses private IP address which is translated to public address at the Enterprise site's gateway. When this host is moved to "Cloud data center", will the "Cloud Data center" advertise this host address to external peers? Or will all external peers go through enterprise's gateway to reach this host which is no longer residing in the enterprise site? Thanks, Linda > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Murari Sridharan > Sent: Saturday, September 17, 2011 3:02 PM > To: david.black@emc.com; armd@ietf.org > Subject: Re: [armd] soliciting typical network designs for ARMD > > FYI, here is a talk that I gave last week in relation to the nvgre > draft below. > http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-442T > > Thanks > Murari > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > david.black@emc.com > Sent: Friday, September 16, 2011 6:14 AM > To: armd@ietf.org > Subject: Re: [armd] soliciting typical network designs for ARMD > > And two more drafts on this topic: > > http://www.ietf.org/id/draft-mahalingam-dutt-dcops-vxlan-00.txt > http://www.ietf.org/id/draft-sridharan-virtualization-nvgre-00.txt > > The edge switches could be the software switches in hypervisors. > > Thanks, > --David > > > > -----Original Message----- > > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf > > Of Warren Kumari > > Sent: Wednesday, August 31, 2011 3:16 PM > > To: Vishwas Manral > > Cc: armd@ietf.org > > Subject: Re: [armd] soliciting typical network designs for ARMD > > > > > > On Aug 11, 2011, at 11:40 PM, Vishwas Manral wrote: > > > > > Hi Linda/ Anoop, > > > > > > Here is the example of the design I was talking about, as defined > by google. > > > > Just a clarification -- s/as defined by google/as described by > someone > > who happens to work for google/ > > > > W > > > > > http://www.ietf.org/id/draft-wkumari-dcops-l3-vmmobility-00.txt > > > > > > Thanks, > > > Vishwas > > > On Tue, Aug 9, 2011 at 2:50 PM, Anoop Ghanwani > wrote: > > > > > > >>>> > > > (though I think if there was a standard way to map Multicast MAC to > > > Multicast IP, they could > > probably use such a standard mechanisms). > > > >>>> > > > > > > They can do that, but then this imposes requirements on the > > > equipment to be able to do multicast forwarding, and even if does, > > > because of pruning requirements the number of groups would be very > > > large. The average data center switch probably won't handle that > > > many groups. > > > > > > On Tue, Aug 9, 2011 at 2:41 PM, Vishwas Manral > wrote: > > > Hi Anoop, > > > > > > From what I know they do not use Multicast GRE (I hear the extra 4 > > > bytes in the GRE header is a > > proprietery extension). > > > > > > I think a directory based mechanism is what is used (though I think > > > if there was a standard way to > > map Multicast MAC to Multicast IP, they could probably use such a > standard mechanisms). > > > > > > Thanks, > > > Vishwas > > > On Tue, Aug 9, 2011 at 2:03 PM, Anoop Ghanwani > wrote: > > > Hi Vishwas, > > > > > > How do they get multicast through the network in that case? > > > Are they planning to use multicast GRE, or just use directory based > > > lookups and not worry about multicast applications for now? > > > > > > Anoop > > > > > > On Tue, Aug 9, 2011 at 1:27 PM, Vishwas Manral > wrote: > > > Hi Linda, > > > > > > The data packets can be tunnelled at the ToR over say a GRE packet > > > and the core is a Layer-3 core > > (except for the downstream ports). So we could have encapsulation/ > > decapsulation of L2 over GRE at the ToR. > > > > > > The very same thing can be done at the hypervisor layer too, in > > > which case the entire DC network > > would look like a Layer-3 flat network including the ToR to server > > link and the hypervisor would do the tunneling. > > > > > > I am not sure if you got the points above or not. I know cloud OS > > > companies that provide the service > > and have big announced customers. > > > > > > Thanks, > > > Vishwas > > > On Tue, Aug 9, 2011 at 11:51 AM, Linda Dunbar > wrote: > > > Vishwas, > > > > > > In my mind the bullet 1) in the list refers to ToR switches > > > downstream ports (facing servers) > > running Layer 2 and ToR uplinks ports run IP Layer 3. > > > > > > Have you seen data center networks with ToR switches downstream > > > ports (i.e. facing servers) enabling > > IP routing, even though the physical links are Ethernet? > > > If yes, we should definitely include it in the ARMD draft. > > > > > > Thanks, > > > Linda > > > On Tue, Aug 9, 2011 at 12:58 PM, Vishwas Manral > wrote: > > > Hi Linda, > > > I am unsure what you mean by this, but: > > > * layer 3 all the way to TOR (Top of Rack switches), We can also > > > have a heirarchical network, with the core totally Layer-3 (and > > > having seperate > > routing), from the hosts still in a large Layer-3 subnet. Another > > aspect could be to have a totally > > Layer-3 network. > > > > > > The difference between them is the link between the servers and the > ToR. > > > > > > Thanks, > > > Vishwas > > > On Tue, Aug 9, 2011 at 10:22 AM, Linda Dunbar > wrote: > > > During the 81st IETF ARMD WG discussion, it was suggested that it > is > > > necessary to document typical > > data center network designs so that address resolution scaling issues > > can be properly described. Many data center operators have expressed > that they can't openly reveal their detailed network designs. > > Therefore, we only want to document anonymous designs without too > much > > detail. During the journey of establishing ARMD, we have come across > the following typical data center network designs: > > > * layer 3 all the way to TOR (Top of Rack switches), > > > * large layer 2 with hundreds (or thousands) of ToRs being > > > interconnected by Layer 2. This > > design will have thousands of hosts under the L2/L3 boundary router > > (s) > > > * CLOS design with thousands of switches. This design will have > > > thousands of hosts under the > > L2/L3 boundary router(s) > > > We have heard that each of the designs above has its own problems. > > > ARMD problem statements might > > need to document DC problems under each typical design. > > > Please send feedback to us (either to the armd email list or to > the > > > ARMD chair Benson & Linda) to > > indicate if we have missed any typical Data Center network designs. > > > > > > Your contribution can greatly accelerate the progress of ARMD WG. > > > > > > Thank you very much. > > > > > > Linda & Benson > > > _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd --Boundary_(ID_f2/dNnGhsysTS7MFseepjw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

Hello = Vishwas:

 

Yes, an asynchronous event can = cause VM movement.  The = Management Entity is involved in the move, but the move can be to any = number of N hosts.  As an = example:

 

-          = 3 Hosts with lots of = VM’s  (Host A, Host = B, Host C)

-          = Host A has a = failure

-          = VM’s from Host A are = moved to Host B and Host C using the Management Entities internal = decision algorithm.

 

Mike

 

 

From: Vishwas Manral = [mailto:vishwas.ietf@gmail.com]
Sent: Wednesday, February 29, = 2012 3:32 PM
To: Michael Smith
Cc: Linda Dunbar; = Gary Berger; armd@ietf.org
Subject: Re: [armd] how does = "draft-sridharan-virtualization-nvgre-00"advertise its = external facing hosts' IP addresses to external = world?

 

Hi Michael,

Please forgive my = ignorance here. I guess what you are saying is that the trigger could be = some asynchronous event not initiated by the operator.

However = isn't the management entity (not manual intervention) involved in = actually moving the VM and any storage/ state associated with it? If it = is the management entity knows of the = movement.

Thanks,
Vishwas

On Tue, Feb 28, 2012 at 1:31 PM, Michael Smith <mksmith@mac.com> = wrote:

VM migration can be planned or unplanned, either manually or = automatically.   In the event of a host failing that is = configured for automatic migration, the VM’s on the host will = migrate to another host as configured.  There is some internal = intelligence that will allow for best placement of VM’s, so they = can move to any one of a number of available = hosts.


Mike

 

From:= = armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda = Dunbar


Sent: = Tuesday, February 28, 2012 1:17 PM
To: Vishwas Manral; Gary = Berger

Cc: armd@ietf.org
Subject: Re: [armd] how = does "draft-sridharan-virtualization-nvgre-00"advertise its = external facing hosts' IP addresses to external = world?

 <= /o:p>

Gary,

 

Can you elaborate why “vm = migration may not be planned”?

 

I thought that VM migration is orchestrated by some entity, like = vMotion or VM managers.

 

Linda

 

From:= = Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: = Monday, February 27, 2012 6:49 PM
To: Gary = Berger
Cc: Linda Dunbar; Murari Sridharan; armd@ietf.org
Subject: Re: [armd] how = does "draft-sridharan-virtualization-nvgre-00"advertise its = external facing hosts' IP addresses to external = world?

 <= /o:p>

Hi Gary,

I = guess what Linda was trying to say is that the station moves = autonomously, however there is some entity moving the VM (which can in = turn could move the state on the switch).

An example of this = could be VEPA.

Thanks,
Vishwas

On Fri, Feb = 24, 2012 at 2:22 PM, Gary Berger <gaberger@cisco.com> = wrote:

 

 

Protocols have been developed for IP mobility between Home Gateway = and Remote Gateway. The question is if we want similar protocols among = TORs or among vSwitches. Handset mobility is random, but VM migration is = planned. =  

 

I wouldn't = put such a restriction, vm migration may not be planned.. They both = degenerate into a multi-homing = problem.

 

Linda

 

From:= = armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of = Vishwas Manral
Sent: Thursday, September 22, 2011 9:38 = PM
To: Murari Sridharan
Cc: armd@ietf.org
Subject: Re: [armd] how = does "draft-sridharan-virtualization-nvgre-00" advertise its = external facing hosts' IP addresses to external = world?

 <= /o:p>

Murari = think IP mobility. :)

 <= /o:p>

On Thu, Sep = 22, 2011 at 5:00 PM, Murari Sridharan <muraris@microsoft.com> = wrote:

Do you = have a scenario in mind?

From: = Vishwas = Manral
Sent: = 9/22/2011 = 4:55 PM


To: = Murari = Sridharan
Cc: = Narasimhan = Venkataramaiah; Linda Dunbar; david.black@emc.com; armd@ietf.org
Subject: = Re: [armd] = how does "draft-sridharan-virtualization-nvgre-00" advertise = its external facing hosts' IP addresses to external = world?

Hi = Murari,

 <= /o:p>

Yes that is = what I mean.

 <= /o:p>

Thanks,=

Vishwas=

On Thu, Sep = 22, 2011 at 4:50 PM, Murari Sridharan <muraris@microsoft.com> = wrote:

You mean not an Ethernet frame = but some IP payload?

 

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Thursday, = September 22, 2011 4:49 PM
To: Murari Sridharan
Cc: = Narasimhan Venkataramaiah; Linda Dunbar; david.black@emc.com; armd@ietf.org


Subje= ct: Re: [armd] how does = "draft-sridharan-virtualization-nvgre-00" advertise its = external facing hosts' IP addresses to external = world?

 <= /o:p>

Murari,=

 <= /o:p>

What I am = saying is the inner header should be allowed to be L3. =

 <= /o:p>

From the = diagram you have that does not seem to be the case. Am I missing it = totally?

 <= /o:p>

Thanks,=

Vishwas=

On Thu, Sep = 22, 2011 at 4:43 PM, Murari Sridharan <muraris@microsoft.com> = wrote:

Vishwas, Thanks for the = feedback we will definitely consider adding that. I am not sure what you = mean by doing L3 instead of L2. We allow any arbitrary virtual topology = including L3.

 

Thanks

 

=

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Thursday, = September 22, 2011 4:19 PM


To: Narasimhan = Venkataramaiah
Cc: Linda Dunbar; Murari Sridharan; david.black@emc.com; armd@ietf.org
Subject: Re: [armd] how = does "draft-sridharan-virtualization-nvgre-00" advertise its = external facing hosts' IP addresses to external = world?

 <= /o:p>

Hi = Simha,

 <= /o:p>

I see this = as the only difference between VXLAN and the NVGRE solution (besides = ofcourse that TNI needs to be parsed in the intermediate device for = hashing and using lesser number of bytes).

 <= /o:p>

I would = think you should add it to your draft immediately. With = tunneling you consolidate the addresses visible to the = core and by providing a hash mechanism, you are providing some level of = randomness.

 <= /o:p>

The other = thing you should look at is L3 (IPv4/ IPv6) over NVGRE instead of = L2 alone. I guess it would be the same comment for the VXLAN = proposal too.

 <= /o:p>

Thanks,=

Vishwas=

On Thu, Sep = 22, 2011 at 4:11 PM, Narasimhan Venkataramaiah <narave@microsoft.com> = wrote:

The draft = mentions exactly this as one use of the reserved 8 bits in Section 4. An = NVGRE endpoint could use the 8 bits to further distribute flows = belonging to a particular TNI and the switches use all 32 bits to get = entropy. One step further would be for the switches to get full entropy = from the inner Ethernet frame. I take it that your comment would be to = make it explicit in the draft. Right?

 

One

   such = example could be to use the upper 8 bits of the Key field = to

   add = flow based entropy and tag all the packets from a flow with an entropy = label.

 

Simha

 

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Thursday, = September 22, 2011 4:04 PM
To: Narasimhan = Venkataramaiah
Cc: Linda Dunbar; Murari Sridharan; david.black@emc.com; armd@ietf.org
Subject: Re: [armd] how = does "draft-sridharan-virtualization-nvgre-00" advertise its = external facing hosts' IP addresses to external = world?

 <= /o:p>

Hi = Simha,

 <= /o:p>

The main = (Standards Track) change in your draft is the addition of = TNI.

 <= /o:p>

A question = I have is a TNI identifies a particular tenant and all flows from/to a = tenant will be hashed to the same path (even with the changes in = switches to do hashing to use TNI).

 <= /o:p>

Why do you = not use the last 8 bits which you have kept as reserved for providing = the randomization for hashing flows between same to/from on different = paths?

 <= /o:p>

Thanks,=

Vishwas=

On Sun, Sep = 18, 2011 at 11:01 AM, Narasimhan Venkataramaiah <narave@microsoft.com> wrote:

The easiest from the point of view of configuration would be to = route everything back through the enterprise - not necessarily the = optimal from the enterprise point of view. Are you referring to a = scenario where the VMs subnet is split between the cloud and the = enterprise? Otherwise I don't see the implication on virtualization as = its no different than getting the traffic routed to the enterprise in = the first = case.

Simha

________________________________________
Fro= m: armd-bounces@ietf.org [armd-bounces@ietf.org] on behalf of Linda Dunbar = [linda.dunbar@huawei.com]
Sent: Sunday, = September 18, 2011 7:06 AM
To: Murari Sridharan; david.black@emc.com; armd@ietf.org
Subject: [armd] how does = "draft-sridharan-virtualization-nvgre-00" advertise its = external facing hosts' IP addresses to external = world?


Hi = Murari,

Thank you very much for sharing the = presentation.

One question:

For a host within an = Enterprise site which needs to communicate with external peers, the host = either uses public IP address which is visible to external peers or uses = private IP address which is translated to public address at the = Enterprise site's gateway.

When this host is moved to "Cloud = data center", will the "Cloud Data center" advertise this = host address to external peers? Or will all external peers go through = enterprise's gateway to reach this host which is no longer residing in = the enterprise site?

Thanks, Linda

> -----Original = Message-----
> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of
> Murari = Sridharan
> Sent: Saturday, September 17, 2011 3:02 PM
> To: = david.black@emc.com; armd@ietf.org
> Subject: Re: [armd] = soliciting typical network designs for ARMD
>
> FYI, here is = a talk that I gave last week in relation to the nvgre
> draft = below.
> http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-442= T
>
> Thanks
> Murari
>
> = -----Original Message-----
> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of
> david.black@emc.com
> Sent: Friday, = September 16, 2011 6:14 AM
> To: armd@ietf.org
> Subject: Re: [armd] = soliciting typical network designs for ARMD
>
> And two more = drafts on this topic:
>
> http://www.ietf.org/id/draft-mahalingam-dutt-dcops-vxla= n-00.txt
> http://www.ietf.org/id/draft-sridharan-virtualization-n= vgre-00.txt
>
> The edge switches could be the software = switches in hypervisors.
>
> Thanks,
> = --David
>
>
> > -----Original Message-----
> = > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf
> > Of = Warren Kumari
> > Sent: Wednesday, August 31, 2011 3:16 = PM
> > To: Vishwas Manral
> > Cc: armd@ietf.org
> > Subject: Re: [armd] = soliciting typical network designs for ARMD
> >
> = >
> > On Aug 11, 2011, at 11:40 PM, Vishwas Manral = wrote:
> >
> > > Hi Linda/ Anoop,
> > = >
> > > Here is the example of the design I was talking = about, as defined
> by google.
> >
> > Just a = clarification -- s/as defined by google/as described by
> = someone
> > who happens to work for google/
> = >
> > W
> >
> > > http://www.ietf.org/id/draft-wkumari-dcops-l3-vmmobilit= y-00.txt
> > >
> > > Thanks,
> > = > Vishwas
> > > On Tue, Aug 9, 2011 at 2:50 PM, Anoop = Ghanwani
> <anoop@alumni.duke.edu> wrote:
> > = >
> > > >>>>
> > > (though I = think if there was a standard way to map Multicast MAC to
> > = > Multicast IP, they could
> > probably use such a standard = mechanisms).
> > > >>>>
> > = >
> > > They can do that, but then this imposes = requirements on the
> > > equipment to be able to do = multicast forwarding, and even if does,
> > > because of = pruning requirements the number of groups would be very
> > = > large.  The average data center switch probably won't handle = that
> > > many groups.
> > >
> > > = On Tue, Aug 9, 2011 at 2:41 PM, Vishwas Manral
> <vishwas.ietf@gmail.com> wrote:
> > = > Hi Anoop,
> > >
> > > From what I know they = do not use Multicast GRE (I hear the extra 4
> > > bytes in = the GRE header is a
> > proprietery extension).
> > = >
> > > I think a directory based mechanism is what is = used (though I think
> > > if there was a standard way = to
> > map Multicast MAC to Multicast IP, they could probably = use such a
> standard mechanisms).
> > >
> > = > Thanks,
> > > Vishwas
> > > On Tue, Aug 9, = 2011 at 2:03 PM, Anoop Ghanwani
> <anoop@alumni.duke.edu> wrote:
> > > = Hi Vishwas,
> > >
> > > How do they get = multicast through the network in that case?
> > > Are they = planning to use multicast GRE, or just use directory based
> > = > lookups and not worry about multicast applications for now?
> = > >
> > > Anoop
> > >
> > > On = Tue, Aug 9, 2011 at 1:27 PM, Vishwas Manral
> <vishwas.ietf@gmail.com> wrote:
> > = > Hi Linda,
> > >
> > > The data packets can = be tunnelled at the ToR over say a GRE packet
> > > and the = core is a Layer-3 core
> > (except for the downstream ports). = So we could have encapsulation/
> > decapsulation of L2 over = GRE at the ToR.
> > >
> > > The very same thing = can be done at the hypervisor layer too, in
> > > which case = the entire DC network
> > would look like a Layer-3 flat = network including the ToR to server
> > link and the hypervisor = would do the tunneling.
> > >
> > > I am not = sure if you got the points above or not. I know cloud OS
> > = > companies that provide the service
> > and have big = announced customers.
> > >
> > > Thanks,
> = > > Vishwas
> > > On Tue, Aug 9, 2011 at 11:51 AM, = Linda Dunbar <dunbar.ll@gmail.com>
> wrote:
> = > > Vishwas,
> > >
> > > In my mind the = bullet 1) in the list refers to ToR switches
> > > = downstream ports (facing servers)
> > running Layer 2 and ToR = uplinks ports run IP Layer 3.
> > >
> > > Have = you seen data center networks with ToR switches downstream
> > = > ports (i.e. facing servers) enabling
> > IP routing, even = though the physical links are Ethernet?
> > > If yes, we = should definitely include it in the ARMD draft.
> > = >
> > > Thanks,
> > > Linda
> > > = On Tue, Aug 9, 2011 at 12:58 PM, Vishwas Manral
> <vishwas.ietf@gmail.com> wrote:
> > = > Hi Linda,
> > > I am unsure what you mean by this, = but:
> > >   * layer 3 all the way to TOR (Top of Rack = switches), We can also
> > > have a heirarchical network, = with the core totally Layer-3 (and
> > > having = seperate
> > routing), from the hosts still in a large Layer-3 = subnet. Another
> > aspect could be to have a totally
> = > Layer-3 network.
> > >
> > > The difference = between them is the link between the servers and the
> = ToR.
> > >
> > > Thanks,
> > > = Vishwas
> > > On Tue, Aug 9, 2011 at 10:22 AM, Linda Dunbar = <dunbar.ll@gmail.com>
> wrote:
> = > > During the 81st IETF ARMD WG discussion, it was suggested that = it
> is
> > > necessary to document typical
> = > data center network designs so that address resolution scaling = issues
> > can be properly described. Many data center = operators have expressed
> that they can't openly reveal their = detailed network designs.
> > Therefore, we only want to = document anonymous designs without too
> much
> > detail. = During the journey of establishing ARMD, we have come across
> the = following typical data center network designs:
> > >   = * layer 3 all the way to TOR (Top of Rack switches),
> > > =   * large layer 2 with hundreds (or thousands) of ToRs = being
> > > interconnected by Layer 2. This
> > = design will have thousands of hosts under the L2/L3 boundary = router
> > (s)
> > >   * CLOS design =  with thousands of switches. This design will have
> > = > thousands of hosts under the
> > L2/L3 boundary = router(s)
> > > We have heard that each of the designs above = has its own problems.
> > > ARMD problem statements = might
> > need to document DC problems under each typical = design.
> > > Please send feedback to us (either to the armd = email list  or to
> the
> > > ARMD chair Benson = & Linda) to
> > indicate if we have missed any typical Data = Center network designs.
> > >
> > > Your = contribution can greatly accelerate the progress of ARMD WG.
> = > >
> > > Thank you very much.
> > = >
> > > Linda & Benson
> > = >

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

____________= ___________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd =

 <= /o:p>

 

= --Boundary_(ID_f2/dNnGhsysTS7MFseepjw)-- From david.black@emc.com Thu Mar 1 13:41:42 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270EC21E8217 for ; Thu, 1 Mar 2012 13:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.728 X-Spam-Level: X-Spam-Status: No, score=-109.728 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9-SxLj5+64l for ; Thu, 1 Mar 2012 13:41:35 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id B5DC221E827F for ; Thu, 1 Mar 2012 13:41:33 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q21LfW2T026431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Mar 2012 16:41:32 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 1 Mar 2012 16:41:13 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q21LfCO6000900; Thu, 1 Mar 2012 16:41:12 -0500 Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Thu, 1 Mar 2012 16:41:12 -0500 From: To: Date: Thu, 1 Mar 2012 16:41:10 -0500 Thread-Topic: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world? Thread-Index: AQFBgImgjHc9GOBNhB03d9UiBPUVDgIidqOuAoKhqSYCXK5zlgH0hEGxASKNSNSXHBpIQIAABM5A Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8CE07@MX14A.corp.emc.com> References: <4A95BA014132FF49AE685FAB4B9F17F610CAB74A@dfweml503-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F632E2495E@dfweml505-mbx> <151901ccf660$5175f500$f461df00$@mac.com> <170701ccf7f1$152f1d50$3f8d57f0$@mac.com> In-Reply-To: <170701ccf7f1$152f1d50$3f8d57f0$@mac.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_7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8CE07MX14Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"advertise its external facing hosts' IP addresses to external world? X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 21:41:42 -0000 --_000_7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8CE07MX14Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Important clarification: Host A has a *partial* failure ... that leaves the VM's running, but causes= the Management Entity to decide that Host A should be vacated. For example, if Host A has redundant I/O connections, and one of the hardwa= re I/O interfaces fails, vacating Host A avoids exposing the VMs to possibl= e failure of the other interface, and enables taking Host A down to fix its= hardware problem. If Host A fails in a fashion that takes down the VMs, recovery is necessary= instead of migration. Thanks, --David From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Mic= hael Smith Sent: Thursday, March 01, 2012 4:20 PM To: 'Vishwas Manral'; 'Michael Smith' Cc: armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"adver= tise its external facing hosts' IP addresses to external world? Hello Vishwas: Yes, an asynchronous event can cause VM movement. The Management Entity is= involved in the move, but the move can be to any number of N hosts. As an= example: - 3 Hosts with lots of VM's (Host A, Host B, Host C) - Host A has a failure - VM's from Host A are moved to Host B and Host C using the Manage= ment Entities internal decision algorithm. Mike From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Wednesday, February 29, 2012 3:32 PM To: Michael Smith Cc: Linda Dunbar; Gary Berger; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"adver= tise its external facing hosts' IP addresses to external world? Hi Michael, Please forgive my ignorance here. I guess what you are saying is that the t= rigger could be some asynchronous event not initiated by the operator. However isn't the management entity (not manual intervention) involved in a= ctually moving the VM and any storage/ state associated with it? If it is t= he management entity knows of the movement. Thanks, Vishwas On Tue, Feb 28, 2012 at 1:31 PM, Michael Smith > wrote: VM migration can be planned or unplanned, either manually or automatically.= In the event of a host failing that is configured for automatic migratio= n, the VM's on the host will migrate to another host as configured. There = is some internal intelligence that will allow for best placement of VM's, s= o they can move to any one of a number of available hosts. Mike From: armd-bounces@ietf.org [mailto:armd-boun= ces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, February 28, 2012 1:17 PM To: Vishwas Manral; Gary Berger Cc: armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"adver= tise its external facing hosts' IP addresses to external world? Gary, Can you elaborate why "vm migration may not be planned"? I thought that VM migration is orchestrated by some entity, like vMotion or= VM managers. Linda From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Monday, February 27, 2012 6:49 PM To: Gary Berger Cc: Linda Dunbar; Murari Sridharan; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00"adver= tise its external facing hosts' IP addresses to external world? Hi Gary, I guess what Linda was trying to say is that the station moves autonomously= , however there is some entity moving the VM (which can in turn could move = the state on the switch). An example of this could be VEPA. Thanks, Vishwas On Fri, Feb 24, 2012 at 2:22 PM, Gary Berger > wrote: Protocols have been developed for IP mobility between Home Gateway and Remo= te Gateway. The question is if we want similar protocols among TORs or amon= g vSwitches. Handset mobility is random, but VM migration is planned. I wouldn't put such a restriction, vm migration may not be planned.. They b= oth degenerate into a multi-homing problem. Linda From: armd-bounces@ietf.org [mailto:armd-boun= ces@ietf.org] On Behalf Of Vishwas Manral Sent: Thursday, September 22, 2011 9:38 PM To: Murari Sridharan Cc: armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" adve= rtise its external facing hosts' IP addresses to external world? Murari think IP mobility. :) On Thu, Sep 22, 2011 at 5:00 PM, Murari Sridharan > wrote: Do you have a scenario in mind? ________________________________ From: Vishwas Manral Sent: 9/22/2011 4:55 PM To: Murari Sridharan Cc: Narasimhan Venkataramaiah; Linda Dunbar; david.black@emc.com; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" adve= rtise its external facing hosts' IP addresses to external world? Hi Murari, Yes that is what I mean. Thanks, Vishwas On Thu, Sep 22, 2011 at 4:50 PM, Murari Sridharan > wrote: You mean not an Ethernet frame but some IP payload? From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Thursday, September 22, 2011 4:49 PM To: Murari Sridharan Cc: Narasimhan Venkataramaiah; Linda Dunbar; david.black@emc.com; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" adve= rtise its external facing hosts' IP addresses to external world? Murari, What I am saying is the inner header should be allowed to be L3. >From the diagram you have that does not seem to be the case. Am I missing i= t totally? Thanks, Vishwas On Thu, Sep 22, 2011 at 4:43 PM, Murari Sridharan > wrote: Vishwas, Thanks for the feedback we will definitely consider adding that. I= am not sure what you mean by doing L3 instead of L2. We allow any arbitrar= y virtual topology including L3. Thanks From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Thursday, September 22, 2011 4:19 PM To: Narasimhan Venkataramaiah Cc: Linda Dunbar; Murari Sridharan; david.black@emc.com; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" adve= rtise its external facing hosts' IP addresses to external world? Hi Simha, I see this as the only difference between VXLAN and the NVGRE solution (bes= ides ofcourse that TNI needs to be parsed in the intermediate device for ha= shing and using lesser number of bytes). I would think you should add it to your draft immediately. With tunneling y= ou consolidate the addresses visible to the core and by providing a hash me= chanism, you are providing some level of randomness. The other thing you should look at is L3 (IPv4/ IPv6) over NVGRE instead of= L2 alone. I guess it would be the same comment for the VXLAN proposal too. Thanks, Vishwas On Thu, Sep 22, 2011 at 4:11 PM, Narasimhan Venkataramaiah > wrote: The draft mentions exactly this as one use of the reserved 8 bits in Sectio= n 4. An NVGRE endpoint could use the 8 bits to further distribute flows bel= onging to a particular TNI and the switches use all 32 bits to get entropy.= One step further would be for the switches to get full entropy from the in= ner Ethernet frame. I take it that your comment would be to make it explici= t in the draft. Right? One such example could be to use the upper 8 bits of the Key field to add flow based entropy and tag all the packets from a flow with an entro= py label. Simha From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Thursday, September 22, 2011 4:04 PM To: Narasimhan Venkataramaiah Cc: Linda Dunbar; Murari Sridharan; david.black@emc.com; armd@ietf.org Subject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00" adve= rtise its external facing hosts' IP addresses to external world? Hi Simha, The main (Standards Track) change in your draft is the addition of TNI. A question I have is a TNI identifies a particular tenant and all flows fro= m/to a tenant will be hashed to the same path (even with the changes in swi= tches to do hashing to use TNI). Why do you not use the last 8 bits which you have kept as reserved for prov= iding the randomization for hashing flows between same to/from on different= paths? Thanks, Vishwas On Sun, Sep 18, 2011 at 11:01 AM, Narasimhan Venkataramaiah > wrote: The easiest from the point of view of configuration would be to route every= thing back through the enterprise - not necessarily the optimal from the en= terprise point of view. Are you referring to a scenario where the VMs subne= t is split between the cloud and the enterprise? Otherwise I don't see the = implication on virtualization as its no different than getting the traffic = routed to the enterprise in the first case. Simha ________________________________________ From: armd-bounces@ietf.org [armd-bounces@iet= f.org] on behalf of Linda Dunbar [linda.dunba= r@huawei.com] Sent: Sunday, September 18, 2011 7:06 AM To: Murari Sridharan; david.black@emc.com; armd= @ietf.org Subject: [armd] how does "draft-sridharan-virtualization-nvgre-00" advertis= e its external facing hosts' IP addresses to external world? Hi Murari, Thank you very much for sharing the presentation. One question: For a host within an Enterprise site which needs to communicate with extern= al peers, the host either uses public IP address which is visible to extern= al peers or uses private IP address which is translated to public address a= t the Enterprise site's gateway. When this host is moved to "Cloud data center", will the "Cloud Data center= " advertise this host address to external peers? Or will all external peers= go through enterprise's gateway to reach this host which is no longer resi= ding in the enterprise site? Thanks, Linda > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bo= unces@ietf.org] On Behalf Of > Murari Sridharan > Sent: Saturday, September 17, 2011 3:02 PM > To: david.black@emc.com; armd@ietf.org > Subject: Re: [armd] soliciting typical network designs for ARMD > > FYI, here is a talk that I gave last week in relation to the nvgre > draft below. > http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-442T > > Thanks > Murari > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bo= unces@ietf.org] On Behalf Of > david.black@emc.com > Sent: Friday, September 16, 2011 6:14 AM > To: armd@ietf.org > Subject: Re: [armd] soliciting typical network designs for ARMD > > And two more drafts on this topic: > > http://www.ietf.org/id/draft-mahalingam-dutt-dcops-vxlan-00.txt > http://www.ietf.org/id/draft-sridharan-virtualization-nvgre-00.txt > > The edge switches could be the software switches in hypervisors. > > Thanks, > --David > > > > -----Original Message----- > > From: armd-bounces@ietf.org [mailto:armd-= bounces@ietf.org] On Behalf > > Of Warren Kumari > > Sent: Wednesday, August 31, 2011 3:16 PM > > To: Vishwas Manral > > Cc: armd@ietf.org > > Subject: Re: [armd] soliciting typical network designs for ARMD > > > > > > On Aug 11, 2011, at 11:40 PM, Vishwas Manral wrote: > > > > > Hi Linda/ Anoop, > > > > > > Here is the example of the design I was talking about, as defined > by google. > > > > Just a clarification -- s/as defined by google/as described by > someone > > who happens to work for google/ > > > > W > > > > > http://www.ietf.org/id/draft-wkumari-dcops-l3-vmmobility-00.txt > > > > > > Thanks, > > > Vishwas > > > On Tue, Aug 9, 2011 at 2:50 PM, Anoop Ghanwani > > wrote: > > > > > > >>>> > > > (though I think if there was a standard way to map Multicast MAC to > > > Multicast IP, they could > > probably use such a standard mechanisms). > > > >>>> > > > > > > They can do that, but then this imposes requirements on the > > > equipment to be able to do multicast forwarding, and even if does, > > > because of pruning requirements the number of groups would be very > > > large. The average data center switch probably won't handle that > > > many groups. > > > > > > On Tue, Aug 9, 2011 at 2:41 PM, Vishwas Manral > > wrote: > > > Hi Anoop, > > > > > > From what I know they do not use Multicast GRE (I hear the extra 4 > > > bytes in the GRE header is a > > proprietery extension). > > > > > > I think a directory based mechanism is what is used (though I think > > > if there was a standard way to > > map Multicast MAC to Multicast IP, they could probably use such a > standard mechanisms). > > > > > > Thanks, > > > Vishwas > > > On Tue, Aug 9, 2011 at 2:03 PM, Anoop Ghanwani > > wrote: > > > Hi Vishwas, > > > > > > How do they get multicast through the network in that case? > > > Are they planning to use multicast GRE, or just use directory based > > > lookups and not worry about multicast applications for now? > > > > > > Anoop > > > > > > On Tue, Aug 9, 2011 at 1:27 PM, Vishwas Manral > > wrote: > > > Hi Linda, > > > > > > The data packets can be tunnelled at the ToR over say a GRE packet > > > and the core is a Layer-3 core > > (except for the downstream ports). So we could have encapsulation/ > > decapsulation of L2 over GRE at the ToR. > > > > > > The very same thing can be done at the hypervisor layer too, in > > > which case the entire DC network > > would look like a Layer-3 flat network including the ToR to server > > link and the hypervisor would do the tunneling. > > > > > > I am not sure if you got the points above or not. I know cloud OS > > > companies that provide the service > > and have big announced customers. > > > > > > Thanks, > > > Vishwas > > > On Tue, Aug 9, 2011 at 11:51 AM, Linda Dunbar > > wrote: > > > Vishwas, > > > > > > In my mind the bullet 1) in the list refers to ToR switches > > > downstream ports (facing servers) > > running Layer 2 and ToR uplinks ports run IP Layer 3. > > > > > > Have you seen data center networks with ToR switches downstream > > > ports (i.e. facing servers) enabling > > IP routing, even though the physical links are Ethernet? > > > If yes, we should definitely include it in the ARMD draft. > > > > > > Thanks, > > > Linda > > > On Tue, Aug 9, 2011 at 12:58 PM, Vishwas Manral > > wrote: > > > Hi Linda, > > > I am unsure what you mean by this, but: > > > * layer 3 all the way to TOR (Top of Rack switches), We can also > > > have a heirarchical network, with the core totally Layer-3 (and > > > having seperate > > routing), from the hosts still in a large Layer-3 subnet. Another > > aspect could be to have a totally > > Layer-3 network. > > > > > > The difference between them is the link between the servers and the > ToR. > > > > > > Thanks, > > > Vishwas > > > On Tue, Aug 9, 2011 at 10:22 AM, Linda Dunbar > > wrote: > > > During the 81st IETF ARMD WG discussion, it was suggested that it > is > > > necessary to document typical > > data center network designs so that address resolution scaling issues > > can be properly described. Many data center operators have expressed > that they can't openly reveal their detailed network designs. > > Therefore, we only want to document anonymous designs without too > much > > detail. During the journey of establishing ARMD, we have come across > the following typical data center network designs: > > > * layer 3 all the way to TOR (Top of Rack switches), > > > * large layer 2 with hundreds (or thousands) of ToRs being > > > interconnected by Layer 2. This > > design will have thousands of hosts under the L2/L3 boundary router > > (s) > > > * CLOS design with thousands of switches. This design will have > > > thousands of hosts under the > > L2/L3 boundary router(s) > > > We have heard that each of the designs above has its own problems. > > > ARMD problem statements might > > need to document DC problems under each typical design. > > > Please send feedback to us (either to the armd email list or to > the > > > ARMD chair Benson & Linda) to > > indicate if we have missed any typical Data Center network designs. > > > > > > Your contribution can greatly accelerate the progress of ARMD WG. > > > > > > Thank you very much. > > > > > > Linda & Benson > > > _______________________________________________ armd mailing list armd@ietf= .org https://www.ietf.org/mailman/listinfo/armd --_000_7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8CE07MX14Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Important clarificat= ion:

 

Host A has a *partial* failure ... that leaves the VM&#= 8217;s running, but causes the Management Entity to decide that Host A shou= ld be vacated.

 

For example, if Host A has redundant I/O connections= , and one of the hardware I/O interfaces fails, vacating Host A avoids expo= sing the VMs to possible failure of the other interface, and enables taking= Host A down to fix its hardware problem.

 

If Host A fails in a fash= ion that takes down the VMs, recovery is necessary instead of migration.

 

Thanks,
--David

= From:= armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of M= ichael Smith
Sent: Thursday, March 01, 2012 4:20 PM
To:= 'Vishwas Manral'; 'Michael Smith'
Cc: armd@ietf.org
Subjec= t: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00&qu= ot;advertise its external facing hosts' IP addresses to external world?

 

Hello Vishwas:

 

Yes,= an asynchronous event can cause VM movement.  The Management Entity i= s involved in the move, but the move can be to any number of N hosts. = As an example:

 = ;

-   &n= bsp;      3 = Hosts with lots of VM’s  (Host A, Host B, Host C)

-<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;    Host A has a = failure

- &n= bsp;        VM’s from Host A are moved to Host B and Host C using the M= anagement Entities internal decision algorithm.

 

Mike

 =

 

<= div>

From: Vishwas Manral [mailto:vishwas.ietf@g= mail.com]
Sent: Wednesday, February 29, 2012 3:32 PM
To: Michael Smith
Cc: Linda Dunbar; Gary Berger; armd@ietf.org
= Subject: Re: [armd] how does "draft-sridharan-virtualization-nv= gre-00"advertise its external facing hosts' IP addresses to external w= orld?

 

Hi Michael,
Please forgive my ignorance here. I guess what you are saying is that the= trigger could be some asynchronous event not initiated by the operator.
However isn't the management entity (not manual intervention) involved= in actually moving the VM and any storage/ state associated with it? If it= is the management entity knows of the movement.

Thanks,
Vishwas<= o:p>

On Tue, Feb 28, 2012 at 1:31 PM, Mi= chael Smith <mksmith@mac.com> = wrote:

VM migration can be planned or= unplanned, either manually or automatically.   In the event of a= host failing that is configured for automatic migration, the VM’s on= the host will migrate to another host as configured.  There is some i= nternal intelligence that will allow for best placement of VM’s, so t= hey can move to any one of a number of available hosts.


Mike

 

 <= o:p>

Gary,

&nbs= p;

Can you elaborate why “<= span style=3D'font-size:8.5pt;font-family:"Calibri","sans-serif"'>vm migrat= ion may not be planned”?

 =

I thought that VM migration is orchestrated by some entit= y, like vMotion or VM managers.

 <= /span>

Linda

 

From: Vishwas Manra= l [mai= lto:vishwas.ietf@gmail.com]
Sent: Monday, February 27, 2012 = 6:49 PM
To: Gary Berger
Cc: Linda Dunbar; Murari Sridha= ran; armd@ietf.orgSubject: Re: [armd] how does "draft-sridharan-virtualization-= nvgre-00"advertise its external facing hosts' IP addresses to external= world?

 

Hi Ga= ry,

I guess what Linda was trying to say is that the station moves a= utonomously, however there is some entity moving the VM (which can in turn = could move the state on the switch).

An example of this could be VE= PA.

Thanks,
Vishwas

On Fri, Feb 24, 201= 2 at 2:22 PM, Gary Berger <gaberger@cisco.com> wrote:

=

 

 

Protocols ha= ve been developed for IP mobility between Home Gateway and Remote Gateway. = The question is if we want similar protocols among TORs or among vSwitches.= Handset mobility is random, but VM migration is planned.  

 

I wouldn't put such a restriction, vm migration may not be= planned.. They both degenerate into a multi-homing problem.

 

Linda

&= nbsp;

From: armd-bounces@ietf.org [mailto:armd-bounces@= ietf.org] On Behalf Of Vishwas Manral
Sent: Thursday, = September 22, 2011 9:38 PM
To: Murari Sridharan
Cc: armd@ietf.org
Sub= ject: Re: [armd] how does "draft-sridharan-virtualization-nvgre-00= " advertise its external facing hosts' IP addresses to external world?=

 

M= urari think IP mobility. :)

 

On Thu, Sep 22, 2011 at 5:00 PM, Murari Sridharan &= lt;muraris@micro= soft.com> wrote:

Do you have a scenario= in mind?

From: Vishwas Manral
Sent: 9/22/2011 4:55 PM


To: Murari Sridharan
Cc: Narasimhan Venkata= ramaiah; Linda Dunbar; david.black@emc.com; armd@ietf.org
Subject: Re: [armd] how does "draft-sr= idharan-virtualization-nvgre-00" advertise its external facing hosts' = IP addresses to external world?

Hi Mu= rari,

 

Yes that is what I mean.

 

Thanks,

Vishwas=

On Thu, Sep 22, 2011 at 4:50 PM, Murari Sridhar= an <muraris@m= icrosoft.com> wrote:

You mean not an Ethernet frame but some IP p= ayload?

 

From: Vishwas Manral [mailt= o:vishwas.ietf@= gmail.com]
Sent: Thursday, September 22, 2011 4:49 PM
= To: Murari Sridharan
Cc: Narasimhan Venkataramaiah; Linda Dun= bar; david.black@e= mc.com; armd@ietf.or= g


Subject: Re: [armd] = how does "draft-sridharan-virtualization-nvgre-00" advertise its = external facing hosts' IP addresses to external world?

=

 

Murari,<= /p>

 

What I am sayin= g is the inner header should be allowed to be L3.

 

From the diagram you have th= at does not seem to be the case. Am I missing it totally?

 

Thanks,<= /p>

Vishwas

On Thu, Sep 22= , 2011 at 4:43 PM, Murari Sridharan <muraris@microsoft.com> wrote:

=

Vishwas, Th= anks for the feedback we will definitely consider adding that. I am not sur= e what you mean by doing L3 instead of L2. We allow any arbitrary virtual t= opology including L3.

 

Thanks

 

From: Vishwas = Manral [mailto:= vishwas.ietf@gmail.com]
Sent: Thursday, September 22, 2011 4= :19 PM


To: Narasimhan Venkataramaiah
Cc: Linda Dunbar; Mu= rari Sridharan; da= vid.black@emc.com; a= rmd@ietf.org
Subject: Re: [armd] how does "draft-sridhar= an-virtualization-nvgre-00" advertise its external facing hosts' IP ad= dresses to external world?

 

Hi Simha,

 

I see this as the only difference = between VXLAN and the NVGRE solution (besides ofcourse that TNI needs to be= parsed in the intermediate device for hashing and using lesser number of b= ytes).

 

I would think you should add it to your draft immediately. With tunnelin= g you consolidate the addresses visible to the core and by p= roviding a hash mechanism, you are providing some level of randomness.=

 

The othe= r thing you should look at is L3 (IPv4/ IPv6) over NVGRE instead of L2= alone. I guess it would be the same comment for the VXLAN proposal to= o.

 

T= hanks,

Vishwas

On Thu, Sep 22, 2011 at 4:11 PM, Narasimhan Venkataramaiah <narave@microsoft.com= > wrote:

The draft mentions exactly this = as one use of the reserved 8 bits in Section 4. An NVGRE endpoint could use= the 8 bits to further distribute flows belonging to a particular TNI and t= he switches use all 32 bits to get entropy. One step further would be for t= he switches to get full entropy from the inner Ethernet frame. I take it th= at your comment would be to make it explicit in the draft. Right?

&nbs= p;

One

   such example could be to use th= e upper 8 bits of the Key field to

   add flow based= entropy and tag all the packets from a flow with an entropy label.<= o:p>

 

Simha

 

From: Vishwas Man= ral [mailto:vis= hwas.ietf@gmail.com]
Sent: Thursday, September 22, 2011 4:04= PM
To: Narasimhan Venkataramaiah
Cc: Linda Dunbar; Mur= ari Sridharan; dav= id.black@emc.com; ar= md@ietf.org
Subject: Re: [armd] how does "draft-sridhara= n-virtualization-nvgre-00" advertise its external facing hosts' IP add= resses to external world?

 =

Hi Simha,

 =

The main (Standards Track) change in your = draft is the addition of TNI.

 

A question I have is a TNI identifies a particula= r tenant and all flows from/to a tenant will be hashed to the same path (ev= en with the changes in switches to do hashing to use TNI).

 

Why do you not use = the last 8 bits which you have kept as reserved for providing the randomiza= tion for hashing flows between same to/from on different paths?<= /p>

 

Thanks,

Vishwas

On Sun, Se= p 18, 2011 at 11:01 AM, Narasimhan Venkataramaiah <narave@microsoft.com> wrote:

The easiest from the point of view of configuration woul= d be to route everything back through the enterprise - not necessarily the = optimal from the enterprise point of view. Are you referring to a scenario = where the VMs subnet is split between the cloud and the enterprise? Otherwi= se I don't see the implication on virtualization as its no different than g= etting the traffic routed to the enterprise in the first case.

Simha=

________________________________________
From: armd-bounces@ietf.org [armd-bounces@ietf.org<= /a>] on behalf of Linda Dunbar [linda.dunbar@huawei.com]
Sent: Sunday, September 1= 8, 2011 7:06 AM
To: Murari Sridharan; david.black@emc.com; armd@ietf.org
Subject: [armd] how does "= ;draft-sridharan-virtualization-nvgre-00" advertise its external facin= g hosts' IP addresses to external world?

<= br>Hi Murari,

Thank you very much for sharing the presentation.
<= br>One question:

For a host within an Enterprise site which needs to= communicate with external peers, the host either uses public IP address wh= ich is visible to external peers or uses private IP address which is transl= ated to public address at the Enterprise site's gateway.

When this h= ost is moved to "Cloud data center", will the "Cloud Data ce= nter" advertise this host address to external peers? Or will all exter= nal peers go through enterprise's gateway to reach this host which is no lo= nger residing in the enterprise site?

Thanks, Linda

> ----= -Original Message-----
> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf= Of
> Murari Sridharan
> Sent: Saturday, September 17, 2011 3:0= 2 PM
> To: d= avid.black@emc.com; = armd@ietf.org
> Subject: Re: [armd] soliciting typical network de= signs for ARMD
>
> FYI, here is a talk that I gave last week in= relation to the nvgre
> draft below.
> http://chan= nel9.msdn.com/Events/BUILD/BUILD2011/SAC-442T
>
> Thanks> Murari
>
> -----Original Message-----
> From: armd-bounces@ietf.org= [mailto:arm= d-bounces@ietf.org] On Behalf Of
> david.black@emc.com
> Sent: Friday, Se= ptember 16, 2011 6:14 AM
> To: armd@ietf.org
> Subject: Re: [armd] soliciting typic= al network designs for ARMD
>
> And two more drafts on this top= ic:
>
> http://www.ietf.org/id/draft-mahalin= gam-dutt-dcops-vxlan-00.txt
> http://www.ie= tf.org/id/draft-sridharan-virtualization-nvgre-00.txt
>
> T= he edge switches could be the software switches in hypervisors.
>
= > Thanks,
> --David
>
>
> > -----Original Mes= sage-----
> > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf
>= > Of Warren Kumari
> > Sent: Wednesday, August 31, 2011 3:16 P= M
> > To: Vishwas Manral
> > Cc: armd@ietf.org
> > Subject: Re: [arm= d] soliciting typical network designs for ARMD
> >
> >> > On Aug 11, 2011, at 11:40 PM, Vishwas Manral wrote:
> >=
> > > Hi Linda/ Anoop,
> > >
> > > Her= e is the example of the design I was talking about, as defined
> by g= oogle.
> >
> > Just a clarification -- s/as defined by go= ogle/as described by
> someone
> > who happens to work for g= oogle/
> >
> > W
> >
> > > http://www.ietf.org/id/draft-wkumari-dcops-l3-vmmobility-00.txt=
> > >
> > > Thanks,
> > > Vishwas<= br>> > > On Tue, Aug 9, 2011 at 2:50 PM, Anoop Ghanwani
> &l= t;anoop@alumni.d= uke.edu> wrote:
> > >
> > > >>>>=
> > > (though I think if there was a standard way to map Multi= cast MAC to
> > > Multicast IP, they could
> > probabl= y use such a standard mechanisms).
> > > >>>>
&g= t; > >
> > > They can do that, but then this imposes requ= irements on the
> > > equipment to be able to do multicast forw= arding, and even if does,
> > > because of pruning requirements= the number of groups would be very
> > > large.  The aver= age data center switch probably won't handle that
> > > many gr= oups.
> > >
> > > On Tue, Aug 9, 2011 at 2:41 PM, V= ishwas Manral
> <vishwas.ietf@gmail.com> wrote:
> > > Hi Anoo= p,
> > >
> > > From what I know they do not use Mul= ticast GRE (I hear the extra 4
> > > bytes in the GRE header is= a
> > proprietery extension).
> > >
> > >= I think a directory based mechanism is what is used (though I think
>= ; > > if there was a standard way to
> > map Multicast MAC t= o Multicast IP, they could probably use such a
> standard mechanisms)= .
> > >
> > > Thanks,
> > > Vishwas
= > > > On Tue, Aug 9, 2011 at 2:03 PM, Anoop Ghanwani
> <<= a href=3D"mailto:anoop@alumni.duke.edu" target=3D"_blank">anoop@alumni.duke= .edu> wrote:
> > > Hi Vishwas,
> > >
>= > > How do they get multicast through the network in that case?
&= gt; > > Are they planning to use multicast GRE, or just use directory= based
> > > lookups and not worry about multicast applications= for now?
> > >
> > > Anoop
> > >
&g= t; > > On Tue, Aug 9, 2011 at 1:27 PM, Vishwas Manral
> <vishwas.ietf@gmail= .com> wrote:
> > > Hi Linda,
> > >
> &= gt; > The data packets can be tunnelled at the ToR over say a GRE packet=
> > > and the core is a Layer-3 core
> > (except for = the downstream ports). So we could have encapsulation/
> > decapsu= lation of L2 over GRE at the ToR.
> > >
> > > The v= ery same thing can be done at the hypervisor layer too, in
> > >= ; which case the entire DC network
> > would look like a Layer-3 f= lat network including the ToR to server
> > link and the hyperviso= r would do the tunneling.
> > >
> > > I am not sure= if you got the points above or not. I know cloud OS
> > > comp= anies that provide the service
> > and have big announced customer= s.
> > >
> > > Thanks,
> > > Vishwas> > > On Tue, Aug 9, 2011 at 11:51 AM, Linda Dunbar <dunbar.ll@gmail.com&g= t;
> wrote:
> > > Vishwas,
> > >
> >= > In my mind the bullet 1) in the list refers to ToR switches
> &= gt; > downstream ports (facing servers)
> > running Layer 2 and= ToR uplinks ports run IP Layer 3.
> > >
> > > Have= you seen data center networks with ToR switches downstream
> > &g= t; ports (i.e. facing servers) enabling
> > IP routing, even thoug= h the physical links are Ethernet?
> > > If yes, we should defi= nitely include it in the ARMD draft.
> > >
> > > Th= anks,
> > > Linda
> > > On Tue, Aug 9, 2011 at 12:5= 8 PM, Vishwas Manral
> <vishwas.ietf@gmail.com> wrote:
> > > H= i Linda,
> > > I am unsure what you mean by this, but:
> = > >   * layer 3 all the way to TOR (Top of Rack switches), We ca= n also
> > > have a heirarchical network, with the core totally= Layer-3 (and
> > > having seperate
> > routing), from= the hosts still in a large Layer-3 subnet. Another
> > aspect cou= ld be to have a totally
> > Layer-3 network.
> > >
= > > > The difference between them is the link between the servers = and the
> ToR.
> > >
> > > Thanks,
> &g= t; > Vishwas
> > > On Tue, Aug 9, 2011 at 10:22 AM, Linda Du= nbar <dunbar.ll= @gmail.com>
> wrote:
> > > During the 81st IETF AR= MD WG discussion, it was suggested that it
> is
> > > nec= essary to document typical
> > data center network designs so that= address resolution scaling issues
> > can be properly described. = Many data center operators have expressed
> that they can't openly re= veal their detailed network designs.
> > Therefore, we only want t= o document anonymous designs without too
> much
> > detail. = During the journey of establishing ARMD, we have come across
> the fo= llowing typical data center network designs:
> > >   * lay= er 3 all the way to TOR (Top of Rack switches),
> > >   * = large layer 2 with hundreds (or thousands) of ToRs being
> > > = interconnected by Layer 2. This
> > design will have thousands of = hosts under the L2/L3 boundary router
> > (s)
> > > &n= bsp; * CLOS design  with thousands of switches. This design will have<= br>> > > thousands of hosts under the
> > L2/L3 boundary = router(s)
> > > We have heard that each of the designs above ha= s its own problems.
> > > ARMD problem statements might
>= > need to document DC problems under each typical design.
> > = > Please send feedback to us (either to the armd email list  or to<= br>> the
> > > ARMD chair Benson & Linda) to
> >= ; indicate if we have missed any typical Data Center network designs.
&g= t; > >
> > > Your contribution can greatly accelerate the= progress of ARMD WG.
> > >
> > > Thank you very mu= ch.
> > >
> > > Linda & Benson
> > >= ;

&nbs= p;

 

 

 

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

<= /div>

 

=

 

= --_000_7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8CE07MX14Acorpemcc_-- From bschlies@cisco.com Sun Mar 4 14:06:41 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556AD21F862B for ; Sun, 4 Mar 2012 14:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q83+jlN-7KJf for ; Sun, 4 Mar 2012 14:06:40 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A680321F8604 for ; Sun, 4 Mar 2012 14:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=704; q=dns/txt; s=iport; t=1330898800; x=1332108400; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=Elq/9kXgfubWou4RiVga15yPvC0i40KACzCqkN1RXOY=; b=FMeALp8Zb5mABVjKpFThLhKi+33oA4vN+RxooNAa3kirOPxRUQMLPvn6 Oc1UQOwV6toebmgDKVuXjHS0M72wYarpe8A8bb09KU+fI+h3T+IQ3+tjK huaXtcMwe5/9mNHbsnzwMh8uU4yPwO2sVNdyKXy2P0nFcmgM+BgFOoK+U M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAJDmU0+rRDoJ/2dsb2JhbABDtEKBB4IWAQodNIFcCRmHZAyYRIEnAZ18jTuCP2MEiFCMbpASgwQ X-IronPort-AV: E=Sophos;i="4.73,531,1325462400"; d="scan'208";a="34302142" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 04 Mar 2012 22:06:38 +0000 Received: from dhcp-171-71-146-239.cisco.com (dhcp-171-71-146-239.cisco.com [171.71.146.239]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q24M6bJ1013766 for ; Sun, 4 Mar 2012 22:06:37 GMT From: Benson Schliesser Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Mar 2012 14:06:37 -0800 Message-Id: <0FD4D4B2-3D52-42BF-8A01-25B9754F913B@cisco.com> To: armd@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [armd] Call for Agenda Items (ARMD @ IETF83) X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2012 22:06:41 -0000 ARMD is scheduled to hold a meeting at IETF83 in Paris during the = Afternoon Session II timeslot (1510-1610) on Wednesday, 28-March-2012. = Please see https://datatracker.ietf.org/meeting/83/agenda.html for = updates. If you wish to give a presentation at the upcoming ARMD meeting at = IETF83, please send a message to the chairs (armd-chairs@tools.ietf.org) = and/or this mailing list (armd@ietf.org). All requests must be received by 13-March-2012. Also, all speakers must = have submitted a draft by the cut-off. (See = http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 for details.) = Exceptions will only be made in exceptional circumstances. Cheers, -Benson & Linda From bschlies@cisco.com Sun Mar 4 15:08:23 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55FA21F85C9 for ; Sun, 4 Mar 2012 15:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuWFzOPmJIzJ for ; Sun, 4 Mar 2012 15:08:23 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E5D0321F85C4 for ; Sun, 4 Mar 2012 15:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1282; q=dns/txt; s=iport; t=1330902503; x=1332112103; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=X+wHcgec6HSmnlJnzhIgM4Wl8ap6PUrrw+FBTQdCng4=; b=T05H/2FwdeV8rLFO7kvagPMujCjMim4sq/buh2CNbv1vTcSxAwzpbU73 GhPun5pSVsIgRtY0iZE/2+EG/OnnzGLF7KqT8fZTDADvWHTsDsSdrFkzr wWoBPGsl3AIYf9igXS1n0OZ16Z9NYprpdRk3rmM+AQKfZ47tRThOaJJ5o g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAIj1U0+rRDoI/2dsb2JhbABDtE6BB4IWASc0gX6HZAyfLoEnAZYXjTuCP2MEiFCMbpASgwQ X-IronPort-AV: E=Sophos;i="4.73,531,1325462400"; d="scan'208";a="34439385" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 04 Mar 2012 23:08:22 +0000 Received: from dhcp-171-71-146-239.cisco.com (dhcp-171-71-146-239.cisco.com [171.71.146.239]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q24N8M1C019112 for ; Sun, 4 Mar 2012 23:08:22 GMT From: Benson Schliesser Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Mar 2012 15:08:22 -0800 Message-Id: To: armd@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [armd] Multicast Issues in ARMD Scope X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2012 23:08:23 -0000 ARMD participants - At the last ARMD meeting at IETF82 in Taipei, a few participants made = comments about multicast. Specifically, I recall Dino asking if it was = in the scope of ARMD's charter. More recently, there has been a = discussion on this list about multicast in datacenters. In response, a = draft was posted at = http://tools.ietf.org/html/draft-mcbride-armd-mcast-overview-00 that = discusses various ways that multicast is used in datacenters. As co-chairs, Linda and I are interested in whether the WG has any work = to do on this topic. For instance, draft-mcbride-armd-mcast-overview = suggests there might be "address resolution for non ARP/ND multicast = traffic". My view, in absence of WG feedback, is that ARMD's scope does not = include "how to run multicast in a datacenter" - that might be more = appropriate for the DC-Ops mailing list at this time. But if there are = multicast-related problems that can be described in terms of address = resolution, then ARMD should discuss them. For instance (if I may = speculate) there might be issues with overlay address resolution and/or = group-to-MAC mappings. Can you help me understand what those might be? Your feedback and comments are appreciated. Cheers, -Benson and Linda From mmcbride7@gmail.com Tue Mar 6 14:04:59 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E3F21F861D for ; Tue, 6 Mar 2012 14:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dwOlXiIxtJa for ; Tue, 6 Mar 2012 14:04:59 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD62621F861B for ; Tue, 6 Mar 2012 14:04:58 -0800 (PST) Received: by lagj5 with SMTP id j5so7990948lag.31 for ; Tue, 06 Mar 2012 14:04:57 -0800 (PST) Received-SPF: pass (google.com: domain of mmcbride7@gmail.com designates 10.152.134.146 as permitted sender) client-ip=10.152.134.146; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mmcbride7@gmail.com designates 10.152.134.146 as permitted sender) smtp.mail=mmcbride7@gmail.com; dkim=pass header.i=mmcbride7@gmail.com Received: from mr.google.com ([10.152.134.146]) by 10.152.134.146 with SMTP id pk18mr23341968lab.43.1331071497847 (num_hops = 1); Tue, 06 Mar 2012 14:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TNiel0zk62+z2V6TCRPQZhOeHLtdhocExJYDn91zNjs=; b=haY4m9QTEZRe4zZQLiIRsrek6dzVFdkNsh7acTFzriWzmOtEHPi0YqDqagWSwfPv36 7Gx68lcu6/2LyRtDF/JqSVdIB5VB1MEcvoDzQ167AfGT+pT0pSc7S5z6/UYwDLz/S6jr VqxA1QQHVx4PP0dytvocHCwMWSvP9IHqiMel65jWMsn2a0DWCHxWw1HZ49k4Fve0hLh6 tdPHRTyqWao50UndjUhbtO/i63W1zLmYaclHloL359l3Q+RazGGmN8vJloKp8qYwZmcS IzeDwQdeWGZlTcIEgcLp47HbWZJ3HR2Pv23jybqd4ue43p+L8p3CWxZks3JSt2e4fhrq sBBQ== MIME-Version: 1.0 Received: by 10.152.134.146 with SMTP id pk18mr19151112lab.43.1331071497766; Tue, 06 Mar 2012 14:04:57 -0800 (PST) Received: by 10.112.80.199 with HTTP; Tue, 6 Mar 2012 14:04:57 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Mar 2012 14:04:57 -0800 Message-ID: From: Mike McBride To: Benson Schliesser Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: armd@ietf.org Subject: Re: [armd] Multicast Issues in ARMD Scope X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:04:59 -0000 Benson, I agree. Such a draft may better belong in DC-Ops or MBONED. The topic created a flurry on this list so I thought it would be good to start documenting the uses and problems. IP multicast uses direct mapping for address resolution, so certain, ARMD in the DC, issues may not apply to multicast. I will describe this in the draft but didn't want to step on the toes of armd-problem-statement. You should consider adding some text, in armd-problem-statement, about multicast direct mapping for address resolution, and perhaps some of the other points from my draft. thanks, mike On Sun, Mar 4, 2012 at 3:08 PM, Benson Schliesser wrot= e: > ARMD participants - > > At the last ARMD meeting at IETF82 in Taipei, a few participants made com= ments about multicast. Specifically, I recall Dino asking if it was in the = scope of ARMD's charter. More recently, there has been a discussion on this= list about multicast in datacenters. In response, a draft was posted at ht= tp://tools.ietf.org/html/draft-mcbride-armd-mcast-overview-00 that discusse= s various ways that multicast is used in datacenters. > > As co-chairs, Linda and I are interested in whether the WG has any work t= o do on this topic. For instance, draft-mcbride-armd-mcast-overview suggest= s there might be "address resolution for non ARP/ND multicast traffic". > > My view, in absence of WG feedback, is that ARMD's scope does not include= "how to run multicast in a datacenter" - that might be more appropriate fo= r the DC-Ops mailing list at this time. But if there are multicast-related = problems that can be described in terms of address resolution, then ARMD sh= ould discuss them. For instance (if I may speculate) there might be issues = with overlay address resolution and/or group-to-MAC mappings. Can you help = me understand what those might be? > > Your feedback and comments are appreciated. > > Cheers, > -Benson and Linda > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd From shtsuchi@cisco.com Mon Mar 12 10:31:50 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A5421F8924; Mon, 12 Mar 2012 10:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O-NTgwcUfTe; Mon, 12 Mar 2012 10:31:45 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8C821F891D; Mon, 12 Mar 2012 10:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=4803; q=dns/txt; s=iport; t=1331573505; x=1332783105; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XtnXJw8fKYgm1f8SQYVNshK1tAbAo8x/3LVmwOJkZSY=; b=HJfxkMyQCSUviGXLb7ZNUuoo00fCQFkXmmu0jfMmxFeNvH9FCc186Q6W NsqWtiJAVkkw1hanazMQHe2v3ID1wsdyyuFC5Ewg7CvqdAN0dt9xJ361j +9RC6/+weOcFCJh3Q3Kd12NVhHLUDbAVXNZQPtDKpj2tKSgKhHSD6F9Ah s=; X-IronPort-AV: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="7702899" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 12 Mar 2012 17:31:43 +0000 Received: from [10.71.44.89] (tky-shtsuchi-8918.cisco.com [10.71.44.89]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2CHVVnU032266; Mon, 12 Mar 2012 17:31:32 GMT Message-ID: <4F5E32F2.50302@cisco.com> Date: Tue, 13 Mar 2012 02:31:30 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com><4F320549.20100@cisco.com> <4F34A0AD.4040300@cisco.com> In-Reply-To: <4F34A0AD.4040300@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org, armd@ietf.org Subject: Re: [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 17:31:50 -0000 v6ops I published 04,add some comments. 4.2. Configuration 4.4. Traffic Pattern http://tools.ietf.org/html/draft-sakura-6rd-datacenter-04 I believe native IPv6 data center is ideal,but the operators sometimes can not reach the ideal. Server based 6rd would be useful to provide IPv6 to customer as solution. Could you share presentation time slot in IETF83? Regards, -Shishio (2012/02/10 13:44), Shishio Tsuchiya wrote: > Linda > Thanks for comments. > > (2012/02/10 8:26), Linda Dunbar wrote: >> Shishio, >> >> Thank you very much for sharing the v6 deployment in data center. >> >> I am not an IPv6 expert. So I have a simple question: when you say "server-based 6rd", do you mean that server does the IPv4 encapsulation? > > Yes. > 6rd is IPv6 over IPv4 tunnel technology. > So backbone operator does not need to care to IPv6 on the core. > Additionally 6rd has stateless feature. > Once the operator has placed/configured 6rd BR on the exit point to the IPv6 internet,does not need additional operation to add 6rd CE(server based 6rd). > And if the server would like to go to the IPv6 internet,then IPv4 packets will through 6rd BR and de-capsulate. > If the server would like to communicate other 6rd server within the data center,then IPv4 packets will reach 6rd server directly and de-capsulate. > >> >> >> Does your data center allow hosts/servers under one IPv6 subnet (e.g. /64) to be placed under different server racks? > > In Sakura internet 6rd cases,each of 6rd server has one 6rd delegate prefix(/64). > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03#section-4.1 > > The 6rd delegate prefix calculates from Sakura's IPv6 prefix(/32) and IPv4 address. > Sakura has the scalability problem which is same as ARMD draft. > http://tools.ietf.org/html/draft-ietf-armd-problem-statement-00 > > They also had to update switches to resolve security issue(Rogue RA). > http://tools.ietf.org/html/rfc6104 > > They selected "server-based 6rd" as the solution to avoid scalability and security problem. > > Regards, > -Shishio > > >> >> Thanks, Linda Dunbar >> >> >> >> >> >> On Tue, Feb 7, 2012 at 11:16 PM, Shishio Tsuchiya> wrote: >> >> v6ops and ARMD >> Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd. >> We thought this is interesting idea,so published the draft. >> >> http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 >> >> I think both of mailing list participants are also interesting in this technique. >> If you have any comment and question of the draft,please let me know. >> >> Regards, >> -Shishio >> -------- Original Message -------- >> Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt >> Date: Mon, 14 Nov 2011 17:21:26 +0800 >> From:> >> Reply-To:> >> To:> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : IPv6 Rapid Deployment (6rd) in a Large Data Center >> Author(s) : Shishio Tsuchiya >> Mark Townsley >> Shuichi Ohkubo >> Filename : draft-sakura-6rd-datacenter-03.txt >> Pages : 15 >> Date : 2011-11-14 >> >> IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid >> deployment of IPv6 by an access service provider which has difficulty >> deploying native IPv6. This document describes how 6rd can be used >> to deliver IPv6 within a Large Data Center. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> _______________________________________________ >> armd mailing list >> armd@ietf.org >> https://www.ietf.org/mailman/listinfo/armd >> >> > > From internet-drafts@ietf.org Mon Mar 12 13:15:56 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEE721E80F4; Mon, 12 Mar 2012 13:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYrxnFKoy4wT; Mon, 12 Mar 2012 13:15:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFBC21E80C8; Mon, 12 Mar 2012 13:15:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312201556.19696.53552.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 13:15:56 -0700 Cc: armd@ietf.org Subject: [armd] I-D Action: draft-ietf-armd-problem-statement-02.txt X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 20:15:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Address Resolution for Massive number= s of hosts in the Data center Working Group of the IETF. Title : Problem Statement for ARMD Author(s) : Thomas Narten Manish Karir Ian Foo Filename : draft-ietf-armd-problem-statement-02.txt Pages : 16 Date : 2012-03-12 This document examines address resolution issues related to the massive scaling of data centers. Our initial scope is relatively narrow. Specifically, it focuses on address resolution (ARP and ND) within the data center. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-02.txt From bschlies@cisco.com Mon Mar 12 13:34:41 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E6111E80B8 for ; Mon, 12 Mar 2012 13:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ6ZK6XPEiLr for ; Mon, 12 Mar 2012 13:34:41 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E0DB111E80BA for ; Mon, 12 Mar 2012 13:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1707; q=dns/txt; s=iport; t=1331584480; x=1332794080; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=SKybMgI+kmioKEHuYrVQsfH+TrCdsP/17hcVfARrEEI=; b=U4SN2FCj3hceTHa0xaTMqyGyiehjTs5G7IP+1kRkjyRyum85NsqBLT6R EDbpAobcQSWANjCs/IXh3FP6abAlU60X2wIzrGlYDlkSx4/TAScPAgrZ2 ogPfnZC6Y25X+vg37OGdFNjisOxWD7ZmiIT89LkmUDk9Pq2vDC6AaL8/S g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFldXk+rRDoH/2dsb2JhbABDtVOBB4IJAQEBAwEBAQEPASc0G1EnMBkJGYdjBAydBAGefY1fgj9jBIhUjHiQI4MB X-IronPort-AV: E=Sophos;i="4.73,573,1325462400"; d="scan'208";a="35794708" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 12 Mar 2012 20:34:40 +0000 Received: from sjc-bschlies-8913.cisco.com (sjc-bschlies-8913.cisco.com [10.20.217.228]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2CKYdlT024336 for ; Mon, 12 Mar 2012 20:34:39 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Benson Schliesser In-Reply-To: <20120312201556.19696.53552.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:34:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4298A010-14A4-4D54-862D-6225841170D1@cisco.com> References: <20120312201556.19696.53552.idtracker@ietfa.amsl.com> To: armd@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [armd] WG Last Call: draft-ietf-armd-problem-statement-02.txt X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 20:34:41 -0000 The chairs would like to begin a 2 week Working Group Last Call on the = ARMD Problem Statement document draft-ietf-armd-problem-statement-02. = (See the announcement message quoted below for reference.) Please read = this latest version of the draft, and comment on the mailing list. This = WG LC will close on 26-March-2012. Cheers, -Benson and Linda On Mar 12, 2012, at 3:15 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Address Resolution for = Massive numbers of hosts in the Data center Working Group of the IETF. >=20 > Title : Problem Statement for ARMD > Author(s) : Thomas Narten > Manish Karir > Ian Foo > Filename : draft-ietf-armd-problem-statement-02.txt > Pages : 16 > Date : 2012-03-12 >=20 > This document examines address resolution issues related to the > massive scaling of data centers. Our initial scope is relatively > narrow. Specifically, it focuses on address resolution (ARP and ND) > within the data center. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-02.t= xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-02.tx= t >=20 > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd From bschlies@cisco.com Fri Mar 16 11:56:30 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C9421F85B7 for ; Fri, 16 Mar 2012 11:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2ldYgyJGDOV for ; Fri, 16 Mar 2012 11:56:30 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 457C421F85B4 for ; Fri, 16 Mar 2012 11:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=929; q=dns/txt; s=iport; t=1331924190; x=1333133790; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=vFHQHhN0Lz5oRXS34jNajZZUd8uX6Z8CJFtwpR9M+xw=; b=YAw2uT+tn0fMXGQrolCn75mtv1dpPLErHkoBPMG3JdrLxafLWhS+JKWs jfqKpFk5N2YDKLP7U5sLjWJ5EIrCJYXJ4hr+SV3hN+tbKs369PYxOzbpJ 7K506KO38ysJqKgklv9x47CtGDS+b663ljRmQRvme9BBIxEQMpQ2i5mED w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAO6LY0+rRDoH/2dsb2JhbABCtjaBB4IJAQEBAwESAQodNBALC0ZXGQkZh2MEDJo9nyyNW4I/YwSIVo0Qjj+BaIME X-IronPort-AV: E=Sophos;i="4.73,598,1325462400"; d="scan'208";a="33882851" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 16 Mar 2012 18:56:30 +0000 Received: from sjc-bschlies-8913.cisco.com (sjc-bschlies-8913.cisco.com [10.20.217.228]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2GIuTQv032126 for ; Fri, 16 Mar 2012 18:56:29 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Benson Schliesser In-Reply-To: <0FD4D4B2-3D52-42BF-8A01-25B9754F913B@cisco.com> Date: Fri, 16 Mar 2012 13:56:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <913FF5C1-3466-4B99-9A2A-C0206B0E7F56@cisco.com> References: <0FD4D4B2-3D52-42BF-8A01-25B9754F913B@cisco.com> To: armd@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [armd] Call for Agenda Items (ARMD @ IETF83) X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 18:56:30 -0000 The agenda for ARMD at IETF 83 has been posted at = http://www.ietf.org/proceedings/83/agenda/agenda-83-armd.html. Cheers, -Benson On Mar 4, 2012, at 4:06 PM, Benson Schliesser wrote: > ARMD is scheduled to hold a meeting at IETF83 in Paris during the = Afternoon Session II timeslot (1510-1610) on Wednesday, 28-March-2012. = Please see https://datatracker.ietf.org/meeting/83/agenda.html for = updates. >=20 > If you wish to give a presentation at the upcoming ARMD meeting at = IETF83, please send a message to the chairs (armd-chairs@tools.ietf.org) = and/or this mailing list (armd@ietf.org). >=20 > All requests must be received by 13-March-2012. Also, all speakers = must have submitted a draft by the cut-off. (See = http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 for details.) = Exceptions will only be made in exceptional circumstances. >=20 > Cheers, > -Benson & Linda >=20 From bschlies@cisco.com Fri Mar 16 12:18:07 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94FA21E8028 for ; Fri, 16 Mar 2012 12:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vplkDfDWYOjE for ; Fri, 16 Mar 2012 12:18:07 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 68F0421E8068 for ; Fri, 16 Mar 2012 12:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=959; q=dns/txt; s=iport; t=1331925486; x=1333135086; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=1Vst/1ijHLUdonIxljEdeKHlD7rVkGoPo8F/5mPEOuA=; b=DmFcRncJTAmoZPhWVmJsdUlUZt5rU1E8lmifMo79c9YEduaogeFH71Rv uJOyPk+nk0PCImqmp5HiWhpHkJmZ6aLFW7iE8ZsJpntylIWWMlAYe7rlL ZH0mzEByIb1VqEmWoKMi1qwN/jPT/uHwbeASRESYurJbFy0YZzIGU0YnJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAFaRY0+rRDoH/2dsb2JhbABCtjqBB4IiAQUiNIFlGYdnDJkkgSefL4pGgxWCP2MEiFaCYYovhlyHY4FogwSBPg X-IronPort-AV: E=Sophos;i="4.73,598,1325462400"; d="scan'208";a="36372022" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 16 Mar 2012 19:18:06 +0000 Received: from sjc-bschlies-8913.cisco.com (sjc-bschlies-8913.cisco.com [10.20.217.228]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2GJI504014154 for ; Fri, 16 Mar 2012 19:18:06 GMT From: Benson Schliesser Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2012 14:18:05 -0500 Message-Id: <770B917D-FA48-449E-AF1B-594AB12F37FD@cisco.com> To: armd@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [armd] Milestones Update X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 19:18:07 -0000 ARMD Participants - Per the "Work Plan" that I sent to ARMD Mailing List in mid-December = (http://www.ietf.org/mail-archive/web/armd/current/msg00375.html), there = are a couple Milestones that I'd like to remove from our Charter. = Specifically, here is what I proposed: =20 "3. The Survey of Existing Implementations milestone was deemed useful, = but there were no volunteers to work on it. Unless somebody commits to = produce text on this topic we will drop the milestone from our work = plan. =20 "4. The Survey of Security milestone was less interesting to the = participants in Taipei. Unless there is specific interest in this = milestone, including one or more committed contributors, we will drop = this milestone from our work plan." =20 There has been no feedback from the mailing list. Thus I conclude that = we have no interest in these items, and we do have consensus to drop = them from our Charter. Cheers, -Benson From bschlies@cisco.com Fri Mar 16 14:01:35 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50AE21E8028 for ; Fri, 16 Mar 2012 14:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzCKWm84pWdn for ; Fri, 16 Mar 2012 14:01:35 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 10B0D21E8024 for ; Fri, 16 Mar 2012 14:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1480; q=dns/txt; s=iport; t=1331931695; x=1333141295; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=wedH/MUs3jKIUinbCaI+9z3hYWkOdebG7T2RlZw89B0=; b=W2BnKCPUzq/+6Yy1v55lE4pP9HStAj1qUyCiH6kZ9Yn2x1KZyn4GAjOl yksejLYeV75Gv+opurvwl3OyrMJPUK5QEiTpATCkuGzG1cCygLAK70SLo MArfn8dQjZEQWig/jEYKObYXAMl17iVl8xbXqqTJSXE5X/PSfo5dG4B3g U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAESpY0+rRDoH/2dsb2JhbABCtjqBB4IiASc0gWUZh2cMmReBJ58jikaDFYI/YwSIVo0Qjj+BaIMEgT4 X-IronPort-AV: E=Sophos;i="4.73,599,1325462400"; d="scan'208";a="33362925" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 16 Mar 2012 21:01:34 +0000 Received: from sjc-bschlies-8913.cisco.com (sjc-bschlies-8913.cisco.com [10.20.217.228]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2GL1YJV013605 for ; Fri, 16 Mar 2012 21:01:34 GMT From: Benson Schliesser Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2012 16:01:33 -0500 Message-Id: <7B1D583B-772C-4136-84A7-DB771169A427@cisco.com> To: armd@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [armd] Disposition of draft-karir-armd-statistics by ARMD WG X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 21:01:36 -0000 ARMD Participants - The WG co-chairs and the draft's authors would appreciate WG feedback on = the future of draft-karir-armd-statistics. The document can be found at = http://tools.ietf.org/html/draft-karir-armd-statistics-02. The chairs asked if there was consensus for Adoption amongst the = attendees at the IETF-82 ARMD meeting in Taipei. Subsequently, this = action was proposed in the Work Plan posted to the ARMD mailing list in = mid-December = (http://www.ietf.org/mail-archive/web/armd/current/msg00375.html): "2. = There was interest in having more data in the ARP/ND statistics document = draft-karir-armd-statistics-01, but there was little interest in = contributing such data. Unless there are contributions to this document = in the near future it will be moved to last-call." Since then, there has been no further mailing list discussion of the = draft, but a few participants have given private feedback. As a result = of this feedback, we are unsure whether to adopt the draft or abandon = it. If adopted by the WG, the chairs intend for this draft to fulfill = our 2nd chartered milestone, which currently says: "ARP/ND statistics = collection and behavior analysis [...]". If abandoned, in absence of an = improved replacement, the chairs intend to drop that milestone from the = charter. Please provide feedback and discussion on the mailing list, so that we = can decide how to proceed with this draft. Cheers, -Benson From bschlies@cisco.com Fri Mar 16 15:51:11 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB22921E8029 for ; Fri, 16 Mar 2012 15:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIo7d9WE8pm0 for ; Fri, 16 Mar 2012 15:51:11 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F11CD21E8014 for ; Fri, 16 Mar 2012 15:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1694; q=dns/txt; s=iport; t=1331938271; x=1333147871; h=from:subject:date:message-id:to:mime-version; bh=z3q9/vH3S6Tknff/1GsFm2FgJ/9sbNAiqudnozo9OI4=; b=C0c+zrecX5adxR7n4W+hpQqhkKYPMorxnd9m6MfavG1RlyFuByc/ET3f Gu3bkjrQH9ilvr47YPlYPNi1cw5OCIFPTDPZ9/U3/XAOgfERIfbQoPNgb oOyoDIwetPgePTyt9ZJNgYnWx6hxO2o6rroHtJNiwb7BIZDqwltFjQT9u w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUJAATDY0+rRDoG/2dsb2JhbABCrUoBHYhSgQeCAAUdAYEEAYFNB4UmB4IpEQyZIIEnnxyNW4I/YwSIVo0Qjj+BaIME X-IronPort-AV: E=Sophos;i="4.73,599,1325462400"; d="scan'208,217";a="36496488" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 16 Mar 2012 22:51:10 +0000 Received: from sjc-bschlies-8913.cisco.com (sjc-bschlies-8913.cisco.com [10.20.217.228]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2GMpAKp017551 for ; Fri, 16 Mar 2012 22:51:10 GMT From: Benson Schliesser Content-Type: multipart/alternative; boundary=Apple-Mail-15--703732258 Date: Fri, 16 Mar 2012 17:51:09 -0500 Message-Id: <15B73861-C485-48F7-BB01-0F93BA0DB7AE@cisco.com> To: armd@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [armd] draft-nachum-sarp X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 22:51:11 -0000 --Apple-Mail-15--703732258 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks,=20 An independent draft has been published that may be of interest to ARMD = participants at http://tools.ietf.org/html/draft-nachum-sarp-01. The = Independent Submissions Editor (ISE) has been asked to publish it as an = RFC, and subsequently asked if we had any comments. Given that it describes a solution, draft-nachum-sarp is not within the = current scope of ARMD's charter. However, its topic should be familiar = to ARMD participants. If you wish to review the draft and provide = feedback to the ISE, please let me know. Cheers, -Benson --Apple-Mail-15--703732258 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Folks, 

An independent draft has been published that may be of interest to ARMD participants at http://tools.ietf.org/html/draft-nachum-sarp-01. The Independent Submissions Editor (ISE) has been asked to publish it as an RFC, and subsequently asked if we had any comments.

Given that it describes a solution, draft-nachum-sarp is not within the current scope of ARMD's charter. However, its topic should be familiar to ARMD participants. If you wish to review the draft and provide feedback to the ISE, please let me know.

Cheers,
-Benson

--Apple-Mail-15--703732258-- From bschlies@cisco.com Fri Mar 16 18:45:51 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838DF21E8026 for ; Fri, 16 Mar 2012 18:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0GIZFb0wfda for ; Fri, 16 Mar 2012 18:45:50 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDFD21E800F for ; Fri, 16 Mar 2012 18:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1032; q=dns/txt; s=iport; t=1331948750; x=1333158350; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QhR2l6uiykdYqv4zOdpZnYRO7f9vdB1T9Mt6z7qgcik=; b=VlIVnQ2bfg/xouFCQ/bBvQJLOpVgYeJKEbircCfPxGhv2XhCrLVpCVor tWgIyfcqgMlHdEkuv9rOTriW/oINI/kQRM+K45ikGaCLzRfFD5bckzC5d 7NI24q4ZEMzNFu2dxcxDvtSUh3agOlQlKidpoX7xo0S1pAGAQbDo9gkWZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD3sY0+rRDoJ/2dsb2JhbABCtj+BB4IJAQEBAwESASc/BQsFBkZXGRsHh2MEmlufIY1Xgj9jBIhWjRCOP4FogwSBPg X-IronPort-AV: E=Sophos;i="4.73,601,1325462400"; d="scan'208";a="33395816" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 17 Mar 2012 01:45:50 +0000 Received: from sjc-bschlies-8913.cisco.com (sjc-bschlies-8913.cisco.com [10.20.217.228]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2H1jnmI005966; Sat, 17 Mar 2012 01:45:50 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Benson Schliesser X-Priority: Normal In-Reply-To: <891938359-1331945722-cardhu_decombobulator_blackberry.rim.net-709240019-@b27.c6.bise6.blackberry> Date: Fri, 16 Mar 2012 20:45:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4F322E08-A1A2-46ED-970B-DB0BECD36CA2@cisco.com> References: <15B73861-C485-48F7-BB01-0F93BA0DB7AE@cisco.com> <891938359-1331945722-cardhu_decombobulator_blackberry.rim.net-709240019-@b27.c6.bise6.blackberry> To: shares@ndzh.com X-Mailer: Apple Mail (2.1084) Cc: armd@ietf.org Subject: Re: [armd] draft-nachum-sarp X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 17 Mar 2012 01:45:51 -0000 On Mar 16, 2012, at 7:55 PM, shares@ndzh.com wrote: > By independent draft do you mean independent editor stream. Yes, it is my understanding that the authors wish to publish = draft-nachum-sarp via the Independent Submission Stream. Linda and I received an email from the Independent Submission Editor = (Nevil Brownlee) about this draft. The authors had sent him the draft as = an Independent Submission. He said that the authors suggested that the = topic was discussed in ARMD WG, and he asked if the WG would have any = objection to its publication in the Independent Stream. Linda and I consulted with each other, and we consulted with our AD (Ron = Bonica), and we all agreed that it is not within ARMD's current scope = because it is a solution-focused draft. Therefore the ARMD WG doesn't = have a position on its publication. However, we also agreed that = individual contributors within ARMD might be interested in reviewing the = draft and providing their feedback to the ISE. Cheers, -Benson From bschlies@cisco.com Mon Mar 19 22:33:50 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C29321E8057 for ; Mon, 19 Mar 2012 22:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM5OXgk9YNbQ for ; Mon, 19 Mar 2012 22:33:49 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9783621E803F for ; Mon, 19 Mar 2012 22:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=2096; q=dns/txt; s=iport; t=1332221629; x=1333431229; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=Wj9/eSgQ4r5D55LqLBMqbwfInAf71YJXWFpRHUSukpc=; b=kJTB20VgcPKbixBFGuzC9Sq2qlKYHf0boGtYPvtr39Z82+/hqlVZycj/ IAgQ8nrzP302dN6BcvmCVqTmKkZhjmkwW2wSHRtGcTDCN0UiMxg6bmUUW FAXrKUd9iCVMCARoPB3F+5+7JaIKGEN55EgH/NtC3d/WmsvGRtQeUXFMV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAGAIMVaE+rRDoH/2dsb2JhbABBgw2zQoEHggkBAQEDAQEBAQ8BJzQQCwsYLicwGQkZh2MEDJhcnxONP4I/YwSIVo0JhW2IUoFogwQ X-IronPort-AV: E=Sophos;i="4.73,616,1325462400"; d="scan'208";a="36741547" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 20 Mar 2012 05:33:49 +0000 Received: from [192.168.0.196] (sjc-vpn1-224.cisco.com [10.21.96.224]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2K5XmEN022901 for ; Tue, 20 Mar 2012 05:33:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Benson Schliesser In-Reply-To: <4298A010-14A4-4D54-862D-6225841170D1@cisco.com> Date: Tue, 20 Mar 2012 00:33:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <573146A8-49CC-4669-9B92-D33EC318AE6B@cisco.com> References: <20120312201556.19696.53552.idtracker@ietfa.amsl.com> <4298A010-14A4-4D54-862D-6225841170D1@cisco.com> To: armd@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [armd] WG Last Call: draft-ietf-armd-problem-statement-02.txt X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 05:33:50 -0000 This is just a reminder: we are in WG LC for = draft-ietf-armd-problem-statement-02 until 26-Mar-2012. Please review = and post comments of support, non-support, etc. Silence will be = interpreted as consensus. But a discussion would be even better. Cheers, -Benson On Mar 12, 2012, at 3:34 PM, Benson Schliesser wrote: > The chairs would like to begin a 2 week Working Group Last Call on the = ARMD Problem Statement document draft-ietf-armd-problem-statement-02. = (See the announcement message quoted below for reference.) Please read = this latest version of the draft, and comment on the mailing list. This = WG LC will close on 26-March-2012. >=20 > Cheers, > -Benson and Linda >=20 >=20 > On Mar 12, 2012, at 3:15 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Address Resolution for = Massive numbers of hosts in the Data center Working Group of the IETF. >>=20 >> Title : Problem Statement for ARMD >> Author(s) : Thomas Narten >> Manish Karir >> Ian Foo >> Filename : draft-ietf-armd-problem-statement-02.txt >> Pages : 16 >> Date : 2012-03-12 >>=20 >> This document examines address resolution issues related to the >> massive scaling of data centers. Our initial scope is relatively >> narrow. Specifically, it focuses on address resolution (ARP and ND) >> within the data center. >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-02.t= xt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-02.tx= t >>=20 >> _______________________________________________ >> armd mailing list >> armd@ietf.org >> https://www.ietf.org/mailman/listinfo/armd >=20 From linda.dunbar@huawei.com Thu Mar 29 06:21:07 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651C821F8B5F for ; Thu, 29 Mar 2012 06:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL2epU+10WNd for ; Thu, 29 Mar 2012 06:21:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 05F9221F8B59 for ; Thu, 29 Mar 2012 06:21:05 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM28646; Thu, 29 Mar 2012 09:21:00 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 06:18:56 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 06:18:57 -0700 From: Linda Dunbar To: Kireeti Kompella , "Benson Schliesser (bschlies)" Thread-Topic: draft-dunbar-armd-arp-nd-scaling Thread-Index: Ac0Nq0qMQY3ju3L+RzOVRoXt7M6mNQAARIaA Date: Thu, 29 Mar 2012 13:18:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F632E54430@dfweml505-mbx> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "armd@ietf.org" Subject: Re: [armd] draft-dunbar-armd-arp-nd-scaling X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 13:21:07 -0000 Kireeti,=20 Thank you very much for the very constructive comments. =20 My reply and follow up is inserted below: Linda > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Thursday, March 29, 2012 7:56 AM > To: Linda Dunbar; Benson Schliesser (bschlies) > Cc: Kireeti Kompella > Subject: draft-dunbar-armd-arp-nd-scaling >=20 > Hi Linda, Benson: >=20 > My promised review: >=20 > High-level: seems useful as a bag of techniques that DC providers can > use. >=20 > The recommendations come in several flavors. Some are for DC providers; > some are for the IETF. What might work is to put recommendations for > DC providers in each section, and put the suggestions for IETF protocol > changes in a "Future Work" section. [Linda] Will do.=20 >=20 > Also, is there a sense of how comprehensive this discussion of > techniques for scaling ARP/ND is? [Linda] The draft is about practices which can be used to reduce the amount= of ARP/ND requests to be handled by L2/L3 boundary routers. So we call it= "scaling ARP/ND". Do you have a better term? We need to change the name in= removing the wording "BCP".=20 >=20 > Details: > a) Abstract: data center environment =3D> data center environments > b) spurious "0" at end of Conventions used > c) reference [ARMD-problems] needs to be fixed (cf with section 3.1) > d) Suggested rewrite for 3.2: >=20 > If a Layer 2 domain consists of several subnets (or VLANs) whose > aggregate number of hosts is large, the L2/L3 boundary routers can > be heavily impacted by the number of ARP/ND broadcast/multicast > messages received from those hosts. This section describes some > commonly used practices in reducing the ARP/ND processing required > on L2/L3 boundary (or gateway) routers for some common traffic > patterns. >=20 [Linda] Thanks for the good suggestion.=20 > e) 3.2.1: > Recommendation: Use in IPv4-only networks. >=20 > [drop suggestions to change IPv6] [Linda] OK >=20 > f) 3.2.2, first para, first line: > When the source address is in a different subnet and the target >=20 > Suggestion: change "target" to "destination address". [Linda] Sure.=20 >=20 > g) remove suggestion to change IPv6 ND protocol in Recommendation. [Linda] Sure.=20 >=20 > h) 3.3: Disadvantage should mention that if ARP mappings change or go > away, static entries could lead to persistent packet loss. >=20 > i) 3.3: Recommendation > Most of the recommendations are for the data center provider. Stuff > like "change IPv6 ND protocol" and "Ask IETF to create new protocol" > seem out of place. (Orthogonally, I don't see the IETF dealing with > static ARP entries.) [Linda] OK.=20 >=20 > j) 3.4: calling this technique "elegant" is a value judgment whose > validity I cannot comment on; however, it seems out of place. >=20 [Linda] Is it better to remove this section?=20 > k) 3.4: Recommendation: remove the first sentence (redundant with the > Disadvantage). [Linda] Sure >=20 > l) 3.5, first para: redundant period at end of para. [Linda] good catch.=20 >=20 > m) 3.5: Recommendation: see early comment on recommendation. >=20 > n) 4.: Perhaps call this Future Work, and focus on protocol extensions > that might help this issue. [Linda] good idea.=20 >=20 > o) 6.: if (as is possible) there is no future document, then some > mumble on security in _this_ document. [Linda] Sure.=20 >=20 >=20 > Kireeti. From kireeti@juniper.net Thu Mar 29 06:46:49 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA40821F8AF4 for ; Thu, 29 Mar 2012 06:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu73nnIB3bQC for ; Thu, 29 Mar 2012 06:46:49 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0A73021F8597 for ; Thu, 29 Mar 2012 06:46:39 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT3Rnt+Nujs3PZ7NWg64gCmNiwh4Bq0aI@postini.com; Thu, 29 Mar 2012 06:46:40 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 29 Mar 2012 06:45:48 -0700 From: Kireeti Kompella To: Linda Dunbar Date: Thu, 29 Mar 2012 06:45:47 -0700 Thread-Topic: draft-dunbar-armd-arp-nd-scaling Thread-Index: Ac0Nsj8epnVokHvlT4m9/MlZ3b7SoQ== Message-ID: <9E6D80F7-9DF5-4B34-8D06-839E2ADD46C6@juniper.net> References: <4A95BA014132FF49AE685FAB4B9F17F632E54430@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F632E54430@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "armd@ietf.org" Subject: Re: [armd] draft-dunbar-armd-arp-nd-scaling X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 13:46:50 -0000 On Mar 29, 2012, at 3:18 PM, Linda Dunbar wrote: >> Also, is there a sense of how comprehensive this discussion of >> techniques for scaling ARP/ND is? >=20 > [Linda] The draft is about practices which can be used to reduce the amou= nt of ARP/ND requests to be handled by L2/L3 boundary routers. So we call = it "scaling ARP/ND". Do you have a better term? We need to change the name = in removing the wording "BCP".=20 How about: Common Practices for Scaling ARP and ND Request Handling >> j) 3.4: calling this technique "elegant" is a value judgment whose >> validity I cannot comment on; however, it seems out of place. >>=20 > [Linda] Is it better to remove this section?=20 No, especially if, as it says, this is an extensively used technique. If f= olks think that this technique is elegant, that's fine. Otherwise change l= ast sentence to: However, this technique may not be appropriate for generic host migration. Kireeti.