From ghanwani@gmail.com Thu May 3 19:21:56 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6A721F86C2 for ; Thu, 3 May 2012 19:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-1lD8a55+X7 for ; Thu, 3 May 2012 19:21:55 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC6721F86BE for ; Thu, 3 May 2012 19:21:55 -0700 (PDT) Received: by dadz9 with SMTP id z9so3437135dad.39 for ; Thu, 03 May 2012 19:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ogvjhsOkGyr7zXNEC2ZCj/8pBPY+l6rfFgP4GmuDJEs=; b=ejUPfVkA3Abra8dqKURsFNKY5bUivm4OEHRs52eGiRQcGVEAKkCq1YWz/dM9YCv8M8 W3k62FJjKFBWJWKch8MSEg50eZxAciJ/7TZ0qkcy5Vy7RlJdsmFw5UxTc8M760PhXSAP jQXzDE1KYdMQJVT2PnC6fPUVi9lVqZk2KI/Wv6SwlW84Q8VF6D8BLHDbC/HzZW+q5jZg /JPt5qfHz/XzrQ6IqIhHTKLzvc0CiNlERqwD1dJDxQiYvJ/AY3GD01VBW0tzIVV0M0fz 3XwWsLKTpqPTqZtyY2/yzW8iBYeykzYEYzVFrFEY2hTM16AdvtgUQji9T0zvcniPWmTW 9X6Q== MIME-Version: 1.0 Received: by 10.68.129.99 with SMTP id nv3mr12609436pbb.161.1336098115102; Thu, 03 May 2012 19:21:55 -0700 (PDT) Received: by 10.142.153.18 with HTTP; Thu, 3 May 2012 19:21:54 -0700 (PDT) Date: Thu, 3 May 2012 19:21:54 -0700 Message-ID: From: Anoop Ghanwani To: armd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [armd] review of X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: anoop@alumni.duke.edu List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 02:21:56 -0000 As one of the people who had volunteered to review draft-ietf-armd-problem-statement-02, here are my comments on the document. They are mostly editorial but there are a few minor issues with the content. Otherwise, the document accurately captures the gist of the problem. Anoop =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All sections =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For consistency Data Center -> data center Access Layer, Access layer -> access layer Aggregation Layer, Aggregation layer -> aggregation layer Layer 2, layer 2 -> L2 Layer 3, layer 3 -> L3 Use ARP Request or ARP request consistently (prefer ARP Request) Section 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D datacenters -> data centers Section 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D In the definition for VM: Replace "bare" with "physical, non-virtualized". In the definition for EoR: Delete extraneous "network". Section 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Change "poor implementations of loop detection and prevention" to "poor implementations of loop detection and prevention or misconfiguration errors". Change "With virtualization, a single physical server can host 10 (or more) VMs, each having its own IP (and MAC) addresses" to "With virtualization, a single physical server can host many VMs, each having its own network interfaces with IP and MAC addresses." [The number is captured in a later sentence.] "services" is used all over the place, but there is no definition for services. =A0=C4pplication, however, is defined. =A0I think what is meant here is application. Last paragraph: These number -> This number. Below Figure 1: Delete "Figure 1". Section 4.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Change "The access switches might be placed either on =A0 top-of-rack (ToR) or at end-of-row (EoR) physical configuration." to "The access layer may be implemented by wiring the servers within a rack to a =A0top-of-rack (ToR) switch or, less commonly, the servers could be wired directly to an end-of-row (EoR) switch." Section 4.4.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For consistency with the following 2 sections change title from Layer 3 to L3. "This topology is ideal for scenarios where servers =A0 attached to a particular access switch generally run applications =A0 that are are confined to using a single subnet." I'm not sure I agree with this. There are many issues surround this including the capabilities of the devices in the network, the use of the multicast, and the preferences of the network administrator. Section 4.4.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "This topology allows for a great deal of flexibility as servers attached to one access switch can be re- loaded with applications with different IP prefix and VMs can now migrate between racks without IP address changes. " to "This topology allows a greater level of flexibility as servers attached to any access switch can be reloaded with applications and provisioned with IP addresses from multiple prefixes as needed. Further, in such an environment, VMs can migrate between racks without IP address changes. Change "layer 2 traffic are still partitioned by VLANs" to "layer 2 traffic is still partitioned using VLANs" "Even though layer 2 traffic are still partitioned by VLANs, the fact that all VLANs are enabled on all ports can lead to broadcast traffic on all VLANs to traverse all links and ports, which is same effect as one big Layer 2 domain. " I disagree with this because all VLANs would only need to be provisioned on the aggregation-facing ports. The disadvantage here is that a lot more broadcast traffic hits the aggregation layer, and when we need to cross VLAN boundaries, the traffic must go all way to the aggregation switch even though the source and destination may be on the same access switch, and the requirement for larger ARP tables at the aggregation switches. Section 4.4.4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " There are several approaches regarding how overlay networks can make very large layer 2 network scale and enable mobility. " to "There are several approaches where overlay networks can be used to build very large L2 networks to enable VM mobility" "This can help the data center designer to control the size of the L2 domain. " It should be clarified that this only applies when L3 overlays are in use. "However, the Overlay Edge switches/routers which perform the network address encapsulation/decapsulation must ultimately perform a L2 address resolution and could still potentially face scaling issues at that point." It's not the overlay edge switches that have the scaling problem, its the volume of broadcasts that need to be sent across the core and that is not helped simply by using an L3 overlay. Change "physical addresses (MAC)" to "physical (MAC) addresses" For consistency, change "Layer 2 / Layer 3 boundary" to L2/L3 boundary Section 4.5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Change "appropriately sized Access, Aggregation and Core networks" to "appropriately sized access, aggregation and core layers" Change "Broadly speaking it is desirable" to "Broadly speaking, it is desirable" Section 5 =3D=3D=3D=3D=3D=3D=3D=3D=3D ARP response -> ARP Reply rerun ARP -> reissue an ARP Request Section 6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Thus, whereas all nodes must process every ARP query, ND queries are processed only by the nodes to which they are intended." When virtualization is in use, the NIC is often operated in promiscuous mode, which means that the packet would be delivered to the hypervisor/vswitch and the filtering would have to be done there (usually implemented in software), making the problem almost as bad as with ARP. Section 7.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D ARP query -> ARP Request Change "One common router implementation architecture has ARP processing handled" to "ARP processing in routers is commonly handled..." revalidate timer -> aging timer their ASIC fast paths -> their forwarding ASICs target's Subnet -> target's subnet Section 7.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D nodes to which they are intended -> nodes for which they are intended Section 7.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ten (or more) VMs -> many VMs (in the 10's today, but growing rapidly as the number of cores per CPU increases) From ghanwani@gmail.com Thu May 3 19:22:58 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283B421F86C2 for ; Thu, 3 May 2012 19:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.405 X-Spam-Level: X-Spam-Status: No, score=-3.405 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1ClKJwI1GbZ for ; Thu, 3 May 2012 19:22:56 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFA1F21F86BE for ; Thu, 3 May 2012 19:22:56 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3289158pbc.31 for ; Thu, 03 May 2012 19:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=QFPOTllsgLbYELdZMsivIk8MUCehsgHYj5pM/bwj3Qo=; b=ISjft21at7winbBsgeML8KmzJGVp4hgZ/flH31+jIxZjWJTb5GM19MQ/e+Vsa0/Pct hY8yHlxkVM9Dm1j7xo6f5iF8lfn4fyeQYKAbxvDI+fG0ILBq2E5e9cdsLpIqzK3tjg29 ivD0OH4/VU0cwjUoN3sZqoHL7Y2c9JtYup+/HezLvMKOAMHlKMr1LaPcK9GySd00O8IM 4kIunG9rIDT2oEW+ul9qf0YDblF0o28emuF9JdPo7PZy0eeAqpVnLoV4Ya/bFtLIlAHD MJwT2va6NMGBfWQNb/NaEdGVwZ3QKcmeDt9tU9m7EHQku/iGaKOzMux8ctCFpbDdyr/c CqYw== MIME-Version: 1.0 Received: by 10.68.221.194 with SMTP id qg2mr1287802pbc.18.1336098176476; Thu, 03 May 2012 19:22:56 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.142.153.18 with HTTP; Thu, 3 May 2012 19:22:56 -0700 (PDT) Date: Thu, 3 May 2012 19:22:56 -0700 X-Google-Sender-Auth: 4ATqj9yTPvts9gtua11asLWtAcU Message-ID: From: Anoop Ghanwani To: armd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [armd] review of draft-ietf-armd-problem-statement-02 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 02:22:58 -0000 Fixed the subject. ---------- Forwarded message ---------- From: Anoop Ghanwani Date: Thu, May 3, 2012 at 7:21 PM Subject: review of To: armd@ietf.org As one of the people who had volunteered to review draft-ietf-armd-problem-statement-02, here are my comments on the document. =A0They are mostly editorial but there are a few minor issues with the content. Otherwise, the document accurately captures the gist of the problem. Anoop =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All sections =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For consistency Data Center -> data center Access Layer, Access layer -> access layer Aggregation Layer, Aggregation layer -> aggregation layer Layer 2, layer 2 -> L2 Layer 3, layer 3 -> L3 Use ARP Request or ARP request consistently (prefer ARP Request) Section 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D datacenters -> data centers Section 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D In the definition for VM: Replace "bare" with "physical, non-virtualized". In the definition for EoR: Delete extraneous "network". Section 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D Change "poor implementations of loop detection and prevention" to "poor implementations of loop detection and prevention or misconfiguration errors". Change "With virtualization, a single physical server can host 10 (or more) VMs, each having its own IP (and MAC) addresses" to "With virtualization, a single physical server can host many VMs, each having its own network interfaces with IP and MAC addresses." [The number is captured in a later sentence.] "services" is used all over the place, but there is no definition for services. =A0=C4pplication, however, is defined. =A0I think what is meant here is application. Last paragraph: These number -> This number. Below Figure 1: Delete "Figure 1". Section 4.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Change "The access switches might be placed either on =A0 top-of-rack (ToR) or at end-of-row (EoR) physical configuration." to "The access layer may be implemented by wiring the servers within a rack to a =A0top-of-rack (ToR) switch or, less commonly, the servers could be wired directly to an end-of-row (EoR) switch." Section 4.4.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For consistency with the following 2 sections change title from Layer 3 to L3. "This topology is ideal for scenarios where servers =A0 attached to a particular access switch generally run applications =A0 that are are confined to using a single subnet." I'm not sure I agree with this. =A0There are many issues surround this including the capabilities of the devices in the network, the use of the multicast, and the preferences of the network administrator. Section 4.4.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "This topology allows for a great deal =A0 of flexibility as servers attached to one access switch can be re- =A0 loaded with applications with different IP prefix and VMs can now =A0 migrate between racks without IP address changes. " to "This topology allows a greater level of flexibility as servers attached to any access switch can be reloaded with applications and provisioned with IP addresses from multiple prefixes as needed. =A0Further, in such an environment, VMs can migrate between racks without IP address changes. Change "layer 2 traffic are still partitioned by VLANs" to "layer 2 traffic is still partitioned using VLANs" "Even though =A0 layer 2 traffic are still partitioned by VLANs, the fact that all =A0 VLANs are enabled on all ports can lead to broadcast traffic on all =A0 VLANs to traverse all links and ports, which is same effect as one =A0 big Layer 2 domain. " I disagree with this because all VLANs would only need to be provisioned on the aggregation-facing ports. The disadvantage here is that a lot more broadcast traffic hits the aggregation layer, and when we need to cross VLAN boundaries, the traffic must go all way to the aggregation switch even though the source and destination may be on the same access switch, and the requirement for larger ARP tables at the aggregation switches. Section 4.4.4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " =A0 There are several approaches regarding how overlay networks can make =A0 very large layer 2 network scale and enable mobility. " to "There are several approaches where overlay networks can be used to build very large L2 networks to enable VM mobility" "This can help the data =A0 center designer to control the size of the L2 domain. =A0" It should be clarified that this only applies when L3 overlays are in use. "However, the =A0 Overlay Edge switches/routers which perform the network address =A0 encapsulation/decapsulation must ultimately perform a L2 address =A0 resolution and could still potentially face scaling issues at that =A0 point." It's not the overlay edge switches that have the scaling problem, its the volume of broadcasts that need to be sent across the core and that is not helped simply by using an L3 overlay. Change "physical addresses (MAC)" to "physical (MAC) addresses" For consistency, change "Layer 2 / Layer 3 boundary" to L2/L3 boundary Section 4.5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Change "appropriately sized Access, Aggregation and Core networks" to "appropriately sized access, aggregation and core layers" Change "Broadly speaking it is desirable" to "Broadly speaking, it is desirable" Section 5 =3D=3D=3D=3D=3D=3D=3D=3D=3D ARP response -> ARP Reply rerun ARP -> reissue an ARP Request Section 6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Thus, whereas all =A0 nodes must process every ARP query, ND queries are processed only by =A0 the nodes to which they are intended." When virtualization is in use, the NIC is often operated in promiscuous mode, which means that the packet would be delivered to the hypervisor/vswitch and the filtering would have to be done there (usually implemented in software), making the problem almost as bad as with ARP. Section 7.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D ARP query -> ARP Request Change =A0 "One common router implementation architecture has ARP processing =A0 handled" to "ARP processing in routers is commonly handled..." revalidate timer -> aging timer their ASIC fast paths -> their forwarding ASICs target's Subnet -> target's subnet Section 7.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D nodes to which they are intended -> nodes for which they are intended Section 7.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ten (or =A0more) VMs -> many VMs (in the 10's today, but growing rapidly as the number of cores per CPU increases) From vhpc@crs4.it Mon May 7 23:41:52 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F4621F85D0 for ; Mon, 7 May 2012 23:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.169 X-Spam-Level: X-Spam-Status: No, score=0.169 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EY8kBz-aIk3 for ; Mon, 7 May 2012 23:41:51 -0700 (PDT) Received: from raffaello.crs4.it (raffaello.crs4.it [156.148.72.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5EABE21F85C2 for ; Mon, 7 May 2012 23:41:39 -0700 (PDT) Received: from smtp.crs4.it (smtp.crs4.it [156.148.18.19]) by raffaello.crs4.it (Postfix) with ESMTP id 2301B790204 for ; Tue, 8 May 2012 08:41:37 +0200 (CEST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.crs4.it (Postfix) with ESMTPSA id DE3DE97CA4 for ; Tue, 8 May 2012 06:41:59 +0200 (CEST) Received: by vbbez10 with SMTP id ez10so1062531vbb.31 for ; Mon, 07 May 2012 23:41:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.23.199 with SMTP id o7mr2279123vdf.16.1336459295643; Mon, 07 May 2012 23:41:35 -0700 (PDT) Received: by 10.52.90.11 with HTTP; Mon, 7 May 2012 23:41:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 May 2012 08:41:35 +0200 Message-ID: From: Paolo Anedda To: armd@ietf.org Content-Type: multipart/alternative; boundary=20cf3071c93c92d76b04bf80ad89 X-Mailman-Approved-At: Tue, 08 May 2012 08:06:43 -0700 Subject: [armd] VHPC '12 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 06:41:52 -0000 --20cf3071c93c92d76b04bf80ad89 Content-Type: text/plain; charset=ISO-8859-1 Dear Mailing List Members, we have extended the submission deadline to the 11th of June, please find the updated CfP for circulation attached. There will be no further extensions!! Regards, Best Regards, Michael Alexander, Gianluigi Zanetti and Anastassios Nanos VHPC'12 Chairs ============================== ===================================== CALL FOR PAPERS 7th Workshop on Virtualization in High-Performance Cloud Computing VHPC '12 as part of Euro-Par 2012, Rhodes Island, Greece =================================================================== Date: August 28, 2012 Workshop URL: http://vhpc.org SUBMISSION DEADLINE: June 11, 2012 - Full paper submission (extended) SCOPE: Virtualization has become a common abstraction layer in modern data centers, enabling resource owners to manage complex infrastructure independently of their applications. Conjointly, virtualization is becoming a driving technology for a manifold of industry grade IT services. The cloud concept includes the notion of a separation between resource owners and users, adding services such as hosted application frameworks and queueing. Utilizing the same infrastructure, clouds carry significant potential for use in high-performance scientific computing. The ability of clouds to provide for requests and releases of vast computing resources dynamically and close to the marginal cost of providing the services is unprecedented in the history of scientific and commercial computing. Distributed computing concepts that leverage federated resource access are popular within the grid community, but have not seen previously desired deployed levels so far. Also, many of the scientific data centers have not adopted virtualization or cloud concepts yet. This workshop aims to bring together industrial providers with the scientific community in order to foster discussion, collaboration and mutual exchange of knowledge and experience. The workshop will be one day in length, composed of 20 min paper presentations, each followed by 10 min discussion sections. Presentations may be accompanied by interactive demonstrations. TOPICS Topics of interest include, but are not limited to: Higher-level cloud architectures, focusing on issues such as: - Languages for describing highly-distributed compute jobs - Workload characterization for VM-based environments - Optimized communication libraries/protocols in the cloud - Cross-layer optimization of numeric algorithms on VM infrastructure - System and process/bytecode VM convergence - Cloud frameworks and API sets - Checkpointing/migration of large compute jobs - Instrumentation interfaces and languages - VMM performance (auto-)tuning on various load types - Cloud reliability, fault-tolerance, and security - Software as a Service (SaaS) architectures - Research and education use cases - Virtualization in cloud, cluster and grid environments - Cross-layer VM optimizations - Cloud use cases including optimizations - VM-based cloud performance modelling - Performance and cost modelling Lower-level design challenges for Hypervisors, VM-aware I/O devices, hardware accelerators or filesystems in VM environments, especially: - Cloud, grid and distributed filesystems - Hardware for I/O virtualization (storage/network/accelerators) - Storage and network I/O subsystems in virtualized environments - Novel software approaches to I/O virtualization - Paravirtualized I/O subsystems for modified/unmodified guests - Virtualization-aware cluster interconnects - Direct device assignment - NUMA-aware subsystems in virtualized environments - Hardware Accelerators in virtualization (GPUs/FPGAs) - Hardware extensions for virtualization - VMMs/Hypervisors for embedded systems Data Center management methods, including: - QoS and and service levels - VM cloud and cluster distribution algorithms - VM load-balancing in Clouds - Hypervisor extensions and tools for cluster and grid computing - Fault tolerant VM environments - Virtual machine monitor platforms - Management, deployment and monitoring of VM-based environments - Cluster provisioning in the Cloud PAPER SUBMISSION Papers submitted to the workshop will be reviewed by at least two members of the program committee and external reviewers. Submissions should include abstract, key words, the e-mail address of the corresponding author, and must not exceed 10 pages, including tables and figures at a main font size no smaller than 11 point. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. Accepted papers will be published in the Springer LNCS series - the format must be according to the Springer LNCS Style. Initial submissions are in PDF; authors of accepted papers will be requested to provide source files. Format Guidelines: http://www.springer.de/comp/lncs/authors.html Style template: ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip Abstract Submission Link: http://edas.info/newPaper.php?c=11943 IMPORTANT DATES Rolling abstract submission June 11, 2012 - Full paper submission (extended) June 29, 2012 - Acceptance notification July 20, 2012 - Camera-ready version due August 28, 2012 - Workshop Date CHAIR Michael Alexander (chair), TU Wien, Austria Gianluigi Zanetti (co-chair), CRS4, Italy Anastassios Nanos (co-chair), NTUA, Greece PROGRAM COMMITTEE Paolo Anedda, CRS4, Italy Giovanni Busonera, CRS4, Italy Brad Calder, Microsoft, USA Roberto Canonico, University of Napoli Federico II, Italy Tommaso Cucinotta, Alcatel-Lucent Bell Labs, Ireland Werner Fischer, Thomas-Krenn AG, Germany William Gardner, University of Guelph, USA Marcus Hardt, Forschungszentrum Karlsruhe, Germany Sverre Jarp, CERN, Switzerland Shantenu Jha, Louisiana State University, USA Xuxian Jiang, NC State, USA Nectarios Koziris, National Technical University of Athens, Greece Simone Leo, CRS4, Italy Ignacio Llorente, Universidad Complutense de Madrid, Spain Naoya Maruyama, Tokyo Institute of Technology, Japan Jean-Marc Menaud, Ecole des Mines de Nantes, France Dimitrios Nikolopoulos, Foundation for Research&Technology Hellas, Greece Jose Renato Santos, HP Labs, USA Walter Schwaiger, TU Wien, Austria Yoshio Turner, HP Labs, USA Kurt Tutschku, University of Vienna, Austria Lizhe Wang, Indiana University, USA Chao-Tung Yang, Tunghai University, Taiwan DURATION: Workshop Duration is one day. GENERAL INFORMATION The workshop will be held as part of Euro-Par 2012. Euro-Par 2012: http://europar2012.cti.gr/ --20cf3071c93c92d76b04bf80ad89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Mailing List Members,

we have extended the submission deadline to the 11th of June, please=20 find the updated CfP for circulation attached. There will be no further=20 extensions!!


Regards,
Best Regards,

Michael Alexander, Gianluigi Zanetti and Anastassios Nanos
VHPC'12 Chairs



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CALL FOR PAPERS

7th Workshop on

Virtualization in High-Performance Cloud Computing

VHPC '12

as part of Euro-Par 2012, Rhodes Island, Greece

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Date: August 28, 2012

Workshop URL: http://v= hpc.org

SUBMISSION DEADLINE:

June 11, 2012 - Full paper submission (extended)


SCOPE:

Virtualization has become a common abstraction layer in modern
data centers, enabling resource owners to manage complex
infrastructure independently of their applications. Conjointly,
virtualization is becoming a driving technology for a manifold of
industry grade IT services. The cloud concept includes the notion
of a separation between resource owners and users, adding =A0services
such as hosted application frameworks and queueing. Utilizing the
same infrastructure, clouds carry significant potential for use in
high-performance scientific computing. The ability of clouds to provide
for requests and releases of vast computing resources dynamically and
close to the marginal cost of providing the services is unprecedented in the history of scientific and commercial computing.

Distributed computing concepts that leverage federated resource
access are popular within the grid community, but have not seen
previously desired deployed levels so far. Also, many of the scientific
data centers have not adopted virtualization or cloud concepts yet.

This workshop aims to bring together industrial providers with the
scientific community in order to foster discussion, collaboration
and mutual exchange of knowledge and experience.

The workshop will be one day in length, composed of 20 min
paper presentations, each followed by 10 min discussion sections.
Presentations may be accompanied by interactive demonstrations.


TOPICS

Topics of interest include, but are not limited to:

Higher-level cloud architectures, focusing on issues such as:
- Languages for describing highly-distributed compute jobs
- Workload characterization for VM-based environments
- Optimized communication libraries/protocols in the cloud
- Cross-layer optimization of numeric algorithms on VM infrastructure
- System and process/bytecode VM convergence
- Cloud frameworks and API sets
- Checkpointing/migration of large compute jobs
- Instrumentation interfaces and languages
- VMM performance (auto-)tuning on various load types
- Cloud reliability, fault-tolerance, and security
- Software as a Service (SaaS) architectures
- Research and education use cases
- Virtualization in cloud, cluster and grid environments
- Cross-layer VM optimizations
- Cloud use cases including optimizations
- VM-based cloud performance modelling
- Performance and cost modelling

Lower-level design challenges for Hypervisors, VM-aware I/O devices,
hardware accelerators or filesystems in VM environments, especially:
- Cloud, grid and distributed filesystems
- Hardware for I/O virtualization (storage/network/accelerators)
- Storage and network I/O subsystems in virtualized environments
- Novel software approaches to I/O virtualization
- Paravirtualized I/O subsystems for modified/unmodified guests
- Virtualization-aware cluster interconnects
- Direct device assignment
- NUMA-aware subsystems in virtualized environments
- Hardware Accelerators in virtualization (GPUs/FPGAs)
- Hardware extensions for virtualization
- VMMs/Hypervisors for embedded systems

Data Center management methods, including:
- QoS and and service levels
- VM cloud and cluster distribution algorithms
- VM load-balancing in Clouds
- Hypervisor extensions and tools for cluster and grid computing
- Fault tolerant VM environments
- Virtual machine monitor platforms
- Management, deployment and monitoring of VM-based environments
- Cluster provisioning in the Cloud


PAPER SUBMISSION

Papers submitted to the workshop will be reviewed by at least two
members of the program committee and external reviewers. Submissions
should include abstract, key words, the e-mail address of the
corresponding author, and must not exceed 10 pages, including tables
and figures at a main font size no smaller than 11 point. Submission
of a paper should be regarded as a commitment that, should the paper
be accepted, at least one of the authors will register and attend the
conference to present the work.

Accepted papers will be published in the Springer LNCS series - the
format must be according to the Springer LNCS Style. Initial
submissions are in PDF; authors of accepted papers will be requested
to provide source files.

Format Guidelines: http://www.springer.de/comp/lncs/authors.html
Style template:
ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.= zip
Abstract Submission Link: http://edas.info/newPaper.php?c=3D11943


IMPORTANT DATES

Rolling abstract submission
June 11, 2012 - Full paper submission (extended)
June 29, 2012 - Acceptance notification
July 20, 2012 - Camera-ready version due
August 28, 2012 - Workshop Date


CHAIR

Michael Alexander (chair), TU Wien, Austria
Gianluigi Zanetti (co-chair), CRS4, Italy
Anastassios Nanos (co-chair), NTUA, Greece


PROGRAM COMMITTEE

Paolo Anedda, CRS4, Italy
Giovanni Busonera, CRS4, Italy
Brad Calder, Microsoft, USA
Roberto Canonico, University of Napoli Federico II, Italy
Tommaso Cucinotta, Alcatel-Lucent Bell Labs, Ireland
Werner Fischer, Thomas-Krenn AG, Germany
William Gardner, University of Guelph, USA
Marcus Hardt, Forschungszentrum Karlsruhe, Germany
Sverre Jarp, CERN, Switzerland
Shantenu Jha, Louisiana State University, USA
Xuxian Jiang, NC State, USA
Nectarios Koziris, National Technical University of Athens, Greece
Simone Leo, CRS4, Italy
Ignacio Llorente, Universidad Complutense de Madrid, Spain
Naoya Maruyama, Tokyo Institute of Technology, Japan
Jean-Marc Menaud, Ecole des Mines de Nantes, France
Dimitrios Nikolopoulos, Foundation for Research&Technology Hellas, Gree= ce
Jose Renato Santos, HP Labs, USA
Walter Schwaiger, TU Wien, Austria
Yoshio Turner, HP Labs, USA
Kurt Tutschku, University of Vienna, Austria
Lizhe Wang, Indiana University, USA
Chao-Tung Yang, Tunghai University, Taiwan


DURATION: Workshop Duration is one day.


GENERAL INFORMATION

The workshop will be held as part of Euro-Par 2012.

Euro-Par 2012: htt= p://europar2012.cti.gr/

--20cf3071c93c92d76b04bf80ad89-- From lucy.yong@huawei.com Thu May 10 12:31:46 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8B911E80AB for ; Thu, 10 May 2012 12:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLRJOhT+X-q7 for ; Thu, 10 May 2012 12:31:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EB0BC11E80D0 for ; Thu, 10 May 2012 12:31:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGA79739; Thu, 10 May 2012 15:31:44 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 May 2012 12:29:20 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Thu, 10 May 2012 12:29:25 -0700 From: Lucy yong To: "armd@ietf.org" Thread-Topic: [armd] review of draft-ietf-armd-problem-statement-02 Thread-Index: Ac0u4zSx8hzo7stpSg+dd0iKJk+ZSQ== Date: Thu, 10 May 2012 19:29:24 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D331080B7@dfweml506-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.151] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D331080B7dfweml506mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 10 May 2012 12:37:42 -0700 Subject: [armd] review of draft-ietf-armd-problem-statement-02 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 19:31:46 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D331080B7dfweml506mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I read this draft and think it describes clearly. I support it. Here are some editing suggestion and comments. Notation: > for original text, < suggested text. >the issue is complicated by routers having many interfaces on which address resolution must be performed or with IEEE 802.1Q domains, where individual VLANs form their own broadcast domains. < the issue is complicated by routers having many interfaces on which address resolution must be performed or within IEEE 802.1Q domains where individual VLANs form their own broadcast domains. >This document is a product of the ARMD WG and identifies potential issues associated with address resolution in datacenters with massive number of hosts. Broadcast Domain: The set of all links, repeaters, and switches that are traversed in order to reach all nodes that are members of a given L2 domain. For example, when sending a broadcast packet on a VLAN, the domain would include all the links and switches that the packet traverses when broadcast traffic is sent. Comment: in DC, will a link or switch be physical link or virtual link, ph= ysical switch or virtual switch? It is better to state explicitly. > As the size of an L2 network increases, the level of broadcast traffic from protocols like ARP increases. < As the size of an L2 broadcast domain increases, the level of broadcast traffic from protocols like ARP increases. > That is, split large L2 networks into multiple smaller L2 networks, each operating as its own L3/IP subnet. Numerous data center networks have been designed with this principle, e.g., with each rack placed within its own L3 IP subnet. By doing so, the broadcast domain (and address resolution) is confined to one Top of Rack switch, which works well from a scaling perspective. Unfortunately, this conflicts in some ways with the current trend towards dynamic work load shifting in data centers and increased virtualization as discussed below. Comment: In DC, split large L2 network into multiple smaller L2 network is = for security trust design. Multiple L2 networks are on the same L3 subnetwo= rk so they all can support the same application, but they are isolated by L= 2 network for security reason, which also reduces ARP issue. > First, it uses broadcast, and any network with a large number of attached hosts will see a correspondingly large amount of broadcast ARP = traffic. Comment: it is not necessary true. A lot of trust designs prevent from host= -to-host communications. > Additionally, If no response is received, the router has to send the ARP/ND query multiple times. < Additionally, if no response is received, the router has to send the ARP/ND query multiple times. > Although address-resolution traffic remains local to one L2 network, some data center designs terminate L2 subnets at individual aggregation switches/routers (e.g., see Section 4.4.2). < Although address-resolution traffic remains local to one L2 network, some data center designs terminate L2 domain at individual aggregation switches/routers (e.g., see Section 4.4.2). Regards, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D331080B7dfweml506mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi,

=  

= I read this draft and think it describes clearly. I support it.<= /span>

 

 

Here are some editing suggest= ion and comments.

Notation: > for original t= ext, < suggested text.

 

>the issue is complicated = by routers having many interfaces on which

   address resoluti= on must be performed or with IEEE 802.1Q domains,

   where individual VLANs form their own broadca= st domains.

 

< the issue is complicated= by routers having many interfaces on which

   address resoluti= on must be performed or within IEEE 802.1Q domains

   where individual VLANs form their own broadca= st domains.

 

 

>This document is a produc= t of the ARMD WG and identifies potential

   issues associate= d with address resolution in datacenters with massive

   number of hosts. 

<This document identifies = potential

   issues associate= d with address resolution in datacenters with massive

   number of hosts. 

 

>   Broadcast Do= main:  The set of all links, repeaters, and switches that

     = ; are traversed in order to reach all nodes that are members of a

     = ; given L2 domain.  For example, when sending a broadcast packet on

     = ; a VLAN, the domain would include all the links and switches that

     = ; the packet traverses when broadcast traffic is sent.

 

Comment:  in DC, will a link or switch be physi= cal link or virtual link, physical switch or virtual switch? It is better t= o state explicitly.

 

>  As the size of an = L2 network increases, the level of

   broadcast traffi= c from protocols like ARP increases.

 

<  As the size of an = L2 broadcast domain increases, the level of

   broadcast traffi= c from protocols like ARP increases.

 

> That is, split large L2 = networks into multiple smaller L2 networks,

   each operating a= s its own L3/IP subnet.  Numerous data center

   networks have be= en designed with this principle, e.g., with each rack

   placed within it= s own L3 IP subnet.  By doing so, the broadcast

   domain (and addr= ess resolution) is confined to one Top of Rack

   switch, which wo= rks well from a scaling perspective.  Unfortunately,=

   this conflicts i= n some ways with the current trend towards dynamic

   work load shifti= ng in data centers and increased virtualization as

   discussed below.=

 

Comment: In DC, split large L= 2 network into multiple smaller L2 network is for security trust design. Mu= ltiple L2 networks are on the same L3 subnetwork so they all can support the same application, but they are isolated by L2 = network for security reason, which also reduces ARP issue.

 

>  First, it uses bro= adcast, and any network with a large number of

   attached hosts w= ill see a correspondingly large amount of broadcast ARP traffic.=

Comment: it is not necessary = true. A lot of trust designs prevent from host-to-host communications.

 

>  Additionally, If n= o response

   is received, the= router has to send the ARP/ND query multiple times.

< Additionally, if no resp= onse

   is received, the= router has to send the ARP/ND query multiple times.

 

>  Although address-r= esolution traffic remains local to one L2 network,

   some data center= designs terminate L2 subnets at individual

   aggregation swit= ches/routers (e.g., see Section 4.4.2). 

 

< Although address-resolut= ion traffic remains local to one L2 network,

   some data center= designs terminate L2 domain at individual

   aggregation swit= ches/routers (e.g., see Section 4.4.2). 

 

Regards,

Lucy

 

--_000_2691CE0099834E4A9C5044EEC662BB9D331080B7dfweml506mbx_-- From d3e3e3@gmail.com Tue May 15 15:11:46 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802EB21F8797 for ; Tue, 15 May 2012 15:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.683 X-Spam-Level: X-Spam-Status: No, score=-103.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiUNI9C9wK1s for ; Tue, 15 May 2012 15:11:41 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7023721F866B for ; Tue, 15 May 2012 15:11:41 -0700 (PDT) Received: by ggnc4 with SMTP id c4so122536ggn.31 for ; Tue, 15 May 2012 15:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=iAYixb01HZ9AwnqhiGPaHXX+TVjqSekpjPX8yBcEfhQ=; b=UK2PDWsVrm6ZGlZ4dB8NQxirkYp/TEXAv74PCDpWlm8H3bC4bJBc0U+XL8rWj9TpQJ kt+Hk/95pOqOBA1QGNexmYFW3oMCcBDLVmvKKqyu6A6kRFdkBjsTnipTjnPR1rq8d9Gx SdAZGAspQBWRfC7KryM7Hedg/paBFCgh7gmyCosjUIawMoYTZ6iduapQ6rqaPwk+RMRP Xe6eVnlSAQRJBThp5fJkD+M8bdaypuY6AHgMTROH2ZuA8M5ojlqkN9dHlZepmUdtyjBr 0PixxJ1WaXozZlHE5ADrhmKUPBLERGVP5SSH7tJJasWNw4vSaTYVeMieJaPjbUzk5FMA dYNw== Received: by 10.50.160.225 with SMTP id xn1mr482173igb.3.1337119900754; Tue, 15 May 2012 15:11:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Tue, 15 May 2012 15:11:20 -0700 (PDT) From: Donald Eastlake Date: Tue, 15 May 2012 18:11:20 -0400 Message-ID: To: armd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [armd] review of draft-ietf-armd-problem-statement-02 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 22:11:46 -0000 I have read this draft and believe it should be published as an Informational RFC. Minor items: "IEEE802.1Q" -> "IEEE 802.1Q" "4095 VLANs" -> "4094 VLANs" (0x000 and 0xFFF are not usable as VLAN IDs) "layer 2 traffic are still partitioned by VLANs" -> either "layer 2 traffic is still partitioned by VLAN" "specifically specifies" -> "specifically states" Suggest IANA Considerations section be changed to say: "This document requires no IANA Actions. RFC Editor: please delete this section before publication." The Authors' Addresses section should include a postal address and telephone number for each author. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From david.black@emc.com Thu May 24 00:43:13 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DD921F855B for ; Thu, 24 May 2012 00:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PY6ub4st9n8S for ; Thu, 24 May 2012 00:43:13 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id ECE2F21F8559 for ; Thu, 24 May 2012 00:43:12 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q4O7hC6L031290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 May 2012 03:43:12 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Thu, 24 May 2012 03:42:57 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q4O7guQ7004705 for ; Thu, 24 May 2012 03:42:57 -0400 Received: from mx15a.corp.emc.com ([169.254.1.236]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Thu, 24 May 2012 03:42:56 -0400 From: To: Date: Thu, 24 May 2012 03:42:50 -0400 Thread-Topic: Comments on draft-ietf-armd-problem-statement-02 Thread-Index: Ac05gNIczm79MGjhRS2Zwok5HhCMRg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71205813C96@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [armd] Comments on draft-ietf-armd-problem-statement-02 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 07:43:13 -0000 Overall, I think this draft is worth publishing as an Informational RFC to record the work that has been done on understanding this problem area. I think the draft needs some work, primarily because section 4 seems to be missing a crisp conclusion. Text should be added at the end of secti= on 4 to make the following three points (that set up the problem discussion in section 7): (1) The L3 to Access Switches design in Section 4.4.1 is the only design that constrains L2 domain size in a fashion that avoids ARP/ND scaling prob= lems. (2) That design in 4.4.1 is limited and limiting, in that it cannot address some of the requirements discussed elsewhere in Section 4 that lead to larg= er L2 domains. (3) Hence the ARP/ND scaling problem exists and is important. I would move section 4 to after section 6 so that the problem details in se= ction 7 follow section 4 directly. ----------- Nits -------------- -- Section 1 -- Delete ARMD WG mentions in 2nd paragraph. A published RFC is an archival document that will live on long after the ARMD WG is an artifact of history. -- Section 2 -- In the definition of Application: "a software process" -> "software". Limit the definition of "Host" to "A computer system on the network". The = rest of the definition is explanation that belongs elsewhere. Definition of L2 domain seems to confuse "802.1Q domain" of a set of VLANs = with an individual VLAN (e.g., as broadcast domain). If both concepts are neede= d, two definitions are needed. Definition of Virtual machine (VM): This definition is overly restrictive t= o complete hardware emulation approaches. There are paravirtualization approaches for which the second sentence is false, but the overall intent o= f the definition that a VM behaves like a physical server for most network purposes is correct. Definition of EoR: "network network" -> "network". Also, should say that t= his is the next level of switching above ToR (above =3D in the direction of the= network core). Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From narten@us.ibm.com Fri May 25 12:44:21 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98F021F87A1 for ; Fri, 25 May 2012 12:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ-bmOQm+hZR for ; Fri, 25 May 2012 12:44:21 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 44D0421F87B6 for ; Fri, 25 May 2012 12:44:19 -0700 (PDT) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 May 2012 15:44:18 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 25 May 2012 15:43:45 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id D001838C8059 for ; Fri, 25 May 2012 15:43:43 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4PJhiLr24510632 for ; Fri, 25 May 2012 15:43:44 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4PJhhMX022251 for ; Fri, 25 May 2012 16:43:44 -0300 Received: from cichlid.raleigh.ibm.com ([9.80.11.36]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q4PJhgGX022207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 May 2012 16:43:43 -0300 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q4PJhfTb019425; Fri, 25 May 2012 15:43:41 -0400 Message-Id: <201205251943.q4PJhfTb019425@cichlid.raleigh.ibm.com> To: anoop@alumni.duke.edu In-reply-to: References: Comments: In-reply-to Anoop Ghanwani message dated "Thu, 03 May 2012 19:21:54 -0700." Date: Fri, 25 May 2012 15:43:40 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12052519-5806-0000-0000-00001591D53A Cc: armd@ietf.org Subject: Re: [armd] review of draft-ietf-armd-problem-statement-02 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 19:44:21 -0000 H Anoop. Thanks for your review very detailed review comments. I've adopted most of them directly. Some questions below. Anoop Ghanwani writes: > Section 4.4.1 > ============ > For consistency with the following 2 sections > change title from Layer 3 to L3. > "This topology is ideal for scenarios where servers >   attached to a particular access switch generally run applications >   that are are confined to using a single subnet." > I'm not sure I agree with this. There are many issues > surround this including the capabilities of the devices > in the network, the use of the multicast, and the preferences > of the network administrator. I agree that "is ideal" is too strong. How about if I say instead: This topology has benefits in scenarios ... Would that address your concerns? > "Even though > layer 2 traffic are still partitioned by VLANs, the fact that all > VLANs are enabled on all ports can lead to broadcast traffic on all > VLANs to traverse all links and ports, which is same effect as one > big Layer 2 domain. " > I disagree with this because all VLANs would only > need to be provisioned on the aggregation-facing ports. > The disadvantage here is that a lot more broadcast traffic > hits the aggregation layer, and when we need to cross > VLAN boundaries, the traffic must go all way to the > aggregation switch even though the source and destination > may be on the same access switch, and the requirement > for larger ARP tables at the aggregation switches. I struggled with this for a long while. Is this text any better?: When the L3 domain only extends to aggregation switches, hosts in any of the IP subnets configured on the aggregation switches can be reachable via L2 through any access switches if access switches enable all the VLANs. This topology allows a greater level of flexibility as servers attached to any access switch can be reloaded with applications that have been provisioned with IP addresses from multiple prefixes as needed. Further, in such an environment, VMs can migrate between racks without IP address changes. The drawback of this design however is that multiple VLANs have to be enabled on all access switches and all access-facing ports on aggregation switches. Even though L2 traffic is still partitioned by VLANs, the fact that all VLANs are enabled on all ports can lead to broadcast traffic on all VLANs to traverse all links and ports, which is same effect as one big L2 domain on the access-facing side of the aggregation switch. In addition, internal traffic itself might have to cross different L2 boundaries resulting in significant ARP/ND load at the aggregation switches. This design provides a good tradeoff between flexibility and L2 domain size. A moderate sized data center might utilize this approach to provide high availability services at a single location. > "However, the > Overlay Edge switches/routers which perform the network address > encapsulation/decapsulation must ultimately perform a L2 address > resolution and could still potentially face scaling issues at that > point." > It's not the overlay edge switches that have the scaling > problem, its the volume of broadcasts that need to be > sent across the core and that is not helped simply by > using an L3 overlay. I also struggled quite a bit with this comment. Is the following an improvement?: A potential problem that arises in a large data center is when a large number of hosts communicate with their peers in different subnets, all these hosts send (and receive) data packets to their respective L2/L3 boundary nodes as the traffic flows are generally bi-directional. This has the potential to further highlight any scaling problems. These L2/L3 boundary nodes have to process ARP/ND requests sent from originating subnets and resolve physical (MAC) addresses in the target subnets for what are generally bi-directional flows. Therefore, for maximum flexibility in managing the data center workload, it is often desirable to use overlays to place related groups of hosts in the same topological subnet to avoid the L2/L3 boundary translation. The use of overlays in the data center network can be a useful design mechanism to help manage a potential bottleneck at the L2 / L3 boundary by redefining where that boundary exists. > Section 6 > ========== > "Thus, whereas all > nodes must process every ARP query, ND queries are processed only by > the nodes to which they are intended." > When virtualization is in use, the NIC is often operated > in promiscuous mode, which means that the packet would > be delivered to the hypervisor/vswitch and the filtering > would have to be done there (usually implemented in software), > making the problem almost as bad as with ARP. Revised text: Thus, whereas all nodes must process every ARP query, ND queries are processed only by the nodes to which they are intended. In cases where multicast filtering can't effectively be implemented in the NIC (e.g., as on hypervisors supporting virualization), filtering would need to be done in software (e.g., in the hypervisor's vSwitch). Thomas From narten@us.ibm.com Fri May 25 13:18:12 2012 Return-Path: X-Original-To: armd@ietfa.amsl.com Delivered-To: armd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA3F21F8794 for ; Fri, 25 May 2012 13:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULNfzcqTZq4q for ; Fri, 25 May 2012 13:18:11 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id AD97521F87A0 for ; Fri, 25 May 2012 13:18:11 -0700 (PDT) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 May 2012 14:18:07 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 25 May 2012 14:17:25 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 3A47D19D8053 for ; Fri, 25 May 2012 14:17:11 -0600 (MDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4PKHBEp146372 for ; Fri, 25 May 2012 14:17:12 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4PKFvJ8025957 for ; Fri, 25 May 2012 14:15:58 -0600 Received: from cichlid.raleigh.ibm.com ([9.80.11.36]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q4PKFtUT025746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 May 2012 14:15:56 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q4PKFq3n019737; Fri, 25 May 2012 16:15:54 -0400 Message-Id: <201205252015.q4PKFq3n019737@cichlid.raleigh.ibm.com> To: Lucy yong In-reply-to: <2691CE0099834E4A9C5044EEC662BB9D331080B7@dfweml506-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D331080B7@dfweml506-mbx> Comments: In-reply-to Lucy yong message dated "Thu, 10 May 2012 19:29:24 -0000." Date: Fri, 25 May 2012 16:15:52 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12052520-7606-0000-0000-000000A00239 Cc: "armd@ietf.org" Subject: Re: [armd] review of draft-ietf-armd-problem-statement-02 X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:18:12 -0000 Hi Lucy. Thanks for the review. I've made all your changes, except: > > Broadcast Domain: The set of all links, repeaters, and switches that > are traversed in order to reach all nodes that are members of a > given L2 domain. For example, when sending a broadcast packet on > a VLAN, the domain would include all the links and switches that > the packet traverses when broadcast traffic is sent. > Comment: in DC, will a link or switch be physical link or virtual > link, physical switch or virtual switch? It is better to state > explicitly. I'm not sure we need say whether a link is physical or virtual. I'm inclined to leave the definition as is. How would it make a difference? > > That is, split large L2 networks into multiple smaller L2 networks, > each operating as its own L3/IP subnet. Numerous data center > networks have been designed with this principle, e.g., with each rack > placed within its own L3 IP subnet. By doing so, the broadcast > domain (and address resolution) is confined to one Top of Rack > switch, which works well from a scaling perspective. Unfortunately, > this conflicts in some ways with the current trend towards dynamic > work load shifting in data centers and increased virtualization as > discussed below. > Comment: In DC, split large L2 network into multiple smaller L2 network is > for security trust design. Multiple L2 networks are on the same L3 > subnetwork so they all can support the same application, but they > are isolated by L2 network for security reason, which also reduces > ARP issue. Agreed. But do we need to say that in the document? (by saying "comment", I assume you are not asking for text changes.) There are lots of factors for any particular design choice, and we can't really describe them all. So I'm inclined to only list those most related to address resolution. > > First, it uses broadcast, and any network with a large number of > attached hosts will see a correspondingly large amount of broadcast ARP > traffic. > Comment: it is not necessary true. A lot of trust designs prevent from host > -to-host communications. I think the same comment applies here as above. One thing I note is that using terms like "any network" or "L2 network" is not very precise. To be precise, we often need to be talking about an L2 domain, i.e, a specific VLAN. Thanks! Thomas