From bschlies@cisco.com Wed Mar 2 10:23:43 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5EF3A67FD for ; Wed, 2 Mar 2011 10:23:43 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSvzWELIrRaM for ; Wed, 2 Mar 2011 10:23:41 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 68D4C3A67D3 for ; Wed, 2 Mar 2011 10:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1566; q=dns/txt; s=iport; t=1299090288; x=1300299888; h=date:subject:from:to:cc:message-id:mime-version: content-transfer-encoding; bh=+j08JtwU9M5F9bPlVCHw+BN7S7RqhevldtNNH91V9SU=; b=Y1a4ie61cpWsj6P8NpdfT2i7/wJxoCxWCfa8Y48s1lN2fwO2Gau4BPVO EjyAI/LB8yRi5x6+hu0OnIjsTc0oNGI7wPkPUEK9hRrraHVG+M344IQWi Ms/lQH5LTgti/0hAzRLk27CqeXokjHAKaErfzs2sH1N5f1nf8fAZvboMh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsGAEoabk2tJXG//2dsb2JhbACYQo4ZdKImm36FYQSFF4cPg0Y X-IronPort-AV: E=Sophos;i="4.62,254,1297036800"; d="scan'208";a="221934579" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2011 18:24:47 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p22IOlMf024642; Wed, 2 Mar 2011 18:24:47 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); Wed, 2 Mar 2011 12:24:47 -0600 Received: from 10.21.65.52 ([10.21.65.52]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.114]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Mar 2011 18:24:46 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 02 Mar 2011 12:24:50 -0600 From: Benson Schliesser To: Message-ID: Thread-Topic: Call for agenda items (pending WG approval) Thread-Index: AcvZBx3pLTSVCxu1tE+Kw2eH68hFYA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Mar 2011 18:24:47.0148 (UTC) FILETIME=[1C35D6C0:01CBD907] Subject: [armd] Call for agenda items (pending WG approval) X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 18:23:43 -0000 Dear ARMD Participants - In anticipation of meeting in Prague, please send requests for agenda slots to Linda and me. The draft agenda is due by 16-March-2011 - all agenda requests must be received within the next two weeks. ARMD is currently undergoing IESG charter review, which should be complete by 17-March-2011. In the event that the charter is not approved our WG session will be canceled. However, in anticipation of a successful chartering we are going ahead with coordination of a meeting during the 1510-1610 Afternoon Session II timeslot on Wed (30-March-2011) in Prague. (See https://datatracker.ietf.org/meeting/80/agenda.html for updates and details.) In the version currently being reviewed, our draft charter covers two areas: (1) Document the current practices in data center network architectures and the scaling characteristics of ARP and ND with respect to large sized layer-2 domains in data centers. (2) Provide operational recommendations intended to minimize issues associated with these architectures and characteristics. Note that, unless the charter is modified during review, we are not chartered to engage in protocol development. Our task at this time is to explore the requirements and operational aspects of ARP/ND scale. (Protocol work may be considered in the future, following this requirements phase, if determined to be appropriate.) All agenda requests must fit into one of these two areas described above, in order to be accepted for discussion in Prague. Thanks, -Benson & Linda From wwwrun@core3.amsl.com Tue Mar 8 10:03:26 2011 Return-Path: X-Original-To: armd@ietf.org Delivered-To: armd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 82C8D3A68F7; Tue, 8 Mar 2011 10:03:26 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110308180326.82C8D3A68F7@core3.amsl.com> Date: Tue, 8 Mar 2011 10:03:26 -0800 (PST) Cc: armd@ietf.org Subject: [armd] WG Review: Address Resolution for Massive numbers of hosts in the Data center (armd) X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org 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, 08 Mar 2011 18:03:26 -0000 A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 15, 2011. Address Resolution for Massive numbers of hosts in the Data center (armd) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-02-18 Chairs: TBD Operations and Management Area Directors: Ronald Bonica Dan Romascanu Operations and Management Area Advisor: Ronald Bonica Internet Area Advisor: Ralph Droms Mailing lists: Address: armd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/armd Archive: http://www.ietf.org/mail-archive/web/armd/ Description of Working Group: Changing workloads in datacenters are having an impact on the performance of current datacenter network designs. For example, the use of virtual machines (VMs) as a means for deployment and management of new services often results in a significant increase in the number of hosts attached to the network. Various requirements for the deployment of VMs in data center networks, such as support for VM mobility, has led to architectures in which broadcast domains are scaling up to span more switching devices and VM servers, and to interconnect more hosts (as represented by VMs). In these deployment architectures, heavily used protocols that are based on broadcast or multicast, such as ARP and ND, may contribute to poor network performance. The armd Working Group will investigate the impact of changing workloads and existing protocols on datacenter network performance. In its work, the armd Working Group will take into consideration work done in data center networking standardization by other SDOs, such as the IEEE 802.1 Data Center Bridging Task Group, and will communicate and exchange information with these organizations. Working Group objectives: (1) Document the current practices in data center network architectures and the scaling characteristics of ARP and ND with respect to large sized layer-2 domains in data centers. (2) Provide operational recommendations intended to minimize issues associated with these architectures and characteristics. Area affiliation of the Working Group: The armd Working Group is assigned to the Operations and Management area, and will maintain close collaboration with the Internet area. Because of its affiliation with Operations and Management, the armd Working Group will focus on documenting current practices and scaling characteristics, and will not do any protocol development or extension work. If the Working Group identifies opportunities for protocol development or extensions, it will first develop requirements for that work. Any protocol development work will be conducted in the appropriate existing Working Groups if such work groups exist. If no such working groups exist, armd may recharter to address the work and may be moved to a different area. Deliverables (Informational RFCs; list to be removed prior to posting): o Problem statement and review of current L2/L3 architectures o Report on ARP/ND statistics collection and behavior analysis in various Data Center environments o Recommendations on data center L2/L3 architectures and identification of opportunities for protocol development work Milestones (Informational RFCs to be completed for IESG review): May 2011 - Problem statement Nov 2011 - ARP/ND statistics collection and behavior analysis in various Data Center environments - many subnets with various sizes - subnets with hosts with VMs and VMs migrate over time - subnets with some hosts on local VMs and others on VMs in the cloud (like Amazon's ECS), - Large subnet. Nov 2011 - Survey of Existing Implementations Nov 2011 - Survey of Security Mar 2012 - Recommendations to avoid or minimize issues caused by ARP/ND Mar 2012 - Gap Analysis From wwwrun@core3.amsl.com Mon Mar 21 16:11:07 2011 Return-Path: X-Original-To: armd@ietf.org Delivered-To: armd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id BB7123A6908; Mon, 21 Mar 2011 16:11:07 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110321231107.BB7123A6908@core3.amsl.com> Date: Mon, 21 Mar 2011 16:11:07 -0700 (PDT) Cc: ldunbar@huawei.com, armd@ietf.org Subject: [armd] WG Action: Address Resolution for Massive numbers of hosts in the Data center (armd) 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, 21 Mar 2011 23:11:07 -0000 A new IETF working group has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. Address Resolution for Massive numbers of hosts in the Data center (armd) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-02-18 Chairs: Linda Dunbar Benson Schliesser Operations and Management Area Directors: Ronald Bonica Dan Romascanu Operations and Management Area Advisor: Ronald Bonica Internet Area Advisor: Ralph Droms Mailing lists: Address: armd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/armd Archive: http://www.ietf.org/mail-archive/web/armd/ Description of Working Group: Changing workloads in datacenters are having an impact on the performance of current datacenter network designs. For example, the use of virtual machines (VMs) as a means for deployment and management of new services often results in a significant increase in the number of hosts attached to the network. Various requirements for the deployment of VMs in data center networks, such as support for VM mobility, has led to architectures in which broadcast domains are scaling up to span more switching devices and VM servers, and to interconnect more hosts (as represented by VMs). In these deployment architectures, heavily used protocols that are based on broadcast or multicast, such as ARP and ND, may contribute to poor network performance. The armd Working Group will investigate the impact of changing workloads and existing protocols on datacenter network performance. In its work, the armd Working Group will take into consideration work done in data center networking standardization by other SDOs, such as the IEEE 802.1 Data Center Bridging Task Group, and will communicate and exchange information with these organizations. Working Group objectives: (1) Document the current practices in data center network architectures and the scaling characteristics of ARP and ND with respect to large sized layer-2 domains in data centers. (2) Provide operational recommendations intended to minimize issues associated with these architectures and characteristics. Area affiliation of the Working Group: The armd Working Group is assigned to the Operations and Management area, and will maintain close collaboration with the Internet area. Because of its affiliation with Operations and Management, the armd Working Group will focus on documenting current practices and scaling characteristics, and will not do any protocol development or extension work. If the Working Group identifies opportunities for protocol development or extensions, it will first develop requirements for that work. Any protocol development work will be conducted in the appropriate existing Working Groups if such work groups exist. If no such working groups exist, armd may recharter to address the work and may be moved to a different area. Deliverables (Informational RFCs; list to be removed prior to posting): o Problem statement and review of current L2/L3 architectures o Report on ARP/ND statistics collection and behavior analysis in various Data Center environments o Recommendations on data center L2/L3 architectures and identification of opportunities for protocol development work Milestones (Informational RFCs to be completed for IESG review): May 2011 - Problem statement Nov 2011 - ARP/ND statistics collection and behavior analysis in various Data Center environments - many subnets with various sizes - subnets with hosts with VMs and VMs migrate over time - subnets with some hosts on local VMs and others on VMs in the cloud (like Amazon's ECS), - Large subnet. Nov 2011 - Survey of Existing Implementations Nov 2011 - Survey of Security Mar 2012 - Recommendations to avoid or minimize issues caused by ARP/ND Mar 2012 - Gap Analysis From bschlies@cisco.com Sun Mar 27 02:19:53 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 1EFA23A6906 for ; Sun, 27 Mar 2011 02:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 LqFj4MClBGqI for ; Sun, 27 Mar 2011 02:19:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D258D3A68FA for ; Sun, 27 Mar 2011 02:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1116; q=dns/txt; s=iport; t=1301217688; x=1302427288; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=GDC8k9VB/QcEhEf/7g5rdco9ZyoVnQ/VFUyQ3ZEeCKg=; b=N5PbUjSb0F4ocahvq85UCi4iUzu2qWDuoH67vJ2pl33wxMR32HyQtjKx HyuiQf+qJiBw5vkVUSVlm/kX5ToA4alLhpm0PiDhkk7F4p1LilUZgvLKg d2iUnIhO8rO4WQjM4SjZmNxQF8umkxs6gByDoSGS1FdEsWM0rfYNskVMc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkHAOkAj02tJXG+/2dsb2JhbACYYox9d6ZXmn+FaQSFOoc9g1o X-IronPort-AV: E=Sophos;i="4.63,250,1299456000"; d="scan'208";a="283436953" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 27 Mar 2011 09:21:06 +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 p2R9L6GB005744 for ; Sun, 27 Mar 2011 09:21:06 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); Sun, 27 Mar 2011 04:21:06 -0500 Received: from 10.61.101.118 ([10.61.101.118]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([144.254.231.94]) with Microsoft Exchange Server HTTP-DAV ; Sun, 27 Mar 2011 09:21:06 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sun, 27 Mar 2011 04:21:04 -0500 From: Benson Schliesser To: Message-ID: Thread-Topic: Agenda for ARMD at IETF80 Thread-Index: AcvsYEugqZoB8c34cEW/L+y9JJ/SvQ== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 27 Mar 2011 09:21:06.0852 (UTC) FILETIME=[4D536E40:01CBEC60] Subject: [armd] Agenda for ARMD at IETF80 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 09:19:53 -0000 Folks - The agenda for the ARMD session at IETF80 has been posted. It can be found at http://www.ietf.org/proceedings/80/agenda/armd.html and is included belo= w for your convenience. -Benson & Linda ARMD AGENDA 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) Jabber: armd@jabber.ietf.org URL: http://tools.ietf.org/wg/armd/ Agenda: version 2 A. Meeting Administrivia (chairs - 05 min) * Welcome * Mailing list and URL * Minutes Scribe * Jabber Scribe * Blue Sheets B. Discussion of Charter (chairs - 10 min) C. Discussion of Problem Statement (chairs - 10 min) D. Problem Statement Drafts 1. draft-dunbar-armd-problem-statement-01 (Linda Dunbar - 10 min) 2. draft-liyz-armd-vm-migration-ps-01 (Yizhou Li - 10 min) 3. draft-mackcrane-armd-ipv6-nd-scaling-00 (Ben Mack-Crane - 10 min) E. Call for Investigation (chairs - 05 min) From bschlies@cisco.com Sun Mar 27 11:51:45 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 C898D3A68D2 for ; Sun, 27 Mar 2011 11:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.862 X-Spam-Level: X-Spam-Status: No, score=-9.862 tagged_above=-999 required=5 tests=[AWL=-0.660, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Dwg93db7KsC for ; Sun, 27 Mar 2011 11:51:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CAB863A68C6 for ; Sun, 27 Mar 2011 11:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1388; q=dns/txt; s=iport; t=1301252002; x=1302461602; h=date:subject:from:to:cc:message-id:mime-version; bh=IKypYdiQY1FqZ/Hr8bNvMlR0U8F2mtv1fwWUV/CDmyU=; b=Ui/y9evU38g8ocJab2ygOtxUVHXXgk1qbvCn+5CXws9mIXsfey/G935V 0sFoHUOzBTDqSAUNJucEOvfkY4wnbHy5+kivKdEXmM0nfhCY6yUgSsTQL ILRvKgbrDcUx/a2D+Ltg6pdummHfgaffqART29fx+U5+hP0v/cv2C38lL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK+Gj02tJXG9/2dsb2JhbACCX6IfXnekSppxhWkEhTqHPYNa X-IronPort-AV: E=Sophos;i="4.63,251,1299456000"; d="scan'208,217";a="325407298" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2011 18:53:21 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2RIrLqr008826; Sun, 27 Mar 2011 18:53:21 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); Sun, 27 Mar 2011 13:53:21 -0500 Received: from 10.61.102.38 ([10.61.102.38]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([144.254.231.93]) with Microsoft Exchange Server HTTP-DAV ; Sun, 27 Mar 2011 18:53:21 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sun, 27 Mar 2011 13:53:18 -0500 From: Benson Schliesser To: "armd@ietf.org" Message-ID: Thread-Topic: Request: Minutes and Jabber Scribe Thread-Index: AcvssDxIYWDIll1Z1EWAOeo9m/0Y5A== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384078799_265236700" X-OriginalArrivalTime: 27 Mar 2011 18:53:21.0450 (UTC) FILETIME=[3E5750A0:01CBECB0] Subject: [armd] Request: Minutes and Jabber Scribe X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 18:51:45 -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_3384078799_265236700 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The upcoming ARMD session (on Wed afternoon in Prague) needs 2+ volunteers, somebody to take meeting minutes and somebody to interact with remote participants via Jabber. These are both very important jobs for the working group. If you are willing to help with either job, please send an email to Linda and me prior to the session. Cheers, -Benson & Linda --B_3384078799_265236700 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Request: Minutes and Jabber Scribe The upcoming ARMD session (on Wed afternoon in Prague) needs 2+ volunteers= , somebody to take meeting minutes and somebody to interact with remote part= icipants via Jabber.  These are both very important jobs for the workin= g group.

If you are willing to help with either job, please send an email to Linda a= nd me prior to the session.

Cheers,
-Benson & Linda
 --B_3384078799_265236700-- From linda.dunbar@huawei.com Mon Mar 28 19:06:58 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0E23A6765 for ; Mon, 28 Mar 2011 19:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=0.970, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3hrbnGvhJLw for ; Mon, 28 Mar 2011 19:06:57 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id DF0573A6405 for ; Mon, 28 Mar 2011 19:06:57 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIS00GEDRAB84@usaga04-in.huawei.com> for armd@ietf.org; Mon, 28 Mar 2011 21:08:35 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LIS00L4RRAABL@usaga04-in.huawei.com> for armd@ietf.org; Mon, 28 Mar 2011 21:08:34 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 28 Mar 2011 19:08:32 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.54]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Mon, 28 Mar 2011 19:08:34 -0700 Date: Tue, 29 Mar 2011 02:08:33 +0000 From: Linda Dunbar X-Originating-IP: [10.47.130.99] To: "armd@ietf.org" Message-id: <4A95BA014132FF49AE685FAB4B9F17F605128F5E@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: ARMD WG will be on WebEx Thread-index: AQHL7bY0TLUv2PX6Gky1OWi+Pal5eQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [armd] ARMD WG will be on WebEx X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 02:06:58 -0000 ARMD WG session in 80th IETF is scheduled on Wed (March 30) afternoon at 3:10pm (Prague time). The session will be on WebEx. Anyone who wants to participate in ARMD WG meeting remotely can goes to http://www.ietf.org/meeting/80/remote-participation.html (from the main IETF 80 page). Linda & Benson From bschlies@cisco.com Tue Mar 29 07:00:32 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D54E3A6803 for ; Tue, 29 Mar 2011 07:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.525 X-Spam-Level: X-Spam-Status: No, score=-10.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 DV1L5A7LOF+B for ; Tue, 29 Mar 2011 07:00:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AE6F43A63D2 for ; Tue, 29 Mar 2011 07:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=252; q=dns/txt; s=iport; t=1301407329; x=1302616929; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=b4D5K+B5/2dHf/ZPHfObXTmyFPQIepZUjWUTcYkkYHA=; b=ltPdPOrlbITCakaLdPRenIzZEyWMmjBWZ+b4kqR77leh00thW8XslQd+ 4WCkTOZhOe3AhGGoVC532TvA8x3+uVRdk5A1jAXSYG4ZWLdnuvAXUs82g ymx37LHOsIPiiexAHs7x36YUN/CrI4fvqPtsNSVTjGBCOOBEnabVjub/Z 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMPlkU2tJV2Z/2dsb2JhbAClTXeoapxChWoEhTyHRoNa X-IronPort-AV: E=Sophos;i="4.63,262,1299456000"; d="scan'208";a="284925331" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 13:53:21 +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 p2TDrLlK030359 for ; Tue, 29 Mar 2011 13:53:21 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, 29 Mar 2011 08:53:21 -0500 Received: from 10.55.91.125 ([10.55.91.125]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([144.254.231.96]) with Microsoft Exchange Server HTTP-DAV ; Tue, 29 Mar 2011 13:53:21 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 29 Mar 2011 08:53:18 -0500 From: Benson Schliesser To: "armd@ietf.org" Message-ID: Thread-Topic: Updated Agenda for ARMD at IETF80 Thread-Index: AcvuGKhGChJncQcO90uO/zxpAbom3g== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Mar 2011 13:53:21.0810 (UTC) FILETIME=[AA8BB720:01CBEE18] Subject: [armd] Updated Agenda for ARMD at IETF80 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:00:32 -0000 The agenda for our ARMD session tomorrow has been updated, and now includes a presentation on draft-so-vpn-o-cs-00. The latest version of the agenda can be found at http://www.ietf.org/proceedings/80/agenda/armd.html. Cheers, -Benson & Linda From muraris@microsoft.com Tue Mar 29 08:31:26 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD333A697F for ; Tue, 29 Mar 2011 08:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpliL+Mic5cF for ; Tue, 29 Mar 2011 08:31:25 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id B03BF3A6835 for ; Tue, 29 Mar 2011 08:31:25 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 29 Mar 2011 08:33:03 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.31]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0270.002; Tue, 29 Mar 2011 08:33:03 -0700 From: Murari Sridharan To: Benson Schliesser , "armd@ietf.org" Thread-Topic: Updated Agenda for ARMD at IETF80 Thread-Index: AcvuGKhGChJncQcO90uO/zxpAbom3gADdYzO Date: Tue, 29 Mar 2011 15:33:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [armd] Updated Agenda for ARMD at IETF80 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:31:26 -0000 Benson, how is this presentation related to ARMD? I'll admit I glanced it o= nly briefly and I fail to find the relevance.=20 Thanks ________________________________________ From: armd-bounces@ietf.org [armd-bounces@ietf.org] on behalf of Benson Sch= liesser [bschlies@cisco.com] Sent: Tuesday, March 29, 2011 6:53 AM To: armd@ietf.org Subject: [armd] Updated Agenda for ARMD at IETF80 The agenda for our ARMD session tomorrow has been updated, and now includes a presentation on draft-so-vpn-o-cs-00. The latest version of the agenda can be found at http://www.ietf.org/proceedings/80/agenda/armd.html. Cheers, -Benson & Linda _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd= From bschlies@cisco.com Tue Mar 29 09:22:49 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 169C13A691E for ; Tue, 29 Mar 2011 09:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 c7XgTUZ731Qz for ; Tue, 29 Mar 2011 09:22:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 14CE33A6863 for ; Tue, 29 Mar 2011 09:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1878; q=dns/txt; s=iport; t=1301415866; x=1302625466; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=dyrxRlaMmarTxzcd2eeyv7TxCyVF7onvpZnJGBYfiag=; b=jlFDip1AIXjsvPYcrK4/lPaFIi5ZBCLQOlYKahz1JGoIJygQ/Y6EGyjY j/QxZjR2O9xfTQotQmE94vzPAI5TviOYSy6fVH4sgiCdAPyfJlMfeTu8o julAGuaKIqxtzEe97nZbZXWubJ5bY+4Tu4nw440Q8nuYTu1oKkAp06Daw E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAANMGkk2tJV2b/2dsb2JhbACYEY09d4h5nwacWoVqBIU8h0aDWg X-IronPort-AV: E=Sophos;i="4.63,263,1299456000"; d="scan'208";a="420322450" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-1.cisco.com with ESMTP; 29 Mar 2011 16:24:26 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2TGOQmW029771; Tue, 29 Mar 2011 16:24:26 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); Tue, 29 Mar 2011 11:24:26 -0500 Received: from 10.21.90.191 ([10.21.90.191]) 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, 29 Mar 2011 16:24:25 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 29 Mar 2011 11:24:22 -0500 From: Benson Schliesser To: Murari Sridharan , "armd@ietf.org" Message-ID: Thread-Topic: Updated Agenda for ARMD at IETF80 Thread-Index: AcvuGKhGChJncQcO90uO/zxpAbom3gADdYzOAAHRGPE= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Mar 2011 16:24:26.0015 (UTC) FILETIME=[C53BA2F0:01CBEE2D] Subject: Re: [armd] Updated Agenda for ARMD at IETF80 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:22:49 -0000 Hi, Murari. Fair question. Linda and I have spoken with the presenter about this question ourselves, and he has assured us that his focus will be on describing scale. There are, of course, a number of additional topics in the draft that will not be discussed during ARMD. For context, here is text that I've used in declining several other presentations that did not make it into the agenda: "In terms of WG management, we're focusing this first meeting on the Problem Statement milestone. Our standard, for timeslots in this agenda, is that a presentation must be focused on describing the scale and/or problems that result from scale. We are not allowing presentations that focus on drivers, context, solutions, etc." Some of these additional topics might become relevant after we make progress on our Problem Statement milestone. We will discuss this during the ARMD session tomorrow, and I look forward to your feedback then. Cheers, -Benson On 3/29/11 10:33 AM, "Murari Sridharan" wrote: > Benson, how is this presentation related to ARMD? I'll admit I glanced it only > briefly and I fail to find the relevance. > > Thanks > > ________________________________________ > From: armd-bounces@ietf.org [armd-bounces@ietf.org] on behalf of Benson > Schliesser [bschlies@cisco.com] > Sent: Tuesday, March 29, 2011 6:53 AM > To: armd@ietf.org > Subject: [armd] Updated Agenda for ARMD at IETF80 > > The agenda for our ARMD session tomorrow has been updated, and now includes > a presentation on draft-so-vpn-o-cs-00. > > The latest version of the agenda can be found at > http://www.ietf.org/proceedings/80/agenda/armd.html. > > Cheers, > -Benson & Linda > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd From bschlies@cisco.com Wed Mar 30 04:54:29 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 63B9628C16A for ; Wed, 30 Mar 2011 04:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.809 X-Spam-Level: X-Spam-Status: No, score=-9.809 tagged_above=-999 required=5 tests=[AWL=-0.607, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IJHirsQt62S for ; Wed, 30 Mar 2011 04:54:26 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 870BE28C126 for ; Wed, 30 Mar 2011 04:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1725; q=dns/txt; s=iport; t=1301486165; x=1302695765; h=date:subject:from:to:message-id:mime-version; bh=q5/nf/yGsOz08ho1xHuH3lFTGkqqXusEset553z6TUw=; b=lL1dQlUUwy5aa5IPng5DISgWNuaDMh+dOaoSiea9PCWwy2SqAtr73N/8 3aE0WfAgQH4yYp9vVyt6BvLaOk+k2/EVteZNvY+C3HTcMHU6W25xa3hzj 2dnIHZD2ArJo7eDIMv6OShqSgKYu+of0xC0JDWUeknT1kJ1WbBJFkwnAc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQHAIYZk02tJXHA/2dsb2JhbACCXpwYhXtdd6EWnFuFagSFP4dHg1s X-IronPort-AV: E=Sophos;i="4.63,268,1299456000"; d="scan'208,217";a="352907924" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-5.cisco.com with ESMTP; 30 Mar 2011 11:56:05 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2UBu5Gi030633 for ; Wed, 30 Mar 2011 11:56:05 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); Wed, 30 Mar 2011 06:56:05 -0500 Received: from 10.55.91.127 ([10.55.91.127]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([144.254.231.95]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 Mar 2011 11:56:05 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 30 Mar 2011 06:56:04 -0500 From: Benson Schliesser To: "armd@ietf.org" Message-ID: Thread-Topic: Final agenda Thread-Index: Acvu0XIY6QgtzP8se0eaHSIcBGnCQA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384312964_1817662" X-OriginalArrivalTime: 30 Mar 2011 11:56:05.0208 (UTC) FILETIME=[72D13580:01CBEED1] Subject: [armd] Final agenda X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:54:29 -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_3384312964_1817662 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Our final agenda has been updated; sorry for the late changes. It is available at http://www.ietf.org/proceedings/80/agenda/armd.html. Changes from previous version are minor: 1) the Call for Investigation topi= c is moved to the first half of the session; 2) the draft-so-vpn-o-cs presentation has been removed from the agenda, at the presenter=B9s request. Reminder: the session is scheduled for today, 15:10 =AD 16:10 in the Barcelona/Berlin meeting room. Cheers, -Benson & Linda --B_3384312964_1817662 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Final agenda Our final agenda has been updated; sorry for the late changes.  It is= available at = http://www.ietf.org/proceedings/80/agenda/armd.html.

Changes from previous version are minor: 1) the Call for Investigation topi= c is moved to the first half of the session; 2) the draft-so-vpn-o-cs presen= tation has been removed from the agenda, at the presenter’s request.
Reminder: the session is scheduled for today, 15:10 – 16:10 in the Ba= rcelona/Berlin meeting room.

Cheers,
-Benson & Linda
 --B_3384312964_1817662-- From rahul@juniper.net Wed Mar 30 05:20:42 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80873A6947 for ; Wed, 30 Mar 2011 05:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcy6HbcuFj50 for ; Wed, 30 Mar 2011 05:20:41 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 6AA9528C18E for ; Wed, 30 Mar 2011 05:20:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTZMgexUIU+5rBUSwDNa1uWIwIQqsxCVi@postini.com; Wed, 30 Mar 2011 05:22:19 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 30 Mar 2011 05:16:42 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p2UCIDv56585 for ; Wed, 30 Mar 2011 05:18:13 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Wed, 30 Mar 2011 05:18:13 -0700 From: Rahul Aggarwal To: Message-ID: <20110330045300.J40232@sapphire.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Subject: [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: Wed, 30 Mar 2011 12:20:42 -0000 To quote the ARMD charter: "Various requirements for the deployment of VMs in data center networks, such as support for VM mobility, has led to architectures in which broadcast domains are scaling up to span more switching devices and VM servers, and to interconnect more hosts (as represented by VMs)." The above text seems to make an assumption that "VM mobility" requires broadcast domains with large number of switching devices. This assumption needs careful evaluation and this evaluation is necessary for the ARMD WG to come up with a useful problem statement. First there is a need to separate "resource fungibility" requirements from "seamless VM Mobility" requirements. Resource fungibility requires layer 2 domains to be stretched across racks and even data centers, as when a VM is re-located its layer 2 domain must not change. One of the reasons for this is that a layer 2 domain is an administrative property of a VM. However seamless VM mobility does _not_ require VMs, which are in different administrative pools, to be placed in the same layer 2 domain. If there are optimal routing solutions to route across layer 2 domains (read subnets) in the presence of seamless VM mobility, then layer 2 domains can be restricted in size to only what is necessary. There is a mis-conception today that optimal forwarding in the presence of VM mobility requires VMs to be in the same layer 2 domain. To summarise the above, if one were to "route when you can and switch when you must" then it reduces the ARP scaling problem. Ofcourse this may require re-using existing routing technologies in novel ways or extensions to them to support optimal forwarding across subnets. Also this does not mean that ARP scaling solutions within a given layer 2 domain are not relevant. The ARMD WG needs to spell out precise reasons for large layer 2 domains and determine which of these are necessary in which environments. A side effect of this is that ARMD may need to produce requirements for routing technologies. Looking at the entire system i.e., layer 2 and layer 3 will lead ARMD to a clearer problem statement and eventually to better solutions to scaling ARP. rahul From xuxh@huawei.com Wed Mar 30 05:53:09 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 8E74C3A6A3C for ; Wed, 30 Mar 2011 05:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.518 X-Spam-Level: * X-Spam-Status: No, score=1.518 tagged_above=-999 required=5 tests=[AWL=-3.517, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG2I3KlLNnJL for ; Wed, 30 Mar 2011 05:53:08 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id A7A603A6816 for ; Wed, 30 Mar 2011 05:53:08 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV00MWZFVBH7@usaga01-in.huawei.com> for armd@ietf.org; Wed, 30 Mar 2011 07:54:47 -0500 (CDT) Received: from huawei.com ([172.17.1.87]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV00J4CFV9XP@usaga01-in.huawei.com> for armd@ietf.org; Wed, 30 Mar 2011 07:54:47 -0500 (CDT) Received: from [172.24.1.52] (Forwarded-For: [130.129.21.140]) by szxmc02-in.huawei.com (mshttpd); Wed, 30 Mar 2011 14:54:45 +0200 Date: Wed, 30 Mar 2011 14:54:45 +0200 From: xuxiaohu 41208 In-reply-to: <20110330045300.J40232@sapphire.juniper.net> To: Rahul Aggarwal Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <20110330045300.J40232@sapphire.juniper.net> Cc: armd@ietf.org Subject: [armd] =?gb2312?b?u9i4tCA6IExheWVyIDIgdnMgTGF5ZXIgMyBpbiBkYXRh?= =?gb2312?b?IGNlbnRlcnM=?= X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:53:09 -0000 Hi Rahul=2C Did you mean that VMs just need to be located within a subnet=2C rather t= han a layer 2 domain=2C so as to support VM mobility=3F = Best regards=2C Xiaohu ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Rahul Aggarwal =3Crahul=40juniper=2Enet=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =C8=FD=D4=C2 30=C8=D5=2C 2011 =CF=C2= =CE=E72=3A24 =D6=F7=CC=E2=3A =5Barmd=5D Layer 2 vs Layer 3 in data centers =CA=D5=BC=FE=C8=CB=3A armd=40ietf=2Eorg =3E = =3E To quote the ARMD charter=3A =3E = =3E =22Various requirements for the deployment of VMs in data center = =3E networks=2C = =3E such as support for VM mobility=2C has led to architectures in which = =3E broadcast domains are scaling up to span more switching devices = =3E and VM = =3E servers=2C and to interconnect more hosts (as represented by VMs)=2E=22= =3E = =3E The above text seems to make an assumption that =22VM mobility=22 = =3E requires = =3E broadcast domains with large number of switching devices=2E This = =3E assumption = =3E needs careful evaluation and this evaluation is necessary for the = =3E ARMD WG = =3E to come up with a useful problem statement=2E =3E = =3E First there is a need to separate =22resource fungibility=22 = =3E requirements from = =3E =22seamless VM Mobility=22 requirements=2E =3E = =3E Resource fungibility requires layer 2 domains to be stretched = =3E across racks = =3E and even data centers=2C as when a VM is re-located its layer 2 = =3E domain must = =3E not change=2E One of the reasons for this is that a layer 2 domain = =3E is an = =3E administrative property of a VM=2E =3E = =3E However seamless VM mobility does =5Fnot=5F require VMs=2C which are = in = =3E different administrative pools=2C to be placed in the same layer 2 = =3E domain=2E = =3E If there are optimal routing solutions to route across layer 2 = =3E domains = =3E (read subnets) in the presence of seamless VM mobility=2C then layer = =3E 2 domains can = =3E be restricted in size to only what is necessary=2E There is a mis- =3E conception = =3E today that optimal forwarding in the presence of VM mobility = =3E requires = =3E VMs to be in the same layer 2 domain=2E =3E = =3E To summarise the above=2C if one were to =22route when you can and = =3E switch when = =3E you must=22 then it reduces the ARP scaling problem=2E Ofcourse this = =3E may = =3E require re-using existing routing technologies in novel ways or = =3E extensions to them to support optimal forwarding across subnets=2E = =3E Also this = =3E does not mean that ARP scaling solutions within a given layer 2 = =3E domain = =3E are not relevant=2E =3E = =3E The ARMD WG needs to spell out precise reasons for large layer 2 = =3E domains = =3E and determine which of these are necessary in which environments=2E = =3E A side = =3E effect of this is that ARMD may need to produce requirements for = =3E routing = =3E technologies=2E Looking at the entire system i=2Ee=2E=2C layer 2 and = layer = =3E 3 will = =3E lead ARMD to a clearer problem statement and eventually to better = =3E solutions to scaling ARP=2E =3E = =3E rahul =3E = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E armd mailing list =3E armd=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/armd =3E From linda.dunbar@huawei.com Wed Mar 30 05:57:36 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 7D9803A6A1C for ; Wed, 30 Mar 2011 05:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+AuIWGVjOK3 for ; Wed, 30 Mar 2011 05:57:35 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 9D1BA3A6816 for ; Wed, 30 Mar 2011 05:57:35 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV00683G2PJX@usaga02-in.huawei.com> for armd@ietf.org; Wed, 30 Mar 2011 05:59:14 -0700 (PDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LIV006B2G2P1Q@usaga02-in.huawei.com> for armd@ietf.org; Wed, 30 Mar 2011 05:59:13 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 30 Mar 2011 05:59:11 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.54]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 30 Mar 2011 05:59:12 -0700 Date: Wed, 30 Mar 2011 12:59:12 +0000 From: Linda Dunbar In-reply-to: <20110330045300.J40232@sapphire.juniper.net> X-Originating-IP: [10.47.150.177] To: Rahul Aggarwal , "armd@ietf.org" Message-id: <4A95BA014132FF49AE685FAB4B9F17F605129ED6@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [armd] Layer 2 vs Layer 3 in data centers Thread-index: AQHL7tVtR4uT6V0Tbk61WCNNUmjAppRF1jog X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110330045300.J40232@sapphire.juniper.net> 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: Wed, 30 Mar 2011 12:57:36 -0000 If you get into the debate why Layer 2 (but Layer 3 can do everything), then this will turn into a never ending debate. Linda -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Rahul Aggarwal Sent: Wednesday, March 30, 2011 7:18 AM To: armd@ietf.org Subject: [armd] Layer 2 vs Layer 3 in data centers To quote the ARMD charter: "Various requirements for the deployment of VMs in data center networks, such as support for VM mobility, has led to architectures in which broadcast domains are scaling up to span more switching devices and VM servers, and to interconnect more hosts (as represented by VMs)." The above text seems to make an assumption that "VM mobility" requires broadcast domains with large number of switching devices. This assumption needs careful evaluation and this evaluation is necessary for the ARMD WG to come up with a useful problem statement. First there is a need to separate "resource fungibility" requirements from "seamless VM Mobility" requirements. Resource fungibility requires layer 2 domains to be stretched across racks and even data centers, as when a VM is re-located its layer 2 domain must not change. One of the reasons for this is that a layer 2 domain is an administrative property of a VM. However seamless VM mobility does _not_ require VMs, which are in different administrative pools, to be placed in the same layer 2 domain. If there are optimal routing solutions to route across layer 2 domains (read subnets) in the presence of seamless VM mobility, then layer 2 domains can be restricted in size to only what is necessary. There is a mis-conception today that optimal forwarding in the presence of VM mobility requires VMs to be in the same layer 2 domain. To summarise the above, if one were to "route when you can and switch when you must" then it reduces the ARP scaling problem. Ofcourse this may require re-using existing routing technologies in novel ways or extensions to them to support optimal forwarding across subnets. Also this does not mean that ARP scaling solutions within a given layer 2 domain are not relevant. The ARMD WG needs to spell out precise reasons for large layer 2 domains and determine which of these are necessary in which environments. A side effect of this is that ARMD may need to produce requirements for routing technologies. Looking at the entire system i.e., layer 2 and layer 3 will lead ARMD to a clearer problem statement and eventually to better solutions to scaling ARP. rahul _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From bschlies@cisco.com Wed Mar 30 05:59:57 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 00C483A67A8 for ; Wed, 30 Mar 2011 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 aCAN873f0gAy for ; Wed, 30 Mar 2011 05:59:56 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 13B083A67E9 for ; Wed, 30 Mar 2011 05:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1015; q=dns/txt; s=iport; t=1301490095; x=1302699695; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=tZk8OZ1gzk6kzwaZMnjzZddDYJIGE8CvWcMN2nX59i8=; b=Zduq3nD/EoMQL1a5myJpZtYLhnn1odnFioB/W6QVWR296hVwuruTtRA8 m7A/AjwessVA9mtVeMr+qH6xOjKvbWN4FsBVHwWGvjHEdkUU37RA+rKhD 0ytGumAwt10GDwrEkBLdDjpSbVs9JyRjegWNX1JUKAhCPWQZcYZgr+NDt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK4ok02tJXG8/2dsb2JhbAClUHeIeZgBnFuFagSFP4dHg1s X-IronPort-AV: E=Sophos;i="4.63,268,1299456000"; d="scan'208";a="673090038" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2011 13:01:34 +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 p2UD1YlS022768; Wed, 30 Mar 2011 13:01:34 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); Wed, 30 Mar 2011 08:01:34 -0500 Received: from 10.55.91.127 ([10.55.91.127]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([144.254.231.93]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 Mar 2011 13:01:34 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 30 Mar 2011 08:01:34 -0500 From: Benson Schliesser To: Rahul Aggarwal , Message-ID: Thread-Topic: [armd] Layer 2 vs Layer 3 in data centers Thread-Index: Acvu2piPX0wwcOx2+0mOh/XIRR3+MA== In-Reply-To: <20110330045300.J40232@sapphire.juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Mar 2011 13:01:34.0779 (UTC) FILETIME=[990628B0:01CBEEDA] 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: Wed, 30 Mar 2011 12:59:57 -0000 Rahul - On 3/30/11 7:18 AM, "Rahul Aggarwal" wrote: > "Various requirements for the deployment of VMs in data center networks, > such as support for VM mobility, has led to architectures in which > broadcast domains are scaling up to span more switching devices and VM > servers, and to interconnect more hosts (as represented by VMs)." This text provides context for our work. The topic of Virtual Machines, mobility, etc, is out of scope as a primary topic of investigation for ARMD. > The ARMD WG needs to spell out precise reasons for large layer 2 domains > and determine which of these are necessary in which environments. Your message has a number of interesting technical points. However, the charter of ARMD is intentionally narrow, and the chairs have received clear direction from our AD - we will focus on the ARP/ND problem only, in order to make progress on a specific problem. The chairs will discuss this at our upcoming session. Cheers, -Benson From rahul@juniper.net Thu Mar 31 05:50:34 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 B93E13A6B12 for ; Thu, 31 Mar 2011 05:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ+tPuSzonNM for ; Thu, 31 Mar 2011 05:50:33 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 5D4103A6914 for ; Thu, 31 Mar 2011 05:50:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTZR42T75q4LNFYo+k7TqWyA1Jzy74jzB@postini.com; Thu, 31 Mar 2011 05:52:13 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 31 Mar 2011 05:45:19 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p2VCkqv80710; Thu, 31 Mar 2011 05:46:52 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Thu, 31 Mar 2011 05:46:52 -0700 From: Rahul Aggarwal To: Linda Dunbar In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F605129ED6@dfweml503-mbx.china.huawei.com> Message-ID: <20110331054014.O96728@sapphire.juniper.net> References: <20110330045300.J40232@sapphire.juniper.net> <4A95BA014132FF49AE685FAB4B9F17F605129ED6@dfweml503-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed 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: Thu, 31 Mar 2011 12:50:34 -0000 Linda, On Wed, 30 Mar 2011, Linda Dunbar wrote: > If you get into the debate why Layer 2 (but Layer 3 can do everything), Apparently you didn't read my email. I didn't say "Layer 3 can do everything". To just quote one sentence of my email: " Looking at the entire system i.e., layer 2 and layer 3 will lead ARMD to a clearer problem statement and eventually to better solutions to scaling ARP." And: "Also this does not mean that ARP scaling solutions within a given layer 2 domain are not relevant." > then this will turn into a never ending debate. > Any debate that helps this WG to get operator input and do any useful work is good. From the meeting yesterday its fairly clear that at present the foundation of this WG is based on fairly little operator input. rahul > Linda > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Rahul Aggarwal > Sent: Wednesday, March 30, 2011 7:18 AM > To: armd@ietf.org > Subject: [armd] Layer 2 vs Layer 3 in data centers > > > To quote the ARMD charter: > > "Various requirements for the deployment of VMs in data center networks, > such as support for VM mobility, has led to architectures in which > broadcast domains are scaling up to span more switching devices and VM > servers, and to interconnect more hosts (as represented by VMs)." > > The above text seems to make an assumption that "VM mobility" requires > broadcast domains with large number of switching devices. This assumption > needs careful evaluation and this evaluation is necessary for the ARMD WG > to come up with a useful problem statement. > > First there is a need to separate "resource fungibility" requirements from > "seamless VM Mobility" requirements. > > Resource fungibility requires layer 2 domains to be stretched across racks > and even data centers, as when a VM is re-located its layer 2 domain must > not change. One of the reasons for this is that a layer 2 domain is an > administrative property of a VM. > > However seamless VM mobility does _not_ require VMs, which are in > different administrative pools, to be placed in the same layer 2 domain. > If there are optimal routing solutions to route across layer 2 domains > (read subnets) in the presence of seamless VM mobility, then layer 2 domains can > be restricted in size to only what is necessary. There is a mis-conception > today that optimal forwarding in the presence of VM mobility requires > VMs to be in the same layer 2 domain. > > To summarise the above, if one were to "route when you can and switch when > you must" then it reduces the ARP scaling problem. Ofcourse this may > require re-using existing routing technologies in novel ways or > extensions to them to support optimal forwarding across subnets. Also this > does not mean that ARP scaling solutions within a given layer 2 domain > are not relevant. > > The ARMD WG needs to spell out precise reasons for large layer 2 domains > and determine which of these are necessary in which environments. A side > effect of this is that ARMD may need to produce requirements for routing > technologies. Looking at the entire system i.e., layer 2 and layer 3 will > lead ARMD to a clearer problem statement and eventually to better > solutions to scaling ARP. > > rahul > > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > From rahul@juniper.net Thu Mar 31 05:56:34 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 580943A6914 for ; Thu, 31 Mar 2011 05:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwruiVXGE7rc for ; Thu, 31 Mar 2011 05:56:33 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 47A843A6952 for ; Thu, 31 Mar 2011 05:56:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTZR6XjM/Hmx0DH7Wzi18QAbauqJREOvD@postini.com; Thu, 31 Mar 2011 05:58:13 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 31 Mar 2011 05:52:53 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p2VCsQv83486; Thu, 31 Mar 2011 05:54:26 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Thu, 31 Mar 2011 05:54:26 -0700 From: Rahul Aggarwal To: Benson Schliesser In-Reply-To: Message-ID: <20110331054719.Q96728@sapphire.juniper.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed 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: Thu, 31 Mar 2011 12:56:34 -0000 Benson, Rahul> The ARMD WG needs to spell out precise reasons for large layer 2 domains Rahul> and determine which of these are necessary in which environments. Benson> Your message has a number of interesting technical points. However, the > charter of ARMD is intentionally narrow, and the chairs have received clear > direction from our AD - we will focus on the ARP/ND problem only, in order > to make progress on a specific problem. > 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 charter as written is not "narrow". For example from the charter: "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"? rahul From bschlies@cisco.com Thu Mar 31 07:13:59 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 32D4D3A6B33 for ; Thu, 31 Mar 2011 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.766 X-Spam-Level: X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[AWL=-0.564, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2SRHZ69AuL5 for ; Thu, 31 Mar 2011 07:13:53 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3BE8B3A6B13 for ; Thu, 31 Mar 2011 07:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=4350; q=dns/txt; s=iport; t=1301580933; x=1302790533; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=+3gzex059byrFsya8qslYTadKgV3sWsOCV2M9fiL3LE=; b=DRWwX9iecHEY4F/TwNa+eI2x8Jpk3VP4RWvG7iHCp5Ag23Kt7Ojpkzge /KJpJMliMBdEZMX+9BDLW68GS4aZGjTOMe4exmiUb+2wmnWyQe/oSfiwN wtLHG3sa/X7FK51r2cq4AyIUQSZr91fVU5rcgLLHeUKJvAPBJNGtXoJbO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADmMlE2tJV2a/2dsb2JhbACCXpt1AYYZYHeIeZoLnBOFawSFQYdQg1s X-IronPort-AV: E=Sophos;i="4.63,275,1299456000"; d="scan'208,217";a="286566326" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2011 14:15:32 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2VEFWOw013607; Thu, 31 Mar 2011 14:15:32 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 09:15:32 -0500 Received: from 10.55.91.240 ([10.55.91.240]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([144.254.231.95]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Mar 2011 14:15:31 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 31 Mar 2011 09:15:32 -0500 From: Benson Schliesser To: Rahul Aggarwal Message-ID: Thread-Topic: [armd] Layer 2 vs Layer 3 in data centers Thread-Index: Acvvrhg6zX17tjPHME+BjUxgF4HBNg== In-Reply-To: <20110331054719.Q96728@sapphire.juniper.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384407733_4189620" X-OriginalArrivalTime: 31 Mar 2011 14:15:32.0303 (UTC) FILETIME=[186855F0:01CBEFAE] 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: Thu, 31 Mar 2011 14:13:59 -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_3384407733_4189620 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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" >=20 > "Recommendations on data center L2/L3 architectures and > identification of opportunities for protocol development work" >=20 > 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 help manage the WG after it was written. My personal view is that the abov= e 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 / actionable 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 something else, then ARMD is not the working group you=B9re looking for. But I encourage you to contribute within the WG scope. Cheers, -Benson --B_3384407733_4189620 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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.

> "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&= 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 a= bove statements, taken by themselves, are so broad as to be meaningless in t= he context of a working group - they do not lead us toward a specific / acti= onable goal.  Thus, they must be interpreted in the context of our obje= ctives: 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.o= rg/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’re looking for.  = But I encourage you to contribute within the WG scope.

Cheers,
-Benson
 --B_3384407733_4189620-- From prvs=7071a0f4f3=hshah@ciena.com Thu Mar 31 08:08:09 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 B9FDB3A6B5B for ; Thu, 31 Mar 2011 08:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfeAhcBreJo7 for ; Thu, 31 Mar 2011 08:08:08 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by core3.amsl.com (Postfix) with ESMTP id ABB8C3A67FC for ; Thu, 31 Mar 2011 08:08:08 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p2VF9juB009571; Thu, 31 Mar 2011 11:09:46 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id vcuuh0134-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 31 Mar 2011 11:09:46 -0400 Received: from mdmxm05.ciena.com (63.118.39.23) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server id 8.1.436.0; Thu, 31 Mar 2011 11:09:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEFB5.AAD34429" Date: Thu, 31 Mar 2011 11:06:13 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [armd] Layer 2 vs Layer 3 in data centers Thread-Index: Acvvrhg6zX17tjPHME+BjUxgF4HBNgABxTWM References: From: "Shah, Himanshu" To: "Benson Schliesser" , "Rahul Aggarwal" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-31_05:2011-03-31, 2011-03-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1103310065 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: Thu, 31 Mar 2011 15:08:09 -0000 ------_=_NextPart_001_01CBEFB5.AAD34429 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Ben's interpretation of the charter. Why-not-L3-solutions or lets-first-see-if-network-buildout-is-correct would be an open ended exercise with no foreseeable outcome. IMO, himanshu=20 -----Original Message----- From: armd-bounces@ietf.org on behalf of Benson Schliesser Sent: Thu 3/31/2011 10:15 AM To: Rahul Aggarwal Cc: armd@ietf.org Subject: Re: [armd] Layer 2 vs Layer 3 in data centers =20 Rahul - On 3/31/11 7:54 AM, "Rahul Aggarwal" 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 > 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" >=20 > "Recommendations on data center L2/L3 architectures and > identification of opportunities for protocol development work" >=20 > 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 help 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 / actionable 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 something else, then ARMD is not the working group you=B9re = looking for. But I encourage you to contribute within the WG scope. Cheers, -Benson ------_=_NextPart_001_01CBEFB5.AAD34429 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [armd] Layer 2 vs Layer 3 in data centers

I agree with Ben's interpretation of the charter.
Why-not-L3-solutions or = lets-first-see-if-network-buildout-is-correct
would be an open ended exercise with no foreseeable outcome.

IMO,
himanshu

-----Original Message-----
From: armd-bounces@ietf.org on behalf of Benson Schliesser
Sent: Thu 3/31/2011 10:15 AM
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" <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
> 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
help 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 /
actionable 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.i= etf.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 something else, then ARMD is not the working group you=B9re = looking
for.  But I encourage you to contribute within the WG scope.

Cheers,
-Benson

------_=_NextPart_001_01CBEFB5.AAD34429-- From dunbar.ll@gmail.com Thu Mar 31 09:44:14 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 7E87E3A699E for ; Thu, 31 Mar 2011 09:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAB44ri75UWD for ; Thu, 31 Mar 2011 09:44:13 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id C24703A6930 for ; Thu, 31 Mar 2011 09:44:12 -0700 (PDT) Received: by eye13 with SMTP id 13so915522eye.31 for ; Thu, 31 Mar 2011 09:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ur+8DPptFzlGas2OWEke4g7TCtl5MaH0B5fUbHU+MFE=; b=VqRjU1/oWJpZJgLTkLu2ptgqL3i2iHjjDXKKMwEGw49/HctcwJU93pk4usAyoKC6ds 3UqxHx0KkAuOkhEAEdryU+bhWnFIihJlq5LjKk5c4Fan41SLAmTuFLBl83whQ3NSrZOm B/X6yN3B/tKfilmdWiucHm4NYeLDW4NDyU4AE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=yFrXl5ZSHMA9n2Mu+pWCk68uoOtK/17XpOPgSM9lAHtbqlhbSzx1MvEbBpXMJqr2mS ldnHQrxb/tMd9ILEjY9lWkIh9/fnJ97jz3grBBAN4OjSpnV/h2rI9k+g1wJ1SRceSL5B EVdHFT45VcNOc2OkDa/LDmW0KbL5tcUuE3lSs= MIME-Version: 1.0 Received: by 10.216.123.74 with SMTP id u52mr2675840weh.24.1301589951578; Thu, 31 Mar 2011 09:45:51 -0700 (PDT) Received: by 10.216.176.3 with HTTP; Thu, 31 Mar 2011 09:45:51 -0700 (PDT) In-Reply-To: <20110331054014.O96728@sapphire.juniper.net> References: <20110330045300.J40232@sapphire.juniper.net> <4A95BA014132FF49AE685FAB4B9F17F605129ED6@dfweml503-mbx.china.huawei.com> <20110331054014.O96728@sapphire.juniper.net> Date: Thu, 31 Mar 2011 11:45:51 -0500 Message-ID: From: Linda Dunbar To: Rahul Aggarwal Content-Type: multipart/alternative; boundary=485b3988adc9b512e4049fca0660 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: Thu, 31 Mar 2011 16:44:14 -0000 --485b3988adc9b512e4049fca0660 Content-Type: text/plain; charset=ISO-8859-1 Rahul, One of the ARMD goals is to get the operators' opinions expressed to make sure we are addressing the right problems and to increase the community input. This is explicit in the charter. We have talked to many data center operators (e.g. Microsoft being one of the authors). We will talk to more operators at the next NANOG. Hopefully the next version of problem statements will reflect more problems from operator's view. Of course, there are thousands of Data centers, all with different network designs. Some may (and will) be missed. Linda On Thu, Mar 31, 2011 at 7:46 AM, Rahul Aggarwal wrote: > > Linda, > > > On Wed, 30 Mar 2011, Linda Dunbar wrote: > > If you get into the debate why Layer 2 (but Layer 3 can do everything), >> > > Apparently you didn't read my email. I didn't say "Layer 3 can do > everything". To just quote one sentence of my email: > > > " Looking at the entire system i.e., layer 2 and layer 3 will > lead ARMD to a clearer problem statement and eventually to better > solutions to scaling ARP." > > And: > > > "Also this does not mean that ARP scaling solutions within a given layer 2 > domain are not relevant." > > then this will turn into a never ending debate. >> >> > Any debate that helps this WG to get operator input and do any useful work > is good. From the meeting yesterday its fairly clear that at present the > foundation of this WG is based on fairly little operator input. > > rahul > > > Linda >> >> -----Original Message----- >> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of >> Rahul Aggarwal >> Sent: Wednesday, March 30, 2011 7:18 AM >> To: armd@ietf.org >> Subject: [armd] Layer 2 vs Layer 3 in data centers >> >> >> To quote the ARMD charter: >> >> "Various requirements for the deployment of VMs in data center networks, >> such as support for VM mobility, has led to architectures in which >> broadcast domains are scaling up to span more switching devices and VM >> servers, and to interconnect more hosts (as represented by VMs)." >> >> The above text seems to make an assumption that "VM mobility" requires >> broadcast domains with large number of switching devices. This assumption >> needs careful evaluation and this evaluation is necessary for the ARMD WG >> to come up with a useful problem statement. >> >> First there is a need to separate "resource fungibility" requirements from >> "seamless VM Mobility" requirements. >> >> Resource fungibility requires layer 2 domains to be stretched across racks >> and even data centers, as when a VM is re-located its layer 2 domain must >> not change. One of the reasons for this is that a layer 2 domain is an >> administrative property of a VM. >> >> However seamless VM mobility does _not_ require VMs, which are in >> different administrative pools, to be placed in the same layer 2 domain. >> If there are optimal routing solutions to route across layer 2 domains >> (read subnets) in the presence of seamless VM mobility, then layer 2 >> domains can >> be restricted in size to only what is necessary. There is a mis-conception >> today that optimal forwarding in the presence of VM mobility requires >> VMs to be in the same layer 2 domain. >> >> To summarise the above, if one were to "route when you can and switch when >> you must" then it reduces the ARP scaling problem. Ofcourse this may >> require re-using existing routing technologies in novel ways or >> extensions to them to support optimal forwarding across subnets. Also this >> does not mean that ARP scaling solutions within a given layer 2 domain >> are not relevant. >> >> The ARMD WG needs to spell out precise reasons for large layer 2 domains >> and determine which of these are necessary in which environments. A side >> effect of this is that ARMD may need to produce requirements for routing >> technologies. Looking at the entire system i.e., layer 2 and layer 3 will >> lead ARMD to a clearer problem statement and eventually to better >> solutions to scaling ARP. >> >> rahul >> >> >> >> _______________________________________________ >> armd mailing list >> armd@ietf.org >> https://www.ietf.org/mailman/listinfo/armd >> >> _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > --485b3988adc9b512e4049fca0660 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Rahul,
=A0
One of the ARMD goals is to get the operators' opinio= ns expressed to make sure we are addressing the right problems and to incre= ase the community input. This is explicit in the charter.
=A0
We have talked to many data center operators (e.g. Micros= oft being one of the authors). We will talk to more operators at the next N= ANOG. Hopefully the next version of problem statements will=A0reflect more= =A0problems from operator's view. Of course, there are thousands of Dat= a centers, all with different network designs. Some may (and will) be misse= d.
=A0
Linda
On Thu, Mar 31, 2011 at 7:46 AM, Rahul Aggarwal = <rahul@juniper.ne= t> wrote:

Linda,=20


On Wed, 30 Mar 2011, Linda Dunbar wrote:

If you get into the debate why L= ayer 2 (but Layer 3 can do everything),

Apparentl= y you didn't read my email. I didn't say "Layer 3 can do every= thing". To just quote one sentence of my email:=20


" Looking at the entire system i.e., layer 2= and layer 3 will
lead ARMD to a clearer problem statement and eventuall= y to better
solutions to scaling ARP."

And:=20


"Also this does not mean that ARP scaling so= lutions within a given layer 2 domain are not relevant."

then this will turn into a never= ending debate.


Any debate that helps this WG= to get operator input and do any useful work is good. From the meeting yes= terday its fairly clear that at present the foundation of this WG is based = on fairly little operator input.

rahul=20


Linda

-----Original Messa= ge-----
From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Rahul Aggarwal Sent: Wednesday, March 30, 2011 7:18 AM
To: armd@ietf.org
Subject: [armd] Layer 2 vs Laye= r 3 in data centers


To quote the ARMD charter:

"Vari= ous requirements for the deployment of VMs in data center networks,
such as support for VM mobility, has led to architectures in which
broad= cast domains are scaling up to span more switching devices and VM
server= s, and to interconnect more hosts (as represented by VMs)."

The above text seems to make an assumption that "VM mobility" req= uires
broadcast domains with large number of switching devices. This ass= umption
needs careful evaluation and this evaluation is necessary for th= e ARMD WG
to come up with a useful problem statement.

First there is a need to= separate "resource fungibility" requirements from
"seaml= ess VM Mobility" requirements.

Resource fungibility requires la= yer 2 domains to be stretched across racks
and even data centers, as when a VM is re-located its layer 2 domain mustnot change. One of the reasons for this is that a layer 2 domain is anadministrative property of a VM.

However seamless VM mobility does = _not_ require VMs, which are in
different administrative pools, to be placed in the same layer 2 domain.If there are optimal routing solutions to route across layer 2 domains
= (read subnets) in the presence of seamless VM mobility, then layer 2 domain= s can
be restricted in size to only what is necessary. There is a mis-conception<= br>today that optimal forwarding in the presence of VM mobility requiresVMs to be in the same layer 2 domain.

To summarise the above, if on= e were to "route when you can and switch when
you must" then it reduces the ARP scaling problem. Ofcourse this mayrequire re-using existing routing technologies in novel ways or
extens= ions to them to support optimal forwarding across subnets. Also this
does not mean that ARP scaling solutions within a given layer 2 domain
a= re not relevant.

The ARMD WG needs to spell out precise reasons for = large layer 2 domains
and determine which of these are necessary in whic= h environments. A side
effect of this is that ARMD may need to produce requirements for routingtechnologies. Looking at the entire system i.e., layer 2 and layer 3 will<= br>lead ARMD to a clearer problem statement and eventually to better
solutions to scaling ARP.

rahul



_____________________= __________________________
armd mailing list
armd@ietf.org
https://www.ietf.org/mailman/= listinfo/armd

_______________________________________________
armd ma= iling list
armd@ietf.= org
https://www.ietf.org/mailman/listinfo/armd

--485b3988adc9b512e4049fca0660--