From pfrejborg@gmail.com Tue Feb 1 07:20:35 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 21FB43A6DEE for ; Tue, 1 Feb 2011 07:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9Eq3NunfeHx for ; Tue, 1 Feb 2011 07:20:29 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id E44A83A6C05 for ; Tue, 1 Feb 2011 07:20:28 -0800 (PST) Received: by ewy8 with SMTP id 8so3481978ewy.31 for ; Tue, 01 Feb 2011 07:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JMy46DtAyZjFrEICaIZx+z1OzeFTNQiimckhqxcxkos=; b=jNjBXXH8D55clCa4Zl8FfdD8vCKBcFZQ4AsvutDRute/x/wuddVfQMeK4adU4JsxWv dW/FdtXLyvGCOMv7yzDNDwCBYkew5AEhHU8zLzw6WhhjB/5/ucku9/paUsmBoHXdRbst W8dpWDP95A7ayo9lxe2mHwB95mSFhOfaDSlpI= 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:content-transfer-encoding; b=SYuz5n9K90yaw2sAkqUs+AljAlqas8ex6G9pOBQVCSfe1oGKWwOERlU0fF7MnQ7p4u 0hPiAQOK/twe+hqrs3EwmyYg9nX2yQEhBSYu4kFWAHpCOg++FvFHy/N6+e2StSNK4HyO tF0Z3k92MHP+MaZ3IPSXcgKy+spr9aVSpOKXs= MIME-Version: 1.0 Received: by 10.213.17.147 with SMTP id s19mr10299107eba.89.1296573825080; Tue, 01 Feb 2011 07:23:45 -0800 (PST) Received: by 10.213.106.6 with HTTP; Tue, 1 Feb 2011 07:23:45 -0800 (PST) In-Reply-To: <006501cbc186$c6bee9d0$543cbd70$@com> References: <006501cbc186$c6bee9d0$543cbd70$@com> Date: Tue, 1 Feb 2011 17:23:45 +0200 Message-ID: From: Patrick Frejborg To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ralph Droms , armd@ietf.org Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 15:20:35 -0000 Hi Susan, my intention was not to interfere with your work at the WG. I have been involved in some large DC network architectures and ARP scalability has never been an issue. My point is that we should try to find ways to move away from L2 topologies towards L3 topologies as they have at Yahoo (that is the impression I got from the link you posted). MPTCP is evolving and that itself provides a session layer for the application. If we apply theoretically MPTCP on the Yahoo architecture, then the first subflow is connected to the load balancer (LB) - user is identified, MPTCP token exchanged and the IP address (to setup a second subflow to the real server) is exchanged with the client. The LB is sending the token via a trusted backdoor to the real server so the client and real server can establish a new subflow for the application - after that the client uses the application without traversing the LB anymore. Same with VM migration - the active server freezes the application and send the DRAM image and MPTCP tokens (session identifiers) over to the standby server. At the same time the active server informs all his active clients that his IP address is going to change because the active server changes location (though the physical server is not changing location - the VM is moving to another place). Once the standby server is ready it starts to accept client sessions and the sessions are accepted once the tokens and other parameters matches. DNS needs to be updated so new clients can find the server, since it changed location recently. It MPTCP goes mainstream, L2 issues in data centers would be history - but it requires upgrades of the client stack and studies what kind of scalability issues there are with MPTCP enabled LBs, VM migration with MPTCP etc. My guess is that MPTCP will happen, it will be very useful for smartphones to roam from one network to another. Perhaps this approach is something that not belongs to IETF - perhaps IRTF is the right forum or perhaps it do not belong here at all? So my apologizes for interfering the WG Patrick On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares wrote: > Patrick: > > Yes, I agree that Data Center problem is bigger than just ARP/ND. However= , > to make progress on the ARP/ND portion we need to focus our work tightly. > > I agree that the problem needs the technologies of 100Gb Ethernet, IP/OTN= or > WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or new TC= P > or IPv6 options), session concepts and NM topologies to provide cross-lay= er > optimization for data centers. I'm actually participating with IETF folks= in > all these areas on protocols or NM. > > Networks/DC are focused on expanding the L2 (see the presentation below: > http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45= .na > nog51-Schaumann.pdf) > > IETF WG do best by tackling one part of the total solution. We are stayin= g > tightly focused on the ARP/ND problem, and proposing a very tight working > group. We are focused on collecting publishable ARP/ND statistics, gettin= g > specific requirements, creating models for discussion, and creating > prototype that the community can access. > > We have demonstrated at our BOF in Beijing that there are many solutions = to > the ARP/ND issues. > > Linda and I have talked to many people providing DC technology or VM > technology or DC services. However, the topic is so hot that people do no= t > want to publish their statistics due to competitive pressures. We are > investigating anonymous data from Research networks with similar DC > topologies. > > If you want to suggest a WG for session layer, I will definitely attend t= hat > group. I'm already tracking the rest of this work, plus the IEEE VLAN gro= up. > > > If you disagree with the tight focus, please send your comments to our AD= s > (Ralph Droms and Jari Arkko). > > Sue > > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Patrick Frejborg > Sent: Monday, January 31, 2011 1:20 PM > To: armd@ietf.org > Subject: [armd] Data center issues > > Hi all, > > I'm new to the list and I just read through =A0the "Updated ARMD Charter = and > Milestones" thread. > > I do agree with Thomas Narten in his post on 27th of January, this is a m= uch > bigger problem than only ARP. It is also about VLAN scalability, how many > MAC-addresses needs to be supported in the L2 domain, spanning-tree issue= s, > failure domain etc > > Much of these challenges can today be solved by implementing VPLS, tomorr= ow > they can be solved by TRILL/SPB - but a L2 broadcast domain is also IMHO = a > failure domain since a bridge floods all unknown > packets out on all ports when a router only forward packets to known > destinations. > > Thus I think the root cause to have large L2 domains is the TCP/IP stack > itself - there is no session layer in the current stack. If the > TCP/IP stack contained a session layer, by implementing a locator/identif= ier > split, then the application could be moved from one server to another > (physical or virtual, it doesn't matter) on the fly. > > > Then we could design data center networks according to best practices, i.= e. > implement routing whenever you can and the failure domains would be much > smaller - also ARP, VLAN, MAC scalability issues are solved. > > And with a session layer in the TCP/IP stack , the customer could move hi= s > applications from one cloud service provider to another cloud - > over a routed network. The security nodes should not use IP addresses to > verify the users/servers, instead the decoupled identifier should > be used to grant/deny access to a resource. > > Examples of =A0locator/identifier split architectures are Host Identity > Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based > Sockets (NBS). > > My 2 cents... > > Patrick > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > From ning.so@verizonbusiness.com Tue Feb 1 07:35:00 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 4D0663A6C11 for ; Tue, 1 Feb 2011 07:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi53hQNCjhgb for ; Tue, 1 Feb 2011 07:34:58 -0800 (PST) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id 409303A6C0F for ; Tue, 1 Feb 2011 07:34:58 -0800 (PST) Received: from omzismtp03.vzbi.com ([unknown] [165.122.46.170]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LFY0064K3FQI610@firewall.verizonbusiness.com> for armd@ietf.org; Tue, 01 Feb 2011 15:38:14 +0000 (GMT) Received: from omzismtp03.vzbi.com ([unknown] [127.0.0.1]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LFY00FIJ3FQ4500@omzismtp03.vzbi.com> for armd@ietf.org; Tue, 01 Feb 2011 15:38:14 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([unknown] [153.39.68.166]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LFY00F473FQ4L00@omzismtp03.vzbi.com> for armd@ietf.org; Tue, 01 Feb 2011 15:38:14 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 01 Feb 2011 15:38:13 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Date: Tue, 01 Feb 2011 15:38:10 +0000 Message-id: <14584D6EE26B314187A4F68BA2060600067702E5@ASHEVS008.mcilink.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [armd] Data center issues Thread-index: AcvCJA6Vf5O69TJISpOIMhLbKfhuigAATx6g References: <006501cbc186$c6bee9d0$543cbd70$@com> From: "So, Ning" To: Patrick Frejborg , Susan Hares X-OriginalArrivalTime: 01 Feb 2011 15:38:13.0542 (UTC) FILETIME=[0993D460:01CBC226] Cc: Ralph Droms , armd@ietf.org Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 15:35:00 -0000 All, I just want to point out that L3 solution may work for some DC design = such as YAHOO, but it is not a universal case. For example, TOS/COS/QoS = are widely deployed in many service providers' networks, and highly = valued by Enterprise/Government customers (and their applications). = Scaling L3 network may not be any easier than L2 in that operational = condition. I do see the needs to keep the options open becasue one size = fits all may not work.=20 =20 Best regards, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of = Patrick Frejborg Sent: Tuesday, February 01, 2011 9:24 AM To: Susan Hares Cc: Ralph Droms; armd@ietf.org Subject: Re: [armd] Data center issues Hi Susan, my intention was not to interfere with your work at the WG. I have been involved in some large DC network architectures and ARP scalability has never been an issue. My point is that we should try to find ways to move away from L2 topologies towards L3 topologies as they have at Yahoo (that is the impression I got from the link you posted). MPTCP is evolving and that itself provides a session layer for the application. If we apply theoretically MPTCP on the Yahoo architecture, then the first subflow is connected to the load balancer (LB) - user is identified, MPTCP token exchanged and the IP address (to setup a second subflow to the real server) is exchanged with the client. The LB is sending the token via a trusted backdoor to the real server so the client and real server can establish a new subflow for the application - after that the client uses the application without traversing the LB anymore. Same with VM migration - the active server freezes the application and send the DRAM image and MPTCP tokens (session identifiers) over to the standby server. At the same time the active server informs all his active clients that his IP address is going to change because the active server changes location (though the physical server is not changing location - the VM is moving to another place). Once the standby server is ready it starts to accept client sessions and the sessions are accepted once the tokens and other parameters matches. DNS needs to be updated so new clients can find the server, since it changed location recently. It MPTCP goes mainstream, L2 issues in data centers would be history - but it requires upgrades of the client stack and studies what kind of scalability issues there are with MPTCP enabled LBs, VM migration with MPTCP etc. My guess is that MPTCP will happen, it will be very useful for smartphones to roam from one network to another. Perhaps this approach is something that not belongs to IETF - perhaps IRTF is the right forum or perhaps it do not belong here at all? So my apologizes for interfering the WG Patrick On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares wrote: > Patrick: > > Yes, I agree that Data Center problem is bigger than just ARP/ND. = However, > to make progress on the ARP/ND portion we need to focus our work = tightly. > > I agree that the problem needs the technologies of 100Gb Ethernet, = IP/OTN or > WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or new = TCP > or IPv6 options), session concepts and NM topologies to provide = cross-layer > optimization for data centers. I'm actually participating with IETF = folks in > all these areas on protocols or NM. > > Networks/DC are focused on expanding the L2 (see the presentation = below: > = http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45= .na > nog51-Schaumann.pdf) > > IETF WG do best by tackling one part of the total solution. We are = staying > tightly focused on the ARP/ND problem, and proposing a very tight = working > group. We are focused on collecting publishable ARP/ND statistics, = getting > specific requirements, creating models for discussion, and creating > prototype that the community can access. > > We have demonstrated at our BOF in Beijing that there are many = solutions to > the ARP/ND issues. > > Linda and I have talked to many people providing DC technology or VM > technology or DC services. However, the topic is so hot that people do = not > want to publish their statistics due to competitive pressures. We are > investigating anonymous data from Research networks with similar DC > topologies. > > If you want to suggest a WG for session layer, I will definitely = attend that > group. I'm already tracking the rest of this work, plus the IEEE VLAN = group. > > > If you disagree with the tight focus, please send your comments to our = ADs > (Ralph Droms and Jari Arkko). > > Sue > > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf = Of > Patrick Frejborg > Sent: Monday, January 31, 2011 1:20 PM > To: armd@ietf.org > Subject: [armd] Data center issues > > Hi all, > > I'm new to the list and I just read through =A0the "Updated ARMD = Charter and > Milestones" thread. > > I do agree with Thomas Narten in his post on 27th of January, this is = a much > bigger problem than only ARP. It is also about VLAN scalability, how = many > MAC-addresses needs to be supported in the L2 domain, spanning-tree = issues, > failure domain etc > > Much of these challenges can today be solved by implementing VPLS, = tomorrow > they can be solved by TRILL/SPB - but a L2 broadcast domain is also = IMHO a > failure domain since a bridge floods all unknown > packets out on all ports when a router only forward packets to known > destinations. > > Thus I think the root cause to have large L2 domains is the TCP/IP = stack > itself - there is no session layer in the current stack. If the > TCP/IP stack contained a session layer, by implementing a = locator/identifier > split, then the application could be moved from one server to another > (physical or virtual, it doesn't matter) on the fly. > > > Then we could design data center networks according to best practices, = i.e. > implement routing whenever you can and the failure domains would be = much > smaller - also ARP, VLAN, MAC scalability issues are solved. > > And with a session layer in the TCP/IP stack , the customer could move = his > applications from one cloud service provider to another cloud - > over a routed network. The security nodes should not use IP addresses = to > verify the users/servers, instead the decoupled identifier should > be used to grant/deny access to a resource. > > Examples of =A0locator/identifier split architectures are Host = Identity > Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based > Sockets (NBS). > > My 2 cents... > > Patrick > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From jari.arkko@piuha.net Tue Feb 1 07:39:22 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594283A6D64 for ; Tue, 1 Feb 2011 07:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr+vCj8kVOoB for ; Tue, 1 Feb 2011 07:39:21 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 74AF23A6D4A for ; Tue, 1 Feb 2011 07:39:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C253E2CC2F; Tue, 1 Feb 2011 17:42:37 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuE+xFrbROZv; Tue, 1 Feb 2011 17:42:37 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 844A82CC2D; Tue, 1 Feb 2011 17:42:36 +0200 (EET) Message-ID: <4D4829EB.5050008@piuha.net> Date: Tue, 01 Feb 2011 07:42:35 -0800 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Patrick Frejborg References: <006501cbc186$c6bee9d0$543cbd70$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , armd@ietf.org Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 15:39:22 -0000 Patrick, You are not "interfering" with the work! I think the issues that you and Thomas raise are important ones. These reasons are partly behind my desire to limit the working group to documenting the problem and providing operational guidance, before proceeding to development of new solutions. I do think that the group should be limited to ARP and ND scaling, but it should not be limited in describing what factors are driving the scaling problems, or talking about operational ways to avoid those problems (different network architectures etc). I need to think if there's something in the charter text that should change because of this. Thomas, do you have any ideas about that? Jari From bensons@queuefull.net Tue Feb 1 13:37:39 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 129D73A687A for ; Tue, 1 Feb 2011 13:37:39 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ytp7DVX38dzj for ; Tue, 1 Feb 2011 13:37:37 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 524B23A6864 for ; Tue, 1 Feb 2011 13:37:37 -0800 (PST) Received: by qwi2 with SMTP id 2so7624494qwi.31 for ; Tue, 01 Feb 2011 13:40:55 -0800 (PST) Received: by 10.229.232.85 with SMTP id jt21mr5627357qcb.164.1296596454767; Tue, 01 Feb 2011 13:40:54 -0800 (PST) Received: from [192.168.1.115] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id g28sm15942397qck.37.2011.02.01.13.40.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 13:40:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Benson Schliesser In-Reply-To: <14584D6EE26B314187A4F68BA2060600067702E5@ASHEVS008.mcilink.com> Date: Tue, 1 Feb 2011 15:40:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006501cbc186$c6bee9d0$543cbd70$@com> <14584D6EE26B314187A4F68BA2060600067702E5@ASHEVS008.mcilink.com> To: "So, Ning" , Patrick Frejborg , Susan Hares , Ralph Droms , armd@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 21:37:39 -0000 I agree with Ning. One of the basic issues that advocates of all-L3 = datacenter networks typically overlook (i.e. because it doesn't apply to = them), is multi-tenancy. It can be done with L3-centric designs, of = course - with MPLS, tunnel overlays, etc - but it's more complex and = costly. There is a reason datacenter networks have been predominantly = L2. Cheers, -Benson On Feb 1, 2011, at 9:38 AM, So, Ning wrote: > All, >=20 > I just want to point out that L3 solution may work for some DC design = such as YAHOO, but it is not a universal case. For example, TOS/COS/QoS = are widely deployed in many service providers' networks, and highly = valued by Enterprise/Government customers (and their applications). = Scaling L3 network may not be any easier than L2 in that operational = condition. I do see the needs to keep the options open becasue one size = fits all may not work.=20 >=20 >=20 > Best regards, >=20 > Ning So > Network Evolution Planning > Verizon, Inc. > (office) 972-729-7905 > (Cell) 972-955-0914 >=20 > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf = Of Patrick Frejborg > Sent: Tuesday, February 01, 2011 9:24 AM > To: Susan Hares > Cc: Ralph Droms; armd@ietf.org > Subject: Re: [armd] Data center issues >=20 > Hi Susan, >=20 > my intention was not to interfere with your work at the WG. >=20 > I have been involved in some large DC network architectures and ARP > scalability has never been an issue. My point is that we should try to > find ways to move away from L2 topologies towards L3 topologies as > they have at Yahoo (that is the impression I got from the link you > posted). >=20 > MPTCP is evolving and that itself provides a session layer for the > application. If we apply theoretically MPTCP on the Yahoo > architecture, then the first subflow is connected to the load balancer > (LB) - user is identified, MPTCP token exchanged and the IP address > (to setup a second subflow to the real server) is exchanged with the > client. The LB is sending the token via a trusted backdoor to the real > server so the client and real server can establish a new subflow for > the application - after that the client uses the application without > traversing the LB anymore. >=20 > Same with VM migration - the active server freezes the application and > send the DRAM image and MPTCP tokens (session identifiers) over to the > standby server. At the same time the active server informs all his > active clients that his IP address is going to change because the > active server changes location (though the physical server is not > changing location - the VM is moving to another place). Once the > standby server is ready it starts to accept client sessions and the > sessions are accepted once the tokens and other parameters matches. > DNS needs to be updated so new clients can find the server, since it > changed location recently. >=20 > It MPTCP goes mainstream, L2 issues in data centers would be history - > but it requires upgrades of the client stack and studies what kind of > scalability issues there are with MPTCP enabled LBs, VM migration with > MPTCP etc. My guess is that MPTCP will happen, it will be very useful > for smartphones to roam from one network to another. >=20 > Perhaps this approach is something that not belongs to IETF - perhaps > IRTF is the right forum or perhaps it do not belong here at all? >=20 > So my apologizes for interfering the WG >=20 > Patrick >=20 > On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares wrote: >> Patrick: >>=20 >> Yes, I agree that Data Center problem is bigger than just ARP/ND. = However, >> to make progress on the ARP/ND portion we need to focus our work = tightly. >>=20 >> I agree that the problem needs the technologies of 100Gb Ethernet, = IP/OTN or >> WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or = new TCP >> or IPv6 options), session concepts and NM topologies to provide = cross-layer >> optimization for data centers. I'm actually participating with IETF = folks in >> all these areas on protocols or NM. >>=20 >> Networks/DC are focused on expanding the L2 (see the presentation = below: >> = http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.= na >> nog51-Schaumann.pdf) >>=20 >> IETF WG do best by tackling one part of the total solution. We are = staying >> tightly focused on the ARP/ND problem, and proposing a very tight = working >> group. We are focused on collecting publishable ARP/ND statistics, = getting >> specific requirements, creating models for discussion, and creating >> prototype that the community can access. >>=20 >> We have demonstrated at our BOF in Beijing that there are many = solutions to >> the ARP/ND issues. >>=20 >> Linda and I have talked to many people providing DC technology or VM >> technology or DC services. However, the topic is so hot that people = do not >> want to publish their statistics due to competitive pressures. We are >> investigating anonymous data from Research networks with similar DC >> topologies. >>=20 >> If you want to suggest a WG for session layer, I will definitely = attend that >> group. I'm already tracking the rest of this work, plus the IEEE VLAN = group. >>=20 >>=20 >> If you disagree with the tight focus, please send your comments to = our ADs >> (Ralph Droms and Jari Arkko). >>=20 >> Sue >>=20 >>=20 >> -----Original Message----- >> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf = Of >> Patrick Frejborg >> Sent: Monday, January 31, 2011 1:20 PM >> To: armd@ietf.org >> Subject: [armd] Data center issues >>=20 >> Hi all, >>=20 >> I'm new to the list and I just read through the "Updated ARMD = Charter and >> Milestones" thread. >>=20 >> I do agree with Thomas Narten in his post on 27th of January, this is = a much >> bigger problem than only ARP. It is also about VLAN scalability, how = many >> MAC-addresses needs to be supported in the L2 domain, spanning-tree = issues, >> failure domain etc >>=20 >> Much of these challenges can today be solved by implementing VPLS, = tomorrow >> they can be solved by TRILL/SPB - but a L2 broadcast domain is also = IMHO a >> failure domain since a bridge floods all unknown >> packets out on all ports when a router only forward packets to known >> destinations. >>=20 >> Thus I think the root cause to have large L2 domains is the TCP/IP = stack >> itself - there is no session layer in the current stack. If the >> TCP/IP stack contained a session layer, by implementing a = locator/identifier >> split, then the application could be moved from one server to another >> (physical or virtual, it doesn't matter) on the fly. >>=20 >>=20 >> Then we could design data center networks according to best = practices, i.e. >> implement routing whenever you can and the failure domains would be = much >> smaller - also ARP, VLAN, MAC scalability issues are solved. >>=20 >> And with a session layer in the TCP/IP stack , the customer could = move his >> applications from one cloud service provider to another cloud - >> over a routed network. The security nodes should not use IP addresses = to >> verify the users/servers, instead the decoupled identifier should >> be used to grant/deny access to a resource. >>=20 >> Examples of locator/identifier split architectures are Host Identity >> Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based >> Sockets (NBS). >>=20 >> My 2 cents... >>=20 >> Patrick >> _______________________________________________ >> armd mailing list >> armd@ietf.org >> https://www.ietf.org/mailman/listinfo/armd >>=20 >>=20 > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd From k.mcewen@verizon.net Tue Feb 1 14:29:54 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C743A6C9E for ; Tue, 1 Feb 2011 14:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 rOSYxmJw+ZuU for ; Tue, 1 Feb 2011 14:29:52 -0800 (PST) Received: from smtp104.vzn.mail.ne1.yahoo.com (smtp104.vzn.mail.ne1.yahoo.com [98.138.85.47]) by core3.amsl.com (Postfix) with SMTP id 2727E3A6CA2 for ; Tue, 1 Feb 2011 14:29:51 -0800 (PST) Received: (qmail 53762 invoked from network); 1 Feb 2011 22:33:07 -0000 Received: from [192.168.1.16] (k.mcewen@71.164.229.85 with plain) by smtp104.vzn.mail.ne1.yahoo.com with SMTP; 01 Feb 2011 14:33:03 -0800 PST X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL X-YMail-OSG: sJPa548VM1my7NWgugaEd6d2iSDxcPqPyWIN1lmeYK0wn6M PbPBgrGM6JGWkqOy.LVdNdBjahuOWqOajJPoXlo5bbT_rBtGlHnkw4saceQJ igx4fOlT4hZdPpJ3VKchmYBfagVYNkUckPp9hG0bfvPZ4SaJ1ryZpPr1jYJX GA4K3S38j8ACM2HHb3OuFKp2MJipaSUeQSSe6YFq8fc9ow5N9F0cE17.2D5. g54xHgr1wkNg8plO72fIiCAxBClSjNh0MDr4Tzb.x_nZmNq8ZPBvWdcQWcrq x9KFhS6w3Z4lI8QzJT29Ttg_t9znDOK_K84cZ6b4CQ_zP9hREn41.qAOPz5R XZKlBf8ACf36xaUpp_49hg2yfcl.kO1P7.SOKnnI. X-Yahoo-Newman-Property: ymail-3 References: <006501cbc186$c6bee9d0$543cbd70$@com> <14584D6EE26B314187A4F68BA2060600067702E5@ASHEVS008.mcilink.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Kathy McEwen Date: Tue, 1 Feb 2011 16:33:00 -0600 To: Benson Schliesser Cc: Ralph Droms , "armd@ietf.org" , Susan Hares Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 22:29:54 -0000 A layer 7 approach I tightly working in co-operation with layers 0 to 7 work= s too.=20 via mobile ...=20 On Feb 1, 2011, at 3:40 PM, Benson Schliesser wrote:= > I agree with Ning. One of the basic issues that advocates of all-L3 datace= nter networks typically overlook (i.e. because it doesn't apply to them), is= multi-tenancy. It can be done with L3-centric designs, of course - with MP= LS, tunnel overlays, etc - but it's more complex and costly. There is a rea= son datacenter networks have been predominantly L2. >=20 > Cheers, > -Benson >=20 >=20 >=20 > On Feb 1, 2011, at 9:38 AM, So, Ning wrote: >=20 >> All, >>=20 >> I just want to point out that L3 solution may work for some DC design suc= h as YAHOO, but it is not a universal case. For example, TOS/COS/QoS are wi= dely deployed in many service providers' networks, and highly valued by Ente= rprise/Government customers (and their applications). Scaling L3 network ma= y not be any easier than L2 in that operational condition. I do see the nee= ds to keep the options open becasue one size fits all may not work.=20 >>=20 >>=20 >> Best regards, >>=20 >> Ning So >> Network Evolution Planning >> Verizon, Inc. >> (office) 972-729-7905 >> (Cell) 972-955-0914 >>=20 >> -----Original Message----- >> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of P= atrick Frejborg >> Sent: Tuesday, February 01, 2011 9:24 AM >> To: Susan Hares >> Cc: Ralph Droms; armd@ietf.org >> Subject: Re: [armd] Data center issues >>=20 >> Hi Susan, >>=20 >> my intention was not to interfere with your work at the WG. >>=20 >> I have been involved in some large DC network architectures and ARP >> scalability has never been an issue. My point is that we should try to >> find ways to move away from L2 topologies towards L3 topologies as >> they have at Yahoo (that is the impression I got from the link you >> posted). >>=20 >> MPTCP is evolving and that itself provides a session layer for the >> application. If we apply theoretically MPTCP on the Yahoo >> architecture, then the first subflow is connected to the load balancer >> (LB) - user is identified, MPTCP token exchanged and the IP address >> (to setup a second subflow to the real server) is exchanged with the >> client. The LB is sending the token via a trusted backdoor to the real >> server so the client and real server can establish a new subflow for >> the application - after that the client uses the application without >> traversing the LB anymore. >>=20 >> Same with VM migration - the active server freezes the application and >> send the DRAM image and MPTCP tokens (session identifiers) over to the >> standby server. At the same time the active server informs all his >> active clients that his IP address is going to change because the >> active server changes location (though the physical server is not >> changing location - the VM is moving to another place). Once the >> standby server is ready it starts to accept client sessions and the >> sessions are accepted once the tokens and other parameters matches. >> DNS needs to be updated so new clients can find the server, since it >> changed location recently. >>=20 >> It MPTCP goes mainstream, L2 issues in data centers would be history - >> but it requires upgrades of the client stack and studies what kind of >> scalability issues there are with MPTCP enabled LBs, VM migration with >> MPTCP etc. My guess is that MPTCP will happen, it will be very useful >> for smartphones to roam from one network to another. >>=20 >> Perhaps this approach is something that not belongs to IETF - perhaps >> IRTF is the right forum or perhaps it do not belong here at all? >>=20 >> So my apologizes for interfering the WG >>=20 >> Patrick >>=20 >> On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares wrote: >>> Patrick: >>>=20 >>> Yes, I agree that Data Center problem is bigger than just ARP/ND. Howeve= r, >>> to make progress on the ARP/ND portion we need to focus our work tightly= . >>>=20 >>> I agree that the problem needs the technologies of 100Gb Ethernet, IP/OT= N or >>> WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or new T= CP >>> or IPv6 options), session concepts and NM topologies to provide cross-la= yer >>> optimization for data centers. I'm actually participating with IETF folk= s in >>> all these areas on protocols or NM. >>>=20 >>> Networks/DC are focused on expanding the L2 (see the presentation below:= >>> http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk4= 5.na >>> nog51-Schaumann.pdf) >>>=20 >>> IETF WG do best by tackling one part of the total solution. We are stayi= ng >>> tightly focused on the ARP/ND problem, and proposing a very tight workin= g >>> group. We are focused on collecting publishable ARP/ND statistics, getti= ng >>> specific requirements, creating models for discussion, and creating >>> prototype that the community can access. >>>=20 >>> We have demonstrated at our BOF in Beijing that there are many solutions= to >>> the ARP/ND issues. >>>=20 >>> Linda and I have talked to many people providing DC technology or VM >>> technology or DC services. However, the topic is so hot that people do n= ot >>> want to publish their statistics due to competitive pressures. We are >>> investigating anonymous data from Research networks with similar DC >>> topologies. >>>=20 >>> If you want to suggest a WG for session layer, I will definitely attend t= hat >>> group. I'm already tracking the rest of this work, plus the IEEE VLAN gr= oup. >>>=20 >>>=20 >>> If you disagree with the tight focus, please send your comments to our A= Ds >>> (Ralph Droms and Jari Arkko). >>>=20 >>> Sue >>>=20 >>>=20 >>> -----Original Message----- >>> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of >>> Patrick Frejborg >>> Sent: Monday, January 31, 2011 1:20 PM >>> To: armd@ietf.org >>> Subject: [armd] Data center issues >>>=20 >>> Hi all, >>>=20 >>> I'm new to the list and I just read through the "Updated ARMD Charter a= nd >>> Milestones" thread. >>>=20 >>> I do agree with Thomas Narten in his post on 27th of January, this is a m= uch >>> bigger problem than only ARP. It is also about VLAN scalability, how man= y >>> MAC-addresses needs to be supported in the L2 domain, spanning-tree issu= es, >>> failure domain etc >>>=20 >>> Much of these challenges can today be solved by implementing VPLS, tomor= row >>> they can be solved by TRILL/SPB - but a L2 broadcast domain is also IMHO= a >>> failure domain since a bridge floods all unknown >>> packets out on all ports when a router only forward packets to known >>> destinations. >>>=20 >>> Thus I think the root cause to have large L2 domains is the TCP/IP stack= >>> itself - there is no session layer in the current stack. If the >>> TCP/IP stack contained a session layer, by implementing a locator/identi= fier >>> split, then the application could be moved from one server to another >>> (physical or virtual, it doesn't matter) on the fly. >>>=20 >>>=20 >>> Then we could design data center networks according to best practices, i= .e. >>> implement routing whenever you can and the failure domains would be much= >>> smaller - also ARP, VLAN, MAC scalability issues are solved. >>>=20 >>> And with a session layer in the TCP/IP stack , the customer could move h= is >>> applications from one cloud service provider to another cloud - >>> over a routed network. The security nodes should not use IP addresses to= >>> verify the users/servers, instead the decoupled identifier should >>> be used to grant/deny access to a resource. >>>=20 >>> Examples of locator/identifier split architectures are Host Identity >>> Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based >>> Sockets (NBS). >>>=20 >>> My 2 cents... >>>=20 >>> Patrick >>> _______________________________________________ >>> armd mailing list >>> armd@ietf.org >>> https://www.ietf.org/mailman/listinfo/armd >>>=20 >>>=20 >> _______________________________________________ >> 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 >=20 > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd From pfrejborg@gmail.com Wed Feb 2 04:39:02 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDDBD3A6CD1 for ; Wed, 2 Feb 2011 04:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 4Ax3sLGMeOiF for ; Wed, 2 Feb 2011 04:39:01 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 3C9283A6B77 for ; Wed, 2 Feb 2011 04:39:01 -0800 (PST) Received: by eyd10 with SMTP id 10so4142307eyd.31 for ; Wed, 02 Feb 2011 04:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qWD2AFmTZ+c5z4sCHuoHIZyaf/NOOnSTHBjpGL3+Xs8=; b=ey712ZNYcf/BDRFKxgY1CuwwFmLciKfhezkLXD/nFIu1XZf1FpiLcI7bEXdkkHeKvk 49V1QznnD6A0d32i8igMSyhFKtv4LejYWjxb0yfTa8y1AwdH4PbQQ1YStqAQsnXUZrzC wg9un881C1LY7SCGtDVzkNORVXCqGh0y0Rqp8= 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:content-transfer-encoding; b=rLVrMruDHAjOv2iAlraJtGfjUR36/1IRU3OnrBuX0dGCpoWeRDSPnVp7IA7Q+2IrNq 2xCuovWhvVycJmhh0RY1BpJEhbLh3nFaRt5Hqjb3vCu4jyOj8wEYRub/tYAhsHWH3VJn /P5VdbPOhwBZ5MiM/Gzm+BCJOI5+zKKWIxkug= MIME-Version: 1.0 Received: by 10.213.108.210 with SMTP id g18mr1291307ebp.63.1296650540195; Wed, 02 Feb 2011 04:42:20 -0800 (PST) Received: by 10.213.106.6 with HTTP; Wed, 2 Feb 2011 04:42:20 -0800 (PST) In-Reply-To: References: <006501cbc186$c6bee9d0$543cbd70$@com> <14584D6EE26B314187A4F68BA2060600067702E5@ASHEVS008.mcilink.com> Date: Wed, 2 Feb 2011 14:42:20 +0200 Message-ID: From: Patrick Frejborg To: Benson Schliesser , ning.so@verizonbusiness.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ralph Droms , Susan Hares , armd@ietf.org Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 12:39:03 -0000 Hi Benson and Ning, some thoughts on your responses: First, it is very true that there isn't a size that fits all - but that is currently the case we have today. We have to implement L2 solution regardless if it is small, mid-size, large, extra-large or extra-extra large data center. And the reason is due to current enterprise applications and tools - it is the only way if you can't change the application (which you can't). My point here is that the networking people are forced to implement L2, not because that we like to have very large L2 network around, but we do not have any other option due to the applications an enterprise is using. The very large content providers, such as Yahoo and Google, seems to have realized that large L2 networks means operational challenges - that's my conclusion from the Yahoo presentation and Google's debate with VMware around cloud http://www.infoworld.com/d/cloud-computing/google-vmware-argue-over-private= -clouds-198 It seems that in order to achieve better scalability, they are applying changes at applications to be used over L3 networks - but I could be wrong. About multi-tenancy solutions, it is very common that MPLS gets involved to solve both L2 and L3 scaling issues - and actually the L2 MPLS based solutions are way more complex to implement and operate than a MPLS L3 solution. The most important design criteria to keep in mind in order to scale L2 domains are "logical ports"and "virtual ports", if those numbers are exceeded then the network admin is sailing on deep and dark waters. AFAIK, there is only one vendor providing these kinds of parameters - it would be nice if every switch vendor came up with similar guidelines because with these parameters you can determine your L2 topology and when to move towards VPLS/TRILL/SPB. But whatever L2 technology used it will not remove the fact that a L2 domain is also a failure domain - would like to have some hands on TRILL to see how well TTL header dampens loops though. If there is loop in the L2 domain then the domain is lost. So it is a business question, do you put all your eggs in one basket or several baskets?? If you prefer to have several baskets then the operational expenditure and issues between the isolated L2 domains becomes much higher - here a common L3 domain, and if the applications support L3 endpoint mobility, would be easier and less expensive to operate. There is a tipping point when it makes sense to switch over to a L3 based DC network, if the applications just would allow us to do it.....so application architects, can we soon have applications that better support endpoint mobility, please.... Patrick On Tue, Feb 1, 2011 at 11:40 PM, Benson Schliesser wrote: > I agree with Ning. One of the basic issues that advocates of all-L3 datac= enter networks typically overlook (i.e. because it doesn't apply to them), = is multi-tenancy. =A0It can be done with L3-centric designs, of course - wi= th MPLS, tunnel overlays, etc - but it's more complex and costly. =A0There = is a reason datacenter networks have been predominantly L2. > > Cheers, > -Benson > > > > On Feb 1, 2011, at 9:38 AM, So, Ning wrote: > >> All, >> >> I just want to point out that L3 solution may work for some DC design su= ch as YAHOO, but it is not a universal case. =A0For example, TOS/COS/QoS ar= e widely deployed in many service providers' networks, and highly valued by= Enterprise/Government customers (and their applications). =A0Scaling L3 ne= twork may not be any easier than L2 in that operational condition. =A0I do = see the needs to keep the options open becasue one size fits all may not wo= rk. >> >> From skh@ndzh.com Wed Feb 2 04:46:19 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A553A7161 for ; Wed, 2 Feb 2011 04:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dhDfpylWKTn for ; Wed, 2 Feb 2011 04:46:18 -0800 (PST) Received: from hickoryhill-consulting.com (63-208-161-194.digitalrealm.net [63.208.161.194]) by core3.amsl.com (Postfix) with ESMTP id A790C3A715A for ; Wed, 2 Feb 2011 04:46:14 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=75.203.160.39; Received: from SKHPERSONALLT (unverified [75.203.160.39]) by hickoryhill-consulting.com (SurgeMail 4.2d4) with ESMTP id 2018543-1945496 for multiple; Wed, 02 Feb 2011 07:49:24 -0500 From: "Susan Hares" To: "'Linda Dunbar'" , "'Benson Schliesser'" , "'So, Ning'" , "'Patrick Frejborg'" , "'Ralph Droms'" , References: <006501cbc186$c6bee9d0$543cbd70$@com> <14584D6EE26B314187A4F68BA2060600067702E5@ASHEVS008.mcilink.com> <4A95BA014132FF49AE685FAB4B9F17F6A7F52F@DFWEML501-MBX.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6A7F52F@DFWEML501-MBX.china.huawei.com> Date: Wed, 2 Feb 2011 07:49:25 -0500 Message-ID: <000701cbc2d7$a0d630a0$e28291e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHLwXOP1tpmlEkFKkyvUsBaLT9ST5PsEMAAgAE6fICAAAQIAIAAZVEA//+FUcCAAMJW4A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 12:46:19 -0000 Ning, Linda, Benson: I think Yahoo's implementation represents choices (hacks) that deny the use of QoS/CoS/ToS bits that many industries (ex. Government) will not accept. Yet, Yahoo made these changes because the type of L2/ARMD did not exist. I think this tells us that we need to hasten the timeline on the ARMD work. So.. I strongly agree with all of you. We need to really get moving on the ARMD definitions and work. Sue -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Tuesday, February 01, 2011 5:27 PM To: Benson Schliesser; So, Ning; Patrick Frejborg; Susan Hares; Ralph Droms; armd@ietf.org Subject: RE: [armd] Data center issues Yahoo solution also requires changes to applications (hosts) and stealing the DSCP bits to carry IP information. Linda -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Benson Schliesser Sent: Tuesday, February 01, 2011 3:41 PM To: So, Ning; Patrick Frejborg; Susan Hares; Ralph Droms; armd@ietf.org Subject: Re: [armd] Data center issues I agree with Ning. One of the basic issues that advocates of all-L3 datacenter networks typically overlook (i.e. because it doesn't apply to them), is multi-tenancy. It can be done with L3-centric designs, of course - with MPLS, tunnel overlays, etc - but it's more complex and costly. There is a reason datacenter networks have been predominantly L2. Cheers, -Benson On Feb 1, 2011, at 9:38 AM, So, Ning wrote: > All, > > I just want to point out that L3 solution may work for some DC design such as YAHOO, but it is not a universal case. For example, TOS/COS/QoS are widely deployed in many service providers' networks, and highly valued by Enterprise/Government customers (and their applications). Scaling L3 network may not be any easier than L2 in that operational condition. I do see the needs to keep the options open becasue one size fits all may not work. > > > Best regards, > > Ning So > Network Evolution Planning > Verizon, Inc. > (office) 972-729-7905 > (Cell) 972-955-0914 > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Patrick Frejborg > Sent: Tuesday, February 01, 2011 9:24 AM > To: Susan Hares > Cc: Ralph Droms; armd@ietf.org > Subject: Re: [armd] Data center issues > > Hi Susan, > > my intention was not to interfere with your work at the WG. > > I have been involved in some large DC network architectures and ARP > scalability has never been an issue. My point is that we should try to > find ways to move away from L2 topologies towards L3 topologies as > they have at Yahoo (that is the impression I got from the link you > posted). > > MPTCP is evolving and that itself provides a session layer for the > application. If we apply theoretically MPTCP on the Yahoo > architecture, then the first subflow is connected to the load balancer > (LB) - user is identified, MPTCP token exchanged and the IP address > (to setup a second subflow to the real server) is exchanged with the > client. The LB is sending the token via a trusted backdoor to the real > server so the client and real server can establish a new subflow for > the application - after that the client uses the application without > traversing the LB anymore. > > Same with VM migration - the active server freezes the application and > send the DRAM image and MPTCP tokens (session identifiers) over to the > standby server. At the same time the active server informs all his > active clients that his IP address is going to change because the > active server changes location (though the physical server is not > changing location - the VM is moving to another place). Once the > standby server is ready it starts to accept client sessions and the > sessions are accepted once the tokens and other parameters matches. > DNS needs to be updated so new clients can find the server, since it > changed location recently. > > It MPTCP goes mainstream, L2 issues in data centers would be history - > but it requires upgrades of the client stack and studies what kind of > scalability issues there are with MPTCP enabled LBs, VM migration with > MPTCP etc. My guess is that MPTCP will happen, it will be very useful > for smartphones to roam from one network to another. > > Perhaps this approach is something that not belongs to IETF - perhaps > IRTF is the right forum or perhaps it do not belong here at all? > > So my apologizes for interfering the WG > > Patrick > > On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares wrote: >> Patrick: >> >> Yes, I agree that Data Center problem is bigger than just ARP/ND. However, >> to make progress on the ARP/ND portion we need to focus our work tightly. >> >> I agree that the problem needs the technologies of 100Gb Ethernet, IP/OTN or >> WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or new TCP >> or IPv6 options), session concepts and NM topologies to provide cross-layer >> optimization for data centers. I'm actually participating with IETF folks in >> all these areas on protocols or NM. >> >> Networks/DC are focused on expanding the L2 (see the presentation below: >> http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.na >> nog51-Schaumann.pdf) >> >> IETF WG do best by tackling one part of the total solution. We are staying >> tightly focused on the ARP/ND problem, and proposing a very tight working >> group. We are focused on collecting publishable ARP/ND statistics, getting >> specific requirements, creating models for discussion, and creating >> prototype that the community can access. >> >> We have demonstrated at our BOF in Beijing that there are many solutions to >> the ARP/ND issues. >> >> Linda and I have talked to many people providing DC technology or VM >> technology or DC services. However, the topic is so hot that people do not >> want to publish their statistics due to competitive pressures. We are >> investigating anonymous data from Research networks with similar DC >> topologies. >> >> If you want to suggest a WG for session layer, I will definitely attend that >> group. I'm already tracking the rest of this work, plus the IEEE VLAN group. >> >> >> If you disagree with the tight focus, please send your comments to our ADs >> (Ralph Droms and Jari Arkko). >> >> Sue >> >> >> -----Original Message----- >> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of >> Patrick Frejborg >> Sent: Monday, January 31, 2011 1:20 PM >> To: armd@ietf.org >> Subject: [armd] Data center issues >> >> Hi all, >> >> I'm new to the list and I just read through the "Updated ARMD Charter and >> Milestones" thread. >> >> I do agree with Thomas Narten in his post on 27th of January, this is a much >> bigger problem than only ARP. It is also about VLAN scalability, how many >> MAC-addresses needs to be supported in the L2 domain, spanning-tree issues, >> failure domain etc >> >> Much of these challenges can today be solved by implementing VPLS, tomorrow >> they can be solved by TRILL/SPB - but a L2 broadcast domain is also IMHO a >> failure domain since a bridge floods all unknown >> packets out on all ports when a router only forward packets to known >> destinations. >> >> Thus I think the root cause to have large L2 domains is the TCP/IP stack >> itself - there is no session layer in the current stack. If the >> TCP/IP stack contained a session layer, by implementing a locator/identifier >> split, then the application could be moved from one server to another >> (physical or virtual, it doesn't matter) on the fly. >> >> >> Then we could design data center networks according to best practices, i.e. >> implement routing whenever you can and the failure domains would be much >> smaller - also ARP, VLAN, MAC scalability issues are solved. >> >> And with a session layer in the TCP/IP stack , the customer could move his >> applications from one cloud service provider to another cloud - >> over a routed network. The security nodes should not use IP addresses to >> verify the users/servers, instead the decoupled identifier should >> be used to grant/deny access to a resource. >> >> Examples of locator/identifier split architectures are Host Identity >> Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based >> Sockets (NBS). >> >> My 2 cents... >> >> Patrick >> _______________________________________________ >> armd mailing list >> armd@ietf.org >> https://www.ietf.org/mailman/listinfo/armd >> >> > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From lars.eggert@nokia.com Wed Feb 2 05:10:37 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 9609B3A716A for ; Wed, 2 Feb 2011 05:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.394 X-Spam-Level: X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, SARE_CSBIG=1.65, 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 B9uCIkhPEQsD for ; Wed, 2 Feb 2011 05:10:36 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id CF4A53A7151 for ; Wed, 2 Feb 2011 05:10:36 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p12DDkhu023243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Feb 2011 15:13:47 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-13-517638308; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Wed, 2 Feb 2011 15:13:38 +0200 Message-Id: References: <006501cbc186$c6bee9d0$543cbd70$@com> To: Patrick Frejborg , Costin Raiciu X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 02 Feb 2011 15:13:43 +0200 (EET) X-Nokia-AV: Clean Cc: Ralph Droms , Susan Hares , armd@ietf.org Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 13:10:37 -0000 --Apple-Mail-13-517638308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Patrick, Costin (CC'ed) and others have recently played quite a bit with = MPTCP in datacenters and I have heard there are huge gains. On 2011-2-1, at 17:23, Patrick Frejborg wrote: > MPTCP is evolving and that itself provides a session layer for the > application. If we apply theoretically MPTCP on the Yahoo > architecture, then the first subflow is connected to the load balancer > (LB) - user is identified, MPTCP token exchanged and the IP address > (to setup a second subflow to the real server) is exchanged with the > client. The LB is sending the token via a trusted backdoor to the real > server so the client and real server can establish a new subflow for > the application - after that the client uses the application without > traversing the LB anymore. --Apple-Mail-13-517638308 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIwMjEzMTMzOFowIwYJKoZIhvcNAQkE MRYEFGHs23S1nnwAmG6aMpyO8iLXADsSMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AKOjVg09KKk+XHiTkXbtaSfN30trExZYclziVeh4cqhUutJ6dKXbcrz6hndIubskE7QBLYwJXwl/ tkO/LkDfYjNaB++YCVuiy6HrbTeXAEnv/hbp9NOXD00Sg26swWjUcrurgqqxiRWc6+Tf74K0WiZu xfOE4Jhm+TMuWvjermJ5JhbXOj5kyow0P8zBvyyYeSHVqbX6cYwmDyja7tCsWeYeGb8yH6Mej3cQ T16ZJ4Z8YoSnNMy38q3yQ+8HHpuxivYmFG4J0eTDda3FrscufyM2sHr97CxLnUzWNoS8WD+br2PP pXpD196qY4OTzwhk1KmGrGg8N92t7M3Fi0X/FVMAAAAAAAA= --Apple-Mail-13-517638308-- From dunbar.ll@gmail.com Wed Feb 2 07:13: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 05FFE3A6CD6 for ; Wed, 2 Feb 2011 07:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 n9d7ZSm3dgCl for ; Wed, 2 Feb 2011 07:13:11 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2385D3A6C98 for ; Wed, 2 Feb 2011 07:13:10 -0800 (PST) Received: by fxm9 with SMTP id 9so62717fxm.31 for ; Wed, 02 Feb 2011 07:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=FOWI5vQLM8NK2RfWRWfZAkv/WLg+wseQQ1d2OZpClhM=; b=rDqfoAho8IIOg3uxqpmIFucqlS2qLg4/RI0dC7XHoxMB4dy0HELNDhfVSlB2pqZsk+ O7In+5iArTmmQ/g6WMmnXJZjRIP6HO8UMuuW0goXY3EUvXxDUJrlixx5URHPIc/Ardan 1oUra1lLQYMPZbNv8SleDc/RSr6/c/OaO4l50= 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 :content-type; b=U01zI0v8/JxkRSiNFeIwGItU8/eNKD6jwQIuLY9M7PhP5beslZG+23oxfsWzG7WIAN JqT/wwx/kR7p3WoP6H22IXmZaJEb5gOEOPkHV/u43k6AdcShiELd9m1zTp2XRvCoPg4d Zo+iKoh1xX2Y2wWNQjB9EoaC0zliUd2AWLjpk= MIME-Version: 1.0 Received: by 10.223.120.193 with SMTP id e1mr6198632far.106.1296659790309; Wed, 02 Feb 2011 07:16:30 -0800 (PST) Received: by 10.223.104.131 with HTTP; Wed, 2 Feb 2011 07:16:30 -0800 (PST) In-Reply-To: References: <006501cbc186$c6bee9d0$543cbd70$@com> Date: Wed, 2 Feb 2011 09:16:30 -0600 Message-ID: From: Linda Dunbar To: Patrick Frejborg , armd@ietf.org Content-Type: multipart/alternative; boundary=001636c5b8b53229df049b4e22ed Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 15:13:14 -0000 --001636c5b8b53229df049b4e22ed Content-Type: text/plain; charset=ISO-8859-1 Hi Patrick, When you design large DC, do you always confine hosts belonging to one subnet as close as possible? The approach you described is at application layer. So is Yahoo's L3DSR approach. Yahoo's approach requires changes to applications and also changes to IP layer (to steal the DSCP bits to carry the IP information). I am sure that application layer will continuously re-inventing itself to fit into today's rigid Layer 2 boundary. But there are a lot of applications being deployed which is hard to change. If Layer 2 can re-inventing itself to eliminate all those restrictions, then existing applications can have more freedom on where they can be placed in Data Center. Linda Dunbar On Tue, Feb 1, 2011 at 9:23 AM, Patrick Frejborg wrote: > Hi Susan, > > my intention was not to interfere with your work at the WG. > > I have been involved in some large DC network architectures and ARP > scalability has never been an issue. My point is that we should try to > find ways to move away from L2 topologies towards L3 topologies as > they have at Yahoo (that is the impression I got from the link you > posted). > > MPTCP is evolving and that itself provides a session layer for the > application. If we apply theoretically MPTCP on the Yahoo > architecture, then the first subflow is connected to the load balancer > (LB) - user is identified, MPTCP token exchanged and the IP address > (to setup a second subflow to the real server) is exchanged with the > client. The LB is sending the token via a trusted backdoor to the real > server so the client and real server can establish a new subflow for > the application - after that the client uses the application without > traversing the LB anymore. > > Same with VM migration - the active server freezes the application and > send the DRAM image and MPTCP tokens (session identifiers) over to the > standby server. At the same time the active server informs all his > active clients that his IP address is going to change because the > active server changes location (though the physical server is not > changing location - the VM is moving to another place). Once the > standby server is ready it starts to accept client sessions and the > sessions are accepted once the tokens and other parameters matches. > DNS needs to be updated so new clients can find the server, since it > changed location recently. > > It MPTCP goes mainstream, L2 issues in data centers would be history - > but it requires upgrades of the client stack and studies what kind of > scalability issues there are with MPTCP enabled LBs, VM migration with > MPTCP etc. My guess is that MPTCP will happen, it will be very useful > for smartphones to roam from one network to another. > > Perhaps this approach is something that not belongs to IETF - perhaps > IRTF is the right forum or perhaps it do not belong here at all? > > So my apologizes for interfering the WG > > Patrick > > On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares wrote: > > Patrick: > > > > Yes, I agree that Data Center problem is bigger than just ARP/ND. > However, > > to make progress on the ARP/ND portion we need to focus our work tightly. > > > > I agree that the problem needs the technologies of 100Gb Ethernet, IP/OTN > or > > WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or new > TCP > > or IPv6 options), session concepts and NM topologies to provide > cross-layer > > optimization for data centers. I'm actually participating with IETF folks > in > > all these areas on protocols or NM. > > > > Networks/DC are focused on expanding the L2 (see the presentation below: > > > http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.na > > nog51-Schaumann.pdf) > > > > IETF WG do best by tackling one part of the total solution. We are > staying > > tightly focused on the ARP/ND problem, and proposing a very tight working > > group. We are focused on collecting publishable ARP/ND statistics, > getting > > specific requirements, creating models for discussion, and creating > > prototype that the community can access. > > > > We have demonstrated at our BOF in Beijing that there are many solutions > to > > the ARP/ND issues. > > > > Linda and I have talked to many people providing DC technology or VM > > technology or DC services. However, the topic is so hot that people do > not > > want to publish their statistics due to competitive pressures. We are > > investigating anonymous data from Research networks with similar DC > > topologies. > > > > If you want to suggest a WG for session layer, I will definitely attend > that > > group. I'm already tracking the rest of this work, plus the IEEE VLAN > group. > > > > > > If you disagree with the tight focus, please send your comments to our > ADs > > (Ralph Droms and Jari Arkko). > > > > Sue > > > > > > -----Original Message----- > > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > > Patrick Frejborg > > Sent: Monday, January 31, 2011 1:20 PM > > To: armd@ietf.org > > Subject: [armd] Data center issues > > > > Hi all, > > > > I'm new to the list and I just read through the "Updated ARMD Charter > and > > Milestones" thread. > > > > I do agree with Thomas Narten in his post on 27th of January, this is a > much > > bigger problem than only ARP. It is also about VLAN scalability, how many > > MAC-addresses needs to be supported in the L2 domain, spanning-tree > issues, > > failure domain etc > > > > Much of these challenges can today be solved by implementing VPLS, > tomorrow > > they can be solved by TRILL/SPB - but a L2 broadcast domain is also IMHO > a > > failure domain since a bridge floods all unknown > > packets out on all ports when a router only forward packets to known > > destinations. > > > > Thus I think the root cause to have large L2 domains is the TCP/IP stack > > itself - there is no session layer in the current stack. If the > > TCP/IP stack contained a session layer, by implementing a > locator/identifier > > split, then the application could be moved from one server to another > > (physical or virtual, it doesn't matter) on the fly. > > > > > > Then we could design data center networks according to best practices, > i.e. > > implement routing whenever you can and the failure domains would be much > > smaller - also ARP, VLAN, MAC scalability issues are solved. > > > > And with a session layer in the TCP/IP stack , the customer could move > his > > applications from one cloud service provider to another cloud - > > over a routed network. The security nodes should not use IP addresses to > > verify the users/servers, instead the decoupled identifier should > > be used to grant/deny access to a resource. > > > > Examples of locator/identifier split architectures are Host Identity > > Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based > > Sockets (NBS). > > > > My 2 cents... > > > > Patrick > > _______________________________________________ > > armd mailing list > > armd@ietf.org > > https://www.ietf.org/mailman/listinfo/armd > > > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > --001636c5b8b53229df049b4e22ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Patrick,
=A0
When you design large DC, do you always confine hosts belonging to one= subnet as close as possible?
=A0
The approach you described is at application layer. So is Yahoo's = L3DSR approach. Yahoo's approach requires changes to applications and a= lso changes to IP layer (to steal the DSCP bits to carry the IP information= ).
I am sure that application layer will continuously re-inventing itself= to fit into today's rigid Layer 2 boundary.
But there are a lot of applications being deployed which is hard to ch= ange.=A0If Layer 2 can re-inventing itself to=A0eliminate all those restric= tions, then=A0existing applications can have more freedom on where they=A0c= an be placed in Data Center.=A0
=A0
Linda Dunbar
=A0

=A0
On Tue, Feb 1, 2011 at 9:23 AM, Patrick Frejborg= <pfrejborg@gma= il.com> wrote:
Hi Susan,

my intention wa= s not to interfere with your work at the WG.

I have been involved in= some large DC network architectures and ARP
scalability has never been an issue. My point is that we should try to
f= ind ways to move away from L2 topologies towards L3 topologies as
they h= ave at Yahoo (that is the impression I got from the link you
posted).
MPTCP is evolving and that itself provides a session layer for the
a= pplication. If we apply theoretically MPTCP on the Yahoo
architecture, t= hen the first subflow is connected to the load balancer
(LB) - user is i= dentified, MPTCP token exchanged and the IP address
(to setup a second subflow to the real server) is exchanged with the
cli= ent. The LB is sending the token via a trusted backdoor to the real
serv= er so the client and real server can establish a new subflow for
the app= lication - after that the client =A0uses the application without
traversing the LB anymore.

Same with VM migration - the active serve= r freezes the application and
send the DRAM image and MPTCP tokens (sess= ion identifiers) over to the
standby server. At the same time the active= server informs all his
active clients that his IP address is going to change because the
active= server changes location (though the physical server is not
changing loc= ation - the VM is moving to another place). Once the
standby =A0server i= s ready it starts to accept client sessions and the
sessions are accepted once the tokens and other parameters matches.
DNS = needs to be updated so new clients can find the server, since it
changed= location recently.

It MPTCP goes mainstream, L2 issues in data cent= ers would be history -
but it requires upgrades of the client stack and studies what kind of
sc= alability issues there are with MPTCP enabled LBs, VM migration with
MPT= CP etc. My guess is that MPTCP will happen, it will be very useful
for s= martphones to roam from one network to another.

Perhaps this approach is something that not belongs to IETF - perhapsIRTF is the right forum or perhaps it do not belong here at all?

S= o my apologizes for interfering the WG

Patri= ck

On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares <skh@ndzh.com> wrote:
> Patrick:>
> Yes, I agree that Data Center problem is bigger than just AR= P/ND. However,
> to make progress on the ARP/ND portion we need to focus our work tight= ly.
>
> I agree that the problem needs the technologies of 100G= b Ethernet, IP/OTN or
> WDWM, 802.1aq/SPB and TRILL plus new TCP/IP s= tack options (STCP or new TCP
> or IPv6 options), session concepts and NM topologies to provide cross-= layer
> optimization for data centers. I'm actually participating= with IETF folks in
> all these areas on protocols or NM.
>
> Networks/DC are focused on expanding the L2 (see the presentation belo= w:
> http://www.nanog.org/meetings/na= nog51/presentations/Monday/NANOG51.Talk45.na
> nog51-Schaumann.pdf)
>
> IETF WG do best by tackling one p= art of the total solution. We are staying
> tightly focused on the AR= P/ND problem, and proposing a very tight working
> group. We are focu= sed on collecting publishable ARP/ND statistics, getting
> specific requirements, creating models for discussion, and creating> prototype that the community can access.
>
> We have demo= nstrated at our BOF in Beijing that there are many solutions to
> the= ARP/ND issues.
>
> Linda and I have talked to many people providing DC technology= or VM
> technology or DC services. However, the topic is so hot that= people do not
> want to publish their statistics due to competitive = pressures. We are
> investigating anonymous data from Research networks with similar DC> topologies.
>
> If you want to suggest a WG for session l= ayer, I will definitely attend that
> group. I'm already tracking= the rest of this work, plus the IEEE VLAN group.
>
>
> If you disagree with the tight focus, please send your= comments to our ADs
> (Ralph Droms and Jari Arkko).
>
> = Sue
>
>
> -----Original Message-----
> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of<= br> > Patrick Frejborg
> Sent: Monday, January 31, 2011 1:20 PM
>= ; To: armd@ietf.org
> Subject: [= armd] Data center issues
>
> Hi all,
>
> I'm ne= w to the list and I just read through =A0the "Updated ARMD Charter and=
> Milestones" thread.
>
> I do agree with Thomas Narten= in his post on 27th of January, this is a much
> bigger problem than= only ARP. It is also about VLAN scalability, how many
> MAC-addresse= s needs to be supported in the L2 domain, spanning-tree issues,
> failure domain etc
>
> Much of these challenges can today = be solved by implementing VPLS, tomorrow
> they can be solved by TRIL= L/SPB - but a L2 broadcast domain is also IMHO a
> failure domain sin= ce a bridge floods all unknown
> packets out on all ports when a router only forward packets to known> destinations.
>
> Thus I think the root cause to have la= rge L2 domains is the TCP/IP stack
> itself - there is no session lay= er in the current stack. If the
> TCP/IP stack contained a session layer, by implementing a locator/iden= tifier
> split, then the application could be moved from one server t= o another
> (physical or virtual, it doesn't matter) on the fly.<= br> >
>
> Then we could design data center networks according to= best practices, i.e.
> implement routing whenever you can and the fa= ilure domains would be much
> smaller - also ARP, VLAN, MAC scalabili= ty issues are solved.
>
> And with a session layer in the TCP/IP stack , the customer co= uld move his
> applications from one cloud service provider to anothe= r cloud -
> over a routed network. The security nodes should not use = IP addresses to
> verify the users/servers, instead the decoupled identifier should
&= gt; be used to grant/deny access to a resource.
>
> Examples of= =A0locator/identifier split architectures are Host Identity
> Protoc= ol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based
> Sockets (NBS).
>
> My 2 cents...
>
> Patrick> _______________________________________________
> armd mailing= list
> armd@ietf.org
> http= s://www.ietf.org/mailman/listinfo/armd
>
>
_______________________________________________
armd mai= ling list
armd@ietf.org
https://w= ww.ietf.org/mailman/listinfo/armd

--001636c5b8b53229df049b4e22ed-- From ning.so@verizonbusiness.com Wed Feb 2 07:37:38 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3BA3A6D1C for ; Wed, 2 Feb 2011 07:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 Qd05XHdUQSDb for ; Wed, 2 Feb 2011 07:37:31 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id E27C53A6D0E for ; Wed, 2 Feb 2011 07:37:30 -0800 (PST) Received: from omzismtp01.vzbi.com ([unknown] [165.122.46.164]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LFZ00LOKY81CP10@firewall.verizonbusiness.com> for armd@ietf.org; Wed, 02 Feb 2011 15:40:50 +0000 (GMT) Received: from omzismtp01.vzbi.com ([unknown] [127.0.0.1]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LFZ0065PY81YU00@omzismtp01.vzbi.com> for armd@ietf.org; Wed, 02 Feb 2011 15:40:49 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([unknown] [153.39.68.167]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LFZ006BWY80YH00@omzismtp01.vzbi.com> for armd@ietf.org; Wed, 02 Feb 2011 15:40:49 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 02 Feb 2011 15:40:48 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CBC2EF.90306EA1" Date: Wed, 02 Feb 2011 15:40:45 +0000 Message-id: <14584D6EE26B314187A4F68BA206060006770B38@ASHEVS008.mcilink.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [armd] Data center issues Thread-index: AcvC7DgcH6YutSEwS6qskdLdMMFr4wAAnDAg References: <006501cbc186$c6bee9d0$543cbd70$@com> From: "So, Ning" To: Linda Dunbar , Patrick Frejborg , armd@ietf.org X-OriginalArrivalTime: 02 Feb 2011 15:40:48.0615 (UTC) FILETIME=[906BD770:01CBC2EF] Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 15:37:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC2EF.90306EA1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I see a lot of people are addressing the different needs and wants, and what can or cannot be done. So here is one more piece of "needs" from a Cloud Service Provider and Data Center Operator's perspective. Whatever the new direction we collectively are taking, it has to have backward compatibility and seamless transition from the current operating environment. Please keeping mind operators like flexibility, a lot. =20 =20 Best regards, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 ________________________________ From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, February 02, 2011 9:17 AM To: Patrick Frejborg; armd@ietf.org Subject: Re: [armd] Data center issues =20 Hi Patrick,=20 =20 When you design large DC, do you always confine hosts belonging to one subnet as close as possible?=20 =20 The approach you described is at application layer. So is Yahoo's L3DSR approach. Yahoo's approach requires changes to applications and also changes to IP layer (to steal the DSCP bits to carry the IP information).=20 I am sure that application layer will continuously re-inventing itself to fit into today's rigid Layer 2 boundary.=20 But there are a lot of applications being deployed which is hard to change. If Layer 2 can re-inventing itself to eliminate all those restrictions, then existing applications can have more freedom on where they can be placed in Data Center.=20 =20 Linda Dunbar =20 =20 On Tue, Feb 1, 2011 at 9:23 AM, Patrick Frejborg wrote: Hi Susan, my intention was not to interfere with your work at the WG. I have been involved in some large DC network architectures and ARP scalability has never been an issue. My point is that we should try to find ways to move away from L2 topologies towards L3 topologies as they have at Yahoo (that is the impression I got from the link you posted). MPTCP is evolving and that itself provides a session layer for the application. If we apply theoretically MPTCP on the Yahoo architecture, then the first subflow is connected to the load balancer (LB) - user is identified, MPTCP token exchanged and the IP address (to setup a second subflow to the real server) is exchanged with the client. The LB is sending the token via a trusted backdoor to the real server so the client and real server can establish a new subflow for the application - after that the client uses the application without traversing the LB anymore. Same with VM migration - the active server freezes the application and send the DRAM image and MPTCP tokens (session identifiers) over to the standby server. At the same time the active server informs all his active clients that his IP address is going to change because the active server changes location (though the physical server is not changing location - the VM is moving to another place). Once the standby server is ready it starts to accept client sessions and the sessions are accepted once the tokens and other parameters matches. DNS needs to be updated so new clients can find the server, since it changed location recently. It MPTCP goes mainstream, L2 issues in data centers would be history - but it requires upgrades of the client stack and studies what kind of scalability issues there are with MPTCP enabled LBs, VM migration with MPTCP etc. My guess is that MPTCP will happen, it will be very useful for smartphones to roam from one network to another. Perhaps this approach is something that not belongs to IETF - perhaps IRTF is the right forum or perhaps it do not belong here at all? So my apologizes for interfering the WG Patrick On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares wrote: > Patrick: > > Yes, I agree that Data Center problem is bigger than just ARP/ND. However, > to make progress on the ARP/ND portion we need to focus our work tightly. > > I agree that the problem needs the technologies of 100Gb Ethernet, IP/OTN or > WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or new TCP > or IPv6 options), session concepts and NM topologies to provide cross-layer > optimization for data centers. I'm actually participating with IETF folks in > all these areas on protocols or NM. > > Networks/DC are focused on expanding the L2 (see the presentation below: > http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk4 5.na > nog51-Schaumann.pdf) > > IETF WG do best by tackling one part of the total solution. We are staying > tightly focused on the ARP/ND problem, and proposing a very tight working > group. We are focused on collecting publishable ARP/ND statistics, getting > specific requirements, creating models for discussion, and creating > prototype that the community can access. > > We have demonstrated at our BOF in Beijing that there are many solutions to > the ARP/ND issues. > > Linda and I have talked to many people providing DC technology or VM > technology or DC services. However, the topic is so hot that people do not > want to publish their statistics due to competitive pressures. We are > investigating anonymous data from Research networks with similar DC > topologies. > > If you want to suggest a WG for session layer, I will definitely attend that > group. I'm already tracking the rest of this work, plus the IEEE VLAN group. > > > If you disagree with the tight focus, please send your comments to our ADs > (Ralph Droms and Jari Arkko). > > Sue > > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Patrick Frejborg > Sent: Monday, January 31, 2011 1:20 PM > To: armd@ietf.org > Subject: [armd] Data center issues > > Hi all, > > I'm new to the list and I just read through the "Updated ARMD Charter and > Milestones" thread. > > I do agree with Thomas Narten in his post on 27th of January, this is a much > bigger problem than only ARP. It is also about VLAN scalability, how many > MAC-addresses needs to be supported in the L2 domain, spanning-tree issues, > failure domain etc > > Much of these challenges can today be solved by implementing VPLS, tomorrow > they can be solved by TRILL/SPB - but a L2 broadcast domain is also IMHO a > failure domain since a bridge floods all unknown > packets out on all ports when a router only forward packets to known > destinations. > > Thus I think the root cause to have large L2 domains is the TCP/IP stack > itself - there is no session layer in the current stack. If the > TCP/IP stack contained a session layer, by implementing a locator/identifier > split, then the application could be moved from one server to another > (physical or virtual, it doesn't matter) on the fly. > > > Then we could design data center networks according to best practices, i.e. > implement routing whenever you can and the failure domains would be much > smaller - also ARP, VLAN, MAC scalability issues are solved. > > And with a session layer in the TCP/IP stack , the customer could move his > applications from one cloud service provider to another cloud - > over a routed network. The security nodes should not use IP addresses to > verify the users/servers, instead the decoupled identifier should > be used to grant/deny access to a resource. > > Examples of locator/identifier split architectures are Host Identity > Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based > Sockets (NBS). > > My 2 cents... > > Patrick > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd =20 ------_=_NextPart_001_01CBC2EF.90306EA1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I see a lot of people are = addressing the different needs and wants, and what can or cannot be done.  So here = is one more piece of “needs” from a Cloud Service Provider and Data = Center Operator’s perspective.  Whatever the new direction we = collectively are taking, it has to have backward compatibility and seamless = transition from the current operating environment.  Please keeping mind operators = like flexibility, a lot.

 

 

=

Best regards,

 

=

Ning So

Network Evolution = Planning

Verizon, Inc.

(office) = 972-729-7905

(Cell) = 972-955-0914

 

=

From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, February = 02, 2011 9:17 AM
To: Patrick Frejborg; armd@ietf.org
Subject: Re: [armd] Data = center issues

 

Hi Patrick,

 

When you design large DC, do you always confine hosts belonging = to one subnet as close as possible?

 

The approach you described is at application layer. So is = Yahoo's L3DSR approach. Yahoo's approach requires changes to applications and also = changes to IP layer (to steal the DSCP bits to carry the IP information). =

I am sure that application layer will continuously re-inventing = itself to fit into today's rigid Layer 2 boundary. =

But there are a lot of applications being deployed which is hard = to change. If Layer 2 can re-inventing itself to eliminate all = those restrictions, then existing applications can have more freedom on = where they can be placed in Data Center. 

 

Linda Dunbar

 


 

On Tue, Feb 1, 2011 at 9:23 AM, Patrick Frejborg <pfrejborg@gmail.com> = wrote:

Hi Susan,

my intention was not to interfere with your work at the WG.

I have been involved in some large DC network architectures and ARP
scalability has never been an issue. My point is that we should try = to
find ways to move away from L2 topologies towards L3 topologies as
they have at Yahoo (that is the impression I got from the link you
posted).

MPTCP is evolving and that itself provides a session layer for the
application. If we apply theoretically MPTCP on the Yahoo
architecture, then the first subflow is connected to the load = balancer
(LB) - user is identified, MPTCP token exchanged and the IP address
(to setup a second subflow to the real server) is exchanged with the
client. The LB is sending the token via a trusted backdoor to the = real
server so the client and real server can establish a new subflow for
the application - after that the client  uses the application = without
traversing the LB anymore.

Same with VM migration - the active server freezes the application = and
send the DRAM image and MPTCP tokens (session identifiers) over to = the
standby server. At the same time the active server informs all his
active clients that his IP address is going to change because the
active server changes location (though the physical server is not
changing location - the VM is moving to another place). Once the
standby  server is ready it starts to accept client sessions and = the
sessions are accepted once the tokens and other parameters matches.
DNS needs to be updated so new clients can find the server, since it
changed location recently.

It MPTCP goes mainstream, L2 issues in data centers would be history = -
but it requires upgrades of the client stack and studies what kind = of
scalability issues there are with MPTCP enabled LBs, VM migration = with
MPTCP etc. My guess is that MPTCP will happen, it will be very = useful
for smartphones to roam from one network to another.

Perhaps this approach is something that not belongs to IETF - = perhaps
IRTF is the right forum or perhaps it do not belong here at all?

So my apologizes for interfering the WG

Patrick


On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares <skh@ndzh.com> wrote:
> Patrick:
>
> Yes, I agree that Data Center problem = is bigger than just ARP/ND. However,
> to make progress on the ARP/ND portion we need to focus our work = tightly.
>
> I agree that the problem needs the technologies of 100Gb Ethernet, = IP/OTN or
> WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or = new TCP
> or IPv6 options), session concepts and NM topologies to provide cross-layer
> optimization for data centers. I'm actually participating with IETF = folks in
> all these areas on protocols or NM.
>
> Networks/DC are focused on expanding the L2 (see the presentation = below:
> http://www.nanog.org/meetings/nanog51/presentations/Mon= day/NANOG51.Talk45.na
> nog51-Schaumann.pdf)
>
> IETF WG do best by tackling one part of the total solution. We are = staying
> tightly focused on the ARP/ND problem, and proposing a very tight = working
> group. We are focused on collecting publishable ARP/ND statistics, = getting
> specific requirements, creating models for discussion, and = creating
> prototype that the community can access.
>
> We have demonstrated at our BOF in Beijing that there are many solutions to
> the ARP/ND issues.
>
> Linda and I have talked to many people providing DC technology or = VM
> technology or DC services. However, the topic is so hot that people = do not
> want to publish their statistics due to competitive pressures. We = are
> investigating anonymous data from Research networks with similar = DC
> topologies.
>
> If you want to suggest a WG for session layer, I will definitely = attend that
> group. I'm already tracking the rest of this work, plus the IEEE = VLAN group.
>
>
> If you disagree with the tight focus, please send your comments to = our ADs
> (Ralph Droms and Jari Arkko).
>
> Sue
>
>
> -----Original Message-----
> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of
> Patrick Frejborg
> Sent: Monday, January 31, 2011 1:20 PM
> To: armd@ietf.org
> Subject: [armd] Data center issues
>
> Hi all,
>
> I'm new to the list and I just read through  the "Updated = ARMD Charter and
> Milestones" thread.
>
> I do agree with Thomas Narten in his post on 27th of January, this = is a much
> bigger problem than only ARP. It is also about VLAN scalability, = how many
> MAC-addresses needs to be supported in the L2 domain, spanning-tree issues,
> failure domain etc
>
> Much of these challenges can today be solved by implementing VPLS, tomorrow
> they can be solved by TRILL/SPB - but a L2 broadcast domain is also = IMHO a
> failure domain since a bridge floods all unknown
> packets out on all ports when a router only forward packets to = known
> destinations.
>
> Thus I think the root cause to have large L2 domains is the TCP/IP = stack
> itself - there is no session layer in the current stack. If the
> TCP/IP stack contained a session layer, by implementing a = locator/identifier
> split, then the application could be moved from one server to = another
> (physical or virtual, it doesn't matter) on the fly.
>
>
> Then we could design data center networks according to best = practices, i.e.
> implement routing whenever you can and the failure domains would be = much
> smaller - also ARP, VLAN, MAC scalability issues are solved.
>
> And with a session layer in the TCP/IP stack , the customer could = move his
> applications from one cloud service provider to another cloud -
> over a routed network. The security nodes should not use IP = addresses to
> verify the users/servers, instead the decoupled identifier = should
> be used to grant/deny access to a resource.
>
> Examples of  locator/identifier split architectures are Host = Identity
> Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name = Based
> Sockets (NBS).
>
> My 2 cents...
>
> Patrick
> _______________________________________________
> armd mailing list
> armd@ietf.org
> https://www.ietf.org/mailman/listinfo/armd
>
>
_______________________________________________
armd mailing list
armd@ietf.org
https://www.ietf.org/mailman/listinfo/armd

 

------_=_NextPart_001_01CBC2EF.90306EA1-- From bedard.phil@gmail.com Wed Feb 2 08:47:06 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F02DC3A6D86 for ; Wed, 2 Feb 2011 08:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, 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 IbAlzZWoE0O8 for ; Wed, 2 Feb 2011 08:46:55 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id D2D453A6D2B for ; Wed, 2 Feb 2011 08:46:54 -0800 (PST) Received: by yie19 with SMTP id 19so84477yie.31 for ; Wed, 02 Feb 2011 08:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=er1JSL7XfE81PJXgsyGa0kxxqJOwU8zmMA+gjNi2m9k=; b=igdJwY3HKVGpTW55NVENE1ay5Q5wqWF6TZp44azOIHExZ9j+fdIDZxdaDE6vUEsNO9 MVc35iC7CJetvx0HJIzGTqPHn1nIRfvOysKjeFQR+TcvFF5mW48+H2iX0NrrE8lw6/FK mZxkZXfWU2obd+AT5uwNJYlZb8nc8q6tQthaA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type; b=fGS5SJCvKUk9oXeem0R7IoWRR1tY/tUqYTDVtvm+0ZRMuXtVSp/y1vGt9gO1B6nLn/ Hd12RqA7khs4hrqqoKSozublhxIoLy1NI8Bun+F3xb5fTt4kqjglCeTkyefcitWD4kzA ZxjT0Fn3BZBioC/hjQBGAM22AAf16/LVkw60U= Received: by 10.150.181.21 with SMTP id d21mr212281ybf.146.1296665414130; Wed, 02 Feb 2011 08:50:14 -0800 (PST) Received: from [10.63.84.103] (gw1.cox.com [24.248.74.254]) by mx.google.com with ESMTPS id u5sm3526853yba.22.2011.02.02.08.50.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 08:50:12 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Wed, 02 Feb 2011 11:50:05 -0500 From: Phil Bedard To: "So, Ning" , Linda Dunbar , Patrick Frejborg , Message-ID: Thread-Topic: [armd] Data center issues In-Reply-To: <14584D6EE26B314187A4F68BA206060006770B38@ASHEVS008.mcilink.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379492211_16459186" Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 16:47:06 -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_3379492211_16459186 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I agree with this. I think we could solve almost all of the issues at the application layer if it was really a choice, but it's not. Yahoo did not have a host mobility problem, which is one of the bigger problems identified thus far. They had a problem of L2 domain scale and the use of STP, with existing equipment. Standards and vendors are moving towards eliminating STP to increase efficiency and greatly increase the scale of L2 domains. Larger L2 networks are going to be the norm in the future, whether we like it or not. I am all for pushing application vendors to making their applications more friendly to mobility with location identifiers and transport connectivity which is dynamically configured. However, people have been talking about this for years and not much to date has materialized. Phil =20 From: "So, Ning" Date: Wed, 02 Feb 2011 15:40:45 +0000 To: Linda Dunbar , Patrick Frejborg , Subject: Re: [armd] Data center issues All, =20 I see a lot of people are addressing the different needs and wants, and wha= t can or cannot be done. So here is one more piece of =B3needs=B2 from a Cloud Service Provider and Data Center Operator=B9s perspective. Whatever the new direction we collectively are taking, it has to have backward compatibility and seamless transition from the current operating environment. Please keeping mind operators like flexibility, a lot. =20 =20 Best regards, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, February 02, 2011 9:17 AM To: Patrick Frejborg; armd@ietf.org Subject: Re: [armd] Data center issues =20 Hi Patrick,=20 =20 When you design large DC, do you always confine hosts belonging to one subnet as close as possible? =20 The approach you described is at application layer. So is Yahoo's L3DSR approach. Yahoo's approach requires changes to applications and also change= s to IP layer (to steal the DSCP bits to carry the IP information). I am sure that application layer will continuously re-inventing itself to fit into today's rigid Layer 2 boundary. But there are a lot of applications being deployed which is hard to change. If Layer 2 can re-inventing itself to eliminate all those restrictions, the= n existing applications can have more freedom on where they can be placed in Data Center.=20 =20 Linda Dunbar =20 =20 On Tue, Feb 1, 2011 at 9:23 AM, Patrick Frejborg wrote: Hi Susan, my intention was not to interfere with your work at the WG. I have been involved in some large DC network architectures and ARP scalability has never been an issue. My point is that we should try to find ways to move away from L2 topologies towards L3 topologies as they have at Yahoo (that is the impression I got from the link you posted). MPTCP is evolving and that itself provides a session layer for the application. If we apply theoretically MPTCP on the Yahoo architecture, then the first subflow is connected to the load balancer (LB) - user is identified, MPTCP token exchanged and the IP address (to setup a second subflow to the real server) is exchanged with the client. The LB is sending the token via a trusted backdoor to the real server so the client and real server can establish a new subflow for the application - after that the client uses the application without traversing the LB anymore. Same with VM migration - the active server freezes the application and send the DRAM image and MPTCP tokens (session identifiers) over to the standby server. At the same time the active server informs all his active clients that his IP address is going to change because the active server changes location (though the physical server is not changing location - the VM is moving to another place). Once the standby server is ready it starts to accept client sessions and the sessions are accepted once the tokens and other parameters matches. DNS needs to be updated so new clients can find the server, since it changed location recently. It MPTCP goes mainstream, L2 issues in data centers would be history - but it requires upgrades of the client stack and studies what kind of scalability issues there are with MPTCP enabled LBs, VM migration with MPTCP etc. My guess is that MPTCP will happen, it will be very useful for smartphones to roam from one network to another. Perhaps this approach is something that not belongs to IETF - perhaps IRTF is the right forum or perhaps it do not belong here at all? So my apologizes for interfering the WG Patrick On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares wrote: > Patrick: > > Yes, I agree that Data Center problem is bigger than just ARP/ND. However= , > to make progress on the ARP/ND portion we need to focus our work tightly. > > I agree that the problem needs the technologies of 100Gb Ethernet, IP/OTN= or > WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or new TC= P > or IPv6 options), session concepts and NM topologies to provide cross-lay= er > optimization for data centers. I'm actually participating with IETF folks= in > all these areas on protocols or NM. > > Networks/DC are focused on expanding the L2 (see the presentation below: > http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45= .na > nog51-Schaumann.pdf) > > IETF WG do best by tackling one part of the total solution. We are stayin= g > tightly focused on the ARP/ND problem, and proposing a very tight working > group. We are focused on collecting publishable ARP/ND statistics, gettin= g > specific requirements, creating models for discussion, and creating > prototype that the community can access. > > We have demonstrated at our BOF in Beijing that there are many solutions = to > the ARP/ND issues. > > Linda and I have talked to many people providing DC technology or VM > technology or DC services. However, the topic is so hot that people do no= t > want to publish their statistics due to competitive pressures. We are > investigating anonymous data from Research networks with similar DC > topologies. > > If you want to suggest a WG for session layer, I will definitely attend t= hat > group. I'm already tracking the rest of this work, plus the IEEE VLAN gro= up. > > > If you disagree with the tight focus, please send your comments to our AD= s > (Ralph Droms and Jari Arkko). > > Sue > > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Patrick Frejborg > Sent: Monday, January 31, 2011 1:20 PM > To: armd@ietf.org > Subject: [armd] Data center issues > > Hi all, > > I'm new to the list and I just read through the "Updated ARMD Charter an= d > Milestones" thread. > > I do agree with Thomas Narten in his post on 27th of January, this is a m= uch > bigger problem than only ARP. It is also about VLAN scalability, how many > MAC-addresses needs to be supported in the L2 domain, spanning-tree issue= s, > failure domain etc > > Much of these challenges can today be solved by implementing VPLS, tomorr= ow > they can be solved by TRILL/SPB - but a L2 broadcast domain is also IMHO = a > failure domain since a bridge floods all unknown > packets out on all ports when a router only forward packets to known > destinations. > > Thus I think the root cause to have large L2 domains is the TCP/IP stack > itself - there is no session layer in the current stack. If the > TCP/IP stack contained a session layer, by implementing a locator/identif= ier > split, then the application could be moved from one server to another > (physical or virtual, it doesn't matter) on the fly. > > > Then we could design data center networks according to best practices, i.= e. > implement routing whenever you can and the failure domains would be much > smaller - also ARP, VLAN, MAC scalability issues are solved. > > And with a session layer in the TCP/IP stack , the customer could move hi= s > applications from one cloud service provider to another cloud - > over a routed network. The security nodes should not use IP addresses to > verify the users/servers, instead the decoupled identifier should > be used to grant/deny access to a resource. > > Examples of locator/identifier split architectures are Host Identity > Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based > Sockets (NBS). > > My 2 cents... > > Patrick > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd =20 _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd --B_3379492211_16459186 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
I agree with this.=  I think we could solve almost all of the issues at the application la= yer if it was really a choice, but it's not.  
Yahoo did not have a host mobility problem, which is one of the= bigger problems identified thus far.   They had a problem of L2 domain= scale and the use of STP, with existing equipment.   Standards and ven= dors are moving towards eliminating STP to increase efficiency and greatly i= ncrease the scale of L2 domains.    Larger L2 networks are going t= o be the norm in the future, whether we like it or not.    
<= div>
I am all for pushing application vendors to making their = applications more friendly to mobility with location identifiers and transpo= rt connectivity which is dynamically configured.   However, people have= been talking about this for years and not much to date has materialized. &n= bsp;

Phil     

<= span id=3D"OLK_SRC_BODY_SECTION">
From: "So, Ning" <ning.so@verizonbusiness.com>
Date: Wed, 02 Feb 2011 15:40:45 +0000
To: Linda Dunbar <dunbar.ll@gmail.com>, Patrick Frejborg <pfrejborg@gmail.com>, <armd@ietf.org>
Subject:= Re: [armd] Data center issues

All,

 

I see a lot of people are addressing t= he different needs and wants, and what can or cannot be done.  So here is= one more piece of “needs” from a Cloud Service Provider and Data Ce= nter Operator’s perspective.  Whatever the new direction we collectiv= ely are taking, it has to have backward compatibility and seamless transition f= rom the current operating environment.  Please keeping mind operators like= flexibility, a lot.

 

 

<= p class=3D"MsoNormal">Best regards,

 

Ning So

Network Evolution Planning

<= p class=3D"MsoNormal">Verizon, Inc.

(office) 972-729-7905

(Cell) 972-955-0914

 

=

From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, February 02, 2011 9:17 AM
To: Patrick Frejbor= g; armd@ietf.org
Subject: Re: [armd] Data center issues

 

Hi Patrick,

 

= When you design large DC, do you always confine hosts belonging to = one subnet as close as possible?

 

= The approach you described is at application layer. So is Yahoo's L= 3DSR approach. Yahoo's approach requires changes to applications and also change= s to IP layer (to steal the DSCP bits to carry the IP information). <= /span>

I am sure that application layer will continuously re-inventing its= elf to fit into today's rigid Layer 2 boundary.

But there are a lot of applications being deployed which is hard to= change. If Layer 2 can re-inventing itself to eliminate all those= restrictions, then existing applications can have more freedom on wher= e they can be placed in Da= ta Center. 

 

= Linda Dunbar

 

=
 

On Tue, Feb 1, 2011 at 9:23 AM, Patrick Frejborg <pfrejborg@gmail.com> wrote:<= /font>

Hi Susan,

my intention was not to interfere with your work at the WG.

I have been involved in some large DC network architectures and ARP
scalability has never been an issue. My point is that we should try to
find ways to move away from L2 topologies towards L3 topologies as
they have at Yahoo (that is the impression I got from the link you
posted).

MPTCP is evolving and that itself provides a session layer for the
application. If we apply theoretically MPTCP on the Yahoo
architecture, then the first subflow is connected to the load balancer
(LB) - user is identified, MPTCP token exchanged and the IP address
(to setup a second subflow to the real server) is exchanged with the
client. The LB is sending the token via a trusted backdoor to the real
server so the client and real server can establish a new subflow for
the application - after that the client  uses the application without<= br> traversing the LB anymore.

Same with VM migration - the active server freezes the application and
send the DRAM image and MPTCP tokens (session identifiers) over to the
standby server. At the same time the active server informs all his
active clients that his IP address is going to change because the
active server changes location (though the physical server is not
changing location - the VM is moving to another place). Once the
standby  server is ready it starts to accept client sessions and the sessions are accepted once the tokens and other parameters matches.
DNS needs to be updated so new clients can find the server, since it
changed location recently.

It MPTCP goes mainstream, L2 issues in data centers would be history -
but it requires upgrades of the client stack and studies what kind of
scalability issues there are with MPTCP enabled LBs, VM migration with
MPTCP etc. My guess is that MPTCP will happen, it will be very useful
for smartphones to roam from one network to another.

Perhaps this approach is something that not belongs to IETF - perhaps
IRTF is the right forum or perhaps it do not belong here at all?

So my apologizes for interfering the WG

Patrick


On Mon, Jan 31, 2011 at 10:38 PM, Susan Hares <skh@ndzh.com> wrote:
> Patrick:
>
> Yes, I agree that Data Center problem is big= ger than just ARP/ND. However,
> to make progress on the ARP/ND portion we need to focus our work tight= ly.
>
> I agree that the problem needs the technologies of 100Gb Ethernet, IP/= OTN or
> WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or new= TCP
> or IPv6 options), session concepts and NM topologies to provide cross-layer
> optimization for data centers. I'm actually participating with IETF fo= lks in
> all these areas on protocols or NM.
>
> Networks/DC are focused on expanding the L2 (see the presentation belo= w:
> http://www.nanog.org/meetings/nanog51/prese= ntations/Monday/NANOG51.Talk45.na
> nog51-Schaumann.pdf)
>
> IETF WG do best by tackling one part of the total solution. We are sta= ying
> tightly focused on the ARP/ND problem, and proposing a very tight work= ing
> group. We are focused on collecting publishable ARP/ND statistics, get= ting
> specific requirements, creating models for discussion, and creating > prototype that the community can access.
>
> We have demonstrated at our BOF in Beijing that there are many solutions to
> the ARP/ND issues.
>
> Linda and I have talked to many people providing DC technology or VM > technology or DC services. However, the topic is so hot that people do= not
> want to publish their statistics due to competitive pressures. We are<= br> > investigating anonymous data from Research networks with similar DC > topologies.
>
> If you want to suggest a WG for session layer, I will definitely atten= d that
> group. I'm already tracking the rest of this work, plus the IEEE VLAN group.
>
>
> If you disagree with the tight focus, please send your comments to our= ADs
> (Ralph Droms and Jari Arkko).
>
> Sue
>
>
> -----Original Message-----
> From: armd-bounces@ietf.org= [mailto:armd-bounces@ietf.org] O= n Behalf Of
> Patrick Frejborg
> Sent: Monday, January 31, 2011 1:20 PM
> To: armd@ietf.org
> Subject: [armd] Data center issues
>
> Hi all,
>
> I'm new to the list and I just read through  the "Updated ARMD Charter and
> Milestones" thread.
>
> I do agree with Thomas Narten in his post on 27th of January, this is = a much
> bigger problem than only ARP. It is also about VLAN scalability, how m= any
> MAC-addresses needs to be supported in the L2 domain, spanning-tree issues,
> failure domain etc
>
> Much of these challenges can today be solved by implementing VPLS, tomorrow
> they can be solved by TRILL/SPB - but a L2 broadcast domain is also IM= HO a
> failure domain since a bridge floods all unknown
> packets out on all ports when a router only forward packets to known > destinations.
>
> Thus I think the root cause to have large L2 domains is the TCP/IP sta= ck
> itself - there is no session layer in the current stack. If the
> TCP/IP stack contained a session layer, by implementing a locator/iden= tifier
> split, then the application could be moved from one server to another<= br> > (physical or virtual, it doesn't matter) on the fly.
>
>
> Then we could design data center networks according to best practices,= i.e.
> implement routing whenever you can and the failure domains would be mu= ch
> smaller - also ARP, VLAN, MAC scalability issues are solved.
>
> And with a session layer in the TCP/IP stack , the customer could move= his
> applications from one cloud service provider to another cloud -
> over a routed network. The security nodes should not use IP addresses = to
> verify the users/servers, instead the decoupled identifier should
> be used to grant/deny access to a resource.
>
> Examples of  locator/identifier split architectures are Host Iden= tity
> Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based<= br> > Sockets (NBS).
>
> My 2 cents...
>
> Patrick
> _______________________________________________
> armd mailing list
> armd@ietf.org
> h= ttps://www.ietf.org/mailman/listinfo/armd
>
>
_______________________________________________
armd mailing list
armd@ietf.org
https://w= ww.ietf.org/mailman/listinfo/armd

 

_______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/m= ailman/listinfo/armd --B_3379492211_16459186-- From rdroms.ietf@gmail.com Wed Feb 2 14:30:23 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 4A9B53A6BA9 for ; Wed, 2 Feb 2011 14:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT-cAsk3J-y4 for ; Wed, 2 Feb 2011 14:30:21 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B5F7B3A6C72 for ; Wed, 2 Feb 2011 14:30:21 -0800 (PST) Received: by qyj19 with SMTP id 19so529644qyj.10 for ; Wed, 02 Feb 2011 14:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Bisx+YbvgXn3/0NnoVrrhb0ZpxZ4xO60+6VNVNg8yhM=; b=bpcqeNvJkmh17KzVa0PEz3ySOW4ZeCNLjqtBlvRzmSxHGl/y/HdKoSZT5ZjjhdEDx5 m7q/J5qQh9nju60Fh64klNXrbgXLFp+IQemcjZldt5b+GDUG8vop5Eb6NIi+frZNbf4q RT+wqco6Ho2dvZCI0RKdeBKgWcpuEMorYt5yg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=qeUhTDPrudLBeCZRjHGg7k450YSKyAJDnBVuD8cd+zIl9dMuBop9VkaTuuO/V3Fzo2 DuU+xP5Zg7gmkG3tPM/ynXUxpcxe2vjQCn55ec7o+Ls8bKGbAZXRAPOYEFlh8o49W64A QoFAziThpwoFqByb/RV+XGQmXdSmdRmqp/r2s= Received: by 10.224.89.74 with SMTP id d10mr8956030qam.335.1296686020813; Wed, 02 Feb 2011 14:33:40 -0800 (PST) Received: from bxb-rdroms-87113.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id w12sm87259qco.32.2011.02.02.14.33.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 14:33:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=GB2312 From: Ralph Droms In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6A7EB6C@DFWEML501-MBX.china.huawei.com> Date: Wed, 2 Feb 2011 17:33:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00b501cbbddc$a0f0c6e0$e2d254a0$@com> <4D411E0C.6010904@piuha.net> <4A95BA014132FF49AE685FAB4B9F17F6A7EB6C@DFWEML501-MBX.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1082) Cc: 'Hares Susan' , "armd@ietf.org" Subject: Re: [armd] Updated ARMD Charter and Milestones X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 22:30:23 -0000 Linda - can you point me at the latest rev of the draft charter? = Thanks. - Ralph On Jan 28, 2011, at 3:01 PM 1/28/11, Linda Dunbar wrote: > Jari,=20 >=20 > Thank you very much for the comments. I will update it and upload to = the website.=20 >=20 > Linda >=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Thursday, January 27, 2011 1:26 AM > To: Linda Dunbar > Cc: armd@ietf.org; rdroms.ietf@gmail.com; 'Hares Susan' > Subject: Re: Updated ARMD Charter and Milestones >=20 > Linda, >=20 > Thanks for suggesting text. I have a few comments on this. The main > comment is that I do not think we are ready to create a working group > that actually develops the solutions. I would like to see the = "document > the scaling characteristics" stage successfully completed first before > chartering any work on solutions. This is not to say that we can't do > the work -- even in the schedule you outline in the milestones -- but = at > least I personally have some trouble committing to the solution part > before I fully understand the current characteristics. >=20 > So from my perspective I'd remove the solution milestones and text > discussing that part of the work. I would also change the objectives = as > follows: >=20 > (1=A3=A9To document the scaling characteristics of ARP (IPv4) and ND = (IPv6) > with respect to increasing numbers of hosts in data centers, (2) to > identify limitations of ARP and ND in such environments, (3) provide > design recommendations intended to minimize issues associated with the > identified limitations, and (4) to develop appropriate solutions to > better support data centers with large number of hosts. >=20 > =3D> >=20 > =A3=A81=A3=A9To document the scaling characteristics of ARP (IPv4) and = ND (IPv6) > with respect to increasing numbers of hosts in data centers and (2) > provide operational recommendations intended to minimize issues > associated with the limits inherent in these characteristics. >=20 > (Just my $0.02, of course, not wearing any hats at the moment.) >=20 > Jari >=20 From linda.dunbar@huawei.com Thu Feb 3 08:14: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 44F303A6A10 for ; Thu, 3 Feb 2011 08:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=-2.124, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 ZfbxASmI6bJf for ; Thu, 3 Feb 2011 08:14:34 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 9F16C3A6A0C for ; Thu, 3 Feb 2011 08:14:34 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LG100EVNULWYV@usaga04-in.huawei.com> for armd@ietf.org; Thu, 03 Feb 2011 10:17:57 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LG100752ULVVQ@usaga04-in.huawei.com> for armd@ietf.org; Thu, 03 Feb 2011 10:17:56 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 03 Feb 2011 08:17:57 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 03 Feb 2011 08:17:53 -0800 Date: Thu, 03 Feb 2011 16:17:52 +0000 From: Linda Dunbar In-reply-to: X-Originating-IP: [10.47.152.107] To: Ralph Droms Message-id: <4A95BA014132FF49AE685FAB4B9F17F6A7FF25@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_P8nXbIqziq2wfwSZ0Y5mzA)" Content-language: en-US Accept-Language: en-US Thread-topic: Updated ARMD Charter and Milestones Thread-index: AQHLvfN09V9sVeruTHuMvBSC7SXc/5PmqWRggAizRwCAAKKocA== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AmgJ Cx5A DFl5 Gm8J HK92 RD77 SVyr UdTy aUf9 a2fN fQPN fbzp gKWz hncB jek5 pxVX; 4; YQByAG0AZABAAGkAZQB0AGYALgBvAHIAZwA7AGoAYQByAGkALgBhAHIAawBrAG8AQABwAGkAdQBoAGEALgBuAGUAdAA7AHIAZAByAG8AbQBzAC4AaQBlAHQAZgBAAGcAbQBhAGkAbAAuAGMAbwBtADsAcwBoAGEAcgBlAHMAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sosha1_v1; 7; {35A18243-BFB9-4BA2-B257-50300A5A74F6}; bABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 03 Feb 2011 16:17:50 GMT; UgBFADoAIABVAHAAZABhAHQAZQBkACAAQQBSAE0ARAAgAEMAaABhAHIAdABlAHIAIABhAG4AZAAgAE0AaQBsAGUAcwB0AG8AbgBlAHMA x-cr-puzzleid: {35A18243-BFB9-4BA2-B257-50300A5A74F6} References: <00b501cbbddc$a0f0c6e0$e2d254a0$@com> <4D411E0C.6010904@piuha.net> <4A95BA014132FF49AE685FAB4B9F17F6A7EB6C@DFWEML501-MBX.china.huawei.com> Cc: 'Hares Susan' , "armd@ietf.org" Subject: Re: [armd] Updated ARMD Charter and Milestones X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:14:36 -0000 --Boundary_(ID_P8nXbIqziq2wfwSZ0Y5mzA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgUmFscGgsDQoNCkkgcmV2aXNlIHRoZSBBUk1EIENoYXJ0ZXIgc3RhdGVtZW50IGJhc2VkIG9u IEphcmkncyBzdWdnZXN0aW9uLiBIZXJlIGl0IGlzLg0KDQpBUk1EOiBBZGRyZXNzIFJlc29sdXRp b24gZm9yIE1hc3NpdmUgbnVtYmVyIG9mIGhvc3RzIGluIERhdGEgQ2VudGVyDQoNCldvcmtpbmcg R3JvdXAgb2JqZWN0aXZlczogIKOoMaOpVG8gZG9jdW1lbnQgdGhlIHNjYWxpbmcgY2hhcmFjdGVy aXN0aWNzIG9mIEFSUCAoSVB2NCkgYW5kIE5EIChJUHY2KSB3aXRoIHJlc3BlY3QgdG8gaW5jcmVh c2luZyBudW1iZXJzIG9mIGhvc3RzIGluIGRhdGEgY2VudGVycyBhbmQgKDIpdG8gcHJvdmlkZSBv cGVyYXRpb25hbCByZWNvbW1lbmRhdGlvbnMgaW50ZW5kZWQgdG8gbWluaW1pemUgaXNzdWVzIGFz c29jaWF0ZWQgd2l0aCB0aGUgbGltaXRzIGluaGVyZW50IGluIHRoZXNlIGNoYXJhY3RlcmlzdGlj cy4NCiAuDQoNCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQpEYXRhIENlbnRlciBOZXR3 b3JrcyBtYXkgYmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBhIHZlcnkgbGFyZ2UgbnVtYmVyIG9mIGF0 dGFjaGVkIGhvc3RzLiAgVGhpcyBpcyBvZnRlbiB0aGUgY2FzZSBpbiB2aXJ0dWFsaXphdGlvbiBl bnZpcm9ubWVudHMgd2hlcmUgaG9zdHMgYXJlIGluc3RhbnRpYXRlZCBhcyBWaXJ0dWFsIE1hY2hp bmVzIChWTXMpLiAgSW4gc3VjaCBlbnZpcm9ubWVudHMsIG1hbnkgVk1zIG1heSBiZSBhc3NvY2lh dGVkIHdpdGggZWFjaCBwaHlzaWNhbCBzZXJ2ZXIuIEEgVk0gaXMgY29uZmlndXJlZCB3aXRoIG9u ZSBvciBtb3JlIHBvcnRzLCBlYWNoIG9mIHdoaWNoIGNvcnJlc3BvbmRzIHRvIGFuIElQIGhvc3Qg aW50ZXJmYWNlIHByb3ZpZGluZyBhdHRhY2htZW50IHRvIGEgZGlzdGluY3QgSVAgc3VibmV0IChl LmcuLCBJRUVFIDgwMi4xUSBWTEFOKS4NCg0KSW4gYSB2aXJ0dWFsaXplZCBkYXRhIGNlbnRlciwg YSBWTSBtYXkgYmUgcGxhY2VkIG9uIGFueSBwaHlzaWNhbCBzZXJ2ZXIuIEEgdmFyaWV0eSBvZiBh bGdvcml0aG1zIGNhbiBiZSBhcHBsaWVkIHRvIHNlbGVjdCB0aGUgbG9jYXRpb24gb2YgYSBWTS4g UmVzb3VyY2UgYXdhcmUgYWxnb3JpdGhtcyAoZS5nLiBlbmVyZ3ksIGJhbmR3aWR0aCwgZXRjLCkg d2lsbCB1c2UgYSBwbGFjZW1lbnQgdGhhdCBzYXRpc2ZpZXMgdGhlIHByb2Nlc3NpbmcgcmVxdWly ZW1lbnRzIG9mIGVhY2ggVk0gYnV0IHJlcXVpcmUgdGhlIG1pbmltYWwgbnVtYmVyIG9mIHBoeXNp Y2FsIHNlcnZlcnMgYW5kIHN3aXRjaGluZyBkZXZpY2VzLiAgRGF0YSBjZW50ZXIgYWRtaW5pc3Ry YXRvcnMgaGF2ZSBsb25nIGRlc2lyZWQgdGhlIGZsZXhpYmlsaXR5IG9mIGJlaW5nIGFibGUgdG8g cmVsb2NhdGUgaG9zdHMgZnJvbSBvdmVyIHV0aWxpemVkIHNlcnZlcnMgdG8gdW5kZXJ1dGlsaXpl ZCBzZXJ2ZXJzIHdpdGhvdXQgdGhlIHJlc3RyaWN0aW9uIG9mIHdoZXJlIHRoZXkgYXJlLg0KV2l0 aCB0aGlzLCBhbmQgc2ltaWxhciB0eXBlcyBvZiBhc3NpZ25tZW50IGFsZ29yaXRobSwgc3VibmV0 cyB0ZW5kIHRvIGV4dGVuZCB0aHJvdWdob3V0IHRoZSBuZXR3b3JrLiBUaGVuIEFSUC9ORCB0cmFm ZmljIGFzc29jaWF0ZWQgd2l0aCBlYWNoIHN1Ym5ldCBpcyBsaWtlbHkgdG8gdHJhdmVyc2UgYSBz aWduaWZpY2FudCBudW1iZXIgb2YgbGlua3MgYW5kIHN3aXRjaGVzIGluIHRoZSBuZXR3b3JrLiAg VGh1cywgaW4gdGhlIGNhc2Ugb2YgdGhlIHZpcnR1YWxpemVkIGRhdGEgY2VudGVyLCB0aGUgcGFy dGl0aW9uIG9mIHRoZSBwaHlzaWNhbCBuZXR3b3JrIGludG8gbXVsdGlwbGUgc3VibmV0d29ya3Mg bWF5IG5vdCBjb25maW5lIEFSUC9ORCB0byBhIGxpbWl0ZWQgbnVtYmVyIG9mIGxpbmtzL3N3aXRj aGVzIGFzIG1pZ2h0IG90aGVyd2lzZSBiZSBleHBlY3RlZC4NCkFub3RoZXIgc2lkZSBlZmZlY3Qg b2YgaG9zdHMgYmVsb25naW5nIHRvIG9uZSBzdWJuZXQgYmVpbmcgc3ByZWFkIGFjcm9zcyBtdWx0 aXBsZSBUT1Igc3dpdGNoZXMsIGlzIHRoYXQgdGhvc2UgVE9SIHN3aXRjaGVzoa8gZmlsdGVyaW5n IGRhdGEgYmFzZXMgKEZEQnMpIGFyZSBmcmVxdWVudGx5IHJlZnJlc2hlZCBieSBBUlAvTkQgYnJv YWRjYXN0L211bHRpY2FzdCBtZXNzYWdlcy4gTW9zdCBsaWtlbHksIHRoZSBmcmVxdWVuY3kgb2Yg QVJQL05EIGJ5IGhvc3RzIGlzIHNob3J0ZXIgdGhlbiBUT1Khr3MgRkRCIE1BQyBhZ2luZyB0aW1l LiBUaGF0IG1lYW5zIFRPUqGvcyBGREIgbmV2ZXIgYWdlIG91dCBhbnkgTUFDIGVudHJpZXMuIEZv ciBzd2l0Y2hlcyB3aG9zZSBGREIgY2FwYWNpdHkgaXMgbGVzcyB0aGFuIGFsbCB0aGUgaG9zdHMg YW1vbmcgYWxsIFZMQU5zIHVzaW5nIHRoYXQgc3dpdGNoLCBzb21lIE1BQyBlbnRyaWVzIHdpbGwg YmUgbG9zdCBkdWUgdG8gdGhlIEZEQiBiZWluZyBmdWxsIGluc3RlYWQgb2YgYmVpbmcgYWdlZCBv dXQuIFVuZGVyIHRob3NlIGNpcmN1bXN0YW5jZXMsIHBhY2tldHMgZm9yIHRob3NlIE1BQ3Mgd2ls bCBiZSBmbG9vZGVkIGFjcm9zcyB0aGUgZW50aXJlIG5ldHdvcmsuDQpUaGUgQVJNRCB3b3JrIHdv dWxkIHByb2NlZWQgaW4gcGhhc2VzLiAgVGhlIGluaXRpYWwgcGhhc2Ugd2lsbCBkb2N1bWVudCB0 aGUgc2NhbGluZyBjaGFyYWN0ZXJpc3RpY3Mgb2YgQVJQL05EIGluIHRoZSBkYXRhIGNlbnRlciBl bnZpcm9ubWVudCwgaWRlbnRpZnkgbGltaXRhdGlvbnMgaW1wbGllZCBieSB0aGUgc2NhbGluZyBj aGFyYWN0ZXJpc3RpY3MsIGFuZCBwcm92aWRlIHJlY29tbWVuZGF0aW9ucyB3aXRoIHJlc3BlY3Qg dG8gbmV0d29yayBkZXNpZ24gZm9yIG1pbmltaXppbmcgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCB0 aGUgaWRlbnRpZmllZCBsaW1pdGF0aW9ucy4gQSBsYXRlciBwaGFzZSB3b3VsZCBhZGRyZXNzIHBv dGVudGlhbCBzb2x1dGlvbnMgdG8gbWFrZSBBUlAvTkQgcHJvdG9jb2xzIHNjYWxlIGluIHN1Y2gg ZW52aXJvbm1lbnRzLg0KR29hbHMgYW5kIE1pbGVzdG9uZXM6DQoqICAgICAgIE1hcmNoIDIwMTE6 ICAgICBQcm9ibGVtIHN0YXRlbWVudA0KKiAgICAgICBNYXJjaCB+Tm92IDIwMTE6IEFSUC9ORCBz dGF0aXN0aWNzIGNvbGxlY3Rpb24gYW5kIGJlaGF2aW9yIGFuYWx5c2lzIGluIHZhcmlvdXMgRGF0 YSBDZW50ZXIgZW52aXJvbm1lbnRzLCBpbmNsdWRpbmcgYnV0IG5vdCBsaW1pdGVkIHRvOg0KbyAg ICAgICBNYW55IHN1Ym5ldHMgd2l0aCB2YXJpb3VzIHNpemVzDQpvICAgICAgIFN1Ym5ldHMgd2l0 aCBob3N0cyBvbiBWTXMgYW5kIFZNcyBtaWdyYXRlIG92ZXIgdGltZQ0KbyAgICAgICBTdWJuZXRz IHdpdGggc29tZSBob3N0cyBvbiBsb2NhbCBWTXMgYW5kIG90aGVycyBvbiBWTXMgaW4gdGhlIGNs b3VkIChsaWtlIEFtYXpvbqGvcyBFQzIpLg0KbyAgICAgICBMYXJnZSBzdWJuZXQNCg0KKiAgICAg ICBKdWx5IDIwMTEgfiBNYXJjaCAyMDEyOiBSZWNvbW1lbmRhdGlvbiBvbiBob3cgdG8gYXZvaWQg b3IgbWluaW1pemUgdGhlIGlzc3VlcyBjYXVzZWQgYnkgQVJQL05EDQoqICAgICAgIE5vdiAyMDEx OiBHYXAgQW5hbHlzaXMgU3RhdGVtZW50IHdpdGhpbiBEYXRhIENlbnRlcg0KbyAgICAgICBHYXBz IHdpdGhpbiBBUlANCm8gICAgICAgR2FwcyB3aXRoaW4gSVB2NiBORCBvciBhdXRvY29uZmlndXJh dGlvbg0KKiAgICAgICBOb3YgMjAxMTogU3VydmV5IG9mIEV4aXN0aW5nIFNvbHV0aW9ucw0KbyAg ICAgICBTdXJ2ZXkgb2YgTkhSUCAoUkZDMjMzMikgJiBTQ1NQIChSRkMyMzM0KSwgIGFuZCB0aGVp ciBhcHBsaWNhYmlsaXR5IHRvIEV0aGVybmV0IG5ldHdvcmtzOw0KbyAgICAgICBTdXJ2ZXkgb2Yg VFJJTEwgd29yayBhcyBhIHBvdGVudGlhbCBzb2x1dGlvbjsNCm8gICAgICAgU3VydmV5IG9mICBv dGhlciBwb3RlbnRpYWwgc29sdXRpb25zLCBsaWtlIE1PT1NFIG9yIFNFQVRUTEU7IGFuZA0KbyAg ICAgICBPdGhlciBwcm9wb3NhbHMNCiogICAgICAgTm92IDIwMTE6IFNlY3VyaXR5IEFuYWx5c2lz IG9mIEV4aXN0aW5nIFNvbHV0aW9ucw0KbyAgICAgICBTdHVkeSBleGlzdGluZyBzb2x1dGlvbnMs IGxpa2UgRHluYW1pYyBBUlAgSW5zcGVjdGlvbiwgRWdyZXNzIEFSUCBJbnNwZWN0aW9uLCBldGMs IGFuZCBldmFsdWF0ZSBpZiBhbnkgb2YgdGhlbSBvciBvdGhlcnMgc2hvdWxkIGJlIGluY2x1ZGVk IGluIHRoZSBzb2x1dGlvbnMgc3BlY2lmaWVkIGJ5IHRoaXMgd29ya2luZyBncm91cC4NCg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSYWxwaCBEcm9tcyBbbWFpbHRvOnJk cm9tcy5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDIsIDIwMTEg NDozNCBQTQ0KVG86IExpbmRhIER1bmJhcg0KQ2M6IFJhbHBoIERyb21zOyBKYXJpIEFya2tvOyBh cm1kQGlldGYub3JnOyAnSGFyZXMgU3VzYW4nDQpTdWJqZWN0OiBSZTogVXBkYXRlZCBBUk1EIENo YXJ0ZXIgYW5kIE1pbGVzdG9uZXMNCg0KTGluZGEgLSBjYW4geW91IHBvaW50IG1lIGF0IHRoZSBs YXRlc3QgcmV2IG9mIHRoZSBkcmFmdCBjaGFydGVyPyAgVGhhbmtzLg0KDQotIFJhbHBoDQoNCk9u IEphbiAyOCwgMjAxMSwgYXQgMzowMSBQTSAxLzI4LzExLCBMaW5kYSBEdW5iYXIgd3JvdGU6DQoN Cj4gSmFyaSwNCj4NCj4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGNvbW1lbnRzLiBJIHdp bGwgdXBkYXRlIGl0IGFuZCB1cGxvYWQgdG8gdGhlIHdlYnNpdGUuDQo+DQo+IExpbmRhDQo+DQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEphcmkgQXJra28gW21haWx0bzpq YXJpLmFya2tvQHBpdWhhLm5ldF0NCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjcsIDIwMTEg MToyNiBBTQ0KPiBUbzogTGluZGEgRHVuYmFyDQo+IENjOiBhcm1kQGlldGYub3JnOyByZHJvbXMu aWV0ZkBnbWFpbC5jb207ICdIYXJlcyBTdXNhbicNCj4gU3ViamVjdDogUmU6IFVwZGF0ZWQgQVJN RCBDaGFydGVyIGFuZCBNaWxlc3RvbmVzDQo+DQo+IExpbmRhLA0KPg0KPiBUaGFua3MgZm9yIHN1 Z2dlc3RpbmcgdGV4dC4gSSBoYXZlIGEgZmV3IGNvbW1lbnRzIG9uIHRoaXMuIFRoZSBtYWluDQo+ IGNvbW1lbnQgaXMgdGhhdCBJIGRvIG5vdCB0aGluayB3ZSBhcmUgcmVhZHkgdG8gY3JlYXRlIGEg d29ya2luZyBncm91cA0KPiB0aGF0IGFjdHVhbGx5IGRldmVsb3BzIHRoZSBzb2x1dGlvbnMuIEkg d291bGQgbGlrZSB0byBzZWUgdGhlICJkb2N1bWVudA0KPiB0aGUgc2NhbGluZyBjaGFyYWN0ZXJp c3RpY3MiIHN0YWdlIHN1Y2Nlc3NmdWxseSBjb21wbGV0ZWQgZmlyc3QgYmVmb3JlDQo+IGNoYXJ0 ZXJpbmcgYW55IHdvcmsgb24gc29sdXRpb25zLiBUaGlzIGlzIG5vdCB0byBzYXkgdGhhdCB3ZSBj YW4ndCBkbw0KPiB0aGUgd29yayAtLSBldmVuIGluIHRoZSBzY2hlZHVsZSB5b3Ugb3V0bGluZSBp biB0aGUgbWlsZXN0b25lcyAtLSBidXQgYXQNCj4gbGVhc3QgSSBwZXJzb25hbGx5IGhhdmUgc29t ZSB0cm91YmxlIGNvbW1pdHRpbmcgdG8gdGhlIHNvbHV0aW9uIHBhcnQNCj4gYmVmb3JlIEkgZnVs bHkgdW5kZXJzdGFuZCB0aGUgY3VycmVudCBjaGFyYWN0ZXJpc3RpY3MuDQo+DQo+IFNvIGZyb20g bXkgcGVyc3BlY3RpdmUgSSdkIHJlbW92ZSB0aGUgc29sdXRpb24gbWlsZXN0b25lcyBhbmQgdGV4 dA0KPiBkaXNjdXNzaW5nIHRoYXQgcGFydCBvZiB0aGUgd29yay4gSSB3b3VsZCBhbHNvIGNoYW5n ZSB0aGUgb2JqZWN0aXZlcyBhcw0KPiBmb2xsb3dzOg0KPg0KPiAoMaOpVG8gZG9jdW1lbnQgdGhl IHNjYWxpbmcgY2hhcmFjdGVyaXN0aWNzIG9mIEFSUCAoSVB2NCkgYW5kIE5EIChJUHY2KQ0KPiB3 aXRoIHJlc3BlY3QgdG8gaW5jcmVhc2luZyBudW1iZXJzIG9mIGhvc3RzIGluIGRhdGEgY2VudGVy cywgKDIpIHRvDQo+IGlkZW50aWZ5IGxpbWl0YXRpb25zIG9mIEFSUCBhbmQgTkQgaW4gc3VjaCBl bnZpcm9ubWVudHMsICgzKSBwcm92aWRlDQo+IGRlc2lnbiByZWNvbW1lbmRhdGlvbnMgaW50ZW5k ZWQgdG8gbWluaW1pemUgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUNCj4gaWRlbnRpZmllZCBs aW1pdGF0aW9ucywgYW5kICg0KSB0byBkZXZlbG9wIGFwcHJvcHJpYXRlIHNvbHV0aW9ucyB0bw0K PiBiZXR0ZXIgc3VwcG9ydCBkYXRhIGNlbnRlcnMgd2l0aCBsYXJnZSBudW1iZXIgb2YgaG9zdHMu DQo+DQo+ID0+DQo+DQo+IKOoMaOpVG8gZG9jdW1lbnQgdGhlIHNjYWxpbmcgY2hhcmFjdGVyaXN0 aWNzIG9mIEFSUCAoSVB2NCkgYW5kIE5EIChJUHY2KQ0KPiB3aXRoIHJlc3BlY3QgdG8gaW5jcmVh c2luZyBudW1iZXJzIG9mIGhvc3RzIGluIGRhdGEgY2VudGVycyBhbmQgKDIpDQo+IHByb3ZpZGUg b3BlcmF0aW9uYWwgcmVjb21tZW5kYXRpb25zIGludGVuZGVkIHRvIG1pbmltaXplIGlzc3Vlcw0K PiBhc3NvY2lhdGVkIHdpdGggdGhlIGxpbWl0cyBpbmhlcmVudCBpbiB0aGVzZSBjaGFyYWN0ZXJp c3RpY3MuDQo+DQo+IChKdXN0IG15ICQwLjAyLCBvZiBjb3Vyc2UsIG5vdCB3ZWFyaW5nIGFueSBo YXRzIGF0IHRoZSBtb21lbnQuKQ0KPg0KPiBKYXJpDQo+DQoNCg0K --Boundary_(ID_P8nXbIqziq2wfwSZ0Y5mzA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi Ralph,
 
I revise the ARMD Charter statement based on Jari's suggestion. Here i= t is.
 
ARMD: Address Resolut= ion for Massive number of hosts in Data Center
 
= Working Group objectives:  =A3=A81=A3=A9To document the scali= ng characteristics of ARP (IPv4) and ND (IPv6) with respect to increasing n= umbers of hosts in data centers and (2)to provide operational recommendations inte= nded to minimize issues associated with the limits inherent in these charac= teristics.
.
 
Description of Working= Group:
Data Center Networks may = be required to support a very large number of attached hosts.  This is= often the case in virtualization environments where hosts are instantiated= as Virtual Machines (VMs). In such environments, many VMs may be associated with each physical server. A VM is configured wi= th one or more ports, each of which corresponds to an IP host interface pro= viding attachment to a distinct IP subnet (e.g., IEEE 802.1Q VLAN).
In a virtualized data center, a VM may be placed on any physical se= rver. A variety of algorithms can be applied to select the location of a VM= . Resource aware algorithms (e.g. energy, bandwidth, etc,) will use a placement that satisfies the processing require= ments of each VM but require the minimal number of physical servers and swi= tching devices.  Data center administrators have long desired the flex= ibility of being able to relocate hosts from over utilized servers to underutilized servers without the restriction= of where they are.
With this, and similar types of assignment algorithm, subnets tend = to extend throughout the network. Then ARP/ND traffic associated with each = subnet is likely to traverse a significant number of links and switches in the network.  Thus, in the case of the= virtualized data center, the partition of the physical network into multip= le subnetworks may not confine ARP/ND to a limited number of links/switches= as might otherwise be expected.
Another side effect of hosts belonging to one subnet being spread a= cross multiple TOR switches, is that those TOR switches=A1=AF filtering dat= a bases (FDBs) are frequently refreshed by ARP/ND broadcast/multicast messages. Most likely, the frequency of ARP/ND b= y hosts is shorter then TOR=A1=AFs FDB MAC aging time. That means TOR=A1=AF= s FDB never age out any MAC entries. For switches whose FDB capacity is les= s than all the hosts among all VLANs using that switch, some MAC entries will be lost due to the FDB being full instea= d of being aged out. Under those circumstances, packets for those MACs will= be flooded across the entire network.
The ARMD work would proceed in phases.  The initial phase will= document the scaling characteristics of ARP/ND in the data center environm= ent, identify limitations implied by the scaling characteristics, and provide recommendations with respect to networ= k design for minimizing issues associated with the identified limitations. = A later phase would address potential solutions to make ARP/ND protocols sc= ale in such environments.
Goals and Milestones:<= /b>
  • March 2011:      Problem statement
  • Mar= ch ~Nov 2011: ARP/ND statistics collection and behavior analysis in various= Data Center environments, including but not limited to:
  • Many subnets with various sizes
  • Subnets with hosts on VMs and V= Ms migrate over time
  • Subnets with some hosts on local VMs and other= s on VMs in the cloud (like Amazon=A1=AFs EC2). 
  • Large subnet=
 
  • July 2011 ~ March 2012: Recommendation on how to avoid or minimize the = issues caused by ARP/ND
  • Nov 2011: Gap Analysis Statement within Dat= a Center
  • Gaps within ARP
  • Gaps within IPv6 ND or autoconfiguration
    • Nov 2011: Survey of Existing Solutions
    • Survey of NHRP (RFC2332) & SCSP (RFC2334),  and their applicab= ility to Ethernet networks;
    • Survey of TRILL work as a potential sol= ution;
    • Survey of  other potential solutions, like MOOSE or SE= ATTLE; and
    • Other proposals
    • Nov 2011: Security Analysis of Existing Solutions
    • Study existing solutions, like Dynamic ARP Inspection, Egress ARP Inspe= ction, etc, and evaluate if any of them or others should be included in the= solutions specified by this working group.  
     
     
     
    -----Original Message-----
    From: Ralph Droms [mailto:rdroms.i= etf@gmail.com]
    Sent: Wednesday, February 02, 2011 4:34 PM
    To: Linda Dunbar
    Cc: Ralph Droms; Jari Arkko; armd@ietf.org; 'Hares Susan'
    Subject: Re: Updated ARMD Charter and Milestones
     
    Linda - can you point me at the latest rev of the draft charter? = Thanks.
     
    - Ralph
     
    On Jan 28, 2011, at 3:01 PM 1/28/11, Linda Dunbar wrote:
     
    > Jari,
    >
    > Thank you very much for the comments. I will update it and upload= to the website.
    >
    > Linda
    >
    > -----Original Message-----
    > From: Jari Arkko [mailto:= jari.arkko@piuha.net]
    > Sent: Thursday, January 27, 2011 1:26 AM
    > To: Linda Dunbar
    > Cc: armd@ietf.org; rdroms.ietf@gmail.com; 'Hares Susan'
    > Subject: Re: Updated ARMD Charter and Milestones
    >
    > Linda,
    >
    > Thanks for suggesting text. I have a few comments on this. The ma= in
    > comment is that I do not think we are ready to create a working g= roup
    > that actually develops the solutions. I would like to see the &qu= ot;document
    > the scaling characteristics" stage successfully completed fi= rst before
    > chartering any work on solutions. This is not to say that we can'= t do
    > the work -- even in the schedule you outline in the milestones --= but at
    > least I personally have some trouble committing to the solution p= art
    > before I fully understand the current characteristics.
    >
    > So from my perspective I'd remove the solution milestones and tex= t
    > discussing that part of the work. I would also change the objecti= ves as
    > follows:
    >
    > (1=A3=A9To document the scalin= g characteristics of ARP (IPv4) and ND (IPv6)
    > with respect to increasing numbers of hosts in data centers, (2) = to
    > identify limitations of ARP and ND in such environments, (3) prov= ide
    > design recommendations intended to minimize issues associated wit= h the
    > identified limitations, and (4) to develop appropriate solutions = to
    > better support data centers with large number of hosts.
    >
    > =3D>
    >
    > =A3=A81=A3=A9To document the scaling characteristics of ARP (IPv4) and= ND (IPv6)
    > with respect to increasing numbers of hosts in data centers and (= 2)
    > provide operational recommendations intended to minimize issues
    > associated with the limits inherent in these characteristics.
    >
    > (Just my $0.02, of course, not wearing any hats at the moment.)
    >
    > Jari
    >
     
     
     --Boundary_(ID_P8nXbIqziq2wfwSZ0Y5mzA)-- From vishwas.ietf@gmail.com Thu Feb 3 09:38:21 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 5E55D3A6A56 for ; Thu, 3 Feb 2011 09:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 iGlxyut-kEvg for ; Thu, 3 Feb 2011 09:38:20 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8E1793A6A51 for ; Thu, 3 Feb 2011 09:38:19 -0800 (PST) Received: by wwa36 with SMTP id 36so1472216wwa.13 for ; Thu, 03 Feb 2011 09:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=61Xoxd+GEpRK5QeqHt2/RN8l94sO8DNV3jM/3JTNZH0=; b=g1AAyBiqCjStXTXjkEUMigYg76teY6AKn/TaEr1/tE9KNJic9LTkKEABmo7BmGDA/d 74yZhhANivbxSRiu/WOMd5fevbjvSXDacmJHlAhRK4Gpqd02cmx+dBPK+2j3aUHNRVb1 jcP49B5NpkSEP6Ht7Y4sCgpI0xxOkaX81xYGw= 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:content-transfer-encoding; b=ZC6WJpbOLnOX1LG9tEC7XFUIXe8y7uTdQ4/P6RgWrDozNxcxf1Jk9fBcF9W17voi4s iBHhF+58vv/Y9liwCU5HYwErNovpaHpKDxR/xLXj/lPxrbh3muVqrbeQdAqR/TRx/IR+ /OGJUVYxPwJyn5rF0BvSYqkb25lC2TSuTiKZo= MIME-Version: 1.0 Received: by 10.216.19.207 with SMTP id n57mr11352342wen.30.1296754901252; Thu, 03 Feb 2011 09:41:41 -0800 (PST) Received: by 10.216.151.100 with HTTP; Thu, 3 Feb 2011 09:41:40 -0800 (PST) In-Reply-To: References: <006501cbc186$c6bee9d0$543cbd70$@com> <14584D6EE26B314187A4F68BA2060600067702E5@ASHEVS008.mcilink.com> Date: Thu, 3 Feb 2011 09:41:40 -0800 Message-ID: From: Vishwas Manral To: Patrick Frejborg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ralph Droms , armd@ietf.org, Susan Hares Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:38:21 -0000 Hi Patrik, Though I agree to the argument that the main reason to use a flat Layer-2 network is because of the applications. I do not the link you have provided talks about the Layer-2 versus Layer-3 model. It seems to talk about the fact that hosting applications in Public cloud is better then in your own cloud. Thanks, Vishwas On Wed, Feb 2, 2011 at 4:42 AM, Patrick Frejborg wrot= e: > Hi Benson and Ning, > > some thoughts on your responses: > > First, it is very true that there isn't a size that fits all - but > that is currently the case we have today. We have to =A0implement L2 > solution regardless if it is small, mid-size, large, extra-large or > extra-extra large data center. > And the reason is due to current enterprise applications and tools - > it is the only way if you can't change the application (which you > can't). My point here is that the networking people are forced to > implement L2, not because that we like to have very large L2 network > around, but we do not have any other option due to the applications an > enterprise is using. > > The very large content providers, such as Yahoo and Google, seems to > have realized that large L2 networks means operational challenges - > that's my conclusion from the Yahoo presentation and Google's debate > with VMware =A0around cloud > http://www.infoworld.com/d/cloud-computing/google-vmware-argue-over-priva= te-clouds-198 > It seems that in order to achieve better scalability, =A0they are > applying changes at applications to be used over L3 networks - but I > could be wrong. > > About multi-tenancy solutions, it is very common that MPLS gets > involved to solve both L2 and L3 scaling issues - and actually the L2 > MPLS based solutions are way more complex to implement and operate > than a MPLS L3 solution. > > The most important design criteria to keep in mind in order to scale > L2 domains are "logical ports"and "virtual ports", if those numbers > are exceeded then the network admin is sailing on deep and dark > waters. AFAIK, there is only one vendor providing these kinds of > parameters - it would be nice if every switch vendor came up with > similar guidelines because with these parameters you can determine > your L2 topology and when to move towards VPLS/TRILL/SPB. > > But whatever L2 technology used it will not remove the fact that a L2 > domain is also a failure domain - would like to have some hands on > TRILL to see how well TTL header dampens loops though. If there is > loop in the L2 domain then the domain is lost. So it is a business > question, do you put all your eggs in one basket or several baskets?? > > If you prefer to have several baskets then the operational expenditure > and issues between the isolated L2 domains becomes =A0much higher - here > a common L3 domain, and if the applications support L3 endpoint > mobility, would be easier and less expensive to operate. There is a > tipping point when it makes sense to switch over to a L3 based DC > network, if the applications just would allow us to do it.....so > application architects, can we soon have applications that better > support endpoint mobility, please.... > > Patrick > > On Tue, Feb 1, 2011 at 11:40 PM, Benson Schliesser > wrote: >> I agree with Ning. One of the basic issues that advocates of all-L3 data= center networks typically overlook (i.e. because it doesn't apply to them),= is multi-tenancy. =A0It can be done with L3-centric designs, of course - w= ith MPLS, tunnel overlays, etc - but it's more complex and costly. =A0There= is a reason datacenter networks have been predominantly L2. >> >> Cheers, >> -Benson >> >> >> >> On Feb 1, 2011, at 9:38 AM, So, Ning wrote: >> >>> All, >>> >>> I just want to point out that L3 solution may work for some DC design s= uch as YAHOO, but it is not a universal case. =A0For example, TOS/COS/QoS a= re widely deployed in many service providers' networks, and highly valued b= y Enterprise/Government customers (and their applications). =A0Scaling L3 n= etwork may not be any easier than L2 in that operational condition. =A0I do= see the needs to keep the options open becasue one size fits all may not w= ork. >>> >>> > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > From pfrejborg@gmail.com Fri Feb 4 00:20:39 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 E0AC13A6AF3 for ; Fri, 4 Feb 2011 00:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WohEiNNmMSZ for ; Fri, 4 Feb 2011 00:20:39 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id A6A0D3A6AE0 for ; Fri, 4 Feb 2011 00:20:38 -0800 (PST) Received: by eyd10 with SMTP id 10so1221022eyd.31 for ; Fri, 04 Feb 2011 00:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hijETQsyKBN//8LRZl3995NjDNYYjYuj4cOtt50HGdM=; b=epQR3DXer53wiLhGk4XP88QCvkzUwio6WuFg0iEcTkALjMMvdNCHI8EnX4RQ6LJ3Rx tB+xxGe+fZbxh/4qdHAlvALb3SpSG0aKhZpqTFWl1oa97F9Z+zYONN9s1BV4nix1IVgD dNRefx4nh1mh3Vf5/nj1XraPfNI342anzJvys= 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=Pi86R9eqwt60pEND7a1H2/piWBXL4KgzSn/cgkDUGbUNYzH8FMXQYj9yPz0yTki2wb MGa0S0OeAE+zQReJBcUnAYukV7Wt02yAhHfLNzo0cJJksBAzZkW/4ARRQADteOU3vEol lzUv8NulweBqQDlu9YTftZ2G1mg91PsF94mYA= MIME-Version: 1.0 Received: by 10.213.4.135 with SMTP id 7mr4571799ebr.52.1296807842195; Fri, 04 Feb 2011 00:24:02 -0800 (PST) Received: by 10.213.106.6 with HTTP; Fri, 4 Feb 2011 00:24:02 -0800 (PST) In-Reply-To: References: <006501cbc186$c6bee9d0$543cbd70$@com> <14584D6EE26B314187A4F68BA2060600067702E5@ASHEVS008.mcilink.com> Date: Fri, 4 Feb 2011 10:24:02 +0200 Message-ID: From: Patrick Frejborg To: Vishwas Manral Content-Type: text/plain; charset=ISO-8859-1 Cc: Ralph Droms , armd@ietf.org, Susan Hares Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 08:20:40 -0000 Hi Vishwas, yes - I might conclude too much on the article, this statement: "In the virtualization approach of private datacenters, a company takes a server and subdivides it into many servers to increase efficiency," Sheth writes. "We do the opposite by taking a large set of low-cost commodity systems and tying them together into one large supercomputer.... Enterprise hardware components are designed to be very reliable, but they can never be 100 percent reliable, so enterprises spend a lot of time and money on maintenance. In contrast, we expect the hardware to fail, and design for reliability in the software such that, when the hardware does fail, customers are just shifted to another server." It is unclear if the software is acting upon L2 or L3 - but they have made some changes on the application(?) and not trying to build a state of the art HA infrastructure - when making changes on applications I would aim for L3 mobility. However, I have no facts how they do it..... Patrick On Thu, Feb 3, 2011 at 7:41 PM, Vishwas Manral wrote: > Hi Patrik, > > Though I agree to the argument that the main reason to use a flat > Layer-2 network is because of the applications. I do not the link you > have provided talks about the Layer-2 versus Layer-3 model. It seems > to talk about the fact that hosting applications in Public cloud is > better then in your own cloud. > From zengqing@huawei.com Tue Feb 8 18:23:08 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5023E3A6841 for ; Tue, 8 Feb 2011 18:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.324 X-Spam-Level: X-Spam-Status: No, score=0.324 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, TVD_SPACE_RATIO=2.219] 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 MMTpm7i0qhKh for ; Tue, 8 Feb 2011 18:23:07 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 873383A682F for ; Tue, 8 Feb 2011 18:23:07 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGB00F6IVYHR2@szxga03-in.huawei.com> for armd@ietf.org; Wed, 09 Feb 2011 10:23:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGB0046WVYH5R@szxga03-in.huawei.com> for armd@ietf.org; Wed, 09 Feb 2011 10:23:05 +0800 (CST) Received: from z00129659 ([10.110.98.98]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGB004O4VYGMM@szxml06-in.huawei.com> for armd@ietf.org; Wed, 09 Feb 2011 10:23:05 +0800 (CST) Date: Wed, 09 Feb 2011 10:23:04 +0800 From: zengqing To: armd@ietf.org Message-id: <007601cbc800$48b110b0$da133210$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcvH/yudtWSH8cAdRqebVL+CLxl04Q== X-Mailman-Approved-At: Wed, 09 Feb 2011 05:37:14 -0800 Subject: [armd] Subscribe 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, 09 Feb 2011 02:23:08 -0000 Subscribe From skh@ndzh.com Wed Feb 16 06:36: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 D6DEE3A6D44 for ; Wed, 16 Feb 2011 06:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_53=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz9CNGbyVGnj for ; Wed, 16 Feb 2011 06:36:44 -0800 (PST) Received: from hickoryhill-consulting.com (63-208-161-199.digitalrealm.net [63.208.161.199]) by core3.amsl.com (Postfix) with ESMTP id 5C5D63A6D1B for ; Wed, 16 Feb 2011 06:36:44 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=75.208.33.23; Received: from SKHPERSONALLT (unverified [75.208.33.23]) by hickoryhill-consulting.com (SurgeMail 4.2d4) with ESMTP id 2068735-1945496 for multiple; Wed, 16 Feb 2011 09:37:07 -0500 From: "Susan Hares" To: "'Patrick Frejborg'" , "'Benson Schliesser'" , References: <006501cbc186$c6bee9d0$543cbd70$@com> <14584D6EE26B314187A4F68BA2060600067702E5@ASHEVS008.mcilink.com> In-Reply-To: Date: Wed, 16 Feb 2011 09:37:06 -0500 Message-ID: <008201cbcde6$fd1ba290$f752e7b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvC1qSRgMt0CUmGRwScnCAFFN/G0wLD8fWw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'Ralph Droms' , armd@ietf.org Subject: Re: [armd] Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 14:36:46 -0000 Patrick: I was re-reading some of my ARMD mail this morning, and I wanted to also acknowledge that a a part of the solution can be changes to applications = for DC. I think the DC platforms (Amazon, Yahoo, Google, Microsoft, etc) = show people are moving to this.=20 I also agree that a whole suite of solutions is necessary for the = community right now.=20 Sue=20 -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Patrick Frejborg Sent: Wednesday, February 02, 2011 7:42 AM To: Benson Schliesser; ning.so@verizonbusiness.com Cc: Ralph Droms; Susan Hares; armd@ietf.org Subject: Re: [armd] Data center issues Hi Benson and Ning, some thoughts on your responses: First, it is very true that there isn't a size that fits all - but that is currently the case we have today. We have to implement L2 solution regardless if it is small, mid-size, large, extra-large or extra-extra large data center. And the reason is due to current enterprise applications and tools - it is the only way if you can't change the application (which you can't). My point here is that the networking people are forced to implement L2, not because that we like to have very large L2 network around, but we do not have any other option due to the applications an enterprise is using. The very large content providers, such as Yahoo and Google, seems to have realized that large L2 networks means operational challenges - that's my conclusion from the Yahoo presentation and Google's debate with VMware around cloud http://www.infoworld.com/d/cloud-computing/google-vmware-argue-over-priva= te- clouds-198 It seems that in order to achieve better scalability, they are applying changes at applications to be used over L3 networks - but I could be wrong. About multi-tenancy solutions, it is very common that MPLS gets involved to solve both L2 and L3 scaling issues - and actually the L2 MPLS based solutions are way more complex to implement and operate than a MPLS L3 solution. The most important design criteria to keep in mind in order to scale L2 domains are "logical ports"and "virtual ports", if those numbers are exceeded then the network admin is sailing on deep and dark waters. AFAIK, there is only one vendor providing these kinds of parameters - it would be nice if every switch vendor came up with similar guidelines because with these parameters you can determine your L2 topology and when to move towards VPLS/TRILL/SPB. But whatever L2 technology used it will not remove the fact that a L2 domain is also a failure domain - would like to have some hands on TRILL to see how well TTL header dampens loops though. If there is loop in the L2 domain then the domain is lost. So it is a business question, do you put all your eggs in one basket or several baskets?? If you prefer to have several baskets then the operational expenditure and issues between the isolated L2 domains becomes much higher - here a common L3 domain, and if the applications support L3 endpoint mobility, would be easier and less expensive to operate. There is a tipping point when it makes sense to switch over to a L3 based DC network, if the applications just would allow us to do it.....so application architects, can we soon have applications that better support endpoint mobility, please.... Patrick On Tue, Feb 1, 2011 at 11:40 PM, Benson Schliesser wrote: > I agree with Ning. One of the basic issues that advocates of all-L3 datacenter networks typically overlook (i.e. because it doesn't apply to them), is multi-tenancy. =A0It can be done with L3-centric designs, of = course - with MPLS, tunnel overlays, etc - but it's more complex and costly. = =A0There is a reason datacenter networks have been predominantly L2. > > Cheers, > -Benson > > > > On Feb 1, 2011, at 9:38 AM, So, Ning wrote: > >> All, >> >> I just want to point out that L3 solution may work for some DC design such as YAHOO, but it is not a universal case. =A0For example, = TOS/COS/QoS are widely deployed in many service providers' networks, and highly valued = by Enterprise/Government customers (and their applications). =A0Scaling L3 network may not be any easier than L2 in that operational condition. = =A0I do see the needs to keep the options open becasue one size fits all may not work. >> >> _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From skh@ndzh.com Thu Feb 17 14:11:12 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16443A6ECC for ; Thu, 17 Feb 2011 14:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.668 X-Spam-Level: * X-Spam-Status: No, score=1.668 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_CSBIG=1.65] 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 KyhG9jtEPh62 for ; Thu, 17 Feb 2011 14:11:10 -0800 (PST) Received: from hickoryhill-consulting.com (63-208-161-199.digitalrealm.net [63.208.161.199]) by core3.amsl.com (Postfix) with ESMTP id 6AC3C3A6E7D for ; Thu, 17 Feb 2011 14:11:08 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=69.99.160.43; Received: from SKHPERSONALLT (unverified [69.99.160.43]) by hickoryhill-consulting.com (SurgeMail 4.2d4) with ESMTP id 2074720-1945496 for multiple; Thu, 17 Feb 2011 17:11:25 -0500 From: "Susan Hares" To: "'Lars Eggert'" , "'Patrick Frejborg'" , "'Costin Raiciu'" References: <006501cbc186$c6bee9d0$543cbd70$@com> In-Reply-To: Date: Thu, 17 Feb 2011 17:11:27 -0500 Message-ID: <003001cbceef$a0e21db0$e2a65910$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvC2w175ad0NoUhTFOpxoQVeSDZZAME7YXQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'Ralph Droms' , armd@ietf.org Subject: Re: [armd] Spam:******, Re: Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 22:11:12 -0000 Lars, Patrick and Costin: I'd like to dig into the ARMD in preparation for IETF 80. Can you send any additional pointers on your work? Many thanks, Sue Hares -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Wednesday, February 02, 2011 8:14 AM To: Patrick Frejborg; Costin Raiciu Cc: Ralph Droms; Susan Hares; armd@ietf.org Subject: Spam:******, Re: [armd] Data center issues Patrick, Costin (CC'ed) and others have recently played quite a bit with MPTCP in datacenters and I have heard there are huge gains. On 2011-2-1, at 17:23, Patrick Frejborg wrote: > MPTCP is evolving and that itself provides a session layer for the > application. If we apply theoretically MPTCP on the Yahoo > architecture, then the first subflow is connected to the load balancer > (LB) - user is identified, MPTCP token exchanged and the IP address > (to setup a second subflow to the real server) is exchanged with the > client. The LB is sending the token via a trusted backdoor to the real > server so the client and real server can establish a new subflow for > the application - after that the client uses the application without > traversing the LB anymore. From pfrejborg@gmail.com Fri Feb 18 10:46:11 2011 Return-Path: X-Original-To: armd@core3.amsl.com Delivered-To: armd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FFE3A6FA9 for ; Fri, 18 Feb 2011 10:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_CSBIG=1.65] 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 Mp3Fk6pvb4-3 for ; Fri, 18 Feb 2011 10:46:10 -0800 (PST) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by core3.amsl.com (Postfix) with ESMTP id 7509F3A6EC0 for ; Fri, 18 Feb 2011 10:46:10 -0800 (PST) Received: by eyf6 with SMTP id 6so2481890eyf.27 for ; Fri, 18 Feb 2011 10:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6+34usRg3sV3JXW88WrS+lnOcDHvad0G2hYd90kHU9o=; b=lOKf8G2ZQMdZJfHjpBRHWf5j3lauNYqD1XCI4itbLNBvx4HtLtKraYz3pFEK4eKeH3 iFetO2VllCEbOtfNJB9bZzQ+BZyyyb1+2fIJkBNrHx7YqKfF1MJKCkNfWTbd/Tzg4Y/H H4h9sCord1lqryRmdPN4MZR0HvvujOXrCA9Xs= 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:content-transfer-encoding; b=XMj+lVPJFsvj/JkQhaW9mtxI5t+aDtF8oicV24jqsG5HkL2kwRfMZDNWWjHWesWK4x MzbePese53GSE6MmywO/NeG59S1f/EVOGzNx86Qxkwy1NAuOqHDr/9njX2bo7+W731sX 8JhIKu8F+/aFnZil0vrNUcFHE5mc57Km+zX1Y= MIME-Version: 1.0 Received: by 10.213.32.137 with SMTP id c9mr1372183ebd.7.1298054802371; Fri, 18 Feb 2011 10:46:42 -0800 (PST) Received: by 10.213.105.195 with HTTP; Fri, 18 Feb 2011 10:46:42 -0800 (PST) In-Reply-To: <003001cbceef$a0e21db0$e2a65910$@com> References: <006501cbc186$c6bee9d0$543cbd70$@com> <003001cbceef$a0e21db0$e2a65910$@com> Date: Fri, 18 Feb 2011 20:46:42 +0200 Message-ID: From: Patrick Frejborg To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ralph Droms , armd@ietf.org, Costin Raiciu Subject: Re: [armd] Spam:******, Re: Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:46:11 -0000 Hi Susan, my work is not really suitable for ARMD since it is produced within IRTF/RRG and considered controversial http://tools.ietf.org/html/draft-frejborg-hipv4-12 I'm currently looking into combine it with MPTCP and VL2, a use case study for data centers You might find the VL2 paper interesting and suitable for ARMD, "VL2: A Scalable and Flexible Data Center Network" Patrick On Fri, Feb 18, 2011 at 12:11 AM, Susan Hares wrote: > Lars, Patrick and Costin: > > I'd like to dig into the ARMD in preparation for IETF 80. =A0Can you send= any > additional pointers on your work? > > Many thanks, > Sue Hares > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of L= ars > Eggert > Sent: Wednesday, February 02, 2011 8:14 AM > To: Patrick Frejborg; Costin Raiciu > Cc: Ralph Droms; Susan Hares; armd@ietf.org > Subject: Spam:******, Re: [armd] Data center issues > > Patrick, Costin (CC'ed) and others have recently played quite a bit with > MPTCP in datacenters and I have heard there are huge gains. > > On 2011-2-1, at 17:23, Patrick Frejborg wrote: > >> MPTCP is evolving and that itself provides a session layer for the >> application. If we apply theoretically MPTCP on the Yahoo >> architecture, then the first subflow is connected to the load balancer >> (LB) - user is identified, MPTCP token exchanged and the IP address >> (to setup a second subflow to the real server) is exchanged with the >> client. The LB is sending the token via a trusted backdoor to the real >> server so the client and real server can establish a new subflow for >> the application - after that the client =A0uses the application without >> traversing the LB anymore. > > > From dmm@1-4-5.net Fri Feb 18 12:35:46 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 9EA673A6F9B for ; Fri, 18 Feb 2011 12:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_CSBIG=1.65] 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 we06rrTTRABn for ; Fri, 18 Feb 2011 12:35:45 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 474D73A6E4D for ; Fri, 18 Feb 2011 12:35:45 -0800 (PST) Received: by vws7 with SMTP id 7so2424692vws.31 for ; Fri, 18 Feb 2011 12:36:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.164.168 with SMTP id yr8mr2139931vdb.166.1298061379376; Fri, 18 Feb 2011 12:36:19 -0800 (PST) Received: by 10.220.5.129 with HTTP; Fri, 18 Feb 2011 12:36:19 -0800 (PST) X-Originating-IP: [128.223.156.117] In-Reply-To: References: <006501cbc186$c6bee9d0$543cbd70$@com> <003001cbceef$a0e21db0$e2a65910$@com> Date: Fri, 18 Feb 2011 12:36:19 -0800 Message-ID: From: David Meyer To: Patrick Frejborg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ralph Droms , Costin Raiciu , Susan Hares , armd@ietf.org Subject: Re: [armd] Spam:******, Re: Data center issues X-BeenThere: armd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 20:35:46 -0000 FWIW there is quite an active research community in this area. I've put up = a few related things on http://www.1-4-5.net/~dmm/DC for other purposes but folks might find some of it interesting... Dave On Fri, Feb 18, 2011 at 10:46 AM, Patrick Frejborg wr= ote: > Hi Susan, > > my work is not really suitable for ARMD since it is produced within > IRTF/RRG and considered controversial > http://tools.ietf.org/html/draft-frejborg-hipv4-12 > I'm currently looking into combine it with MPTCP and VL2, a use case > study for data centers > > You might find the VL2 paper interesting and suitable for ARMD, "VL2: > A Scalable and Flexible Data Center Network" > > Patrick > > On Fri, Feb 18, 2011 at 12:11 AM, Susan Hares wrote: >> Lars, Patrick and Costin: >> >> I'd like to dig into the ARMD in preparation for IETF 80. =A0Can you sen= d any >> additional pointers on your work? >> >> Many thanks, >> Sue Hares >> >> -----Original Message----- >> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of = Lars >> Eggert >> Sent: Wednesday, February 02, 2011 8:14 AM >> To: Patrick Frejborg; Costin Raiciu >> Cc: Ralph Droms; Susan Hares; armd@ietf.org >> Subject: Spam:******, Re: [armd] Data center issues >> >> Patrick, Costin (CC'ed) and others have recently played quite a bit with >> MPTCP in datacenters and I have heard there are huge gains. >> >> On 2011-2-1, at 17:23, Patrick Frejborg wrote: >> >>> MPTCP is evolving and that itself provides a session layer for the >>> application. If we apply theoretically MPTCP on the Yahoo >>> architecture, then the first subflow is connected to the load balancer >>> (LB) - user is identified, MPTCP token exchanged and the IP address >>> (to setup a second subflow to the real server) is exchanged with the >>> client. The LB is sending the token via a trusted backdoor to the real >>> server so the client and real server can establish a new subflow for >>> the application - after that the client =A0uses the application without >>> traversing the LB anymore. >> >> >> > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd >