From jari.arkko@piuha.net Thu Jan 13 14:50:26 2011 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 39B1A3A6452 for ; Thu, 13 Jan 2011 14:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 l1Kn7dzcyTmq for ; Thu, 13 Jan 2011 14:50:25 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id DC86A3A6BED for ; Thu, 13 Jan 2011 14:50:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A56062CC31 for ; Fri, 14 Jan 2011 00:52:47 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJNUL7xpk8KD for ; Fri, 14 Jan 2011 00:52:47 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2C70C2CC2D for ; Fri, 14 Jan 2011 00:52:47 +0200 (EET) Message-ID: <4D2F823E.30804@piuha.net> Date: Fri, 14 Jan 2011 00:52:46 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: armd@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [armd] thoughts on the continuation of the ARMD work X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:50:26 -0000 It is time to decide what to do with another BOF or some other continuation of this work. I'm not the AD responsible for this work (Ralph is) but I thought it might be useful to provide some possible ideas that might work. One approach is to run a second BOF, and attempt to come to a conclusion that we have or do not have a scaling problem in ARP. If we do have a scaling problem then we can charter a working group that works on a solution. Linda and Sue tell me that they are working on experiments that may help us understand the scaling problems better, so there may be some material ready from this to the BOF. Another approach is to just charter a working group that documents scaling characteristics of ARP and ND, and perhaps also provides some operational advice on how to best run your networks without running into issues. This working group would run, say, for six months and would come up with a couple of RFCs. At that point it would we could perhaps recharter the group for some protocol work, if the RFCs showed that there are severe issues. In either case we need to work on what the scaling characteristics of ARP and ND are. The difference is that in the BOF approach we need to focus on finding the "smoking gun" and have a yes-no type discussion. In the WG approach we can take a bit more time, do an in-depth analysis, can document the results neutrally without pressure to find the gun, and may even provide some useful advice to network managers in the process. Jari From guyingjie@huawei.com Thu Jan 13 15:36:08 2011 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 D3F8F3A6C13 for ; Thu, 13 Jan 2011 15:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 J+UyZ6qZSt6I for ; Thu, 13 Jan 2011 15:36:07 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B82463A6872 for ; Thu, 13 Jan 2011 15:36:07 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ00IO5J04SK@szxga04-in.huawei.com> for armd@ietf.org; Fri, 14 Jan 2011 07:38:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ00DZDJ04DL@szxga04-in.huawei.com> for armd@ietf.org; Fri, 14 Jan 2011 07:38:28 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [64.75.138.103]) by szxmc04-in.huawei.com (mshttpd); Fri, 14 Jan 2011 07:38:28 +0800 Date: Fri, 14 Jan 2011 07:38:28 +0800 From: guyingjie 00107907 In-reply-to: <4D2F823E.30804@piuha.net> To: Jari Arkko 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=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <4D2F823E.30804@piuha.net> Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:36:08 -0000 Well, personally I would support approach 2. We may first output some Informal RFCs, and if necessary, we can recharter the WG. Best Regards Y.J. GU ----- Original mail ----- > It is time to decide what to do with another BOF or some other > continuation of this work. > > I'm not the AD responsible for this work (Ralph is) but I thought it > might be useful to provide some possible ideas that might work. > > One approach is to run a second BOF, and attempt to come to a > conclusionthat we have or do not have a scaling problem in ARP. If > we do have a > scaling problem then we can charter a working group that works on a > solution. Linda and Sue tell me that they are working on experiments > that may help us understand the scaling problems better, so there > may be > some material ready from this to the BOF. > > Another approach is to just charter a working group that documents > scaling characteristics of ARP and ND, and perhaps also provides some > operational advice on how to best run your networks without > running into > issues. This working group would run, say, for six months and > would come > up with a couple of RFCs. At that point it would we could perhaps > recharter the group for some protocol work, if the RFCs showed that > there are severe issues. > > In either case we need to work on what the scaling characteristics of > ARP and ND are. The difference is that in the BOF approach we need to > focus on finding the "smoking gun" and have a yes-no type > discussion. In > the WG approach we can take a bit more time, do an in-depth analysis, > can document the results neutrally without pressure to find the > gun, and > may even provide some useful advice to network managers in the > process. > Jari > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > From robert.sultan@huawei.com Thu Jan 13 15:43:22 2011 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 BE8863A6C27 for ; Thu, 13 Jan 2011 15:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDpeypVsXv+2 for ; Thu, 13 Jan 2011 15:43:21 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 8962B3A6C24 for ; Thu, 13 Jan 2011 15:43:21 -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 <0LEZ00HA6JC8AB@usaga04-in.huawei.com> for armd@ietf.org; Thu, 13 Jan 2011 17:45:45 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LEZ00176JC7WX@usaga04-in.huawei.com> for armd@ietf.org; Thu, 13 Jan 2011 17:45:44 -0600 (CST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 13 Jan 2011 15:45:37 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0218.012; Thu, 13 Jan 2011 15:45:43 -0800 Date: Thu, 13 Jan 2011 23:45:43 +0000 From: robert sultan In-reply-to: <4D2F823E.30804@piuha.net> X-Originating-IP: [172.18.9.109] To: "armd@ietf.org" Message-id: <6F65960726BEFB4EB40F2ED6E1B22B4EFDC9B9@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [armd] thoughts on the continuation of the ARMD work Thread-index: AQHLs3TVVgZu2N1bfkW9Lqmfiuq3mJPPj/O1 X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4D2F823E.30804@piuha.net> X-Mailman-Approved-At: Fri, 14 Jan 2011 08:12:50 -0800 Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 14 Jan 2011 02:11:13 -0000 I agree with Jari's second suggestion, to charter a group to document and analyze ARP and ND performance in networks of various size. ...Bob ________________________________________ From: armd-bounces@ietf.org [armd-bounces@ietf.org] on behalf of Jari Arkko [jari.arkko@piuha.net] Sent: Thursday, January 13, 2011 2:52 PM To: armd@ietf.org Subject: [armd] thoughts on the continuation of the ARMD work It is time to decide what to do with another BOF or some other continuation of this work. I'm not the AD responsible for this work (Ralph is) but I thought it might be useful to provide some possible ideas that might work. One approach is to run a second BOF, and attempt to come to a conclusion that we have or do not have a scaling problem in ARP. If we do have a scaling problem then we can charter a working group that works on a solution. Linda and Sue tell me that they are working on experiments that may help us understand the scaling problems better, so there may be some material ready from this to the BOF. Another approach is to just charter a working group that documents scaling characteristics of ARP and ND, and perhaps also provides some operational advice on how to best run your networks without running into issues. This working group would run, say, for six months and would come up with a couple of RFCs. At that point it would we could perhaps recharter the group for some protocol work, if the RFCs showed that there are severe issues. In either case we need to work on what the scaling characteristics of ARP and ND are. The difference is that in the BOF approach we need to focus on finding the "smoking gun" and have a yes-no type discussion. In the WG approach we can take a bit more time, do an in-depth analysis, can document the results neutrally without pressure to find the gun, and may even provide some useful advice to network managers in the process. Jari _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From prvs=4999ea92e6=hshah@ciena.com Tue Jan 18 13:55:02 2011 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 839B63A6F59 for ; Tue, 18 Jan 2011 13:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q07EyzJlA3bj for ; Tue, 18 Jan 2011 13:55:01 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by core3.amsl.com (Postfix) with ESMTP id 5DA443A6F57 for ; Tue, 18 Jan 2011 13:55:01 -0800 (PST) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p0ILvA5J022011 for ; Tue, 18 Jan 2011 16:57:39 -0500 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id twh8jrfr9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Jan 2011 16:57:39 -0500 Received: from mdmxm05.ciena.com (63.118.39.23) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server id 8.1.436.0; Tue, 18 Jan 2011 16:57:38 -0500 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_01CBB75A.B8DACB6B" Date: Tue, 18 Jan 2011 16:57:37 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [armd] thoughts on the continuation of the ARMD work Thread-Index: Acu3Wrf5qtn9jL4DR6+S7h8l8Vey7w== From: "Shah, Himanshu" To: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-18_07:2011-01-18, 2011-01-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=7 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1101180177 Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 18 Jan 2011 21:55:02 -0000 ------_=_NextPart_001_01CBB75A.B8DACB6B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It appears that we are unnecessarily setting the bar=20 higher for this work to continue. =20 I believe there was adequate problem scope and data presented during the last BoFs. We seem to put more emphasis on peripheral, off-the-cuff opinions and warrant more research, more data.. =20 We need to get out of this BoF-forever-mode (or go-fetch-more-rocks cycle),=20 and start a WG to address the problem. To that extent, I agree with your suggestion about continuing the work in a WG, even if that meant to be in a problem-study mode initially. =20 /himanshu =20 =20 =20 =20 -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Thursday, January 13, 2011 4:53 PM To: armd@ietf.org Subject: [armd] thoughts on the continuation of the ARMD work =20 It is time to decide what to do with another BOF or some other continuation of this work. =20 I'm not the AD responsible for this work (Ralph is) but I thought it might be useful to provide some possible ideas that might work. =20 One approach is to run a second BOF, and attempt to come to a conclusion that we have or do not have a scaling problem in ARP. If we do have a scaling problem then we can charter a working group that works on a solution. Linda and Sue tell me that they are working on experiments that may help us understand the scaling problems better, so there may be some material ready from this to the BOF. =20 Another approach is to just charter a working group that documents scaling characteristics of ARP and ND, and perhaps also provides some operational advice on how to best run your networks without running into issues. This working group would run, say, for six months and would come up with a couple of RFCs. At that point it would we could perhaps recharter the group for some protocol work, if the RFCs showed that there are severe issues. =20 In either case we need to work on what the scaling characteristics of ARP and ND are. The difference is that in the BOF approach we need to focus on finding the "smoking gun" and have a yes-no type discussion. In the WG approach we can take a bit more time, do an in-depth analysis, can document the results neutrally without pressure to find the gun, and may even provide some useful advice to network managers in the process. =20 Jari =20 ------_=_NextPart_001_01CBB75A.B8DACB6B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It = appears that we are unnecessarily setting the bar

higher for this work to continue.

 

I = believe there was adequate problem scope and data = presented

during the last BoFs. We = seem to put more emphasis on peripheral,

off-the-cuff opinions and warrant more research, = more data..

 

We = need to get out of this BoF-forever-mode (or go-fetch-more-rocks cycle), =

and start a WG to address the = problem. To that extent, I agree with

your suggestion about continuing the work in a WG, = even if that meant

to be in a = problem-study mode initially.

 

/himanshu  

 

 

 

-----Original Message-----

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

Sent: Thursday, January 13, 2011 4:53 = PM

To: armd@ietf.org

Subject: [armd] thoughts on the continuation of the = ARMD work

 

It is time to decide what to do with another BOF or = some other continuation of this work.

 

I'm = not the AD responsible for this work (Ralph is) but I thought it might = be useful to provide some possible ideas that might = work.

 

One approach is to run a second BOF, and attempt to = come to a conclusion that we have or do not have a scaling problem in = ARP. If we do have a scaling problem then we can charter a working group = that works on a solution. Linda and Sue tell me that they are working on = experiments that may help us understand the scaling problems better, so = there may be some material ready from this to the BOF.

 

Another approach is to just charter a working group = that documents scaling characteristics of ARP and ND, and perhaps also = provides some operational advice on how to best run your networks = without running into issues. This working group would run, say, for six = months and would come up with a couple of RFCs. At that point it would = we could perhaps recharter the group for some protocol work, if the RFCs = showed that there are severe issues.

 

In = either case we need to work on what the scaling characteristics of ARP = and ND are. The difference is that in the BOF approach we need to focus = on finding the "smoking gun" and have a yes-no type = discussion. In the WG approach we can take a bit more time, do an = in-depth analysis, can document the results neutrally without pressure = to find the gun, and may even provide some useful advice to network = managers in the process.

 

Jari

 

------_=_NextPart_001_01CBB75A.B8DACB6B-- From muraris@microsoft.com Tue Jan 18 15:36:07 2011 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 9459028C163 for ; Tue, 18 Jan 2011 15:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 XI0nM6PfW981 for ; Tue, 18 Jan 2011 15:36:06 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 8E50828C15C for ; Tue, 18 Jan 2011 15:36:06 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 18 Jan 2011 15:38:45 -0800 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.221]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0255.003; Tue, 18 Jan 2011 15:38:44 -0800 From: Murari Sridharan To: Jari Arkko , "armd@ietf.org" Thread-Topic: [armd] thoughts on the continuation of the ARMD work Thread-Index: AQHLs3Skw7hBwO+9fE2cKC+ljVywhJPXaZ5g Date: Tue, 18 Jan 2011 23:38:44 +0000 Message-ID: References: <4D2F823E.30804@piuha.net> In-Reply-To: <4D2F823E.30804@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 18 Jan 2011 23:36:07 -0000 I like the second approach and support the formation of a WG to study the s= caling characteristics. Understanding this is essential.=20 Thanks -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Jar= i Arkko Sent: Thursday, January 13, 2011 2:53 PM To: armd@ietf.org Subject: [armd] thoughts on the continuation of the ARMD work It is time to decide what to do with another BOF or some other continuation= of this work. I'm not the AD responsible for this work (Ralph is) but I thought it might = be useful to provide some possible ideas that might work. One approach is to run a second BOF, and attempt to come to a conclusion th= at we have or do not have a scaling problem in ARP. If we do have a scaling= problem then we can charter a working group that works on a solution. Lind= a and Sue tell me that they are working on experiments that may help us und= erstand the scaling problems better, so there may be some material ready fr= om this to the BOF. Another approach is to just charter a working group that documents scaling = characteristics of ARP and ND, and perhaps also provides some operational a= dvice on how to best run your networks without running into issues. This wo= rking group would run, say, for six months and would come up with a couple = of RFCs. At that point it would we could perhaps recharter the group for so= me protocol work, if the RFCs showed that there are severe issues. In either case we need to work on what the scaling characteristics of ARP a= nd ND are. The difference is that in the BOF approach we need to focus on f= inding the "smoking gun" and have a yes-no type discussion. In the WG appro= ach we can take a bit more time, do an in-depth analysis, can document the = results neutrally without pressure to find the gun, and may even provide so= me useful advice to network managers in the process. Jari _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From d3e3e3@gmail.com Tue Jan 18 19:18:38 2011 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 02B0228C0D0 for ; Tue, 18 Jan 2011 19:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ZXSwvUaOloYD for ; Tue, 18 Jan 2011 19:18:33 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9E44C28C0E1 for ; Tue, 18 Jan 2011 19:18:33 -0800 (PST) Received: by wyf23 with SMTP id 23so407218wyf.31 for ; Tue, 18 Jan 2011 19:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=SHQsET2sfwugkXmD4x4Ud9Ro61dQNsSa+x2ALvV1k5g=; b=pSEqCDP8satPEMTyrOx2CWwgSn5Hs3cE3LqsvtTP3Oedrhacgi+jGCGig7VmyZSVc6 CYsA5slm50bA4cJ558GX6/C/TV+vbKWHq8JkeShbl8yfY5Ip3KasaqRt62j04ZO/EDwT UFDK9KUAhPblm8snxn2F5l+1NMn1oa13N+IGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=G+45M4z6INoFvdVEl2Mm8vdEH5m6Zcgm5GylwCjTc8EdQRSumjSlPNJlq7KWMlB3v9 morUfqy31crP/pXF+SpGjz1MA+Oi2UGgA0gMrJGwPsUR6orYrHZnBtsDXR0JKoC5jFGs wKiYiE6MvCU1zwvPOWZHB1+rhLiudRyyeOGtQ= Received: by 10.227.141.138 with SMTP id m10mr146260wbu.66.1295407271007; Tue, 18 Jan 2011 19:21:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.61.81 with HTTP; Tue, 18 Jan 2011 19:20:50 -0800 (PST) In-Reply-To: References: <4D2F823E.30804@piuha.net> From: Donald Eastlake Date: Tue, 18 Jan 2011 22:20:50 -0500 Message-ID: To: "armd@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 19 Jan 2011 03:18:38 -0000 The second approach, to charter a working group that documents scaling characteristics of ARP and ND, and perhaps also provides some operational advice, seems like a reasonable course to me. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, Jan 18, 2011 at 6:38 PM, Murari Sridharan w= rote: > I like the second approach and support the formation of a WG to study the= scaling characteristics. Understanding this is essential. > > Thanks > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of J= ari Arkko > Sent: Thursday, January 13, 2011 2:53 PM > To: armd@ietf.org > Subject: [armd] thoughts on the continuation of the ARMD work > > It is time to decide what to do with another BOF or some other continuati= on of this work. > > I'm not the AD responsible for this work (Ralph is) but I thought it migh= t be useful to provide some possible ideas that might work. > > One approach is to run a second BOF, and attempt to come to a conclusion = that we have or do not have a scaling problem in ARP. If we do have a scali= ng problem then we can charter a working group that works on a solution. Li= nda and Sue tell me that they are working on experiments that may help us u= nderstand the scaling problems better, so there may be some material ready = from this to the BOF. > > Another approach is to just charter a working group that documents scalin= g characteristics of ARP and ND, and perhaps also provides some operational= advice on how to best run your networks without running into issues. This = working group would run, say, for six months and would come up with a coupl= e of RFCs. At that point it would we could perhaps recharter the group for = some protocol work, if the RFCs showed that there are severe issues. > > In either case we need to work on what the scaling characteristics of ARP= and ND are. The difference is that in the BOF approach we need to focus on= finding the "smoking gun" and have a yes-no type discussion. In the WG app= roach we can take a bit more time, do an in-depth analysis, can document th= e results neutrally without pressure to find the gun, and may even provide = some useful advice to network managers in the process. > > Jari > > > _______________________________________________ > 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 rcallon@juniper.net Tue Jan 18 19:29:19 2011 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 22E4628C0FD for ; Tue, 18 Jan 2011 19:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.659 X-Spam-Level: X-Spam-Status: No, score=-106.659 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 1pBv4Yvl-pr8 for ; Tue, 18 Jan 2011 19:29:18 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id B8A0828C0D0 for ; Tue, 18 Jan 2011 19:29:16 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTTZbK6YGxJxx6ajSAF2zDpKS+DmbEUYM@postini.com; Tue, 18 Jan 2011 19:31:57 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 18 Jan 2011 19:31:28 -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; Tue, 18 Jan 2011 22:31:27 -0500 From: Ross Callon To: Donald Eastlake , "armd@ietf.org" Date: Tue, 18 Jan 2011 22:31:26 -0500 Thread-Topic: [armd] thoughts on the continuation of the ARMD work Thread-Index: Acu3h/GGn2CZgzjhT027+NLwKfEcLQAAJATw Message-ID: References: <4D2F823E.30804@piuha.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 19 Jan 2011 03:29:19 -0000 How big a task do we think that this will be?=20 (I am asking this with the understanding that there is a very wide range of= "amount of work" implied by a WG charter).=20 Ross -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Don= ald Eastlake Sent: Tuesday, January 18, 2011 10:21 PM To: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work The second approach, to charter a working group that documents scaling characteristics of ARP and ND, and perhaps also provides some operational advice, seems like a reasonable course to me. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, Jan 18, 2011 at 6:38 PM, Murari Sridharan w= rote: > I like the second approach and support the formation of a WG to study the= scaling characteristics. Understanding this is essential. > > Thanks > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of J= ari Arkko > Sent: Thursday, January 13, 2011 2:53 PM > To: armd@ietf.org > Subject: [armd] thoughts on the continuation of the ARMD work > > It is time to decide what to do with another BOF or some other continuati= on of this work. > > I'm not the AD responsible for this work (Ralph is) but I thought it migh= t be useful to provide some possible ideas that might work. > > One approach is to run a second BOF, and attempt to come to a conclusion = that we have or do not have a scaling problem in ARP. If we do have a scali= ng problem then we can charter a working group that works on a solution. Li= nda and Sue tell me that they are working on experiments that may help us u= nderstand the scaling problems better, so there may be some material ready = from this to the BOF. > > Another approach is to just charter a working group that documents scalin= g characteristics of ARP and ND, and perhaps also provides some operational= advice on how to best run your networks without running into issues. This = working group would run, say, for six months and would come up with a coupl= e of RFCs. At that point it would we could perhaps recharter the group for = some protocol work, if the RFCs showed that there are severe issues. > > In either case we need to work on what the scaling characteristics of ARP= and ND are. The difference is that in the BOF approach we need to focus on= finding the "smoking gun" and have a yes-no type discussion. In the WG app= roach we can take a bit more time, do an in-depth analysis, can document th= e results neutrally without pressure to find the gun, and may even provide = some useful advice to network managers in the process. > > Jari > > > _______________________________________________ > 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 > _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From ning.so@verizonbusiness.com Wed Jan 19 06:35:18 2011 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 C45B13A7143 for ; Wed, 19 Jan 2011 06:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 Yq465aXgif-W for ; Wed, 19 Jan 2011 06:35:17 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id CA05C3A7141 for ; Wed, 19 Jan 2011 06:35:17 -0800 (PST) Received: from pdcismtp01.vzbi.com ([unknown] [166.40.77.67]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LF9009LRXUS1C80@firewall.verizonbusiness.com> for armd@ietf.org; Wed, 19 Jan 2011 14:35:16 +0000 (GMT) Received: from pdcismtp01.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LF9000ESXUSIG00@pdcismtp01.vzbi.com> for armd@ietf.org; Wed, 19 Jan 2011 14:35:16 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([unknown] [153.39.68.167]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LF9000FZXUR5K00@pdcismtp01.vzbi.com> for armd@ietf.org; Wed, 19 Jan 2011 14:35:16 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 14:35:15 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Date: Wed, 19 Jan 2011 14:35:13 +0000 Message-id: <14584D6EE26B314187A4F68BA2060600064CBF3E@ASHEVS008.mcilink.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [armd] thoughts on the continuation of the ARMD work Thread-index: AQHLs3Skw7hBwO+9fE2cKC+ljVywhJPXaZ5ggAD6LiA= References: <4D2F823E.30804@piuha.net> From: "So, Ning" To: armd@ietf.org X-OriginalArrivalTime: 19 Jan 2011 14:35:15.0771 (UTC) FILETIME=[167AF8B0:01CBB7E6] Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 19 Jan 2011 14:35:18 -0000 The data centers, especially the new ones that are being built to host the next generation "Cloud-based" services, are getting to be VERY big in anticipation of the forecasted service offerings. Scalability and the utilization efficiency (mobility) are certainly major concerns for the service providers. Proposed ARMD charter seems to cover those areas well, from my opinion. I support the formulation of the WG to start tackling the problems officially.=20 =20 Best regrads, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Thursday, January 13, 2011 2:53 PM To: armd@ietf.org Subject: [armd] thoughts on the continuation of the ARMD work It is time to decide what to do with another BOF or some other continuation of this work. I'm not the AD responsible for this work (Ralph is) but I thought it might be useful to provide some possible ideas that might work. One approach is to run a second BOF, and attempt to come to a conclusion that we have or do not have a scaling problem in ARP. If we do have a scaling problem then we can charter a working group that works on a solution. Linda and Sue tell me that they are working on experiments that may help us understand the scaling problems better, so there may be some material ready from this to the BOF. Another approach is to just charter a working group that documents scaling characteristics of ARP and ND, and perhaps also provides some operational advice on how to best run your networks without running into issues. This working group would run, say, for six months and would come up with a couple of RFCs. At that point it would we could perhaps recharter the group for some protocol work, if the RFCs showed that there are severe issues. In either case we need to work on what the scaling characteristics of ARP and ND are. The difference is that in the BOF approach we need to focus on finding the "smoking gun" and have a yes-no type discussion. In the WG approach we can take a bit more time, do an in-depth analysis, can document the results neutrally without pressure to find the gun, and may even provide some useful advice to network managers in the process. Jari _______________________________________________ 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 Wed Jan 19 07:50:27 2011 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 9FA7B3A6FEF for ; Wed, 19 Jan 2011 07:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 rZueDgUzDqYr for ; Wed, 19 Jan 2011 07:50:26 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 9C2EB3A7011 for ; Wed, 19 Jan 2011 07:50:26 -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 <0LFA00CW61GII3@usaga04-in.huawei.com> for armd@ietf.org; Wed, 19 Jan 2011 09:53:06 -0600 (CST) Received: from L735042 ([10.124.12.99]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFA00EY91GG1L@usaga04-in.huawei.com> for armd@ietf.org; Wed, 19 Jan 2011 09:53:06 -0600 (CST) Date: Wed, 19 Jan 2011 09:53:05 -0600 From: Linda Dunbar In-reply-to: To: 'Ross Callon' , 'Donald Eastlake' , armd@ietf.org Message-id: <006501cbb7f0$f65c28a0$0c00a8c0@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: Acu3h/GGn2CZgzjhT027+NLwKfEcLQAAJATwABoAu8A= References: <4D2F823E.30804@piuha.net> Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 19 Jan 2011 15:50:27 -0000 Ross,=20 I will revise the Charter statement, scope of work and deliverables = based on the emails posted. We can then evaluate the amount of work. I anticipate that it will be in several phases: Phase 1 being documenting the = problems and issues, Phase 2 being on solutions, ... Linda=20 -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of = Ross Callon Sent: Tuesday, January 18, 2011 9:31 PM To: Donald Eastlake; armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work How big a task do we think that this will be?=20 (I am asking this with the understanding that there is a very wide range = of "amount of work" implied by a WG charter).=20 Ross -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Donald Eastlake Sent: Tuesday, January 18, 2011 10:21 PM To: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work The second approach, to charter a working group that documents scaling characteristics of ARP and ND, and perhaps also provides some operational advice, seems like a reasonable course to me. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, Jan 18, 2011 at 6:38 PM, Murari Sridharan = wrote: > I like the second approach and support the formation of a WG to study = the scaling characteristics. Understanding this is essential. > > Thanks > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf = Of Jari Arkko > Sent: Thursday, January 13, 2011 2:53 PM > To: armd@ietf.org > Subject: [armd] thoughts on the continuation of the ARMD work > > It is time to decide what to do with another BOF or some other continuation of this work. > > I'm not the AD responsible for this work (Ralph is) but I thought it = might be useful to provide some possible ideas that might work. > > One approach is to run a second BOF, and attempt to come to a = conclusion that we have or do not have a scaling problem in ARP. If we do have a scaling problem then we can charter a working group that works on a solution. Linda and Sue tell me that they are working on experiments = that may help us understand the scaling problems better, so there may be some material ready from this to the BOF. > > Another approach is to just charter a working group that documents = scaling characteristics of ARP and ND, and perhaps also provides some = operational advice on how to best run your networks without running into issues. = This working group would run, say, for six months and would come up with a = couple of RFCs. At that point it would we could perhaps recharter the group for some protocol work, if the RFCs showed that there are severe issues. > > In either case we need to work on what the scaling characteristics of = ARP and ND are. The difference is that in the BOF approach we need to focus = on finding the "smoking gun" and have a yes-no type discussion. In the WG approach we can take a bit more time, do an in-depth analysis, can = document the results neutrally without pressure to find the gun, and may even = provide some useful advice to network managers in the process. > > Jari > > > _______________________________________________ > 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 > _______________________________________________ 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 tmackcrane@huawei.com Wed Jan 19 08:46:32 2011 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 7066F3A7170 for ; Wed, 19 Jan 2011 08:46:32 -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=[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 qL0eIt4TrHg8 for ; Wed, 19 Jan 2011 08:46:31 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 537CF3A7037 for ; Wed, 19 Jan 2011 08:46:31 -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 <0LFA00FZN41Z2U@usaga01-in.huawei.com> for armd@ietf.org; Wed, 19 Jan 2011 08:49:11 -0800 (PST) Received: from T737581 (c-24-1-109-43.hsd1.il.comcast.net [24.1.109.43]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFA00GWR41YX6@usaga01-in.huawei.com> for armd@ietf.org; Wed, 19 Jan 2011 08:49:11 -0800 (PST) Date: Wed, 19 Jan 2011 10:49:10 -0600 From: Ben Mack-Crane In-reply-to: <4D2F823E.30804@piuha.net> To: 'Jari Arkko' , armd@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcuzdJ/f82YxavdLS5WwvaF+OHTDfQEgyVQg References: <4D2F823E.30804@piuha.net> Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 19 Jan 2011 16:46:32 -0000 I agree with the sentiments expressed so far. It would be best to charter a WG to further study and document performance concerns and related operational advice for very large L2 networks and add to the charter if protocol work is required. So I support the second approach described below. Regards, Ben Mack-Crane > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Jari Arkko > Sent: Thursday, January 13, 2011 4:53 PM > To: armd@ietf.org > Subject: [armd] thoughts on the continuation of the ARMD work > > It is time to decide what to do with another BOF or some other > continuation of this work. > > I'm not the AD responsible for this work (Ralph is) but I thought it > might be useful to provide some possible ideas that might work. > > One approach is to run a second BOF, and attempt to come to a > conclusion > that we have or do not have a scaling problem in ARP. If we do have a > scaling problem then we can charter a working group that works on a > solution. Linda and Sue tell me that they are working on experiments > that may help us understand the scaling problems better, so there may > be > some material ready from this to the BOF. > > Another approach is to just charter a working group that documents > scaling characteristics of ARP and ND, and perhaps also provides some > operational advice on how to best run your networks without running > into > issues. This working group would run, say, for six months and would > come > up with a couple of RFCs. At that point it would we could perhaps > recharter the group for some protocol work, if the RFCs showed that > there are severe issues. > > In either case we need to work on what the scaling characteristics of > ARP and ND are. The difference is that in the BOF approach we need to > focus on finding the "smoking gun" and have a yes-no type discussion. > In > the WG approach we can take a bit more time, do an in-depth analysis, > can document the results neutrally without pressure to find the gun, > and > may even provide some useful advice to network managers in the process. > > Jari > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd From wang.jun17@zte.com.cn Wed Jan 19 17:17:11 2011 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 3D89028C106; Wed, 19 Jan 2011 17:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 2weDRlVmKrcX; Wed, 19 Jan 2011 17:17:10 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 977F028C126; Wed, 19 Jan 2011 17:17:08 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101361595298; Thu, 20 Jan 2011 09:17:51 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 66283.4353062561; Thu, 20 Jan 2011 09:12:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p0K1JbUi008811; Thu, 20 Jan 2011 09:19:38 +0800 (GMT-8) (envelope-from wang.jun17@zte.com.cn) In-Reply-To: To: Ben Mack-Crane MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.jun17@zte.com.cn Date: Thu, 20 Jan 2011 09:19:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-20 09:19:38, Serialize complete at 2011-01-20 09:19:38 Content-Type: multipart/alternative; boundary="=_alternative 000731354825781E_=" X-MAIL: mse02.zte.com.cn p0K1JbUi008811 Cc: armd-bounces@ietf.org, armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:17:11 -0000 This is a multipart message in MIME format. --=_alternative 000731354825781E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgQVJQL05EIGlzc3VlcyBkZXBlbmQgb24gbm90IG9ubHkgdGhlIG5ldHdvcmsg c2NhbGUgYnV0IGFsc28gDQp0aGUgZGlzdHJpYnV0ZWQgbWVjaGFuaXNtIGFkb3B0ZWQgYW1vbmcg dGhlIHNlcnZlcnMuDQoNClRoZSBkaXN0cmlidXRlZCBhbGdvcml0aG0gZGVjaWRlcyB0aGUgY29u bmVjdGl2aXR5IGluIHRoZSBzYW1lIExBTiwgYW5kIA0KY29ubmVjdGl2aXR5IGRlY2lkZXMgdGhl IG51bWJlciBvZiBBUlAvTkQgYnJvYWRjYXN0IHJlcXVlc3QgdHJpZ2dlcmVkIGJ5IA0KdGhlIGFn ZWluZyB0aW1lci4NCg0KDQpSdXNzZWxsDQoNCg0KDQoNCg0KQmVuIE1hY2stQ3JhbmUgPHRtYWNr Y3JhbmVAaHVhd2VpLmNvbT4gDQq3orz+yMs6ICBhcm1kLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEt MDEtMjAgMDA6NDkNCg0KytW8/sjLDQonSmFyaSBBcmtrbycgPGphcmkuYXJra29AcGl1aGEubmV0 PiwgYXJtZEBpZXRmLm9yZw0Ks63LzQ0KDQrW98ziDQpSZTogW2FybWRdIHRob3VnaHRzIG9uIHRo ZSBjb250aW51YXRpb24gb2YgdGhlIEFSTUQgd29yaw0KDQoNCg0KDQoNCg0KSSBhZ3JlZSB3aXRo IHRoZSBzZW50aW1lbnRzIGV4cHJlc3NlZCBzbyBmYXIuIEl0IHdvdWxkIGJlIGJlc3QgdG8gY2hh cnRlciANCmENCldHIHRvIGZ1cnRoZXIgc3R1ZHkgYW5kIGRvY3VtZW50IHBlcmZvcm1hbmNlIGNv bmNlcm5zIGFuZCByZWxhdGVkDQpvcGVyYXRpb25hbCBhZHZpY2UgZm9yIHZlcnkgbGFyZ2UgTDIg bmV0d29ya3MgYW5kIGFkZCB0byB0aGUgY2hhcnRlciBpZg0KcHJvdG9jb2wgd29yayBpcyByZXF1 aXJlZC4gIFNvIEkgc3VwcG9ydCB0aGUgc2Vjb25kIGFwcHJvYWNoIGRlc2NyaWJlZA0KYmVsb3cu DQoNCg0KUmVnYXJkcywNCkJlbiBNYWNrLUNyYW5lDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogYXJtZC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXJtZC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gSmFyaSBBcmtrbw0KPiBTZW50OiBUaHVyc2RheSwg SmFudWFyeSAxMywgMjAxMSA0OjUzIFBNDQo+IFRvOiBhcm1kQGlldGYub3JnDQo+IFN1YmplY3Q6 IFthcm1kXSB0aG91Z2h0cyBvbiB0aGUgY29udGludWF0aW9uIG9mIHRoZSBBUk1EIHdvcmsNCj4g DQo+IEl0IGlzIHRpbWUgdG8gZGVjaWRlIHdoYXQgdG8gZG8gd2l0aCBhbm90aGVyIEJPRiBvciBz b21lIG90aGVyDQo+IGNvbnRpbnVhdGlvbiBvZiB0aGlzIHdvcmsuDQo+IA0KPiBJJ20gbm90IHRo ZSBBRCByZXNwb25zaWJsZSBmb3IgdGhpcyB3b3JrIChSYWxwaCBpcykgYnV0IEkgdGhvdWdodCBp dA0KPiBtaWdodCBiZSB1c2VmdWwgdG8gcHJvdmlkZSBzb21lIHBvc3NpYmxlIGlkZWFzIHRoYXQg bWlnaHQgd29yay4NCj4gDQo+IE9uZSBhcHByb2FjaCBpcyB0byBydW4gYSBzZWNvbmQgQk9GLCBh bmQgYXR0ZW1wdCB0byBjb21lIHRvIGENCj4gY29uY2x1c2lvbg0KPiB0aGF0IHdlIGhhdmUgb3Ig ZG8gbm90IGhhdmUgYSBzY2FsaW5nIHByb2JsZW0gaW4gQVJQLiBJZiB3ZSBkbyBoYXZlIGENCj4g c2NhbGluZyBwcm9ibGVtIHRoZW4gd2UgY2FuIGNoYXJ0ZXIgYSB3b3JraW5nIGdyb3VwIHRoYXQg d29ya3Mgb24gYQ0KPiBzb2x1dGlvbi4gTGluZGEgYW5kIFN1ZSB0ZWxsIG1lIHRoYXQgdGhleSBh cmUgd29ya2luZyBvbiBleHBlcmltZW50cw0KPiB0aGF0IG1heSBoZWxwIHVzIHVuZGVyc3RhbmQg dGhlIHNjYWxpbmcgcHJvYmxlbXMgYmV0dGVyLCBzbyB0aGVyZSBtYXkNCj4gYmUNCj4gc29tZSBt YXRlcmlhbCByZWFkeSBmcm9tIHRoaXMgdG8gdGhlIEJPRi4NCj4gDQo+IEFub3RoZXIgYXBwcm9h Y2ggaXMgdG8ganVzdCBjaGFydGVyIGEgd29ya2luZyBncm91cCB0aGF0IGRvY3VtZW50cw0KPiBz Y2FsaW5nIGNoYXJhY3RlcmlzdGljcyBvZiBBUlAgYW5kIE5ELCBhbmQgcGVyaGFwcyBhbHNvIHBy b3ZpZGVzIHNvbWUNCj4gb3BlcmF0aW9uYWwgYWR2aWNlIG9uIGhvdyB0byBiZXN0IHJ1biB5b3Vy IG5ldHdvcmtzIHdpdGhvdXQgcnVubmluZw0KPiBpbnRvDQo+IGlzc3Vlcy4gVGhpcyB3b3JraW5n IGdyb3VwIHdvdWxkIHJ1biwgc2F5LCBmb3Igc2l4IG1vbnRocyBhbmQgd291bGQNCj4gY29tZQ0K PiB1cCB3aXRoIGEgY291cGxlIG9mIFJGQ3MuIEF0IHRoYXQgcG9pbnQgaXQgd291bGQgd2UgY291 bGQgcGVyaGFwcw0KPiByZWNoYXJ0ZXIgdGhlIGdyb3VwIGZvciBzb21lIHByb3RvY29sIHdvcmss IGlmIHRoZSBSRkNzIHNob3dlZCB0aGF0DQo+IHRoZXJlIGFyZSBzZXZlcmUgaXNzdWVzLg0KPiAN Cj4gSW4gZWl0aGVyIGNhc2Ugd2UgbmVlZCB0byB3b3JrIG9uIHdoYXQgdGhlIHNjYWxpbmcgY2hh cmFjdGVyaXN0aWNzIG9mDQo+IEFSUCBhbmQgTkQgYXJlLiBUaGUgZGlmZmVyZW5jZSBpcyB0aGF0 IGluIHRoZSBCT0YgYXBwcm9hY2ggd2UgbmVlZCB0bw0KPiBmb2N1cyBvbiBmaW5kaW5nIHRoZSAi c21va2luZyBndW4iIGFuZCBoYXZlIGEgeWVzLW5vIHR5cGUgZGlzY3Vzc2lvbi4NCj4gSW4NCj4g dGhlIFdHIGFwcHJvYWNoIHdlIGNhbiB0YWtlIGEgYml0IG1vcmUgdGltZSwgZG8gYW4gaW4tZGVw dGggYW5hbHlzaXMsDQo+IGNhbiBkb2N1bWVudCB0aGUgcmVzdWx0cyBuZXV0cmFsbHkgd2l0aG91 dCBwcmVzc3VyZSB0byBmaW5kIHRoZSBndW4sDQo+IGFuZA0KPiBtYXkgZXZlbiBwcm92aWRlIHNv bWUgdXNlZnVsIGFkdmljZSB0byBuZXR3b3JrIG1hbmFnZXJzIGluIHRoZSBwcm9jZXNzLg0KPiAN Cj4gSmFyaQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IGFybWQgbWFpbGluZyBsaXN0DQo+IGFybWRAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcm1kDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQphcm1kIG1haWxpbmcgbGlzdA0KYXJtZEBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcm1kDQoNCg0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2Fn ZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0g c3lzdGVtLg0K --=_alternative 000731354825781E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgdGhlIEFSUC9ORCBp c3N1ZXMgZGVwZW5kIG9uDQpub3Qgb25seSB0aGUgbmV0d29yayBzY2FsZSBidXQgYWxzbyB0aGUg ZGlzdHJpYnV0ZWQgbWVjaGFuaXNtIGFkb3B0ZWQgYW1vbmcNCnRoZSBzZXJ2ZXJzLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGRpc3RyaWJ1dGVk IGFsZ29yaXRobSBkZWNpZGVzIHRoZQ0KY29ubmVjdGl2aXR5IGluIHRoZSBzYW1lIExBTiwgYW5k IGNvbm5lY3Rpdml0eSBkZWNpZGVzIHRoZSBudW1iZXIgb2YgQVJQL05EDQpicm9hZGNhc3QgcmVx dWVzdCB0cmlnZ2VyZWQgYnkgdGhlIGFnZWluZyB0aW1lci48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJ1c3NlbGw8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj4NCjxicj4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5CZW4gTWFjay1DcmFuZSAmbHQ7dG1hY2tj cmFuZUBodWF3ZWkuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDthcm1kLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wMS0yMCAwMDo0OTwvZm9udD4N Cjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4nSmFyaSBB cmtrbycgJmx0O2phcmkuYXJra29AcGl1aGEubmV0Jmd0OywNCmFybWRAaWV0Zi5vcmc8L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3 zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBb YXJtZF0gdGhvdWdodHMgb24gdGhlIGNvbnRpbnVhdGlvbg0Kb2YgdGhlIEFSTUQgd29yazwvZm9u dD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90 YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSBh Z3JlZSB3aXRoIHRoZSBzZW50aW1lbnRzIGV4cHJlc3NlZCBzbyBmYXIuIEl0IHdvdWxkDQpiZSBi ZXN0IHRvIGNoYXJ0ZXIgYTxicj4NCldHIHRvIGZ1cnRoZXIgc3R1ZHkgYW5kIGRvY3VtZW50IHBl cmZvcm1hbmNlIGNvbmNlcm5zIGFuZCByZWxhdGVkPGJyPg0Kb3BlcmF0aW9uYWwgYWR2aWNlIGZv ciB2ZXJ5IGxhcmdlIEwyIG5ldHdvcmtzIGFuZCBhZGQgdG8gdGhlIGNoYXJ0ZXIgaWY8YnI+DQpw cm90b2NvbCB3b3JrIGlzIHJlcXVpcmVkLiAmbmJzcDtTbyBJIHN1cHBvcnQgdGhlIHNlY29uZCBh cHByb2FjaCBkZXNjcmliZWQ8YnI+DQpiZWxvdy48YnI+DQo8YnI+DQo8YnI+DQpSZWdhcmRzLDxi cj4NCkJlbiBNYWNrLUNyYW5lPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsgRnJvbTogYXJtZC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXJtZC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCk9mPGJyPg0KJmd0OyBKYXJpIEFya2tvPGJyPg0K Jmd0OyBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxMywgMjAxMSA0OjUzIFBNPGJyPg0KJmd0OyBU bzogYXJtZEBpZXRmLm9yZzxicj4NCiZndDsgU3ViamVjdDogW2FybWRdIHRob3VnaHRzIG9uIHRo ZSBjb250aW51YXRpb24gb2YgdGhlIEFSTUQgd29yazxicj4NCiZndDsgPGJyPg0KJmd0OyBJdCBp cyB0aW1lIHRvIGRlY2lkZSB3aGF0IHRvIGRvIHdpdGggYW5vdGhlciBCT0Ygb3Igc29tZSBvdGhl cjxicj4NCiZndDsgY29udGludWF0aW9uIG9mIHRoaXMgd29yay48YnI+DQomZ3Q7IDxicj4NCiZn dDsgSSdtIG5vdCB0aGUgQUQgcmVzcG9uc2libGUgZm9yIHRoaXMgd29yayAoUmFscGggaXMpIGJ1 dCBJIHRob3VnaHQNCml0PGJyPg0KJmd0OyBtaWdodCBiZSB1c2VmdWwgdG8gcHJvdmlkZSBzb21l IHBvc3NpYmxlIGlkZWFzIHRoYXQgbWlnaHQgd29yay48YnI+DQomZ3Q7IDxicj4NCiZndDsgT25l IGFwcHJvYWNoIGlzIHRvIHJ1biBhIHNlY29uZCBCT0YsIGFuZCBhdHRlbXB0IHRvIGNvbWUgdG8g YTxicj4NCiZndDsgY29uY2x1c2lvbjxicj4NCiZndDsgdGhhdCB3ZSBoYXZlIG9yIGRvIG5vdCBo YXZlIGEgc2NhbGluZyBwcm9ibGVtIGluIEFSUC4gSWYgd2UgZG8gaGF2ZQ0KYTxicj4NCiZndDsg c2NhbGluZyBwcm9ibGVtIHRoZW4gd2UgY2FuIGNoYXJ0ZXIgYSB3b3JraW5nIGdyb3VwIHRoYXQg d29ya3Mgb24NCmE8YnI+DQomZ3Q7IHNvbHV0aW9uLiBMaW5kYSBhbmQgU3VlIHRlbGwgbWUgdGhh dCB0aGV5IGFyZSB3b3JraW5nIG9uIGV4cGVyaW1lbnRzPGJyPg0KJmd0OyB0aGF0IG1heSBoZWxw IHVzIHVuZGVyc3RhbmQgdGhlIHNjYWxpbmcgcHJvYmxlbXMgYmV0dGVyLCBzbyB0aGVyZQ0KbWF5 PGJyPg0KJmd0OyBiZTxicj4NCiZndDsgc29tZSBtYXRlcmlhbCByZWFkeSBmcm9tIHRoaXMgdG8g dGhlIEJPRi48YnI+DQomZ3Q7IDxicj4NCiZndDsgQW5vdGhlciBhcHByb2FjaCBpcyB0byBqdXN0 IGNoYXJ0ZXIgYSB3b3JraW5nIGdyb3VwIHRoYXQgZG9jdW1lbnRzPGJyPg0KJmd0OyBzY2FsaW5n IGNoYXJhY3RlcmlzdGljcyBvZiBBUlAgYW5kIE5ELCBhbmQgcGVyaGFwcyBhbHNvIHByb3ZpZGVz IHNvbWU8YnI+DQomZ3Q7IG9wZXJhdGlvbmFsIGFkdmljZSBvbiBob3cgdG8gYmVzdCBydW4geW91 ciBuZXR3b3JrcyB3aXRob3V0IHJ1bm5pbmc8YnI+DQomZ3Q7IGludG88YnI+DQomZ3Q7IGlzc3Vl cy4gVGhpcyB3b3JraW5nIGdyb3VwIHdvdWxkIHJ1biwgc2F5LCBmb3Igc2l4IG1vbnRocyBhbmQg d291bGQ8YnI+DQomZ3Q7IGNvbWU8YnI+DQomZ3Q7IHVwIHdpdGggYSBjb3VwbGUgb2YgUkZDcy4g QXQgdGhhdCBwb2ludCBpdCB3b3VsZCB3ZSBjb3VsZCBwZXJoYXBzPGJyPg0KJmd0OyByZWNoYXJ0 ZXIgdGhlIGdyb3VwIGZvciBzb21lIHByb3RvY29sIHdvcmssIGlmIHRoZSBSRkNzIHNob3dlZCB0 aGF0PGJyPg0KJmd0OyB0aGVyZSBhcmUgc2V2ZXJlIGlzc3Vlcy48YnI+DQomZ3Q7IDxicj4NCiZn dDsgSW4gZWl0aGVyIGNhc2Ugd2UgbmVlZCB0byB3b3JrIG9uIHdoYXQgdGhlIHNjYWxpbmcgY2hh cmFjdGVyaXN0aWNzDQpvZjxicj4NCiZndDsgQVJQIGFuZCBORCBhcmUuIFRoZSBkaWZmZXJlbmNl IGlzIHRoYXQgaW4gdGhlIEJPRiBhcHByb2FjaCB3ZSBuZWVkDQp0bzxicj4NCiZndDsgZm9jdXMg b24gZmluZGluZyB0aGUgJnF1b3Q7c21va2luZyBndW4mcXVvdDsgYW5kIGhhdmUgYSB5ZXMtbm8g dHlwZQ0KZGlzY3Vzc2lvbi48YnI+DQomZ3Q7IEluPGJyPg0KJmd0OyB0aGUgV0cgYXBwcm9hY2gg d2UgY2FuIHRha2UgYSBiaXQgbW9yZSB0aW1lLCBkbyBhbiBpbi1kZXB0aCBhbmFseXNpcyw8YnI+ DQomZ3Q7IGNhbiBkb2N1bWVudCB0aGUgcmVzdWx0cyBuZXV0cmFsbHkgd2l0aG91dCBwcmVzc3Vy ZSB0byBmaW5kIHRoZSBndW4sPGJyPg0KJmd0OyBhbmQ8YnI+DQomZ3Q7IG1heSBldmVuIHByb3Zp ZGUgc29tZSB1c2VmdWwgYWR2aWNlIHRvIG5ldHdvcmsgbWFuYWdlcnMgaW4gdGhlIHByb2Nlc3Mu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEphcmk8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgYXJtZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IGFybWRAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXJtZDxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KYXJtZCBtYWls aW5nIGxpc3Q8YnI+DQphcm1kQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hcm1kPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHBy ZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNw O1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5i c3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5i c3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVu dHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8m bmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJz cDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMm bmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMu DQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5z bWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7 YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2Um bmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNw O3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYm bmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJz cDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3Jp Z2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3 cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUm bmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4N ClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtm b3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7 QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000731354825781E_=-- From vishwas.ietf@gmail.com Wed Jan 19 18:31:08 2011 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 D45563A6F07 for ; Wed, 19 Jan 2011 18:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, 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 Jwn5iAP7WUGS for ; Wed, 19 Jan 2011 18:31:07 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BD8A83A6DA7 for ; Wed, 19 Jan 2011 18:31:06 -0800 (PST) Received: by wyf23 with SMTP id 23so120049wyf.31 for ; Wed, 19 Jan 2011 18:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BjRISwlXot7mLvEEUWNZyi6J0XNs7CaBSSLq0phTZK0=; b=N2a1GVLytyLS0BBtLT9QcRoBuEGqs3FV3XfwrRwTlPFOEVk4/GUrApVf/K8t0fqlFJ 3X5w/gNE0rAtaOmeXAiB7/s2sBj9RYKH7J8YF2U+RPGGvrmfG1dOfLhCSLfwE2DSIR4O 3uEUfcIHSW2afXT77P/ieUEeto8g5Ptj9c8L8= 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; b=ldlNNJ/ZAtMKh2z7I7ni1iFRMi/h3NuJgwXR+NfEJxbiFMoQYR0omE3XkJS9xbL7I6 7jU4PWYN5gPMWKmPEu3/ksROVvCKFIIBFggHVkbwMhg8+f8WzrKTwGXa4sbrEyS1j3L9 vSed5KojolJHb6ZPmiRTI5fjR150427TCP5rs= MIME-Version: 1.0 Received: by 10.216.150.164 with SMTP id z36mr1379990wej.52.1295490827093; Wed, 19 Jan 2011 18:33:47 -0800 (PST) Received: by 10.216.21.65 with HTTP; Wed, 19 Jan 2011 18:33:47 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Jan 2011 18:33:47 -0800 Message-ID: From: Vishwas Manral To: "Shah, Himanshu" Content-Type: text/plain; charset=ISO-8859-1 Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 02:31:09 -0000 Hi, I agree with Himanshu's views. Thanks, Vishwas On Tue, Jan 18, 2011 at 1:57 PM, Shah, Himanshu wrote: > It appears that we are unnecessarily setting the bar > > higher for this work to continue. > > > > I believe there was adequate problem scope and data presented > > during the last BoFs. We seem to put more emphasis on peripheral, > > off-the-cuff opinions and warrant more research, more data.. > > > > We need to get out of this BoF-forever-mode (or go-fetch-more-rocks cycle), > > and start a WG to address the problem. To that extent, I agree with > > your suggestion about continuing the work in a WG, even if that meant > > to be in a problem-study mode initially. > > > > /himanshu > > > > > > > > -----Original Message----- > > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Jari > Arkko > > Sent: Thursday, January 13, 2011 4:53 PM > > To: armd@ietf.org > > Subject: [armd] thoughts on the continuation of the ARMD work > > > > It is time to decide what to do with another BOF or some other continuation > of this work. > > > > I'm not the AD responsible for this work (Ralph is) but I thought it might > be useful to provide some possible ideas that might work. > > > > One approach is to run a second BOF, and attempt to come to a conclusion > that we have or do not have a scaling problem in ARP. If we do have a > scaling problem then we can charter a working group that works on a > solution. Linda and Sue tell me that they are working on experiments that > may help us understand the scaling problems better, so there may be some > material ready from this to the BOF. > > > > Another approach is to just charter a working group that documents scaling > characteristics of ARP and ND, and perhaps also provides some operational > advice on how to best run your networks without running into issues. This > working group would run, say, for six months and would come up with a couple > of RFCs. At that point it would we could perhaps recharter the group for > some protocol work, if the RFCs showed that there are severe issues. > > > > In either case we need to work on what the scaling characteristics of ARP > and ND are. The difference is that in the BOF approach we need to focus on > finding the "smoking gun" and have a yes-no type discussion. In the WG > approach we can take a bit more time, do an in-depth analysis, can document > the results neutrally without pressure to find the gun, and may even provide > some useful advice to network managers in the process. > > > > Jari > > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > From thsridhar@gmail.com Wed Jan 19 23:55:12 2011 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 A4DDC3A7094 for ; Wed, 19 Jan 2011 23:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 vdOpBX6XZEwQ for ; Wed, 19 Jan 2011 23:55:11 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 9DBA93A6DAD for ; Wed, 19 Jan 2011 23:55:10 -0800 (PST) Received: by eyd10 with SMTP id 10so113302eyd.31 for ; Wed, 19 Jan 2011 23:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=p46YnDSwNGcoIMNlsvm7TuhKs6q1Y8AHXBEu4wD0Lrk=; b=SiknBofNzuvNU+V+arVfNit5wMkq/yxQKeYRWeV0fLoPywdd1I+YOoAfaKZybl3cr6 Ct+gMQa6VbtzCSfHtMa0ftRwRFRABBqafFBpYwMaubkubGn29nV2igGAr37APhkPUHLE dS4Y8gOZreOmL2Ri700o9g3JIaEt5HQhJRGKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=LFPwnJJbI3mCOGcuVZR4xkBhtD87Chu5Ltyk1jFlMstmXIIb3b2WhhALbF6YSdsvOH Brgu2ea03d5mUbp5vYXtma4i6QzmO28UiQRevWxNVfu5lfW4VLwb9Np77L58M1rzkXoT 7K12fAE8tlynIJQBIjKRqoo3hCFSR8adnDbdQ= Received: by 10.14.17.93 with SMTP id i69mr2087992eei.18.1295510272026; Wed, 19 Jan 2011 23:57:52 -0800 (PST) MIME-Version: 1.0 Sender: thsridhar@gmail.com Received: by 10.14.119.10 with HTTP; Wed, 19 Jan 2011 23:57:31 -0800 (PST) From: T Sridhar Date: Wed, 19 Jan 2011 23:57:31 -0800 X-Google-Sender-Auth: nqyMMxgKQsnKnZ9uwdsLSvuVdo8 Message-ID: To: armd@ietf.org Content-Type: multipart/alternative; boundary=0016e65aefda912881049a427dbe Subject: Re: [armd] thoughts on the continuation of the ARMD work X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 07:55:12 -0000 --0016e65aefda912881049a427dbe Content-Type: text/plain; charset=ISO-8859-1 I like Himanshu's description calling it a "go-fetch-more-rocks cycle" :-) I am also in favor of chartering the WG. Thanks, Sridhar From: "Shah, Himanshu" To: Date: Tue, 18 Jan 2011 16:57:37 -0500 Subject: Re: [armd] thoughts on the continuation of the ARMD work It appears that we are unnecessarily setting the bar higher for this work to continue. I believe there was adequate problem scope and data presented during the last BoFs. We seem to put more emphasis on peripheral, off-the-cuff opinions and warrant more research, more data.. We need to get out of this BoF-forever-mode (or go-fetch-more-rocks cycle), and start a WG to address the problem. To that extent, I agree with your suggestion about continuing the work in a WG, even if that meant to be in a problem-study mode initially. /himanshu -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Thursday, January 13, 2011 4:53 PM To: armd@ietf.org Subject: [armd] thoughts on the continuation of the ARMD work It is time to decide what to do with another BOF or some other continuation of this work. I'm not the AD responsible for this work (Ralph is) but I thought it might be useful to provide some possible ideas that might work. One approach is to run a second BOF, and attempt to come to a conclusion that we have or do not have a scaling problem in ARP. If we do have a scaling problem then we can charter a working group that works on a solution. Linda and Sue tell me that they are working on experiments that may help us understand the scaling problems better, so there may be some material ready from this to the BOF. Another approach is to just charter a working group that documents scaling characteristics of ARP and ND, and perhaps also provides some operational advice on how to best run your networks without running into issues. This working group would run, say, for six months and would come up with a couple of RFCs. At that point it would we could perhaps recharter the group for some protocol work, if the RFCs showed that there are severe issues. In either case we need to work on what the scaling characteristics of ARP and ND are. The difference is that in the BOF approach we need to focus on finding the "smoking gun" and have a yes-no type discussion. In the WG approach we can take a bit more time, do an in-depth analysis, can document the results neutrally without pressure to find the gun, and may even provide some useful advice to network managers in the process. Jari --0016e65aefda912881049a427dbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I like Himanshu's description calling it a "go-fetch-more-rocks cy= cle" :-)

I am also in favor of chartering the WG.

Thanks= ,
Sridhar


From:=A0"Shah, Himanshu" <hshah@ciena.com>
To:=A0<armd@ietf.org>
Date:= =A0Tue, 18 Jan 2011 16:57:37 -0500
Subject:=A0Re: [armd] thoughts on the=20 continuation of the ARMD work

It appears that we are unnecessarily setting the=20 bar

higher for this work to continue.

=A0

I believe=20 there was adequate problem scope and data presented

during the=20 last BoFs. We seem to put more emphasis on peripheral,

off-the-cuff opinions and warrant more research, more data..

=A0

We need=20 to get out of this BoF-forever-mode (or go-fetch-more-rocks cycle),

= and start a WG to address the problem. To that extent, I agree with

your suggestion about continuing the work in a WG, even if that meant

to be in a problem-study mode initially.

=A0

/himanshu =A0

= =A0

=A0

=A0

-----Original Message-----

From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Jari Arkko

Sent: Thursday, January 13, 2011 4:53 PM

=

To: armd@ietf.org

Subject: [armd] thoughts on the continuation of the ARMD work

=A0

It=20 is time to decide what to do with another BOF or some other continuation of this work.

=A0

I'm not the AD responsible for this work= =20 (Ralph is) but I thought it might be useful to provide some possible=20 ideas that might work.

=A0

One approach is to run a second=20 BOF, and attempt to come to a conclusion that we have or do not have a=20 scaling problem in ARP. If we do have a scaling problem then we can=20 charter a working group that works on a solution. Linda and Sue tell me=20 that they are working on experiments that may help us understand the=20 scaling problems better, so there may be some material ready from this=20 to the BOF.

=A0

Another approach is to just charter a working= =20 group that documents scaling characteristics of ARP and ND, and perhaps=20 also provides some operational advice on how to best run your networks=20 without running into issues. This working group would run, say, for six=20 months and would come up with a couple of RFCs. At that point it would=20 we could perhaps recharter the group for some protocol work, if the RFCs showed that there are severe issues.

=A0

In either case we=20 need to work on what the scaling characteristics of ARP and ND are. The=20 difference is that in the BOF approach we need to focus on finding the=20 "smoking gun" and have a yes-no type discussion. In the WG approa= ch we=20 can take a bit more time, do an in-depth analysis, can document the=20 results neutrally without pressure to find the gun, and may even provide some useful advice to network managers in the process.

=A0

Jar= i

=A0


--0016e65aefda912881049a427dbe-- From narten@us.ibm.com Thu Jan 20 06:37:43 2011 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 38F2E3A7125 for ; Thu, 20 Jan 2011 06:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.335 X-Spam-Level: X-Spam-Status: No, score=-105.335 tagged_above=-999 required=5 tests=[AWL=1.264, 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 eHAzXGDEMbJq for ; Thu, 20 Jan 2011 06:37:42 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 45AA03A7122 for ; Thu, 20 Jan 2011 06:37:42 -0800 (PST) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0KEJcR2007636 for ; Thu, 20 Jan 2011 09:22:48 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 0CD567280D8 for ; Thu, 20 Jan 2011 09:39:56 -0500 (EST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0KEdrLH449438 for ; Thu, 20 Jan 2011 09:39:55 -0500 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0KEdrcX021766 for ; Thu, 20 Jan 2011 07:39:53 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-154-223.mts.ibm.com [9.76.154.223]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0KEdp0R021657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 07:39:52 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p0KEdogU005235; Thu, 20 Jan 2011 09:39:50 -0500 Message-Id: <201101201439.p0KEdogU005235@cichlid.raleigh.ibm.com> To: Jari Arkko In-reply-to: <4D2F823E.30804@piuha.net> References: <4D2F823E.30804@piuha.net> Comments: In-reply-to Jari Arkko message dated "Fri, 14 Jan 2011 00:52:46 +0200." Date: Thu, 20 Jan 2011 09:39:50 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 14:37:43 -0000 The difficulty I have with this group is that it is based on the premise is that ARP doesn't scale. Of course that is true. But it is at some level meaningless. ARP works fine, so long as the subnet (or link, using IPv6 terminology) doesn't get "too large". This has been known for 20+ years. If you make your subnet too large and flat, you will experience pain. We are dealing with the classic "I want to make my network big and flat because that gives me certain advantages". Yet there are downsides to that. We will never make ARP "scale" as big as is imaginable or as some people might want. Even if we *want* that, and it would be *nice*. It would be nice to get a Free Lunch too, but that doesn't happen in real life. The constraints to "solving" the ARP scaling problem are enormous. We can't change any protocols, or modify hosts, because it is pretty clear that those sorts of changes will take too long to become widely implemented and deployed to be useful. That leaves us with techniques like Proxy ARP. Do we need a WG to tell us how to use Proxy ARP? I would hope not... Thomas From ldunbar@huawei.com Thu Jan 20 08:11:54 2011 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 C5D933A7149 for ; Thu, 20 Jan 2011 08:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.185 X-Spam-Level: X-Spam-Status: No, score=-106.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 W679XG9UO8Jd for ; Thu, 20 Jan 2011 08:11:53 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 87A903A70F5 for ; Thu, 20 Jan 2011 08:11: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 <0LFB00DSLX4BLB@usaga02-in.huawei.com> for armd@ietf.org; Thu, 20 Jan 2011 08:14:36 -0800 (PST) Received: from L735042 ([10.124.12.99]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFB00MKDX4BC8@usaga02-in.huawei.com> for armd@ietf.org; Thu, 20 Jan 2011 08:14:35 -0800 (PST) Date: Thu, 20 Jan 2011 10:14:35 -0600 From: Linda Dunbar In-reply-to: <201101201439.p0KEdogU005235@cichlid.raleigh.ibm.com> To: 'Thomas Narten' , 'Jari Arkko' Message-id: <005501cbb8bd$2173ad70$630c7c0a@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=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acu4sAeDxXtIJkbcQmKIRzM7qlp1iQAC3h3A References: <4D2F823E.30804@piuha.net> <201101201439.p0KEdogU005235@cichlid.raleigh.ibm.com> Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 16:11:54 -0000 Thomas, ARP works fine when all the hosts within one subnet are confined to one Aggregation switch (or Top of Rack switch) because all the broadcast messages are confined. When VM and VM migration is deployed in Data Centers, hosts in one subnet (VLAN) may start with being close together and gradually being relocated to various places as the result of continuous VM migration. We are not talking about flat big network. Each subnet is not big, but when there are so many of them, ARP/ND broadcast messages will cause a lot more traffic traversing across Aggregation switches. One of our customers' data centers already have more than 4000 VLANs. When VMs belonging to one subnet are spread across multiple TOR switches, all the ARP broadcast messages and ND multicast messages are sent to all TOR switches in the broadcast domain. This will cause TOR switch to refresh its FDB even for the MAC not used by its local hosts. Most likely, the frequency of ARP/ND by hosts is shorter then TOR FDB MAC aging time. That means TOR FDB will have all the MAC addresses even if most of them are not used by local hosts. Linda Dunbar -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Thursday, January 20, 2011 8:40 AM To: Jari Arkko Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work The difficulty I have with this group is that it is based on the premise is that ARP doesn't scale. Of course that is true. But it is at some level meaningless. ARP works fine, so long as the subnet (or link, using IPv6 terminology) doesn't get "too large". This has been known for 20+ years. If you make your subnet too large and flat, you will experience pain. We are dealing with the classic "I want to make my network big and flat because that gives me certain advantages". Yet there are downsides to that. We will never make ARP "scale" as big as is imaginable or as some people might want. Even if we *want* that, and it would be *nice*. It would be nice to get a Free Lunch too, but that doesn't happen in real life. The constraints to "solving" the ARP scaling problem are enormous. We can't change any protocols, or modify hosts, because it is pretty clear that those sorts of changes will take too long to become widely implemented and deployed to be useful. That leaves us with techniques like Proxy ARP. Do we need a WG to tell us how to use Proxy ARP? I would hope not... Thomas _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From skh@ndzh.com Thu Jan 20 15:08:48 2011 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 CCF1F3A687A for ; Thu, 20 Jan 2011 15:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKKfQtk8ePwf for ; Thu, 20 Jan 2011 15:08:47 -0800 (PST) Received: from hickoryhill-consulting.com (63-208-161-194.digitalrealm.net [63.208.161.194]) by core3.amsl.com (Postfix) with ESMTP id BC6383A686C for ; Thu, 20 Jan 2011 15:08:47 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=121.15.1.161; Received: from SKHPERSONALLT (unverified [121.15.1.161]) by hickoryhill-consulting.com (SurgeMail 4.2d4) with ESMTP id 1973362-1945496 for multiple; Thu, 20 Jan 2011 18:11:12 -0500 From: "Susan Hares" To: "'Linda Dunbar'" , "'Thomas Narten'" , "'Jari Arkko'" References: <4D2F823E.30804@piuha.net> <201101201439.p0KEdogU005235@cichlid.raleigh.ibm.com> <005501cbb8bd$2173ad70$630c7c0a@china.huawei.com> In-Reply-To: <005501cbb8bd$2173ad70$630c7c0a@china.huawei.com> Date: Thu, 20 Jan 2011 18:11:13 -0500 Message-ID: <001901cbb8f7$56bad9b0$04308d10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu4sAeDxXtIJkbcQmKIRzM7qlp1iQAC3h3AAA2lmfA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-Mailman-Approved-At: Thu, 20 Jan 2011 15:17:22 -0800 Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 23:08:48 -0000 Thomas: Let me add my 2 cents to Linda's comment. The comment of "I want to make my network big and flat because that gives me certain advantages". is arising again due to changes in the Data Center environment. Please note this is a specific target environment. Please understand that general "ARP Scaling" is not our focus - but a specific area of ARP scaling for this target environment with business implications. As to the constraints, we are examining the constraints on ARP that must stay for this specific target work and those which can be relaxed (for this specific target). Linda is providing specific examples for this target environment. IP + glue protocols has always adapted to specific environments with tuning (for example mobile). We welcome comments based on this specific scope on this list. General discussion about "general ARP" changes is not our focus. Sue Hares -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, January 20, 2011 11:15 AM To: 'Thomas Narten'; 'Jari Arkko' Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work Thomas, ARP works fine when all the hosts within one subnet are confined to one Aggregation switch (or Top of Rack switch) because all the broadcast messages are confined. When VM and VM migration is deployed in Data Centers, hosts in one subnet (VLAN) may start with being close together and gradually being relocated to various places as the result of continuous VM migration. We are not talking about flat big network. Each subnet is not big, but when there are so many of them, ARP/ND broadcast messages will cause a lot more traffic traversing across Aggregation switches. One of our customers' data centers already have more than 4000 VLANs. When VMs belonging to one subnet are spread across multiple TOR switches, all the ARP broadcast messages and ND multicast messages are sent to all TOR switches in the broadcast domain. This will cause TOR switch to refresh its FDB even for the MAC not used by its local hosts. Most likely, the frequency of ARP/ND by hosts is shorter then TOR FDB MAC aging time. That means TOR FDB will have all the MAC addresses even if most of them are not used by local hosts. Linda Dunbar -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Thursday, January 20, 2011 8:40 AM To: Jari Arkko Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work The difficulty I have with this group is that it is based on the premise is that ARP doesn't scale. Of course that is true. But it is at some level meaningless. ARP works fine, so long as the subnet (or link, using IPv6 terminology) doesn't get "too large". This has been known for 20+ years. If you make your subnet too large and flat, you will experience pain. We are dealing with the classic "I want to make my network big and flat because that gives me certain advantages". Yet there are downsides to that. We will never make ARP "scale" as big as is imaginable or as some people might want. Even if we *want* that, and it would be *nice*. It would be nice to get a Free Lunch too, but that doesn't happen in real life. The constraints to "solving" the ARP scaling problem are enormous. We can't change any protocols, or modify hosts, because it is pretty clear that those sorts of changes will take too long to become widely implemented and deployed to be useful. That leaves us with techniques like Proxy ARP. Do we need a WG to tell us how to use Proxy ARP? I would hope not... Thomas _______________________________________________ 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 anoop@brocade.com Fri Jan 21 12:46:58 2011 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 8679628C0E9 for ; Fri, 21 Jan 2011 12:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV5471xDtk9E for ; Fri, 21 Jan 2011 12:46:57 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 5D5003A6807 for ; Fri, 21 Jan 2011 12:46:57 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p0LKkb1X031840; Fri, 21 Jan 2011 12:49:40 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id tygyj00pu-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Jan 2011 12:49:40 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 21 Jan 2011 12:56:15 -0800 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Fri, 21 Jan 2011 12:49:38 -0800 From: Anoop Ghanwani To: Susan Hares , "'Linda Dunbar'" , "'Thomas Narten'" , "'Jari Arkko'" Date: Fri, 21 Jan 2011 12:49:57 -0800 Thread-Topic: [armd] thoughts on the continuation of the ARMD work Thread-Index: Acu4sAeDxXtIJkbcQmKIRzM7qlp1iQAC3h3AAA2lmfAALky9QA== Message-ID: <70C2EE1DF21B1245AD686FDC41D377C551F2972284@HQ1-EXCH02.corp.brocade.com> References: <4D2F823E.30804@piuha.net> <201101201439.p0KEdogU005235@cichlid.raleigh.ibm.com> <005501cbb8bd$2173ad70$630c7c0a@china.huawei.com> <001901cbb8f7$56bad9b0$04308d10$@com> In-Reply-To: <001901cbb8f7$56bad9b0$04308d10$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-21_07:2011-01-21, 2011-01-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101210132 Cc: "armd@ietf.org" Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 21 Jan 2011 20:46:58 -0000 Thought I should also voice my support for the creation of a working group to document the problems and a mechanism to deal with them. Folks are already starting to implement various things and it would be nice to have interoperable, consistent solutions. And to address Thomas' concern, this is really not so much about making networks flatter, but rather=20 about stretching an L2 domain across the data center, as opposed to keeping it confined to a single=20 top-of-the-rack or aggregation switch. Put another way, the subnet size stays the same, say 256 hosts,=20 but instead of having all 256 sitting under the same aggregation switch, we would now like to see them scattered across the data center. Network administrators have complained about this problem ("I can't decommission a malfunctioning server in one part of the network and put a new one in with the same IP address in a new location") even before the advent of server virtualization, but server virtualization with its mobility function has made this an even more compelling problem. Anoop > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Susan Hares > Sent: Thursday, January 20, 2011 3:11 PM > To: 'Linda Dunbar'; 'Thomas Narten'; 'Jari Arkko' > Cc: armd@ietf.org > Subject: Re: [armd] thoughts on the continuation of the ARMD work >=20 > Thomas: >=20 > Let me add my 2 cents to Linda's comment. The comment of >=20 > "I want to make my network big and flat because that gives me certain > advantages". >=20 > is arising again due to changes in the Data Center environment. Please > note > this is a specific target environment. >=20 > Please understand that general "ARP Scaling" is not our focus - but a > specific area of ARP scaling for this target environment with business > implications. >=20 > As to the constraints, we are examining the constraints on ARP that > must > stay for this specific target work and those which can be relaxed (for > this > specific target). >=20 > Linda is providing specific examples for this target environment. IP + > glue > protocols has always adapted to specific environments with tuning (for > example mobile). >=20 > We welcome comments based on this specific scope on this list. General > discussion about "general ARP" changes is not our focus. >=20 >=20 > Sue Hares >=20 > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Linda Dunbar > Sent: Thursday, January 20, 2011 11:15 AM > To: 'Thomas Narten'; 'Jari Arkko' > Cc: armd@ietf.org > Subject: Re: [armd] thoughts on the continuation of the ARMD work >=20 > Thomas, >=20 > ARP works fine when all the hosts within one subnet are confined to one > Aggregation switch (or Top of Rack switch) because all the broadcast > messages are confined. >=20 > When VM and VM migration is deployed in Data Centers, hosts in one > subnet > (VLAN) may start with being close together and gradually being > relocated to > various places as the result of continuous VM migration. >=20 > We are not talking about flat big network. Each subnet is not big, but > when > there are so many of them, ARP/ND broadcast messages will cause a lot > more > traffic traversing across Aggregation switches. One of our customers' > data > centers already have more than 4000 VLANs. >=20 > When VMs belonging to one subnet are spread across multiple TOR > switches, > all the ARP broadcast messages and ND multicast messages are sent to > all TOR > switches in the broadcast domain. This will cause TOR switch to refresh > its > FDB even for the MAC not used by its local hosts. Most likely, the > frequency > of ARP/ND by hosts is shorter then TOR FDB MAC aging time. That means > TOR > FDB will have all the MAC addresses even if most of them are not used > by > local hosts. >=20 > Linda Dunbar >=20 > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Thursday, January 20, 2011 8:40 AM > To: Jari Arkko > Cc: armd@ietf.org > Subject: Re: [armd] thoughts on the continuation of the ARMD work >=20 > The difficulty I have with this group is that it is based on the > premise is that ARP doesn't scale. Of course that is true. But it is > at some level meaningless. ARP works fine, so long as the subnet (or > link, using IPv6 terminology) doesn't get "too large". This has been > known for 20+ years. If you make your subnet too large and flat, you > will experience pain. >=20 > We are dealing with the classic "I want to make my network big and > flat because that gives me certain advantages". Yet there are > downsides to that. We will never make ARP "scale" as big as is > imaginable or as some people might want. Even if we *want* that, and > it would be *nice*. It would be nice to get a Free Lunch too, but that > doesn't happen in real life. >=20 > The constraints to "solving" the ARP scaling problem are enormous. We > can't change any protocols, or modify hosts, because it is pretty > clear that those sorts of changes will take too long to become widely > implemented and deployed to be useful. That leaves us with techniques > like Proxy ARP. Do we need a WG to tell us how to use Proxy ARP? I > would hope not... >=20 > Thomas >=20 > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd >=20 > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd >=20 > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd From smerchant@extremenetworks.com Fri Jan 21 13:35:42 2011 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 47AEB3A6AA6 for ; Fri, 21 Jan 2011 13:35:42 -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.001, 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 jM8pa15JFpmc for ; Fri, 21 Jan 2011 13:35:40 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by core3.amsl.com (Postfix) with ESMTP id CBBE03A6A51 for ; Fri, 21 Jan 2011 13:35:40 -0800 (PST) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Fri, 21 Jan 2011 13:38:27 -0800 From: Shehzad Merchant To: Anoop Ghanwani , Susan Hares , 'Linda Dunbar' , "'Thomas Narten'" , 'Jari Arkko' Date: Fri, 21 Jan 2011 13:33:54 -0800 Thread-Topic: [armd] thoughts on the continuation of the ARMD work Thread-Index: Acu4sAeDxXtIJkbcQmKIRzM7qlp1iQAC3h3AAA2lmfAALky9QAABi8nA Message-ID: <68529EF594C22B4EA60265702E2D49BEB6A55C38D3@USEXCHANGE.corp.extremenetworks.com> References: <4D2F823E.30804@piuha.net> <201101201439.p0KEdogU005235@cichlid.raleigh.ibm.com> <005501cbb8bd$2173ad70$630c7c0a@china.huawei.com> <001901cbb8f7$56bad9b0$04308d10$@com> <70C2EE1DF21B1245AD686FDC41D377C551F2972284@HQ1-EXCH02.corp.brocade.com> In-Reply-To: <70C2EE1DF21B1245AD686FDC41D377C551F2972284@HQ1-EXCH02.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "armd@ietf.org" Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 21 Jan 2011 21:35:42 -0000 Hi Anoop, I am in agreement around creating a working group. Also agree that the ability to decommission a server in one part of the DC = and bring up a new one in another part of the DC with the same IP address i= s a problem. However, we are definitely seeing that L2 domains are growing in size as th= ey start stretching across racks within a DC (driven in part by the need to= move VMs around within the DC) and in fact there even seems to be a lot of= interest in stretching them across DCs in different locations as well. As = such there definitely seems to be a trend where the L2 domains have more an= d more hosts within them which is directly exacerbating issues related to A= RPs and more generally broadcast/multicast processing. -Shehzad -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Ano= op Ghanwani Sent: Friday, January 21, 2011 12:50 PM To: Susan Hares; 'Linda Dunbar'; 'Thomas Narten'; 'Jari Arkko' Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work Thought I should also voice my support for the creation of a working group to document the problems and a mechanism to deal with them. Folks are already starting to implement various things and it would be nice to have interoperable, consistent solutions. And to address Thomas' concern, this is really not so much about making networks flatter, but rather about stretching an L2 domain across the data center, as opposed to keeping it confined to a single top-of-the-rack or aggregation switch. Put another way, the subnet size stays the same, say 256 hosts, but instead of having all 256 sitting under the same aggregation switch, we would now like to see them scattered across the data center. Network administrators have complained about this problem ("I can't decommission a malfunctioning server in one part of the network and put a new one in with the same IP address in a new location") even before the advent of server virtualization, but server virtualization with its mobility function has made this an even more compelling problem. Anoop > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Susan Hares > Sent: Thursday, January 20, 2011 3:11 PM > To: 'Linda Dunbar'; 'Thomas Narten'; 'Jari Arkko' > Cc: armd@ietf.org > Subject: Re: [armd] thoughts on the continuation of the ARMD work > > Thomas: > > Let me add my 2 cents to Linda's comment. The comment of > > "I want to make my network big and flat because that gives me certain > advantages". > > is arising again due to changes in the Data Center environment. Please > note > this is a specific target environment. > > Please understand that general "ARP Scaling" is not our focus - but a > specific area of ARP scaling for this target environment with business > implications. > > As to the constraints, we are examining the constraints on ARP that > must > stay for this specific target work and those which can be relaxed (for > this > specific target). > > Linda is providing specific examples for this target environment. IP + > glue > protocols has always adapted to specific environments with tuning (for > example mobile). > > We welcome comments based on this specific scope on this list. General > discussion about "general ARP" changes is not our focus. > > > Sue Hares > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Linda Dunbar > Sent: Thursday, January 20, 2011 11:15 AM > To: 'Thomas Narten'; 'Jari Arkko' > Cc: armd@ietf.org > Subject: Re: [armd] thoughts on the continuation of the ARMD work > > Thomas, > > ARP works fine when all the hosts within one subnet are confined to one > Aggregation switch (or Top of Rack switch) because all the broadcast > messages are confined. > > When VM and VM migration is deployed in Data Centers, hosts in one > subnet > (VLAN) may start with being close together and gradually being > relocated to > various places as the result of continuous VM migration. > > We are not talking about flat big network. Each subnet is not big, but > when > there are so many of them, ARP/ND broadcast messages will cause a lot > more > traffic traversing across Aggregation switches. One of our customers' > data > centers already have more than 4000 VLANs. > > When VMs belonging to one subnet are spread across multiple TOR > switches, > all the ARP broadcast messages and ND multicast messages are sent to > all TOR > switches in the broadcast domain. This will cause TOR switch to refresh > its > FDB even for the MAC not used by its local hosts. Most likely, the > frequency > of ARP/ND by hosts is shorter then TOR FDB MAC aging time. That means > TOR > FDB will have all the MAC addresses even if most of them are not used > by > local hosts. > > Linda Dunbar > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Thursday, January 20, 2011 8:40 AM > To: Jari Arkko > Cc: armd@ietf.org > Subject: Re: [armd] thoughts on the continuation of the ARMD work > > The difficulty I have with this group is that it is based on the > premise is that ARP doesn't scale. Of course that is true. But it is > at some level meaningless. ARP works fine, so long as the subnet (or > link, using IPv6 terminology) doesn't get "too large". This has been > known for 20+ years. If you make your subnet too large and flat, you > will experience pain. > > We are dealing with the classic "I want to make my network big and > flat because that gives me certain advantages". Yet there are > downsides to that. We will never make ARP "scale" as big as is > imaginable or as some people might want. Even if we *want* that, and > it would be *nice*. It would be nice to get a Free Lunch too, but that > doesn't happen in real life. > > The constraints to "solving" the ARP scaling problem are enormous. We > can't change any protocols, or modify hosts, because it is pretty > clear that those sorts of changes will take too long to become widely > implemented and deployed to be useful. That leaves us with techniques > like Proxy ARP. Do we need a WG to tell us how to use Proxy ARP? I > would hope not... > > Thomas > > _______________________________________________ > 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 > > _______________________________________________ > 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 DISCLAIMER: This e-mail and any attachments to it may contain confidential and propriet= ary material and is solely for the use of the intended recipient. Any revie= w, use, disclosure, distribution or copying of this transmittal is prohibit= ed except by or on behalf of the intended recipient. If you have received = this transmittal in error, please notify the sender and destroy this e-mail= and any attachments and all copies, whether electronic or printed. From narten@us.ibm.com Fri Jan 21 14:29:28 2011 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 F2ECB3A6831 for ; Fri, 21 Jan 2011 14:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.793 X-Spam-Level: X-Spam-Status: No, score=-105.793 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 iCXFtxHlb-kR for ; Fri, 21 Jan 2011 14:29:28 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id E3D753A682A for ; Fri, 21 Jan 2011 14:29:27 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0LMRIc3013750 for ; Fri, 21 Jan 2011 15:27:18 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0LMWErO171160 for ; Fri, 21 Jan 2011 15:32:14 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0LMWDdl004899 for ; Fri, 21 Jan 2011 15:32:14 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-146-211.mts.ibm.com [9.76.146.211]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0LMWCEn004802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 15:32:13 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p0LMWBBY022341; Fri, 21 Jan 2011 17:32:11 -0500 Message-Id: <201101212232.p0LMWBBY022341@cichlid.raleigh.ibm.com> To: Linda Dunbar In-reply-to: <005501cbb8bd$2173ad70$630c7c0a@china.huawei.com> References: <4D2F823E.30804@piuha.net> <201101201439.p0KEdogU005235@cichlid.raleigh.ibm.com> <005501cbb8bd$2173ad70$630c7c0a@china.huawei.com> Comments: In-reply-to Linda Dunbar message dated "Thu, 20 Jan 2011 10:14:35 -0600." Date: Fri, 21 Jan 2011 17:32:11 -0500 From: Thomas Narten Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 21 Jan 2011 22:29:29 -0000 One difficulty I have had with this discussion is lack of clarity about the actual scenario. I agree (and understand) that the problem being described is more complicated than just saying we are starting with one big flat IP subnet. But there appear to be unstated assumptions about VLANS, where related hosts are clustered, etc. that are not fully explained. Linda Dunbar writes: > ARP works fine when all the hosts within one subnet are confined to one > Aggregation switch (or Top of Rack switch) because all the broadcast > messages are confined. Is the entire IP subnet confined to the same aggregation switch? Are they all in one VLAN where all members of a particular VLAN are confinded to one aggregation switch? Why is ARP traffic confined by default in the above case? There are some instated assumptions going on here (or at least, I don't know what they are.) > When VM and VM migration is deployed in Data Centers, hosts in one subnet > (VLAN) may start with being close together and gradually being relocated to > various places as the result of continuous VM migration. So is the VLAN containing the migrating machine "stretching" and no longer confined to the same Aggregation switch after the move? > We are not talking about flat big network. Each subnet is not big, but when > there are so many of them, ARP/ND broadcast messages will cause a lot more > traffic traversing across Aggregation switches. One of our customers' data > centers already have more than 4000 VLANs. Then isn't your problem that you simply have too many nodes in a single broadcast domain. ARP isn't the root problem. The scaling problem is really related to size of the L2 broadcast domain, and the number of VLANs and hosts on that one L2 broadcast domain. Right? > When VMs belonging to one subnet are spread across multiple TOR > switches, all the ARP broadcast messages and ND multicast messages > are sent to all TOR switches in the broadcast domain. Here again there are some unstated assumptions about TOR racks, and how IP subnets (and/or VLANs)are spread across them. I think it would help explain the real problem to also describe (say) the VLAN structure before a move and after a move to show why ARP traffic is sent to only one TOR switch in one case, but sent to more broadly in other cases. My guess is that ARP is the straw that breaks the proverbial camel's back in the datacenter configuration where this is a problem. But ARP per se, is not the problem. Thomas > This will cause TOR switch to refresh its FDB even for the MAC not > used by its local hosts. Most likely, the frequency of ARP/ND by > hosts is shorter then TOR FDB MAC aging time. That means TOR FDB > will have all the MAC addresses even if most of them are not used by > local hosts. > Linda Dunbar > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Thursday, January 20, 2011 8:40 AM > To: Jari Arkko > Cc: armd@ietf.org > Subject: Re: [armd] thoughts on the continuation of the ARMD work > The difficulty I have with this group is that it is based on the > premise is that ARP doesn't scale. Of course that is true. But it is > at some level meaningless. ARP works fine, so long as the subnet (or > link, using IPv6 terminology) doesn't get "too large". This has been > known for 20+ years. If you make your subnet too large and flat, you > will experience pain. > We are dealing with the classic "I want to make my network big and > flat because that gives me certain advantages". Yet there are > downsides to that. We will never make ARP "scale" as big as is > imaginable or as some people might want. Even if we *want* that, and > it would be *nice*. It would be nice to get a Free Lunch too, but that > doesn't happen in real life. > The constraints to "solving" the ARP scaling problem are enormous. We > can't change any protocols, or modify hosts, because it is pretty > clear that those sorts of changes will take too long to become widely > implemented and deployed to be useful. That leaves us with techniques > like Proxy ARP. Do we need a WG to tell us how to use Proxy ARP? I > would hope not... > Thomas > _______________________________________________ > 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 anoop@brocade.com Sat Jan 22 11:42:56 2011 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 1E4773A69A2 for ; Sat, 22 Jan 2011 11:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnPJiiB++85V for ; Sat, 22 Jan 2011 11:42:54 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id BDB5C3A6945 for ; Sat, 22 Jan 2011 11:42:54 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p0MJf8jW028694; Sat, 22 Jan 2011 11:45:38 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id tym71geuv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 22 Jan 2011 11:45:38 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 22 Jan 2011 11:47:12 -0800 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Sat, 22 Jan 2011 11:45:37 -0800 From: Anoop Ghanwani To: Thomas Narten , Linda Dunbar Date: Sat, 22 Jan 2011 11:45:36 -0800 Thread-Topic: [armd] thoughts on the continuation of the ARMD work Thread-Index: Acu5uxBzIELr9RTtSduJRxAwiK2nWQAsGstp Message-ID: <70C2EE1DF21B1245AD686FDC41D377C551F2AAB05F@HQ1-EXCH02.corp.brocade.com> References: <4D2F823E.30804@piuha.net> <201101201439.p0KEdogU005235@cichlid.raleigh.ibm.com> <005501cbb8bd$2173ad70$630c7c0a@china.huawei.com>, <201101212232.p0LMWBBY022341@cichlid.raleigh.ibm.com> In-Reply-To: <201101212232.p0LMWBBY022341@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-22_07:2011-01-21, 2011-01-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1101220077 Cc: "armd@ietf.org" Subject: Re: [armd] thoughts on the continuation of the ARMD work 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, 22 Jan 2011 19:42:56 -0000 >>> Is the entire IP subnet confined to the same aggregation switch? Are they all in one VLAN where all members of a particular VLAN are confinded to one aggregation switch? >>> First off, for the most part VLAN =3D IP subnet. There are=20 some corner cases such as multinetting or the use of=20 private VLANs where this equality doesn't hold, but we can leave those out for this discussion. Today, all members of a VLAN and thus subnet, are typically confined to a single aggregation switch (typically a pair running VRRP for redundancy). An additional reason why people don't like to string VLANs across multiple aggregation switches all over the data center is because of problems they have had with STP such debugging loops due to misconfiguration of STP and the fact that STP limits the links on which traffic is sent to a tree (no ECMP). This is expected to change with the advent of technologies such as TRILL. In fact in many designs, the subnet termination is done even before the aggregation switch at the top of rack, so that STP can be completely done away with. >>> Why is ARP traffic confined by default in the above case? There are some instated assumptions going on here (or at least, I don't know what they are.) >>> ARP only gets within the subnet, so it only flows on links that need to get to members of the subnet. By putting members of the subnet in arbitrary locations, we now have ARP traffic going across backbone links. >>> So is the VLAN containing the migrating machine "stretching" and no longer confined to the same Aggregation switch after the move? >>> Correct. We want it to be able to move anywhere within the data center, or even across data centers. And we want to keep as much ARP traffic as we can off the backbone links. Anoop ________________________________________ From: armd-bounces@ietf.org [armd-bounces@ietf.org] On Behalf Of Thomas Nar= ten [narten@us.ibm.com] Sent: Friday, January 21, 2011 3:32 PM To: Linda Dunbar Cc: armd@ietf.org Subject: Re: [armd] thoughts on the continuation of the ARMD work One difficulty I have had with this discussion is lack of clarity about the actual scenario. I agree (and understand) that the problem being described is more complicated than just saying we are starting with one big flat IP subnet. But there appear to be unstated assumptions about VLANS, where related hosts are clustered, etc. that are not fully explained. Linda Dunbar writes: > ARP works fine when all the hosts within one subnet are confined to one > Aggregation switch (or Top of Rack switch) because all the broadcast > messages are confined. Is the entire IP subnet confined to the same aggregation switch? Are they all in one VLAN where all members of a particular VLAN are confinded to one aggregation switch? Why is ARP traffic confined by default in the above case? There are some instated assumptions going on here (or at least, I don't know what they are.) > When VM and VM migration is deployed in Data Centers, hosts in one subnet > (VLAN) may start with being close together and gradually being relocated = to > various places as the result of continuous VM migration. So is the VLAN containing the migrating machine "stretching" and no longer confined to the same Aggregation switch after the move? > We are not talking about flat big network. Each subnet is not big, but wh= en > there are so many of them, ARP/ND broadcast messages will cause a lot mor= e > traffic traversing across Aggregation switches. One of our customers' dat= a > centers already have more than 4000 VLANs. Then isn't your problem that you simply have too many nodes in a single broadcast domain. ARP isn't the root problem. The scaling problem is really related to size of the L2 broadcast domain, and the number of VLANs and hosts on that one L2 broadcast domain. Right? > When VMs belonging to one subnet are spread across multiple TOR > switches, all the ARP broadcast messages and ND multicast messages > are sent to all TOR switches in the broadcast domain. Here again there are some unstated assumptions about TOR racks, and how IP subnets (and/or VLANs)are spread across them. I think it would help explain the real problem to also describe (say) the VLAN structure before a move and after a move to show why ARP traffic is sent to only one TOR switch in one case, but sent to more broadly in other cases. My guess is that ARP is the straw that breaks the proverbial camel's back in the datacenter configuration where this is a problem. But ARP per se, is not the problem. Thomas > This will cause TOR switch to refresh its FDB even for the MAC not > used by its local hosts. Most likely, the frequency of ARP/ND by > hosts is shorter then TOR FDB MAC aging time. That means TOR FDB > will have all the MAC addresses even if most of them are not used by > local hosts. > Linda Dunbar > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Thursday, January 20, 2011 8:40 AM > To: Jari Arkko > Cc: armd@ietf.org > Subject: Re: [armd] thoughts on the continuation of the ARMD work > The difficulty I have with this group is that it is based on the > premise is that ARP doesn't scale. Of course that is true. But it is > at some level meaningless. ARP works fine, so long as the subnet (or > link, using IPv6 terminology) doesn't get "too large". This has been > known for 20+ years. If you make your subnet too large and flat, you > will experience pain. > We are dealing with the classic "I want to make my network big and > flat because that gives me certain advantages". Yet there are > downsides to that. We will never make ARP "scale" as big as is > imaginable or as some people might want. Even if we *want* that, and > it would be *nice*. It would be nice to get a Free Lunch too, but that > doesn't happen in real life. > The constraints to "solving" the ARP scaling problem are enormous. We > can't change any protocols, or modify hosts, because it is pretty > clear that those sorts of changes will take too long to become widely > implemented and deployed to be useful. That leaves us with techniques > like Proxy ARP. Do we need a WG to tell us how to use Proxy ARP? I > would hope not... > Thomas > _______________________________________________ > 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 _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From jari.arkko@piuha.net Wed Jan 26 23:23:06 2011 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 3E1473A6B02 for ; Wed, 26 Jan 2011 23:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, 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 M4qpv7tH-EfE for ; Wed, 26 Jan 2011 23:23:05 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id CD1E83A6B06 for ; Wed, 26 Jan 2011 23:23:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E18052CC2F; Thu, 27 Jan 2011 09:26:06 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H6lss4InAeI; Thu, 27 Jan 2011 09:26:06 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 3171D2CC2D; Thu, 27 Jan 2011 09:26:04 +0200 (EET) Message-ID: <4D411E0C.6010904@piuha.net> Date: Wed, 26 Jan 2011 23:26:04 -0800 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Linda Dunbar References: <00b501cbbddc$a0f0c6e0$e2d254a0$@com> In-Reply-To: <00b501cbbddc$a0f0c6e0$e2d254a0$@com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: 'Hares Susan' , armd@ietf.org Subject: Re: [armd] Updated ARMD Charter and Milestones X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 07:23:06 -0000 Linda, Thanks for suggesting text. I have a few comments on this. The main comment is that I do not think we are ready to create a working group that actually develops the solutions. I would like to see the "document the scaling characteristics" stage successfully completed first before chartering any work on solutions. This is not to say that we can't do the work -- even in the schedule you outline in the milestones -- but at least I personally have some trouble committing to the solution part before I fully understand the current characteristics. So from my perspective I'd remove the solution milestones and text discussing that part of the work. I would also change the objectives as follows: (1）To document the scaling characteristics of ARP (IPv4) and ND (IPv6) with respect to increasing numbers of hosts in data centers, (2) to identify limitations of ARP and ND in such environments, (3) provide design recommendations intended to minimize issues associated with the identified limitations, and (4) to develop appropriate solutions to better support data centers with large number of hosts. => （1）To document the scaling characteristics of ARP (IPv4) and ND (IPv6) with respect to increasing numbers of hosts in data centers and (2) provide operational recommendations intended to minimize issues associated with the limits inherent in these characteristics. (Just my $0.02, of course, not wearing any hats at the moment.) Jari From narten@us.ibm.com Thu Jan 27 06:15:24 2011 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 20B0B3A687B for ; Thu, 27 Jan 2011 06:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.973 X-Spam-Level: X-Spam-Status: No, score=-105.973 tagged_above=-999 required=5 tests=[AWL=0.626, 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 at6xi3QQpMRf for ; Thu, 27 Jan 2011 06:15:23 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 4A31F3A6872 for ; Thu, 27 Jan 2011 06:15:23 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0RE9L6d015209 for ; Thu, 27 Jan 2011 09:09:21 -0500 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 871A14DE8042 for ; Thu, 27 Jan 2011 09:14:52 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0REINNc1601738 for ; Thu, 27 Jan 2011 09:18:24 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0REINPS007667 for ; Thu, 27 Jan 2011 09:18:23 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-48-47-248.mts.ibm.com [9.48.47.248]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0REIMJU007583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 09:18:23 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p0REIKfg017998; Thu, 27 Jan 2011 09:18:21 -0500 Message-Id: <201101271418.p0REIKfg017998@cichlid.raleigh.ibm.com> To: Jari Arkko In-reply-to: <4D411E0C.6010904@piuha.net> References: <00b501cbbddc$a0f0c6e0$e2d254a0$@com> <4D411E0C.6010904@piuha.net> Comments: In-reply-to Jari Arkko message dated "Wed, 26 Jan 2011 23:26:04 -0800." Date: Thu, 27 Jan 2011 09:18:20 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Cc: armd@ietf.org, 'Hares Susan' , Linda Dunbar Subject: Re: [armd] Updated ARMD Charter and Milestones X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:15:24 -0000 Based on the thread of the last week, I think it's misleading to restrict the charter of this work just to ARP and ND. It seems clear to me that this is also about VLANs, how they are typically deployed in a large data center, and how migration of servers from one part of the data center to another is changing communication assumptions that have been true in the past (e.g., a single IP subnet no longer resides just within a single aggregation switch, but is stretching a VLAN across the data center in new ways). My point is, the focus on ARP and ND is too narrow. The overall problem stems from L2 practices that are more complex than just treating the entire data center as one big IP subnet. In fact, it is being treated as one big L2 broadcast domain, with VLANs overlaid on that domain in ways that are changing. As the pattern for how VLANs are deployed in practice, that impacts the traffic patterns across the data center. It is those changing patters that appear to be the root cause of the scaling problems being blamed on ARP. I also support chartering only the documentation of the problem at this time. Thomas From shares@huawei.com Wed Jan 26 23:25:40 2011 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 0EE783A6AFD for ; Wed, 26 Jan 2011 23:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.797 X-Spam-Level: X-Spam-Status: No, score=-105.797 tagged_above=-999 required=5 tests=[AWL=0.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 KKHrx987dwMq for ; Wed, 26 Jan 2011 23:25:39 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 41EA93A6B12 for ; Wed, 26 Jan 2011 23:25:39 -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 <0LFO004687FSCF@usaga02-in.huawei.com> for armd@ietf.org; Wed, 26 Jan 2011 23:28:40 -0800 (PST) Received: from H00901778 ([10.47.138.17]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFO00L6A7FOFX@usaga02-in.huawei.com> for armd@ietf.org; Wed, 26 Jan 2011 23:28:40 -0800 (PST) Date: Thu, 27 Jan 2011 02:28:38 -0500 From: Hares Susan In-reply-to: <4D411E0C.6010904@piuha.net> To: 'Jari Arkko' , 'Linda Dunbar' Message-id: <15F799A613264FB5A42A3EA342F7C687@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7BIT Thread-index: Acu984B02rdEpxAiQ1uic6Ys5CTUegAADkiA References: <00b501cbbddc$a0f0c6e0$e2d254a0$@com> <4D411E0C.6010904@piuha.net> X-Mailman-Approved-At: Thu, 27 Jan 2011 08:08:28 -0800 Cc: armd@ietf.org Subject: Re: [armd] Updated ARMD Charter and Milestones X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 07:25:40 -0000 Jari: Thank you for the feedback on the objectives. We'll wait and see what Ralph Droms has to say. Sue -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Thursday, January 27, 2011 2:26 AM To: Linda Dunbar Cc: armd@ietf.org; rdroms.ietf@gmail.com; 'Hares Susan' Subject: Re: Updated ARMD Charter and Milestones Linda, Thanks for suggesting text. I have a few comments on this. The main comment is that I do not think we are ready to create a working group that actually develops the solutions. I would like to see the "document the scaling characteristics" stage successfully completed first before chartering any work on solutions. This is not to say that we can't do the work -- even in the schedule you outline in the milestones -- but at least I personally have some trouble committing to the solution part before I fully understand the current characteristics. So from my perspective I'd remove the solution milestones and text discussing that part of the work. I would also change the objectives as follows: (1）To document the scaling characteristics of ARP (IPv4) and ND (IPv6) with respect to increasing numbers of hosts in data centers, (2) to identify limitations of ARP and ND in such environments, (3) provide design recommendations intended to minimize issues associated with the identified limitations, and (4) to develop appropriate solutions to better support data centers with large number of hosts. => （1）To document the scaling characteristics of ARP (IPv4) and ND (IPv6) with respect to increasing numbers of hosts in data centers and (2) provide operational recommendations intended to minimize issues associated with the limits inherent in these characteristics. (Just my $0.02, of course, not wearing any hats at the moment.) Jari From pfrejborg@gmail.com Mon Jan 31 10:16:42 2011 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 DCB593A6AD9 for ; Mon, 31 Jan 2011 10:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, 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 FZscG49Wm4Gv for ; Mon, 31 Jan 2011 10:16:42 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id AFF2E3A69A9 for ; Mon, 31 Jan 2011 10:16:41 -0800 (PST) Received: by ewy8 with SMTP id 8so2941288ewy.31 for ; Mon, 31 Jan 2011 10:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Y6IAUvddNWLsWiaAYvW35vIQ49jzjwBHOVZrrk4Ri1U=; b=perUaqdJoAMZWKpzHuaf/RaPIWAu+VFMF6KgYerX7jSrjluuFXkLzAPuAQ1AiBEpnQ YWRsqRuK7n7FOLasADUQvU9n0lP5CU8sP+p3s9lu5faciexhk9MqZtkfByV5P9oOOLZz NHrxUht/LaT49OtOMVhdIs7rJsbZTWk1u8lqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=koMjkW8n25JFuh4VVQH0DQomsgRIhY3KUUUII5Iu8ocTb0XIRfC8aqfhbefiKRFguB TljOP2Ocvobc0LdUDAG4wK/PbNRF1w+mSuDvB9ukJiKX7iXEDtTs4swoI+nEf8HI9EDq /pTiuUaad7REMNci5NDZLn9t2FoyP6gT0ciH0= MIME-Version: 1.0 Received: by 10.213.9.131 with SMTP id l3mr774550ebl.37.1296497995761; Mon, 31 Jan 2011 10:19:55 -0800 (PST) Received: by 10.213.106.6 with HTTP; Mon, 31 Jan 2011 10:19:55 -0800 (PST) Date: Mon, 31 Jan 2011 20:19:55 +0200 Message-ID: From: Patrick Frejborg To: armd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [armd] Data center issues 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, 31 Jan 2011 18:16:43 -0000 Hi all, I'm new to the list and I just read through the "Updated ARMD Charter and Milestones" thread. I do agree with Thomas Narten in his post on 27th of January, this is a much bigger problem than only ARP. It is also about VLAN scalability, how many MAC-addresses needs to be supported in the L2 domain, spanning-tree issues, failure domain etc Much of these challenges can today be solved by implementing VPLS, tomorrow they can be solved by TRILL/SPB - but a L2 broadcast domain is also IMHO a failure domain since a bridge floods all unknown packets out on all ports when a router only forward packets to known destinations. Thus I think the root cause to have large L2 domains is the TCP/IP stack itself - there is no session layer in the current stack. If the TCP/IP stack contained a session layer, by implementing a locator/identifier split, then the application could be moved from one server to another (physical or virtual, it doesn't matter) on the fly. Then we could design data center networks according to best practices, i.e. implement routing whenever you can and the failure domains would be much smaller - also ARP, VLAN, MAC scalability issues are solved. And with a session layer in the TCP/IP stack , the customer could move his applications from one cloud service provider to another cloud - over a routed network. The security nodes should not use IP addresses to verify the users/servers, instead the decoupled identifier should be used to grant/deny access to a resource. Examples of locator/identifier split architectures are Host Identity Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based Sockets (NBS). My 2 cents... Patrick From skh@ndzh.com Mon Jan 31 12:35:01 2011 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 728663A6C93 for ; Mon, 31 Jan 2011 12:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPti1ztooJBG for ; Mon, 31 Jan 2011 12:35:00 -0800 (PST) Received: from hickoryhill-consulting.com (63-208-161-194.digitalrealm.net [63.208.161.194]) by core3.amsl.com (Postfix) with ESMTP id 1F4123A6C92 for ; Mon, 31 Jan 2011 12:34:59 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=192.35.166.244; Received: from SKHPERSONALLT (unverified [192.35.166.244]) by hickoryhill-consulting.com (SurgeMail 4.2d4) with ESMTP id 2011944-1945496 for multiple; Mon, 31 Jan 2011 15:38:07 -0500 From: "Susan Hares" To: "'Patrick Frejborg'" , References: In-Reply-To: Date: Mon, 31 Jan 2011 15:38:10 -0500 Message-ID: <006501cbc186$c6bee9d0$543cbd70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvBc3iq9ATwusnzRZixV/uSWTOI9QADy9+Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'Ralph Droms' Subject: Re: [armd] Data center issues 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, 31 Jan 2011 20:35:01 -0000 Patrick: Yes, I agree that Data Center problem is bigger than just ARP/ND. However, to make progress on the ARP/ND portion we need to focus our work tightly. I agree that the problem needs the technologies of 100Gb Ethernet, IP/OTN or WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or new TCP or IPv6 options), session concepts and NM topologies to provide cross-layer optimization for data centers. I'm actually participating with IETF folks in all these areas on protocols or NM. Networks/DC are focused on expanding the L2 (see the presentation below: http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.na nog51-Schaumann.pdf) IETF WG do best by tackling one part of the total solution. We are staying tightly focused on the ARP/ND problem, and proposing a very tight working group. We are focused on collecting publishable ARP/ND statistics, getting specific requirements, creating models for discussion, and creating prototype that the community can access. We have demonstrated at our BOF in Beijing that there are many solutions to the ARP/ND issues. Linda and I have talked to many people providing DC technology or VM technology or DC services. However, the topic is so hot that people do not want to publish their statistics due to competitive pressures. We are investigating anonymous data from Research networks with similar DC topologies. If you want to suggest a WG for session layer, I will definitely attend that group. I'm already tracking the rest of this work, plus the IEEE VLAN group. If you disagree with the tight focus, please send your comments to our ADs (Ralph Droms and Jari Arkko). Sue -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Patrick Frejborg Sent: Monday, January 31, 2011 1:20 PM To: armd@ietf.org Subject: [armd] Data center issues Hi all, I'm new to the list and I just read through the "Updated ARMD Charter and Milestones" thread. I do agree with Thomas Narten in his post on 27th of January, this is a much bigger problem than only ARP. It is also about VLAN scalability, how many MAC-addresses needs to be supported in the L2 domain, spanning-tree issues, failure domain etc Much of these challenges can today be solved by implementing VPLS, tomorrow they can be solved by TRILL/SPB - but a L2 broadcast domain is also IMHO a failure domain since a bridge floods all unknown packets out on all ports when a router only forward packets to known destinations. Thus I think the root cause to have large L2 domains is the TCP/IP stack itself - there is no session layer in the current stack. If the TCP/IP stack contained a session layer, by implementing a locator/identifier split, then the application could be moved from one server to another (physical or virtual, it doesn't matter) on the fly. Then we could design data center networks according to best practices, i.e. implement routing whenever you can and the failure domains would be much smaller - also ARP, VLAN, MAC scalability issues are solved. And with a session layer in the TCP/IP stack , the customer could move his applications from one cloud service provider to another cloud - over a routed network. The security nodes should not use IP addresses to verify the users/servers, instead the decoupled identifier should be used to grant/deny access to a resource. Examples of locator/identifier split architectures are Host Identity Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based Sockets (NBS). My 2 cents... Patrick _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From skh@ndzh.com Mon Jan 31 12:44:17 2011 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 E77563A6C52 for ; Mon, 31 Jan 2011 12:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn6vJIqa17dm for ; Mon, 31 Jan 2011 12:44:14 -0800 (PST) Received: from hickoryhill-consulting.com (63-208-161-194.digitalrealm.net [63.208.161.194]) by core3.amsl.com (Postfix) with ESMTP id B6F3D3A6AEB for ; Mon, 31 Jan 2011 12:44:13 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=192.35.166.244; Received: from SKHPERSONALLT (unverified [192.35.166.244]) by hickoryhill-consulting.com (SurgeMail 4.2d4) with ESMTP id 2011979-1945496 for multiple; Mon, 31 Jan 2011 15:47:25 -0500 From: "Susan Hares" To: Date: Mon, 31 Jan 2011 15:47:29 -0500 Message-ID: <006b01cbc188$14002d20$3c008760$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01CBC15E.2B2A2520" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvBiBNbQMdox4lfSjKr3+vxf4Hd5Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'Ralph Droms' Subject: [armd] Presentation 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, 31 Jan 2011 20:44:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006C_01CBC15E.2B2A2520 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi all: I'm at NANOG, and saw a very interesting presentation by Yahoo on their need to replace L2 DSR with L3 DSR due to the problems with scaling L2 at the Data Center. http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.na nog51-Schaumann.pdf Take a look at the requirements that Yahoo implies in their talk. I think it is possible to have a revised-ARP + 802.1aq/SPB / TRILL + filters to allow the large DC without the NAT-like approach (DSCP/TOS bits). Sue ------=_NextPart_000_006C_01CBC15E.2B2A2520 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi all: =

 

I’m at NANOG, and saw a very interesting = presentation by Yahoo on their need to replace L2 DSR with L3 DSR due to = the problems with scaling L2 at the Data Center.

 

http://www.nanog.org/meetings/nanog51/pre= sentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf

=

 

Take a = look at the requirements that Yahoo implies in their talk. =

 

I think it is possible to have a revised-ARP + = 802.1aq/SPB / TRILL + filters to allow the large DC without the NAT-like = approach (DSCP/TOS bits).  

 

Sue =

------=_NextPart_000_006C_01CBC15E.2B2A2520--