From dave.mcdysan@verizon.com Mon Apr 4 05:24:47 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 CEF9F3A69A4 for ; Mon, 4 Apr 2011 05:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FE6im9H5L2ge for ; Mon, 4 Apr 2011 05:24:40 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id A2F9328B23E for ; Mon, 4 Apr 2011 05:24:40 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p34CQ5N4009155 for ; Mon, 4 Apr 2011 08:26:22 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.63,296,1299456000"; d="scan'208,217";a="23588709" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 04 Apr 2011 12:26:05 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.173]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Mon, 4 Apr 2011 08:26:05 -0400 To: Benson Schliesser , Rahul Aggarwal Date: Mon, 4 Apr 2011 08:26:03 -0400 Thread-Topic: [armd] Layer 2 vs Layer 3 in data centers Thread-Index: Acvyw3dJDySvP9TGT+GwHgUzK1t10Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9BF2E641376Cdavemcdysanoneverizoncom_" MIME-Version: 1.0 Cc: "armd@ietf.org" Subject: Re: [armd] Layer 2 vs Layer 3 in data centers 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, 04 Apr 2011 12:24:47 -0000 --_000_C9BF2E641376Cdavemcdysanoneverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Benson, A possible clarification that you mentioned was that of "Ephemeral Drafts"= where all references (including those not specifically dealing with ARP/N= D) could be retained. I think what is being requested from operators is scenarios where a large f= lat L2 network is desired, but ARP and/or ND scaling prevents the operator = from doing this. It would be most helpful to not restrict the problem state= ment to just what are the statistics and behavior (since if there is truly = a problem some form of workaround would have been done), but ask the operat= ors to input what sorts of problems they see as best being solved by a larg= e flat L2 network that would use ARP and/or ND. As you point out, the WG is focused on ARP/ND, but the survey may in fact p= oint to forms of solution that are not modifications to or extensions of AR= P and ND. In my interpretation, the scope is recommendations to avoid or minimize iss= ues caused by (existing implementation problems that cannot be effectively = solved with) ARP/ND Thanks, Dave From: Benson Schliesser > Date: Thu, 31 Mar 2011 10:15:32 -0400 To: Rahul Aggarwal > Cc: "armd@ietf.org" > Subject: Re: [armd] Layer 2 vs Layer 3 in data centers Rahul - On 3/31/11 7:54 AM, "Rahul Aggarwal" wrote: > Your reading of the charter is fairly different from mine and also that o= f > other people as shown by comments made in the meeting yesterday. The > charter as written is not "narrow". For example from the charter: My reading of the charter is consistent with the direction of our ADs. If = the charter text needs to be updated, to make clear the IESG's intent, then= we can discuss that. > "Problem statement and review of current L2/L3 architectures" > > "Recommendations on data center L2/L3 architectures and > identification of opportunities for protocol development work" > > Why do you think the above statements in the charter are "narrow"? To be perfectly clear: I didn't write our current charter; I was asked to h= elp manage the WG after it was written. My personal view is that the above= statements, taken by themselves, are so broad as to be meaningless in the = context of a working group - they do not lead us toward a specific / action= able goal. Thus, they must be interpreted in the context of our objectives= : to define possible scale problems in L3-L2 address resolution. During yesterday's ARMD session I presented an overview of our charter and = problem statement scope. You can review the presentation slides at http://= tools.ietf.org/agenda/80/slides/armd-4.pdf. At this time, contributions to= the WG will be held against that standard. If you want to work on somethi= ng else, then ARMD is not the working group you=92re looking for. But I en= courage you to contribute within the WG scope. Cheers, -Benson --_000_C9BF2E641376Cdavemcdysanoneverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Benson,

=
A possible clarification that you mentioned was  that of "Ep= hemeral Drafts"  where all references (including those not specif= ically dealing with ARP/ND) could be retained.

I t= hink what is being requested from operators is scenarios where a large flat= L2 network is desired, but ARP and/or ND scaling prevents the operator fro= m doing this. It would be most helpful to not restrict the problem statemen= t to just what are the statistics and behavior (since if there is truly a p= roblem some form of workaround would have been done), but ask the operators= to input what sorts of problems they see as best being solved by a large f= lat L2 network that would use ARP and/or ND.

As yo= u point out, the WG is focused on ARP/ND, but the survey may in fact point = to forms of solution that are not modifications to or extensions of ARP and= ND. 

In my interpretation, the scope is recommendations to av= oid or minimize issues caused by (existing implementation problems that can= not be effectively solved with) ARP/ND

Than= ks,

Dave
  
From: Benson Schliesser <bschlies@cisco.com>
Date: Thu, 31 Mar 2011 10:15:32 -0400
To: Rahul Aggarwal <rahul@juniper.net>
Cc: "armd@ietf.org<= /a>" <armd@ietf.org>
Subject: Re: [armd] Layer 2 vs Layer = 3 in data centers

Rahul -

On 3/31/11 7:54 AM, "Rahul Aggarwal" <rahul@juniper.net> wrote:

> = Your reading of the charter is fairly different from mine and also that of =
> other people as shown by comments made in the meeting yesterday. The <= br> > charter as written is not "narrow". For example from the cha= rter:

My reading of the charter is consistent with the direction of our ADs. &nbs= p;If the charter text needs to be updated, to make clear the IESG's intent,= then we can discuss that.

> "Proble= m statement and review of current L2/L3 architectures"
>
> "Recommendations on data center L2/L3 architectures and
> identification of opportunities for protocol development work" >
> Why do you think the above statements in the charter are "narrow&= quot;?

To be perfectly clear: I didn't write our current charter; I was asked to h= elp manage the WG after it was written.  My personal view is that the = above statements, taken by themselves, are so broad as to be meaningless in= the context of a working group - they do not lead us toward a specific / a= ctionable goal.  Thus, they must be interpreted in the context of our = objectives: to define possible scale problems in L3-L2 address resolution.<= br>
During yesterday's ARMD session I presented an overview of our charter and = problem statement scope.  You can review the presentation slides at http://tools.ie= tf.org/agenda/80/slides/armd-4.pdf.  At this time, contributions t= o the WG will be held against that standard.  If you want to work on s= omething else, then ARMD is not the working group you=92re looking for. &nb= sp;But I encourage you to contribute within the WG scope.

Cheers,
-Benson
--_000_C9BF2E641376Cdavemcdysanoneverizoncom_-- From mark.pearson@hp.com Thu Apr 21 16:51:09 2011 Return-Path: X-Original-To: armd@ietfc.amsl.com Delivered-To: armd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ED950E06DD for ; Thu, 21 Apr 2011 16:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zF4MM-0jItl for ; Thu, 21 Apr 2011 16:51:09 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfc.amsl.com (Postfix) with ESMTP id 777CAE06E6 for ; Thu, 21 Apr 2011 16:51:09 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (g2w1953g.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 820C7381EF for ; Thu, 21 Apr 2011 23:51:08 +0000 (UTC) Received: from G4W1853.americas.hpqcorp.net (16.234.97.231) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 21 Apr 2011 23:47:32 +0000 Received: from GVW1095EXB.americas.hpqcorp.net ([16.234.97.239]) by G4W1853.americas.hpqcorp.net ([16.234.97.231]) with mapi; Thu, 21 Apr 2011 23:47:32 +0000 From: "Pearson, Mark A (HP Networking ATG)" To: "armd@ietf.org" Date: Thu, 21 Apr 2011 23:47:30 +0000 Thread-Topic: ARMD at NANOG ? Thread-Index: AcwAfnpxMvKdN6LsRaWmAx2ymQaKjw== Message-ID: <23335681082E004B9BC425D7FDCC94F0758B7D51F7@GVW1095EXB.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_23335681082E004B9BC425D7FDCC94F0758B7D51F7GVW1095EXBame_" MIME-Version: 1.0 Subject: [armd] ARMD at NANOG ? 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, 21 Apr 2011 23:51:10 -0000 --_000_23335681082E004B9BC425D7FDCC94F0758B7D51F7GVW1095EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is it confirmed that there will be an ARMD discussion or BOF at NANOG ? A= ny details? Mark. --_000_23335681082E004B9BC425D7FDCC94F0758B7D51F7GVW1095EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is it confirmed = that there will be an ARMD discussion or BOF at NANOG ?   Any det= ails?

 

Mark.

= --_000_23335681082E004B9BC425D7FDCC94F0758B7D51F7GVW1095EXBame_-- From bschlies@cisco.com Thu Apr 21 17:00:37 2011 Return-Path: X-Original-To: armd@ietfc.amsl.com Delivered-To: armd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 39AFDE065C for ; Thu, 21 Apr 2011 17:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8cMt0kFt-OT for ; Thu, 21 Apr 2011 17:00:36 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfc.amsl.com (Postfix) with ESMTP id 6F42EE06DD for ; Thu, 21 Apr 2011 17:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1597; q=dns/txt; s=iport; t=1303430436; x=1304640036; h=subject:references:from:content-transfer-encoding: in-reply-to:message-id:date:cc:to:mime-version; bh=AGZADdILlUmYZ0RAQnQYBqrxuCwIsYhYKIoFAmD3eHU=; b=ZxIoNZwInmKSPxp2AcQdd2XS6UzRXSsY5sAK1hDAii8KB5puYwqu6wFr J0TnB1DkCR1xEfAtG17ySPxyrVGC4/Kef/5XdXFjjgHXnAQpU/039MoD5 NVOIMiVENwiOfkbkpapvACn+m4MgSWKFw/kbSztmJzsB4fWK3PNtDk16E c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAPvDsE2tJXHA/2dsb2JhbACEUKAKfwJ3iHCeL4tckQGEeX0EhXSIN4QM X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208,217";a="231038768" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 22 Apr 2011 00:00:35 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p3M00ZWv008069; Fri, 22 Apr 2011 00:00:35 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 19:00:35 -0500 Received: from 72.163.62.205 ([72.163.62.205]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Apr 2011 00:00:35 +0000 References: <23335681082E004B9BC425D7FDCC94F0758B7D51F7@GVW1095EXB.americas.hpqcorp.net> From: "Benson Schliesser (bschlies)" thread-topic: [armd] ARMD at NANOG ? thread-index: AcwAgE4A5/VkPzD3Q1+htyjxM/vVOg== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="Apple-Mail-2739-853200105"; charset="iso-8859-1" In-Reply-To: <23335681082E004B9BC425D7FDCC94F0758B7D51F7@GVW1095EXB.americas.hpqcorp.net> Message-ID: Date: Thu, 21 Apr 2011 19:00:29 -0500 To: "Pearson, Mark A (HP Networking ATG)" MIME-Version: 1.0 (iPhone Mail 8C148) X-OriginalArrivalTime: 22 Apr 2011 00:00:35.0319 (UTC) FILETIME=[4E1C4070:01CC0080] Cc: armd@ietf.org Subject: Re: [armd] ARMD at NANOG ? 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, 22 Apr 2011 00:00:37 -0000 --Apple-Mail-2739-853200105 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 21, 2011, at 18:47, "Pearson, Mark A (HP Networking ATG)" wrote: > Is it confirmed that there will be an ARMD discussion or BOF at NANOG ? A= ny details? >=20 We have submitted a request to the NANOG PC and are awaiting their response.= (I believe they meet next Thursday.) For planning purposes, it is safe to a= ssume that we will meet at NANOG 52 but the meeting format and details are s= till TBD. We will provide more info as soon as possible. Cheers, -Benson --Apple-Mail-2739-853200105 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8

On Apr 21, 2011, at 18:47, "Pearson, Mark A (HP Networking ATG)" <mark.pearson@hp.com> wrote:

Is it confirmed that there will be an ARMD discussion or BOF at NANOG ?   Any details?


We have submitted a request to the NANOG PC and are awaiting their response. (I believe they meet next Thursday.) For planning purposes, it is safe to assume that we will meet at NANOG 52 but the meeting format and details are still TBD.

We will provide more info as soon as possible.

Cheers,
-Benson

--Apple-Mail-2739-853200105-- From bschlies@cisco.com Mon Apr 25 17:25:53 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 A7F09E0679 for ; Mon, 25 Apr 2011 17:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.871 X-Spam-Level: X-Spam-Status: No, score=-8.871 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_UNSUB18B=0.331] 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 z9SpxqeG4gBn for ; Mon, 25 Apr 2011 17:25:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 145AFE0663 for ; Mon, 25 Apr 2011 17:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=28155; q=dns/txt; s=iport; t=1303777545; x=1304987145; h=date:subject:from:to:message-id:mime-version; bh=cqPA0x3ihX46ZyrFpPcVslzwErsdyoyGSbX1pETNhJI=; b=LbWs+zPgL1G2oAH47R60tLET60udLqL01xNFeZu3z/Jtqe6slopnq9Cy o+kiWCunas1KTqUC/dSgJqb3YdJ5mbi3Rvse0G5V8NzBj6eq9/C204tBv 2itfgMARmZMTQO1SLIuUzrQIP3HKk46Kz2Ww9tuJ+7XN9KdQOC+7P8Gkh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALUQtk2tJXG9/2dsb2JhbACCYqF+XHepKp0HhXYEhXaIP4QP X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208,217";a="301796240" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2011 00:25:44 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3Q0Piuq021206 for ; Tue, 26 Apr 2011 00:25:44 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); Mon, 25 Apr 2011 19:25:43 -0500 Received: from 10.21.112.82 ([10.21.112.82]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Apr 2011 00:25:44 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 25 Apr 2011 19:26:25 -0500 From: Benson Schliesser To: "armd@ietf.org" Message-ID: Thread-Topic: Draft Minutes of IETF80 ARMD session Thread-Index: AcwDqJNxPTYZTGrxUkWrvwig87B7vA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386604386_8344652" X-OriginalArrivalTime: 26 Apr 2011 00:25:43.0955 (UTC) FILETIME=[7AFAD630:01CC03A8] Subject: [armd] Draft Minutes of IETF80 ARMD session 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, 26 Apr 2011 00:25:53 -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_3386604386_8344652 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Below are the minutes from our ARMD session in Prague (IETF80). Thanks to Shoaib Rao and Serge Manning for taking such detailed notes. Please respon= d to the list or directly to the co-chairs with any corrections. The notes will be uploaded to the IETF website by the end of this week. Thanks, -Benson & Linda ARMD Working Group - Meeting Minutes - IETF 80 Address Resolution for Massive numbers of hosts in the Data center (ARMD) Location: Barcelona/Berlin meeting room, Hilton Prague, Prague, CZ Time: 30-March-2011, 1510=AD1610 - Wednesday, Afternoon Session II Chairs: Benson Schliesser (bschlies@cisco.com) & Linda Dunbar (linda.dunbar@huawei.com) Agenda: * Meeting Administrivia * Discussion of Charter * Discussion of Problem Statement * Call for Investigation * Problem Statement Drafts Benson:=20 Sorry for starting the meeting late, Welcome to ARMD which is now a working group,=20 Read Note well, let's start the Charter discussion, as you all know there were couple of=20 BOFS talking about the cloud topics in general and they seemed to be too broad. We are WG now and have a charter the summary of which is displayed in the first 3=20 bullets of the presentation. The 1st one has already gotten controversial on the mailing list -- We are assuming that=20 this will be a massive layer 2 effort. We are not talking about why Rahul Agarwal: I do not agree with the interpretation of the charter that you have on the slides. The=20 way I read the charter is that the way people are building data centers today one of the=20 issues they have is data center mobility. One of the issues with the curren= t charter is=20 that it assumes VM mobility requires massive L2 network. We need to really grill into what VM mobility means and what are the reason= s for=20 building large layer 2 networks. For example the VM's might be in the same administrative domain and the administrative domain is in the same L2 network or in=20 the same VLAN. That kind of architecture is probably hard to change but if there are=20 other reasons we need to see if functions can be handed over to layer 3. So the charter and requirements of the WG needs to change to investigate where layer=20 2 hands off to layer 3 and the charter should also include definition of mobility. Benson: I do not disagree with the technical questions you are asking as whether yo= u build it=20 layer at 2 or layer 3 effects the scale but the question we have been chartered to=20 address is -- Is there an ARP/ND problem to resolve, what is the dimension of the=20 problem and at what stage the problem starts. If there is a problem than only=20 discussions around whether layer 3 mitigates that problem becomes relevant. Rahul: I am not necessarily saying that ARP is not a problem. All I am saying is how big a=20 problem it is and it changes how you partition your network based on layer = 2 and layer 3.=20 Getting your layer 2 and layer3 interaction right can be one way of scaling your network.=20 By limiting the discussion to layer 2 only we are making a mistake. Jari Arkko: I am not the responsible A.D. but I was involved in the discussions and the charter does=20 say that you need to document the scaling characteristics of ARP/ND and document the=20 operational characteristics that can reduce those issues. So it's not to find the smoking=20 gun but to determine if there is a problem or not. The interaction of layer 2 and layer 3=20 will come out in the operational practices part. Benson: We have to define what the problem is and that is not up for debate and in order to=20 manage the working group that is all we will focus on at this first meeting= . I am not=20 saying that these discussions are not relevant. All I am saying is that they are not=20 relevant to the current discussion. Igor: Defining the issue to be VM mobility is too restrictive. Address mobility and resolution in=20 VM migration environment is the real issue and we should not limit to just ARP/ND. If=20 the investigations reveals that ARP/ND are the culprits then that is fine. The problem=20 should be generalized to Address Resolution. There are lots of researches happening in=20 this area that we can utilize. Benson: We are not a research group. We are in the OPS area and are limited to things that are=20 being deployed today. As you pointed out there is a lot of work going on in this area but=20 that is out of scope for now. Linda: Agree with Igor that Address Resolution general issues should be studied by ARMD.=20 Thomas Narten: People are trying to do something here in terms of scaling data center. We need to=20 understand what they are saying, what the pain is and that should be the driving force=20 here. By following the charter very closely I worry that by just looking at ARP/ND we=20 are looking at the symptom of the problem without understanding the problem= . Benson: Personally I share your concern. But we have to narrow down the scope. Thomas: But I hear someone say cloud and someone say data center. We need to make sure=20 what we are talking about. Linda:=20 The Charter says data center. XXXX:=20 I also have different reading of the charter. If we can find an alternative to large layer2=20 networks than that is better than investing in understanding how large layer2 networks=20 work. XXXX: What is the acceptable solution space in this WG Benson: We are not looking at the solution space. We are looking at the problem, i= s there is an=20 operational problem and what are the dimensions of that problem. If there are gaps=20 than look at the solutions that are there and maybe recharter. XXXX: Is proposing new solutions using existing technology in scope Benson: No Jari Working on solutions whether they are part of new protocol or existing protocol is out=20 of scope for now. We are trying to understand what the problem is. Igor: You just said that we are looking for ways to solve address resolution problem but the=20 slides say ARP/ND which one is it. Are you looking at just ARP/ND? It shoul= d be Address=20 Resolution issues in Data Center. Benson: Anything that is deployed in a meaningful way Igor: What about 100K static entries? Benson: Sure. Please write a draft on how it scales. Erik Nordmark: We do not want sales pitch. However it will be useful if someone has experience doing=20 address resolution using other than ARP/ND say like chicken wire then it is useful to=20 write down their experience. XXXX: Why Erik Nordmark: What is more interesting right now is data and not a particular approach. Benson: Don't describe the solution, don't describe other reasons why you are interested in the=20 solution. Describe the impact of your particular approach. Vince: I frankly suggest that look at the charter page and look at goals and mile stones. All the=20 comments and recommendations can be directed to individual working groups o= r towards the deliverable's of the working group. Benson: There will be references to outside work that is out of scope. The chairs will create a=20 bucket draft to hold these documents. Benson: Let's talk about the problem statement. The context is massive layer 2. There are all kinds of reasons we might hav= e massive layer 2. We will just assume it is massive. We need to define the word massive. Does it means it spans large distances in one data center or different data centers. As a working group we need to achieve=20 consensus what massive means. Talk about what are ARP/ND problems. Does ARP/ND cause too=20 much bandwidth to be used or causes too much host processing. Our first milestone is to define this. Till now we have had discussion on the context but that does not answer the question. Jari: There are a different kinds of dimensions with different kinds of things we can scale for=20 example number of hosts, number of routers. We should not define what massive=20 means. Define the scaling characteristics of ARP/ND, The idea would be that if you keep=20 adding hosts when will you run into issues. May be some kind of an equation that=20 computes how much traffic gets generated as the network is expanded etc. Benson: That is what I meant to convey also Benson: We are proposing a new working group draft. Current drafts have good conten= t and we=20 may use them. We are looking for a new editor. Anyone interested please contact us. Ning So: I will volunteer for the editing job. Benson: There are operators in the room we need real data from them if we are going to be=20 realistic and successful. If you have data that you can share please bring that to the =20 mailing list. If you know someone who has data and want us to go make phone calls and=20 twist arms please let us know. Igor: Can you be a little be more specific what data Benson: Let's talk about that on the mailing list. It is a good question in by itself Thomas: It would be great to have data that we understand and shows what pain it is= . Another=20 way to look at things would be to categorize them in three buckets. For example an=20 environment where current solutions work fine, an environment where the current=20 solutions do not scale and another environment where current technology doe= s not=20 work because of restrictions imposed several years ago and relaxing them will solve the=20 issue. Based on conversations I have had, at some level the protocols work fine but they=20 stop working when taken to a certain level. Igor: The reason I asked for specifics of the data is because there are different data center=20 designs and each is optimized for different things. Benson: That will be good data to have Igor: So you want every possible data center design document Benson: This needs more discussion that we can have here today Ralph: It does not have to be a lot of data but data that helps us understand the issue Benson: Yeah. Once we concede there is a problem we can have discussion about solutions. Jari: Data which can tell us in which dimension the problem is will be very useful. Benson: Let's talk about it on the mailing list Rahul: What we need here is a problem statement and requirements documents written by the=20 operators.=20 Benson: Please bring any more discussions to the mailing list. let's start the presentations Linda: draft-dunbar-armd-problem-statement-01.txt Yizhou Li: draft-liyz-armd-vm-migration-ps-01 Randy Bush: As usual vendors telling operators what we experience. It would be nice to have=20 operators describe the real problems Benson: I agree with you, but no operator submitted drafts or asked for time Igor: Come and ask US Jabber - Ron Bonica: Do you want to have an interim meeting where operators present Randy Bush: Come to NANOG Jari: I have been concerned that we are trying to create technology pushed by Vendors and I=20 would like to hear from Operators and data center guys. Rahul Agarwal: Speaking as a vendor I agree with Randy and Igor that operators need to provide input=20 for the WG to do the work but Operators do not shut down the WG. XXXX: If we don't define the problem the working group will go away Dinesh: It seems to me that you said we will not talk about solutions but the previous=20 presentations have solutions Benson: I agree that all 3 presentations have out of scope material but these were the best and=20 since this is the first meeting we are lenient. Dave McDyson: Are future data centers in scope? Benson: No as we are an ops WG we only look at current deployed solutions. But if you have=20 ideas send them out. Igor: We need to define what a data center is as everyone's idea of what a data center is=20 widely different. Benson: Let's take this to the mailing list Cathy: Nanog would love to have a BOF on Address Resolution. Nanog has much higher operator experience. Benson I will contact you off line. Linda: draft-mackcrane-armd-ipv6-nd-scaling-00 (Author not present, Linda presente= d on his behalf) Igor: you have assumed one type of architecture. A lot of people don't use this design,=20 so the analysis won't apply. Contrary to your conclusion, IPv6 ND does have issues.=20 Chris Morrow: DC is designed for a particular workload. If you change the workload, it may look like the protocol but may be hardware problems. Benson: those are all valid issues. Igor: for most people a DC is the three tier design in text books. But reality is different.=20 Perhaps there are about 3 or 4 designs out there. Should we document those designs? Benson: yes, if you can help with that information on the mailing list. Meeting closes. --B_3386604386_8344652 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Draft Minutes of IETF80 ARMD session Below are the minutes from our ARMD session in Prague (IETF80).  Than= ks to Shoaib Rao and Serge Manning for taking such detailed notes.  Ple= ase respond to the list or directly to the co-chairs with any corrections. &= nbsp;The notes will be uploaded to the IETF website by the end of this week.=

Thanks,
-Benson & Linda


ARMD Working Group - Meeting Minutes - IETF 80

Address Resolution for Massive numbers of hosts in the Data center (ARMD) Location: Barcelona/Berlin meeting room, Hilton Prague, Prague, CZ
Time: 30-March-2011, 1510–1610 - Wednesday, Afternoon Session II
Chairs: Benson Schliesser (bschlies@cisco.com<= /a>) & Linda Dunbar (linda.dunbar@huaw= ei.com)

Agenda:
 * Meeting Administrivia
 * Discussion of Charter
 * Discussion of Problem Statement
 * Call for Investigation
 * Problem Statement Drafts

Benson:
Sorry for starting the meeting late, Welcome to ARMD which is now a working= group,
Read Note well, let's start the Charter discussion, as you all know there w= ere couple of
BOFS talking about the cloud topics in general and they seemed to be too br= oad.
We are WG now and have a charter the summary of which is displayed in the f= irst 3
bullets of the presentation.
The 1st one has already gotten controversial on the mailing list -- We are = assuming that
this will be a massive layer 2 effort. We are not talking about why

Rahul Agarwal:
I do not agree with the interpretation of the charter that you have on the = slides. The
way I read the charter is that the way people are building data centers tod= ay one of the
issues they have is data center mobility. One of the issues with the curren= t charter is
that it assumes VM mobility requires massive L2 network.
We need to really grill into what VM mobility means and what are the reason= s for
building large layer 2 networks. For example the VM's might be in the same =
administrative domain and the administrative domain is in the same L2 netwo= rk or in
the same VLAN. That kind of architecture is probably hard to change but if = there are
other reasons we need to see if functions can be handed over to layer 3. So the charter and requirements of the WG needs to change to investigate wh= ere layer
2 hands off to layer 3 and the charter should also include definition of mo= bility.

Benson:
I do not disagree with the technical questions you are asking as whether yo= u build it
layer at 2 or layer 3 effects the scale but the question we have been chart= ered to
address is -- Is there an ARP/ND problem to resolve, what is the dimension = of the
problem and at what stage the problem starts. If there is a problem than on= ly
discussions around whether layer 3 mitigates that problem becomes relevant.=

Rahul:
I am not necessarily saying that ARP is not a problem. All I am saying is h= ow big a
problem it is and it changes how you partition your network based on layer = 2 and layer 3.
Getting your layer 2 and layer3 interaction right can be one way of scaling= your network.
By limiting the discussion to layer 2 only we are making a mistake.

Jari Arkko:
I am not the responsible A.D. but I was involved in the discussions and the= charter does
say that you need to document the scaling characteristics of ARP/ND and doc= ument the
operational characteristics that can reduce those issues. So it's not to fi= nd the smoking
gun but to determine if there is a problem or not. The interaction of layer= 2 and layer 3
will come out in the operational practices part.

Benson:
We have to define what the problem is and that is not up for debate and in = order to
manage the working group that is all we will focus on at this first meeting= . I am not
saying that these discussions are not relevant.  All I am saying is th= at they are not
relevant to the current discussion.

Igor:
Defining the issue to be VM mobility is too restrictive. Address mobility a= nd resolution in
VM migration environment is the real issue and we should not limit to just = ARP/ND.  If
the investigations reveals that ARP/ND are the culprits then that is fine. = The problem
should be generalized to Address Resolution. There are lots of researches h= appening in
this area that we can utilize.

Benson:
We are not a research group. We are in the OPS area and are limited to thin= gs that are
being deployed today. As you pointed out there is a lot of work going on in= this area but
that is out of scope for now.

Linda:
Agree with Igor that Address Resolution general issues should be studied by= ARMD.

Thomas Narten:
People are trying to do something here in terms of scaling data center. We = need to
understand what they are saying, what the pain is and that should be the dr= iving force
here. By following the charter very closely  I worry that by just &nbs= p;looking at ARP/ND we
are looking at the symptom of the problem without understanding the problem= .

Benson:
Personally I share your concern. But we have to narrow down the scope.

Thomas:
But I hear someone say cloud and someone say data center. We need to make s= ure
what we are talking about.

Linda:
The Charter says data center.

XXXX:
I also have different reading of the charter. If we can find an alternative= to large  layer2
networks than that is better than investing in understanding  how larg= e layer2 networks
work.

XXXX:
What is the acceptable solution space in this WG

Benson:
We are not looking at the solution space. We are looking at the problem, &n= bsp;is there is an
operational  problem and what are the dimensions of that problem. If t= here are gaps
than look at the solutions that are there and maybe recharter.

XXXX:
Is proposing new solutions using existing technology in scope

Benson:
No

Jari
Working on solutions whether they are part of new protocol or existing prot= ocol is out
of scope for now. We are trying to understand what the problem is.

Igor:
You just said that we are looking for ways to solve address resolution prob= lem but the
slides say ARP/ND which one is it. Are you looking at just ARP/ND? It shoul= d be Address
Resolution issues in Data Center.

Benson:
Anything that is deployed in a meaningful way

Igor:
What about 100K static entries?

Benson:
Sure. Please write a draft on how it scales.

Erik Nordmark:
We do not want sales pitch. However it will be useful if someone has experi= ence doing
address resolution using other than ARP/ND say like chicken wire then it is= useful to
write down their experience.

XXXX:
Why

Erik Nordmark:
What is more interesting right now is data and not a particular approach.
Benson:
Don't describe the solution, don't describe other reasons why you are inter= ested in the
solution. Describe the impact of your particular approach.

Vince:
I frankly suggest that look at the charter page and look at goals and mile = stones. All the
comments and recommendations can be directed to individual working groups o= r
towards the deliverable's of the working group.

Benson:
There will be references to outside work that is out of scope. The chairs w= ill create a
bucket draft to hold these documents.

Benson:
Let's talk about the problem statement.
The context is massive layer 2. There are all kinds of reasons we might hav= e massive layer 2. We
will just assume it is massive. We need to define the word massive. Does it= means it spans large
distances in one data center or different data centers. As a working group = we need to achieve
consensus what massive means. Talk about what are ARP/ND problems. Does ARP= /ND cause too
much bandwidth to be used or causes too much host processing. Our first mil= estone is to define
this. Till now we have had discussion on the context but that does not answ= er the question.

Jari:
There are a different kinds of dimensions with different kinds of things we= can scale for
example number of hosts, number of routers. We should not define what massi= ve
means. Define the scaling characteristics of ARP/ND, The idea would be that= if you keep
adding hosts when will you run into issues. May be some kind of an equation= that
computes how much traffic gets generated as the network is expanded etc.
Benson:
That is what I meant to convey also

Benson:
We are proposing a new working group draft. Current drafts have good conten= t and we
may use them. We are looking for a new editor. Anyone interested please con= tact us.

Ning So:
I will volunteer for the editing job.

Benson:
There are operators in the room we need real data from them if we are going= to be
realistic and successful. If you have data that you can share please bring = that to the  
mailing list. If you know someone who has data and want us to go make phone= calls and
twist arms please let us know.

Igor:
Can you be a little be more specific what data

Benson:
Let's talk about that on the mailing list. It is a good question in by itse= lf

Thomas:
It would be great to have data that we understand and shows what pain it is= . Another
way to look at things would be to categorize them in three buckets. For exa= mple an
environment where current solutions work fine, an environment where the cur= rent
solutions do not scale and another environment where current technology doe= s not
work because of restrictions imposed several years ago and relaxing them wi= ll solve the
issue. Based on conversations I have had, at some level the protocols work = fine but they
stop working when taken to a certain level.

Igor:
The reason I asked for specifics of the data is because there are different= data center
designs and each is optimized for different things.

Benson:
That will be good data to have

Igor:
So you want every possible data center design document

Benson:
This needs more discussion that we can have here today

Ralph:
It does not have to be a lot of data but data that helps us understand the = issue

Benson:
Yeah. Once we concede there is a problem we can have discussion about solut= ions.

Jari:
Data which can tell us in which dimension the problem is will be very usefu= l.

Benson:
Let's talk about it on the mailing list

Rahul:
What we need here is a problem statement and requirements documents written= by the
operators.

Benson:
Please bring any more discussions to the mailing list. let's start the pres= entations

Linda:
draft-dunbar-armd-problem-statement-01.txt

Yizhou Li:
draft-liyz-armd-vm-migration-ps-01

Randy Bush:
As usual vendors telling operators what we experience. It would be nice to = have
operators describe the real problems

Benson:
I agree with you, but no operator submitted drafts or asked for time

Igor:
Come and ask US

Jabber - Ron Bonica:
Do you want to have an interim meeting where operators present

Randy Bush:
Come to NANOG

Jari:
I have been concerned that we are trying to create technology pushed by Ven= dors and I
would like to hear from Operators and data center guys.

Rahul Agarwal:
Speaking as a vendor I agree with Randy and Igor that operators need to pro= vide input
for the WG to do the work but Operators do not shut down the WG.

XXXX:
If we don't define the problem the working group will go away

Dinesh:
It seems to me that you said we will not talk about solutions but the previ= ous
presentations have solutions

Benson:
I agree that all 3 presentations have out of scope material but these were = the best and
since this is the first meeting we are lenient.

Dave McDyson:
Are future data centers in scope?

Benson:
No as we are an ops WG we only look at current deployed solutions. But if y= ou have
ideas send them out.

Igor:
We need to define what a data center is as everyone's idea of what a data c= enter is
widely different.

Benson:
Let's take this to the mailing list

Cathy:
Nanog would love to have a BOF on Address Resolution. Nanog has much higher=
operator experience.

Benson
I will contact you off line.

Linda:
draft-mackcrane-armd-ipv6-nd-scaling-00 (Author not present, Linda presente= d on his behalf)

Igor:
you have assumed one type of architecture. A lot of people don't use this d= esign,
so the analysis won't apply. Contrary to your conclusion, IPv6 ND does have= issues.

Chris Morrow:
DC is designed for a particular workload. If you change the workload, it may look like the protocol but may be hardware problems.

Benson:
those are all valid issues.

Igor:
for most people a DC is the three tier design in text books. But reality is= different.
Perhaps there are about 3 or 4 designs out there. Should we document those = designs?

Benson:
yes, if you can help with that information on the mailing list.

Meeting closes.

--B_3386604386_8344652-- From dino@cisco.com Mon Apr 25 17:29:31 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 CA8F2E0663 for ; Mon, 25 Apr 2011 17:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 034bMrcNOoDf for ; Mon, 25 Apr 2011 17:29:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 54FB6E062A for ; Mon, 25 Apr 2011 17:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=14504; q=dns/txt; s=iport; t=1303777770; x=1304987370; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=JH7+wblh3SQpnqbGm24REEulrpZDwWLYB9EVIQajsL4=; b=lD9/SIGeWKhZZ9slnjHkvheyqJKWy1Rdml0nP64VuKJYBPPkUjaVkbON VQg2lwvduoP7mDBXNgOON8+FCZSUHf7pUWuk0UP6h/18TLcwAdOZ7VaOE mczuONljcEVwCHh2BB2T7GzUS/9gu472HMCg4uPz0Js5G7j/G56xJaXh4 g=; X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208";a="686897518" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2011 00:29:30 +0000 Received: from [192.168.1.4] (sjc-vpn2-487.cisco.com [10.21.113.231]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3Q0TTUU006576; Tue, 26 Apr 2011 00:29:30 GMT Message-Id: From: Dino Farinacci To: Benson Schliesser In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 25 Apr 2011 17:29:30 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "armd@ietf.org" Subject: Re: [armd] Draft Minutes of IETF80 ARMD session 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, 26 Apr 2011 00:29:31 -0000 I think you missed a very important point that Randy made. This effort should be run by operators and not vendors. There is a Randy reference below but it isn't quite on target. He did =20= say below but he also said above. Dino On Apr 25, 2011, at 5:26 PM, Benson Schliesser wrote: > Below are the minutes from our ARMD session in Prague (IETF80). =20 > Thanks to Shoaib Rao and Serge Manning for taking such detailed =20 > notes. Please respond to the list or directly to the co-chairs with =20= > any corrections. The notes will be uploaded to the IETF website by =20= > the end of this week. > > Thanks, > -Benson & Linda > > > ARMD Working Group - Meeting Minutes - IETF 80 > > Address Resolution for Massive numbers of hosts in the Data center =20 > (ARMD) > Location: Barcelona/Berlin meeting room, Hilton Prague, Prague, CZ > Time: 30-March-2011, 1510=961610 - Wednesday, Afternoon Session II > Chairs: Benson Schliesser (bschlies@cisco.com) & Linda Dunbar = (linda.dunbar@huawei.com=20 > ) > > Agenda: > * Meeting Administrivia > * Discussion of Charter > * Discussion of Problem Statement > * Call for Investigation > * Problem Statement Drafts > > Benson: > Sorry for starting the meeting late, Welcome to ARMD which is now a =20= > working group, > Read Note well, let's start the Charter discussion, as you all know =20= > there were couple of > BOFS talking about the cloud topics in general and they seemed to be =20= > too broad. > We are WG now and have a charter the summary of which is displayed =20 > in the first 3 > bullets of the presentation. > The 1st one has already gotten controversial on the mailing list -- =20= > We are assuming that > this will be a massive layer 2 effort. We are not talking about why > > Rahul Agarwal: > I do not agree with the interpretation of the charter that you have =20= > on the slides. The > way I read the charter is that the way people are building data =20 > centers today one of the > issues they have is data center mobility. One of the issues with the =20= > current charter is > that it assumes VM mobility requires massive L2 network. > We need to really grill into what VM mobility means and what are the =20= > reasons for > building large layer 2 networks. For example the VM's might be in =20 > the same > administrative domain and the administrative domain is in the same =20 > L2 network or in > the same VLAN. That kind of architecture is probably hard to change =20= > but if there are > other reasons we need to see if functions can be handed over to =20 > layer 3. > So the charter and requirements of the WG needs to change to =20 > investigate where layer > 2 hands off to layer 3 and the charter should also include =20 > definition of mobility. > > Benson: > I do not disagree with the technical questions you are asking as =20 > whether you build it > layer at 2 or layer 3 effects the scale but the question we have =20 > been chartered to > address is -- Is there an ARP/ND problem to resolve, what is the =20 > dimension of the > problem and at what stage the problem starts. If there is a problem =20= > than only > discussions around whether layer 3 mitigates that problem becomes =20 > relevant. > > Rahul: > I am not necessarily saying that ARP is not a problem. All I am =20 > saying is how big a > problem it is and it changes how you partition your network based on =20= > layer 2 and layer 3. > Getting your layer 2 and layer3 interaction right can be one way of =20= > scaling your network. > By limiting the discussion to layer 2 only we are making a mistake. > > Jari Arkko: > I am not the responsible A.D. but I was involved in the discussions =20= > and the charter does > say that you need to document the scaling characteristics of ARP/ND =20= > and document the > operational characteristics that can reduce those issues. So it's =20 > not to find the smoking > gun but to determine if there is a problem or not. The interaction =20 > of layer 2 and layer 3 > will come out in the operational practices part. > > Benson: > We have to define what the problem is and that is not up for debate =20= > and in order to > manage the working group that is all we will focus on at this first =20= > meeting. I am not > saying that these discussions are not relevant. All I am saying is =20= > that they are not > relevant to the current discussion. > > Igor: > Defining the issue to be VM mobility is too restrictive. Address =20 > mobility and resolution in > VM migration environment is the real issue and we should not limit =20 > to just ARP/ND. If > the investigations reveals that ARP/ND are the culprits then that is =20= > fine. The problem > should be generalized to Address Resolution. There are lots of =20 > researches happening in > this area that we can utilize. > > Benson: > We are not a research group. We are in the OPS area and are limited =20= > to things that are > being deployed today. As you pointed out there is a lot of work =20 > going on in this area but > that is out of scope for now. > > Linda: > Agree with Igor that Address Resolution general issues should be =20 > studied by ARMD. > > Thomas Narten: > People are trying to do something here in terms of scaling data =20 > center. We need to > understand what they are saying, what the pain is and that should be =20= > the driving force > here. By following the charter very closely I worry that by just =20 > looking at ARP/ND we > are looking at the symptom of the problem without understanding the =20= > problem. > > Benson: > Personally I share your concern. But we have to narrow down the scope. > > Thomas: > But I hear someone say cloud and someone say data center. We need to =20= > make sure > what we are talking about. > > Linda: > The Charter says data center. > > XXXX: > I also have different reading of the charter. If we can find an =20 > alternative to large layer2 > networks than that is better than investing in understanding how =20 > large layer2 networks > work. > > XXXX: > What is the acceptable solution space in this WG > > Benson: > We are not looking at the solution space. We are looking at the =20 > problem, is there is an > operational problem and what are the dimensions of that problem. If =20= > there are gaps > than look at the solutions that are there and maybe recharter. > > XXXX: > Is proposing new solutions using existing technology in scope > > Benson: > No > > Jari > Working on solutions whether they are part of new protocol or =20 > existing protocol is out > of scope for now. We are trying to understand what the problem is. > > Igor: > You just said that we are looking for ways to solve address =20 > resolution problem but the > slides say ARP/ND which one is it. Are you looking at just ARP/ND? =20 > It should be Address > Resolution issues in Data Center. > > Benson: > Anything that is deployed in a meaningful way > > Igor: > What about 100K static entries? > > Benson: > Sure. Please write a draft on how it scales. > > Erik Nordmark: > We do not want sales pitch. However it will be useful if someone has =20= > experience doing > address resolution using other than ARP/ND say like chicken wire =20 > then it is useful to > write down their experience. > > XXXX: > Why > > Erik Nordmark: > What is more interesting right now is data and not a particular =20 > approach. > > Benson: > Don't describe the solution, don't describe other reasons why you =20 > are interested in the > solution. Describe the impact of your particular approach. > > Vince: > I frankly suggest that look at the charter page and look at goals =20 > and mile stones. All the > comments and recommendations can be directed to individual working =20 > groups or > towards the deliverable's of the working group. > > Benson: > There will be references to outside work that is out of scope. The =20 > chairs will create a > bucket draft to hold these documents. > > Benson: > Let's talk about the problem statement. > The context is massive layer 2. There are all kinds of reasons we =20 > might have massive layer 2. We > will just assume it is massive. We need to define the word massive. =20= > Does it means it spans large > distances in one data center or different data centers. As a working =20= > group we need to achieve > consensus what massive means. Talk about what are ARP/ND problems. =20 > Does ARP/ND cause too > much bandwidth to be used or causes too much host processing. Our =20 > first milestone is to define > this. Till now we have had discussion on the context but that does =20 > not answer the question. > > Jari: > There are a different kinds of dimensions with different kinds of =20 > things we can scale for > example number of hosts, number of routers. We should not define =20 > what massive > means. Define the scaling characteristics of ARP/ND, The idea would =20= > be that if you keep > adding hosts when will you run into issues. May be some kind of an =20 > equation that > computes how much traffic gets generated as the network is expanded =20= > etc. > > Benson: > That is what I meant to convey also > > Benson: > We are proposing a new working group draft. Current drafts have good =20= > content and we > may use them. We are looking for a new editor. Anyone interested =20 > please contact us. > > Ning So: > I will volunteer for the editing job. > > Benson: > There are operators in the room we need real data from them if we =20 > are going to be > realistic and successful. If you have data that you can share please =20= > bring that to the > mailing list. If you know someone who has data and want us to go =20 > make phone calls and > twist arms please let us know. > > Igor: > Can you be a little be more specific what data > > Benson: > Let's talk about that on the mailing list. It is a good question in =20= > by itself > > Thomas: > It would be great to have data that we understand and shows what =20 > pain it is. Another > way to look at things would be to categorize them in three buckets. =20= > For example an > environment where current solutions work fine, an environment where =20= > the current > solutions do not scale and another environment where current =20 > technology does not > work because of restrictions imposed several years ago and relaxing =20= > them will solve the > issue. Based on conversations I have had, at some level the =20 > protocols work fine but they > stop working when taken to a certain level. > > Igor: > The reason I asked for specifics of the data is because there are =20 > different data center > designs and each is optimized for different things. > > Benson: > That will be good data to have > > Igor: > So you want every possible data center design document > > Benson: > This needs more discussion that we can have here today > > Ralph: > It does not have to be a lot of data but data that helps us =20 > understand the issue > > Benson: > Yeah. Once we concede there is a problem we can have discussion =20 > about solutions. > > Jari: > Data which can tell us in which dimension the problem is will be =20 > very useful. > > Benson: > Let's talk about it on the mailing list > > Rahul: > What we need here is a problem statement and requirements documents =20= > written by the > operators. > > Benson: > Please bring any more discussions to the mailing list. let's start =20 > the presentations > > Linda: > draft-dunbar-armd-problem-statement-01.txt > > Yizhou Li: > draft-liyz-armd-vm-migration-ps-01 > > Randy Bush: > As usual vendors telling operators what we experience. It would be =20 > nice to have > operators describe the real problems > > Benson: > I agree with you, but no operator submitted drafts or asked for time > > Igor: > Come and ask US > > Jabber - Ron Bonica: > Do you want to have an interim meeting where operators present > > Randy Bush: > Come to NANOG > > Jari: > I have been concerned that we are trying to create technology pushed =20= > by Vendors and I > would like to hear from Operators and data center guys. > > Rahul Agarwal: > Speaking as a vendor I agree with Randy and Igor that operators need =20= > to provide input > for the WG to do the work but Operators do not shut down the WG. > > XXXX: > If we don't define the problem the working group will go away > > Dinesh: > It seems to me that you said we will not talk about solutions but =20 > the previous > presentations have solutions > > Benson: > I agree that all 3 presentations have out of scope material but =20 > these were the best and > since this is the first meeting we are lenient. > > Dave McDyson: > Are future data centers in scope? > > Benson: > No as we are an ops WG we only look at current deployed solutions. =20 > But if you have > ideas send them out. > > Igor: > We need to define what a data center is as everyone's idea of what a =20= > data center is > widely different. > > Benson: > Let's take this to the mailing list > > Cathy: > Nanog would love to have a BOF on Address Resolution. Nanog has much =20= > higher > operator experience. > > Benson > I will contact you off line. > > Linda: > draft-mackcrane-armd-ipv6-nd-scaling-00 (Author not present, Linda =20 > presented on his behalf) > > Igor: > you have assumed one type of architecture. A lot of people don't use =20= > this design, > so the analysis won't apply. Contrary to your conclusion, IPv6 ND =20 > does have issues. > > Chris Morrow: > DC is designed for a particular workload. If you change the =20 > workload, it > may look like the protocol but may be hardware problems. > > Benson: > those are all valid issues. > > Igor: > for most people a DC is the three tier design in text books. But =20 > reality is different. > Perhaps there are about 3 or 4 designs out there. Should we document =20= > those designs? > > Benson: > yes, if you can help with that information on the mailing list. > > Meeting closes. > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd From bschlies@cisco.com Mon Apr 25 17:40:38 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 DCC5FE0670 for ; Mon, 25 Apr 2011 17:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.871 X-Spam-Level: X-Spam-Status: No, score=-8.871 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_UNSUB18B=0.331] 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 nuSl547FvmPx for ; Mon, 25 Apr 2011 17:40:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 57411E062A for ; Mon, 25 Apr 2011 17:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=36464; q=dns/txt; s=iport; t=1303778432; x=1304988032; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=mEYPn7eMwksIYwIVlskQlPPvvE6nZjQ1ryEbnFI8Mwg=; b=W8viUBZXqLSkslplOZBS1/Uwe9gHVCbFBFRlTyucrV/mGVjovlafHIou 3AqTilA6Q7Z6YjEkPSdQlG0kdtehgcLTG1a5gv0EB5v0G/1nuPBAnxSMC HeNjD3PuduZ6EZOYeRZeCVi/vUw0lgp/HV6HYsZzNZGiw0NMQDLzhwzt6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPwTtk2tJV2Z/2dsb2JhbACCYqF+XHeIcKAvnQmFdgSFdog/hA8 X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208,217";a="436191494" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2011 00:40:31 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3Q0eVQK013946 for ; Tue, 26 Apr 2011 00:40:31 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Apr 2011 19:40:30 -0500 Received: from 10.21.112.82 ([10.21.112.82]) 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 ; Tue, 26 Apr 2011 00:40:31 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 25 Apr 2011 19:41:10 -0500 From: Benson Schliesser To: Dino Farinacci , "armd@ietf.org" Message-ID: Thread-Topic: [armd] Draft Minutes of IETF80 ARMD session Thread-Index: AcwDqqLyplmMcy4Q00a17BAPh97NNA== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386605271_8442324" X-OriginalArrivalTime: 26 Apr 2011 00:40:30.0500 (UTC) FILETIME=[8B66DE40:01CC03AA] Subject: Re: [armd] Draft Minutes of IETF80 ARMD session 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, 26 Apr 2011 00:40: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_3386605271_8442324 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 4/25/11 7:29 PM, "Dino Farinacci" wrote: > I think you missed a very important point that Randy made. >=20 > This effort should be run by operators and not vendors. >=20 > There is a Randy reference below but it isn't quite on target. He did > say below but he also said above. >=20 > Dino Thanks, Dino. I agree that some of Randy's comments are missing. However I=B9m personally loathe to put words in Randy=B9s mouth. ;) Perhaps somebody (preferably Randy himself) will propose an update (text) for the minutes? Cheers, -Benson =20 >=20 > On Apr 25, 2011, at 5:26 PM, Benson Schliesser wrote: >=20 >> Below are the minutes from our ARMD session in Prague (IETF80). >> Thanks to Shoaib Rao and Serge Manning for taking such detailed >> notes. Please respond to the list or directly to the co-chairs with >> any corrections. The notes will be uploaded to the IETF website by >> the end of this week. >>=20 >> Thanks, >> -Benson & Linda >>=20 >>=20 >> ARMD Working Group - Meeting Minutes - IETF 80 >>=20 >> Address Resolution for Massive numbers of hosts in the Data center >> (ARMD) >> Location: Barcelona/Berlin meeting room, Hilton Prague, Prague, CZ >> Time: 30-March-2011, 1510=AD1610 - Wednesday, Afternoon Session II >> Chairs: Benson Schliesser (bschlies@cisco.com) & Linda Dunbar >> (linda.dunbar@huawei.com >> ) >>=20 >> Agenda: >> * Meeting Administrivia >> * Discussion of Charter >> * Discussion of Problem Statement >> * Call for Investigation >> * Problem Statement Drafts >>=20 >> Benson: >> Sorry for starting the meeting late, Welcome to ARMD which is now a >> working group, >> Read Note well, let's start the Charter discussion, as you all know >> there were couple of >> BOFS talking about the cloud topics in general and they seemed to be >> too broad. >> We are WG now and have a charter the summary of which is displayed >> in the first 3 >> bullets of the presentation. >> The 1st one has already gotten controversial on the mailing list -- >> We are assuming that >> this will be a massive layer 2 effort. We are not talking about why >>=20 >> Rahul Agarwal: >> I do not agree with the interpretation of the charter that you have >> on the slides. The >> way I read the charter is that the way people are building data >> centers today one of the >> issues they have is data center mobility. One of the issues with the >> current charter is >> that it assumes VM mobility requires massive L2 network. >> We need to really grill into what VM mobility means and what are the >> reasons for >> building large layer 2 networks. For example the VM's might be in >> the same >> administrative domain and the administrative domain is in the same >> L2 network or in >> the same VLAN. That kind of architecture is probably hard to change >> but if there are >> other reasons we need to see if functions can be handed over to >> layer 3. >> So the charter and requirements of the WG needs to change to >> investigate where layer >> 2 hands off to layer 3 and the charter should also include >> definition of mobility. >>=20 >> Benson: >> I do not disagree with the technical questions you are asking as >> whether you build it >> layer at 2 or layer 3 effects the scale but the question we have >> been chartered to >> address is -- Is there an ARP/ND problem to resolve, what is the >> dimension of the >> problem and at what stage the problem starts. If there is a problem >> than only >> discussions around whether layer 3 mitigates that problem becomes >> relevant. >>=20 >> Rahul: >> I am not necessarily saying that ARP is not a problem. All I am >> saying is how big a >> problem it is and it changes how you partition your network based on >> layer 2 and layer 3. >> Getting your layer 2 and layer3 interaction right can be one way of >> scaling your network. >> By limiting the discussion to layer 2 only we are making a mistake. >>=20 >> Jari Arkko: >> I am not the responsible A.D. but I was involved in the discussions >> and the charter does >> say that you need to document the scaling characteristics of ARP/ND >> and document the >> operational characteristics that can reduce those issues. So it's >> not to find the smoking >> gun but to determine if there is a problem or not. The interaction >> of layer 2 and layer 3 >> will come out in the operational practices part. >>=20 >> Benson: >> We have to define what the problem is and that is not up for debate >> and in order to >> manage the working group that is all we will focus on at this first >> meeting. I am not >> saying that these discussions are not relevant. All I am saying is >> that they are not >> relevant to the current discussion. >>=20 >> Igor: >> Defining the issue to be VM mobility is too restrictive. Address >> mobility and resolution in >> VM migration environment is the real issue and we should not limit >> to just ARP/ND. If >> the investigations reveals that ARP/ND are the culprits then that is >> fine. The problem >> should be generalized to Address Resolution. There are lots of >> researches happening in >> this area that we can utilize. >>=20 >> Benson: >> We are not a research group. We are in the OPS area and are limited >> to things that are >> being deployed today. As you pointed out there is a lot of work >> going on in this area but >> that is out of scope for now. >>=20 >> Linda: >> Agree with Igor that Address Resolution general issues should be >> studied by ARMD. >>=20 >> Thomas Narten: >> People are trying to do something here in terms of scaling data >> center. We need to >> understand what they are saying, what the pain is and that should be >> the driving force >> here. By following the charter very closely I worry that by just >> looking at ARP/ND we >> are looking at the symptom of the problem without understanding the >> problem. >>=20 >> Benson: >> Personally I share your concern. But we have to narrow down the scope. >>=20 >> Thomas: >> But I hear someone say cloud and someone say data center. We need to >> make sure >> what we are talking about. >>=20 >> Linda: >> The Charter says data center. >>=20 >> XXXX: >> I also have different reading of the charter. If we can find an >> alternative to large layer2 >> networks than that is better than investing in understanding how >> large layer2 networks >> work. >>=20 >> XXXX: >> What is the acceptable solution space in this WG >>=20 >> Benson: >> We are not looking at the solution space. We are looking at the >> problem, is there is an >> operational problem and what are the dimensions of that problem. If >> there are gaps >> than look at the solutions that are there and maybe recharter. >>=20 >> XXXX: >> Is proposing new solutions using existing technology in scope >>=20 >> Benson: >> No >>=20 >> Jari >> Working on solutions whether they are part of new protocol or >> existing protocol is out >> of scope for now. We are trying to understand what the problem is. >>=20 >> Igor: >> You just said that we are looking for ways to solve address >> resolution problem but the >> slides say ARP/ND which one is it. Are you looking at just ARP/ND? >> It should be Address >> Resolution issues in Data Center. >>=20 >> Benson: >> Anything that is deployed in a meaningful way >>=20 >> Igor: >> What about 100K static entries? >>=20 >> Benson: >> Sure. Please write a draft on how it scales. >>=20 >> Erik Nordmark: >> We do not want sales pitch. However it will be useful if someone has >> experience doing >> address resolution using other than ARP/ND say like chicken wire >> then it is useful to >> write down their experience. >>=20 >> XXXX: >> Why >>=20 >> Erik Nordmark: >> What is more interesting right now is data and not a particular >> approach. >>=20 >> Benson: >> Don't describe the solution, don't describe other reasons why you >> are interested in the >> solution. Describe the impact of your particular approach. >>=20 >> Vince: >> I frankly suggest that look at the charter page and look at goals >> and mile stones. All the >> comments and recommendations can be directed to individual working >> groups or >> towards the deliverable's of the working group. >>=20 >> Benson: >> There will be references to outside work that is out of scope. The >> chairs will create a >> bucket draft to hold these documents. >>=20 >> Benson: >> Let's talk about the problem statement. >> The context is massive layer 2. There are all kinds of reasons we >> might have massive layer 2. We >> will just assume it is massive. We need to define the word massive. >> Does it means it spans large >> distances in one data center or different data centers. As a working >> group we need to achieve >> consensus what massive means. Talk about what are ARP/ND problems. >> Does ARP/ND cause too >> much bandwidth to be used or causes too much host processing. Our >> first milestone is to define >> this. Till now we have had discussion on the context but that does >> not answer the question. >>=20 >> Jari: >> There are a different kinds of dimensions with different kinds of >> things we can scale for >> example number of hosts, number of routers. We should not define >> what massive >> means. Define the scaling characteristics of ARP/ND, The idea would >> be that if you keep >> adding hosts when will you run into issues. May be some kind of an >> equation that >> computes how much traffic gets generated as the network is expanded >> etc. >>=20 >> Benson: >> That is what I meant to convey also >>=20 >> Benson: >> We are proposing a new working group draft. Current drafts have good >> content and we >> may use them. We are looking for a new editor. Anyone interested >> please contact us. >>=20 >> Ning So: >> I will volunteer for the editing job. >>=20 >> Benson: >> There are operators in the room we need real data from them if we >> are going to be >> realistic and successful. If you have data that you can share please >> bring that to the >> mailing list. If you know someone who has data and want us to go >> make phone calls and >> twist arms please let us know. >>=20 >> Igor: >> Can you be a little be more specific what data >>=20 >> Benson: >> Let's talk about that on the mailing list. It is a good question in >> by itself >>=20 >> Thomas: >> It would be great to have data that we understand and shows what >> pain it is. Another >> way to look at things would be to categorize them in three buckets. >> For example an >> environment where current solutions work fine, an environment where >> the current >> solutions do not scale and another environment where current >> technology does not >> work because of restrictions imposed several years ago and relaxing >> them will solve the >> issue. Based on conversations I have had, at some level the >> protocols work fine but they >> stop working when taken to a certain level. >>=20 >> Igor: >> The reason I asked for specifics of the data is because there are >> different data center >> designs and each is optimized for different things. >>=20 >> Benson: >> That will be good data to have >>=20 >> Igor: >> So you want every possible data center design document >>=20 >> Benson: >> This needs more discussion that we can have here today >>=20 >> Ralph: >> It does not have to be a lot of data but data that helps us >> understand the issue >>=20 >> Benson: >> Yeah. Once we concede there is a problem we can have discussion >> about solutions. >>=20 >> Jari: >> Data which can tell us in which dimension the problem is will be >> very useful. >>=20 >> Benson: >> Let's talk about it on the mailing list >>=20 >> Rahul: >> What we need here is a problem statement and requirements documents >> written by the >> operators. >>=20 >> Benson: >> Please bring any more discussions to the mailing list. let's start >> the presentations >>=20 >> Linda: >> draft-dunbar-armd-problem-statement-01.txt >>=20 >> Yizhou Li: >> draft-liyz-armd-vm-migration-ps-01 >>=20 >> Randy Bush: >> As usual vendors telling operators what we experience. It would be >> nice to have >> operators describe the real problems >>=20 >> Benson: >> I agree with you, but no operator submitted drafts or asked for time >>=20 >> Igor: >> Come and ask US >>=20 >> Jabber - Ron Bonica: >> Do you want to have an interim meeting where operators present >>=20 >> Randy Bush: >> Come to NANOG >>=20 >> Jari: >> I have been concerned that we are trying to create technology pushed >> by Vendors and I >> would like to hear from Operators and data center guys. >>=20 >> Rahul Agarwal: >> Speaking as a vendor I agree with Randy and Igor that operators need >> to provide input >> for the WG to do the work but Operators do not shut down the WG. >>=20 >> XXXX: >> If we don't define the problem the working group will go away >>=20 >> Dinesh: >> It seems to me that you said we will not talk about solutions but >> the previous >> presentations have solutions >>=20 >> Benson: >> I agree that all 3 presentations have out of scope material but >> these were the best and >> since this is the first meeting we are lenient. >>=20 >> Dave McDyson: >> Are future data centers in scope? >>=20 >> Benson: >> No as we are an ops WG we only look at current deployed solutions. >> But if you have >> ideas send them out. >>=20 >> Igor: >> We need to define what a data center is as everyone's idea of what a >> data center is >> widely different. >>=20 >> Benson: >> Let's take this to the mailing list >>=20 >> Cathy: >> Nanog would love to have a BOF on Address Resolution. Nanog has much >> higher >> operator experience. >>=20 >> Benson >> I will contact you off line. >>=20 >> Linda: >> draft-mackcrane-armd-ipv6-nd-scaling-00 (Author not present, Linda >> presented on his behalf) >>=20 >> Igor: >> you have assumed one type of architecture. A lot of people don't use >> this design, >> so the analysis won't apply. Contrary to your conclusion, IPv6 ND >> does have issues. >>=20 >> Chris Morrow: >> DC is designed for a particular workload. If you change the >> workload, it >> may look like the protocol but may be hardware problems. >>=20 >> Benson: >> those are all valid issues. >>=20 >> Igor: >> for most people a DC is the three tier design in text books. But >> reality is different. >> Perhaps there are about 3 or 4 designs out there. Should we document >> those designs? >>=20 >> Benson: >> yes, if you can help with that information on the mailing list. >>=20 >> Meeting closes. >>=20 >> _______________________________________________ >> armd mailing list >> armd@ietf.org >> https://www.ietf.org/mailman/listinfo/armd >=20 --B_3386605271_8442324 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [armd] Draft Minutes of IETF80 ARMD session
On 4/25/11 7:29 PM, "Dino Farinacci" <dino@cisco.com> wrote:

> I think you missed a very important point that R= andy made.
>
> This effort should be run by operators and not vendors.
>
> There is a Randy reference below but it isn't quite on target. He did =  
> say below but he also said above.
>
> Dino

Thanks, Dino.  I agree that some of Randy's comments are missing. &nbs= p;However I’m personally loathe to put words in Randy’s mouth. &= nbsp;;)

Perhaps somebody (preferably Randy himself) will propose an update (text) f= or the minutes?

Cheers,
-Benson
 

>
> On Apr 25, 2011, at 5:26 PM, Benson Schliesser wrote:
>
>> Below are the minutes from our ARMD s= ession in Prague (IETF80).   
>> Thanks to Shoaib Rao and Serge Manning for taking such detailed &n= bsp;
>> notes.  Please respond to the list or directly to the co-chai= rs with  
>> any corrections.  The notes will be uploaded to the IETF webs= ite by  
>> the end of this week.
>>
>> Thanks,
>> -Benson & Linda
>>
>>
>> ARMD Working Group - Meeting Minutes - IETF 80
>>
>> Address Resolution for Massive numbers of hosts in the Data center=  
>> (ARMD)
>> Location: Barcelona/Berlin meeting room, Hilton Prague, Prague, CZ=
>> Time: 30-March-2011, 1510–1610 - Wednesday, Afternoon Sessio= n II
>> Chairs: Benson Schliesser (bschlies@c= isco.com) & Linda Dunbar
>> (linda.dunbar@huawei.com >> )
>>
>> Agenda:
>>  * Meeting Administrivia
>>  * Discussion of Charter
>>  * Discussion of Problem Statement
>>  * Call for Investigation
>>  * Problem Statement Drafts
>>
>> Benson:
>> Sorry for starting the meeting late, Welcome to ARMD which is now = a  
>> working group,
>> Read Note well, let's start the Charter discussion, as you all kno= w  
>> there were couple of
>> BOFS talking about the cloud topics in general and they seemed to = be  
>> too broad.
>> We are WG now and have a charter the summary of which is displayed=  
>> in the first 3
>> bullets of the presentation.
>> The 1st one has already gotten controversial on the mailing list -= -  
>> We are assuming that
>> this will be a massive layer 2 effort. We are not talking about wh= y
>>
>> Rahul Agarwal:
>> I do not agree with the interpretation of the charter that you hav= e  
>> on the slides. The
>> way I read the charter is that the way people are building data &n= bsp;
>> centers today one of the
>> issues they have is data center mobility. One of the issues with t= he  
>> current charter is
>> that it assumes VM mobility requires massive L2 network.
>> We need to really grill into what VM mobility means and what are t= he  
>> reasons for
>> building large layer 2 networks. For example the VM's might be in =  
>> the same
>> administrative domain and the administrative domain is in the same=  
>> L2 network or in
>> the same VLAN. That kind of architecture is probably hard to chang= e  
>> but if there are
>> other reasons we need to see if functions can be handed over to &n= bsp;
>> layer 3.
>> So the charter and requirements of the WG needs to change to  = ;
>> investigate where layer
>> 2 hands off to layer 3 and the charter should also include  <= BR> >> definition of mobility.
>>
>> Benson:
>> I do not disagree with the technical questions you are asking as &= nbsp;
>> whether you build it
>> layer at 2 or layer 3 effects the scale but the question we have &= nbsp;
>> been chartered to
>> address is -- Is there an ARP/ND problem to resolve, what is the &= nbsp;
>> dimension of the
>> problem and at what stage the problem starts. If there is a proble= m  
>> than only
>> discussions around whether layer 3 mitigates that problem becomes =  
>> relevant.
>>
>> Rahul:
>> I am not necessarily saying that ARP is not a problem. All I am &n= bsp;
>> saying is how big a
>> problem it is and it changes how you partition your network based = on  
>> layer 2 and layer 3.
>> Getting your layer 2 and layer3 interaction right can be one way o= f  
>> scaling your network.
>> By limiting the discussion to layer 2 only we are making a mistake= .
>>
>> Jari Arkko:
>> I am not the responsible A.D. but I was involved in the discussion= s  
>> and the charter does
>> say that you need to document the scaling characteristics of ARP/N= D  
>> and document the
>> operational characteristics that can reduce those issues. So it's =  
>> not to find the smoking
>> gun but to determine if there is a problem or not. The interaction=  
>> of layer 2 and layer 3
>> will come out in the operational practices part.
>>
>> Benson:
>> We have to define what the problem is and that is not up for debat= e  
>> and in order to
>> manage the working group that is all we will focus on at this firs= t  
>> meeting. I am not
>> saying that these discussions are not relevant.  All I am say= ing is  
>> that they are not
>> relevant to the current discussion.
>>
>> Igor:
>> Defining the issue to be VM mobility is too restrictive. Address &= nbsp;
>> mobility and resolution in
>> VM migration environment is the real issue and we should not limit=  
>> to just ARP/ND.  If
>> the investigations reveals that ARP/ND are the culprits then that = is  
>> fine. The problem
>> should be generalized to Address Resolution. There are lots of &nb= sp;
>> researches happening in
>> this area that we can utilize.
>>
>> Benson:
>> We are not a research group. We are in the OPS area and are limite= d  
>> to things that are
>> being deployed today. As you pointed out there is a lot of work &n= bsp;
>> going on in this area but
>> that is out of scope for now.
>>
>> Linda:
>> Agree with Igor that Address Resolution general issues should be &= nbsp;
>> studied by ARMD.
>>
>> Thomas Narten:
>> People are trying to do something here in terms of scaling data &n= bsp;
>> center. We need to
>> understand what they are saying, what the pain is and that should = be  
>> the driving force
>> here. By following the charter very closely  I worry that by = just   
>> looking at ARP/ND we
>> are looking at the symptom of the problem without understanding th= e  
>> problem.
>>
>> Benson:
>> Personally I share your concern. But we have to narrow down the sc= ope.
>>
>> Thomas:
>> But I hear someone say cloud and someone say data center. We need = to  
>> make sure
>> what we are talking about.
>>
>> Linda:
>> The Charter says data center.
>>
>> XXXX:
>> I also have different reading of the charter. If we can find an &n= bsp;
>> alternative to large  layer2
>> networks than that is better than investing in understanding  = ;how  
>> large layer2 networks
>> work.
>>
>> XXXX:
>> What is the acceptable solution space in this WG
>>
>> Benson:
>> We are not looking at the solution space. We are looking at the &n= bsp;
>> problem,  is there is an
>> operational  problem and what are the dimensions of that prob= lem. If  
>> there are gaps
>> than look at the solutions that are there and maybe recharter.
>>
>> XXXX:
>> Is proposing new solutions using existing technology in scope
>>
>> Benson:
>> No
>>
>> Jari
>> Working on solutions whether they are part of new protocol or &nbs= p;
>> existing protocol is out
>> of scope for now. We are trying to understand what the problem is.=
>>
>> Igor:
>> You just said that we are looking for ways to solve address  =
>> resolution problem but the
>> slides say ARP/ND which one is it. Are you looking at just ARP/ND?=  
>> It should be Address
>> Resolution issues in Data Center.
>>
>> Benson:
>> Anything that is deployed in a meaningful way
>>
>> Igor:
>> What about 100K static entries?
>>
>> Benson:
>> Sure. Please write a draft on how it scales.
>>
>> Erik Nordmark:
>> We do not want sales pitch. However it will be useful if someone h= as  
>> experience doing
>> address resolution using other than ARP/ND say like chicken wire &= nbsp;
>> then it is useful to
>> write down their experience.
>>
>> XXXX:
>> Why
>>
>> Erik Nordmark:
>> What is more interesting right now is data and not a particular &n= bsp;
>> approach.
>>
>> Benson:
>> Don't describe the solution, don't describe other reasons why you =  
>> are interested in the
>> solution. Describe the impact of your particular approach.
>>
>> Vince:
>> I frankly suggest that look at the charter page and look at goals =  
>> and mile stones. All the
>> comments and recommendations can be directed to individual working=  
>> groups or
>> towards the deliverable's of the working group.
>>
>> Benson:
>> There will be references to outside work that is out of scope. The=  
>> chairs will create a
>> bucket draft to hold these documents.
>>
>> Benson:
>> Let's talk about the problem statement.
>> The context is massive layer 2. There are all kinds of reasons we =  
>> might have massive layer 2. We
>> will just assume it is massive. We need to define the word massive= .  
>> Does it means it spans large
>> distances in one data center or different data centers. As a worki= ng  
>> group we need to achieve
>> consensus what massive means. Talk about what are ARP/ND problems.=  
>> Does ARP/ND cause too
>> much bandwidth to be used or causes too much host processing. Our =  
>> first milestone is to define
>> this. Till now we have had discussion on the context but that does=  
>> not answer the question.
>>
>> Jari:
>> There are a different kinds of dimensions with different kinds of =  
>> things we can scale for
>> example number of hosts, number of routers. We should not define &= nbsp;
>> what massive
>> means. Define the scaling characteristics of ARP/ND, The idea woul= d  
>> be that if you keep
>> adding hosts when will you run into issues. May be some kind of an=  
>> equation that
>> computes how much traffic gets generated as the network is expande= d  
>> etc.
>>
>> Benson:
>> That is what I meant to convey also
>>
>> Benson:
>> We are proposing a new working group draft. Current drafts have go= od  
>> content and we
>> may use them. We are looking for a new editor. Anyone interested &= nbsp;
>> please contact us.
>>
>> Ning So:
>> I will volunteer for the editing job.
>>
>> Benson:
>> There are operators in the room we need real data from them if we =  
>> are going to be
>> realistic and successful. If you have data that you can share plea= se  
>> bring that to the
>> mailing list. If you know someone who has data and want us to go &= nbsp;
>> make phone calls and
>> twist arms please let us know.
>>
>> Igor:
>> Can you be a little be more specific what data
>>
>> Benson:
>> Let's talk about that on the mailing list. It is a good question i= n  
>> by itself
>>
>> Thomas:
>> It would be great to have data that we understand and shows what &= nbsp;
>> pain it is. Another
>> way to look at things would be to categorize them in three buckets= .  
>> For example an
>> environment where current solutions work fine, an environment wher= e  
>> the current
>> solutions do not scale and another environment where current  = ;
>> technology does not
>> work because of restrictions imposed several years ago and relaxin= g  
>> them will solve the
>> issue. Based on conversations I have had, at some level the  =
>> protocols work fine but they
>> stop working when taken to a certain level.
>>
>> Igor:
>> The reason I asked for specifics of the data is because there are =  
>> different data center
>> designs and each is optimized for different things.
>>
>> Benson:
>> That will be good data to have
>>
>> Igor:
>> So you want every possible data center design document
>>
>> Benson:
>> This needs more discussion that we can have here today
>>
>> Ralph:
>> It does not have to be a lot of data but data that helps us  =
>> understand the issue
>>
>> Benson:
>> Yeah. Once we concede there is a problem we can have discussion &n= bsp;
>> about solutions.
>>
>> Jari:
>> Data which can tell us in which dimension the problem is will be &= nbsp;
>> very useful.
>>
>> Benson:
>> Let's talk about it on the mailing list
>>
>> Rahul:
>> What we need here is a problem statement and requirements document= s  
>> written by the
>> operators.
>>
>> Benson:
>> Please bring any more discussions to the mailing list. let's start=  
>> the presentations
>>
>> Linda:
>> draft-dunbar-armd-problem-statement-01.txt
>>
>> Yizhou Li:
>> draft-liyz-armd-vm-migration-ps-01
>>
>> Randy Bush:
>> As usual vendors telling operators what we experience. It would be=  
>> nice to have
>> operators describe the real problems
>>
>> Benson:
>> I agree with you, but no operator submitted drafts or asked for ti= me
>>
>> Igor:
>> Come and ask US
>>
>> Jabber - Ron Bonica:
>> Do you want to have an interim meeting where operators present
>>
>> Randy Bush:
>> Come to NANOG
>>
>> Jari:
>> I have been concerned that we are trying to create technology push= ed  
>> by Vendors and I
>> would like to hear from Operators and data center guys.
>>
>> Rahul Agarwal:
>> Speaking as a vendor I agree with Randy and Igor that operators ne= ed  
>> to provide input
>> for the WG to do the work but Operators do not shut down the WG. >>
>> XXXX:
>> If we don't define the problem the working group will go away
>>
>> Dinesh:
>> It seems to me that you said we will not talk about solutions but =  
>> the previous
>> presentations have solutions
>>
>> Benson:
>> I agree that all 3 presentations have out of scope material but &n= bsp;
>> these were the best and
>> since this is the first meeting we are lenient.
>>
>> Dave McDyson:
>> Are future data centers in scope?
>>
>> Benson:
>> No as we are an ops WG we only look at current deployed solutions.=  
>> But if you have
>> ideas send them out.
>>
>> Igor:
>> We need to define what a data center is as everyone's idea of what= a  
>> data center is
>> widely different.
>>
>> Benson:
>> Let's take this to the mailing list
>>
>> Cathy:
>> Nanog would love to have a BOF on Address Resolution. Nanog has mu= ch  
>> higher
>> operator experience.
>>
>> Benson
>> I will contact you off line.
>>
>> Linda:
>> draft-mackcrane-armd-ipv6-nd-scaling-00 (Author not present, Linda=  
>> presented on his behalf)
>>
>> Igor:
>> you have assumed one type of architecture. A lot of people don't u= se  
>> this design,
>> so the analysis won't apply. Contrary to your conclusion, IPv6 ND =  
>> does have issues.
>>
>> Chris Morrow:
>> DC is designed for a particular workload. If you change the  =
>> workload, it
>> may look like the protocol but may be hardware problems.
>>
>> Benson:
>> those are all valid issues.
>>
>> Igor:
>> for most people a DC is the three tier design in text books. But &= nbsp;
>> reality is different.
>> Perhaps there are about 3 or 4 designs out there. Should we docume= nt  
>> those designs?
>>
>> Benson:
>> yes, if you can help with that information on the mailing list. >>
>> Meeting closes.
>>
>> _______________________________________________
>> armd mailing list
>> armd@ietf.org
>> https://www.i= etf.org/mailman/listinfo/armd
>
--B_3386605271_8442324-- From bschlies@cisco.com Mon Apr 25 18:45:50 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 92B24E0692 for ; Mon, 25 Apr 2011 18:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.036 X-Spam-Level: X-Spam-Status: No, score=-9.036 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 7DpYHffGdC4h for ; Mon, 25 Apr 2011 18:45:49 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 05F16E068C for ; Mon, 25 Apr 2011 18:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=3802; q=dns/txt; s=iport; t=1303782349; x=1304991949; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=gOZAGsvGFpHVhgw0eoIgN8QKa6wknWbgz8cfeauc/n4=; b=gYDb333NXubmJLl19tchKJiYBSMjQqDOhEFNayjKNdqwFhA8J6+pfRXE LXO/dKLBFAre+qkHDmCBAsKfMfADht/DcioEWy+eb275CpiYrSqyaUDg4 V68nrt5LHsSLRi0b4Fibv3REOBUGfQa+nk7v+SMJqiNhhwFKgCkisUAfp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHAjtk2tJXG+/2dsb2JhbACCYqF+XHeIcKEUnRCFdgSFdog/hA8 X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208,217";a="301828841" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2011 01:45:48 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3Q1jmY2029532; Tue, 26 Apr 2011 01:45:48 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); Mon, 25 Apr 2011 20:45:47 -0500 Received: from 10.21.122.32 ([10.21.122.32]) 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 ; Tue, 26 Apr 2011 01:45:47 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 25 Apr 2011 20:46:22 -0500 From: Benson Schliesser To: "armd@ietf.org" Message-ID: Thread-Topic: [armd] Draft Minutes of IETF80 ARMD session Thread-Index: AcwDs76ti0z9AtMVYkSw2Ym0Q1JNcQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386609183_8622068" X-OriginalArrivalTime: 26 Apr 2011 01:45:47.0312 (UTC) FILETIME=[AA00F300:01CC03B3] Cc: Randy Bush Subject: [armd] FW: Draft Minutes of IETF80 ARMD session 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, 26 Apr 2011 01:45:50 -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_3386609183_8622068 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Randy was kind enough to provide text updating the minutes. Please see his email, forwarded with permission below: Cheers, -Benson ------ Forwarded Message From: Randy Bush Date: Tue, 26 Apr 2011 10:25:36 +0900 To: Benson Schliesser Cc: Dino Farinacci , Linda Dunbar Subject: Re: FW: [armd] Draft Minutes of IETF80 ARMD session as benson guessed, i do not read the armd list >> I think you missed a very important point that Randy made. >> This effort should be run by operators and not vendors. correct > Thanks, Dino. I agree that some of Randy's comments are missing. > However I=B9m personally loathe to put words in Randy=B9s mouth. ;) lots of other people do :) > Perhaps somebody (preferably Randy himself) will propose an update > (text) for the minutes? i request the minutes be ammended as follows to show that i said: this effort should be run by operators and not vendors and particularly not a single vendor whose presentations dominated the meeting and who described a broken implementation as an excuse for more work the wg is a poor excuse for huawei to get an overly-ambitious person to a wg chairship randy ------ End of Forwarded Message --B_3386609183_8622068 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable FW: [armd] Draft Minutes of IETF80 ARMD session Randy was kind enough to provide text updating the minutes.  Please s= ee his email, forwarded with permission below:

Cheers,
-Benson

------ Forwarded Message
From: Randy Bush <randy@psg.com>
Date: Tue, 26 Apr 2011 10:25:36 +0900
To: Benson Schliesser <bschlies@cisco.com>
Cc: Dino Farinacci <
dino@cisco.com>, Lin= da Dunbar <linda.dunbar@huawei.com&= gt;
Subject: Re: FW: [armd] Draft Minutes of IETF80 ARMD session

as benson guessed, i do not read the armd list

>> I think you missed a very important point th= at Randy made.
>> This effort should be run by operators and not vendors.

correct

> Thanks, Dino.  I agree that some of Randy's= comments are missing.
> However I’m personally loathe to put words in Randy’s mout= h.  ;)

lots of other people do :)

> Perhaps somebody (preferably Randy himself) will= propose an update
> (text) for the minutes?

i request the minutes be ammended as follows to show that i said:

  this effort should be run by operators and not vendors

  and particularly not a single vendor whose presentations domina= ted the
  meeting and who described a broken implementation as an excuse = for
  more work

  the wg is a poor excuse for huawei to get an overly-ambitious p= erson
  to a wg chairship

randy

------ End of Forwarded Message
--B_3386609183_8622068-- From dave.mcdysan@verizon.com Tue Apr 26 06:52:54 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 0191AE07C6 for ; Tue, 26 Apr 2011 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=0.308, 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 nzI6jGjp1YXc for ; Tue, 26 Apr 2011 06:52:53 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by ietfa.amsl.com (Postfix) with ESMTP id 29BC7E079F for ; Tue, 26 Apr 2011 06:52:53 -0700 (PDT) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p3QDqZh3018768 for ; Tue, 26 Apr 2011 09:52:40 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.64,268,1301875200"; d="scan'208,217";a="38182126" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 26 Apr 2011 13:52:34 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.224]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Tue, 26 Apr 2011 09:52:34 -0400 To: Benson Schliesser , "armd@ietf.org" Date: Tue, 26 Apr 2011 09:52:31 -0400 Thread-Topic: [armd] Draft Minutes of IETF80 ARMD session Thread-Index: AcwEGTHAp66+ZNtGTOGFrp6Zvxk41g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9DC45AB159D5davemcdysanoneverizoncom_" MIME-Version: 1.0 Subject: Re: [armd] Draft Minutes of IETF80 ARMD session 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, 26 Apr 2011 13:52:54 -0000 --_000_C9DC45AB159D5davemcdysanoneverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that I may have said something like the following (slightly edite= d) Dave McDysan: I also have different reading of the charter. If we can find an alternative= to large layer2 networks that is better than investing in understanding how to make large = layer2 networks Work. I recall reading the following deliverable bullets from the armd charter in= support of the above statement: o Problem statement and review of current L2/L3 architectures o Recommendations on data center L2/L3 architectures and identification of opportunities for protocol development work Thanks, Dave From: Benson Schliesser > Date: Mon, 25 Apr 2011 20:26:25 -0400 To: "armd@ietf.org" > Subject: [armd] Draft Minutes of IETF80 ARMD session XXXX: I also have different reading of the charter. If we can find an alternative= to large layer2 networks than that is better than investing in understanding how large lay= er2 networks work. --_000_C9DC45AB159D5davemcdysanoneverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I believe that I may have = said something like the following (slightly edited)

Dave McDysan: 
I also have dif= ferent reading of the charter. If we can find an alternative to large  = ;layer2 
networks that is better than investing in understanding &n= bsp;how to make large layer2 networks 
Work.

I recall reading the following deliverable bullets from the arm= d charter in support of the above statement:
<= span class=3D"Apple-style-span" style=3D"font-size: 15px;">
  o Problem=
 statement and review of current L2/L3 architectures
  o =
Recommendations on data center L2/L3 architectures and
     identification of opportunities for protocol development work
Thanks,

Dave
From: Benson Schliesser <bschlies@cisco.com>
Date: Mon, 25 Apr 2011 20:26:25 -0400
To: "arm= d@ietf.org" <armd@ietf.org><= br>Subject: [armd] Draft Minutes o= f IETF80 ARMD session

XXXX: 
I also have different reading o= f the charter. If we can find an alternative to large  layer2 
networks than that is better = than investing in understanding  how large layer2 networks 
work.
--_000_C9DC45AB159D5davemcdysanoneverizoncom_-- From bschlies@cisco.com Tue Apr 26 07:58:28 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 5B0EFE072C for ; Tue, 26 Apr 2011 07:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.092 X-Spam-Level: X-Spam-Status: No, score=-9.092 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 gE9oB6vBKNoE for ; Tue, 26 Apr 2011 07:58:27 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCE5E0772 for ; Tue, 26 Apr 2011 07:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=3900; q=dns/txt; s=iport; t=1303829905; x=1305039505; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=VHlpHVeGkYIUyaDQ3M+oopRauyH8MBgiBy8gIw+LW84=; b=cDGFJzcNkYMuiZhmcL5B0HPfujfwp3ST7WJc1NCSXgQ7mtRobiPsyk3s gUVht2o9icEJKxQijJU701UlZSV/ohnkvtP2uRPVeWvwxgIFObNhzP9BM hbI1KhelOttx0hSQp3Zwc8106XD/+ZmMDe3CkirLzKmXaPOW90cZ9MjhV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGDctk2tJV2Z/2dsb2JhbACCYqIHX3eIcJ87nR2FdgSFfYhEhBSKKg X-IronPort-AV: E=Sophos;i="4.64,268,1301875200"; d="scan'208,217";a="436572217" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2011 14:58:24 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3QEwOUx010457; Tue, 26 Apr 2011 14:58:24 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, 26 Apr 2011 09:58:24 -0500 Received: from 10.21.83.167 ([10.21.83.167]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Apr 2011 14:58:24 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 26 Apr 2011 09:58:58 -0500 From: Benson Schliesser To: "Mcdysan, David E" , "armd@ietf.org" Message-ID: Thread-Topic: [armd] Draft Minutes of IETF80 ARMD session Thread-Index: AcwEGTHAp66+ZNtGTOGFrp6Zvxk41gACUaDw In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386656738_9051517" X-OriginalArrivalTime: 26 Apr 2011 14:58:24.0010 (UTC) FILETIME=[64012EA0:01CC0422] Subject: Re: [armd] Draft Minutes of IETF80 ARMD session 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, 26 Apr 2011 14:58:28 -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_3386656738_9051517 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Thanks, Dave. I=B9ll update the notes accordingly. Cheers, -Benson On 4/26/11 8:52 AM, "Mcdysan, David E" wrote: > I believe that I may have said something like the following (slightly edi= ted) >=20 > Dave McDysan:=20 > I also have different reading of the charter. If we can find an alternati= ve to > large layer2=20 > networks that is better than investing in understanding how to make larg= e > layer2 networks=20 > Work. >=20 > I recall reading the following deliverable bullets from the armd charter = in > support of the above statement: > o Problem statement and review of current L2/L3 architectures > o Recommendations on data center L2/L3 architectures and > identification of opportunities for protocol development work > Thanks, >=20 > Dave > From: Benson Schliesser > Date: Mon, 25 Apr 2011 20:26:25 -0400 > To: "armd@ietf.org" > Subject: [armd] Draft Minutes of IETF80 ARMD session >=20 >> XXXX:=20 >> I also have different reading of the charter. If we can find an alternat= ive >> to large layer2 >> networks than that is better than investing in understanding how large >> layer2 networks=20 >> work. >=20 --B_3386656738_9051517 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [armd] Draft Minutes of IETF80 ARMD session Thanks, Dave.  I’ll update the notes accordingly.

Cheers,
-Benson


On 4/26/11 8:52 AM, "Mcdysan, David E" <dave.mcdysan@verizon.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>I believe that I may have said something like th= e following (slightly edited)

Dave McDysan:
I also have different reading of the charter. If we can find an alternative= to large  layer2
networks that is better than investing in understanding  how to make l= arge layer2 networks
Work.

I recall reading the following deliverable bullets from the armd charter in= support of the above statement:
  o Problem statement and review of current L2/L3 architectures   o Recommendations on data center L2/L3 architectures and
     identification of opportunities for protocol = development work
Thanks,

Dave
From: Benson Schliesser <bschlies@c= isco.com>
Date: Mon, 25 Apr 2011 20:26:25 -0400
To: "armd@ietf.org" <armd@ietf.org>
Subject: [armd] Draft Minutes of IETF80 ARMD session

<= SPAN STYLE=3D'font-size:11.5pt'>XXXX:
I also have different reading of the charter. If we can find an alternative= to large  layer2
networks than that is better than investing in understanding  how larg= e layer2 networks
work.
=
--B_3386656738_9051517-- From bschlies@cisco.com Fri Apr 29 16:42:15 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 91E19E06AF for ; Fri, 29 Apr 2011 16:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.119 X-Spam-Level: X-Spam-Status: No, score=-9.119 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 SzCy6zhyfn0a for ; Fri, 29 Apr 2011 16:42:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 90D2BE0698 for ; Fri, 29 Apr 2011 16:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1310; q=dns/txt; s=iport; t=1304120534; x=1305330134; h=date:subject:from:to:message-id:mime-version; bh=wQjf66uBXbeBINYhBG+D+JCCWsBsAsj6qGswtZeOPR0=; b=kVVP1RqaVoascCEIpZvcsabkzl+92x2YbFaPdjIU1l8X/HtgC88ovD+J lf3RZinhovVIu3PpNec3QkffuUTBl2lIFLfZtlI+7/TFKPkbDqvqCDTg5 gctynqI/7a+m2MerT4yc78jqGsHdFoWBhLhQNrZjUe08FoyaKb7q9SgE/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEJAKdLu02tJXG8/2dsb2JhbACCYZwmhilid6cwgR2cTYV+BIYNiFuEIIoY X-IronPort-AV: E=Sophos;i="4.64,291,1301875200"; d="scan'208,217";a="347557934" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 29 Apr 2011 23:42:14 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3TNgDxE032700 for ; Fri, 29 Apr 2011 23:42:13 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Apr 2011 18:42:13 -0500 Received: from 10.21.94.76 ([10.21.94.76]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Fri, 29 Apr 2011 23:42:13 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 29 Apr 2011 18:42:51 -0500 From: Benson Schliesser To: "armd@ietf.org" Message-ID: Thread-Topic: IETF80 minutes uploaded Thread-Index: AcwGxycIv1k0BXqYAEuKrixLPUC7HQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386947372_16240012" X-OriginalArrivalTime: 29 Apr 2011 23:42:13.0722 (UTC) FILETIME=[10CFE3A0:01CC06C7] Subject: [armd] IETF80 minutes uploaded 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 Apr 2011 23:42:15 -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_3386947372_16240012 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The minutes from the ARMD session at IETF 80 (in Prague) have been uploaded. They can be found at http://www.ietf.org/proceedings/80/minutes/armd.txt Many thanks to Shoaib Rao and Serge Manning for taking notes, and to the participants that responded with corrections. Cheers, -Benson & Linda --B_3386947372_16240012 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable IETF80 minutes uploaded The minutes from the ARMD session at IETF 80 (in Prague) have been uploade= d.  They can be found at http://www.ietf.org/proceedings/80/minutes/armd.txt

Many thanks to Shoaib Rao and Serge Manning for taking notes, and to the pa= rticipants that responded with corrections.

Cheers,
-Benson & Linda
--B_3386947372_16240012--