From rees@umich.edu Wed Jul 6 07:22:51 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85B521F8619 for ; Wed, 6 Jul 2011 07:22:51 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMCNPkjSBNqJ for ; Wed, 6 Jul 2011 07:22:51 -0700 (PDT) Received: from merit-proxy01.merit.edu (merit-proxy01.merit.edu [207.75.116.193]) by ietfa.amsl.com (Postfix) with ESMTP id 4F14021F8606 for ; Wed, 6 Jul 2011 07:22:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by merit-proxy01.merit.edu (Postfix) with ESMTP id B260B2039854 for ; Wed, 6 Jul 2011 10:22:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at merit-proxy01.merit.edu Received: from merit-proxy01.merit.edu ([127.0.0.1]) by localhost (merit-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97B2uxuTd5b1 for ; Wed, 6 Jul 2011 10:22:49 -0400 (EDT) Received: from merit.edu (pietrapertosa.merit.edu [198.108.62.155]) by merit-proxy01.merit.edu (Postfix) with ESMTPSA id 30EBD2039853 for ; Wed, 6 Jul 2011 10:22:49 -0400 (EDT) Date: Wed, 6 Jul 2011 10:22:48 -0400 From: Jim Rees To: armd@ietf.org Message-ID: <20110706142248.GA19575@merit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [armd] [internet-drafts@ietf.org: New Version Notification for draft-karir-armd-statistics-00.txt] X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 14:22:52 -0000 I submitted a draft last week but did something wrong and the announcement didn't go to the list. Comments welcome. Draft is available here: https://datatracker.ietf.org/doc/draft-karir-armd-statistics/ ----- Forwarded message from internet-drafts@ietf.org ----- Date: Fri, 01 Jul 2011 13:12:20 -0700 From: internet-drafts@ietf.org Subject: New Version Notification for draft-karir-armd-statistics-00.txt To: rees@merit.edu Cc: mkarir@merit.edu, rees@merit.edu A new version of I-D, draft-karir-armd-statistics-00.txt has been successfully submitted by Jim Rees and posted to the IETF repository. Filename: draft-karir-armd-statistics Revision: 00 Title: Address Resolution Statistics Creation date: 2011-07-01 WG ID: Individual Submission Number of pages: 13 Abstract: As large scale data centers continue to grow with an ever-increasing number of virtual and physical servers there is a need to re- evaluate performance at the network edge. Performance is often critical for large scale data center scale applications and it is important to minimize any unnecessary latency or load in order to streamline the operation of services at such large scales. To extract maximum performance from these applications it is important to optimize and tune all the layers in the data center stack. One critical area that requires particular attention is the link-layer address resolution protocol that maps an IP address with the specific hardware address at the edge of the network. The goal of this document is to characterize this problem space in detail in order to better understand the scale of the problem as well as to identify particular scenarios where address resolution might have greater adverse impact on performance. The IETF Secretariat ----- End forwarded message ----- From rees@umich.edu Sun Jul 10 13:25:21 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591DD21F8767 for ; Sun, 10 Jul 2011 13:25:21 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iJf7Jjj9OsD for ; Sun, 10 Jul 2011 13:25:20 -0700 (PDT) Received: from merit-proxy02.merit.edu (merit-proxy02.merit.edu [207.75.116.194]) by ietfa.amsl.com (Postfix) with ESMTP id B76E721F868D for ; Sun, 10 Jul 2011 13:25:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by merit-proxy02.merit.edu (Postfix) with ESMTP id 2EAE02039861 for ; Sun, 10 Jul 2011 16:26:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at merit-proxy02.merit.edu Received: from merit-proxy02.merit.edu ([127.0.0.1]) by localhost (merit-proxy02.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBdyCmQ85ICW for ; Sun, 10 Jul 2011 16:26:27 -0400 (EDT) Received: from merit.edu (74-126-0-171.static.123.net [74.126.0.171]) by merit-proxy02.merit.edu (Postfix) with ESMTPSA id BD5122039854 for ; Sun, 10 Jul 2011 16:26:26 -0400 (EDT) Date: Sun, 10 Jul 2011 16:25:17 -0400 From: Jim Rees To: armd@ietf.org Message-ID: <20110710202517.GA7447@merit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [armd] [internet-drafts@ietf.org: New Version Notification for draft-karir-armd-statistics-01.txt] X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 20:25:21 -0000 I've just uploaded a new version of draft-karir-armd-statistics-01.txt. Comments welcome. The url is: http://www.ietf.org/id/draft-karir-armd-statistics-01.txt Apparently I should have submitted this as a WG draft rather than individual. Is there any way to change that now or should I submit it as a new draft? ----- Forwarded message from internet-drafts@ietf.org ----- Date: Sun, 10 Jul 2011 13:20:23 -0700 From: internet-drafts@ietf.org Subject: New Version Notification for draft-karir-armd-statistics-01.txt To: rees@merit.edu Cc: mkarir@merit.edu, rees@merit.edu A new version of I-D, draft-karir-armd-statistics-01.txt has been successfully submitted by Jim Rees and posted to the IETF repository. Filename: draft-karir-armd-statistics Revision: 01 Title: Address Resolution Statistics Creation date: 2011-07-10 WG ID: Individual Submission Number of pages: 13 Abstract: As large scale data centers continue to grow with an ever-increasing number of virtual and physical servers there is a need to re- evaluate performance at the network edge. Performance is often critical for large scale data center scale applications and it is important to minimize any unnecessary latency or load in order to streamline the operation of services at such large scales. To extract maximum performance from these applications it is important to optimize and tune all the layers in the data center stack. One critical area that requires particular attention is the link-layer address resolution protocol that maps an IP address with the specific hardware address at the edge of the network. The goal of this document is to characterize this problem space in detail in order to better understand the scale of the problem as well as to identify particular scenarios where address resolution might have greater adverse impact on performance. The IETF Secretariat ----- End forwarded message ----- From d3e3e3@gmail.com Sun Jul 10 17:53:35 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7731A21F86B9 for ; Sun, 10 Jul 2011 17:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.513 X-Spam-Level: X-Spam-Status: No, score=-104.513 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qD9-QuOWkVjN for ; Sun, 10 Jul 2011 17:53:34 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8B521F869E for ; Sun, 10 Jul 2011 17:53:34 -0700 (PDT) Received: by gyd5 with SMTP id 5so1594714gyd.31 for ; Sun, 10 Jul 2011 17:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=meVoBKd6WRdEZR1OIniHDik4TKS3yR703PjeRvCJoUA=; b=hHHUalCcBWA0h0JBnTM0/1f1tRpQKkieBQXMXTHkhcDboiOSRFox4QEQjbQuvRloyL Gwx2vBQ+8kBaa68Lh5brV34oH4P/i7lX8T7zoOB8NwVILZZL3N3CDtV+Mr6zMo3IjieS HDPoeB5fOyr0RigX6HVlSNLjzzcz4sFSR72xg= Received: by 10.150.210.1 with SMTP id i1mr1580239ybg.377.1310345614093; Sun, 10 Jul 2011 17:53:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.83.3 with HTTP; Sun, 10 Jul 2011 17:53:13 -0700 (PDT) In-Reply-To: <20110710202517.GA7447@merit.edu> References: <20110710202517.GA7447@merit.edu> From: Donald Eastlake Date: Sun, 10 Jul 2011 20:53:13 -0400 Message-ID: To: Jim Rees Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: armd@ietf.org Subject: Re: [armd] [internet-drafts@ietf.org: New Version Notification for draft-karir-armd-statistics-01.txt] X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 00:53:35 -0000 There really isn't anything to do but change the file name inside the draft and then re-submit it as draft-ietf-armd-statistics-00.txt. After its posted, if desired, one of the chairs or possibly you can send a message to action@ietf.org saying that draft-karir-armd-statistics is replaced by draft-ietf-armd-statistics-00. This later action just internally links the drafts in the draft database should eventually have been done even if you had submitted the -01 personal draft as a -00 WG draft. 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 Sun, Jul 10, 2011 at 4:25 PM, Jim Rees wrote: > I've just uploaded a new version of draft-karir-armd-statistics-01.txt. > Comments welcome. =A0The url is: > > http://www.ietf.org/id/draft-karir-armd-statistics-01.txt > > Apparently I should have submitted this as a WG draft rather than > individual. =A0Is there any way to change that now or should I submit it = as a > new draft? > > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Sun, 10 Jul 2011 13:20:23 -0700 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-karir-armd-statistics-01.txt > To: rees@merit.edu > Cc: mkarir@merit.edu, rees@merit.edu > > A new version of I-D, draft-karir-armd-statistics-01.txt has been success= fully submitted by Jim Rees and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-karir-armd-statistics > Revision: =A0 =A0 =A0 =A001 > Title: =A0 =A0 =A0 =A0 =A0 Address Resolution Statistics > Creation date: =A0 2011-07-10 > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission > Number of pages: 13 > > Abstract: > =A0 As large scale data centers continue to grow with an ever-increasing > =A0 number of virtual and physical servers there is a need to re- > =A0 evaluate performance at the network edge. =A0Performance is often > =A0 critical for large scale data center scale applications and it is > =A0 important to minimize any unnecessary latency or load in order to > =A0 streamline the operation of services at such large scales. =A0To > =A0 extract maximum performance from these applications it is important > =A0 to optimize and tune all the layers in the data center stack. =A0One > =A0 critical area that requires particular attention is the link-layer > =A0 address resolution protocol that maps an IP address with the > =A0 specific hardware address at the edge of the network. > > =A0 The goal of this document is to characterize this problem space in > =A0 detail in order to better understand the scale of the problem as > =A0 well as to identify particular scenarios where address resolution > =A0 might have greater adverse impact on performance. > > > > > > The IETF Secretariat > > ----- End forwarded message ----- > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > From bschlies@cisco.com Tue Jul 12 09:47:33 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160D521F8CED for ; Tue, 12 Jul 2011 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmn98+hJ8Ruq for ; Tue, 12 Jul 2011 09:47:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EE59721F8C9B for ; Tue, 12 Jul 2011 09:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=2890; q=dns/txt; s=iport; t=1310489249; x=1311698849; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=YWh31MMUkBgET7kNbNqjmjqwO8bv3fzgkXkFb4IkMwU=; b=QnM4YDzDeisJwaIq9V6ELbmO4LO1jY/MEAFMvNMdLVRoNLk09ft96Tp+ zHlgeQgv5ieGyLRlWUE72w+T0PaSXU6x8+IIHcDoqxH0S3sfkDMpFa5fe zqjZHDZCMZwAAplI2OBOtwV0m2sRTpCVq5FqStJfO72cCQ9RgshuwzLXj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMLAC96HE6tJXG//2dsb2JhbABTglOjd2UCcAeIeqJjgSKeHYY6BIdRiwuFCIdLhBY X-IronPort-AV: E=Sophos;i="4.65,521,1304294400"; d="scan'208,217";a="2212561" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jul 2011 16:47:28 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6CGlS6k009062 for ; Tue, 12 Jul 2011 16:47:28 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jul 2011 11:47:28 -0500 Received: from 171.70.247.53 ([171.70.247.53]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Jul 2011 16:47:27 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 12 Jul 2011 11:49:40 -0500 From: Benson Schliesser To: "armd@ietf.org" Message-ID: Thread-Topic: Call for Agenda Items Thread-Index: Acwy77034xRVNJbDFUWevZBlcnLHgQNw/PMU In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393316180_31869343" X-OriginalArrivalTime: 12 Jul 2011 16:47:28.0104 (UTC) FILETIME=[62656E80:01CC40B3] Subject: Re: [armd] Call for Agenda Items X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:47:33 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393316180_31869343 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Just a reminder: if you want time in the ARMD agenda at IETF81, let us know today. We have already received several requests, and will be publishing our agenda tomorrow. Cheers, -Benson & Linda On 6/24/11 11:24 PM, "Benson Schliesser" wrote: > The first-draft agenda for IETF 81 has been published and ARMD is currently > assigned a slot on Friday, Morning Session I 0900-1130; please see > https://datatracker.ietf.org/meeting/81/agenda.html for updates. > > If you would like time on the agenda, please send an email to the chairs > (armd-chairs@tools.ietf.org) or the ARMD mailing list. Agenda requests must > be received by 12-July-2011. > > Please note that the initial document (-00) cut-off is just over a week away, > on 04-July-2011. All ARMD presentations are expected to have an active draft; > exceptions to this rule will only be allowed in exceptional circumstances. > > -Benson & Linda --B_3393316180_31869343 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: Call for Agenda Items Just a reminder: if you want time in the ARMD agenda at IETF81, let us kno= w today.

We have already received several requests, and will be publishing our agend= a tomorrow.

Cheers,
-Benson & Linda


On 6/24/11 11:24 PM, "Benson Schliesser" <bschlies@cisco.com> wrote:

> The first-draft agenda for IETF 81 has been publ= ished and ARMD is currently
> assigned a slot on Friday, Morning Session I 0900-1130; please see > https://= datatracker.ietf.org/meeting/81/agenda.html for updates.
>
> If you would like time on the agenda, please send an email to the chai= rs
> (armd-chairs@tools.ietf.org) = or the ARMD mailing list.  Agenda requests must
> be received by 12-July-2011.
>
> Please note that the initial document (-00) cut-off is just over a wee= k away,
> on 04-July-2011.  All ARMD presentations are expected to have an = active draft;
> exceptions to this rule will only be allowed in exceptional circumstan= ces.
>
> -Benson & Linda
 --B_3393316180_31869343-- From bschlies@cisco.com Tue Jul 12 19:31:14 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869FE11E80AE for ; Tue, 12 Jul 2011 19:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1hwyA2E9S2g for ; Tue, 12 Jul 2011 19:31:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 61DC111E80A3 for ; Tue, 12 Jul 2011 19:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=7604; q=dns/txt; s=iport; t=1310524270; x=1311733870; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=zTZBU1WtJ/ns6ZoZE14P1Mqkn3SX430jT7SWJxx6nBQ=; b=kPhnpohdyNf84swrDMk9v1yAFuLAJyl627Z9zzQ5/FUSmLlvwfu2f/T1 VrVU/cmX8djnGfWTN91IB/U/DO3gQ1wGLV5KPg5yljqDogUv6ZD7pwoqg pGg23VEWkZWlFkNOOrVxhvHdcIcj7+AIxMvGEhtvFiEeeXU3NWeuWd07f E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIIAJECHU6tJV2a/2dsb2JhbABFDhCCQ6N7ZwJ3iHqkTJ4SgyKDGASHUYsPhQiHTINBVQ X-IronPort-AV: E=Sophos;i="4.65,523,1304294400"; d="scan'208,217";a="2377234" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 13 Jul 2011 02:31:10 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6D2V9ID028498; Wed, 13 Jul 2011 02:31:09 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jul 2011 21:31:09 -0500 Received: from 171.70.247.53 ([171.70.247.53]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.114]) with Microsoft Exchange Server HTTP-DAV ; Wed, 13 Jul 2011 02:31:09 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 12 Jul 2011 21:33:22 -0500 From: Benson Schliesser To: Jim Rees , Message-ID: Thread-Topic: [armd] [internet-drafts@ietf.org: New Version Notification for draft-karir-armd-statistics-01.txt] Thread-Index: AcxBBTvAmhwOTpxdnUygsGGvJGIuyQ== In-Reply-To: <20110710202517.GA7447@merit.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393351203_33980875" X-OriginalArrivalTime: 13 Jul 2011 02:31:09.0522 (UTC) FILETIME=[ECC9BB20:01CC4104] Subject: Re: [armd] [internet-drafts@ietf.org: New Version Notification for draft-karir-armd-statistics-01.txt] X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 02:31:14 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393351203_33980875 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 7/10/11 3:25 PM, "Jim Rees" wrote: > I've just uploaded a new version of draft-karir-armd-statistics-01.txt. > Comments welcome. The url is: > > http://www.ietf.org/id/draft-karir-armd-statistics-01.txt Thanks for working on this, Jim and Manish. I would like to reiterate the call for mailing-list discussion of this draft. > Apparently I should have submitted this as a WG draft rather than > individual. Is there any way to change that now or should I submit it as a > new draft? After you present this draft in Quebec, we can solicit WG consensus on making this a WG document. Cheers, -Benson > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Sun, 10 Jul 2011 13:20:23 -0700 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-karir-armd-statistics-01.txt > To: rees@merit.edu > Cc: mkarir@merit.edu, rees@merit.edu > > A new version of I-D, draft-karir-armd-statistics-01.txt has been successfully > submitted by Jim Rees and posted to the IETF repository. > > Filename: draft-karir-armd-statistics > Revision: 01 > Title: Address Resolution Statistics > Creation date: 2011-07-10 > WG ID: Individual Submission > Number of pages: 13 > > Abstract: > As large scale data centers continue to grow with an ever-increasing > number of virtual and physical servers there is a need to re- > evaluate performance at the network edge. Performance is often > critical for large scale data center scale applications and it is > important to minimize any unnecessary latency or load in order to > streamline the operation of services at such large scales. To > extract maximum performance from these applications it is important > to optimize and tune all the layers in the data center stack. One > critical area that requires particular attention is the link-layer > address resolution protocol that maps an IP address with the > specific hardware address at the edge of the network. > > The goal of this document is to characterize this problem space in > detail in order to better understand the scale of the problem as > well as to identify particular scenarios where address resolution > might have greater adverse impact on performance. > > > > > > The IETF Secretariat > > ----- End forwarded message ----- > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd --B_3393351203_33980875 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [armd] [internet-drafts@ietf.org: New Version Notification for d= raft-karir-armd-statistics-01.txt]
On 7/10/11 3:25 PM, "Jim Rees" <rees@= merit.edu> wrote:

> I've just uploaded a new version of draft-karir-= armd-statistics-01.txt.
> Comments welcome.  The url is:
>
> ht= tp://www.ietf.org/id/draft-karir-armd-statistics-01.txt

Thanks for working on this, Jim and Manish.

I would like to reiterate the call for mailing-list discussion of this draf= t.

> Apparently I should have submitted this as a WG = draft rather than
> individual.  Is there any way to change that now or should I subm= it it as a
> new draft?

After you present this draft in Quebec, we can solicit WG consensus on maki= ng this a WG document.

Cheers,
-Benson


> ----- Forwarded message from internet-drafts@ietf.org -----
>
> Date: Sun, 10 Jul 2011 13:20:23 -0700
> From: internet-drafts@ietf.org<= BR> > Subject: New Version Notification for draft-karir-armd-statistics-01.t= xt
> To: rees@merit.edu
> Cc: mkarir@merit.edu, rees@merit.edu
>
> A new version of I-D, draft-karir-armd-statistics-01.txt has been succ= essfully
> submitted by Jim Rees and posted to the IETF repository.
>
> Filename:  draft-karir-armd-statistics
> Revision:  01
> Title:   Address Resolution Statistics
> Creation date:  2011-07-10
> WG ID:   Individual Submission
> Number of pages: 13
>
> Abstract:
>    As large scale data centers continue to grow with an= ever-increasing
>    number of virtual and physical servers there is a ne= ed to re-
>    evaluate performance at the network edge.  Perf= ormance is often
>    critical for large scale data center scale applicati= ons and it is
>    important to minimize any unnecessary latency or loa= d in order to
>    streamline the operation of services at such large s= cales.  To
>    extract maximum performance from these applications = it is important
>    to optimize and tune all the layers in the data cent= er stack.  One
>    critical area that requires particular attention is = the link-layer
>    address resolution protocol that maps an IP address = with the
>    specific hardware address at the edge of the network= .
>
>    The goal of this document is to characterize this pr= oblem space in
>    detail in order to better understand the scale of th= e problem as
>    well as to identify particular scenarios where addre= ss resolution
>    might have greater adverse impact on performance. >
>
>            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =        
>
>
> The IETF Secretariat
>
> ----- End forwarded message -----
> _______________________________________________
> armd mailing list
> armd@ietf.org
> https://www.ietf.= org/mailman/listinfo/armd
 --B_3393351203_33980875-- From ning.so@verizonbusiness.com Thu Jul 14 11:48:42 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02ED21F8B2D for ; Thu, 14 Jul 2011 11:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGm-vec0FKrH for ; Thu, 14 Jul 2011 11:48:42 -0700 (PDT) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by ietfa.amsl.com (Postfix) with ESMTP id 077BE21F8B2F for ; Thu, 14 Jul 2011 11:48:42 -0700 (PDT) Received: from pdcismtp02.vzbi.com ([unknown] [166.40.77.70]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LOC00LDL6SHSV20@firewall.verizonbusiness.com> for armd@ietf.org; Thu, 14 Jul 2011 18:45:53 +0000 (GMT) Received: from pdcismtp02.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LOC00K2I6SH4300@pdcismtp02.vzbi.com> for armd@ietf.org; Thu, 14 Jul 2011 18:45:53 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([unknown] [153.39.68.166]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LOC00JD96SHY000@pdcismtp02.vzbi.com> for armd@ietf.org; Thu, 14 Jul 2011 18:45:53 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 18:45:53 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CC4256.41EE2A07" Date: Thu, 14 Jul 2011 18:45:52 +0000 Message-id: <14584D6EE26B314187A4F68BA206060007CA8D2E@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: AR Requirements for VDCS draft Thread-index: AcxCVdf7mdQeAsTVT2KWgWSk6UIclQ== From: "So, Ning" To: armd@ietf.org X-OriginalArrivalTime: 14 Jul 2011 18:45:53.0335 (UTC) FILETIME=[42452470:01CC4256] Subject: [armd] AR Requirements for VDCS draft X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 18:48:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4256.41EE2A07 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Just want to let you know that we uploaded an Address Resolution Requirements for VPN-oriented Data Center Services draft a couple of weeks ago. We welcome any and all comments and suggestions, and solution development corporations. Here is the link to the drafts. =20 http://datatracker.ietf.org/doc/draft-so-armd-vdcs-ar/ =20 http://datatracker.ietf.org/doc/draft-so-vdcs/ =20 =20 Best regards, =20 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =20 =20 ------_=_NextPart_001_01CC4256.41EE2A07 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Just want to = let you know that we uploaded an Address Resolution Requirements for = VPN-oriented Data Center Services draft a couple of weeks ago.  We = welcome any and all comments and suggestions, and solution development = corporations.   Here is the link to the = drafts.

 

http://da= tatracker.ietf.org/doc/draft-so-armd-vdcs-ar/

 

http://datatracke= r.ietf.org/doc/draft-so-vdcs/

 

 

Best = regards,

 

Ning = So

Verizon = Corporate Technology

(office) = 972-729-7905

(Cell) = 972-955-0914

 

 

------_=_NextPart_001_01CC4256.41EE2A07-- From bschlies@cisco.com Sat Jul 16 14:01:39 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB2621F8879 for ; Sat, 16 Jul 2011 14:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-4.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvvPsXnlI0F9 for ; Sat, 16 Jul 2011 14:01:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 848A421F8828 for ; Sat, 16 Jul 2011 14:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1301; q=dns/txt; s=iport; t=1310850098; x=1312059698; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=9KhkDHzCKtBCG/Ipug6AswyJlY1xXu4oVI6hIP5oYpY=; b=iZrzZXtXYDCfyS41EOXlZIGaMPP/arnMb+sRyjjgItidibbuNQKfIYz7 YxfaV87xiFq/M3MZVI+MkuugKcSNOblhQmp52Ooc9wcCKrUpIiGxZ4m/u YoSCBC5tAHhtm7gB0DveaX0FmPQEfXCMif5sn8gU6QZkAwVxbjK7oPFTP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwMAEP7IU6tJXG8/2dsb2JhbABSglOdI4cTbHAHqzKBI50ohjwEhyUvixKFCotp X-IronPort-AV: E=Sophos;i="4.67,214,1309737600"; d="scan'208,217";a="3621755" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jul 2011 21:01:37 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6GL1beF011616 for ; Sat, 16 Jul 2011 21:01:37 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Jul 2011 16:01:37 -0500 Received: from 10.21.119.230 ([10.21.119.230]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.114]) with Microsoft Exchange Server HTTP-DAV ; Sat, 16 Jul 2011 21:01:37 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Sat, 16 Jul 2011 13:26:17 -0500 From: Benson Schliesser To: "armd@ietf.org" Message-ID: Thread-Topic: ARMD agenda for IETF81 Thread-Index: AcxBq0bNuwq/eRnd+0iyKyLMKslf5QCOpMli In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393677034_39493163" X-OriginalArrivalTime: 16 Jul 2011 21:01:37.0260 (UTC) FILETIME=[8D40FAC0:01CC43FB] Subject: [armd] ARMD agenda for IETF81 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 21:01:39 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393677034_39493163 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The initial draft agenda for ARMD at IETF-81 has been uploaded. Please find it at http://www.ietf.org/proceedings/81/agenda/armd.html There may be a few updates prior to our meeting in Quebec. We=B9ll notify the list if/when a new version is posted. Cheers, -Benson & Linda --B_3393677034_39493163 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable ARMD agenda for IETF81
The initial draft agenda for ARMD at IETF-81 has been uploaded. Please find= it at http://= www.ietf.org/proceedings/81/agenda/armd.html

There may be a few updates prior to our meeting in Quebec. We’ll noti= fy the list if/when a new version is posted.

Cheers,
-Benson & Linda

 --B_3393677034_39493163-- From bschlies@cisco.com Sat Jul 16 14:01:41 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD2721F8906 for ; Sat, 16 Jul 2011 14:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=-3.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-KtoylyMTG5 for ; Sat, 16 Jul 2011 14:01:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8B35221F8828 for ; Sat, 16 Jul 2011 14:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=4878; q=dns/txt; s=iport; t=1310850099; x=1312059699; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=MqbIrLz2+C5J6oSxogd7bCYk3WNt5Pj6yqtHsvleEHY=; b=XBVD/KrkICeuDMT8ihnBJPE80G7dwT6Rfev0EcwXaE8CrevLX+R2RrT8 UGkvEjDCAc4O/+8xhGasC9/OaXLgwHpEMxoe4hnkKvqXdw/FJ2lfWDUpB iZ0sQVUOPxLEj/h14VdRAb0tww6A6niInYm6OJzFiidz5w66wisLmRI0+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEBAK37IU6tJXG//2dsb2JhbABMBoJTlV+HJQGHMWxwB6smgSOdKIM9gn8Eh1SLEoUKi2k X-IronPort-AV: E=Sophos;i="4.67,214,1309737600"; d="scan'208,217";a="3620387" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2011 21:01:38 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6GL1c1B020013 for ; Sat, 16 Jul 2011 21:01:38 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Jul 2011 16:01:38 -0500 Received: from 10.21.119.230 ([10.21.119.230]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.114]) with Microsoft Exchange Server HTTP-DAV ; Sat, 16 Jul 2011 21:01:37 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Sat, 16 Jul 2011 13:26:19 -0500 From: Benson Schliesser To: "armd@ietf.org" Message-ID: Thread-Topic: IETF 81 Audio Streaming Thread-Index: AcxDOZ3Hko0nXfGgQ5qTPZ2w2JeV0wAYmhgAABJ1P/Y= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393677035_39492263" X-OriginalArrivalTime: 16 Jul 2011 21:01:38.0081 (UTC) FILETIME=[8DBE4110:01CC43FB] Subject: [armd] FW: IETF 81 Audio Streaming X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 21:01:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393677035_39492263 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit ------ Forwarded Message Greetings! We're two weeks out from the beginning of meeting streaming. For those interested in monitoring sessions or participating remotely the following information may prove useful. - -Audio Streaming- All 8 parallel tracks at the IETF 81 meeting will be broadcast starting with the commencement of working group sessions on Monday, July 25, 2011 at 0900 EDT (GMT-4) and continue until Friday, July 29 at 1515 EDT. Because we have been asked several times in the past, note that if you wish to use the rooms that are being recorded for impromptu meeting during unscheduled sessions or lunch breaks that you can invite remote participants to tune in to the appropriate stream. Recording cannot be guaranteed for unscheduled sessions. Conversely, it should never be assumed that recording or observation is not occurring on open microphones, they are after all connected to the Internet. The links for streaming sources and the schedule are best retrieved from the IETF tools agenda, which as per Standard operating procedure will be located here: http://tools.ietf.org/agenda/81/ - -Jabber/XMPP- For information on IETF Jabber participation see: http://www.ietf.org/jabber/index.html or click on the Jabber links in the tools team agenda once you have a properly configured jabber/xmpp messaging client. - -Webex- Webex screen sharing participation is possible for a limited number of sessions. Consult with your working-group chair or the secretariat for more information. - -Ticketing- For prompt access to the meeting trouble desk, the email address is: mtd@ietf.org For streaming related issues please send email to ietf-streaming@verilan.com with info including the current time and affected streaming channel. Regards, Nick Kukich Network Engineer Verilan Event Services, Inc. 503.710.5115 --B_3393677035_39492263 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable FW: IETF 81 Audio Streaming
------ Forwarded Message

Greetings!

We're two weeks out from the beginning of meeting streaming. For those inte= rested in monitoring sessions or participating remotely the following inform= ation may prove useful.

- -Audio Streaming-

All 8 parallel tracks at the IETF 81 meeting will be broadcast starting wit= h the commencement of working group sessions on Monday, July 25, 2011 at 090= 0 EDT (GMT-4) and continue until Friday, July 29 at 1515 EDT.

Because we have been asked several times in the past, note that if you wish= to use the rooms that are being recorded for impromptu meeting during unsch= eduled sessions or lunch breaks that you can invite remote participants to t= une in to the appropriate stream. Recording cannot be guaranteed for unsched= uled sessions. Conversely, it should never be assumed that recording or obse= rvation is not occurring on open microphones, they are after all connected t= o the Internet.

The links for streaming sources and the schedule are best retrieved from th= e IETF tools agenda, which as per Standard operating procedure will be locat= ed here:

http://tools.ietf.org/agenda/81/=

- -Jabber/XMPP-

For information on IETF Jabber participation see:

http://www.ietf.org/jabber/= index.html  

or click on the Jabber links in the tools team agenda once you have a prope= rly configured jabber/xmpp messaging client.

- -Webex-

Webex screen sharing participation is possible for a limited number of sess= ions. Consult with your working-group chair or the secretariat for more info= rmation.

- -Ticketing-

For prompt access to the meeting trouble desk, the email address is:

mtd@ietf.org  

For streaming related issues please send email to ietf-streaming@verilan.com with info including the current t= ime and affected streaming channel.

Regards,

 
Nick Kukich

 

Network Engineer
Verilan Event Services, Inc.

503.710.5115
 
 --B_3393677035_39492263-- From liyizhou@huawei.com Thu Jul 28 08:13:36 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A0E21F8C88 for ; Thu, 28 Jul 2011 08:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.743 X-Spam-Level: X-Spam-Status: No, score=-5.743 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+QIPtqGa3QS for ; Thu, 28 Jul 2011 08:13:35 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C8C7821F873D for ; Thu, 28 Jul 2011 08:13:34 -0700 (PDT) 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 <0LP100D70UAKNJ@szxga04-in.huawei.com> for ARMD@ietf.org; Thu, 28 Jul 2011 23:13:32 +0800 (CST) Received: from szxrg02-dlp.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 <0LP1008TWUAKWO@szxga04-in.huawei.com> for ARMD@ietf.org; Thu, 28 Jul 2011 23:13:32 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACR34955; Thu, 28 Jul 2011 23:13:32 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Jul 2011 23:13:24 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Thu, 28 Jul 2011 23:13:31 +0800 Date: Thu, 28 Jul 2011 15:13:30 +0000 From: Liyizhou X-Originating-IP: [172.24.2.40] To: "narten@us.ibm.com" , "ARMD@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_4yo6G+PwdRPj6dDOXv9B6A)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: problem statement and scope of ARMD Thread-index: AQHMTTVMDz7OnwgJJEq6XEi8qgdoHg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [armd] problem statement and scope of ARMD X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:13:36 -0000 --Boundary_(ID_4yo6G+PwdRPj6dDOXv9B6A) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Thomas and folks, In the problem statement draft (draft-narten-armd-problem-statement ), it touches scalbility issue mostly. I think there are another set of problems regarding ARP/ND introduced by vm migration. (I use ARP to represent both ARP/ND in the following text) ARP was designed for address resolution, however in virtualized DC case, it is also used as an indication of completion of migration now. There are a number of vulnerabilities to use ARP as such indication (some details could be found in draft-liyz-armd-vm-migration-ps), 1. No ARP "forget". Blackhole issue. It is expected that flooded ARP message after migration would re-fresh all relevant MAC table entries to solve the blackhole issue. However it is not always true. (see bullet 2) 2. Unreliably delivery. With increasing scale of network, it is unavoidable that ARP message gets lost in congestion when it is used as indication of migration. It makes blackhole issue worse. At some location, frames are kept being sent to the blackhole until its MAC entry timeout. Simply sending *mutiple* ARPs may make it recover from message loss. However it causes scalibility issue worse. 3. Duplicate address detection (DAD). ARP was used for duplicate address detection (but there are different implementations on this). In migration case, there must be some suspension time of vm. Length of suspension time depends on how much changed memory contents need to be copied from old location to new location. During suspension period, normal DAD would not function effectively as VM is not able to respond to ARP message for DAD. Theoretically legally "stealing" of IP address by other host may happen. I hope ARMD addresses both ARP's scalability issue and ARP's vulnerability issue when it is used as an indication of vm migration. I would like to see ARMD cover both in its scope. Yizhou --Boundary_(ID_4yo6G+PwdRPj6dDOXv9B6A) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT

Hi Thomas and folks,

 

In the problem statement draft (draft-narten-armd-problem-statement ), it touches scalbility issue mostly. I think there are another set of problems regarding ARP/ND introduced by vm migration. (I use ARP to represent both ARP/ND in the following text)

 

 ARP was designed for address resolution, however in virtualized DC case, it is also used as an indication of completion of migration now. There are a number of vulnerabilities to use ARP as such indication (some details could be found in draft-liyz-armd-vm-migration-ps),

 

1. No ARP "forget". Blackhole issue. It is expected that flooded ARP message after migration would re-fresh all relevant MAC table entries to solve the blackhole issue. However it is not always true. (see bullet 2)

2. Unreliably delivery. With increasing scale of network, it is unavoidable that ARP message gets lost in congestion when it is used as indication of migration. It makes blackhole issue worse. At some location, frames are kept being sent to the blackhole until its MAC entry timeout. Simply sending *mutiple* ARPs may make it recover from message loss. However it causes scalibility issue worse.

3. Duplicate address detection (DAD). ARP was used for duplicate address detection (but there are different implementations on this). In migration case, there must be some suspension time of vm. Length of suspension time depends on how much changed memory contents need to be copied from old location to new location. During suspension period, normal DAD would not function effectively as VM is not able to respond to ARP message for DAD. Theoretically legally "stealing" of IP address by other host may happen.

 

I hope ARMD addresses both ARP's scalability issue and ARP's vulnerability issue when it is used as an indication of vm migration. I would like to see ARMD cover both in its scope.

 

Yizhou

--Boundary_(ID_4yo6G+PwdRPj6dDOXv9B6A)-- From bschlies@cisco.com Thu Jul 28 15:47:26 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98F711E80F5 for ; Thu, 28 Jul 2011 15:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.72 X-Spam-Level: X-Spam-Status: No, score=-4.72 tagged_above=-999 required=5 tests=[AWL=-2.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0KOmgvaDYRq for ; Thu, 28 Jul 2011 15:47:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB0A11E80F2 for ; Thu, 28 Jul 2011 15:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=4567; q=dns/txt; s=iport; t=1311893246; x=1313102846; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=pjWFzHdbT/yI4qfu89g+BbKTqS8tVwtiEIej1KtWhT8=; b=fBdPr+qqhtc9+MGx1Dwbg6XAC8Y9RatlJszfWv4PwbLSizOMOxnfYGqc 2Po8a4n8ecpT9/PIMWaFsBX9L6cixL/jYtlU/sDqLBlg/KG3Aowa95QAU sOfzJQ19yPfiIJKv8zzdUTdgsUqq0iszYpyXdVeXesjhrWGt+UG8AS7Mb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMvlMU6tJXG9/2dsb2JhbAA1AQEBAQIBFAErAwEaGwwFDgEJZlECBQEOCCenNneIfKQtnjyGQQSHWosghQ+Lcg X-IronPort-AV: E=Sophos;i="4.67,284,1309737600"; d="scan'208";a="7569857" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jul 2011 22:47:25 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6SMlPRJ026389; Thu, 28 Jul 2011 22:47:25 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 17:47:25 -0500 Received: from 10.21.120.233 ([10.21.120.233]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jul 2011 22:47:25 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 28 Jul 2011 17:49:56 -0500 From: Benson Schliesser To: Liyizhou , "ARMD@ietf.org" Message-ID: Thread-Topic: [armd] problem statement and scope of ARMD Thread-Index: AQHMTTVMDz7OnwgJJEq6XEi8qgdoHpUCVuz5 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Jul 2011 22:47:25.0486 (UTC) FILETIME=[520C64E0:01CC4D78] Cc: Thomas Narten Subject: Re: [armd] problem statement and scope of ARMD X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 22:47:27 -0000 Hi, Yizhou. On 7/28/11 10:13 AM, "Liyizhou" wrote: > In the problem statement draft (draft-narten-armd-problem-statement), it > touches scalbility issue mostly. I think there are another set of problems > regarding ARP/ND introduced by vm migration. (I use ARP to represent both > ARP/ND in the following text) Yes, the current Problem Statement draft is intentionally narrow. It can be expanded to include more scope - we need input, such as your input below, to discover what the WG wants. This will be discussed during our WG meeting on Friday, and I encourage you to provide input there in addition to your input on the list. > ARP was designed for address resolution, however in virtualized DC case, it > is also used as an indication of completion of migration now. > ... If ARP is used purely as an "indication of completion" then that may not be related to address resolution, and may not be in-scope for ARMD. (e.g. if the MAC address does not change during a migration, the gratuitous ARP is not happening for the benefit of address resolution) > 1. No ARP "forget". Blackhole issue. It is expected that flooded ARP message > after migration would re-fresh all relevant MAC table entries to solve the > blackhole issue. However it is not always true. (see bullet 2) Bridge learning is not in-scope for ARMD, and therefore e.g. a relatively small number of gratuitous ARP messages that are sent purely to update switch MAC forwarding tables are not something we should focus on. On the other hand, if VM migrations happen so frequently that gratuitous ARP messages overwhelm the network, then we should quantify that. I suspect that migration causes a small number of ARP messages (~1 message) compared to normal operation (many messages). Do you have a different view of this? Regardless, at the previous IETF meeting, we suggested that an "ephemeral" draft might be used to capture other related issues. Perhaps you would consider writing a contribution to such a document, briefly explaining this issue and/or providing pointers to references? > 2. Unreliably delivery. With increasing scale of network, it is unavoidable > that ARP message gets lost in congestion when it is used as indication of > migration. It makes blackhole issue worse. At some location, frames are kept > being sent to the blackhole until its MAC entry timeout. Simply sending > *mutiple* ARPs may make it recover from message loss. However it causes > scalibility issue worse. This sounds like something that the WG should consider for the Problem Statement. In essence, my understanding of the problem is that ARP lacks a reliability mechanism, and fails (without graceful indication) during network congestion. What I'd like to understand further is whether this is a more significant problem than e.g. the fact that everything can fail during congestion. I encourage further list discussion of this point. > 3. Duplicate address detection (DAD). ARP was used for duplicate address > detection (but there are different implementations on this). In migration > case, there must be some suspension time of vm. Length of suspension time > depends on how much changed memory contents need to be copied from old > location to new location. During suspension period, normal DAD would not > function effectively as VM is not able to respond to ARP message for DAD. > Theoretically legally "stealing" of IP address by other host may happen. This is also interesting, and may be included in the Problem Statement if there is WG interest to do so. The problem as I understand it, is that DAD assumes that an address is reserved only if a host is active and able to respond, and therefore any mechanism that temporarily disconnects a host creates this potential conflict. In other words, DAD doesn't accommodate the VM migration use-case unless the migration completes within a certain amount of time. Do you agree with this characterization? Do you believe that this problem applies to other situations, e.g. DHCP leases expiring during a VM migration, etc? > I hope ARMD addresses both ARP's scalability issue and ARP's vulnerability > issue when it is used as an indication of vm migration. I would like to see > ARMD cover both in its scope. This seems like a reasonable request, but I'd like to see more discussion of the issues - and I'd like to hear from other WG participants, whether they agree these should be in the Problem Statement. Cheers, -Benson From caesar@cs.illinois.edu Fri Jul 29 04:42:44 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB7F21F8B75 for ; Fri, 29 Jul 2011 04:42:44 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdGa3Ghd8nCm for ; Fri, 29 Jul 2011 04:42:43 -0700 (PDT) Received: from citesht3.cites.illinois.edu (citesht3.cites.illinois.edu [192.17.212.153]) by ietfa.amsl.com (Postfix) with ESMTP id 7992621F8B38 for ; Fri, 29 Jul 2011 04:42:43 -0700 (PDT) Received: from [192.168.1.2] (192.17.212.139) by smtp.illinois.edu (192.17.212.153) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 29 Jul 2011 06:42:42 -0500 Message-ID: <4E329CB2.8010908@cs.illinois.edu> Date: Fri, 29 Jul 2011 06:42:42 -0500 From: Matthew Caesar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Subject: [armd] For your consideration: SEATTLE X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 11:44:05 -0000 Hi, I've been watching this list with a lot of interest. We wanted to post for your consideration a protocol called SEATTLE we've been developing, which targets large improvements in scalability of layer-2 in the context of data centers/cloud computing by eliminating the need for broadcasts. We think SEATTLE addresses some of the goals in ARMD's charter. More details below, but we'd be quite interested to discuss/answer questions if there's interest. SEATTLE achieves the same configuration-free properties as Ethernet bridging yet scales to large networks. Unlike other proposals (e.g., TRILL, Rbridges, Viking, SmartBridges), SEATTLE completely eliminates the need for network-wide broadcasting, achieving data-plane control overheads that grow logarithmically with network size. SEATTLE is backwards-compatible with existing Ethernets, simplifying incremental deployment, and supporting existing Ethernet functions (e.g., VLANs and host bootstrapping). SEATTLE also supports more advanced (optional) features, such as the ability to search and look up services based on text strings, more flexible routing and more control over layer-2 routing policies, and the ability to anycast and load balance directly over named services. SEATTLE has two main features: Distributed in-network directory service: The switches collectively run a directory service that handles ARP and DHCP requests, as well as packets sent to unknown destination addresses. The directory service leverages consistent hashing and the link-state routing protocol to form a one-hop distributed hash table. The directory is a key-value store, where the hash of the key determines the switch(es) responsible for storing the information. For example, for ARP queries, the key is an IP address and the value includes the IP address and the host’s location. When an ingress switch cannot handle an ARP/DHCP request or a data packet directly, the switch computes the hash and directs the packet through the responsible intermediate switch. The intermediate switch can response to ARP and DHCP queries, and direct data packets onward to their egress switch while returning the destination host’s location to the ingress switch. Reactive caching and invalidation: To minimize the portion of traffic directed over longer paths, an ingress switch reactively caches the responses from the intermediate switch. For example, while an intermediate switch may handle an ARP query, the data packets typically flow directly along the shortest path. In addition, other hosts connected to the same ingress switch benefit from the cached information. However, the cached information becomes stale if a host moves to a new location. SEATTLE includes an efficient cache invalidation protocol that reactively updates the stale cache entries when a packet wrongly travels to the old egress switch. The first feature leads to good performance (by keeping traffic in the data plane, and avoiding broadcast) and self scaling (by having the directory service naturally scale with the size of the network), and the second ensures fast recovery after failures and migration. Our writeup on SEATTLE: http://www.cs.princeton.edu/~jrex/papers/seattle08.pdf presents more details on this protocol, our experiences designing and implementing a system prototype, and a performance evaluation of the protocol through simulations and deployment in a testbed. -- Matt From liyizhou@huawei.com Fri Jul 29 06:33:19 2011 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EC021F8BA2 for ; Fri, 29 Jul 2011 06:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.278 X-Spam-Level: X-Spam-Status: No, score=-4.278 tagged_above=-999 required=5 tests=[AWL=-1.179, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8sq2puPfVMg for ; Fri, 29 Jul 2011 06:33:18 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5B11F21F8B88 for ; Fri, 29 Jul 2011 06:33:18 -0700 (PDT) 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 <0LP3003FKKBGKR@szxga04-in.huawei.com> for ARMD@ietf.org; Fri, 29 Jul 2011 21:33:17 +0800 (CST) Received: from szxrg02-dlp.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 <0LP300F92KBGM0@szxga04-in.huawei.com> for ARMD@ietf.org; Fri, 29 Jul 2011 21:33:16 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACS15146; Fri, 29 Jul 2011 21:33:16 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 29 Jul 2011 21:33:05 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 21:33:16 +0800 Date: Fri, 29 Jul 2011 13:33:15 +0000 From: Liyizhou In-reply-to: X-Originating-IP: [172.24.2.40] To: Benson Schliesser , "ARMD@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=big5 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [armd] problem statement and scope of ARMD Thread-index: AQHMTTVMDz7OnwgJJEq6XEi8qgdoHpUCVuz5gABVVL8= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Thomas Narten Subject: [armd] =?big5?b?tarOYDogIHByb2JsZW0gc3RhdGVtZW50IGFuZCBzY29wZSBv?= =?big5?b?ZiBBUk1E?= X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 13:33:19 -0000 Hi Benson, Please see inlines with [yz] . On 7/28/11 10:13 AM, "Liyizhou" wrote: > In the problem statement draft (draft-narten-armd-problem-statement), it > touches scalbility issue mostly. I think there are another set of problems > regarding ARP/ND introduced by vm migration. (I use ARP to represent both > ARP/ND in the following text) Yes, the current Problem Statement draft is intentionally narrow. It can be expanded to include more scope - we need input, such as your input below, to discover what the WG wants. This will be discussed during our WG meeting on Friday, and I encourage you to provide input there in addition to your input on the list. [yz] Sure. > ARP was designed for address resolution, however in virtualized DC case, it > is also used as an indication of completion of migration now. > ... If ARP is used purely as an "indication of completion" then that may not be related to address resolution, and may not be in-scope for ARMD. (e.g. if the MAC address does not change during a migration, the gratuitous ARP is not happening for the benefit of address resolution) [yz] It is also used for updating the interface number of ARP table entry though IP/MAC should keep unchanged in migration. > 1. No ARP "forget". Blackhole issue. It is expected that flooded ARP message > after migration would re-fresh all relevant MAC table entries to solve the > blackhole issue. However it is not always true. (see bullet 2) Bridge learning is not in-scope for ARMD, and therefore e.g. a relatively small number of gratuitous ARP messages that are sent purely to update switch MAC forwarding tables are not something we should focus on. On the other hand, if VM migrations happen so frequently that gratuitous ARP messages overwhelm the network, then we should quantify that. I suspect that migration causes a small number of ARP messages (~1 message) compared to normal operation (many messages). Do you have a different view of this? [yz] I agree with it. Regardless, at the previous IETF meeting, we suggested that an "ephemeral" draft might be used to capture other related issues. Perhaps you would consider writing a contribution to such a document, briefly explaining this issue and/or providing pointers to references? > 2. Unreliably delivery. With increasing scale of network, it is unavoidable > that ARP message gets lost in congestion when it is used as indication of > migration. It makes blackhole issue worse. At some location, frames are kept > being sent to the blackhole until its MAC entry timeout. Simply sending > *mutiple* ARPs may make it recover from message loss. However it causes > scalibility issue worse. This sounds like something that the WG should consider for the Problem Statement. In essence, my understanding of the problem is that ARP lacks a reliability mechanism, and fails (without graceful indication) during network congestion. What I'd like to understand further is whether this is a more significant problem than e.g. the fact that everything can fail during congestion. [yz] I believe so. Normal congestion control may use packet re-transmission on timeout or reducing packet transmission rate mechanisms. Those do not solve the blackhole issue. Gratuitous ARP does not have reliable re-transmission mechenism. Limiting transmission rate by traffic sessions would be helpful to alleviate overall congestion. It may consequently increase the possibility of next gratuitous ARP to be succesfully delivered. However blackhole is not removed until receiving succesful gratuitous ARP or ARP reply sent by migrated vm. Its duration varies a lot. I encourage further list discussion of this point. > 3. Duplicate address detection (DAD). ARP was used for duplicate address > detection (but there are different implementations on this). In migration > case, there must be some suspension time of vm. Length of suspension time > depends on how much changed memory contents need to be copied from old > location to new location. During suspension period, normal DAD would not > function effectively as VM is not able to respond to ARP message for DAD. > Theoretically legally "stealing" of IP address by other host may happen. This is also interesting, and may be included in the Problem Statement if there is WG interest to do so. The problem as I understand it, is that DAD assumes that an address is reserved only if a host is active and able to respond, and therefore any mechanism that temporarily disconnects a host creates this potential conflict. In other words, DAD doesn't accommodate the VM migration use-case unless the migration completes within a certain amount of time. Do you agree with this characterization? [yz] Yes. Do you believe that this problem applies to other situations, e.g. DHCP leases expiring during a VM migration, etc? [yz] I do not know at the moment. Lease renew is expected to be requested by end host. It tries to renew the lease at 50% of lease time. If fails, try again (with broadcast) at 87.5% of lease. Not too sure what may happen if vm tries to renew the lease at suspension time. Will investigate further. > I hope ARMD addresses both ARP's scalability issue and ARP's vulnerability > issue when it is used as an indication of vm migration. I would like to see > ARMD cover both in its scope. This seems like a reasonable request, but I'd like to see more discussion of the issues - and I'd like to hear from other WG participants, whether they agree these should be in the Problem Statement. Cheers, -Benson