From ldunbar@huawei.com Sun Nov 7 05:47:28 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEFD3A6A5F for ; Sun, 7 Nov 2010 05:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1BbXXvCpT2f for ; Sun, 7 Nov 2010 05:47:26 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id C7F7A3A68D3 for ; Sun, 7 Nov 2010 05:47:26 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBI000K7OZKQP@usaga03-in.huawei.com> for armd@ietf.org; Sun, 07 Nov 2010 07:47:45 -0600 (CST) Received: from L735042 (3.97.247.60.static.bjtelecom.net [60.247.97.3]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBI0081BOZIU3@usaga03-in.huawei.com> for armd@ietf.org; Sun, 07 Nov 2010 07:47:44 -0600 (CST) Date: Sun, 07 Nov 2010 21:47:51 +0800 From: Linda Dunbar To: armd@ietf.org Message-id: <005301cb7e82$6081aaf0$84418182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_25nholxttHa6HfAAoed9DA)" Thread-index: Act+gl74yQRQ1tuuS5O5UKqH5cAVGQ== Cc: 'Jari Arkko' Subject: [armd] ARMD BOF agenda and details X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 13:47:28 -0000 This is a multi-part message in MIME format. --Boundary_(ID_25nholxttHa6HfAAoed9DA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT ARMD BOF will be Friday Nov 12, 9am~11:30am at Garden Ballroom. Detailed agenda has been posted on the wiki website. http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD%20-%20BOF %20agenda%20at%2079th%20IETF.ppt Looking forward to seeing most of you in Beijing. Linda Dunbar --Boundary_(ID_25nholxttHa6HfAAoed9DA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

ARMD BOF will be Friday Nov 12, 9am~11:30am at Garden Ballroom.

Detailed agenda has been posted on the wiki website.

 

http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD%20-%20BOF%20agenda%20at%2079th%20IETF.ppt

 

 

Looking forward to seeing most of you in Beijing.

 

Linda Dunbar

 

--Boundary_(ID_25nholxttHa6HfAAoed9DA)-- From ldunbar@huawei.com Mon Nov 8 21:32:16 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCC73A690A for ; Mon, 8 Nov 2010 21:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBz3B3y+M6dg for ; Mon, 8 Nov 2010 21:32:14 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id CD37B3A68EC for ; Mon, 8 Nov 2010 21:32:11 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBL00828RE8HQ@usaga01-in.huawei.com> for armd@ietf.org; Mon, 08 Nov 2010 21:32:32 -0800 (PST) Received: from L735042 (dhcp-81e9.meeting.ietf.org [130.129.129.233]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBL00FSIRE1AZ@usaga01-in.huawei.com> for armd@ietf.org; Mon, 08 Nov 2010 21:32:32 -0800 (PST) Date: Tue, 09 Nov 2010 13:32:32 +0800 From: Linda Dunbar To: armd@ietf.org Message-id: <005001cb7fcf$85f89610$e9818182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_r/f7xxLEMg1nukMAAzaEbg)" Thread-index: Act/z4HacNsXQUGVQK6QyJPqySfoWQ== Cc: 'Jari Arkko' , 'Hares Susan' Subject: [armd] Latest ARMD charter statement X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 05:32:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_r/f7xxLEMg1nukMAAzaEbg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I made some minor word changes to ARMD charter statement as suggested by Sridhar. The latest version is uploaded to the Wiki website: http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD%20charter %20and%20milestones%20v5.docx For those of you interested in seeing the charter with Change bar enabled, you can see this version: http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD%20charter %20and%20milestones%20v5%20chg%20bar.docx ARMD BOF is Friday 9am at Garden Ballroom 1 (First Level) Linda Dunbar --Boundary_(ID_r/f7xxLEMg1nukMAAzaEbg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I made some minor word changes to ARMD charter statement as suggested by Sridhar.

 

The latest version is uploaded to the Wiki website:

http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD%20charter%20and%20milestones%20v5.docx

 

For those of you interested in seeing the charter with Change bar enabled, you can see this version:

 

http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD%20charter%20and%20milestones%20v5%20chg%20bar.docx

 

ARMD BOF is Friday 9am at Garden Ballroom 1 (First Level)

 

Linda Dunbar

 

--Boundary_(ID_r/f7xxLEMg1nukMAAzaEbg)-- From julienl@qualcomm.com Mon Nov 8 23:28:15 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9183A67AF for ; Mon, 8 Nov 2010 23:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWKpxFVJMprb for ; Mon, 8 Nov 2010 23:28:14 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0C9263A67B8 for ; Mon, 8 Nov 2010 23:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1289287717; x=1320823717; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Linda=20Dunbar=20,=20"armd@iet f.org"=20|CC:=20'Jari=20Arkko'=20|Date:=20Mon,=208=20Nov=202010=2023:28:04=20 -0800|Subject:=20RE:=20[armd]=20ARMD=20BOF=20agenda=20and =20details|Thread-Topic:=20[armd]=20ARMD=20BOF=20agenda =20and=20details|Thread-Index:=20Act+gl74yQRQ1tuuS5O5UKqH 5cAVGQBXTiRw|Message-ID:=20|References:=20 <005301cb7e82$6081aaf0$84418182@china.huawei.com> |In-Reply-To:=20<005301cb7e82$6081aaf0$84418182@china.hua wei.com>|Accept-Language:=20en-US|Content-Language:=20en- US|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_BF345F63074F8040B58C00A186FCA57F29F6C 37774NALASEXMB04na_"|MIME-Version:=201.0; bh=Kc8K5OqHTfGs9Jxs3sCxEwz45X+KupDjAkYe5o87Mpg=; b=gK89lyZyIgNhSSsN5rxXdqrIC8oIitGUlZ+xwPNYEbnwIOitNwSiz2V7 sAmjxIl7tVjIoWxXAhRuA9EQcB+pmkR3pLYqW+z3CcCAq8Pg2tqzflCPB nM2vffg0fPL7Qpp/tFysTsl0tbpVUU568ey6EgpYyTbskDOE7PJ82h/H5 Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6161"; a="61166607" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 08 Nov 2010 23:28:07 -0800 X-IronPort-AV: E=Sophos;i="4.59,172,1288594800"; d="scan'208,217";a="7989022" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 08 Nov 2010 23:28:07 -0800 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 8 Nov 2010 23:28:07 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Mon, 8 Nov 2010 23:28:06 -0800 From: "Laganier, Julien" To: Linda Dunbar , "armd@ietf.org" Date: Mon, 8 Nov 2010 23:28:04 -0800 Thread-Topic: [armd] ARMD BOF agenda and details Thread-Index: Act+gl74yQRQ1tuuS5O5UKqH5cAVGQBXTiRw Message-ID: References: <005301cb7e82$6081aaf0$84418182@china.huawei.com> In-Reply-To: <005301cb7e82$6081aaf0$84418182@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BF345F63074F8040B58C00A186FCA57F29F6C37774NALASEXMB04na_" MIME-Version: 1.0 Cc: 'Jari Arkko' Subject: Re: [armd] ARMD BOF agenda and details X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 07:28:15 -0000 --_000_BF345F63074F8040B58C00A186FCA57F29F6C37774NALASEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda and some of the meeting material is posted at the usual place: https://datatracker.ietf.org/meeting/79/materials.html --julien From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Lin= da Dunbar Sent: Sunday, November 07, 2010 6:48 AM To: armd@ietf.org Cc: 'Jari Arkko' Subject: [armd] ARMD BOF agenda and details ARMD BOF will be Friday Nov 12, 9am~11:30am at Garden Ballroom. Detailed agenda has been posted on the wiki website. http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD%20-%20BO= F%20agenda%20at%2079th%20IETF.ppt Looking forward to seeing most of you in Beijing. Linda Dunbar --_000_BF345F63074F8040B58C00A186FCA57F29F6C37774NALASEXMB04na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agenda and some of the meeting material is posted at the usu= al place:

 

https://dat= atracker.ietf.org/meeting/79/materials.html

 

--julien

 

From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Li= nda Dunbar
Sent: Sunday, November 07, 2010 6:48 AM
To: armd@ietf.org
Cc: 'Jari Arkko'
Subject: [armd] ARMD BOF agenda and details

 

ARMD = BOF will be Friday Nov 12, 9am~11:30am at Garden Ballroom.

Detai= led agenda has been posted on the wiki website.

=  

http://trac.tools.ietf.org/bof/t= rac/attachment/wiki/WikiStart/ARMD%20-%20BOF%20agenda%20at%2079th%20IETF.pp= t

=  

=  

Looki= ng forward to seeing most of you in Beijing.

=  

Linda= Dunbar

 

--_000_BF345F63074F8040B58C00A186FCA57F29F6C37774NALASEXMB04na_-- From julienl@qualcomm.com Thu Nov 11 16:37:44 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC353A6803 for ; Thu, 11 Nov 2010 16:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMlMZRsRi-f5 for ; Thu, 11 Nov 2010 16:37:42 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 8E2E53A6452 for ; Thu, 11 Nov 2010 16:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1289522288; x=1321058288; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"armd@ietf.org"=20,=20Susan=20Hares =20|Date:=20Thu,=2011=20Nov=202010=2016:38: 04=20-0800|Subject:=20RE:=20[armd]=20ARMD=20BOF=20agenda =20and=20details|Thread-Topic:=20[armd]=20ARMD=20BOF=20ag enda=20and=20details|Thread-Index:=20Act+gl74yQRQ1tuuS5O5 UKqH5cAVGQBXTiRwAIiK4TA=3D|Message-ID:=20 |References:=20<005301cb7e82$6081aaf0$84418182@china.huaw ei.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_BF345F63074F8040B58C00A186FCA57F29F6E 77FFANALASEXMB04na_"|MIME-Version:=201.0; bh=sANQTMSNAnkE5o5rsIMsH2ZzvVMTZOi73Af2nsOd34E=; b=MPq1P5kZuYqUrloRAd9qkBmnp7hpTIe+yZGhsK9tt+sWWiNpjoQv78+j ZPTWJVVYU6OTtffojD+21XJrz5Icq3i/W9xi+Z5tLhETuhl6O4siAgrh9 0CLz1lRTL1bAkvIrUqrSVZ3yGYuSGDBfFH4MHANDOQVyG/wvdAE0q7r0U I=; X-IronPort-AV: E=McAfee;i="5400,1158,6164"; a="61657391" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 11 Nov 2010 16:38:07 -0800 X-IronPort-AV: E=Sophos;i="4.59,183,1288594800"; d="scan'208,217";a="8926177" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 11 Nov 2010 16:38:07 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 11 Nov 2010 16:38:07 -0800 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 11 Nov 2010 16:38:07 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Thu, 11 Nov 2010 16:38:07 -0800 From: "Laganier, Julien" To: "armd@ietf.org" , Susan Hares Date: Thu, 11 Nov 2010 16:38:04 -0800 Thread-Topic: [armd] ARMD BOF agenda and details Thread-Index: Act+gl74yQRQ1tuuS5O5UKqH5cAVGQBXTiRwAIiK4TA= Message-ID: References: <005301cb7e82$6081aaf0$84418182@china.huawei.com> In-Reply-To: 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_BF345F63074F8040B58C00A186FCA57F29F6E77FFANALASEXMB04na_" MIME-Version: 1.0 Subject: Re: [armd] ARMD BOF agenda and details X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 00:37:44 -0000 --_000_BF345F63074F8040B58C00A186FCA57F29F6E77FFANALASEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Final Agenda and all meeting material is uploaded: https://datatracker.ietf.org/meeting/79/materials.html --julien From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Lag= anier, Julien Sent: Tuesday, November 09, 2010 12:28 AM To: Linda Dunbar; armd@ietf.org Cc: 'Jari Arkko' Subject: Re: [armd] ARMD BOF agenda and details Agenda and some of the meeting material is posted at the usual place: https://datatracker.ietf.org/meeting/79/materials.html --julien From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Lin= da Dunbar Sent: Sunday, November 07, 2010 6:48 AM To: armd@ietf.org Cc: 'Jari Arkko' Subject: [armd] ARMD BOF agenda and details ARMD BOF will be Friday Nov 12, 9am~11:30am at Garden Ballroom. Detailed agenda has been posted on the wiki website. http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD%20-%20BO= F%20agenda%20at%2079th%20IETF.ppt Looking forward to seeing most of you in Beijing. Linda Dunbar --_000_BF345F63074F8040B58C00A186FCA57F29F6E77FFANALASEXMB04na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Final Agenda and all meeting material is uploaded:

 

https://dat= atracker.ietf.org/meeting/79/materials.html

 

--julien

 

From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of La= ganier, Julien
Sent: Tuesday, November 09, 2010 12:28 AM
To: Linda Dunbar; armd@ietf.org
Cc: 'Jari Arkko'
Subject: Re: [armd] ARMD BOF agenda and details

 

Agenda and some of the meeting material is posted at the usu= al place:

 

https://dat= atracker.ietf.org/meeting/79/materials.html

 

--julien

 

From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Li= nda Dunbar
Sent: Sunday, November 07, 2010 6:48 AM
To: armd@ietf.org
Cc: 'Jari Arkko'
Subject: [armd] ARMD BOF agenda and details

 

ARMD = BOF will be Friday Nov 12, 9am~11:30am at Garden Ballroom.

Detai= led agenda has been posted on the wiki website.

=  

http://trac.tools.ietf.org/bof/t= rac/attachment/wiki/WikiStart/ARMD%20-%20BOF%20agenda%20at%2079th%20IETF.pp= t

=  

=  

Looki= ng forward to seeing most of you in Beijing.

=  

Linda= Dunbar

 

--_000_BF345F63074F8040B58C00A186FCA57F29F6E77FFANALASEXMB04na_-- From xuxh@huawei.com Thu Nov 11 18:30:51 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE613A6860 for ; Thu, 11 Nov 2010 18:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.187 X-Spam-Level: **** X-Spam-Status: No, score=4.187 tagged_above=-999 required=5 tests=[AWL=-2.953, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o19sgNvOq8oK for ; Thu, 11 Nov 2010 18:30:50 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B60203A6781 for ; Thu, 11 Nov 2010 18:30:50 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBR003AP2ZZEC@szxga01-in.huawei.com> for armd@ietf.org; Fri, 12 Nov 2010 10:31:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBR000IF2ZZH9@szxga01-in.huawei.com> for armd@ietf.org; Fri, 12 Nov 2010 10:31:11 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [130.129.39.76]) by szxmc04-in.huawei.com (mshttpd); Fri, 12 Nov 2010 10:31:06 +0800 Date: Fri, 12 Nov 2010 10:31:06 +0800 From: xuxiaohu 41208 In-reply-to: To: "Laganier, Julien" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <005301cb7e82$6081aaf0$84418182@china.huawei.com> Cc: Susan Hares , "armd@ietf.org" Subject: [armd] =?gb2312?b?VHdvIGNvbW1lbnRzIG9uIE1PT1NFLy8gu9i4tCA6UmU6?= =?gb2312?b?ICBBUk1EIEJPRiBhZ2VuZGEgYW5kIGRldGFpbHM=?= X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 02:30:51 -0000 1=2E Does moose deal with the ARP scalability issue=2C or MAC table scala= bility issue=3F 2=2E Can MOOSE support multi-homing function=3F for example=2C if MAC-NAT= -1 forwarding initial packets fails=2C MAC-NAT-2 takes over the forwardin= g and translation servive=2C which node will be responsible for updating = the previous ARP cache which contains the MAC translated by MAC-NAT-1=3F Xiaohu Xu Huawei Technologies Co=2E=2CLtd ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Laganier=2C Julien=22 =3Cjulienl=40qualcomm=2Eco= m=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =CA=AE=D2=BB=D4=C2 12=C8=D5=2C 2010= =C9=CF=CE=E78=3A38 =D6=F7=CC=E2=3A Re=3A =5Barmd=5D ARMD BOF agenda and details =CA=D5=BC=FE=C8=CB=3A =22armd=40ietf=2Eorg=22 =3Carmd=40ietf=2Eorg=3E=2C = Susan Hares =3Cskh=40ndzh=2Ecom=3E =3E Final Agenda and all meeting material is uploaded=3A =3E = =3E https=3A//datatracker=2Eietf=2Eorg/meeting/79/materials=2Ehtml =3E = =3E --julien =3E = =3E From=3A armd-bounces=40ietf=2Eorg =5Bmailto=3Aarmd-bounces=40ietf=2Eo= rg=5D On = =3E Behalf Of Laganier=2C Julien =3E Sent=3A Tuesday=2C November 09=2C 2010 12=3A28 AM =3E To=3A Linda Dunbar=3B armd=40ietf=2Eorg =3E Cc=3A =27Jari Arkko=27 =3E Subject=3A Re=3A =5Barmd=5D ARMD BOF agenda and details =3E = =3E Agenda and some of the meeting material is posted at the usual place=3A= =3E = =3E https=3A//datatracker=2Eietf=2Eorg/meeting/79/materials=2Ehtml =3E = =3E --julien =3E = =3E From=3A armd-bounces=40ietf=2Eorg =5Bmailto=3Aarmd-bounces=40ietf=2Eo= rg=5D On = =3E Behalf Of Linda Dunbar =3E Sent=3A Sunday=2C November 07=2C 2010 6=3A48 AM =3E To=3A armd=40ietf=2Eorg =3E Cc=3A =27Jari Arkko=27 =3E Subject=3A =5Barmd=5D ARMD BOF agenda and details =3E = =3E ARMD BOF will be Friday Nov 12=2C 9am=7E11=3A30am at Garden Ballroom=2E= =3E Detailed agenda has been posted on the wiki website=2E =3E = =3E http=3A//trac=2Etools=2Eietf=2Eorg/bof/trac/attachment/wiki/WikiStart= /ARMD=2520-=2520BOF=2520agenda=2520at=252079th=2520IETF=2Eppt =3E = =3E = =3E Looking forward to seeing most of you in Beijing=2E =3E = =3E Linda Dunbar =3E = =3E From Malcolm.Scott@cl.cam.ac.uk Thu Nov 11 18:36:49 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071833A69B6 for ; Thu, 11 Nov 2010 18:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyL2mtN6LJ6i for ; Thu, 11 Nov 2010 18:36:37 -0800 (PST) Received: from saturn.retrosnub.co.uk (saturn.retrosnub.co.uk [IPv6:2001:470:9321:f003:bc9d:1dff:fe9b:7466]) by core3.amsl.com (Postfix) with ESMTP id 015D73A6932 for ; Thu, 11 Nov 2010 18:36:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by saturn.retrosnub.co.uk (Postfix; Retrosnub mail exchanger) with ESMTP id 6D73340A10; Fri, 12 Nov 2010 02:36:45 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at saturn.retrosnub.co.uk Received: from saturn.retrosnub.co.uk ([127.0.0.1]) by localhost (saturn.retrosnub.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-lwReQEkvnl; Fri, 12 Nov 2010 02:36:39 +0000 (GMT) Received: from callisto.malc.org.uk (callisto.malc.org.uk [IPv6:2a01:348:11d:2:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: m@lcolm.org.uk) by saturn.retrosnub.co.uk (Postfix; Retrosnub mail exchanger) with ESMTPSA; Fri, 12 Nov 2010 02:36:39 +0000 (GMT) Date: Fri, 12 Nov 2010 02:36:39 +0000 (GMT) From: Malcolm Scott X-X-Sender: mas90@callisto.malc.org.uk To: xuxiaohu 41208 In-Reply-To: Message-ID: References: <005301cb7e82$6081aaf0$84418182@china.huawei.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "armd@ietf.org" , Susan Hares Subject: Re: [armd] =?utf-8?b?VHdvIGNvbW1lbnRzIG9uIE1PT1NFLy8g5Zue5aSNIDpSZTog?= =?utf-8?q?_ARMD_BOF_agenda_and_details?= X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 02:36:49 -0000 At 10:31 today, xuxiaohu 41208 wrote: > 1. Does moose deal with the ARP scalability issue, or MAC table > scalability issue? MAC table scalability, primarily. I'm thinking about ways to bring in ARP scalability; I think moose is a good starting point for this. We could at least use draft-shah-armd-arp-reduction in combination with moose. > 2. Can MOOSE support multi-homing function? for example, if MAC-NAT-1 > forwarding initial packets fails, MAC-NAT-2 takes over the forwarding and > translation servive, which node will be responsible for updating the > previous ARP cache which contains the MAC translated by MAC-NAT-1? Current implementation does not support this, but I am planning on working on this. I envisage an election protocol to determine which moose switch is the primary home switch for each host, but don't yet have details. Malcolm -- Malcolm Scott University of Cambridge Computer Laboratory From xuxh@huawei.com Thu Nov 11 18:57:25 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2029B3A68B6 for ; Thu, 11 Nov 2010 18:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.608 X-Spam-Level: **** X-Spam-Status: No, score=4.608 tagged_above=-999 required=5 tests=[AWL=-2.531, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltv1xQGcTzRp for ; Thu, 11 Nov 2010 18:57:24 -0800 (PST) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2548F3A6932 for ; Thu, 11 Nov 2010 18:57:24 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBR00673489WL@szxga05-in.huawei.com> for armd@ietf.org; Fri, 12 Nov 2010 10:57:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBR00FIQ488X7@szxga05-in.huawei.com> for armd@ietf.org; Fri, 12 Nov 2010 10:57:45 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [130.129.39.76]) by szxmc04-in.huawei.com (mshttpd); Fri, 12 Nov 2010 10:57:44 +0800 Date: Fri, 12 Nov 2010 10:57:44 +0800 From: xuxiaohu 41208 In-reply-to: To: Malcolm Scott Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <005301cb7e82$6081aaf0$84418182@china.huawei.com> Cc: "armd@ietf.org" , Susan Hares Subject: [armd] =?gb2312?b?u9i4tCA6UmU6ICBUd28gY29tbWVudHMgb24gTU9PU0Uv?= =?gb2312?b?LyC72Li0IDpSZTogIEFSTUQgQk9GIGFnZW5kYSBhbmQgZGV0YWlscw==?= X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 02:57:25 -0000 ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Malcolm Scott =3CMalcolm=2EScott=40cl=2Ecam=2Eac=2E= uk=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =CA=AE=D2=BB=D4=C2 12=C8=D5=2C 2010= =C9=CF=CE=E710=3A36 =D6=F7=CC=E2=3A Re=3A =5Barmd=5D Two comments on MOOSE// =BB=D8=B8=B4 =3A= Re=3A ARMD BOF agenda and details =CA=D5=BC=FE=C8=CB=3A xuxiaohu 41208 =3Cxuxh=40huawei=2Ecom=3E =B3=AD=CB=CD=3A =22Laganier=2C Julien=22 =3Cjulienl=40qualcomm=2Ecom=3E=2C= Susan Hares =3Cskh=40ndzh=2Ecom=3E=2C =22armd=40ietf=2Eorg=22 =3Carmd=40= ietf=2Eorg=3E =3E At 10=3A31 today=2C xuxiaohu 41208 wrote=3A =3E = =3E =3E 1=2E Does moose deal with the ARP scalability issue=2C or MAC tab= le = =3E =3E scalability issue=3F =3E = =3E MAC table scalability=2C primarily=2E I=27m thinking about ways to = =3E bring in ARP = =3E scalability=3B I think moose is a good starting point for this=2E =3E = =3E We could at least use draft-shah-armd-arp-reduction in combination = =3E with = =3E moose=2E =3E = =3E =3E 2=2E Can MOOSE support multi-homing function=3F for example=2C if= MAC- =3E NAT-1 = =3E =3E forwarding initial packets fails=2C MAC-NAT-2 takes over the = =3E forwarding and = =3E =3E translation servive=2C which node will be responsible for updatin= g = =3E the = =3E =3E previous ARP cache which contains the MAC translated by MAC-NAT-1= =3F =3E = =3E Current implementation does not support this=2C but I am planning on = =3E working = =3E on this=2E I envisage an election protocol to determine which moose = =3E switch is = =3E the primary home switch for each host=2C but don=27t yet have details= =2E Maybe multiple MAC-NAT devices of a given redundancy group could share a = single Virtual Switch ID=2E = By the way=2C I suggest to remove the port ID part in the translated MAC = address which makes the mechanism much more complex=2C especially when co= nsidering multi-homing scenario=2E IMHO=2C it is acceptable that the MAC = forwarding table on core switches is sized to the number of edge switches= (i=2Ee=2E=2C MAC-NAT devices)=2E Xiaohu =3E Malcolm =3E = =3E -- = =3E Malcolm Scott =3E University of Cambridge Computer Laboratory =3E = =3E From Malcolm.Scott@cl.cam.ac.uk Thu Nov 11 19:07:39 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34BF628C164 for ; Thu, 11 Nov 2010 19:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih4DaMx+ocy3 for ; Thu, 11 Nov 2010 19:07:38 -0800 (PST) Received: from saturn.retrosnub.co.uk (saturn.retrosnub.co.uk [IPv6:2001:470:9321:f003:bc9d:1dff:fe9b:7466]) by core3.amsl.com (Postfix) with ESMTP id 4C3FB28C163 for ; Thu, 11 Nov 2010 19:07:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by saturn.retrosnub.co.uk (Postfix; Retrosnub mail exchanger) with ESMTP id 6AE6640A0D; Fri, 12 Nov 2010 03:08:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at saturn.retrosnub.co.uk Received: from saturn.retrosnub.co.uk ([127.0.0.1]) by localhost (saturn.retrosnub.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHfSW0efpeZB; Fri, 12 Nov 2010 03:08:02 +0000 (GMT) Received: from callisto.malc.org.uk (callisto.malc.org.uk [IPv6:2a01:348:11d:2:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: m@lcolm.org.uk) by saturn.retrosnub.co.uk (Postfix; Retrosnub mail exchanger) with ESMTPSA; Fri, 12 Nov 2010 03:08:01 +0000 (GMT) Date: Fri, 12 Nov 2010 03:08:01 +0000 (GMT) From: Malcolm Scott X-X-Sender: mas90@callisto.malc.org.uk To: xuxiaohu 41208 In-Reply-To: Message-ID: References: <005301cb7e82$6081aaf0$84418182@china.huawei.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Susan Hares , "armd@ietf.org" Subject: Re: [armd] =?utf-8?b?5Zue5aSNIDpSZTogIFR3byBjb21tZW50cyBvbiBNT09TRS8v?= =?utf-8?b?IOWbnuWkjSA6UmU6ICBBUk1EIEJPRiBhZ2VuZGEgYW5kIGRldGFpbHM=?= X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 03:07:39 -0000 At 10:57 today, xuxiaohu 41208 wrote: > By the way, I suggest to remove the port ID part in the translated MAC > address which makes the mechanism much more complex, especially when > considering multi-homing scenario. IMHO, it is acceptable that the MAC > forwarding table on core switches is sized to the number of edge > switches(i.e., MAC-NAT devices). There was a slide on this which I had to omit due to time. The part of the NAT MAC address beyond the switch ID can be implementation-dependent; maybe some switches will want to put a port ID in there, or maybe it should just be a sequential ID, or even something like a hash of the host's real MAC address. Remote switches MUST NOT assume any structure to the switch-local portion. -- Malcolm Scott University of Cambridge Computer Laboratory From jmh@joelhalpern.com Fri Nov 12 16:50:34 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AAEC3A67FD for ; Fri, 12 Nov 2010 16:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDgR+hOTkKJN for ; Fri, 12 Nov 2010 16:50:33 -0800 (PST) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 7085D3A67E4 for ; Fri, 12 Nov 2010 16:50:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B6D223236DB6 for ; Fri, 12 Nov 2010 16:51:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-180.clppva.btas.verizon.net [71.161.52.180]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 39B403236DB5 for ; Fri, 12 Nov 2010 16:51:07 -0800 (PST) Message-ID: <4CDDE0FA.3060107@joelhalpern.com> Date: Fri, 12 Nov 2010 19:51:06 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "armd@ietf.org" References: <005301cb7e82$6081aaf0$84418182@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [armd] =?utf-8?b?5Zue5aSNIDpSZTogIEFSTUQgU2NvcGluZw==?= X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 00:50:34 -0000 First, an apology. For personal reasons I had to miss the BoF, so there may be context which makes the following comment irrelevant. Assuming I have followed the discussion properly, allow me to level up. There appear to be at least two problems. (I have seen renditions that make it three, but two suffices.) One problem is how to create, manage, and use the mapping information between IP address and MAC address. This ARP resolution problem can be addressed from many angles, and there are a number of proposals. (In addition to the several drafts, there are also the ideas of using Trill, 802.1aq, or SCSP to carry the information around.) This is a problem that the IETF can reasoanbly address. It seems to me that we probably should address it. The second problem is how to handle the forwarding of packets based on their MAC address. That is what the MAC NAT proposal addresses. Potentially, such a proposal could reduce the need for the first item, but it is in a very separate space. In particular, defining how Ethernet Switches work, and how Ethernet MAC addresses are used, seems to me to be an IEEE matter. We, the IETF, justifiably get upset if other standards bodies start telling us how IP addresses should behave. It seems appropriate for us to stay out of degining matters which fall squarely and exclusively in the purview of other standards bodies. Yours, Joel M. Halpern On 11/11/2010 10:08 PM, Malcolm Scott wrote: > At 10:57 today, xuxiaohu 41208 wrote: > >> By the way, I suggest to remove the port ID part in the translated MAC >> address which makes the mechanism much more complex, especially when >> considering multi-homing scenario. IMHO, it is acceptable that the MAC >> forwarding table on core switches is sized to the number of edge >> switches(i.e., MAC-NAT devices). > > There was a slide on this which I had to omit due to time. The part of > the NAT MAC address beyond the switch ID can be > implementation-dependent; maybe some switches will want to put a port ID > in there, or maybe it should just be a sequential ID, or even something > like a hash of the host's real MAC address. > > Remote switches MUST NOT assume any structure to the switch-local portion. > From k.mcewen@verizon.net Fri Nov 12 18:23:08 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05783A686E for ; Fri, 12 Nov 2010 18:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcG0obQ6CRPN for ; Fri, 12 Nov 2010 18:23:01 -0800 (PST) Received: from smtp103.vzn.mail.ne1.yahoo.com (smtp103.vzn.mail.ne1.yahoo.com [98.138.85.46]) by core3.amsl.com (Postfix) with SMTP id B43133A6848 for ; Fri, 12 Nov 2010 18:23:01 -0800 (PST) Received: (qmail 3810 invoked from network); 13 Nov 2010 02:23:35 -0000 Received: from [192.168.0.96] (k.mcewen@71.43.42.114 with plain) by smtp103.vzn.mail.ne1.yahoo.com with SMTP; 12 Nov 2010 18:23:33 -0800 PST X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL X-YMail-OSG: R6NsJGQVM1nDHD22EVB2.rJGxAkcxqFjRnH64O_iy3WZxYq lvB8owYw1k3uNqpL.yJWlw.l.63D.RFrpSU3J8kQf0g_xagHAvahr6el.xTG L8Sf.jmObHhE1.WmpNWKFVaSiMbSq6VapqfwoEvbiwenHlVqk4NnINGqLjvk VJLKlN9d2LIkJpG7XUFVU57WS5au5oP1u2K5uYnlJU0.rVNLQ48wABIjMC6f bPQRn.sVxhERWIp_R8ZtypEBpSazC.eM.sTImh4h_EOS60gI4Aq091WxysIg KS3da7B9VpPvY2TWVEO8S_Wha6wF8js4_TIQbtQ-- X-Yahoo-Newman-Property: ymail-3 References: <005301cb7e82$6081aaf0$84418182@china.huawei.com> <4CDDE0FA.3060107@joelhalpern.com> In-Reply-To: <4CDDE0FA.3060107@joelhalpern.com> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-50--77360125 Message-Id: X-Mailer: iPhone Mail (8B117) From: Kathy McEwen Date: Fri, 12 Nov 2010 20:22:46 -0600 To: "Joel M. Halpern" Cc: "armd@ietf.org" Subject: Re: [armd] =?utf-8?b?5Zue5aSNIDpSZTogIEFSTUQgU2NvcGluZw==?= X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 02:23:08 -0000 --Apple-Mail-50--77360125 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hmmm it would be very nice to believe networks are autonomous and independen= t islands too... Fortunately they are not.... Being mobile and having wings= to fly makes our generation unique in time thus far ... Addressing is compl= ex for that reason.=20 Sent from my iPhone On Nov 12, 2010, at 6:51 PM, "Joel M. Halpern" wrote: > First, an apology. For personal reasons I had to miss the BoF, so there m= ay be context which makes the following comment irrelevant. >=20 > Assuming I have followed the discussion properly, allow me to level up. > There appear to be at least two problems. (I have seen renditions that mak= e it three, but two suffices.) >=20 > One problem is how to create, manage, and use the mapping information betw= een IP address and MAC address. This ARP resolution problem can be addresse= d from many angles, and there are a number of proposals. (In addition to th= e several drafts, there are also the ideas of using Trill, 802.1aq, or SCSP t= o carry the information around.) > This is a problem that the IETF can reasoanbly address. It seems to me th= at we probably should address it. >=20 > The second problem is how to handle the forwarding of packets based on the= ir MAC address. That is what the MAC NAT proposal addresses. Potentially, s= uch a proposal could reduce the need for the first item, but it is in a very= separate space. > In particular, defining how Ethernet Switches work, and how Ethernet MAC a= ddresses are used, seems to me to be an IEEE matter. We, the IETF, justifia= bly get upset if other standards bodies start telling us how IP addresses sh= ould behave. It seems appropriate for us to stay out of degining matters wh= ich fall squarely and exclusively in the purview of other standards bodies. >=20 > Yours, > Joel M. Halpern >=20 > On 11/11/2010 10:08 PM, Malcolm Scott wrote: >> At 10:57 today, xuxiaohu 41208 wrote: >>=20 >>> By the way, I suggest to remove the port ID part in the translated MAC >>> address which makes the mechanism much more complex, especially when >>> considering multi-homing scenario. IMHO, it is acceptable that the MAC >>> forwarding table on core switches is sized to the number of edge >>> switches(i.e., MAC-NAT devices). >>=20 >> There was a slide on this which I had to omit due to time. The part of >> the NAT MAC address beyond the switch ID can be >> implementation-dependent; maybe some switches will want to put a port ID >> in there, or maybe it should just be a sequential ID, or even something >> like a hash of the host's real MAC address. >>=20 >> Remote switches MUST NOT assume any structure to the switch-local portion= . >>=20 > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd --Apple-Mail-50--77360125 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hmmm it would be very n= ice to believe networks are autonomous and independent islands too...  = Fortunately they are not.... Being mobile and having wings to fly makes our g= eneration unique in time thus far ... Addressing is complex for that reason.=  

Sent from my iPhone

On Nov 12, 2010, at 6= :51 PM, "Joel M. Halpern" <jmh@joe= lhalpern.com> wrote:

First, an apology.  For personal reasons I had to miss the= BoF, so there may be context which makes the following comment irrelevant.<= /span>

Assuming I have followed the discussion pro= perly, allow me to level up.
There appear to be at least two= problems. (I have seen renditions that make it three, but two suffices.)

One problem is how to create, manage, and use= the mapping information between IP address and MAC address.  This ARP r= esolution problem can be addressed from many angles, and there are a number o= f proposals.  (In addition to the several drafts, there are also the id= eas of using Trill, 802.1aq, or SCSP to carry the information around.)
This is a problem that the IETF can reasoanbly address.  It s= eems to me that we probably should address it.

The second problem is how to handle the forwarding of packets based on t= heir MAC address.  That is what the MAC NAT proposal addresses. Potenti= ally, such a proposal could reduce the need for the first item, but it is in= a very separate space.

In particular, defining how Ethernet= Switches work, and how Ethernet MAC addresses are used, seems to me to be a= n IEEE matter.  We, the IETF, justifiably get upset if other standards b= odies start telling us how IP addresses should behave.  It seems approp= riate for us to stay out of degining matters which fall squarely and exclusi= vely in the purview of other standards bodies.

Yours,

Joel M. Halpern

= On 11/11/2010 10:08 PM, Malcolm Scott wrote:
At 10:57 today, xuxiaohu 41208 wrote:

By the way, I suggest to remove the port I= D part in the translated MAC
address which makes the mecha= nism much more complex, especially when
=
considering multi-= homing scenario. IMHO, it is acceptable that the MAC
=
forwa= rding table on core switches is sized to the number of edge
switches(i.e., MAC-NAT devices).

There was a slide on this which I had to omit due to time. The part o= f
the NAT MAC address= beyond the switch ID can be
implementation-dependent; maybe some switches will want to put a por= t ID
in there, or may= be it should just be a sequential ID, or even something
like a hash of the host's real MAC addres= s.

Remote switches MUST NOT assume any st= ructure to the switch-local portion.

______________________________= _________________
armd mailing list
armd@ietf.org
https://www.ietf.org/mailman/listinfo/ar= md
= --Apple-Mail-50--77360125-- From ldunbar@huawei.com Tue Nov 16 13:21:21 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C436F3A67D6 for ; Tue, 16 Nov 2010 13:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCJjHPnBejoP for ; Tue, 16 Nov 2010 13:21:14 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id C2CD53A67B3 for ; Tue, 16 Nov 2010 13:21:13 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBZ009G9Y0L0I@usaga02-in.huawei.com> for armd@ietf.org; Tue, 16 Nov 2010 13:21:57 -0800 (PST) Received: from L735042 ([10.124.12.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBZ00DSCY0KEY@usaga02-in.huawei.com> for armd@ietf.org; Tue, 16 Nov 2010 13:21:56 -0800 (PST) Date: Tue, 16 Nov 2010 15:21:56 -0600 From: Linda Dunbar To: armd@ietf.org Message-id: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_y8kypPBU7BAvpCM70fbP/Q)" Thread-index: AcuF1EunO/W4DTWoQ6+xNMF7hcFMug== Cc: rcallon@juniper.net, adrian@olddog.co.uk, 'Jari Arkko' , 'Claudio DeSanti' Subject: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 21:21:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_y8kypPBU7BAvpCM70fbP/Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thanks to everyone who participated in the ARMD BOF discussion last Friday. There were two major comments we heard from the audience. One comment is wishing to see some statistics (by Internet AD Ralph), and another comment is suggesting that we should go to "Data Center Operation" working group to discuss with other "data center operation issues". Suggestion 1: Need ARP statistics: At the BOF, I forgot to mention that ARP statistics was quoted in our first problem statement draft for ARP222 (back when it was only at the bar BOF stage). As time goes on, we modified the draft several times by several authors to include more important stuff, those numbers get eliminated from the draft. The study done by CMU shows (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): the number of ARP queries received at a workstation on CMU's School of Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the host received 1150 ARPs per second, and on average, the host received 89 ARPs per second, which corresponds to 45 kbps of traffic. During the data collection, 2,456 hosts were observed sending ARP queries. CMU expected that the amount of ARP traffic will scale linearly with the number of hosts on the LAN. For 1 million hosts, they would expect 468,240 ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, which is more than enough to overwhelm a standard 100 Mbps LAN connection. Ignoring the link capacity, forcing hosts to handle an extra half million packets per second to inspect each ARP packet would impose a prohibitive computational burden. As Cisco's Claudio DeSanti pointed out during the BOF, large number of client subnets is effectively causing network to have the same problem as one large broadcast domain. Question: What other statistics do people would like to see before being convinced that ARP optimization is indeed necessary to make network scale to support next gen mega data center? Suggestion 2: To lump the ARP improvement discussion with Data Center Operation working group (by Ross Callon) Chatting with Ross Callon after the BOF, I learnt that Ross is referring to the potential Cloud Operation group (as the result of Cloud bar BOF). Actually, I initially did present the ARP issue at the Cloud bar BOF at the 78th IETF. But I learned that the audience for Cloud is too diverse to converge on network problems. The problems which Cloud bar BOF has presented cover Applications APIs, Logging, Security, etc. They are not even on network problems. I am afraid of mixing network problems with application problems will just get many people more confused. I remember during 78th IETF Cloud Bar BOF, the people who focus on Application APIs think network problem is too trivial to be even discussed at the same place with cloud applications problems. Question: Should we go towards this direction? What other refinement we need to consider? Thanks, Linda Dunbar --Boundary_(ID_y8kypPBU7BAvpCM70fbP/Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Thanks to everyone who participated in the ARMD BOF discussion last Friday. There were two major comments we heard from the audience. One comment is wishing to see some statistics (by Internet AD Ralph), and another comment is suggesting that we should go to “Data Center Operation” working group to discuss with other “data center operation issues”.

 

Suggestion 1: Need ARP statistics:

At the BOF, I forgot to mention that ARP statistics was quoted in our first problem statement draft for ARP222 (back when it was only at the bar BOF stage).  As time goes on, we modified the draft several times by several authors to include more important stuff, those numbers get eliminated from the draft.

 

The study done by CMU shows (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf):

 

the number of ARP queries received at a workstation on CMU’s School of Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the host received 1150 ARPs per second, and on average, the host received 89 ARPs per second, which corresponds to 45 kbps of traffic. During the data collection, 2,456 hosts were observed sending ARP queries.

 

CMU expected that the amount of ARP traffic will scale linearly with the number of hosts on the LAN. For 1 million hosts, they would expect 468,240 ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, which is more than enough to overwhelm a standard 100 Mbps LAN connection. Ignoring the link capacity, forcing hosts to handle an extra half million packets per second to inspect each ARP packet would impose a prohibitive computational burden.

 

 

As Cisco’s Claudio DeSanti pointed out during the BOF, large number of client subnets is effectively causing network to have the same problem as one large broadcast domain.

 

Question: What other statistics do people would like to see before being convinced that ARP optimization is indeed necessary to make network scale to support next gen mega data center?

 

Suggestion 2: To lump the ARP improvement discussion with Data Center Operation working group (by Ross Callon)

Chatting with Ross Callon after the BOF, I learnt that Ross is referring to the potential Cloud Operation group (as the result of Cloud bar BOF).

 

 Actually, I initially did present the ARP issue at the Cloud bar BOF at the 78th IETF. But I learned that the audience for Cloud is too diverse to converge on network problems. The problems which Cloud bar BOF has presented cover Applications APIs, Logging, Security, etc. They are not even on network problems.

I am afraid of mixing network problems with application problems will just get many people more confused. I remember during 78th IETF Cloud Bar BOF, the people who focus on Application APIs think network problem is too trivial to be even discussed at the same place with cloud applications problems.

 

Question: Should we go towards this direction?

 

 

What other refinement we need to consider?

 

Thanks, Linda Dunbar

 

--Boundary_(ID_y8kypPBU7BAvpCM70fbP/Q)-- From ning.so@verizonbusiness.com Tue Nov 16 13:32:40 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5113A67E2 for ; Tue, 16 Nov 2010 13:32:40 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvxMH2k4T5Pf for ; Tue, 16 Nov 2010 13:32:33 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id 268BC3A67DA for ; Tue, 16 Nov 2010 13:32:33 -0800 (PST) Received: from omzismtp01.vzbi.com ([unknown] [165.122.46.164]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LBZ002PXYJEG520@firewall.verizonbusiness.com> for armd@ietf.org; Tue, 16 Nov 2010 21:33:16 +0000 (GMT) Received: from omzismtp01.vzbi.com ([unknown] [127.0.0.1]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LBZ00FJGYJFF300@omzismtp01.vzbi.com> for armd@ietf.org; Tue, 16 Nov 2010 21:33:15 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LBZ00F17YJERL00@omzismtp01.vzbi.com> for armd@ietf.org; Tue, 16 Nov 2010 21:33:15 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.147]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Nov 2010 21:33:14 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CB85D5.DFA5C446" Date: Tue, 16 Nov 2010 21:33:12 +0000 Message-id: <14584D6EE26B314187A4F68BA206060005C3DA75@ASHEVS008.mcilink.com> In-reply-to: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [armd] ARMD BOF follow up Thread-index: AcuF1EunO/W4DTWoQ6+xNMF7hcFMugAAQOWg References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> From: "So, Ning" To: Linda Dunbar , armd@ietf.org X-OriginalArrivalTime: 16 Nov 2010 21:33:14.0458 (UTC) FILETIME=[E01AEBA0:01CB85D5] Cc: rcallon@juniper.net, adrian@olddog.co.uk, Jari Arkko , Claudio DeSanti Subject: Re: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 21:32:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB85D5.DFA5C446 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Linda, =20 I concur with your concern on your suggestion #2. Cloud Data Center WG (name will likely change) and Cloud AppsBoF were both being proposed during the meeting last week. One potential solution is to have network related ARMD drafts go to the new WG, while non-network related SRMD drafts go to the new Cloud AppsBoF. =20 =20 =20 Best regrads, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 ________________________________ From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, November 16, 2010 3:22 PM To: armd@ietf.org Cc: rcallon@juniper.net; adrian@olddog.co.uk; 'Jari Arkko'; 'Claudio DeSanti' Subject: [armd] ARMD BOF follow up =20 Thanks to everyone who participated in the ARMD BOF discussion last Friday. There were two major comments we heard from the audience. One comment is wishing to see some statistics (by Internet AD Ralph), and another comment is suggesting that we should go to "Data Center Operation" working group to discuss with other "data center operation issues".=20 =20 Suggestion 1: Need ARP statistics:=20 At the BOF, I forgot to mention that ARP statistics was quoted in our first problem statement draft for ARP222 (back when it was only at the bar BOF stage). As time goes on, we modified the draft several times by several authors to include more important stuff, those numbers get eliminated from the draft.=20 =20 The study done by CMU shows (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf):=20 =20 the number of ARP queries received at a workstation on CMU's School of Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the host received 1150 ARPs per second, and on average, the host received 89 ARPs per second, which corresponds to 45 kbps of traffic. During the data collection, 2,456 hosts were observed sending ARP queries.=20 =20 CMU expected that the amount of ARP traffic will scale linearly with the number of hosts on the LAN. For 1 million hosts, they would expect 468,240 ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, which is more than enough to overwhelm a standard 100 Mbps LAN connection. Ignoring the link capacity, forcing hosts to handle an extra half million packets per second to inspect each ARP packet would impose a prohibitive computational burden. =20 =20 As Cisco's Claudio DeSanti pointed out during the BOF, large number of client subnets is effectively causing network to have the same problem as one large broadcast domain.=20 =20 Question: What other statistics do people would like to see before being convinced that ARP optimization is indeed necessary to make network scale to support next gen mega data center?=20 =20 Suggestion 2: To lump the ARP improvement discussion with Data Center Operation working group (by Ross Callon) Chatting with Ross Callon after the BOF, I learnt that Ross is referring to the potential Cloud Operation group (as the result of Cloud bar BOF). =20 Actually, I initially did present the ARP issue at the Cloud bar BOF at the 78th IETF. But I learned that the audience for Cloud is too diverse to converge on network problems. The problems which Cloud bar BOF has presented cover Applications APIs, Logging, Security, etc. They are not even on network problems.=20 I am afraid of mixing network problems with application problems will just get many people more confused. I remember during 78th IETF Cloud Bar BOF, the people who focus on Application APIs think network problem is too trivial to be even discussed at the same place with cloud applications problems.=20 =20 Question: Should we go towards this direction?=20 =20 =20 What other refinement we need to consider?=20 =20 Thanks, Linda Dunbar=20 =20 ------_=_NextPart_001_01CB85D5.DFA5C446 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Linda,

 

I concur with your concern on your suggestion #2.  Cloud Data Center WG (name will likely change) and = Cloud AppsBoF were both being proposed during the meeting last week.  One potential solution is to have network related ARMD drafts go to the new = WG, while non-network related SRMD drafts go to the new Cloud AppsBoF. =  

 

 

=

Best regrads,

 

=

Ning So

Network Evolution = Planning

Verizon, Inc.

(office) = 972-729-7905

(Cell) = 972-955-0914

 

=

From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Tuesday, November = 16, 2010 3:22 PM
To: armd@ietf.org
Cc: rcallon@juniper.net; adrian@olddog.co.uk; 'Jari Arkko'; 'Claudio DeSanti'
Subject: [armd] ARMD BOF = follow up

 

Thanks to everyone who participated in the ARMD BOF discussion last Friday. There were two major comments we heard from the audience. One comment is wishing to see some statistics (by Internet AD = Ralph), and another comment is suggesting that we should go to “Data = Center Operation” working group to discuss with other “data center operation issues”.

 

Suggestion 1: Need ARP statistics: =

At the BOF, I forgot to = mention that ARP statistics was quoted in our first problem statement draft for = ARP222 (back when it was only at the bar BOF stage).  As time goes on, we = modified the draft several times by several authors to include more important stuff, = those numbers get eliminated from the draft.

 

The study done by CMU shows = (http= ://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf):

 

the number of ARP queries received at a workstation on CMU’s = School of = Computer Science LAN over a 12 = hour period on August 9, 2004. At peak, the host received 1150 ARPs per = second, and on average, the host received 89 ARPs per second, which corresponds to = 45 kbps of traffic. During the data collection, 2,456 hosts were observed = sending ARP queries.

 

CMU expected that the amount of ARP traffic will scale linearly with the = number of hosts on the LAN. For 1 million hosts, they would expect 468,240 ARPs = per second or 239 Mbps of ARP traffic to arrive at each host at peak, which = is more than enough to overwhelm a standard 100 Mbps LAN connection. Ignoring = the link capacity, forcing hosts to handle an extra half million packets per = second to inspect each ARP packet would impose a prohibitive computational = burden.

 

 

As Cisco’s Claudio = DeSanti pointed out during the BOF, large number of client subnets is = effectively causing network to have the same problem as one large broadcast domain. =

 

Question: = What other statistics do people would like to see before being convinced that = ARP optimization is indeed necessary to make network scale to support next = gen mega data center?

 

Suggestion 2: To lump the = ARP improvement discussion with Data Center Operation working group (by Ross Callon)

Chatting with Ross Callon = after the BOF, I learnt that Ross is referring to the potential Cloud Operation = group (as the result of Cloud bar BOF).

 

 Actually, I initially = did present the ARP issue at the Cloud bar BOF at the 78th IETF. = But I learned that the audience for Cloud is too diverse to converge on = network problems. The problems which Cloud bar BOF has presented cover = Applications APIs, Logging, Security, etc. They are not even on network problems. =

I am afraid of mixing = network problems with application problems will just get many people more = confused. I remember during 78th IETF Cloud Bar BOF, the people who focus = on Application APIs think network problem is too trivial to be even = discussed at the same place with cloud applications problems. =

 

Question: = Should we go towards this direction?

 

 

What other refinement we need to consider? =

 

Thanks, Linda Dunbar

 

------_=_NextPart_001_01CB85D5.DFA5C446-- From vishwas.ietf@gmail.com Tue Nov 16 17:34:02 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F43F3A680E for ; Tue, 16 Nov 2010 17:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDxHjbvh7NN7 for ; Tue, 16 Nov 2010 17:34:00 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id E4F263A67A3 for ; Tue, 16 Nov 2010 17:33:56 -0800 (PST) Received: by qwd7 with SMTP id 7so2772qwd.31 for ; Tue, 16 Nov 2010 17:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pFrwcjZUj8buTpdRIh/3eCtWjeRYleXcUMbtm/MVZdA=; b=pVK42JcVvjHRBfA1Q7cVG+WUwq5WsmyH9Auz88LbfIAu424aCMVXTcwXLVxseEn2Yd 5p7mTHcrzLGuOWxpiGnhmQAeoOQmcyqDU4yuk477bCyoZ7f+gt9AIYRoCwHM5WDMitdZ shAqU3QSbOQauJSnFfgNrheC8e/oVvUnkF6ZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oYP4gRuMKg+2VRLatP8Yp+lbTU3TFiEyG+xHnyYLiJLnt8Qo4DrOQJCTDQCG5AsNAN aMIqqhOAHanNNEbnFVml41FyB1xGe7mowQEEoi1hPeqI6b2orANM+UFPOaOvxc0THW15 MgTI/aWqCmuy/mrTecxcvGgk55IYS99tlMMeA= MIME-Version: 1.0 Received: by 10.229.240.78 with SMTP id kz14mr6805794qcb.230.1289957681106; Tue, 16 Nov 2010 17:34:41 -0800 (PST) Received: by 10.229.86.19 with HTTP; Tue, 16 Nov 2010 17:34:41 -0800 (PST) In-Reply-To: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> Date: Tue, 16 Nov 2010 17:34:41 -0800 Message-ID: From: Vishwas Manral To: Linda Dunbar Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: rcallon@juniper.net, adrian@olddog.co.uk, Jari Arkko , Claudio DeSanti , armd@ietf.org Subject: Re: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 01:34:02 -0000 Hi Linda, I recently joined the group. So forgive me if I repeat something that has been discussed earlier. > For 1 million hosts, they would expect 468,240 > ARPs per second or 239 Mbps of ARP traffic to arrive at > each host at peak, which is more than enough to > overwhelm a standard 100 Mbps LAN connection. As ARP messages may not always be broadcast and the broadcast domain, is 239 Mbps the total ARP packet on a network or is it per host? If it is not per host we should not talk about the overwhelming the 100Mpbs= LAN. Thanks, Vishwas On Tue, Nov 16, 2010 at 1:21 PM, Linda Dunbar wrote: > Thanks to everyone who participated in the ARMD BOF discussion last Frida= y. > There were two major comments we heard from the audience. One comment is > wishing to see some statistics (by Internet AD Ralph), and another commen= t > is suggesting that we should go to =93Data Center Operation=94 working gr= oup to > discuss with other =93data center operation issues=94. > > > > Suggestion 1: Need ARP statistics: > > At the BOF, I forgot to mention that ARP statistics was quoted in our fir= st > problem statement draft for ARP222 (back when it was only at the bar BOF > stage). =A0As time goes on, we modified the draft several times by severa= l > authors to include more important stuff, those numbers get eliminated fro= m > the draft. > > > > The study done by CMU shows > (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): > > > > the number of ARP queries received at a workstation on CMU=92s School of > Computer Science LAN over a 12 hour period on August 9, 2004. At peak, th= e > host received 1150 ARPs per second, and on average, the host received 89 > ARPs per second, which corresponds to 45 kbps of traffic. During the data > collection, 2,456 hosts were observed sending ARP queries. > > > > CMU expected that the amount of ARP traffic will scale linearly with the > number of hosts on the LAN. For 1 million hosts, they would expect 468,24= 0 > ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak= , > which is more than enough to overwhelm a standard 100 Mbps LAN connection= . > Ignoring the link capacity, forcing hosts to handle an extra half million > packets per second to inspect each ARP packet would impose a prohibitive > computational burden. > > > > > > As Cisco=92s Claudio DeSanti pointed out during the BOF, large number of > client subnets is effectively causing network to have the same problem as > one large broadcast domain. > > > > Question: What other statistics do people would like to see before being > convinced that ARP optimization is indeed necessary to make network scale= to > support next gen mega data center? > > > > Suggestion 2: To lump the ARP improvement discussion with Data Center > Operation working group (by Ross Callon) > > Chatting with Ross Callon after the BOF, I learnt that Ross is referring = to > the potential Cloud Operation group (as the result of Cloud bar BOF). > > > > =A0Actually, I initially did present the ARP issue at the Cloud bar BOF a= t the > 78th IETF. But I learned that the audience for Cloud is too diverse to > converge on network problems. The problems which Cloud bar BOF has presen= ted > cover Applications APIs, Logging, Security, etc. They are not even on > network problems. > > I am afraid of mixing network problems with application problems will jus= t > get many people more confused. I remember during 78th IETF Cloud Bar BOF, > the people who focus on Application APIs think network problem is too > trivial to be even discussed at the same place with cloud applications > problems. > > > > Question: Should we go towards this direction? > > > > > > What other refinement we need to consider? > > > > Thanks, Linda Dunbar > > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > From adrian@olddog.co.uk Wed Nov 17 02:40:00 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2AFA3A68E5 for ; Wed, 17 Nov 2010 02:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXbCBdYCKtPL for ; Wed, 17 Nov 2010 02:39:52 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 57BDB3A68D1 for ; Wed, 17 Nov 2010 02:39:51 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id oAHAeRG5026372; Wed, 17 Nov 2010 10:40:28 GMT Received: from 950129200 ([141.39.21.98]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id oAHAeQEh026367; Wed, 17 Nov 2010 10:40:26 GMT From: "Adrian Farrel" To: "'So, Ning'" , "'Linda Dunbar'" , References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> <14584D6EE26B314187A4F68BA206060005C3DA75@ASHEVS008.mcilink.com> In-Reply-To: <14584D6EE26B314187A4F68BA206060005C3DA75@ASHEVS008.mcilink.com> Date: Wed, 17 Nov 2010 10:40:26 -0000 Message-ID: <03c601cb8643$d94fd650$8bef82f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03C7_01CB8643.D99013A0" X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQDWFxtyC9s+fQZHnPtRs1kFXSPnJwKNn/pNlUvr6lA= X-Mailman-Approved-At: Wed, 17 Nov 2010 07:09:40 -0800 Cc: rcallon@juniper.net, 'Jari Arkko' , 'Claudio DeSanti' Subject: Re: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 10:40:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03C7_01CB8643.D99013A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I don't believe Ops Area WGs are allowed to do protocol extensions (except for management protocols), so option 2 is not an option if the ARMD work requires protocol changes. OTOH, if the ARMD work collapses to how to operate ARP in a specific environment, then this would be clear for Ops. Adrian From: So, Ning [mailto:ning.so@verizonbusiness.com] Sent: 16 November 2010 21:33 To: Linda Dunbar; armd@ietf.org Cc: rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; Claudio DeSanti Subject: RE: [armd] ARMD BOF follow up Linda, I concur with your concern on your suggestion #2. Cloud Data Center WG (name will likely change) and Cloud AppsBoF were both being proposed during the meeting last week. One potential solution is to have network related ARMD drafts go to the new WG, while non-network related SRMD drafts go to the new Cloud AppsBoF. Best regrads, Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 _____ From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, November 16, 2010 3:22 PM To: armd@ietf.org Cc: rcallon@juniper.net; adrian@olddog.co.uk; 'Jari Arkko'; 'Claudio DeSanti' Subject: [armd] ARMD BOF follow up Thanks to everyone who participated in the ARMD BOF discussion last Friday. There were two major comments we heard from the audience. One comment is wishing to see some statistics (by Internet AD Ralph), and another comment is suggesting that we should go to "Data Center Operation" working group to discuss with other "data center operation issues". Suggestion 1: Need ARP statistics: At the BOF, I forgot to mention that ARP statistics was quoted in our first problem statement draft for ARP222 (back when it was only at the bar BOF stage). As time goes on, we modified the draft several times by several authors to include more important stuff, those numbers get eliminated from the draft. The study done by CMU shows (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): the number of ARP queries received at a workstation on CMU's School of Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the host received 1150 ARPs per second, and on average, the host received 89 ARPs per second, which corresponds to 45 kbps of traffic. During the data collection, 2,456 hosts were observed sending ARP queries. CMU expected that the amount of ARP traffic will scale linearly with the number of hosts on the LAN. For 1 million hosts, they would expect 468,240 ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, which is more than enough to overwhelm a standard 100 Mbps LAN connection. Ignoring the link capacity, forcing hosts to handle an extra half million packets per second to inspect each ARP packet would impose a prohibitive computational burden. As Cisco's Claudio DeSanti pointed out during the BOF, large number of client subnets is effectively causing network to have the same problem as one large broadcast domain. Question: What other statistics do people would like to see before being convinced that ARP optimization is indeed necessary to make network scale to support next gen mega data center? Suggestion 2: To lump the ARP improvement discussion with Data Center Operation working group (by Ross Callon) Chatting with Ross Callon after the BOF, I learnt that Ross is referring to the potential Cloud Operation group (as the result of Cloud bar BOF). Actually, I initially did present the ARP issue at the Cloud bar BOF at the 78th IETF. But I learned that the audience for Cloud is too diverse to converge on network problems. The problems which Cloud bar BOF has presented cover Applications APIs, Logging, Security, etc. They are not even on network problems. I am afraid of mixing network problems with application problems will just get many people more confused. I remember during 78th IETF Cloud Bar BOF, the people who focus on Application APIs think network problem is too trivial to be even discussed at the same place with cloud applications problems. Question: Should we go towards this direction? What other refinement we need to consider? Thanks, Linda Dunbar ------=_NextPart_000_03C7_01CB8643.D99013A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I don't believe Ops Area WGs = are allowed to do protocol extensions (except for management protocols), = so option 2 is not an option if the ARMD work requires protocol = changes.

 

OTOH, if the ARMD work = collapses to how to operate ARP in a specific environment, then this = would be clear for Ops.

 

Adrian

 

From: So, Ning = [mailto:ning.so@verizonbusiness.com]
Sent: 16 November 2010 = 21:33
To: Linda Dunbar; armd@ietf.org
Cc: = rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; Claudio = DeSanti
Subject: RE: [armd] ARMD BOF follow = up

 

Linda,

 

I concur with your concern on your suggestion #2. =  Cloud Data Center WG (name will likely change) and Cloud AppsBoF = were both being proposed during the meeting last week.  One = potential solution is to have network related ARMD drafts go to the new = WG, while non-network related SRMD drafts go to the new Cloud AppsBoF. =  

 

 

=

Best regrads,

 

=

Ning So

Network Evolution Planning

Verizon, Inc.

(office) 972-729-7905

(Cell) 972-955-0914

 


From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On = Behalf Of Linda Dunbar
Sent: Tuesday, November 16, 2010 = 3:22 PM
To: armd@ietf.org
Cc: rcallon@juniper.net; = adrian@olddog.co.uk; 'Jari Arkko'; 'Claudio DeSanti'
Subject: = [armd] ARMD BOF follow up

 

Thanks= to everyone who participated in the ARMD BOF discussion last Friday. = There were two major comments we heard from the audience. One comment is = wishing to see some statistics (by Internet AD Ralph), and another = comment is suggesting that we should go to “Data Center = Operation” working group to discuss with other “data center = operation issues”.

&= nbsp;

Sugges= tion 1: Need ARP statistics:

At = the BOF, I forgot to mention that ARP statistics was quoted in our first = problem statement draft for ARP222 (back when it was only at the bar BOF = stage).  As time goes on, we modified the draft several times by = several authors to include more important stuff, those numbers get = eliminated from the draft.

&= nbsp;

The = study done by CMU shows (http= ://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): =

&= nbsp;

the number of ARP queries received at = a workstation on CMU’s School of Computer Science LAN over a 12 = hour period on August 9, 2004. At peak, the host received 1150 ARPs per = second, and on average, the host received 89 ARPs per second, which = corresponds to 45 kbps of traffic. During the data collection, 2,456 = hosts were observed sending ARP queries.

 

CMU expected that the amount of ARP = traffic will scale linearly with the number of hosts on the LAN. For 1 = million hosts, they would expect 468,240 ARPs per second or 239 Mbps of = ARP traffic to arrive at each host at peak, which is more than enough to = overwhelm a standard 100 Mbps LAN connection. Ignoring the link = capacity, forcing hosts to handle an extra half million packets per = second to inspect each ARP packet would impose a prohibitive = computational burden.

 

&= nbsp;

As = Cisco’s Claudio DeSanti pointed out during the BOF, large number = of client subnets is effectively causing network to have the same = problem as one large broadcast domain.

&= nbsp;

Questi= on: What other statistics do people would like to see before being = convinced that ARP optimization is indeed necessary to make network = scale to support next gen mega data center?

&= nbsp;

Sugges= tion 2: To lump the ARP improvement discussion with Data Center = Operation working group (by Ross Callon)

Chatti= ng with Ross Callon after the BOF, I learnt that Ross is referring to = the potential Cloud Operation group (as the result of Cloud bar BOF). =

&= nbsp;

 = Actually, I initially did present the ARP issue at the Cloud bar BOF at = the 78th IETF. But I learned that the audience for Cloud is = too diverse to converge on network problems. The problems which Cloud = bar BOF has presented cover Applications APIs, Logging, Security, etc. = They are not even on network problems.

I am = afraid of mixing network problems with application problems will just = get many people more confused. I remember during 78th IETF = Cloud Bar BOF, the people who focus on Application APIs think network = problem is too trivial to be even discussed at the same place with cloud = applications problems.

&= nbsp;

Questi= on: Should we go towards this direction?

&= nbsp;

&= nbsp;

What = other refinement we need to consider?

&= nbsp;

Thanks= , Linda Dunbar

&= nbsp;

------=_NextPart_000_03C7_01CB8643.D99013A0-- From rcallon@juniper.net Wed Nov 17 06:43:01 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A983A6918 for ; Wed, 17 Nov 2010 06:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.708 X-Spam-Level: X-Spam-Status: No, score=-106.708 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMomuoZRAIvW for ; Wed, 17 Nov 2010 06:42:51 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id AFE063A6903 for ; Wed, 17 Nov 2010 06:42:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTOPqDSYmk7SYNJOc47igmlWnNdLaFAAO@postini.com; Wed, 17 Nov 2010 06:43:33 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 17 Nov 2010 06:41:27 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 17 Nov 2010 09:41:26 -0500 From: Ross Callon To: "adrian@olddog.co.uk" , "'So, Ning'" , 'Linda Dunbar' , "armd@ietf.org" Date: Wed, 17 Nov 2010 09:41:24 -0500 Thread-Topic: [armd] ARMD BOF follow up Thread-Index: AQDWFxtyC9s+fQZHnPtRs1kFXSPnJwKNn/pNlUvr6lCAAEEnwA== Message-ID: References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> <14584D6EE26B314187A4F68BA206060005C3DA75@ASHEVS008.mcilink.com> <03c601cb8643$d94fd650$8bef82f0$@olddog.co.uk> In-Reply-To: <03c601cb8643$d94fd650$8bef82f0$@olddog.co.uk> 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_DF7F294AF4153D498141CBEFADB177049AAE498EB7EMBX01WFjnprn_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 17 Nov 2010 07:09:40 -0800 Cc: Ronald Bonica , 'Jari Arkko' , 'Claudio DeSanti' Subject: Re: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 14:43:01 -0000 --_000_DF7F294AF4153D498141CBEFADB177049AAE498EB7EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have CC'd Ron Bonica on this, as he is the operations AD. My understanding of the results of the BOF is that there is clearly a probl= em to be solved, an urgency to begin work, and several possible solutions. There is also a need to clearly document what the problem is, the requireme= nts for a solution, and the range of possible solutions. This is work that = could be done in a data center operations working group. It is possible that some potential solutions may involve care of how existi= ng protocols are deployed (an operational issue). It is possible that some potential solutions may involve extensions or chan= ges to existing IETF protocols. I am not an AD (and no longer play one on T= V or anywhere else). My understanding is that these extensions to existing = IETF protocols would need to be done in other IETF WGs - presumably the one= s responsible for whatever protocol is being extended. However, it will be = much easier to charter this work once there is agreement on an initial draf= t documenting what the problem is and requirements of a solution. Ross From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, November 17, 2010 5:40 AM To: 'So, Ning'; 'Linda Dunbar'; armd@ietf.org Cc: Ross Callon; 'Jari Arkko'; 'Claudio DeSanti' Subject: RE: [armd] ARMD BOF follow up Hi, I don't believe Ops Area WGs are allowed to do protocol extensions (except = for management protocols), so option 2 is not an option if the ARMD work re= quires protocol changes. OTOH, if the ARMD work collapses to how to operate ARP in a specific enviro= nment, then this would be clear for Ops. Adrian From: So, Ning [mailto:ning.so@verizonbusiness.com] Sent: 16 November 2010 21:33 To: Linda Dunbar; armd@ietf.org Cc: rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; Claudio DeSanti Subject: RE: [armd] ARMD BOF follow up Linda, I concur with your concern on your suggestion #2. Cloud Data Center WG (na= me will likely change) and Cloud AppsBoF were both being proposed during th= e meeting last week. One potential solution is to have network related ARM= D drafts go to the new WG, while non-network related SRMD drafts go to the = new Cloud AppsBoF. Best regrads, Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 ________________________________ From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Lin= da Dunbar Sent: Tuesday, November 16, 2010 3:22 PM To: armd@ietf.org Cc: rcallon@juniper.net; adrian@olddog.co.uk; 'Jari Arkko'; 'Claudio DeSant= i' Subject: [armd] ARMD BOF follow up Thanks to everyone who participated in the ARMD BOF discussion last Friday.= There were two major comments we heard from the audience. One comment is w= ishing to see some statistics (by Internet AD Ralph), and another comment i= s suggesting that we should go to "Data Center Operation" working group to = discuss with other "data center operation issues". Suggestion 1: Need ARP statistics: At the BOF, I forgot to mention that ARP statistics was quoted in our first= problem statement draft for ARP222 (back when it was only at the bar BOF s= tage). As time goes on, we modified the draft several times by several aut= hors to include more important stuff, those numbers get eliminated from the= draft. The study done by CMU shows (http://www.cs.cmu.edu/~hzhang/papers/hotnets04= -ethernet.pdf): the number of ARP queries received at a workstation on CMU's School of Comp= uter Science LAN over a 12 hour period on August 9, 2004. At peak, the host= received 1150 ARPs per second, and on average, the host received 89 ARPs p= er second, which corresponds to 45 kbps of traffic. During the data collect= ion, 2,456 hosts were observed sending ARP queries. CMU expected that the amount of ARP traffic will scale linearly with the nu= mber of hosts on the LAN. For 1 million hosts, they would expect 468,240 AR= Ps per second or 239 Mbps of ARP traffic to arrive at each host at peak, wh= ich is more than enough to overwhelm a standard 100 Mbps LAN connection. Ig= noring the link capacity, forcing hosts to handle an extra half million pac= kets per second to inspect each ARP packet would impose a prohibitive compu= tational burden. As Cisco's Claudio DeSanti pointed out during the BOF, large number of clie= nt subnets is effectively causing network to have the same problem as one l= arge broadcast domain. Question: What other statistics do people would like to see before being co= nvinced that ARP optimization is indeed necessary to make network scale to = support next gen mega data center? Suggestion 2: To lump the ARP improvement discussion with Data Center Opera= tion working group (by Ross Callon) Chatting with Ross Callon after the BOF, I learnt that Ross is referring to= the potential Cloud Operation group (as the result of Cloud bar BOF). Actually, I initially did present the ARP issue at the Cloud bar BOF at th= e 78th IETF. But I learned that the audience for Cloud is too diverse to co= nverge on network problems. The problems which Cloud bar BOF has presented = cover Applications APIs, Logging, Security, etc. They are not even on netwo= rk problems. I am afraid of mixing network problems with application problems will just = get many people more confused. I remember during 78th IETF Cloud Bar BOF, t= he people who focus on Application APIs think network problem is too trivia= l to be even discussed at the same place with cloud applications problems. Question: Should we go towards this direction? What other refinement we need to consider? Thanks, Linda Dunbar --_000_DF7F294AF4153D498141CBEFADB177049AAE498EB7EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have CC’d Ron Bonica on this, as he is the operation= s AD.

 

My understanding of the results of the BOF is that there is clearly a problem to be solved, an urgency to begin work, and several possi= ble solutions. 

 

There is also a need to clearly document what the problem is= , the requirements for a solution, and the range of possible solutions. This = is work that could be done in a data center operations working group.

 

It is possible that some potential solutions may involve car= e of how existing protocols are deployed (an operational issue).

 

It is possible that some potential solutions may involve extensions or changes to existing IETF protocols. I am not an AD (and no lo= nger play one on TV or anywhere else). My understanding is that these extensions= to existing IETF protocols would need to be done in other IETF WGs – presumably the ones responsible for whatever protocol is being extended. However, it will be much easier to charter this work once there is agreemen= t on an initial draft documenting what the problem is and requirements of a solution.

 

Ross

 

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, November 17, 2010 5:40 AM
To: 'So, Ning'; 'Linda Dunbar'; armd@ietf.org
Cc: Ross Callon; 'Jari Arkko'; 'Claudio DeSanti'
Subject: RE: [armd] ARMD BOF follow up

 

Hi,

 

I don't believe Ops Area WGs are allowed to do protocol extensions (except for management protocols), so option 2 is not an option = if the ARMD work requires protocol changes.

 

OTOH, if the ARMD work collapses to how to operate ARP in a specific environment, then this would be clear for Ops.

 

Adrian

 

From: So, Ning [mailto:ning.so@verizonbusiness.com]
Sent: 16 November 2010 21:33
To: Linda Dunbar; armd@ietf.org
Cc: rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; Claudio DeSanti
Subject: RE: [armd] ARMD BOF follow up

 

Linda,

 

I concur with your concern on your suggestion #2.  Cloud D= ata Center WG (name will likely change) and Cloud AppsBoF were both being propo= sed during the meeting last week.  One potential solution is to have netwo= rk related ARMD drafts go to the new WG, while non-network related SRMD drafts= go to the new Cloud AppsBoF.  

 

 

Best regrads,

 

Ning So

Network Evolution Planning

Verizon, Inc.

(office) 972-729-7905

(Cell) 972-955-0914

 


From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Li= nda Dunbar
Sent: Tuesday, November 16, 2010 3:22 PM
To: armd@ietf.org
Cc: rcallon@juniper.net; adrian@olddog.co.uk; 'Jari Arkko'; 'Claudio DeSanti'
Subject: [armd] ARMD BOF follow up

 

Thank= s to everyone who participated in the ARMD BOF discussion last Friday. There wer= e two major comments we heard from the audience. One comment is wishing to se= e some statistics (by Internet AD Ralph), and another comment is suggesting t= hat we should go to “Data Center Operation” working group to discus= s with other “data center operation issues”.

=  

Sugge= stion 1: Need ARP statistics:

At the BOF, I forgot to mention that ARP statistics was quoted in our first problem statement draft for ARP222 (back when it was only at the bar BOF stage).  As time goes on, we modified the draft several times by sever= al authors to include more important stuff, those numbers get eliminated from = the draft.

 

The study done by CMU shows (http:/= /www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf):

 

the= number of ARP queries received at a workstation on CMU’s School of Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the host rece= ived 1150 ARPs per second, and on average, the host received 89 ARPs per second, which corresponds to 45 kbps of traffic. During the data collection, 2,456 hosts were observed sending ARP queries.

 

CMU expected that the amount of ARP traffic will scale linearly with the number= of hosts on the LAN. For 1 million hosts, they would expect 468,240 ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, which is = more than enough to overwhelm a standard 100 Mbps LAN connection. Ignoring the l= ink capacity, forcing hosts to handle an extra half million packets per second = to inspect each ARP packet would impose a prohibitive computational burden.

 

=  

As Cisco’s Claudio DeSanti pointed out during the BOF, large number of client subnets is effectively causing network to have the same problem as o= ne large broadcast domain.

 

Question: What other statistics do people would like to see before being convinced th= at ARP optimization is indeed necessary to make network scale to support next = gen mega data center?

 

Suggestion 2: To lump the ARP improvement discussion with Data Center Operation workin= g group (by Ross Callon)

Chatting with Ross Callon after the BOF, I learnt that Ross is referring to the potential Cloud Operation group (as the result of Cloud bar BOF).

 

 Actually, I initially did present the ARP issue at the Cloud bar BOF at the 78th= IETF. But I learned that the audience for Cloud is too diverse to converge = on network problems. The problems which Cloud bar BOF has presented cover Applications APIs, Logging, Security, etc. They are not even on network problems.

I am afraid of mixing network problems with application problems will just ge= t many people more confused. I remember during 78th IETF Cloud Bar BOF, the people who focus on Application APIs think network problem is too trivial to be even discussed at the same place with cloud applications problems.

 

Question: Should we go towards this direction?

 

 

What = other refinement we need to consider?

=  

Thank= s, Linda Dunbar

=  

--_000_DF7F294AF4153D498141CBEFADB177049AAE498EB7EMBX01WFjnprn_-- From ldunbar@huawei.com Wed Nov 17 07:22:54 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7763A6904 for ; Wed, 17 Nov 2010 07:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS78T0pIZ+Wq for ; Wed, 17 Nov 2010 07:22:48 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id D15653A6923 for ; Wed, 17 Nov 2010 07:22:47 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC100A3EC38OU@usaga02-in.huawei.com> for armd@ietf.org; Wed, 17 Nov 2010 07:23:33 -0800 (PST) Received: from L735042 ([10.124.12.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC100CD4C38Z3@usaga02-in.huawei.com> for armd@ietf.org; Wed, 17 Nov 2010 07:23:32 -0800 (PST) Date: Wed, 17 Nov 2010 09:23:32 -0600 From: Linda Dunbar In-reply-to: To: 'Vishwas Manral' Message-id: <00c001cb866b$650c7910$6c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_t9Dk2K2c3d+oXvfhyMRgnA)" Thread-index: AcuF98ui6ydZQstwQcyCPSdHhdr2pwAcznLQ References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> Cc: rcallon@juniper.net, adrian@olddog.co.uk, 'Jari Arkko' , armd@ietf.org Subject: Re: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 15:22:54 -0000 This is a multi-part message in MIME format. --Boundary_(ID_t9Dk2K2c3d+oXvfhyMRgnA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Vishwas, See answers inserted below: -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, November 16, 2010 7:35 PM To: Linda Dunbar Cc: armd@ietf.org; rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; Claudio DeSanti Subject: Re: [armd] ARMD BOF follow up Hi Linda, I recently joined the group. So forgive me if I repeat something that has been discussed earlier. > For 1 million hosts, they would expect 468,240 > ARPs per second or 239 Mbps of ARP traffic to arrive at > each host at peak, which is more than enough to > overwhelm a standard 100 Mbps LAN connection. As ARP messages may not always be broadcast and the broadcast domain, is 239 Mbps the total ARP packet on a network or is it per host? [Linda] It is 239 Mbps towards each host. The traffic in the network is much higher. If it is not per host we should not talk about the overwhelming the 100Mpbs LAN. Thanks, Vishwas On Tue, Nov 16, 2010 at 1:21 PM, Linda Dunbar wrote: > Thanks to everyone who participated in the ARMD BOF discussion last Friday. > There were two major comments we heard from the audience. One comment is > wishing to see some statistics (by Internet AD Ralph), and another comment > is suggesting that we should go to "Data Center Operation" working group to > discuss with other "data center operation issues". > > > > Suggestion 1: Need ARP statistics: > > At the BOF, I forgot to mention that ARP statistics was quoted in our first > problem statement draft for ARP222 (back when it was only at the bar BOF > stage). As time goes on, we modified the draft several times by several > authors to include more important stuff, those numbers get eliminated from > the draft. > > > > The study done by CMU shows > (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): > > > > the number of ARP queries received at a workstation on CMU's School of > Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the > host received 1150 ARPs per second, and on average, the host received 89 > ARPs per second, which corresponds to 45 kbps of traffic. During the data > collection, 2,456 hosts were observed sending ARP queries. > > > > CMU expected that the amount of ARP traffic will scale linearly with the > number of hosts on the LAN. For 1 million hosts, they would expect 468,240 > ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, > which is more than enough to overwhelm a standard 100 Mbps LAN connection. > Ignoring the link capacity, forcing hosts to handle an extra half million > packets per second to inspect each ARP packet would impose a prohibitive > computational burden. > > > > > > As Cisco's Claudio DeSanti pointed out during the BOF, large number of > client subnets is effectively causing network to have the same problem as > one large broadcast domain. > > > > Question: What other statistics do people would like to see before being > convinced that ARP optimization is indeed necessary to make network scale to > support next gen mega data center? > > > > Suggestion 2: To lump the ARP improvement discussion with Data Center > Operation working group (by Ross Callon) > > Chatting with Ross Callon after the BOF, I learnt that Ross is referring to > the potential Cloud Operation group (as the result of Cloud bar BOF). > > > > Actually, I initially did present the ARP issue at the Cloud bar BOF at the > 78th IETF. But I learned that the audience for Cloud is too diverse to > converge on network problems. The problems which Cloud bar BOF has presented > cover Applications APIs, Logging, Security, etc. They are not even on > network problems. > > I am afraid of mixing network problems with application problems will just > get many people more confused. I remember during 78th IETF Cloud Bar BOF, > the people who focus on Application APIs think network problem is too > trivial to be even discussed at the same place with cloud applications > problems. > > > > Question: Should we go towards this direction? > > > > > > What other refinement we need to consider? > > > > Thanks, Linda Dunbar > > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > --Boundary_(ID_t9Dk2K2c3d+oXvfhyMRgnA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT RE: [armd] ARMD BOF follow up

Vishwas,

See answers inserted below:

-----Original Message-----
From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, November 16, 2010 7:35 PM
To: Linda Dunbar
Cc: armd@ietf.org; rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; Claudio DeSanti
Subject: Re: [armd] ARMD BOF follow up

Hi Linda,

I recently joined the group. So forgive me if I repeat something that

has been discussed earlier.

> For 1 million hosts, they would expect 468,240

> ARPs per second or 239 Mbps of ARP traffic to arrive at

> each host at peak, which is more than enough to

> overwhelm a standard 100 Mbps LAN connection.

As ARP messages may not always be  broadcast and the broadcast domain,

is 239 Mbps the total ARP packet on a network or is it per host?

[Linda] It is 239 Mbps towards each host. The traffic in the network is much higher.

If it is not per host we should not talk about the overwhelming the 100Mpbs LAN.

Thanks,

Vishwas

On Tue, Nov 16, 2010 at 1:21 PM, Linda Dunbar <ldunbar@huawei.com> wrote:

> Thanks to everyone who participated in the ARMD BOF discussion last Friday.

> There were two major comments we heard from the audience. One comment is

> wishing to see some statistics (by Internet AD Ralph), and another comment

> is suggesting that we should go to “Data Center Operation” working group to

> discuss with other “data center operation issues”.

>

>

>

> Suggestion 1: Need ARP statistics:

>

> At the BOF, I forgot to mention that ARP statistics was quoted in our first

> problem statement draft for ARP222 (back when it was only at the bar BOF

> stage).  As time goes on, we modified the draft several times by several

> authors to include more important stuff, those numbers get eliminated from

> the draft.

>

>

>

> The study done by CMU shows

> (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf):

>

>

>

> the number of ARP queries received at a workstation on CMUs School of

> Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the

> host received 1150 ARPs per second, and on average, the host received 89

> ARPs per second, which corresponds to 45 kbps of traffic. During the data

> collection, 2,456 hosts were observed sending ARP queries.

>

>

>

> CMU expected that the amount of ARP traffic will scale linearly with the

> number of hosts on the LAN. For 1 million hosts, they would expect 468,240

> ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak,

> which is more than enough to overwhelm a standard 100 Mbps LAN connection.

> Ignoring the link capacity, forcing hosts to handle an extra half million

> packets per second to inspect each ARP packet would impose a prohibitive

> computational burden.

>

>

>

>

>

> As Ciscos Claudio DeSanti pointed out during the BOF, large number of

> client subnets is effectively causing network to have the same problem as

> one large broadcast domain.

>

>

>

> Question: What other statistics do people would like to see before being

> convinced that ARP optimization is indeed necessary to make network scale to

> support next gen mega data center?

>

>

>

> Suggestion 2: To lump the ARP improvement discussion with Data Center

> Operation working group (by Ross Callon)

>

> Chatting with Ross Callon after the BOF, I learnt that Ross is referring to

> the potential Cloud Operation group (as the result of Cloud bar BOF).

>

>

>

>  Actually, I initially did present the ARP issue at the Cloud bar BOF at the

> 78th IETF. But I learned that the audience for Cloud is too diverse to

> converge on network problems. The problems which Cloud bar BOF has presented

> cover Applications APIs, Logging, Security, etc. They are not even on

> network problems.

>

> I am afraid of mixing network problems with application problems will just

> get many people more confused. I remember during 78th IETF Cloud Bar BOF,

> the people who focus on Application APIs think network problem is too

> trivial to be even discussed at the same place with cloud applications

> problems.

>

>

>

> Question: Should we go towards this direction?

>

>

>

>

>

> What other refinement we need to consider?

>

>

>

> Thanks, Linda Dunbar

>

>

>

> _______________________________________________

> armd mailing list

> armd@ietf.org

> https://www.ietf.org/mailman/listinfo/armd

>

>

--Boundary_(ID_t9Dk2K2c3d+oXvfhyMRgnA)-- From vishwas.ietf@gmail.com Wed Nov 17 10:35:38 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65AD23A696D for ; Wed, 17 Nov 2010 10:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+ZGbYurl6Ej for ; Wed, 17 Nov 2010 10:35:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 07E7C3A6953 for ; Wed, 17 Nov 2010 10:35:31 -0800 (PST) Received: by vws17 with SMTP id 17so9053vws.31 for ; Wed, 17 Nov 2010 10:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s8HcDgI22jy5O60711nRMKBb12NkrLyvlFV9dNTAe54=; b=R6EvgVoas6IuXtHaJq3lZKlG4ttyQ+Aui/qQimmPpqJoJNdz2TKUvuieo4SyPqh0B1 hjHXDzo6Ydn429LxHUIk+pQSmSAIT/Df9D6DbH2ySzuZzyIeCWDenFvYFDZ7O1jSurxv O7dkE59UKjfqvNos0IylSR+XJlzxjAsxtdE0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jJvAb08eALg9Ntd/EVmlu80Dpo/QsUYnLlJPBB4hN2HT5ijURwtFX1RA+IM0mn07xy m3mDOj+Pmw1FQoWxf2JT6zc++QCMWZVGNJWZtA2KsFR7BrwtO296Y9BESFyOx4Qi145T CS+GWbYOG5uipry9tyIWSFHMAycO7hUNzwNIE= MIME-Version: 1.0 Received: by 10.229.212.12 with SMTP id gq12mr7755714qcb.154.1290018976831; Wed, 17 Nov 2010 10:36:16 -0800 (PST) Received: by 10.229.86.19 with HTTP; Wed, 17 Nov 2010 10:36:16 -0800 (PST) In-Reply-To: <00c001cb866b$650c7910$6c0c7c0a@china.huawei.com> References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> <00c001cb866b$650c7910$6c0c7c0a@china.huawei.com> Date: Wed, 17 Nov 2010 10:36:16 -0800 Message-ID: From: Vishwas Manral To: Linda Dunbar Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: rcallon@juniper.net, adrian@olddog.co.uk, Jari Arkko , armd@ietf.org Subject: Re: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 18:35:38 -0000 Hi Linda, So is the assumption that of a million hosts 1/7 of the ARP traffic will be bound to 1 particular host - to get the number of 239 Mbps? I was wondering how the calculations were done. Thanks, Vishwas On Wed, Nov 17, 2010 at 7:23 AM, Linda Dunbar wrote: > Vishwas, > > See answers inserted below: > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Tuesday, November 16, 2010 7:35 PM > To: Linda Dunbar > Cc: armd@ietf.org; rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; > Claudio DeSanti > Subject: Re: [armd] ARMD BOF follow up > > Hi Linda, > > I recently joined the group. So forgive me if I repeat something that > > has been discussed earlier. > >> For 1 million hosts, they would expect 468,240 > >> ARPs per second or 239 Mbps of ARP traffic to arrive at > >> each host at peak, which is more than enough to > >> overwhelm a standard 100 Mbps LAN connection. > > As ARP messages may not always be=A0 broadcast and the broadcast domain, > > is 239 Mbps the total ARP packet on a network or is it per host? > > [Linda] It is 239 Mbps towards each host. The traffic in the network is m= uch > higher. > > If it is not per host we should not talk about the overwhelming the 100Mp= bs > LAN. > > Thanks, > > Vishwas > > On Tue, Nov 16, 2010 at 1:21 PM, Linda Dunbar wrote: > >> Thanks to everyone who participated in the ARMD BOF discussion last >> Friday. > >> There were two major comments we heard from the audience. One comment is > >> wishing to see some statistics (by Internet AD Ralph), and another comme= nt > >> is suggesting that we should go to =93Data Center Operation=94 working g= roup >> to > >> discuss with other =93data center operation issues=94. > >> > >> > >> > >> Suggestion 1: Need ARP statistics: > >> > >> At the BOF, I forgot to mention that ARP statistics was quoted in our >> first > >> problem statement draft for ARP222 (back when it was only at the bar BOF > >> stage). =A0As time goes on, we modified the draft several times by sever= al > >> authors to include more important stuff, those numbers get eliminated fr= om > >> the draft. > >> > >> > >> > >> The study done by CMU shows > >> (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): > >> > >> > >> > >> the number of ARP queries received at a workstation on CMU=92s School of > >> Computer Science LAN over a 12 hour period on August 9, 2004. At peak, t= he > >> host received 1150 ARPs per second, and on average, the host received 89 > >> ARPs per second, which corresponds to 45 kbps of traffic. During the dat= a > >> collection, 2,456 hosts were observed sending ARP queries. > >> > >> > >> > >> CMU expected that the amount of ARP traffic will scale linearly with the > >> number of hosts on the LAN. For 1 million hosts, they would expect 468,2= 40 > >> ARPs per second or 239 Mbps of ARP traffic to arrive at each host at pea= k, > >> which is more than enough to overwhelm a standard 100 Mbps LAN connectio= n. > >> Ignoring the link capacity, forcing hosts to handle an extra half millio= n > >> packets per second to inspect each ARP packet would impose a prohibitive > >> computational burden. > >> > >> > >> > >> > >> > >> As Cisco=92s Claudio DeSanti pointed out during the BOF, large number of > >> client subnets is effectively causing network to have the same problem a= s > >> one large broadcast domain. > >> > >> > >> > >> Question: What other statistics do people would like to see before being > >> convinced that ARP optimization is indeed necessary to make network scal= e >> to > >> support next gen mega data center? > >> > >> > >> > >> Suggestion 2: To lump the ARP improvement discussion with Data Center > >> Operation working group (by Ross Callon) > >> > >> Chatting with Ross Callon after the BOF, I learnt that Ross is referring >> to > >> the potential Cloud Operation group (as the result of Cloud bar BOF). > >> > >> > >> > >> =A0Actually, I initially did present the ARP issue at the Cloud bar BOF = at >> the > >> 78th IETF. But I learned that the audience for Cloud is too diverse to > >> converge on network problems. The problems which Cloud bar BOF has >> presented > >> cover Applications APIs, Logging, Security, etc. They are not even on > >> network problems. > >> > >> I am afraid of mixing network problems with application problems will ju= st > >> get many people more confused. I remember during 78th IETF Cloud Bar BOF= , > >> the people who focus on Application APIs think network problem is too > >> trivial to be even discussed at the same place with cloud applications > >> problems. > >> > >> > >> > >> Question: Should we go towards this direction? > >> > >> > >> > >> > >> > >> What other refinement we need to consider? > >> > >> > >> > >> Thanks, Linda Dunbar > >> > >> > >> > >> _______________________________________________ > >> armd mailing list > >> armd@ietf.org > >> https://www.ietf.org/mailman/listinfo/armd > >> > >> From ldunbar@huawei.com Wed Nov 17 08:39:12 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C133A6940 for ; Wed, 17 Nov 2010 08:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNRqSTJtBW4n for ; Wed, 17 Nov 2010 08:39:01 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 107903A6942 for ; Wed, 17 Nov 2010 08:39:00 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC100D80FM7OW@usaga04-in.huawei.com> for armd@ietf.org; Wed, 17 Nov 2010 10:39:44 -0600 (CST) Received: from L735042 ([10.124.12.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC10001VFM4WT@usaga04-in.huawei.com> for armd@ietf.org; Wed, 17 Nov 2010 10:39:43 -0600 (CST) Date: Wed, 17 Nov 2010 10:39:43 -0600 From: Linda Dunbar In-reply-to: To: 'Ross Callon' , adrian@olddog.co.uk, "'So, Ning'" , armd@ietf.org Message-id: <00e301cb8676$0a5f9410$6c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_ztsRg1Oh+UXtd90Va2Se7w)" Thread-index: AQDWFxtyC9s+fQZHnPtRs1kFXSPnJwKNn/pNlUvr6lCAAEEnwIAAEVUg References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> <14584D6EE26B314187A4F68BA206060005C3DA75@ASHEVS008.mcilink.com> <03c601cb8643$d94fd650$8bef82f0$@olddog.co.uk> X-Mailman-Approved-At: Thu, 18 Nov 2010 08:06:30 -0800 Cc: 'Spencer Dawkins' , 'Ronald Bonica' , 'Hares Susan' , 'Jari Arkko' , 'Claudio DeSanti' Subject: Re: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 16:39:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ztsRg1Oh+UXtd90Va2Se7w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Ross and Adrian, Thank you very much for the valuable input. Glad to learn that everyone agrees that there is clearly a problem to be solved and the urgency to begin work. The discussion is on where the work should be chartered. The detailed problems for ARMD has been described by http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD-Problem%2 0Statement.pdf Please provide comments if the problems stated in the document are not clear enough. There are 4 potential solutions presented at the BOF. Clearly protocol extension has been identified. I am very concerned of lumping ARMD problems with Cloud Data Center Operation. As of now, in addition to Cloud Application extension (such as APIs, Logging, and Security), the Cloud Data Center operations already include the following areas for network protocol extension: * VPN extension for Cloud * Virtual Resource management * Cloud hosted UE * Service mobility for virtualized networks ARMD is a very tightly scoped problem domain for large data center. Even though it is part of total large data center problem domain, the ARMD itself can be very easily carved out from other problems associated with Cloud Data Center. I thought that IETF always wants to create a small working group focusing on one problem at a time. Best Regards Linda Dunbar _____ From: Ross Callon [mailto:rcallon@juniper.net] Sent: Wednesday, November 17, 2010 8:41 AM To: adrian@olddog.co.uk; 'So, Ning'; 'Linda Dunbar'; armd@ietf.org Cc: 'Jari Arkko'; 'Claudio DeSanti'; Ronald Bonica Subject: RE: [armd] ARMD BOF follow up I have CC'd Ron Bonica on this, as he is the operations AD. My understanding of the results of the BOF is that there is clearly a problem to be solved, an urgency to begin work, and several possible solutions. There is also a need to clearly document what the problem is, the requirements for a solution, and the range of possible solutions. This is work that could be done in a data center operations working group. It is possible that some potential solutions may involve care of how existing protocols are deployed (an operational issue). It is possible that some potential solutions may involve extensions or changes to existing IETF protocols. I am not an AD (and no longer play one on TV or anywhere else). My understanding is that these extensions to existing IETF protocols would need to be done in other IETF WGs - presumably the ones responsible for whatever protocol is being extended. However, it will be much easier to charter this work once there is agreement on an initial draft documenting what the problem is and requirements of a solution. Ross From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, November 17, 2010 5:40 AM To: 'So, Ning'; 'Linda Dunbar'; armd@ietf.org Cc: Ross Callon; 'Jari Arkko'; 'Claudio DeSanti' Subject: RE: [armd] ARMD BOF follow up Hi, I don't believe Ops Area WGs are allowed to do protocol extensions (except for management protocols), so option 2 is not an option if the ARMD work requires protocol changes. OTOH, if the ARMD work collapses to how to operate ARP in a specific environment, then this would be clear for Ops. Adrian From: So, Ning [mailto:ning.so@verizonbusiness.com] Sent: 16 November 2010 21:33 To: Linda Dunbar; armd@ietf.org Cc: rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; Claudio DeSanti Subject: RE: [armd] ARMD BOF follow up Linda, I concur with your concern on your suggestion #2. Cloud Data Center WG (name will likely change) and Cloud AppsBoF were both being proposed during the meeting last week. One potential solution is to have network related ARMD drafts go to the new WG, while non-network related SRMD drafts go to the new Cloud AppsBoF. Best regrads, Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 _____ From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, November 16, 2010 3:22 PM To: armd@ietf.org Cc: rcallon@juniper.net; adrian@olddog.co.uk; 'Jari Arkko'; 'Claudio DeSanti' Subject: [armd] ARMD BOF follow up Thanks to everyone who participated in the ARMD BOF discussion last Friday. There were two major comments we heard from the audience. One comment is wishing to see some statistics (by Internet AD Ralph), and another comment is suggesting that we should go to "Data Center Operation" working group to discuss with other "data center operation issues". Suggestion 1: Need ARP statistics: At the BOF, I forgot to mention that ARP statistics was quoted in our first problem statement draft for ARP222 (back when it was only at the bar BOF stage). As time goes on, we modified the draft several times by several authors to include more important stuff, those numbers get eliminated from the draft. The study done by CMU shows (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): the number of ARP queries received at a workstation on CMU's School of Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the host received 1150 ARPs per second, and on average, the host received 89 ARPs per second, which corresponds to 45 kbps of traffic. During the data collection, 2,456 hosts were observed sending ARP queries. CMU expected that the amount of ARP traffic will scale linearly with the number of hosts on the LAN. For 1 million hosts, they would expect 468,240 ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, which is more than enough to overwhelm a standard 100 Mbps LAN connection. Ignoring the link capacity, forcing hosts to handle an extra half million packets per second to inspect each ARP packet would impose a prohibitive computational burden. As Cisco's Claudio DeSanti pointed out during the BOF, large number of client subnets is effectively causing network to have the same problem as one large broadcast domain. Question: What other statistics do people would like to see before being convinced that ARP optimization is indeed necessary to make network scale to support next gen mega data center? Suggestion 2: To lump the ARP improvement discussion with Data Center Operation working group (by Ross Callon) Chatting with Ross Callon after the BOF, I learnt that Ross is referring to the potential Cloud Operation group (as the result of Cloud bar BOF). Actually, I initially did present the ARP issue at the Cloud bar BOF at the 78th IETF. But I learned that the audience for Cloud is too diverse to converge on network problems. The problems which Cloud bar BOF has presented cover Applications APIs, Logging, Security, etc. They are not even on network problems. I am afraid of mixing network problems with application problems will just get many people more confused. I remember during 78th IETF Cloud Bar BOF, the people who focus on Application APIs think network problem is too trivial to be even discussed at the same place with cloud applications problems. Question: Should we go towards this direction? What other refinement we need to consider? Thanks, Linda Dunbar --Boundary_(ID_ztsRg1Oh+UXtd90Va2Se7w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Ross and Adrian,

 

Thank you very much for the valuable input. Glad to learn that everyone agrees that there is clearly a problem to be solved and the urgency to begin work. The discussion is on where the work should be chartered. The detailed problems for ARMD has been described by http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD-Problem%20Statement.pdf

Please provide comments if the problems stated in the document are not clear enough.

There are 4 potential solutions presented at the BOF. Clearly protocol extension has been identified.

 

I am very concerned of lumping ARMD problems with Cloud Data Center Operation. As of now, in addition to Cloud Application extension (such as APIs, Logging, and Security), the Cloud Data Center operations already include the following areas for network protocol extension:

·        VPN extension for Cloud

·        Virtual Resource management

·        Cloud hosted UE

·        Service mobility for virtualized networks

 

ARMD is a very tightly scoped problem domain for large data center. Even though it is part of total large data center problem domain, the ARMD itself can be very easily carved out from other problems associated with Cloud Data Center. I thought that IETF always wants to create a small working group focusing on one problem at a time.

 

Best Regards

 

Linda Dunbar

 

 

 

 


From: Ross Callon [mailto:rcallon@juniper.net]
Sent: Wednesday, November 17, 2010 8:41 AM
To: adrian@olddog.co.uk; 'So, Ning'; 'Linda Dunbar'; armd@ietf.org
Cc: 'Jari Arkko'; 'Claudio DeSanti'; Ronald Bonica
Subject: RE: [armd] ARMD BOF follow up

 

I have CC’d Ron Bonica on this, as he is the operations AD.

 

My understanding of the results of the BOF is that there is clearly a problem to be solved, an urgency to begin work, and several possible solutions. 

 

There is also a need to clearly document what the problem is, the requirements for a solution, and the range of possible solutions. This is work that could be done in a data center operations working group.

 

It is possible that some potential solutions may involve care of how existing protocols are deployed (an operational issue).

 

It is possible that some potential solutions may involve extensions or changes to existing IETF protocols. I am not an AD (and no longer play one on TV or anywhere else). My understanding is that these extensions to existing IETF protocols would need to be done in other IETF WGs – presumably the ones responsible for whatever protocol is being extended. However, it will be much easier to charter this work once there is agreement on an initial draft documenting what the problem is and requirements of a solution.

 

Ross

 

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, November 17, 2010 5:40 AM
To: 'So, Ning'; 'Linda Dunbar'; armd@ietf.org
Cc: Ross Callon; 'Jari Arkko'; 'Claudio DeSanti'
Subject: RE: [armd] ARMD BOF follow up

 

Hi,

 

I don't believe Ops Area WGs are allowed to do protocol extensions (except for management protocols), so option 2 is not an option if the ARMD work requires protocol changes.

 

OTOH, if the ARMD work collapses to how to operate ARP in a specific environment, then this would be clear for Ops.

 

Adrian

 

From: So, Ning [mailto:ning.so@verizonbusiness.com]
Sent: 16 November 2010 21:33
To: Linda Dunbar; armd@ietf.org
Cc: rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; Claudio DeSanti
Subject: RE: [armd] ARMD BOF follow up

 

Linda,

 

I concur with your concern on your suggestion #2.  Cloud Data Center WG (name will likely change) and Cloud AppsBoF were both being proposed during the meeting last week.  One potential solution is to have network related ARMD drafts go to the new WG, while non-network related SRMD drafts go to the new Cloud AppsBoF.  

 

 

Best regrads,

 

Ning So

Network Evolution Planning

Verizon, Inc.

(office) 972-729-7905

(Cell) 972-955-0914

 


From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Tuesday, November 16, 2010 3:22 PM
To: armd@ietf.org
Cc: rcallon@juniper.net; adrian@olddog.co.uk; 'Jari Arkko'; 'Claudio DeSanti'
Subject: [armd] ARMD BOF follow up

 

Thanks to everyone who participated in the ARMD BOF discussion last Friday. There were two major comments we heard from the audience. One comment is wishing to see some statistics (by Internet AD Ralph), and another comment is suggesting that we should go to “Data Center Operation” working group to discuss with other “data center operation issues”.

 

Suggestion 1: Need ARP statistics:

At the BOF, I forgot to mention that ARP statistics was quoted in our first problem statement draft for ARP222 (back when it was only at the bar BOF stage).  As time goes on, we modified the draft several times by several authors to include more important stuff, those numbers get eliminated from the draft.

 

The study done by CMU shows (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf):

 

the number of ARP queries received at a workstation on CMU’s School of Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the host received 1150 ARPs per second, and on average, the host received 89 ARPs per second, which corresponds to 45 kbps of traffic. During the data collection, 2,456 hosts were observed sending ARP queries.

 

CMU expected that the amount of ARP traffic will scale linearly with the number of hosts on the LAN. For 1 million hosts, they would expect 468,240 ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, which is more than enough to overwhelm a standard 100 Mbps LAN connection. Ignoring the link capacity, forcing hosts to handle an extra half million packets per second to inspect each ARP packet would impose a prohibitive computational burden.

 

 

As Cisco’s Claudio DeSanti pointed out during the BOF, large number of client subnets is effectively causing network to have the same problem as one large broadcast domain.

 

Question: What other statistics do people would like to see before being convinced that ARP optimization is indeed necessary to make network scale to support next gen mega data center?

 

Suggestion 2: To lump the ARP improvement discussion with Data Center Operation working group (by Ross Callon)

Chatting with Ross Callon after the BOF, I learnt that Ross is referring to the potential Cloud Operation group (as the result of Cloud bar BOF).

 

 Actually, I initially did present the ARP issue at the Cloud bar BOF at the 78th IETF. But I learned that the audience for Cloud is too diverse to converge on network problems. The problems which Cloud bar BOF has presented cover Applications APIs, Logging, Security, etc. They are not even on network problems.

I am afraid of mixing network problems with application problems will just get many people more confused. I remember during 78th IETF Cloud Bar BOF, the people who focus on Application APIs think network problem is too trivial to be even discussed at the same place with cloud applications problems.

 

Question: Should we go towards this direction?

 

 

What other refinement we need to consider?

 

Thanks, Linda Dunbar

 

--Boundary_(ID_ztsRg1Oh+UXtd90Va2Se7w)-- From vishwas.ietf@gmail.com Sat Nov 20 13:58:29 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A130D28C111 for ; Sat, 20 Nov 2010 13:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtugLLno4roQ for ; Sat, 20 Nov 2010 13:58:28 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D65C728C0D8 for ; Sat, 20 Nov 2010 13:58:27 -0800 (PST) Received: by qwb7 with SMTP id 7so970014qwb.31 for ; Sat, 20 Nov 2010 13:59:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9J/QI5TiqjiJ3gHeBC+vmubS1P3EGCBvfjUMgfDJaOg=; b=wVumj6Zu6jLHeHpNPW6qSnlLED4fqyjYaTQZ4PPKT1/lmy82wmGDGacCyO3VEfDLNp XHkm+meIcf13E6S8yDswW3PwF/CcQdvepNN79+FGBKsE/Ltz4wPM0oL/1vMJAudWP2GM y3IlMKftB29MiNFCJBbejL7jxksbaYA4/v9N4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XtIRIuZtFVMXAgImNxGgB2+bmT5PH9HiSLVhm4kUyVes6Sw1HeO2+QY3l4LKW8AgwG 5IZlqPACk7M+YsY3PHfBlOY8msIF7XOvseUE5b92oObOcP/MV0eFOl2IMS9sg1FKKTSs Y9UkplueFxoHIbfip9JLGSbnRRXiUJawBHB2Y= MIME-Version: 1.0 Received: by 10.229.233.18 with SMTP id jw18mr3346775qcb.192.1290290359243; Sat, 20 Nov 2010 13:59:19 -0800 (PST) Received: by 10.229.86.19 with HTTP; Sat, 20 Nov 2010 13:59:19 -0800 (PST) In-Reply-To: References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> <00c001cb866b$650c7910$6c0c7c0a@china.huawei.com> Date: Sat, 20 Nov 2010 13:59:19 -0800 Message-ID: From: Vishwas Manral To: Linda Dunbar Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: adrian@olddog.co.uk, Jari Arkko , armd@ietf.org Subject: Re: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 21:58:29 -0000 Hi Linda, Reading one of the papers on Data center flows done by MS Research, it seems 80% of the cloud data center data stays within the rack. It would also mean that in such cases ARP would probably not need to be resolved in most of these cases. Thanks, Vishwas On Wed, Nov 17, 2010 at 10:36 AM, Vishwas Manral w= rote: > Hi Linda, > > So is the assumption that of a million hosts 1/7 of the ARP traffic > will be bound to 1 particular host - to get the number of 239 Mbps? > > I was wondering how the calculations were done. > > Thanks, > Vishwas > > On Wed, Nov 17, 2010 at 7:23 AM, Linda Dunbar wrote: >> Vishwas, >> >> See answers inserted below: >> >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Tuesday, November 16, 2010 7:35 PM >> To: Linda Dunbar >> Cc: armd@ietf.org; rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; >> Claudio DeSanti >> Subject: Re: [armd] ARMD BOF follow up >> >> Hi Linda, >> >> I recently joined the group. So forgive me if I repeat something that >> >> has been discussed earlier. >> >>> For 1 million hosts, they would expect 468,240 >> >>> ARPs per second or 239 Mbps of ARP traffic to arrive at >> >>> each host at peak, which is more than enough to >> >>> overwhelm a standard 100 Mbps LAN connection. >> >> As ARP messages may not always be=A0 broadcast and the broadcast domain, >> >> is 239 Mbps the total ARP packet on a network or is it per host? >> >> [Linda] It is 239 Mbps towards each host. The traffic in the network is = much >> higher. >> >> If it is not per host we should not talk about the overwhelming the 100M= pbs >> LAN. >> >> Thanks, >> >> Vishwas >> >> On Tue, Nov 16, 2010 at 1:21 PM, Linda Dunbar wrote= : >> >>> Thanks to everyone who participated in the ARMD BOF discussion last >>> Friday. >> >>> There were two major comments we heard from the audience. One comment i= s >> >>> wishing to see some statistics (by Internet AD Ralph), and another comm= ent >> >>> is suggesting that we should go to =93Data Center Operation=94 working = group >>> to >> >>> discuss with other =93data center operation issues=94. >> >>> >> >>> >> >>> >> >>> Suggestion 1: Need ARP statistics: >> >>> >> >>> At the BOF, I forgot to mention that ARP statistics was quoted in our >>> first >> >>> problem statement draft for ARP222 (back when it was only at the bar BO= F >> >>> stage). =A0As time goes on, we modified the draft several times by seve= ral >> >>> authors to include more important stuff, those numbers get eliminated f= rom >> >>> the draft. >> >>> >> >>> >> >>> >> >>> The study done by CMU shows >> >>> (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): >> >>> >> >>> >> >>> >> >>> the number of ARP queries received at a workstation on CMU=92s School o= f >> >>> Computer Science LAN over a 12 hour period on August 9, 2004. At peak, = the >> >>> host received 1150 ARPs per second, and on average, the host received 8= 9 >> >>> ARPs per second, which corresponds to 45 kbps of traffic. During the da= ta >> >>> collection, 2,456 hosts were observed sending ARP queries. >> >>> >> >>> >> >>> >> >>> CMU expected that the amount of ARP traffic will scale linearly with th= e >> >>> number of hosts on the LAN. For 1 million hosts, they would expect 468,= 240 >> >>> ARPs per second or 239 Mbps of ARP traffic to arrive at each host at pe= ak, >> >>> which is more than enough to overwhelm a standard 100 Mbps LAN connecti= on. >> >>> Ignoring the link capacity, forcing hosts to handle an extra half milli= on >> >>> packets per second to inspect each ARP packet would impose a prohibitiv= e >> >>> computational burden. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> As Cisco=92s Claudio DeSanti pointed out during the BOF, large number o= f >> >>> client subnets is effectively causing network to have the same problem = as >> >>> one large broadcast domain. >> >>> >> >>> >> >>> >> >>> Question: What other statistics do people would like to see before bein= g >> >>> convinced that ARP optimization is indeed necessary to make network sca= le >>> to >> >>> support next gen mega data center? >> >>> >> >>> >> >>> >> >>> Suggestion 2: To lump the ARP improvement discussion with Data Center >> >>> Operation working group (by Ross Callon) >> >>> >> >>> Chatting with Ross Callon after the BOF, I learnt that Ross is referrin= g >>> to >> >>> the potential Cloud Operation group (as the result of Cloud bar BOF). >> >>> >> >>> >> >>> >> >>> =A0Actually, I initially did present the ARP issue at the Cloud bar BOF= at >>> the >> >>> 78th IETF. But I learned that the audience for Cloud is too diverse to >> >>> converge on network problems. The problems which Cloud bar BOF has >>> presented >> >>> cover Applications APIs, Logging, Security, etc. They are not even on >> >>> network problems. >> >>> >> >>> I am afraid of mixing network problems with application problems will j= ust >> >>> get many people more confused. I remember during 78th IETF Cloud Bar BO= F, >> >>> the people who focus on Application APIs think network problem is too >> >>> trivial to be even discussed at the same place with cloud applications >> >>> problems. >> >>> >> >>> >> >>> >> >>> Question: Should we go towards this direction? >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> What other refinement we need to consider? >> >>> >> >>> >> >>> >> >>> Thanks, Linda Dunbar >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> armd mailing list >> >>> armd@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/armd >> >>> >> >>> > From ldunbar@huawei.com Mon Nov 22 15:57:55 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE15128C17D for ; Mon, 22 Nov 2010 15:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.797 X-Spam-Level: X-Spam-Status: No, score=-104.797 tagged_above=-999 required=5 tests=[AWL=1.802, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ko3Au6741QFh for ; Mon, 22 Nov 2010 15:57:54 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id B22023A6A0D for ; Mon, 22 Nov 2010 15:57:53 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCB00CHD9A10B@usaga02-in.huawei.com> for armd@ietf.org; Mon, 22 Nov 2010 15:58:50 -0800 (PST) Received: from L735042 ([10.124.12.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCB0063N9A1L3@usaga02-in.huawei.com> for armd@ietf.org; Mon, 22 Nov 2010 15:58:49 -0800 (PST) Date: Mon, 22 Nov 2010 17:58:49 -0600 From: Linda Dunbar In-reply-to: To: 'Vishwas Manral' Message-id: <01cc01cb8aa1$351557b0$6c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcuI/jVzi/lc8CsaSpyd44OFzFrt6ABoiIUQ References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> <00c001cb866b$650c7910$6c0c7c0a@china.huawei.com> Cc: adrian@olddog.co.uk, 'Jari Arkko' , armd@ietf.org Subject: Re: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 23:57:55 -0000 Vishwas:=20 Can you point out which paper you are referring to?=20 Many Cloud research papers, like this one from MS: http://portal.acm.org/citation.cfm?id=3D1496103 are arguing that Network constraints (like VLAN, ARPs, ACL) are the major barrier to Data Center agility even though network is only 15% of total data center cost.=20 The trend of data center is to scale out, instead of scale up, which = means there would be more and more servers in data center. To be able to = provide host service anywhere on any servers is the key in reducing overall data center cost.=20 Linda Dunbar -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Saturday, November 20, 2010 3:59 PM To: Linda Dunbar Cc: adrian@olddog.co.uk; Jari Arkko; armd@ietf.org Subject: Re: [armd] ARMD BOF follow up Hi Linda, Reading one of the papers on Data center flows done by MS Research, it seems 80% of the cloud data center data stays within the rack. It would also mean that in such cases ARP would probably not need to be resolved in most of these cases. Thanks, Vishwas On Wed, Nov 17, 2010 at 10:36 AM, Vishwas Manral = wrote: > Hi Linda, > > So is the assumption that of a million hosts 1/7 of the ARP traffic > will be bound to 1 particular host - to get the number of 239 Mbps? > > I was wondering how the calculations were done. > > Thanks, > Vishwas > > On Wed, Nov 17, 2010 at 7:23 AM, Linda Dunbar = wrote: >> Vishwas, >> >> See answers inserted below: >> >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Tuesday, November 16, 2010 7:35 PM >> To: Linda Dunbar >> Cc: armd@ietf.org; rcallon@juniper.net; adrian@olddog.co.uk; Jari = Arkko; >> Claudio DeSanti >> Subject: Re: [armd] ARMD BOF follow up >> >> Hi Linda, >> >> I recently joined the group. So forgive me if I repeat something that >> >> has been discussed earlier. >> >>> For 1 million hosts, they would expect 468,240 >> >>> ARPs per second or 239 Mbps of ARP traffic to arrive at >> >>> each host at peak, which is more than enough to >> >>> overwhelm a standard 100 Mbps LAN connection. >> >> As ARP messages may not always be=A0 broadcast and the broadcast = domain, >> >> is 239 Mbps the total ARP packet on a network or is it per host? >> >> [Linda] It is 239 Mbps towards each host. The traffic in the network = is much >> higher. >> >> If it is not per host we should not talk about the overwhelming the 100Mpbs >> LAN. >> >> Thanks, >> >> Vishwas >> >> On Tue, Nov 16, 2010 at 1:21 PM, Linda Dunbar = wrote: >> >>> Thanks to everyone who participated in the ARMD BOF discussion last >>> Friday. >> >>> There were two major comments we heard from the audience. One = comment is >> >>> wishing to see some statistics (by Internet AD Ralph), and another comment >> >>> is suggesting that we should go to =93Data Center Operation=94 = working group >>> to >> >>> discuss with other =93data center operation issues=94. >> >>> >> >>> >> >>> >> >>> Suggestion 1: Need ARP statistics: >> >>> >> >>> At the BOF, I forgot to mention that ARP statistics was quoted in = our >>> first >> >>> problem statement draft for ARP222 (back when it was only at the bar = BOF >> >>> stage). =A0As time goes on, we modified the draft several times by = several >> >>> authors to include more important stuff, those numbers get = eliminated from >> >>> the draft. >> >>> >> >>> >> >>> >> >>> The study done by CMU shows >> >>> (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): >> >>> >> >>> >> >>> >> >>> the number of ARP queries received at a workstation on CMU=92s = School of >> >>> Computer Science LAN over a 12 hour period on August 9, 2004. At = peak, the >> >>> host received 1150 ARPs per second, and on average, the host = received 89 >> >>> ARPs per second, which corresponds to 45 kbps of traffic. During the data >> >>> collection, 2,456 hosts were observed sending ARP queries. >> >>> >> >>> >> >>> >> >>> CMU expected that the amount of ARP traffic will scale linearly with = the >> >>> number of hosts on the LAN. For 1 million hosts, they would expect 468,240 >> >>> ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, >> >>> which is more than enough to overwhelm a standard 100 Mbps LAN connection. >> >>> Ignoring the link capacity, forcing hosts to handle an extra half million >> >>> packets per second to inspect each ARP packet would impose a = prohibitive >> >>> computational burden. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> As Cisco=92s Claudio DeSanti pointed out during the BOF, large = number of >> >>> client subnets is effectively causing network to have the same = problem as >> >>> one large broadcast domain. >> >>> >> >>> >> >>> >> >>> Question: What other statistics do people would like to see before = being >> >>> convinced that ARP optimization is indeed necessary to make network scale >>> to >> >>> support next gen mega data center? >> >>> >> >>> >> >>> >> >>> Suggestion 2: To lump the ARP improvement discussion with Data = Center >> >>> Operation working group (by Ross Callon) >> >>> >> >>> Chatting with Ross Callon after the BOF, I learnt that Ross is = referring >>> to >> >>> the potential Cloud Operation group (as the result of Cloud bar = BOF). >> >>> >> >>> >> >>> >> >>> =A0Actually, I initially did present the ARP issue at the Cloud bar = BOF at >>> the >> >>> 78th IETF. But I learned that the audience for Cloud is too diverse = to >> >>> converge on network problems. The problems which Cloud bar BOF has >>> presented >> >>> cover Applications APIs, Logging, Security, etc. They are not even = on >> >>> network problems. >> >>> >> >>> I am afraid of mixing network problems with application problems = will just >> >>> get many people more confused. I remember during 78th IETF Cloud Bar BOF, >> >>> the people who focus on Application APIs think network problem is = too >> >>> trivial to be even discussed at the same place with cloud = applications >> >>> problems. >> >>> >> >>> >> >>> >> >>> Question: Should we go towards this direction? >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> What other refinement we need to consider? >> >>> >> >>> >> >>> >> >>> Thanks, Linda Dunbar >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> armd mailing list >> >>> armd@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/armd >> >>> >> >>> > _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From vishwas.ietf@gmail.com Mon Nov 22 16:56:41 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6ED028C0D8 for ; Mon, 22 Nov 2010 16:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrivPA4Aiu5l for ; Mon, 22 Nov 2010 16:56:39 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 94B2A3A6B02 for ; Mon, 22 Nov 2010 16:56:38 -0800 (PST) Received: by qyk11 with SMTP id 11so738023qyk.10 for ; Mon, 22 Nov 2010 16:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=T4Eg6uqhLSFkgrSv0JlrhOqPz0ip3zq7QBtcFmaLE5o=; b=rYjhoCM1uVc+ZbwXV17vbEpv8NZZh35kb/KFd8VSHeNWQtJJDB/SQ08rY4SReeVb78 kOd6HWaduQ/tQedH/nlmDFqKJnuLcEJGxuG51/QKMZ/48G3PigNSAsfwEwDYqm6GgrrH ESTHyGeXraj9zAC63Qhz21vVZnMZKJEBAe4j4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BLKmZK7WYjFWOkEQMnm2U//th0sIL/sM6F+fmX/CWMBZGJ5ei4dzbvcFC6GnHiwuRh pYVnh41Z+sqXDgcZlfspmTIO+hqKFUGytbt9A8oz3bYOMw/Gk9ZUMQxcb1/0Lutqo7KF sQKQX6x6B1VTPgFFdWu9xcZBp4HRUzR6Pqm20= MIME-Version: 1.0 Received: by 10.229.233.142 with SMTP id jy14mr5669929qcb.2.1290473853934; Mon, 22 Nov 2010 16:57:33 -0800 (PST) Received: by 10.229.86.19 with HTTP; Mon, 22 Nov 2010 16:57:33 -0800 (PST) In-Reply-To: <01cc01cb8aa1$351557b0$6c0c7c0a@china.huawei.com> References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> <00c001cb866b$650c7910$6c0c7c0a@china.huawei.com> <01cc01cb8aa1$351557b0$6c0c7c0a@china.huawei.com> Date: Mon, 22 Nov 2010 16:57:33 -0800 Message-ID: From: Vishwas Manral To: Linda Dunbar Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: adrian@olddog.co.uk, Jari Arkko , armd@ietf.org Subject: Re: [armd] ARMD BOF follow up X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 00:56:42 -0000 Hi Linda, I am refering to the paper http://research.microsoft.com/pubs/138279/DC-Network-Characterization-imc20= 10.pdf I am not saying that ARP scalability is not required (I have noticed that with even a few thousand ARP the CPU can get overwhelmed). I am just trying to understand the constraints under which the numbers being used are defined. Thanks, Vishwas On Mon, Nov 22, 2010 at 3:58 PM, Linda Dunbar wrote: > Vishwas: > > Can you point out which paper you are referring to? > > Many Cloud research papers, like this one from MS: > http://portal.acm.org/citation.cfm?id=3D1496103 are arguing that Network > constraints (like VLAN, ARPs, ACL) are the major barrier to Data Center > agility even though network is only 15% of total data center cost. > > The trend of data center is to scale out, instead of scale up, which mean= s > there would be more and more servers in data center. To be able to provid= e > host service anywhere on any servers is the key in reducing overall data > center cost. > > Linda Dunbar > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Vishwas Manral > Sent: Saturday, November 20, 2010 3:59 PM > To: Linda Dunbar > Cc: adrian@olddog.co.uk; Jari Arkko; armd@ietf.org > Subject: Re: [armd] ARMD BOF follow up > > Hi Linda, > > Reading one of the papers on Data center flows done by MS Research, it > seems 80% of the cloud data center data stays within the rack. It > would also mean that in such cases ARP would probably not need to be > resolved in most of these cases. > > Thanks, > Vishwas > > On Wed, Nov 17, 2010 at 10:36 AM, Vishwas Manral > wrote: >> Hi Linda, >> >> So is the assumption that of a million hosts 1/7 of the ARP traffic >> will be bound to 1 particular host - to get the number of 239 Mbps? >> >> I was wondering how the calculations were done. >> >> Thanks, >> Vishwas >> >> On Wed, Nov 17, 2010 at 7:23 AM, Linda Dunbar wrote= : >>> Vishwas, >>> >>> See answers inserted below: >>> >>> -----Original Message----- >>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>> Sent: Tuesday, November 16, 2010 7:35 PM >>> To: Linda Dunbar >>> Cc: armd@ietf.org; rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko= ; >>> Claudio DeSanti >>> Subject: Re: [armd] ARMD BOF follow up >>> >>> Hi Linda, >>> >>> I recently joined the group. So forgive me if I repeat something that >>> >>> has been discussed earlier. >>> >>>> For 1 million hosts, they would expect 468,240 >>> >>>> ARPs per second or 239 Mbps of ARP traffic to arrive at >>> >>>> each host at peak, which is more than enough to >>> >>>> overwhelm a standard 100 Mbps LAN connection. >>> >>> As ARP messages may not always be=A0 broadcast and the broadcast domain= , >>> >>> is 239 Mbps the total ARP packet on a network or is it per host? >>> >>> [Linda] It is 239 Mbps towards each host. The traffic in the network is > much >>> higher. >>> >>> If it is not per host we should not talk about the overwhelming the > 100Mpbs >>> LAN. >>> >>> Thanks, >>> >>> Vishwas >>> >>> On Tue, Nov 16, 2010 at 1:21 PM, Linda Dunbar wrot= e: >>> >>>> Thanks to everyone who participated in the ARMD BOF discussion last >>>> Friday. >>> >>>> There were two major comments we heard from the audience. One comment = is >>> >>>> wishing to see some statistics (by Internet AD Ralph), and another > comment >>> >>>> is suggesting that we should go to =93Data Center Operation=94 working= group >>>> to >>> >>>> discuss with other =93data center operation issues=94. >>> >>>> >>> >>>> >>> >>>> >>> >>>> Suggestion 1: Need ARP statistics: >>> >>>> >>> >>>> At the BOF, I forgot to mention that ARP statistics was quoted in our >>>> first >>> >>>> problem statement draft for ARP222 (back when it was only at the bar B= OF >>> >>>> stage). =A0As time goes on, we modified the draft several times by sev= eral >>> >>>> authors to include more important stuff, those numbers get eliminated > from >>> >>>> the draft. >>> >>>> >>> >>>> >>> >>>> >>> >>>> The study done by CMU shows >>> >>>> (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): >>> >>>> >>> >>>> >>> >>>> >>> >>>> the number of ARP queries received at a workstation on CMU=92s School = of >>> >>>> Computer Science LAN over a 12 hour period on August 9, 2004. At peak, > the >>> >>>> host received 1150 ARPs per second, and on average, the host received = 89 >>> >>>> ARPs per second, which corresponds to 45 kbps of traffic. During the > data >>> >>>> collection, 2,456 hosts were observed sending ARP queries. >>> >>>> >>> >>>> >>> >>>> >>> >>>> CMU expected that the amount of ARP traffic will scale linearly with t= he >>> >>>> number of hosts on the LAN. For 1 million hosts, they would expect > 468,240 >>> >>>> ARPs per second or 239 Mbps of ARP traffic to arrive at each host at > peak, >>> >>>> which is more than enough to overwhelm a standard 100 Mbps LAN > connection. >>> >>>> Ignoring the link capacity, forcing hosts to handle an extra half > million >>> >>>> packets per second to inspect each ARP packet would impose a prohibiti= ve >>> >>>> computational burden. >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> As Cisco=92s Claudio DeSanti pointed out during the BOF, large number = of >>> >>>> client subnets is effectively causing network to have the same problem > as >>> >>>> one large broadcast domain. >>> >>>> >>> >>>> >>> >>>> >>> >>>> Question: What other statistics do people would like to see before bei= ng >>> >>>> convinced that ARP optimization is indeed necessary to make network > scale >>>> to >>> >>>> support next gen mega data center? >>> >>>> >>> >>>> >>> >>>> >>> >>>> Suggestion 2: To lump the ARP improvement discussion with Data Center >>> >>>> Operation working group (by Ross Callon) >>> >>>> >>> >>>> Chatting with Ross Callon after the BOF, I learnt that Ross is referri= ng >>>> to >>> >>>> the potential Cloud Operation group (as the result of Cloud bar BOF). >>> >>>> >>> >>>> >>> >>>> >>> >>>> =A0Actually, I initially did present the ARP issue at the Cloud bar BO= F at >>>> the >>> >>>> 78th IETF. But I learned that the audience for Cloud is too diverse to >>> >>>> converge on network problems. The problems which Cloud bar BOF has >>>> presented >>> >>>> cover Applications APIs, Logging, Security, etc. They are not even on >>> >>>> network problems. >>> >>>> >>> >>>> I am afraid of mixing network problems with application problems will > just >>> >>>> get many people more confused. I remember during 78th IETF Cloud Bar > BOF, >>> >>>> the people who focus on Application APIs think network problem is too >>> >>>> trivial to be even discussed at the same place with cloud applications >>> >>>> problems. >>> >>>> >>> >>>> >>> >>>> >>> >>>> Question: Should we go towards this direction? >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> What other refinement we need to consider? >>> >>>> >>> >>>> >>> >>>> >>> >>>> Thanks, Linda Dunbar >>> >>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> armd mailing list >>> >>>> armd@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/armd >>> >>>> >>> >>>> >> > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > From ldunbar@huawei.com Tue Nov 30 15:33:16 2010 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A983A6C70 for ; Tue, 30 Nov 2010 15:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.483 X-Spam-Level: X-Spam-Status: No, score=-105.483 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcYW9CvZbEB5 for ; Tue, 30 Nov 2010 15:33:05 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 634F53A6C8E for ; Tue, 30 Nov 2010 15:33:05 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCQ00I061H45P@usaga04-in.huawei.com> for armd@ietf.org; Tue, 30 Nov 2010 17:34:17 -0600 (CST) Received: from L735042 ([10.124.12.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCQ00D2B1H149@usaga04-in.huawei.com> for armd@ietf.org; Tue, 30 Nov 2010 17:34:16 -0600 (CST) Date: Tue, 30 Nov 2010 17:34:13 -0600 From: Linda Dunbar In-reply-to: To: adrian@olddog.co.uk, armd@ietf.org Message-id: <00f601cb90e7$19294010$6c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_8BwM6D6KeXatwPtY8jKxVw)" Thread-index: AQDWFxtyC9s+fQZHnPtRs1kFXSPnJwKNn/pNlUvr6lCAAEEnwIAU/kpQ References: <007301cb85d4$4bd28580$6c0c7c0a@china.huawei.com> <14584D6EE26B314187A4F68BA206060005C3DA75@ASHEVS008.mcilink.com> <03c601cb8643$d94fd650$8bef82f0$@olddog.co.uk> Cc: 'Jari Arkko' , 'Ralph Droms' Subject: [armd] Need to reach concensus on ARMD problem domain X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 23:33:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_8BwM6D6KeXatwPtY8jKxVw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT During afterwards discussion on how to move ARMD forward, we were pointed out that there are two different areas being addressed by ARMD problem statements: One is the general ARP problem associated with massive number of hosts * The massive number of client subnets in Data Center will cause similar problems to networks in data center with virtualized servers. Another one is ARP can actually be used as solution to quickly update intermediate switches' FDB when hosts (VMs) migrate from one location to another. * (our original thought is about there will be more ARPs when VMs migrate. The bullet listed in the ARMD Problem Statement is to justify urgency to enhance ARP). We'd like to hear people's opinion on if ARMD problem domain should include only the first one or both (i.e. ARP needing extension to be used in data center with large number of hosts and ARP as solution for Layer 2 switches quick convergence)? Your input is appreciated. Linda Dunbar _____ From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Ross Callon Sent: Wednesday, November 17, 2010 8:41 AM To: adrian@olddog.co.uk; 'So, Ning'; 'Linda Dunbar'; armd@ietf.org Cc: Ronald Bonica; 'Jari Arkko'; 'Claudio DeSanti' Subject: Re: [armd] ARMD BOF follow up I have CC'd Ron Bonica on this, as he is the operations AD. My understanding of the results of the BOF is that there is clearly a problem to be solved, an urgency to begin work, and several possible solutions. There is also a need to clearly document what the problem is, the requirements for a solution, and the range of possible solutions. This is work that could be done in a data center operations working group. It is possible that some potential solutions may involve care of how existing protocols are deployed (an operational issue). It is possible that some potential solutions may involve extensions or changes to existing IETF protocols. I am not an AD (and no longer play one on TV or anywhere else). My understanding is that these extensions to existing IETF protocols would need to be done in other IETF WGs - presumably the ones responsible for whatever protocol is being extended. However, it will be much easier to charter this work once there is agreement on an initial draft documenting what the problem is and requirements of a solution. Ross From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, November 17, 2010 5:40 AM To: 'So, Ning'; 'Linda Dunbar'; armd@ietf.org Cc: Ross Callon; 'Jari Arkko'; 'Claudio DeSanti' Subject: RE: [armd] ARMD BOF follow up Hi, I don't believe Ops Area WGs are allowed to do protocol extensions (except for management protocols), so option 2 is not an option if the ARMD work requires protocol changes. OTOH, if the ARMD work collapses to how to operate ARP in a specific environment, then this would be clear for Ops. Adrian From: So, Ning [mailto:ning.so@verizonbusiness.com] Sent: 16 November 2010 21:33 To: Linda Dunbar; armd@ietf.org Cc: rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; Claudio DeSanti Subject: RE: [armd] ARMD BOF follow up Linda, I concur with your concern on your suggestion #2. Cloud Data Center WG (name will likely change) and Cloud AppsBoF were both being proposed during the meeting last week. One potential solution is to have network related ARMD drafts go to the new WG, while non-network related SRMD drafts go to the new Cloud AppsBoF. Best regrads, Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 _____ From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, November 16, 2010 3:22 PM To: armd@ietf.org Cc: rcallon@juniper.net; adrian@olddog.co.uk; 'Jari Arkko'; 'Claudio DeSanti' Subject: [armd] ARMD BOF follow up Thanks to everyone who participated in the ARMD BOF discussion last Friday. There were two major comments we heard from the audience. One comment is wishing to see some statistics (by Internet AD Ralph), and another comment is suggesting that we should go to "Data Center Operation" working group to discuss with other "data center operation issues". Suggestion 1: Need ARP statistics: At the BOF, I forgot to mention that ARP statistics was quoted in our first problem statement draft for ARP222 (back when it was only at the bar BOF stage). As time goes on, we modified the draft several times by several authors to include more important stuff, those numbers get eliminated from the draft. The study done by CMU shows (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf): the number of ARP queries received at a workstation on CMU's School of Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the host received 1150 ARPs per second, and on average, the host received 89 ARPs per second, which corresponds to 45 kbps of traffic. During the data collection, 2,456 hosts were observed sending ARP queries. CMU expected that the amount of ARP traffic will scale linearly with the number of hosts on the LAN. For 1 million hosts, they would expect 468,240 ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, which is more than enough to overwhelm a standard 100 Mbps LAN connection. Ignoring the link capacity, forcing hosts to handle an extra half million packets per second to inspect each ARP packet would impose a prohibitive computational burden. As Cisco's Claudio DeSanti pointed out during the BOF, large number of client subnets is effectively causing network to have the same problem as one large broadcast domain. Question: What other statistics do people would like to see before being convinced that ARP optimization is indeed necessary to make network scale to support next gen mega data center? Suggestion 2: To lump the ARP improvement discussion with Data Center Operation working group (by Ross Callon) Chatting with Ross Callon after the BOF, I learnt that Ross is referring to the potential Cloud Operation group (as the result of Cloud bar BOF). Actually, I initially did present the ARP issue at the Cloud bar BOF at the 78th IETF. But I learned that the audience for Cloud is too diverse to converge on network problems. The problems which Cloud bar BOF has presented cover Applications APIs, Logging, Security, etc. They are not even on network problems. I am afraid of mixing network problems with application problems will just get many people more confused. I remember during 78th IETF Cloud Bar BOF, the people who focus on Application APIs think network problem is too trivial to be even discussed at the same place with cloud applications problems. Question: Should we go towards this direction? What other refinement we need to consider? Thanks, Linda Dunbar --Boundary_(ID_8BwM6D6KeXatwPtY8jKxVw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

During afterwards discussion on how to move ARMD forward, we were pointed out that there are two different areas being addressed by ARMD problem statements:

 

One is the general ARP problem associated with massive number of hosts

    • The massive number of client subnets in Data Center will cause similar problems to networks in data center with virtualized servers.

Another one is ARP can actually be used as solution to quickly update intermediate switches’ FDB when hosts (VMs) migrate from one location to another.

    • (our original thought is about there will be more ARPs when VMs migrate. The bullet listed in the ARMD Problem Statement is to justify urgency to enhance ARP).

 

We’d like to hear people’s opinion on if ARMD problem domain should include only the first one or both (i.e. ARP needing extension to be used in data center with large number of hosts and ARP as solution for Layer 2 switches quick convergence)?

 

Your input is appreciated.

 

Linda Dunbar

 

 


From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Wednesday, November 17, 2010 8:41 AM
To: adrian@olddog.co.uk; 'So, Ning'; 'Linda Dunbar'; armd@ietf.org
Cc: Ronald Bonica; 'Jari Arkko'; 'Claudio DeSanti'
Subject: Re: [armd] ARMD BOF follow up

 

I have CC’d Ron Bonica on this, as he is the operations AD.

 

My understanding of the results of the BOF is that there is clearly a problem to be solved, an urgency to begin work, and several possible solutions. 

 

There is also a need to clearly document what the problem is, the requirements for a solution, and the range of possible solutions. This is work that could be done in a data center operations working group.

 

It is possible that some potential solutions may involve care of how existing protocols are deployed (an operational issue).

 

It is possible that some potential solutions may involve extensions or changes to existing IETF protocols. I am not an AD (and no longer play one on TV or anywhere else). My understanding is that these extensions to existing IETF protocols would need to be done in other IETF WGs – presumably the ones responsible for whatever protocol is being extended. However, it will be much easier to charter this work once there is agreement on an initial draft documenting what the problem is and requirements of a solution.

 

Ross

 

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, November 17, 2010 5:40 AM
To: 'So, Ning'; 'Linda Dunbar'; armd@ietf.org
Cc: Ross Callon; 'Jari Arkko'; 'Claudio DeSanti'
Subject: RE: [armd] ARMD BOF follow up

 

Hi,

 

I don't believe Ops Area WGs are allowed to do protocol extensions (except for management protocols), so option 2 is not an option if the ARMD work requires protocol changes.

 

OTOH, if the ARMD work collapses to how to operate ARP in a specific environment, then this would be clear for Ops.

 

Adrian

 

From: So, Ning [mailto:ning.so@verizonbusiness.com]
Sent: 16 November 2010 21:33
To: Linda Dunbar; armd@ietf.org
Cc: rcallon@juniper.net; adrian@olddog.co.uk; Jari Arkko; Claudio DeSanti
Subject: RE: [armd] ARMD BOF follow up

 

Linda,

 

I concur with your concern on your suggestion #2.  Cloud Data Center WG (name will likely change) and Cloud AppsBoF were both being proposed during the meeting last week.  One potential solution is to have network related ARMD drafts go to the new WG, while non-network related SRMD drafts go to the new Cloud AppsBoF.  

 

 

Best regrads,

 

Ning So

Network Evolution Planning

Verizon, Inc.

(office) 972-729-7905

(Cell) 972-955-0914

 


From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Tuesday, November 16, 2010 3:22 PM
To: armd@ietf.org
Cc: rcallon@juniper.net; adrian@olddog.co.uk; 'Jari Arkko'; 'Claudio DeSanti'
Subject: [armd] ARMD BOF follow up

 

Thanks to everyone who participated in the ARMD BOF discussion last Friday. There were two major comments we heard from the audience. One comment is wishing to see some statistics (by Internet AD Ralph), and another comment is suggesting that we should go to “Data Center Operation” working group to discuss with other “data center operation issues”.

 

Suggestion 1: Need ARP statistics:

At the BOF, I forgot to mention that ARP statistics was quoted in our first problem statement draft for ARP222 (back when it was only at the bar BOF stage).  As time goes on, we modified the draft several times by several authors to include more important stuff, those numbers get eliminated from the draft.

 

The study done by CMU shows (http://www.cs.cmu.edu/~hzhang/papers/hotnets04-ethernet.pdf):

 

the number of ARP queries received at a workstation on CMU’s School of Computer Science LAN over a 12 hour period on August 9, 2004. At peak, the host received 1150 ARPs per second, and on average, the host received 89 ARPs per second, which corresponds to 45 kbps of traffic. During the data collection, 2,456 hosts were observed sending ARP queries.

 

CMU expected that the amount of ARP traffic will scale linearly with the number of hosts on the LAN. For 1 million hosts, they would expect 468,240 ARPs per second or 239 Mbps of ARP traffic to arrive at each host at peak, which is more than enough to overwhelm a standard 100 Mbps LAN connection. Ignoring the link capacity, forcing hosts to handle an extra half million packets per second to inspect each ARP packet would impose a prohibitive computational burden.

 

 

As Cisco’s Claudio DeSanti pointed out during the BOF, large number of client subnets is effectively causing network to have the same problem as one large broadcast domain.

 

Question: What other statistics do people would like to see before being convinced that ARP optimization is indeed necessary to make network scale to support next gen mega data center?

 

Suggestion 2: To lump the ARP improvement discussion with Data Center Operation working group (by Ross Callon)

Chatting with Ross Callon after the BOF, I learnt that Ross is referring to the potential Cloud Operation group (as the result of Cloud bar BOF).

 

 Actually, I initially did present the ARP issue at the Cloud bar BOF at the 78th IETF. But I learned that the audience for Cloud is too diverse to converge on network problems. The problems which Cloud bar BOF has presented cover Applications APIs, Logging, Security, etc. They are not even on network problems.

I am afraid of mixing network problems with application problems will just get many people more confused. I remember during 78th IETF Cloud Bar BOF, the people who focus on Application APIs think network problem is too trivial to be even discussed at the same place with cloud applications problems.

 

Question: Should we go towards this direction?

 

 

What other refinement we need to consider?

 

Thanks, Linda Dunbar

 

--Boundary_(ID_8BwM6D6KeXatwPtY8jKxVw)--