From wwwrun@ietfa.amsl.com Thu Dec 8 15:14:24 2011 Return-Path: X-Original-To: dc@ietf.org Delivered-To: dc@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id F1BE921F8507; Thu, 8 Dec 2011 15:14:23 -0800 (PST) From: IETF Secretariat To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20111208231423.F1BE921F8507@ietfa.amsl.com> Date: Thu, 8 Dec 2011 15:14:23 -0800 (PST) Cc: rbonica@juniper.net, dc@ietf.org, stbryant@cisco.com Subject: [dc] New Non-WG Mailing List: dc -- IETF Data Center Mailing List X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 23:14:24 -0000 A new IETF non-working group email list has been created. IETF Data Center Mailing List List address: dc@ietf.org Archive: http://www.ietf.org/mail-archive/web/dc/ To subscribe: https://www.ietf.org/mailman/listinfo/dc Purpose: This mailing list is for the discussion of networking issues related to data centers (DC). These issues include both issues that relate to connectivity within a single DC and issue that relate to connectivity between two or more DCs. Topics discussed on this mailing list include: - Services provided by the DC, and the networking requirements that those services generate - Network architectures commonly deployed in DC - Network architectures commonly deployed to interconnect DCs - Scaling, management and security problems associated with each commonly deployed architecture - Solutions to the above mentioned problems. For additional information, please contact the list administrators. From ccie15672@gmail.com Fri Dec 9 07:21:59 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9384621F8549 for ; Fri, 9 Dec 2011 07:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1uce8EJY8va for ; Fri, 9 Dec 2011 07:21:59 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB69621F852E for ; Fri, 9 Dec 2011 07:21:55 -0800 (PST) Received: by ggnk5 with SMTP id k5so3903930ggn.31 for ; Fri, 09 Dec 2011 07:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=RQxm1Ajg7gBnZaJ5RZd6SaWIVWwHKNVHeE/HLE1UE5w=; b=KYO5cxT1XHGENvAdDlmPnmdzfW7cAMDlP3CKWMHyz3qUQQs27GMC08c43316K0URsn Wyn0hj04B+8dXjDJ+NYxPzFCo91qE0PXufphrUYSN1Id98V5dmKIThI9jwf5/EkF2F4H LigcwyYk6XyUYQOUa0Svohbhb5QWgz+nYbcBY= MIME-Version: 1.0 Received: by 10.182.11.104 with SMTP id p8mr556911obb.24.1323444115550; Fri, 09 Dec 2011 07:21:55 -0800 (PST) Received: by 10.182.122.102 with HTTP; Fri, 9 Dec 2011 07:21:55 -0800 (PST) Date: Fri, 9 Dec 2011 09:21:55 -0600 Message-ID: From: Derick Winkworth To: dc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dc] RYU... X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 15:23:49 -0000 All: Those of you that have been following the VPN4DC discussion should be interested in RYU: http://www.osrg.net/ryu/index.html. This is an integrated OpenFlow/OpenStack solution that addresses part of what we are trying to achieve. Its worth taking a moment to go over it... Derick Winkworth CCIE/JNCIE "All energy flows according to the whims of the Great Magnet" -HST From vumip1@gmail.com Fri Dec 9 12:29:34 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04EC21F8AAA for ; Fri, 9 Dec 2011 12:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3AP7z2CL6fW for ; Fri, 9 Dec 2011 12:29:33 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D02A21F8A96 for ; Fri, 9 Dec 2011 12:29:33 -0800 (PST) Received: by ggnk5 with SMTP id k5so4240251ggn.31 for ; Fri, 09 Dec 2011 12:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=TQBRDrroS2UGuKG8ewbP6Euqc6MgF+ZeWNFLA4v8/0Y=; b=rTwOwK/kIhiwzgsy8zKAyXrGzDcmeWHgeyEDdC8UKz4JwHKDqNZDI2PvTDQazQXy8y dsz+MImT8UmaiOLCxcQHhds+KDpGt3ZnYuaRYBF4WnxnpSOt3AtZ6W2qo8KQ6wRIPT8B sPRYjbgyjJYb1Addst17jpkpp46WkXIDDIKTg= MIME-Version: 1.0 Received: by 10.50.77.194 with SMTP id u2mr4980031igw.2.1323462572825; Fri, 09 Dec 2011 12:29:32 -0800 (PST) Received: by 10.50.170.105 with HTTP; Fri, 9 Dec 2011 12:29:32 -0800 (PST) Date: Fri, 9 Dec 2011 15:29:32 -0500 Message-ID: From: Bhumip Khasnabish To: dc@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3bafa786ddf604b3aea4ed Cc: "So, Ning" , Chu.JunSheng@zte.com.cn, Suren Karavettil , Lizhong Jin , meng.yu@zte.com.cn, shao.weixiang@zte.com.cn, hu.jie@zte.com.cn Subject: [dc] Requesting comments on the following drafts X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:29:34 -0000 --e89a8f3bafa786ddf604b3aea4ed Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear All, We are planning to update the following DC-related drafts soon, and would appreciate your valuable comments and suggestions. http://www.ietf.org/id/draft-karavettil-vdcs-security-framework-00.txt http://tools.ietf.org/id/draft-khasnabish-cloud-reference-framework-01.txt http://tools.ietf.org/id/draft-khasnabish-cloud-sdo-survey-01.txt http://tools.ietf.org/id/draft-khasnabish-cloud-industry-workitems-survey-0= 1.txt http://tools.ietf.org/id/draft-junsheng-opsawg-virtual-resource-management-= 00.txt Thanks a lot. Best. Bhumip Khasnabish vumip1@gmail.com bhumip.khasnabish@zteusa.com +1-781-752-8003 (mobile) http://www.linkedin.com/in/bhumipkhasnabish __o _ `\ <, _ .......... ( =95 ) / ( =95 ) ...................... --e89a8f3bafa786ddf604b3aea4ed Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Dear All,
=A0
We are planning to update the following DC-related drafts soon,
and would appreciate your valuable comments and suggestions.
=A0
=A0
=A0
Thanks a lot.
Best.

Bhumip Khasnabish

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __o
=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 _ `\ <, _
.......... ( =95 ) / ( =95 = ) ......................

--e89a8f3bafa786ddf604b3aea4ed-- From bschlies@cisco.com Fri Dec 9 12:59:32 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA1721F84BD; Fri, 9 Dec 2011 12:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM2ZHtRdRedO; Fri, 9 Dec 2011 12:59:31 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 660E921F84B8; Fri, 9 Dec 2011 12:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=2157; q=dns/txt; s=iport; t=1323464371; x=1324673971; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=roq4XWgkqaRGXWShkIk6S3ICqoXbpoFYs5YscsEWqk8=; b=U2DcMZTgVNIVaDeMXnlff1//vIiy3lZUaFt4TO9tRMWP2bJpVuv+RAEw /GGBO6dkKWlWUorQbsqSGtzJG6LtAIlK3Z4cIc841RJBEU+68EioVLm7W N2Ps3bn70WzEYvQaMldLDVMDMCHbbE27/J4MJOG3fecfFVypRKcQxRMuy 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADB24k6rRDoG/2dsb2JhbABDqniBBYFyAQEBAQIBAQEBDwEnNAsFCwsRAQIBAg0iJyIGCAYTCRIHh2UIl1cBng2LD2MEiDCMQJJG X-IronPort-AV: E=Sophos;i="4.71,328,1320624000"; d="scan'208";a="19118810" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 09 Dec 2011 20:59:31 +0000 Received: from sjc-bschlies-8919.cisco.com (sjc-bschlies-8919.cisco.com [10.20.217.234]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pB9KxU9f010779; Fri, 9 Dec 2011 20:59:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Benson Schliesser In-Reply-To: <6665BC1FEA04AB47B1F75FA641C43BC0911ACF31@FHDP1LUMXC7V41.us.one.verizon.com> Date: Fri, 9 Dec 2011 14:59:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <389BEA43-78EF-46DA-871E-10174F9F32FF@cisco.com> References: <6665BC1FEA04AB47B1F75FA641C43BC0911ACF31@FHDP1LUMXC7V41.us.one.verizon.com> To: "So, Ning" X-Mailer: Apple Mail (2.1084) Cc: l2vpn@ietf.org, l3vpn@ietf.org, dc@ietf.org, armd@ietf.org Subject: Re: [dc] New Non-WG Mailing List: dc -- IETF Data Center Mailing X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:59:32 -0000 Hi, Ning. On Dec 9, 2011, at 2:36 PM, So, Ning wrote: > Thanks for the lead. Are you suggesting all vpn4dc related discussion = should move out of L3VPN mailing list onto DC mailing list? Do you know = if the new DC list meant to be for all DC related discussion, or just a = sub-set of topics? For example, VPN4DC, NVO3, SDN, SAMI, and so on. =20 If there is a more-specific forum for a given topic, I would suggest = using it. For instance, if one wishes to discuss ARMD issues, I suggest = using the armd@ietf.org mailing list. But there is much that is out of = ARMD's scope, which might be more appropriate for discussion on = dc@ietf.org instead. I will leave it to L3VPN and L2VPN chairs to comment on what is in scope = for those respective mailing lists. Cheers, -Benson Begin forwarded message: > From: IETF Secretariat > Date: 8 December 2011 23:14:23 GMT > To: IETF Announcement list > Cc: rbonica@juniper.net, dc@ietf.org, stbryant@cisco.com > Subject: New Non-WG Mailing List: dc -- IETF Data Center Mailing List >=20 > A new IETF non-working group email list has been created. >=20 > IETF Data Center Mailing List > List address: dc@ietf.org > Archive: http://www.ietf.org/mail-archive/web/dc/ > To subscribe: https://www.ietf.org/mailman/listinfo/dc >=20 > Purpose: This mailing list is for the discussion of networking issues=20= > related to data centers (DC). These issues include both issues that=20 > relate to connectivity within a single DC and issue that relate to=20 > connectivity between two or more DCs. Topics discussed on this mailing=20= > list include: >=20 > - Services provided by the DC, and the networking requirements that =20= > those services generate > - Network architectures commonly deployed in DC > - Network architectures commonly deployed to interconnect DCs > - Scaling, management and security problems associated with each =20 > commonly deployed architecture > - Solutions to the above mentioned problems.=20 >=20 > For additional information, please contact the list administrators. From vumip1@gmail.com Tue Dec 13 14:19:51 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC75321F86DD; Tue, 13 Dec 2011 14:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQdCL1V1gNG0; Tue, 13 Dec 2011 14:19:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0A0421F844F; Tue, 13 Dec 2011 14:19:50 -0800 (PST) Received: by iaek3 with SMTP id k3so221331iae.31 for ; Tue, 13 Dec 2011 14:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=7CltsZj4p+Ct7LnJxz4yrTbjkZNQ7rfoyO7z0Y8xrr0=; b=w3geuNt052iY4RR+8YQotSAUqnmQ4TP3N6a3KNDWHRb3+gXseioC7IXLuiK36E09HI qMs1NIOa8eR//u9AHBejVAxane9SD8qEJjukelT9IU4MlTulzloVaaLjVpDULcfvLZEa ZVTtrwlQLVvpC2Frl2bGuVAHOB5Z3oV23s9I4= MIME-Version: 1.0 Received: by 10.50.202.65 with SMTP id kg1mr21309099igc.1.1323814790648; Tue, 13 Dec 2011 14:19:50 -0800 (PST) Received: by 10.50.170.105 with HTTP; Tue, 13 Dec 2011 14:19:50 -0800 (PST) Date: Tue, 13 Dec 2011 17:19:50 -0500 Message-ID: From: Bhumip Khasnabish To: dc@ietf.org Content-Type: multipart/alternative; boundary=f46d0447851558549604b400a699 Cc: vnrg@irtf.org, opsawg@ietf.org, l3vpn@ietf.org, apps-discuss@ietf.org Subject: [dc] slides from Dr. Chu's lunch time talk on Smart Cloud Computing Network Architecture and Services during IETF-82 X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 22:19:52 -0000 --f46d0447851558549604b400a699 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For the Cloud and Data center enthusiasts, the slides from Dr. Chu's lunch time talk on Smart Cloud Computing Network Architecture and Services during IETF-82 ( (on Thu-17-Nov.-2011, Taipei, Taiwan) can be found at the following website: http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/ The file names are part1-IETF-82-LunchTalk-Smart-Cloud-Computing-Network-Architecture-and-Serv= ices_v3-Public-Thu17Nov2011.pdf (990.4 KB) part2-IETF-82-LunchTalk-Smart-Cloud-Computing-Network-Architecture-and-Serv= ices_v3-Public-Thu17Nov2011.pdf (742.0 KB) part3-IETF-82-LunchTalk-Smart-Cloud-Computing-Network-Architecture-and-Serv= ices_v3-Public-Thu17Nov2011.pdf (813.0 KB) Thanks. Best. Bhumip Khasnabish vumip1@gmail.com bhumip.khasnabish@zteusa.com +1-781-752-8003 (mobile) http://www.linkedin.com/in/bhumipkhasnabish __o _ `\ <, _ .......... ( =95 ) / ( =95 ) ...................... --f46d0447851558549604b400a699 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
For the Cloud and Data center enthusiasts, the slides from
Dr. Chu's lunch time talk on
Smart Cloud Computing Network Architecture and Services
during IETF-82 ( (on Thu-17-Nov.-2011, Taipei, Taiwan) can
be found at the following=A0 website:
=A0
The file names are

part1-IETF-82-LunchTalk-Smart-Cloud-Computing-Network-Architecture-and-S= ervices_v3-Public-Thu17Nov2011.pdf (990.4 KB)

part2-IETF-82-LunchTalk-Smart-Cloud-Computing-Network-Architecture-and-S= ervices_v3-Public-Thu17Nov2011.pdf (742.0 KB)

part3-IETF-82-LunchTalk-Smart-Cloud-Computing-Network-Architecture-and-S= ervices_v3-Public-Thu17Nov2011.pdf (813.0 KB)

=A0
Thanks.
Best.

Bhumip Khasnabish

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __o
=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 _ `\ <, _
.......... ( =95 ) / ( =95 = ) ......................

--f46d0447851558549604b400a699-- From lufang@cisco.com Wed Dec 14 07:52:53 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C1221F8BA8; Wed, 14 Dec 2011 07:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC1oSzC9s9wv; Wed, 14 Dec 2011 07:52:52 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BED7B21F8B87; Wed, 14 Dec 2011 07:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=12029; q=dns/txt; s=iport; t=1323877972; x=1325087572; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=PHttAAO0kBy22XaVoyuae51OMPOoClWImBh556ks2XA=; b=fRqegoBGxcwHD4NTEAzKmjEdbFBnCyVQ2W1epqBqXcQR0uRyE4S5iz7n AUygCrp2iWqh/NnVdelPMPjzK7lz+7LgBjINsC/mfPZlQjoDS1fy8XBXl 9DqZ2y3HijvjgCg0tWwMN3E/5zx5kC4/wgzlqC3GAXR6xtRtau+NWFM8M Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8AANTF6E6tJXG//2dsb2JhbABDgk2YFIgTiDOBBYFyAQEBBBIBCQEQAzcBERACAQgRBAEBCwYXAQYBRQcBAQUDAQEEARIIGodgmF8Bnl2LJmMEgliFWp8L X-IronPort-AV: E=Sophos;i="4.71,352,1320624000"; d="scan'208,217";a="43885580" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 14 Dec 2011 15:52:51 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBEFqpQW031976; Wed, 14 Dec 2011 15:52:51 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Dec 2011 09:52:51 -0600 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_01CCBA78.6EF0D4F8" Date: Wed, 14 Dec 2011 09:52:48 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25078503E5@XMB-RCD-201.cisco.com> In-Reply-To: <7CD4FCD7-9EBF-40BD-83A0-6E8F9FFE4902@wanadoo.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [Sdnp] Carrier Cloud 2012: Call for Papers Thread-Index: Acy6d21QNNLKOd0CRh68334M9wjsCQAAFlFw References: <7CD4FCD7-9EBF-40BD-83A0-6E8F9FFE4902@wanadoo.fr> From: "Luyuan Fang (lufang)" To: "Remi Scavenius" , X-OriginalArrivalTime: 14 Dec 2011 15:52:51.0096 (UTC) FILETIME=[6F2CF180:01CCBA78] X-Mailman-Approved-At: Wed, 14 Dec 2011 08:04:17 -0800 Cc: l2vpn@ietf.org, opsawg@ietf.org, l3vpn@ietf.org, dc@ietf.org, armd@ietf.org Subject: [dc] FW: [Sdnp] Carrier Cloud 2012: Call for Papers X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 15:52:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBA78.6EF0D4F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: sdnp-bounces@lucidvision.com [mailto:sdnp-bounces@lucidvision.com] On Behalf Of Remi Scavenius Sent: Wednesday, December 14, 2011 10:38 AM To: sdnp@lucidvision.com Subject: [Sdnp] Carrier Cloud 2012: Call for Papers =20 If this email does not display correctly, please click here =20 =20 =20 =20 =20 Carrier Cloud 2012: Transforming Service Providers Business =20 =20 =20 SaaS and IaaS are one thing and networking is another. This is an argument carriers can definitely put on the table when investigating the cloud services market. During the Carrier Cloud Summit, to be held in Novotel Wellness & Convention Centre Paris Roissy CDG from 19 to 21 June, 2012, project leaders, manufacturers and service developers will address all technical issues through up-to-date contributions. A call for proposals is effective until January 31st, 2012. The proposals will be analyzed by a scientific committee.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Organized by Upperside Conferences 54 rue du Faubourg Saint Antoine 75012 Paris - France =20 If you don't want to receive emails regarding our conferences and events, send us an email. =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CCBA78.6EF0D4F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = sdnp-bounces@lucidvision.com [mailto:sdnp-bounces@lucidvision.com] On Behalf Of Remi = Scavenius
Sent: Wednesday, December 14, 2011 10:38 AM
To: sdnp@lucidvision.com
Subject: [Sdnp] Carrier Cloud 2012: Call for = Papers

 

If this = email does not display correctly, please click here

 

 

 

 

Carrier Cloud 2012: Transforming Service Providers = Business

 

 

SaaS and IaaS are one thing and networking is = another. This is an argument carriers can definitely put on the table when investigating the cloud services market. During the Carrier Cloud = Summit, to be held in Novotel Wellness & Convention Centre Paris Roissy = CDG from 19 to 21 June, 2012, project leaders, manufacturers and service developers will address all technical = issues through up-to-date contributions.

A call for proposals is effective until January 31st, = 2012.

The proposals will be analyzed by a scientific = committee.

 

 

 

 

 

 

 

 

Organized = by Upperside Conferences 54 rue du = Faubourg Saint Antoine 75012 Paris - France

 

If you don't = want to receive emails regarding our conferences and events, send us an = email.

 

 

 

 

 

------_=_NextPart_001_01CCBA78.6EF0D4F8-- From wwwrun@ietfa.amsl.com Wed Dec 14 09:25:46 2011 Return-Path: X-Original-To: dc@ietf.org Delivered-To: dc@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 9AAA921F8AF0; Wed, 14 Dec 2011 09:25:46 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20111214172546.9AAA921F8AF0@ietfa.amsl.com> Date: Wed, 14 Dec 2011 09:25:46 -0800 (PST) Cc: dc@ietf.org Subject: [dc] Joint O&M / Routing Area Interim To Discuss Data Center Network Challenges X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 17:25:46 -0000 The IETF Operations and Routing Areas will hold a two-day joint interim meeting in late January or early February to discuss networking challenges encountered in data centers. A doodle poll has been posted at http://www.doodle.com/hiu9xgw7tg7pkrwg in order to gauge interest and identify a convenient date. While a venue has not yet been chosen, the IETF is considering sites in the eastern part of the United States and Canada. An attendance fee may be charged to cover meeting costs. Those requesting time on the agenda are asked to submit Internet Drafts in the following areas: - New services offered through data centers - Networking requirements for the data center - Network architectures for the data center - Scaling, resiliency, security issues in the data center networks Internet Drafts considered by this meeting will specify motivation, requirements and constraints for data center networking solutions to be developed by the IETF. Presentations regarding solutions will be entertained only if that discussion helps to describe the problem space and time permits a balanced discussion of candidate technologies. All drafts presented at this meeting will be announced and discussed on the IETF Data Center Mailing List (dc@ietf.org). Those submitting drafts are asked to announce them to the mailing list upon submission. From paul.hoffman@vpnc.org Wed Dec 14 09:58:46 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF1621F87D3 for ; Wed, 14 Dec 2011 09:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4nkHuHddLgE for ; Wed, 14 Dec 2011 09:58:45 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 589AA21F85B1 for ; Wed, 14 Dec 2011 09:58:45 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBEHwiUX042863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 14 Dec 2011 10:58:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Dec 2011 09:58:44 -0800 Message-Id: <5F2A04CD-3AD0-4EF8-8401-3B83A65518A5@vpnc.org> To: dc@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Wed, 14 Dec 2011 10:51:53 -0800 Subject: [dc] Will the interim meeting allow remote participation? X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 17:58:46 -0000 Just wondering... --Paul Hoffman From rbonica@juniper.net Wed Dec 14 11:21:32 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6133B1F0C5D for ; Wed, 14 Dec 2011 11:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rUUJcc8pkXV for ; Wed, 14 Dec 2011 11:21:29 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id E10701F0C4F for ; Wed, 14 Dec 2011 11:21:27 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTuj3K4NrSBUAIvEqbkjCVOq/9FeivfQD@postini.com; Wed, 14 Dec 2011 11:21:29 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 14 Dec 2011 10:52:33 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 14 Dec 2011 13:52:32 -0500 From: Ronald Bonica To: Paul Hoffman , "dc@ietf.org" Date: Wed, 14 Dec 2011 13:52:31 -0500 Thread-Topic: [dc] Will the interim meeting allow remote participation? Thread-Index: Acy6kXSXYytL2fPlSi+bSYGMpoT4owAAARwQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D74E464234@EMBX01-WF.jnpr.net> References: <5F2A04CD-3AD0-4EF8-8401-3B83A65518A5@vpnc.org> In-Reply-To: <5F2A04CD-3AD0-4EF8-8401-3B83A65518A5@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dc] Will the interim meeting allow remote participation? X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 19:21:32 -0000 Hi Paul, I don't know yet. It depends on the venue options that we get. Ron > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Wednesday, December 14, 2011 12:59 PM > To: dc@ietf.org > Subject: [dc] Will the interim meeting allow remote participation? >=20 > Just wondering... >=20 > --Paul Hoffman >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From joelja@bogus.com Thu Dec 15 14:01:55 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AC821F8500 for ; Thu, 15 Dec 2011 14:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMZCn34xCs+V for ; Thu, 15 Dec 2011 14:01:54 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C5D9E21F84FD for ; Thu, 15 Dec 2011 14:01:54 -0800 (PST) Received: from Joels-MacBook-Pro.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pBFM1rIv015786 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 15 Dec 2011 22:01:54 GMT (envelope-from joelja@bogus.com) Message-ID: <4EEA6E4C.1040004@bogus.com> Date: Thu, 15 Dec 2011 14:01:48 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ronald Bonica References: <5F2A04CD-3AD0-4EF8-8401-3B83A65518A5@vpnc.org> <13205C286662DE4387D9AF3AC30EF456D74E464234@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74E464234@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 15 Dec 2011 22:01:54 +0000 (UTC) Cc: Paul Hoffman , "dc@ietf.org" Subject: Re: [dc] Will the interim meeting allow remote participation? X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 22:01:55 -0000 On 12/14/11 10:52 , Ronald Bonica wrote: > Hi Paul, > > I don't know yet. It depends on the venue options that we get. So far it's been an impressively low traffic list for a cross area intersection of interests gearing up to discuss documents at an interim. > Ron > > >> -----Original Message----- >> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >> Paul Hoffman >> Sent: Wednesday, December 14, 2011 12:59 PM >> To: dc@ietf.org >> Subject: [dc] Will the interim meeting allow remote participation? >> >> Just wondering... >> >> --Paul Hoffman >> >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc > From marshall.eubanks@gmail.com Thu Dec 15 14:25:28 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E6721F87FA for ; Thu, 15 Dec 2011 14:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYl-qRaaCRpj for ; Thu, 15 Dec 2011 14:25:27 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 69BB721F87D6 for ; Thu, 15 Dec 2011 14:25:27 -0800 (PST) Received: by ggnk5 with SMTP id k5so2551486ggn.31 for ; Thu, 15 Dec 2011 14:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kLWjMhs8vRfdXm7ZEdopptyyViphXCzDI0jEsNrqWZ4=; b=bFWLsP4U6BHpDfkYFKBX1BK5vufosdcZl7IejR9ARNUyRV0BEiYctNqtZx0m/N9p+F JoHrR9MoWtWyw6bC9IYxgRg84N4VLvVoc//1emKCIWHqeabkN1BoLCc/GsBPIUkWtMDu McgYr/TLo5gYjJ8Iu21D+DEFFmmS6px2zTG24= MIME-Version: 1.0 Received: by 10.182.167.69 with SMTP id zm5mr1710055obb.13.1323987927005; Thu, 15 Dec 2011 14:25:27 -0800 (PST) Received: by 10.182.227.67 with HTTP; Thu, 15 Dec 2011 14:25:26 -0800 (PST) In-Reply-To: <4EEA6E4C.1040004@bogus.com> References: <5F2A04CD-3AD0-4EF8-8401-3B83A65518A5@vpnc.org> <13205C286662DE4387D9AF3AC30EF456D74E464234@EMBX01-WF.jnpr.net> <4EEA6E4C.1040004@bogus.com> Date: Thu, 15 Dec 2011 17:25:26 -0500 Message-ID: From: Marshall Eubanks To: Joel jaeggli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ronald Bonica , Paul Hoffman , "dc@ietf.org" Subject: Re: [dc] Will the interim meeting allow remote participation? X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 22:25:28 -0000 On Thu, Dec 15, 2011 at 5:01 PM, Joel jaeggli wrote: > On 12/14/11 10:52 , Ronald Bonica wrote: >> Hi Paul, >> >> I don't know yet. It depends on the venue options that we get. > I think that it really needs to have remote access. If that seems to be a problem, please let the IAOC know. > So far it's been an impressively low traffic list for a cross area > intersection of interests gearing up to discuss documents at an interim. > There seemed to be a substantial amount of interest in Taipei. All of the meetings were well attended, and there was a lot of discussion outside of the meetings. Regards Marshall >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Ron >> >> >>> -----Original Message----- >>> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >>> Paul Hoffman >>> Sent: Wednesday, December 14, 2011 12:59 PM >>> To: dc@ietf.org >>> Subject: [dc] Will the interim meeting allow remote participation? >>> >>> Just wondering... >>> >>> --Paul Hoffman >>> >>> _______________________________________________ >>> dc mailing list >>> dc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dc >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc >> > > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From lars@netapp.com Fri Dec 16 00:24:12 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D6B21F8513 for ; Fri, 16 Dec 2011 00:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.967 X-Spam-Level: X-Spam-Status: No, score=-9.967 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U-Pb4pCjcNw for ; Fri, 16 Dec 2011 00:24:11 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id E993821F8511 for ; Fri, 16 Dec 2011 00:24:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,362,1320652800"; d="p7s'?scan'208";a="607906478" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 16 Dec 2011 00:23:55 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id pBG8NrXw028673 for ; Fri, 16 Dec 2011 00:23:55 -0800 (PST) Received: from VMWEXCEHT05-PRD.hq.netapp.com ([10.106.77.35]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Dec 2011 00:23:49 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.01.0355.002; Fri, 16 Dec 2011 00:23:43 -0800 From: "Eggert, Lars" To: "dc@ietf.org" Thread-Topic: IRTF datacenter research group discussion list Thread-Index: AQHMu8wF2kztUMq2mESW0xNiJ3OGrQ== Date: Fri, 16 Dec 2011 08:23:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_0675A58C-EC80-4C1B-88B8-C828DE26D9C7"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Dec 2011 08:23:49.0291 (UTC) FILETIME=[096F3FB0:01CCBBCC] Subject: [dc] IRTF datacenter research group discussion list X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 08:24:12 -0000 --Apple-Mail=_0675A58C-EC80-4C1B-88B8-C828DE26D9C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I wanted to make you all aware of the IRTF's dcrg-interest mailing list, = which was set up following a face-to-face meeting at SIGCOMM this year = to discuss a possible IRTF research group on datacenter networking: = http://irtf.org/mailman/listinfo/dcrg-interest There has not been much activity towards the formation of an IRTF RG = since SIGCOMM, but I am hopeful that the high energy level demonstrated = in the various Taipei meetings on the topic will inject some energy here = - several of the topics that may be too early for the IETF to = standardize around would fit an IRTF RG very well. I'm certainly = supportive of this. Lars IRTF Chair --=20 Mobile number during December: +358 46 5215582 Mobile number starting January: +49 151 12055791 --Apple-Mail=_0675A58C-EC80-4C1B-88B8-C828DE26D9C7 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIxNjA4MjM0NVowIwYJKoZIhvcNAQkEMRYEFLH4 9uv40m0QjgCewspmttC79+HSMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAITGxFdQ M46SAq8nI1BNYgcodCU0nNgOm10R/frmEWLc41pge8fhnBXKVB9/AgOckB8tga11wA1mZ3B0SB9c rMQHThUcAcBp9VneIcikPK/9tiIg0K6k7v2m7O9SHGwANIMFSwjtSsYRYnVvcnOgxP8cw0NSTiXi OiTE7WHsH/IlT5JQX4PPol3vv1IhFPErQdHSkYkod29DO49eiyJ46qPl6iKGl4tlOwracdgf5NY9 wGU18cdZ6m4iv3iYUrGJlYVrE4Zj3TT92jUrx+PHic5b4//HehjZnLJSOhgVL6EyxLP+O/KHue3Z Cowipkb+aYwudfNR7fYqBKeaAe+5LIIAAAAAAAA= --Apple-Mail=_0675A58C-EC80-4C1B-88B8-C828DE26D9C7-- From narten@us.ibm.com Fri Dec 16 05:16:29 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6984E21F8B58 for ; Fri, 16 Dec 2011 05:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.105 X-Spam-Level: X-Spam-Status: No, score=-106.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPyZ1gQ9z1ia for ; Fri, 16 Dec 2011 05:16:29 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by ietfa.amsl.com (Postfix) with ESMTP id BEF7821F8B4E for ; Fri, 16 Dec 2011 05:16:28 -0800 (PST) Received: from /spool/local by e2.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 16 Dec 2011 08:16:26 -0500 Received: from d01relay04.pok.ibm.com (9.56.227.236) by e2.ny.us.ibm.com (192.168.1.102) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 16 Dec 2011 08:15:36 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBGDFYKH268686 for ; Fri, 16 Dec 2011 08:15:35 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBGDFYML032360 for ; Fri, 16 Dec 2011 08:15:34 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-119.mts.ibm.com [9.65.248.119]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBGDFRb6031720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Dec 2011 08:15:29 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pBGDFP9X009939 for ; Fri, 16 Dec 2011 08:15:27 -0500 Message-Id: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> To: "dc@ietf.org" Date: Fri, 16 Dec 2011 08:15:25 -0500 From: Thomas Narten x-cbid: 11121613-5112-0000-0000-00000323C7FC Subject: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 13:16:29 -0000 Joel jaeggli writes: > So far it's been an impressively low traffic list for a cross area > intersection of interests gearing up to discuss documents at an interim. Fair point. And with that, I'd like to start with a summary of the potential work items that might be covered here. By "work items", I'd like to see a grouping of IDs/presentations into (potential) work areas. The goal would be to talk about each work area somewhat separately. If we aren't able to organize work into mostly self-contained areas (i.e., WGs), we'll never get anywhere. So far, the ones I know of include: NVO3 draft-narten-nvo3-overlay-problem-statement-01.txt SDN draft-nadeau-sdn-problem-statement-01.txt Use Case/Examples: draft-stiliadis-sdnp-framework-use-cases-01.txt draft-pan-sdn-bod-problem-statement-and-use-case-01.txt draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt draft-mcdysan-sdnp-cloudbursting-usecase-00.txt Solutions/Approachs: draft-nadeau-sdn-framework-01.txt draft-marques-sdnp-flow-spec-00.txt VPN4DC http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 http://tools.ietf.org/html/draft-so-vpn4dc-00 http://datatracker.ietf.org/doc/draft-so-vdcs-01 http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Are there others? Thomas From lufang@cisco.com Fri Dec 16 09:29:56 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB7921F8B4F for ; Fri, 16 Dec 2011 09:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PdZlDLtj4MJ for ; Fri, 16 Dec 2011 09:29:54 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 991B821F8B44 for ; Fri, 16 Dec 2011 09:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=2487; q=dns/txt; s=iport; t=1324056594; x=1325266194; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=kWjrxfdDXHS2ueoOGgaAnAL4tjQTP5qt0tW+VFbO0s0=; b=UkF+0Q0VQFGCI2mF2CG/MEc+3zMUrxDDWsS+gdqgRBHecKzBXZUsturR btnWaLUJSsMSzv0goeOdY+n/3QG7Yq+Xn79m47DdT0wbR6hZZz3X8TCtQ gQggVPrdI/Rij9oJdsvioP6tNj+tspqGvAfOJms5WSPlCs8uXjmg4QJwt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUAAM1+606tJXG9/2dsb2JhbABDmwmQS4EFgXIBAQECAgEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCAESB4dgmWkBnjiLIWMEiDSfDQ X-IronPort-AV: E=Sophos;i="4.71,364,1320624000"; d="scan'208";a="44655751" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 16 Dec 2011 17:29:54 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pBGHTsAw001104; Fri, 16 Dec 2011 17:29:54 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Dec 2011 11:29:53 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Dec 2011 11:29:51 -0600 Message-ID: <238542D917511A45B6B8AA806E875E2507850C94@XMB-RCD-201.cisco.com> In-Reply-To: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Work items for this group Thread-Index: Acy79O3yVHqks9B7Tg2DUH7ccjlAaAAItFSg References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> From: "Luyuan Fang (lufang)" To: "Thomas Narten" , X-OriginalArrivalTime: 16 Dec 2011 17:29:53.0925 (UTC) FILETIME=[52ADA350:01CCBC18] Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 17:29:56 -0000 Agree with Thomas' approach, thanks for the summary. Here is also the link for VPN4DC slides which we discussed in Taipei. http://www.ietf.org/proceedings/82/slides/l3vpn-3.pdf Luyuan > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Friday, December 16, 2011 8:15 AM > To: dc@ietf.org > Subject: [dc] Work items for this group >=20 > Joel jaeggli writes: >=20 > > So far it's been an impressively low traffic list for a cross area > > intersection of interests gearing up to discuss documents at an > interim. >=20 > Fair point. >=20 > And with that, I'd like to start with a summary of the potential work > items that might be covered here. By "work items", I'd like to see a > grouping of IDs/presentations into (potential) work areas. The goal > would be to talk about each work area somewhat separately. If we > aren't able to organize work into mostly self-contained areas (i.e., > WGs), we'll never get anywhere. >=20 > So far, the ones I know of include: >=20 > NVO3 > draft-narten-nvo3-overlay-problem-statement-01.txt > SDN > draft-nadeau-sdn-problem-statement-01.txt >=20 > Use Case/Examples: > draft-stiliadis-sdnp-framework-use-cases-01.txt > draft-pan-sdn-bod-problem-statement-and-use-case-01.txt > draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt > draft-mcdysan-sdnp-cloudbursting-usecase-00.txt >=20 > Solutions/Approachs: > draft-nadeau-sdn-framework-01.txt > draft-marques-sdnp-flow-spec-00.txt > VPN4DC > http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 >=20 > http://tools.ietf.org/html/draft-bitar-datacenter-vpn- > applicability-01 > http://tools.ietf.org/html/draft-so-vpn4dc-00 > http://datatracker.ietf.org/doc/draft-so-vdcs-01 > http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 > http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 > http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 > http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis- > 00 > http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >=20 > Are there others? >=20 > Thomas >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From joelja@bogus.com Fri Dec 16 10:14:03 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9368821F8A55 for ; Fri, 16 Dec 2011 10:14:03 -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=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2jZBThFdLMU for ; Fri, 16 Dec 2011 10:14:03 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 243CA21F8A62 for ; Fri, 16 Dec 2011 10:14:03 -0800 (PST) Received: from Joels-MacBook-Pro.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pBGIE0HK038560 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 16 Dec 2011 18:14:01 GMT (envelope-from joelja@bogus.com) Message-ID: <4EEB8A63.8040609@bogus.com> Date: Fri, 16 Dec 2011 10:13:55 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Luyuan Fang (lufang)" References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> <238542D917511A45B6B8AA806E875E2507850C94@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E2507850C94@XMB-RCD-201.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 16 Dec 2011 18:14:01 +0000 (UTC) Cc: Thomas Narten , dc@ietf.org Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 18:14:03 -0000 I thought the summary was a pretty good reading list, thanks. joel On 12/16/11 09:29 , Luyuan Fang (lufang) wrote: > Agree with Thomas' approach, thanks for the summary. > > Here is also the link for VPN4DC slides which we discussed in Taipei. > http://www.ietf.org/proceedings/82/slides/l3vpn-3.pdf > > Luyuan > >> -----Original Message----- >> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >> Thomas Narten >> Sent: Friday, December 16, 2011 8:15 AM >> To: dc@ietf.org >> Subject: [dc] Work items for this group >> >> Joel jaeggli writes: >> >>> So far it's been an impressively low traffic list for a cross area >>> intersection of interests gearing up to discuss documents at an >> interim. >> >> Fair point. >> >> And with that, I'd like to start with a summary of the potential work >> items that might be covered here. By "work items", I'd like to see a >> grouping of IDs/presentations into (potential) work areas. The goal >> would be to talk about each work area somewhat separately. If we >> aren't able to organize work into mostly self-contained areas (i.e., >> WGs), we'll never get anywhere. >> >> So far, the ones I know of include: >> >> NVO3 >> draft-narten-nvo3-overlay-problem-statement-01.txt >> SDN >> draft-nadeau-sdn-problem-statement-01.txt >> >> Use Case/Examples: >> draft-stiliadis-sdnp-framework-use-cases-01.txt >> draft-pan-sdn-bod-problem-statement-and-use-case-01.txt >> draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt >> draft-mcdysan-sdnp-cloudbursting-usecase-00.txt >> >> Solutions/Approachs: >> draft-nadeau-sdn-framework-01.txt >> draft-marques-sdnp-flow-spec-00.txt >> VPN4DC >> http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 >> >> http://tools.ietf.org/html/draft-bitar-datacenter-vpn- >> applicability-01 >> http://tools.ietf.org/html/draft-so-vpn4dc-00 >> http://datatracker.ietf.org/doc/draft-so-vdcs-01 >> > http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 >> http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 >> http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 >> > http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis- >> 00 >> http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 >> http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >> >> Are there others? >> >> Thomas >> >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc > From melinda.shore@gmail.com Fri Dec 16 10:19:11 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3135B21F8B6C for ; Fri, 16 Dec 2011 10:19:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQZ7-YfHJDqQ for ; Fri, 16 Dec 2011 10:19:10 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA3121F8B37 for ; Fri, 16 Dec 2011 10:19:10 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so1814091vbb.31 for ; Fri, 16 Dec 2011 10:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VJiEGVYjElJi+ZF0GdgbE92F8CxD7lwY6Q11zgciXAE=; b=sKpAROo7DMu32H5ouotFoXbD0VdGbikzYcSQT/7OIZaqnOO9/dsepAA8wZ/qV3+FOm xXF61NSgLmcHTXgQUbtKFXctgPEU1F/k/8fMmWjGyhuDaA3h3hxVNLCU8i6MW8CqrNen KmfLLGHTNhWWmqz5qB+IBQLaj8Y41cSohLipE= Received: by 10.52.26.66 with SMTP id j2mr7006365vdg.98.1324059550107; Fri, 16 Dec 2011 10:19:10 -0800 (PST) Received: from polypro.local (66-230-87-15-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.87.15]) by mx.google.com with ESMTPS id c7sm9724998vdh.12.2011.12.16.10.19.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Dec 2011 10:19:09 -0800 (PST) Message-ID: <4EEB8B9A.7090304@gmail.com> Date: Fri, 16 Dec 2011 09:19:06 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.24) Gecko/20111103 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: dc@ietf.org References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> In-Reply-To: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 18:19:11 -0000 On 12/16/11 4:15 AM, Thomas Narten wrote: > Are there others? There's the stuff on middlebox state transfer. It came out of the datacenter discussions and has been going forward in the ops area, but at this point it's not really clear to me that it's the best fit for ops. Melinda From linda.dunbar@huawei.com Fri Dec 16 10:37:11 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E516F21F8B1E for ; Fri, 16 Dec 2011 10:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hasme5iNk6eC for ; Fri, 16 Dec 2011 10:37:11 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8E521F8B10 for ; Fri, 16 Dec 2011 10:37:11 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABW38396; Fri, 16 Dec 2011 13:37:10 -0500 (EST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Dec 2011 10:35:38 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Fri, 16 Dec 2011 10:35:32 -0800 From: Linda Dunbar To: Melinda Shore , "dc@ietf.org" Thread-Topic: [dc] Work items for this group Thread-Index: AQHMu/T73M2yuZR6J06DZ8EmnClWQZXfTJYA//995IA= Date: Fri, 16 Dec 2011 18:35:31 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F61A67AA1D@dfweml505-mbx> References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> <4EEB8B9A.7090304@gmail.com> In-Reply-To: <4EEB8B9A.7090304@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 18:37:12 -0000 Since there are so much TCP state transition discussed in the middlebox sta= te transfer drafts, would Transport area be a better fit for this?=20 Linda > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Melinda Shore > Sent: Friday, December 16, 2011 12:19 PM > To: dc@ietf.org > Subject: Re: [dc] Work items for this group >=20 > On 12/16/11 4:15 AM, Thomas Narten wrote: > > Are there others? >=20 > There's the stuff on middlebox state transfer. It came > out of the datacenter discussions and has been going forward > in the ops area, but at this point it's not really clear to > me that it's the best fit for ops. >=20 > Melinda > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From cdl@asgaard.org Fri Dec 16 10:43:26 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B49021F8492 for ; Fri, 16 Dec 2011 10:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okWlKhoX5mxh for ; Fri, 16 Dec 2011 10:43:25 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 69E0821F8491 for ; Fri, 16 Dec 2011 10:43:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 7A15F9E2B83; Fri, 16 Dec 2011 18:43:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhJtfzsl-+33; Fri, 16 Dec 2011 18:43:22 +0000 (UTC) Received: from fenrir.bigswitch.com (74-93-4-129-sfba.hfc.comcastbusiness.net [74.93.4.129]) by asgaard.org (Postfix) with ESMTPSA id 834699E2B6C; Fri, 16 Dec 2011 18:43:22 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_692FD42B-775D-4D9D-8DD3-51C3BA6CE77F"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Christopher LILJENSTOLPE In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F61A67AA1D@dfweml505-mbx> Date: Fri, 16 Dec 2011 10:43:16 -0800 Message-Id: <2B21320D-F720-424F-9F36-0287CE5B95EA@asgaard.org> References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> <4EEB8B9A.7090304@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F61A67AA1D@dfweml505-mbx> To: Linda Dunbar X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Fri, 16 Dec 2011 10:48:43 -0800 Cc: Melinda Shore , "dc@ietf.org" Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 18:43:26 -0000 --Apple-Mail=_692FD42B-775D-4D9D-8DD3-51C3BA6CE77F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, It's one of those "not sure where it fits" things. There is a = lot of TCP state, but there is lots of other state as well. =20 Chris On 16Dec2011, at 10.35, Linda Dunbar wrote: > Since there are so much TCP state transition discussed in the = middlebox state transfer drafts, would Transport area be a better fit = for this?=20 >=20 > Linda >=20 >> -----Original Message----- >> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >> Melinda Shore >> Sent: Friday, December 16, 2011 12:19 PM >> To: dc@ietf.org >> Subject: Re: [dc] Work items for this group >>=20 >> On 12/16/11 4:15 AM, Thomas Narten wrote: >>> Are there others? >>=20 >> There's the stuff on middlebox state transfer. It came >> out of the datacenter discussions and has been going forward >> in the ops area, but at this point it's not really clear to >> me that it's the best fit for ops. >>=20 >> Melinda >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_692FD42B-775D-4D9D-8DD3-51C3BA6CE77F Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJO65FIAAoJEGmx2Mt/+Iw/J94H/2LebAQxKkFc0HcA+dxnv+zH 4VVDWPtgt+4lluRRdV9iIDf4Hdq06w4Ly2/d39KdeXu1cS20iQAzLlx9Uak8Y8fh bePg+9W3w9Y1mhSVoewE9sxTIdUlwnQolhW4eWsgdih4oWuhQWuSk8oG9gv8B4g1 aDf+O6OMmDAQTPfcrwPJFSL6/rDb5slhg6PJH16dnEu9BvhNVAx7ZFXPMSMFH8g6 fryyklGvr0Kq/fAaLcXc+UAYoLn0ImGhcXUZDuZf9B9fjaUpslrf2XZq++NtncRl MxCFnueCLMPzJWooemjkzxZx9aiwZl6rwFxDFogQmq+HrLPJULWFDjY73J6FRn8= =JCKb -----END PGP SIGNATURE----- --Apple-Mail=_692FD42B-775D-4D9D-8DD3-51C3BA6CE77F-- From linda.dunbar@huawei.com Fri Dec 16 11:02:31 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B43B11E8093 for ; Fri, 16 Dec 2011 11:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4CMW+OuVih7 for ; Fri, 16 Dec 2011 11:02:30 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 92A4721F8B2E for ; Fri, 16 Dec 2011 11:02:30 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABW39732; Fri, 16 Dec 2011 14:02:30 -0500 (EST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Dec 2011 11:00:36 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Fri, 16 Dec 2011 11:00:40 -0800 From: Linda Dunbar To: Thomas Narten , "dc@ietf.org" Thread-Topic: [dc] Work items for this group Thread-Index: AQHMu/T73M2yuZR6J06DZ8EmnClWQZXey4uw Date: Fri, 16 Dec 2011 19:00:40 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F61A67AA4F@dfweml505-mbx> References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> In-Reply-To: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 19:02:31 -0000 Thomas,=20 Thanks for starting the list.=20 There are several drafts in ARMD for Data Center. The first two drafts have= been discussed at the 82nd IETF meeting in Taipei, therefore might not nee= d to be discussed again at the DC Interim meeting. But they are very good d= ocuments in describing Data Center general architecture and address resolut= ion issues in data centers, which people on this mail list should be intere= sted in.=20 http://datatracker.ietf.org/doc/draft-ietf-armd-problem-statement/ http://datatracker.ietf.org/doc/draft-karir-armd-datacenter-reference-arch/ http://datatracker.ietf.org/doc/draft-karir-armd-statistics/ This draft hasn't been discussed yet due to scope issues. Therefore, they = are suited for DC Interim meeting. http://datatracker.ietf.org/doc/draft-shah-armd-arp-reduction/ Here is another draft in ARMD, which is interesting.=20 http://datatracker.ietf.org/doc/draft-so-armd-vdcs-ar/ Here are a couple of drafts in TRILL targeted for the data center environme= nt: http://datatracker.ietf.org/doc/draft-dunbar-trill-directory-assisted-edge/ http://datatracker.ietf.org/doc/draft-dunbar-trill-directory-assisted-encap= / There will be an ARMD draft on BCP for ARP/ND Scaling for Large Data Center= s to be uploaded soon, which are relevant.=20 Linda Dunbar > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Friday, December 16, 2011 7:15 AM > To: dc@ietf.org > Subject: [dc] Work items for this group >=20 > Joel jaeggli writes: >=20 > > So far it's been an impressively low traffic list for a cross area > > intersection of interests gearing up to discuss documents at an > interim. >=20 > Fair point. >=20 > And with that, I'd like to start with a summary of the potential work > items that might be covered here. By "work items", I'd like to see a > grouping of IDs/presentations into (potential) work areas. The goal > would be to talk about each work area somewhat separately. If we > aren't able to organize work into mostly self-contained areas (i.e., > WGs), we'll never get anywhere. >=20 > So far, the ones I know of include: >=20 > NVO3 > draft-narten-nvo3-overlay-problem-statement-01.txt > SDN > draft-nadeau-sdn-problem-statement-01.txt >=20 > Use Case/Examples: > draft-stiliadis-sdnp-framework-use-cases-01.txt > draft-pan-sdn-bod-problem-statement-and-use-case-01.txt > draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt > draft-mcdysan-sdnp-cloudbursting-usecase-00.txt >=20 > Solutions/Approachs: > draft-nadeau-sdn-framework-01.txt > draft-marques-sdnp-flow-spec-00.txt > VPN4DC > http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 >=20 > http://tools.ietf.org/html/draft-bitar-datacenter-vpn- > applicability-01 > http://tools.ietf.org/html/draft-so-vpn4dc-00 > http://datatracker.ietf.org/doc/draft-so-vdcs-01 > http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 > http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 > http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 > http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis- > 00 > http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >=20 > Are there others? >=20 > Thomas >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From melinda.shore@gmail.com Fri Dec 16 11:42:56 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF93121F8AD1 for ; Fri, 16 Dec 2011 11:42:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9n7iFmRRpcz for ; Fri, 16 Dec 2011 11:42:56 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43D1621F8ACE for ; Fri, 16 Dec 2011 11:42:56 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so1883717vbb.31 for ; Fri, 16 Dec 2011 11:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ypwJOE6eF1j2akdLyWJvsoql2s7uxovLJe3Taxl9jjg=; b=AWcYkkn1zCigEUKYe/2Ip5JakOQrttotIFNRDLTX87frEjGEGdDy3ewvbOhLL+GFO3 TLxYZ4SwAvTYjiorZ+O6fU2YqupyHnRPXeTR8SMPoVJzj1rLrNdKcLIPe+QdDkNg0gJo YOanWr2ZQltUIiYZhmf7PBfMZNpM0CwGNX17g= Received: by 10.52.93.146 with SMTP id cu18mr7386489vdb.56.1324064575841; Fri, 16 Dec 2011 11:42:55 -0800 (PST) Received: from [137.229.12.236] (drake.swits.alaska.edu. [137.229.12.236]) by mx.google.com with ESMTPS id id7sm9980204vdb.21.2011.12.16.11.42.53 (version=SSLv3 cipher=OTHER); Fri, 16 Dec 2011 11:42:55 -0800 (PST) Message-ID: <4EEB9F4B.9000805@gmail.com> Date: Fri, 16 Dec 2011 10:43:07 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Linda Dunbar References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> <4EEB8B9A.7090304@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F61A67AA1D@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F61A67AA1D@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dc@ietf.org" Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 19:42:56 -0000 On 12/16/2011 09:35 AM, Linda Dunbar wrote: > Since there are so much TCP state transition discussed in the middlebox state transfer drafts, would Transport area be a better fit for this? That's what I'm guessing at the moment, esp. since that's where transport-layer middlebox-related work has been performed in the past, but as far as I know nobody's talked with the transport ADs about it yet. I'm shooting to have a new framework document out before the end of the month and maybe it could be used as the basis for discussions with the transport folk. Melinda From lufang@cisco.com Fri Dec 16 11:43:14 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8E611E8093 for ; Fri, 16 Dec 2011 11:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lk4prEh1yk8 for ; Fri, 16 Dec 2011 11:43:13 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 614DB11E8089 for ; Fri, 16 Dec 2011 11:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=4846; q=dns/txt; s=iport; t=1324064593; x=1325274193; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=1JwrFblvHYl0xTqkqPL6CoVqz4KHKzEcyA2pJ7Tu2pM=; b=llzIBUbKxUbNgIN40RaFQqTsH5kltw4fYqiVDdvJu0pTr2L4SFTg/l27 7XY0ZLFg2EhzkUfHHu2TiR4iwq/rnLL85lMp3CAQIzHfO5T5vIsxnw82w uB/nBW7mryb1cWaP5lmhfU0y1UwCCNjI/6aW48w6FTRh842gStn5bM6aJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUAAHue606tJXHB/2dsb2JhbABEmwmQS4EFgXIBAQEDAQEBAQ8BHQo0EAcEAgEIEQEDAQELBhcBBgEmHwMGCAIEARIIEweHWAiZVAGeNYshYwSINJ8N X-IronPort-AV: E=Sophos;i="4.71,364,1320624000"; d="scan'208";a="44670169" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 16 Dec 2011 19:43:13 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pBGJhCL9018966; Fri, 16 Dec 2011 19:43:12 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Dec 2011 13:43:12 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Dec 2011 13:43:10 -0600 Message-ID: <238542D917511A45B6B8AA806E875E2507850D69@XMB-RCD-201.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F61A67AA4F@dfweml505-mbx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Work items for this group Thread-Index: AQHMu/T73M2yuZR6J06DZ8EmnClWQZXey4uwgAAJxuA= References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F61A67AA4F@dfweml505-mbx> From: "Luyuan Fang (lufang)" To: "Linda Dunbar" , "Thomas Narten" , X-OriginalArrivalTime: 16 Dec 2011 19:43:12.0634 (UTC) FILETIME=[F247C5A0:01CCBC2A] Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 19:43:14 -0000 This takes us back to the dc list scope discussion. Regarding ARMD, I thought Benson commended before: "if one wishes to discuss ARMD issues, I suggest using the armd@ietf.org mailing list. But there is much that is out of ARMD's scope, which might be more appropriate for discussion on dc@ietf.org instead." Are you suggesting a different approach? Or these new ARMD drafts are out of scope of ARMD? Same goes with the TRILL drafts... If the scope of the dc list is to cover every topic in ietf related to dc, regardless there is already WG or not, we have several more WGs to pull in, I think we will have scale and focus issues. Luyuan > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Linda Dunbar > Sent: Friday, December 16, 2011 2:01 PM > To: Thomas Narten; dc@ietf.org > Subject: Re: [dc] Work items for this group >=20 > Thomas, >=20 > Thanks for starting the list. > There are several drafts in ARMD for Data Center. The first two drafts > have been discussed at the 82nd IETF meeting in Taipei, therefore might > not need to be discussed again at the DC Interim meeting. But they are > very good documents in describing Data Center general architecture and > address resolution issues in data centers, which people on this mail > list should be interested in. >=20 > http://datatracker.ietf.org/doc/draft-ietf-armd-problem-statement/ > http://datatracker.ietf.org/doc/draft-karir-armd-datacenter-reference- > arch/ > http://datatracker.ietf.org/doc/draft-karir-armd-statistics/ >=20 > This draft hasn't been discussed yet due to scope issues. Therefore, > they are suited for DC Interim meeting. > http://datatracker.ietf.org/doc/draft-shah-armd-arp-reduction/ >=20 > Here is another draft in ARMD, which is interesting. > http://datatracker.ietf.org/doc/draft-so-armd-vdcs-ar/ >=20 >=20 >=20 > Here are a couple of drafts in TRILL targeted for the data center > environment: >=20 > http://datatracker.ietf.org/doc/draft-dunbar-trill-directory-assisted- > edge/ >=20 > http://datatracker.ietf.org/doc/draft-dunbar-trill-directory-assisted- > encap/ >=20 > There will be an ARMD draft on BCP for ARP/ND Scaling for Large Data > Centers to be uploaded soon, which are relevant. >=20 > Linda Dunbar >=20 > > -----Original Message----- > > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > > Thomas Narten > > Sent: Friday, December 16, 2011 7:15 AM > > To: dc@ietf.org > > Subject: [dc] Work items for this group > > > > Joel jaeggli writes: > > > > > So far it's been an impressively low traffic list for a cross area > > > intersection of interests gearing up to discuss documents at an > > interim. > > > > Fair point. > > > > And with that, I'd like to start with a summary of the potential work > > items that might be covered here. By "work items", I'd like to see a > > grouping of IDs/presentations into (potential) work areas. The goal > > would be to talk about each work area somewhat separately. If we > > aren't able to organize work into mostly self-contained areas (i.e., > > WGs), we'll never get anywhere. > > > > So far, the ones I know of include: > > > > NVO3 > > draft-narten-nvo3-overlay-problem-statement-01.txt > > SDN > > draft-nadeau-sdn-problem-statement-01.txt > > > > Use Case/Examples: > > draft-stiliadis-sdnp-framework-use-cases-01.txt > > draft-pan-sdn-bod-problem-statement-and-use-case-01.txt > > draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt > > draft-mcdysan-sdnp-cloudbursting-usecase-00.txt > > > > Solutions/Approachs: > > draft-nadeau-sdn-framework-01.txt > > draft-marques-sdnp-flow-spec-00.txt > > VPN4DC > > http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 > > > > http://tools.ietf.org/html/draft-bitar-datacenter-vpn- > > applicability-01 > > http://tools.ietf.org/html/draft-so-vpn4dc-00 > > http://datatracker.ietf.org/doc/draft-so-vdcs-01 > > http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement- > 00 > > http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 > > http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 > > http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap- > analysis- > > 00 > > http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 > > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 > > > > Are there others? > > > > Thomas > > > > _______________________________________________ > > dc mailing list > > dc@ietf.org > > https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From pthaler@broadcom.com Fri Dec 16 11:44:14 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6C021F8AD3 for ; Fri, 16 Dec 2011 11:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93X9zOyyFHiv for ; Fri, 16 Dec 2011 11:44:13 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id C08B021F8AD1 for ; Fri, 16 Dec 2011 11:44:13 -0800 (PST) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 16 Dec 2011 11:51:29 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR01.corp.ad.broadcom.com ([10.252.49.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Fri, 16 Dec 2011 11:43:59 -0800 From: "Pat Thaler" To: "Thomas Narten" , "dc@ietf.org" Date: Fri, 16 Dec 2011 11:43:58 -0800 Thread-Topic: [dc] Work items for this group Thread-Index: Acy79PP2MzjKjzreTHupFg9CCILwwwANaLpQ Message-ID: References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> In-Reply-To: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62F57ECB5045326173-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 19:44:14 -0000 Not a work item, but would it be helpful to have an overview of the IEEE 80= 2.1 work for Data Center that is in progress or has recently completed? I c= ould put something together if there is an interest. Pat -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Thomas = Narten Sent: Friday, December 16, 2011 5:15 AM To: dc@ietf.org Subject: [dc] Work items for this group Joel jaeggli writes: > So far it's been an impressively low traffic list for a cross area > intersection of interests gearing up to discuss documents at an interim. Fair point. And with that, I'd like to start with a summary of the potential work items that might be covered here. By "work items", I'd like to see a grouping of IDs/presentations into (potential) work areas. The goal would be to talk about each work area somewhat separately. If we aren't able to organize work into mostly self-contained areas (i.e., WGs), we'll never get anywhere. So far, the ones I know of include: NVO3 draft-narten-nvo3-overlay-problem-statement-01.txt SDN draft-nadeau-sdn-problem-statement-01.txt Use Case/Examples:=09 draft-stiliadis-sdnp-framework-use-cases-01.txt draft-pan-sdn-bod-problem-statement-and-use-case-01.txt draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt draft-mcdysan-sdnp-cloudbursting-usecase-00.txt =20 Solutions/Approachs: draft-nadeau-sdn-framework-01.txt draft-marques-sdnp-flow-spec-00.txt VPN4DC http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 http://tools.ietf.org/html/draft-so-vpn4dc-00 http://datatracker.ietf.org/doc/draft-so-vdcs-01 http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Are there others? Thomas _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From ning.so@verizon.com Fri Dec 16 11:55:45 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B84F11E8094 for ; Fri, 16 Dec 2011 11:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU-XTQdYZW48 for ; Fri, 16 Dec 2011 11:55:44 -0800 (PST) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7413711E8089 for ; Fri, 16 Dec 2011 11:55:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe03.verizon.com with ESMTP; 16 Dec 2011 19:55:43 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.71,365,1320624000"; d="scan'208";a="194587644" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 16 Dec 2011 19:55:42 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.26]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Fri, 16 Dec 2011 14:55:42 -0500 To: Thomas Narten , "dc@ietf.org" Date: Fri, 16 Dec 2011 14:55:41 -0500 Thread-Topic: [dc] Work items for this group Thread-Index: Acy79PoCNdmkHfhNTN6MDuQ4SSVkeQANMH4A Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC0925A792F@FHDP1LUMXC7V41.us.one.verizon.com> References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> In-Reply-To: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 19:55:45 -0000 Thomas and all, Here are some additional drafts related to VPN4DC that you did not include = in your list. http://datatracker.ietf.org/doc/draft-karavettil-vdcs-security-framework/ http://datatracker.ietf.org/doc/draft-so-armd-vdcs-ar/ Additional DC/Cloud related drafts I am aware of that cannot be categorized= into the 3 initiatives (NVO3, SDN, VPN4DC). 1.http://datatracker.ietf.org/doc/draft-junsheng-opsawg-virtual-resource-ma= nagement/ 2. http://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-manag= ement/ 3. http://datatracker.ietf.org/doc/draft-okita-ops-vnetmodel/ 4. http://datatracker.ietf.org/doc/draft-shima-clouds-net-portability-reqs-= and-models/ 5. http://datatracker.ietf.org/doc/draft-shao-opsawg-cloud-service-broker/ 6. http://datatracker.ietf.org/doc/draft-ko-dvn-problem-statement/ 7. http://datatracker.ietf.org/doc/draft-golovinsky-cloud-services-log-form= at/ 8. http://datatracker.ietf.org/doc/draft-gu-opsawg-policies-migration-solut= ion-survey/ 9. http://tools.ietf.org/id/draft-gu-opsa-policies-migration-00.txt 10. http://datatracker.ietf.org/doc/draft-khasnabish-cloud-industry-workite= ms-survey/ 11. http://datatracker.ietf.org/doc/draft-khasnabish-cloud-sdo-survey/ 12. http://datatracker.ietf.org/doc/draft-khasnabish-cloud-reference-framew= ork/ 13. http://datatracker.ietf.org/doc/draft-karavettil-vdcs-security-framewor= k/ I am sure I have miss many more drafts.=20 With this many drafts going all different directions, and having consolidat= ed discussion on one mailing list, I am afraid we will be taking right pass= each other. =20 =A0 Best regards, =A0 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =A0 -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Thomas = Narten Sent: Friday, December 16, 2011 7:15 AM To: dc@ietf.org Subject: [dc] Work items for this group Joel jaeggli writes: > So far it's been an impressively low traffic list for a cross area=20 > intersection of interests gearing up to discuss documents at an interim. Fair point. And with that, I'd like to start with a summary of the potential work items= that might be covered here. By "work items", I'd like to see a grouping of= IDs/presentations into (potential) work areas. The goal would be to talk a= bout each work area somewhat separately. If we aren't able to organize work= into mostly self-contained areas (i.e., WGs), we'll never get anywhere. So far, the ones I know of include: NVO3 draft-narten-nvo3-overlay-problem-statement-01.txt SDN draft-nadeau-sdn-problem-statement-01.txt Use Case/Examples:=09 draft-stiliadis-sdnp-framework-use-cases-01.txt draft-pan-sdn-bod-problem-statement-and-use-case-01.txt draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt draft-mcdysan-sdnp-cloudbursting-usecase-00.txt =20 Solutions/Approachs: draft-nadeau-sdn-framework-01.txt draft-marques-sdnp-flow-spec-00.txt VPN4DC http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 http://tools.ietf.org/html/draft-so-vpn4dc-00 http://datatracker.ietf.org/doc/draft-so-vdcs-01 http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Are there others? Thomas _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From dimitri.stiliadis@alcatel-lucent.com Fri Dec 16 12:02:08 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF3E11E80A6 for ; Fri, 16 Dec 2011 12:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwK3B4MYMf0B for ; Fri, 16 Dec 2011 12:02:08 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id EA1581F0C4B for ; Fri, 16 Dec 2011 12:01:56 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pBGK1tUO008210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2011 14:01:55 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBGK1tsr011077 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Dec 2011 14:01:55 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 16 Dec 2011 14:01:55 -0600 From: "Stiliadis, Dimitrios (Dimitri)" To: Thomas Narten , "dc@ietf.org" Date: Fri, 16 Dec 2011 14:01:52 -0600 Thread-Topic: [dc] Work items for this group Thread-Index: Acy79PBePb+MhQZ5TPSsIDsVWqvi7gAOEo6Q Message-ID: References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> In-Reply-To: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 20:02:08 -0000 Is the whole SDN area in "scope" for the dc discussion?=20 One could argue that the DC is one use case of the SDN scope, but I think=20 SDN is much broader than this, with plenty non-DC driven use cases. Dimitri =A0=20 > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Friday, December 16, 2011 5:15 AM > To: dc@ietf.org > Subject: [dc] Work items for this group >=20 > Joel jaeggli writes: >=20 > > So far it's been an impressively low traffic list for a cross area > > intersection of interests gearing up to discuss documents at an > interim. >=20 > Fair point. >=20 > And with that, I'd like to start with a summary of the potential work > items that might be covered here. By "work items", I'd like to see a > grouping of IDs/presentations into (potential) work areas. The goal > would be to talk about each work area somewhat separately. If we > aren't able to organize work into mostly self-contained areas (i.e., > WGs), we'll never get anywhere. >=20 > So far, the ones I know of include: >=20 > NVO3 > draft-narten-nvo3-overlay-problem-statement-01.txt > SDN > draft-nadeau-sdn-problem-statement-01.txt >=20 > Use Case/Examples: > draft-stiliadis-sdnp-framework-use-cases-01.txt > draft-pan-sdn-bod-problem-statement-and-use-case-01.txt > draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt > draft-mcdysan-sdnp-cloudbursting-usecase-00.txt >=20 > Solutions/Approachs: > draft-nadeau-sdn-framework-01.txt > draft-marques-sdnp-flow-spec-00.txt > VPN4DC > http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 >=20 > http://tools.ietf.org/html/draft-bitar-datacenter-vpn- > applicability-01 > http://tools.ietf.org/html/draft-so-vpn4dc-00 > http://datatracker.ietf.org/doc/draft-so-vdcs-01 > http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 > http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 > http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 > http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis- > 00 > http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >=20 > Are there others? >=20 > Thomas >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From linda.dunbar@huawei.com Fri Dec 16 12:02:19 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABAF1F0C4B for ; Fri, 16 Dec 2011 12:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTMGKPfm2ApT for ; Fri, 16 Dec 2011 12:02:18 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9A421F8AF5 for ; Fri, 16 Dec 2011 12:02:16 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABW43214; Fri, 16 Dec 2011 15:02:15 -0500 (EST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Dec 2011 11:59:53 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Fri, 16 Dec 2011 11:59:48 -0800 From: Linda Dunbar To: Pat Thaler , Thomas Narten , "dc@ietf.org" Thread-Topic: [dc] Work items for this group Thread-Index: AQHMu/T73M2yuZR6J06DZ8EmnClWQZXfZEwA//9+Q9A= Date: Fri, 16 Dec 2011 19:59:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F61A67AB96@dfweml505-mbx> References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 20:02:19 -0000 Very good suggestion.=20 Linda > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Pat > Thaler > Sent: Friday, December 16, 2011 1:44 PM > To: Thomas Narten; dc@ietf.org > Subject: Re: [dc] Work items for this group >=20 > Not a work item, but would it be helpful to have an overview of the > IEEE 802.1 work for Data Center that is in progress or has recently > completed? I could put something together if there is an interest. >=20 > Pat >=20 > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Friday, December 16, 2011 5:15 AM > To: dc@ietf.org > Subject: [dc] Work items for this group >=20 > Joel jaeggli writes: >=20 > > So far it's been an impressively low traffic list for a cross area > > intersection of interests gearing up to discuss documents at an > interim. >=20 > Fair point. >=20 > And with that, I'd like to start with a summary of the potential work > items that might be covered here. By "work items", I'd like to see a > grouping of IDs/presentations into (potential) work areas. The goal > would be to talk about each work area somewhat separately. If we > aren't able to organize work into mostly self-contained areas (i.e., > WGs), we'll never get anywhere. >=20 > So far, the ones I know of include: >=20 > NVO3 > draft-narten-nvo3-overlay-problem-statement-01.txt > SDN > draft-nadeau-sdn-problem-statement-01.txt >=20 > Use Case/Examples: > draft-stiliadis-sdnp-framework-use-cases-01.txt > draft-pan-sdn-bod-problem-statement-and-use-case-01.txt > draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt > draft-mcdysan-sdnp-cloudbursting-usecase-00.txt >=20 > Solutions/Approachs: > draft-nadeau-sdn-framework-01.txt > draft-marques-sdnp-flow-spec-00.txt > VPN4DC > http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 >=20 > http://tools.ietf.org/html/draft-bitar-datacenter-vpn- > applicability-01 > http://tools.ietf.org/html/draft-so-vpn4dc-00 > http://datatracker.ietf.org/doc/draft-so-vdcs-01 > http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 > http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 > http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 > http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis- > 00 > http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >=20 > Are there others? >=20 > Thomas >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc >=20 >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From linda.dunbar@huawei.com Fri Dec 16 12:10:51 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145081F0C55 for ; Fri, 16 Dec 2011 12:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LBbW6vPVqvN for ; Fri, 16 Dec 2011 12:10:49 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAA71F0C53 for ; Fri, 16 Dec 2011 12:10:44 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABW43648; Fri, 16 Dec 2011 15:10:33 -0500 (EST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Dec 2011 12:08:59 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Fri, 16 Dec 2011 12:09:03 -0800 From: Linda Dunbar To: "Luyuan Fang (lufang)" , Thomas Narten , "dc@ietf.org" Thread-Topic: [dc] Work items for this group Thread-Index: AQHMu/T73M2yuZR6J06DZ8EmnClWQZXey4uwgAAJxuCAAAvNcA== Date: Fri, 16 Dec 2011 20:09:03 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F61A67ABEA@dfweml505-mbx> References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F61A67AA4F@dfweml505-mbx> <238542D917511A45B6B8AA806E875E2507850D69@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E2507850D69@XMB-RCD-201.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 20:10:51 -0000 LuYuan,=20 =20 I said that " .. might not need to be discussed again at the DC Interim mee= ting. But they are very good documents in describing Data Center general ar= chitecture and address resolution issues in data centers, which people on t= his mail list should be interested in" Having said this, if this DC Interim meeting is intended for IETF across ar= ea discussion on Data Center networking, it might worth the time to bring u= p all data center related work in various IETF WGs. For example, the Mobile= IP technologies which allow mobile devices to move anywhere can be valuabl= e to data center network to allow VMs to be placed anywhere. I assume it is up to ADs to decide what to be discussed at this DC Interim = meeting when there are too many contributions.=20 Linda =20 > -----Original Message----- > From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > Sent: Friday, December 16, 2011 1:43 PM > To: Linda Dunbar; Thomas Narten; dc@ietf.org > Subject: RE: [dc] Work items for this group >=20 > This takes us back to the dc list scope discussion. >=20 > Regarding ARMD, I thought Benson commended before: "if one wishes to > discuss ARMD issues, I suggest using the armd@ietf.org mailing list. > But > there is much that is out of ARMD's scope, which might be more > appropriate for discussion on dc@ietf.org instead." >=20 > Are you suggesting a different approach? Or these new ARMD drafts are > out of scope of ARMD? > Same goes with the TRILL drafts... >=20 > If the scope of the dc list is to cover every topic in ietf related to > dc, regardless there is already WG or not, we have several more WGs to > pull in, I think we will have scale and focus issues. >=20 > Luyuan >=20 > > -----Original Message----- > > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > > Linda Dunbar > > Sent: Friday, December 16, 2011 2:01 PM > > To: Thomas Narten; dc@ietf.org > > Subject: Re: [dc] Work items for this group > > > > Thomas, > > > > Thanks for starting the list. > > There are several drafts in ARMD for Data Center. The first two > drafts > > have been discussed at the 82nd IETF meeting in Taipei, therefore > might > > not need to be discussed again at the DC Interim meeting. But they > are > > very good documents in describing Data Center general architecture > and > > address resolution issues in data centers, which people on this mail > > list should be interested in. > > > > http://datatracker.ietf.org/doc/draft-ietf-armd-problem-statement/ > > http://datatracker.ietf.org/doc/draft-karir-armd-datacenter- > reference- > > arch/ > > http://datatracker.ietf.org/doc/draft-karir-armd-statistics/ > > > > This draft hasn't been discussed yet due to scope issues. Therefore, > > they are suited for DC Interim meeting. > > http://datatracker.ietf.org/doc/draft-shah-armd-arp-reduction/ > > > > Here is another draft in ARMD, which is interesting. > > http://datatracker.ietf.org/doc/draft-so-armd-vdcs-ar/ > > > > > > > > Here are a couple of drafts in TRILL targeted for the data center > > environment: > > > > http://datatracker.ietf.org/doc/draft-dunbar-trill-directory- > assisted- > > edge/ > > > > http://datatracker.ietf.org/doc/draft-dunbar-trill-directory- > assisted- > > encap/ > > > > There will be an ARMD draft on BCP for ARP/ND Scaling for Large Data > > Centers to be uploaded soon, which are relevant. > > > > Linda Dunbar > > > > > -----Original Message----- > > > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > > > Thomas Narten > > > Sent: Friday, December 16, 2011 7:15 AM > > > To: dc@ietf.org > > > Subject: [dc] Work items for this group > > > > > > Joel jaeggli writes: > > > > > > > So far it's been an impressively low traffic list for a cross > area > > > > intersection of interests gearing up to discuss documents at an > > > interim. > > > > > > Fair point. > > > > > > And with that, I'd like to start with a summary of the potential > work > > > items that might be covered here. By "work items", I'd like to see > a > > > grouping of IDs/presentations into (potential) work areas. The goal > > > would be to talk about each work area somewhat separately. If we > > > aren't able to organize work into mostly self-contained areas (i.e., > > > WGs), we'll never get anywhere. > > > > > > So far, the ones I know of include: > > > > > > NVO3 > > > draft-narten-nvo3-overlay-problem-statement-01.txt > > > SDN > > > draft-nadeau-sdn-problem-statement-01.txt > > > > > > Use Case/Examples: > > > draft-stiliadis-sdnp-framework-use-cases-01.txt > > > draft-pan-sdn-bod-problem-statement-and-use-case-01.txt > > > draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt > > > draft-mcdysan-sdnp-cloudbursting-usecase-00.txt > > > > > > Solutions/Approachs: > > > draft-nadeau-sdn-framework-01.txt > > > draft-marques-sdnp-flow-spec-00.txt > > > VPN4DC > > > > http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 > > > > > > http://tools.ietf.org/html/draft-bitar-datacenter-vpn- > > > applicability-01 > > > http://tools.ietf.org/html/draft-so-vpn4dc-00 > > > http://datatracker.ietf.org/doc/draft-so-vdcs-01 > > > > http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement- > > 00 > > > http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 > > > > http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 > > > http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap- > > analysis- > > > 00 > > > http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution- > 00 > > > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 > > > > > > Are there others? > > > > > > Thomas > > > > > > _______________________________________________ > > > dc mailing list > > > dc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dc > > _______________________________________________ > > dc mailing list > > dc@ietf.org > > https://www.ietf.org/mailman/listinfo/dc From linda.dunbar@huawei.com Fri Dec 16 12:11:23 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFFA1F0C5B for ; Fri, 16 Dec 2011 12:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wrut4nePw8+x for ; Fri, 16 Dec 2011 12:11:22 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A55F31F0C53 for ; Fri, 16 Dec 2011 12:11:22 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABP45105; Fri, 16 Dec 2011 15:11:22 -0500 (EST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Dec 2011 12:09:44 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Fri, 16 Dec 2011 12:09:49 -0800 From: Linda Dunbar To: "Stiliadis, Dimitrios (Dimitri)" , Thomas Narten , "dc@ietf.org" Thread-Topic: [dc] Work items for this group Thread-Index: AQHMu/T73M2yuZR6J06DZ8EmnClWQZXfaU0A//97+OA= Date: Fri, 16 Dec 2011 20:09:47 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F61A67ABFB@dfweml505-mbx> References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 20:11:23 -0000 I completely agree that SDN is much more broader than DC.=20 Linda > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Stiliadis, Dimitrios (Dimitri) > Sent: Friday, December 16, 2011 2:02 PM > To: Thomas Narten; dc@ietf.org > Subject: Re: [dc] Work items for this group >=20 > Is the whole SDN area in "scope" for the dc discussion? >=20 > One could argue that the DC is one use case of the SDN scope, but I > think > SDN is much broader than this, with plenty non-DC driven use cases. >=20 > Dimitri >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > > Thomas Narten > > Sent: Friday, December 16, 2011 5:15 AM > > To: dc@ietf.org > > Subject: [dc] Work items for this group > > > > Joel jaeggli writes: > > > > > So far it's been an impressively low traffic list for a cross area > > > intersection of interests gearing up to discuss documents at an > > interim. > > > > Fair point. > > > > And with that, I'd like to start with a summary of the potential work > > items that might be covered here. By "work items", I'd like to see a > > grouping of IDs/presentations into (potential) work areas. The goal > > would be to talk about each work area somewhat separately. If we > > aren't able to organize work into mostly self-contained areas (i.e., > > WGs), we'll never get anywhere. > > > > So far, the ones I know of include: > > > > NVO3 > > draft-narten-nvo3-overlay-problem-statement-01.txt > > SDN > > draft-nadeau-sdn-problem-statement-01.txt > > > > Use Case/Examples: > > draft-stiliadis-sdnp-framework-use-cases-01.txt > > draft-pan-sdn-bod-problem-statement-and-use-case-01.txt > > draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt > > draft-mcdysan-sdnp-cloudbursting-usecase-00.txt > > > > Solutions/Approachs: > > draft-nadeau-sdn-framework-01.txt > > draft-marques-sdnp-flow-spec-00.txt > > VPN4DC > > http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 > > > > http://tools.ietf.org/html/draft-bitar-datacenter-vpn- > > applicability-01 > > http://tools.ietf.org/html/draft-so-vpn4dc-00 > > http://datatracker.ietf.org/doc/draft-so-vdcs-01 > > http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement- > 00 > > http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 > > http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 > > http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap- > analysis- > > 00 > > http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 > > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 > > > > Are there others? > > > > Thomas > > > > _______________________________________________ > > dc mailing list > > dc@ietf.org > > https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From narten@us.ibm.com Fri Dec 16 12:12:32 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EF41F0C5B for ; Fri, 16 Dec 2011 12:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6anaUtrS0ifR for ; Fri, 16 Dec 2011 12:12:31 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by ietfa.amsl.com (Postfix) with ESMTP id 27A6D1F0C53 for ; Fri, 16 Dec 2011 12:12:31 -0800 (PST) Received: from /spool/local by e1.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 16 Dec 2011 15:12:29 -0500 Received: from d01relay05.pok.ibm.com (9.56.227.237) by e1.ny.us.ibm.com (192.168.1.101) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 16 Dec 2011 15:07:58 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBGK7iXb236778 for ; Fri, 16 Dec 2011 15:07:44 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBGK7iWM005973 for ; Fri, 16 Dec 2011 18:07:44 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-65-208-228.mts.ibm.com [9.65.208.228]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBGK7hN9005933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Dec 2011 18:07:44 -0200 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pBGK7gxw006973 for ; Fri, 16 Dec 2011 15:07:43 -0500 Message-Id: <201112162007.pBGK7gxw006973@cichlid.raleigh.ibm.com> To: dc@ietf.org In-reply-to: <4EEB8B9A.7090304@gmail.com> References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> <4EEB8B9A.7090304@gmail.com> Comments: In-reply-to Melinda Shore message dated "Fri, 16 Dec 2011 09:19:06 -0900." Date: Fri, 16 Dec 2011 15:07:42 -0500 From: Thomas Narten x-cbid: 11121620-6078-0000-0000-000005B30D8F Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 20:12:32 -0000 Responding to a bunch of messages... As always, I think we should focus on *problems* here. This effort (I assume) is about starting new work and figuring out where to do it. If work already has a home, we should be aware of it, but there is presumably no reason for us to discuss it here. This includes documents that are not formal WG documents, but clearly relate to an existing WG. Melinda Shore writes: > There's the stuff on middlebox state transfer. Are you referring to sami, or something else? Can we get a draft list? And/or pointers to recent WG sessions/presentations? And if this is about TCP state transfer, then I would think TSV is the right place to start, not here. Linda Dunbar writes: > There are several drafts in ARMD for Data Center. Following up on Benson's original point, I think we should only be talking about documents/problems that do not already have a home elsewhere. Which ARMD-related documents do not have a home in ARMD? And why not? Ditto for the Trill documents (which I assume belong in Trill and not here) Finally, there are way too many drafts already. What we absolutely need to do is: 1) organize around problem themes. 2) drill down on the problem. And it is not reasonable to ask anyone to read all the drafts in this space... That is part of the problem... With so many potential drafts, its hard to get a big picture. But we need to understand the bigger picture in order to figure out how to divide the problem space... Thus, again, being able to articulate a problem statement in a few paragraphs in clear language will be worth a lot of gold in this group. Thomas From lufang@cisco.com Fri Dec 16 12:36:22 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F2511E809F for ; Fri, 16 Dec 2011 12:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppEyGulxVXnf for ; Fri, 16 Dec 2011 12:36:21 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5778611E8089 for ; Fri, 16 Dec 2011 12:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=2449; q=dns/txt; s=iport; t=1324067781; x=1325277381; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=A1PAYeAw3izRJSXrgi33EqIhW0tozYYo//ViO+pXoQg=; b=k9ywEr1PwT6gs64f+fbbUzB1HOVGnb/GlQYxnU/2XseoYMVBhb/VMgKL kTm85RHejMFWO3KbF2N4L7m2RHeX0VeTJ9Or39kurqpWH/NpXOnCFJEle vecJx4mHGDb897keuS5VaO/YEAfuz0GufXNX1MFQTmB7HnLsxQj8aI9W3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUAABur606tJXHB/2dsb2JhbABEmwqQS4EFgXIBAQEDAQEBAQ8BHQo0EAcEAgEIEQQBAQsGFwEGASAGHwkIAQEEAQkJCBqHWAiZWwGeMASLIWMEiDSXL4de X-IronPort-AV: E=Sophos;i="4.71,365,1320624000"; d="scan'208";a="44694031" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 16 Dec 2011 20:36:21 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pBGKaKac023530; Fri, 16 Dec 2011 20:36:20 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Dec 2011 14:36:20 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Dec 2011 14:36:17 -0600 Message-ID: <238542D917511A45B6B8AA806E875E2507850DAB@XMB-RCD-201.cisco.com> In-Reply-To: <201112162007.pBGK7gxw006973@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Work items for this group Thread-Index: Acy8Lw2YsfPvXMvLQfGvSKbZFeODzwAACVNA References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com><4EEB8B9A.7090304@gmail.com> <201112162007.pBGK7gxw006973@cichlid.raleigh.ibm.com> From: "Luyuan Fang (lufang)" To: "Thomas Narten" , X-OriginalArrivalTime: 16 Dec 2011 20:36:20.0720 (UTC) FILETIME=[5E871700:01CCBC32] Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 20:36:22 -0000 Very much agree. The focus here should be the problem space the right home for the items have no home yet. I think the general DC strategy discussion is also important.=20 > If work already has a home, we should be aware of it, but there is presumably no reason for us to discuss it here. Yep, agree. Luyuan > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Friday, December 16, 2011 3:08 PM > To: dc@ietf.org > Subject: Re: [dc] Work items for this group >=20 > Responding to a bunch of messages... >=20 > As always, I think we should focus on *problems* here. This effort (I > assume) is about starting new work and figuring out where to do it. >=20 >=20 > This includes documents that are not formal WG documents, but clearly > relate to an existing WG. >=20 > Melinda Shore writes: >=20 > > There's the stuff on middlebox state transfer. >=20 > Are you referring to sami, or something else? Can we get a draft list? > And/or pointers to recent WG sessions/presentations? >=20 > And if this is about TCP state transfer, then I would think TSV is the > right place to start, not here. >=20 > Linda Dunbar writes: >=20 > > There are several drafts in ARMD for Data Center. >=20 > Following up on Benson's original point, I think we should only be > talking about documents/problems that do not already have a home > elsewhere. >=20 > Which ARMD-related documents do not have a home in ARMD? And why not? >=20 > Ditto for the Trill documents (which I assume belong in Trill and not > here) >=20 > Finally, there are way too many drafts already. >=20 > What we absolutely need to do is: >=20 > 1) organize around problem themes. >=20 > 2) drill down on the problem. >=20 > And it is not reasonable to ask anyone to read all the drafts in this > space... That is part of the problem... With so many potential drafts, > its hard to get a big picture. But we need to understand the bigger > picture in order to figure out how to divide the problem space... >=20 > Thus, again, being able to articulate a problem statement in a few > paragraphs in clear language will be worth a lot of gold in this > group. >=20 > Thomas >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From lufang@cisco.com Fri Dec 16 13:15:57 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082471F0C6A for ; Fri, 16 Dec 2011 13:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKlElov2IK0E for ; Fri, 16 Dec 2011 13:15:56 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4D05321F8495 for ; Fri, 16 Dec 2011 13:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=4159; q=dns/txt; s=iport; t=1324070156; x=1325279756; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=WJvZXQWdeCRp0n3Nchk/sDkA0fY5P78vZrpcN+mIBkw=; b=M+eKgA9PXciZY9OdveNqoMu6jPjwb8m000k5OPubDmf5mAUDhFqI+OKs DeLjQPenRRan11OZ/vfYxoPqieK5mMUwIcU6L8UMpW3Efc4Vj9qauQuWX GH8AxhrxmkqZostouPOAo4b1sS3UcarXkG2FNV/5pvegbqbgF5Stosa0+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUAALK0606tJXG+/2dsb2JhbABEmwqQS4EFgXIBAQEEAQEBDwEdCjQXBAIBCBEBAwEBCwYXAQYBJh8DBggCBAESCBMHh2CZZgGeM4shYwSINJ8N X-IronPort-AV: E=Sophos;i="4.71,365,1320624000"; d="scan'208";a="44691227" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 16 Dec 2011 21:15:56 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBGLFtXE014925; Fri, 16 Dec 2011 21:15:55 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Dec 2011 15:15:55 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Dec 2011 15:15:53 -0600 Message-ID: <238542D917511A45B6B8AA806E875E2507850DE4@XMB-RCD-201.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F61A67ABFB@dfweml505-mbx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Work items for this group Thread-Index: AQHMu/T73M2yuZR6J06DZ8EmnClWQZXfaU0A//97+OCAAA27EA== References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F61A67ABFB@dfweml505-mbx> From: "Luyuan Fang (lufang)" To: "Linda Dunbar" , "Stiliadis, Dimitrios (Dimitri)" , "Thomas Narten" , X-OriginalArrivalTime: 16 Dec 2011 21:15:55.0752 (UTC) FILETIME=[E6283680:01CCBC37] Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 21:15:57 -0000 Yes, Dimitri brought up a good point. It seems to me only dc use case for SDN is relevant to the dc list.=20 The question would be where the SDN general architecture discussion is homed, I'm assume the current SDN list? Or may be AD would set a new ietf SDN list? If the entire SDN is on the dc list, that would need to change the dc list scope far beyond dc. The interim meeting would be a good place to discuss these. Luyuan > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Linda Dunbar > Sent: Friday, December 16, 2011 3:10 PM > To: Stiliadis, Dimitrios (Dimitri); Thomas Narten; dc@ietf.org > Subject: Re: [dc] Work items for this group >=20 > I completely agree that SDN is much more broader than DC. >=20 > Linda >=20 > > -----Original Message----- > > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > > Stiliadis, Dimitrios (Dimitri) > > Sent: Friday, December 16, 2011 2:02 PM > > To: Thomas Narten; dc@ietf.org > > Subject: Re: [dc] Work items for this group > > > > Is the whole SDN area in "scope" for the dc discussion? > > > > One could argue that the DC is one use case of the SDN scope, but I > > think > > SDN is much broader than this, with plenty non-DC driven use cases. > > > > Dimitri > > > > > > > > > > > > > > > -----Original Message----- > > > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > > > Thomas Narten > > > Sent: Friday, December 16, 2011 5:15 AM > > > To: dc@ietf.org > > > Subject: [dc] Work items for this group > > > > > > Joel jaeggli writes: > > > > > > > So far it's been an impressively low traffic list for a cross > area > > > > intersection of interests gearing up to discuss documents at an > > > interim. > > > > > > Fair point. > > > > > > And with that, I'd like to start with a summary of the potential > work > > > items that might be covered here. By "work items", I'd like to see > a > > > grouping of IDs/presentations into (potential) work areas. The goal > > > would be to talk about each work area somewhat separately. If we > > > aren't able to organize work into mostly self-contained areas > (i.e., > > > WGs), we'll never get anywhere. > > > > > > So far, the ones I know of include: > > > > > > NVO3 > > > draft-narten-nvo3-overlay-problem-statement-01.txt > > > SDN > > > draft-nadeau-sdn-problem-statement-01.txt > > > > > > Use Case/Examples: > > > draft-stiliadis-sdnp-framework-use-cases-01.txt > > > draft-pan-sdn-bod-problem-statement-and-use-case-01.txt > > > draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt > > > draft-mcdysan-sdnp-cloudbursting-usecase-00.txt > > > > > > Solutions/Approachs: > > > draft-nadeau-sdn-framework-01.txt > > > draft-marques-sdnp-flow-spec-00.txt > > > VPN4DC > > > http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement- > 00 > > > > > > http://tools.ietf.org/html/draft-bitar-datacenter-vpn- > > > applicability-01 > > > http://tools.ietf.org/html/draft-so-vpn4dc-00 > > > http://datatracker.ietf.org/doc/draft-so-vdcs-01 > > > http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem- > statement- > > 00 > > > http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 > > > http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect- > 00 > > > http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap- > > analysis- > > > 00 > > > http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution- > 00 > > > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 > > > > > > Are there others? > > > > > > Thomas > > > > > > _______________________________________________ > > > dc mailing list > > > dc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dc > > _______________________________________________ > > dc mailing list > > dc@ietf.org > > https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From manumala@force10networks.com Fri Dec 16 12:11:32 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3B81F0C65 for ; Fri, 16 Dec 2011 12:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpwDYK71s2s4 for ; Fri, 16 Dec 2011 12:11:32 -0800 (PST) Received: from mx.force10networks.com (corp.force10networks.com [64.186.164.204]) by ietfa.amsl.com (Postfix) with ESMTP id 335651F0C53 for ; Fri, 16 Dec 2011 12:11:32 -0800 (PST) Received: from EX07-SJC-MBX1.force10networks.com ([fe80:0000:0000:0000:e980:0ee4:72.36.142.28]) by exch7-sjc-fe.force10networks.com ([10.11.0.87]) with mapi; Fri, 16 Dec 2011 12:11:28 -0800 From: Mohnish Anumala To: Pat Thaler , "dc@ietf.org" Date: Fri, 16 Dec 2011 12:11:26 -0800 Thread-Topic: [dc] Work items for this group Thread-Index: Acy79PP2MzjKjzreTHupFg9CCILwwwANaLpQAAEMwSA= Message-ID: References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 17 Dec 2011 07:08:53 -0800 Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 20:11:32 -0000 That will be great. Thanks, --Mohnish -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Pat Tha= ler Sent: Friday, December 16, 2011 11:44 AM To: Thomas Narten; dc@ietf.org Subject: Re: [dc] Work items for this group Not a work item, but would it be helpful to have an overview of the IEEE 80= 2.1 work for Data Center that is in progress or has recently completed? I c= ould put something together if there is an interest. Pat -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Thomas = Narten Sent: Friday, December 16, 2011 5:15 AM To: dc@ietf.org Subject: [dc] Work items for this group Joel jaeggli writes: > So far it's been an impressively low traffic list for a cross area > intersection of interests gearing up to discuss documents at an interim. Fair point. And with that, I'd like to start with a summary of the potential work items that might be covered here. By "work items", I'd like to see a grouping of IDs/presentations into (potential) work areas. The goal would be to talk about each work area somewhat separately. If we aren't able to organize work into mostly self-contained areas (i.e., WGs), we'll never get anywhere. So far, the ones I know of include: NVO3 draft-narten-nvo3-overlay-problem-statement-01.txt SDN draft-nadeau-sdn-problem-statement-01.txt Use Case/Examples:=09 draft-stiliadis-sdnp-framework-use-cases-01.txt draft-pan-sdn-bod-problem-statement-and-use-case-01.txt draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt draft-mcdysan-sdnp-cloudbursting-usecase-00.txt =20 Solutions/Approachs: draft-nadeau-sdn-framework-01.txt draft-marques-sdnp-flow-spec-00.txt VPN4DC http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 http://tools.ietf.org/html/draft-so-vpn4dc-00 http://datatracker.ietf.org/doc/draft-so-vdcs-01 http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Are there others? Thomas _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From radiatel2004@yahoo.fr Sat Dec 17 06:33:00 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A559921F8B1E for ; Sat, 17 Dec 2011 06:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.053 X-Spam-Level: * X-Spam-Status: No, score=1.053 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNnyQJZpLxgJ for ; Sat, 17 Dec 2011 06:33:00 -0800 (PST) Received: from nm20-vm0.bullet.mail.ukl.yahoo.com (nm20-vm0.bullet.mail.ukl.yahoo.com [217.146.183.115]) by ietfa.amsl.com (Postfix) with SMTP id DFCCC21F8B1D for ; Sat, 17 Dec 2011 06:32:59 -0800 (PST) Received: from [217.146.183.182] by nm20.bullet.mail.ukl.yahoo.com with NNFMP; 17 Dec 2011 14:32:54 -0000 Received: from [217.146.183.61] by tm13.bullet.mail.ukl.yahoo.com with NNFMP; 17 Dec 2011 14:32:54 -0000 Received: from [127.0.0.1] by omp1030.mail.ukl.yahoo.com with NNFMP; 17 Dec 2011 14:32:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 643383.3391.bm@omp1030.mail.ukl.yahoo.com Received: (qmail 33177 invoked by uid 60001); 17 Dec 2011 14:32:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1324132374; bh=I0qR11MUDl+PMLTqgjaxdhP5DqBaWt040lZgvUUEpnI=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=dKsSl2j1rgs++p17u6sv075p/VLQSa+p06xTn2eHIBOZIrsZQHJvxNou+FAYLZh3TSnS76q3H1QitCQuO3fKZSFXJAY8pDPvWrhfRp9fGShMXa/CyS1N7nQEkxV9+Fi+5SWVrveeiWS7g0tGgifgxQz8QNPy0YjdFk4GCJuNEBw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=L6OXoGNz0Gm8p+ibN7QfDLbeBUUHXI43ETpjYN8cZbyopsNG0Pybt2dvlch0F0SsUZBDt6YBWqbbuRcco0a1sWToQI6SfzzE5yi3umLsGMg2CsRhdN2R5Cro4IkmasrnrCR+YEK/TL0ViM9Uu8/sfahK44ausRj6KmKI5fU4MwE=; X-YMail-OSG: N4l8YJUVM1k6MlcT5N2bZ0WLHfyNKROivXdjgUrQsAoLKIP _AVjq3DGYArHoGyQFRzwPlJuMjHW6xanJ4AhVLGCdIAhy8QqvYQ5RaW6UqNC GW42VjHQu.sN7i09RBTxYjx1Zy_OsFX28XW.lSO9rkWH0WEzYHKK_o4FFb.9 N8p7q9ZR38Cab7arbxoK2jC84ccbiE2qalqS1JIN78Ece.X3QMC3Cw7KGbO4 V_5qkF5HiW6Dx3Jo4vXHQ_DHnXZ_F6uWmiE2_A9NC4UwQV0cwV8HIx9D8bSt PQDfIJuOcrjwojPRS2ish9RD2uuz5TFmYs_VDvdTA_VgIYX5IhClnqexQPAt Sed_Rhmo2ONzh0euXPfR2tJubHTl3oMBgGYV6f76bjO4u5Zo- Received: from [41.96.59.173] by web27103.mail.ukl.yahoo.com via HTTP; Sat, 17 Dec 2011 14:32:54 GMT X-Mailer: YahooMailWebService/0.8.115.331698 Message-ID: <1324132374.32639.YahooMailNeo@web27103.mail.ukl.yahoo.com> Date: Sat, 17 Dec 2011 14:32:54 +0000 (GMT) From: radia boukari To: "dc@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1663360971-2103557325-1324132374=:32639" X-Mailman-Approved-At: Sat, 17 Dec 2011 07:08:53 -0800 Subject: [dc] volunteer X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: radia boukari List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 14:33:00 -0000 --1663360971-2103557325-1324132374=:32639 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello=0AI am new I would like to know what do I have to do to get envolved = .=0Athank you=A0=0ABest regards --1663360971-2103557325-1324132374=:32639 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello
= I am new I would like to know what do I have to do to get envolved .
<= div>thank you 
Best regards
--1663360971-2103557325-1324132374=:32639-- From marshall.eubanks@gmail.com Sat Dec 17 07:28:45 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4D421F84F5 for ; Sat, 17 Dec 2011 07:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.497 X-Spam-Level: X-Spam-Status: No, score=-103.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoKkouWSWHQK for ; Sat, 17 Dec 2011 07:28:45 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A55A21F84ED for ; Sat, 17 Dec 2011 07:28:44 -0800 (PST) Received: by obcuz6 with SMTP id uz6so980174obc.31 for ; Sat, 17 Dec 2011 07:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UTupTGjneYa2zGlQjywQ0ZUPGfShD0fV2rfwgnGOf2o=; b=s6drAcJXPXGvjvJZJQi6DMvXP8leL34MQ45B5xWU0IyY260NB/55L5+eRvEGZ0/J3S DJJqRHesonPK3jAg+Areasm9VLJerP213wL1R6Ahr/vC7b1iRWzheGnfJFzQbTWvItE8 2cTikwI7tivYu+N36rmcFnQiMPgcb65Fe+7/g= MIME-Version: 1.0 Received: by 10.182.227.101 with SMTP id rz5mr6446267obc.78.1324135723361; Sat, 17 Dec 2011 07:28:43 -0800 (PST) Received: by 10.182.227.67 with HTTP; Sat, 17 Dec 2011 07:28:43 -0800 (PST) In-Reply-To: <1324132374.32639.YahooMailNeo@web27103.mail.ukl.yahoo.com> References: <1324132374.32639.YahooMailNeo@web27103.mail.ukl.yahoo.com> Date: Sat, 17 Dec 2011 10:28:43 -0500 Message-ID: From: Marshall Eubanks To: radia boukari Content-Type: text/plain; charset=ISO-8859-1 Cc: "dc@ietf.org" Subject: Re: [dc] volunteer X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 15:28:45 -0000 On Sat, Dec 17, 2011 at 9:32 AM, radia boukari wrote: > Hello > I am new I would like to know what do I have to do to get envolved . > thank you > Best regards This is the IETF. It is relatively easy. Read the drafts, try and understand them, comment here on what is wrong or what could be improved. If you see anything missing, suggest text or even write a draft to fill the gap. Regards Marshall > > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc > From warren@kumari.net Sat Dec 17 09:38:22 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B9221F84B7 for ; Sat, 17 Dec 2011 09:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH15wwqiMYOX for ; Sat, 17 Dec 2011 09:38:21 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACCE21F84B6 for ; Sat, 17 Dec 2011 09:38:21 -0800 (PST) Received: from [192.168.0.105] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 991791B401ED; Sat, 17 Dec 2011 12:38:20 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Sat, 17 Dec 2011 12:38:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1324132374.32639.YahooMailNeo@web27103.mail.ukl.yahoo.com> To: Marshall Eubanks X-Mailer: Apple Mail (2.1084) Cc: Warren Kumari , "dc@ietf.org" , radia boukari Subject: Re: [dc] volunteer X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 17:38:22 -0000 On Dec 17, 2011, at 10:28 AM, Marshall Eubanks wrote: > On Sat, Dec 17, 2011 at 9:32 AM, radia boukari = wrote: >> Hello >> I am new I would like to know what do I have to do to get envolved . >> thank you >> Best regards >=20 > This is the IETF. It is relatively easy. Read the drafts, try and > understand them, comment here on what is wrong or what could be > improved. If you see anything missing, suggest text or even write a > draft to fill the gap. And, if you are new to the IETF, I'd suggest reading "The Tao of IETF: A = Novice's Guide to the Internet Engineering Task Force" -- = http://www.ietf.org/tao.html Understanding the way that the IETF works, and that energetic / heated = discussions doesn't (necessarily) mean that folk aren't really good = friends is important[0]. W [0]: I've had some chats with newcomers who are shocked at the = (apparent) animosity between some folk, not realizing that we just = debate / argue to got to consensus[1]. [1]: Ok, to be honest, it's actually because it's fun, but don't tell = anyon.. doh.... >=20 > Regards > Marshall >=20 >=20 >>=20 >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc >>=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc >=20 From pedro.r.marques@gmail.com Sat Dec 17 12:16:57 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3793E21F8B15 for ; Sat, 17 Dec 2011 12:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LpM6B68FPav for ; Sat, 17 Dec 2011 12:16:56 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD1321F8B12 for ; Sat, 17 Dec 2011 12:16:56 -0800 (PST) Received: by iaek3 with SMTP id k3so7398813iae.31 for ; Sat, 17 Dec 2011 12:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vVybH864h4C2gcWv3xfn2fLJ+f4hHz6zBtpcIObX3Vo=; b=sw0Xc2MSmfmMGnY6sSncGWRcBbsxhIhZIO75E/8P3KB2jK65sMXWR8RScEIJeEttnx 722hvkuB01A9rO7bCjbKYQbRSxDTJaK+rsKCjTtqVoRLJm01Eg7qghTAMlOiE+3lxRjv W3ISG0MWcLoT2vJWA3MTo9dn5hx+gRzXF5kn4= MIME-Version: 1.0 Received: by 10.50.182.199 with SMTP id eg7mr16974706igc.57.1324153016109; Sat, 17 Dec 2011 12:16:56 -0800 (PST) Received: by 10.231.14.2 with HTTP; Sat, 17 Dec 2011 12:16:56 -0800 (PST) In-Reply-To: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> References: <201112161315.pBGDFP9X009939@cichlid.raleigh.ibm.com> Date: Sat, 17 Dec 2011 12:16:56 -0800 Message-ID: From: Pedro Marques To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dc@ietf.org" Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 20:16:57 -0000 Thomas, Please add http://tools.ietf.org/html/draft-marques-sndp-l3vpn-schema-00 to the the list. It defines the northbound API to orchestration/provision systems that can be used along with draft-marques-l3vpn-end-system-03 (virtual network connectivity) and draft-marques-sdnp-flow-spec-00 (inter-vpn traffic filtering). The 3 documents are part of the same solution but they address sub-problems that are best treated independently, in my view. thanks, Pedro. On Fri, Dec 16, 2011 at 5:15 AM, Thomas Narten wrote: > Joel jaeggli writes: > >> So far it's been an impressively low traffic list for a cross area >> intersection of interests gearing up to discuss documents at an interim. > > Fair point. > > And with that, I'd like to start with a summary of the potential work > items that might be covered here. By "work items", I'd like to see a > grouping of IDs/presentations into (potential) work areas. The goal > would be to talk about each work area somewhat separately. If we > aren't able to organize work into mostly self-contained areas (i.e., > WGs), we'll never get anywhere. > > So far, the ones I know of include: > > NVO3 > =A0 =A0draft-narten-nvo3-overlay-problem-statement-01.txt > SDN > =A0 =A0draft-nadeau-sdn-problem-statement-01.txt > > =A0Use Case/Examples: > =A0 =A0draft-stiliadis-sdnp-framework-use-cases-01.txt > =A0 =A0draft-pan-sdn-bod-problem-statement-and-use-case-01.txt > =A0 =A0draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt > =A0 =A0draft-mcdysan-sdnp-cloudbursting-usecase-00.txt > > =A0Solutions/Approachs: > =A0 =A0draft-nadeau-sdn-framework-01.txt > =A0 =A0draft-marques-sdnp-flow-spec-00.txt > VPN4DC > =A0 =A0http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 > > =A0 =A0http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicabilit= y-01 > =A0 =A0http://tools.ietf.org/html/draft-so-vpn4dc-00 > =A0 =A0http://datatracker.ietf.org/doc/draft-so-vdcs-01 > =A0 =A0http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-0= 0 > =A0 =A0http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 > =A0 =A0http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 > =A0 =A0http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis= -00 > =A0 =A0http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 > =A0 =A0http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 > > Are there others? > > Thomas > > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From Peter.AshwoodSmith@huawei.com Mon Dec 19 06:20:19 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC5F21F8B85 for ; Mon, 19 Dec 2011 06:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuOYUKJ+DKSA for ; Mon, 19 Dec 2011 06:20:19 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3521F8B84 for ; Mon, 19 Dec 2011 06:20:19 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABY00884; Mon, 19 Dec 2011 09:20:18 -0500 (EST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Dec 2011 06:19:00 -0800 Received: from DFWEML504-MBX.china.huawei.com ([10.124.31.30]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Mon, 19 Dec 2011 06:18:57 -0800 From: AshwoodsmithPeter To: Mohnish Anumala , Pat Thaler , "dc@ietf.org" Thread-Topic: [dc] Work items for this group Thread-Index: AQHMu/U8TFnXo6E+80W5SKRQ8lJ7k5XfZEwAgAAHrQCAA84CIA== Date: Mon, 19 Dec 2011 14:18:56 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E28F875D@dfweml504-mbx> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dc] Work items for this group X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 14:20:19 -0000 Pat if you want some material on .1aq or .1Qbp we can provide some overview= stuff. Peter Ashwood-Smith -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Mohnish= Anumala Sent: Friday, December 16, 2011 3:11 PM To: Pat Thaler; dc@ietf.org Subject: Re: [dc] Work items for this group That will be great. Thanks, --Mohnish -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Pat Tha= ler Sent: Friday, December 16, 2011 11:44 AM To: Thomas Narten; dc@ietf.org Subject: Re: [dc] Work items for this group Not a work item, but would it be helpful to have an overview of the IEEE 80= 2.1 work for Data Center that is in progress or has recently completed? I c= ould put something together if there is an interest. Pat -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Thomas = Narten Sent: Friday, December 16, 2011 5:15 AM To: dc@ietf.org Subject: [dc] Work items for this group Joel jaeggli writes: > So far it's been an impressively low traffic list for a cross area > intersection of interests gearing up to discuss documents at an interim. Fair point. And with that, I'd like to start with a summary of the potential work items that might be covered here. By "work items", I'd like to see a grouping of IDs/presentations into (potential) work areas. The goal would be to talk about each work area somewhat separately. If we aren't able to organize work into mostly self-contained areas (i.e., WGs), we'll never get anywhere. So far, the ones I know of include: NVO3 draft-narten-nvo3-overlay-problem-statement-01.txt SDN draft-nadeau-sdn-problem-statement-01.txt Use Case/Examples:=09 draft-stiliadis-sdnp-framework-use-cases-01.txt draft-pan-sdn-bod-problem-statement-and-use-case-01.txt draft-pan-sdn-dc-problem-statement-and-use-cases-01.txt draft-mcdysan-sdnp-cloudbursting-usecase-00.txt =20 Solutions/Approachs: draft-nadeau-sdn-framework-01.txt draft-marques-sdnp-flow-spec-00.txt VPN4DC http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 http://tools.ietf.org/html/draft-so-vpn4dc-00 http://datatracker.ietf.org/doc/draft-so-vdcs-01 http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Are there others? Thomas _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From vumip1@gmail.com Mon Dec 19 08:15:02 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6BF21F8541 for ; Mon, 19 Dec 2011 08:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3pFcYOYLhpE for ; Mon, 19 Dec 2011 08:15:01 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D59E21F853A for ; Mon, 19 Dec 2011 08:15:01 -0800 (PST) Received: by ghbg18 with SMTP id g18so452235ghb.31 for ; Mon, 19 Dec 2011 08:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=z5WhQJSsXYXVps3XaMlcpIp+g10VUqkfYiBrVQ8cfiI=; b=PvxJ3y/ADFdIz6Gg2A/SV9vPoS2/rO3ER9MXFr7MBX7ftuFRiVi6tusozncDp0XEep T7mIsapjqrcs4DvcP+vaHvoeUv9/qHZPFeZUyvu90CWFTT+EaHuEWr/Ls73zY+0VF76n 2j4dkSSZyJJgLA9UkUUJdD1Bo6z3jmhgpvBzU= MIME-Version: 1.0 Received: by 10.50.106.226 with SMTP id gx2mr28589374igb.13.1324311300882; Mon, 19 Dec 2011 08:15:00 -0800 (PST) Received: by 10.50.170.105 with HTTP; Mon, 19 Dec 2011 08:15:00 -0800 (PST) Date: Mon, 19 Dec 2011 11:15:00 -0500 Message-ID: From: Bhumip Khasnabish To: dc@ietf.org Content-Type: multipart/alternative; boundary=e89a8f2351e1a940bb04b47440d1 Subject: [dc] DC Ops work itmes and related drafts that we discusses during Quebec mtg X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 16:15:02 -0000 --e89a8f2351e1a940bb04b47440d1 Content-Type: text/plain; charset=ISO-8859-1 The slides that we used for Data Center Operations and Management Discussion during the Quebec mtg. can be found at the following link .. http://www.ietf.org/proceedings/81/slides/opsawg-3.pdf Thanks. Bhumip --e89a8f2351e1a940bb04b47440d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The slides that we used for Data Center Operations a= nd Management Discussion during the Quebec mtg. ca= n be found at the following link ..
=A0
=A0
Thanks.
=A0
Bhumip
=A0
--e89a8f2351e1a940bb04b47440d1-- From vumip1@gmail.com Mon Dec 19 12:27:28 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FEE21F861E for ; Mon, 19 Dec 2011 12:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6FGLvY0CORY for ; Mon, 19 Dec 2011 12:27:28 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0213521F85D1 for ; Mon, 19 Dec 2011 12:27:27 -0800 (PST) Received: by iaen33 with SMTP id n33so660176iae.31 for ; Mon, 19 Dec 2011 12:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rQpyF2f/jT85hvRU1C0piBNRssdsMUqo6ogvUMltXNs=; b=a3bCDLh64owOrtW1j39G2ja9YrIFNOu2PxPTKjXB2zEGps/bgcjNYGDaHYwCVP3aSA POIUTYgZELTEPsUGuuVaLsvrGDpYzavXGCX/DMp6mVBPzYzFhDrUnHXRWdNLHZ6TM5K8 Cq0q3ICLfAOEGeAwpWq3afmmRtU6Qu7LQcGkc= MIME-Version: 1.0 Received: by 10.50.163.97 with SMTP id yh1mr29197687igb.37.1324326447482; Mon, 19 Dec 2011 12:27:27 -0800 (PST) Received: by 10.50.170.105 with HTTP; Mon, 19 Dec 2011 12:27:27 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Dec 2011 15:27:27 -0500 Message-ID: From: Bhumip Khasnabish To: dc@ietf.org Content-Type: multipart/alternative; boundary=e89a8f83903d78094e04b477c78b Cc: "So, Ning" , Chu.JunSheng@zte.com.cn, Suren Karavettil , Lizhong Jin , meng.yu@zte.com.cn, shao.weixiang@zte.com.cn, hu.jie@zte.com.cn Subject: Re: [dc] Requesting comments on the following drafts X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:27:28 -0000 --e89a8f83903d78094e04b477c78b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Also, the following draft on Cloud Service Broker http://tools.ietf.org/html/draft-shao-opsawg-cloud-service-broker-00 Thanks. Best. Bhumip On Fri, Dec 9, 2011 at 3:29 PM, Bhumip Khasnabish wrote: > Dear All, > > We are planning to update the following DC-related drafts soon, > and would appreciate your valuable comments and suggestions. > > http://www.ietf.org/id/draft-karavettil-vdcs-security-framework-00.txt > > http://tools.ietf.org/id/draft-khasnabish-cloud-reference-framework-01.tx= t > > http://tools.ietf.org/id/draft-khasnabish-cloud-sdo-survey-01.txt > > > http://tools.ietf.org/id/draft-khasnabish-cloud-industry-workitems-survey= -01.txt > > > http://tools.ietf.org/id/draft-junsheng-opsawg-virtual-resource-managemen= t-00.txt > > Thanks a lot. > Best. > > Bhumip Khasnabish > vumip1@gmail.com > bhumip.khasnabish@zteusa.com > +1-781-752-8003 (mobile) > http://www.linkedin.com/in/bhumipkhasnabish > > __o > _ `\ <, _ > .......... ( =95 ) / ( =95 ) ...................... > > --e89a8f83903d78094e04b477c78b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Also, the following draft on Cloud Service Broker
=A0
Thanks.
=A0
Best.
=A0
Bhumip

=A0
On Fri, Dec 9, 2011 at 3:29 PM, Bhumip Khasnabis= h <vumip1@gmail.com> wrote:
Dear All,
=A0
We are planning to update the following DC-related drafts soon,
and would appreciate your valuable comments and suggestions.
=A0
=A0
=A0
Thanks a lot.
Best.

Bhumip Khasnabish

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __o
=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 _ `\ <, _
.......... ( =95 ) / ( =95 = ) ......................



=A0=20 --e89a8f83903d78094e04b477c78b-- From Tina.Tsou.Zouting@huawei.com Mon Dec 19 12:46:50 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769AE21F853E for ; Mon, 19 Dec 2011 12:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPyah7SEPJ5N for ; Mon, 19 Dec 2011 12:46:49 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9AC21F853B for ; Mon, 19 Dec 2011 12:46:48 -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 <0LWG00132XPR9X@szxga03-in.huawei.com> for dc@ietf.org; Tue, 20 Dec 2011 04:46:39 +0800 (CST) Received: from szxrg02-dlp.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 <0LWG00C8SXPQIJ@szxga03-in.huawei.com> for dc@ietf.org; Tue, 20 Dec 2011 04:46:39 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFU51027; Tue, 20 Dec 2011 04:46:03 +0800 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Dec 2011 04:46:00 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Tue, 20 Dec 2011 04:45:55 +0800 Date: Mon, 19 Dec 2011 20:45:54 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.145] To: Bhumip Khasnabish , "dc@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_yeI4oQOJdEhXRnQozuu51w)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [dc] Requesting comments on the following drafts Thread-index: AQHMvoyn3V1GhJnxW0W4NMRN7zkcKZXjntvQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "So, Ning" , "Chu.JunSheng@zte.com.cn" , Suren Karavettil , Lizhong Jin , "meng.yu@zte.com.cn" , "shao.weixiang@zte.com.cn" , "hu.jie@zte.com.cn" Subject: Re: [dc] Requesting comments on the following drafts X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:46:50 -0000 --Boundary_(ID_yeI4oQOJdEhXRnQozuu51w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT In line... Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Bhumip Khasnabish Sent: Monday, December 19, 2011 12:27 PM To: dc@ietf.org Cc: So, Ning; Chu.JunSheng@zte.com.cn; Suren Karavettil; Lizhong Jin; meng.yu@zte.com.cn; shao.weixiang@zte.com.cn; hu.jie@zte.com.cn Subject: Re: [dc] Requesting comments on the following drafts Also, the following draft on Cloud Service Broker http://tools.ietf.org/html/draft-shao-opsawg-cloud-service-broker-00 [Tina: It seems like http://tools.ietf.org/id/draft-tsou-vrom-problem-statement-02.txt mentioned earlier the idea more or less Cloud Service Broker talks about.] Thanks. Best. Bhumip On Fri, Dec 9, 2011 at 3:29 PM, Bhumip Khasnabish > wrote: Dear All, We are planning to update the following DC-related drafts soon, and would appreciate your valuable comments and suggestions. http://www.ietf.org/id/draft-karavettil-vdcs-security-framework-00.txt http://tools.ietf.org/id/draft-khasnabish-cloud-reference-framework-01.txt http://tools.ietf.org/id/draft-khasnabish-cloud-sdo-survey-01.txt http://tools.ietf.org/id/draft-khasnabish-cloud-industry-workitems-survey-01.txt http://tools.ietf.org/id/draft-junsheng-opsawg-virtual-resource-management-00.txt Thanks a lot. Best. Bhumip Khasnabish vumip1@gmail.com bhumip.khasnabish@zteusa.com +1-781-752-8003 (mobile) http://www.linkedin.com/in/bhumipkhasnabish __o _ `\ <, _ .......... ( * ) / ( * ) ...................... --Boundary_(ID_yeI4oQOJdEhXRnQozuu51w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

In line…

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

 

From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Bhumip Khasnabish
Sent: Monday, December 19, 2011 12:27 PM
To: dc@ietf.org
Cc: So, Ning; Chu.JunSheng@zte.com.cn; Suren Karavettil; Lizhong Jin; meng.yu@zte.com.cn; shao.weixiang@zte.com.cn; hu.jie@zte.com.cn
Subject: Re: [dc] Requesting comments on the following drafts

 

Also, the following draft on Cloud Service Broker

 

[Tina: It seems like http://tools.ietf.org/id/draft-tsou-vrom-problem-statement-02.txt mentioned earlier the idea more or less Cloud Service Broker talks about.]

 

Thanks.

 

Best.

 

Bhumip


 

On Fri, Dec 9, 2011 at 3:29 PM, Bhumip Khasnabish <vumip1@gmail.com> wrote:

Dear All,

 

We are planning to update the following DC-related drafts soon,

and would appreciate your valuable comments and suggestions.

 

 

 

Thanks a lot.

Best.

Bhumip Khasnabish


                   __o
             _ `\ <, _
.......... ( • ) / ( • ) ......................

 



 

--Boundary_(ID_yeI4oQOJdEhXRnQozuu51w)-- From rbonica@juniper.net Tue Dec 20 11:53:43 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB4521F858D for ; Tue, 20 Dec 2011 11:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.407 X-Spam-Level: X-Spam-Status: No, score=-106.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpK-XXiG89q3 for ; Tue, 20 Dec 2011 11:53:42 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7730021F8586 for ; Tue, 20 Dec 2011 11:53:40 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTvDnsCfmVc2cXxYvvlx2XTLmK1rxaQeW@postini.com; Tue, 20 Dec 2011 11:53:40 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Dec 2011 11:48:32 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 20 Dec 2011 14:48:31 -0500 From: Ronald Bonica To: "dc@ietf.org" Date: Tue, 20 Dec 2011 14:48:29 -0500 Thread-Topic: Scoping the Interim meeting Thread-Index: Acy/UFjTkv7a6r5mTy699yqvnJVhAw== Message-ID: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:53:43 -0000 Folks, During the last few days, this list has produced an impressive annotated bi= bliography of Internet Drafts. Thanks to all who have contributed. In preparation for the upcoming interim meeting, this group should consider= all of the "problem statement" drafts. Specifically, we should make a list= of problems that are called out by a majority of these drafts. We will ide= ntify these problems as the core data center problem space. We should also make another list of problems that are called out by only a = small minority of drafts. Having made this second list, we will explain why= the problem is not commonly viewed. Possible answers are: - it is not a real problem - the problem is not unique to the data center - the problem is unique to a particular service being offered in the DC - the problem is unique to a particular data center network architecture It would be great if we could capture the output of this exercise in an Int= ernet Draft.=20 Comments? -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From lufang@cisco.com Tue Dec 20 13:00:28 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2AC21F88B6 for ; Tue, 20 Dec 2011 13:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQb1EvpuK-gd for ; Tue, 20 Dec 2011 13:00:27 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C596221F88A0 for ; Tue, 20 Dec 2011 13:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1716; q=dns/txt; s=iport; t=1324414828; x=1325624428; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=XNWrUKNbAe9ng2zB2OKtBcdJKDGhxOY4jfBcV44JZkc=; b=MxjVpWsxowEgl4vDbNy1FAIWfNgl4VUv+fo9Uflw3TTV92FjLBAggDsh zdyo+wkXuIBnRm+48vPV4DownRJHJ1LRa7dhCUWPa/FDHqQ4LpP9JZM8/ iZET1folQS0Dp008Y4Bv+88ZiVXLJLj9yefb5G1dNUIr2PZivOpOovagS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAABX28E6tJV2b/2dsb2JhbAA5CpsvkFWBBYFyAQEBBAEBAQ8BHQoPJQsMBAIBCA4DAQMBAQsGFwEGASYfAwYIAQEEARIIARmHYJh7AZ4viFOCVmMEiDefFw X-IronPort-AV: E=Sophos;i="4.71,384,1320624000"; d="scan'208";a="45666531" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 20 Dec 2011 21:00:27 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBKL0R4g031369; Tue, 20 Dec 2011 21:00:27 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 15:00:27 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Dec 2011 15:00:26 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25078F4933@XMB-RCD-201.cisco.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Scoping the Interim meeting Thread-Index: Acy/UFjTkv7a6r5mTy699yqvnJVhAwABZZ9A References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> From: "Luyuan Fang (lufang)" To: "Ronald Bonica" , X-OriginalArrivalTime: 20 Dec 2011 21:00:27.0053 (UTC) FILETIME=[6642FDD0:01CCBF5A] Cc: Thomas Narten Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 21:00:28 -0000 Ron, We think this is a very good idea.=20 We'd like to volunteer to edit this problem analysis draft together. Welcome everyone's input. Thanks, Luyuan and Thomas > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Tuesday, December 20, 2011 2:48 PM > To: dc@ietf.org > Subject: [dc] Scoping the Interim meeting >=20 > Folks, >=20 > During the last few days, this list has produced an impressive > annotated bibliography of Internet Drafts. Thanks to all who have > contributed. >=20 > In preparation for the upcoming interim meeting, this group should > consider all of the "problem statement" drafts. Specifically, we should > make a list of problems that are called out by a majority of these > drafts. We will identify these problems as the core data center problem > space. >=20 > We should also make another list of problems that are called out by > only a small minority of drafts. Having made this second list, we will > explain why the problem is not commonly viewed. Possible answers are: >=20 > - it is not a real problem > - the problem is not unique to the data center > - the problem is unique to a particular service being offered in the DC > - the problem is unique to a particular data center network > architecture >=20 > It would be great if we could capture the output of this exercise in an > Internet Draft. >=20 > Comments? >=20 >=20 > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf >=20 >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From pthaler@broadcom.com Tue Dec 20 15:12:26 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016E821F848D for ; Tue, 20 Dec 2011 15:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQCCHACwWWBM for ; Tue, 20 Dec 2011 15:12:25 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4466F21F8485 for ; Tue, 20 Dec 2011 15:12:25 -0800 (PST) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 20 Dec 2011 15:19:46 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR01.corp.ad.broadcom.com ([10.252.49.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 20 Dec 2011 15:12:10 -0800 From: "Pat Thaler" To: "Ronald Bonica" , "dc@ietf.org" Date: Tue, 20 Dec 2011 15:12:09 -0800 Thread-Topic: Scoping the Interim meeting Thread-Index: Acy/UFjTkv7a6r5mTy699yqvnJVhAwAG2YiQ Message-ID: References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62EFC7985046436901-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 23:12:26 -0000 There is a fifth possibility for why a problem might be only in a small min= ority of drafts - it is a real problem that should be in the core data center problem space= , but only a small group of authors have identified it Probably that explanation won't apply to most of the set, but it is possibl= e in the early days of people looking at a problem space from different per= spectives and we should apply our judgment rather than making the cut just = based on the number of drafts that spotted the issue. Pat -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Ronald = Bonica Sent: Tuesday, December 20, 2011 11:48 AM To: dc@ietf.org Subject: [dc] Scoping the Interim meeting Folks, During the last few days, this list has produced an impressive annotated bi= bliography of Internet Drafts. Thanks to all who have contributed. In preparation for the upcoming interim meeting, this group should consider= all of the "problem statement" drafts. Specifically, we should make a list= of problems that are called out by a majority of these drafts. We will ide= ntify these problems as the core data center problem space. We should also make another list of problems that are called out by only a = small minority of drafts. Having made this second list, we will explain why= the problem is not commonly viewed. Possible answers are: - it is not a real problem - the problem is not unique to the data center - the problem is unique to a particular service being offered in the DC - the problem is unique to a particular data center network architecture It would be great if we could capture the output of this exercise in an Int= ernet Draft.=20 Comments? -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From guyingjie@huawei.com Tue Dec 20 18:04:18 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C61411E8089 for ; Tue, 20 Dec 2011 18:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BdIQVMYc24S for ; Tue, 20 Dec 2011 18:04:16 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A761511E8073 for ; Tue, 20 Dec 2011 18:04:15 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWJ00JRC72V44@szxga05-in.huawei.com> for dc@ietf.org; Wed, 21 Dec 2011 10:04:08 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWJ00IWX72VZG@szxga05-in.huawei.com> for dc@ietf.org; Wed, 21 Dec 2011 10:04:07 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFV29523; Wed, 21 Dec 2011 10:04:07 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Dec 2011 10:04:03 +0800 Received: from g00107907 (10.138.41.134) by szxeml406-hub.china.huawei.com (10.82.67.93) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Dec 2011 10:04:00 +0800 Date: Wed, 21 Dec 2011 10:08:29 +0800 From: "Yingjie Gu(yingjie)" X-Originating-IP: [10.138.41.134] To: dc@ietf.org, 'Ronald Bonica' , lufang@cisco.com, 'Thomas Narten' Message-id: <021a01ccbf85$6f6753e0$4e35fba0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_nAvOAiciTOhUoR1kqhVNzw)" Content-language: zh-cn Thread-index: Acy/hW6OvUjeJPqjQcO+7CrfyvBEug== X-CFilter-Loop: Reflected Cc: 'Linda Dunbar' Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 02:04:18 -0000 --Boundary_(ID_nAvOAiciTOhUoR1kqhVNzw) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi Ron and Luyuan, Good idea. I'd volunteer to work together on this draft. _____ Ron, We think this is a very good idea. We'd like to volunteer to edit this problem analysis draft together. Welcome everyone's input. Thanks, Luyuan and Thomas > -----Original Message----- > From: dc-bounces at ietf.org [mailto:dc-bounces at ietf.org] On Behalf Of > Ronald Bonica > Sent: Tuesday, December 20, 2011 2:48 PM > To: dc at ietf.org > Subject: [dc] Scoping the Interim meeting > > Folks, > > During the last few days, this list has produced an impressive > annotated bibliography of Internet Drafts. Thanks to all who have > contributed. > > In preparation for the upcoming interim meeting, this group should > consider all of the "problem statement" drafts. Specifically, we should > make a list of problems that are called out by a majority of these > drafts. We will identify these problems as the core data center problem > space. > > We should also make another list of problems that are called out by > only a small minority of drafts. Having made this second list, we will > explain why the problem is not commonly viewed. Possible answers are: > > - it is not a real problem > - the problem is not unique to the data center > - the problem is unique to a particular service being offered in the DC > - the problem is unique to a particular data center network > architecture > > It would be great if we could capture the output of this exercise in an > Internet Draft. > > Comments? > > > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf > > > _______________________________________________ > dc mailing list > dc at ietf.org > https://www.ietf.org/mailman/listinfo/dc _____ Best Regards Gu Yingjie --Boundary_(ID_nAvOAiciTOhUoR1kqhVNzw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

Hi Ron and Luyuan,

Good idea.

I’d volunteer to work together on this draft.

 

 

 

Ron,
 
We think this is a very good idea. 
We'd like to volunteer to edit this problem analysis draft together.
Welcome everyone's input.
 
Thanks,
Luyuan and Thomas
 
 
> -----Original Message-----
> Ronald Bonica
> Sent: Tuesday, December 20, 2011 2:48 PM
> To: dc at ietf.org
> Subject: [dc] Scoping the Interim meeting
> 
> Folks,
> 
> During the last few days, this list has produced an impressive
> annotated bibliography of Internet Drafts. Thanks to all who have

> contributed.

> 
> In preparation for the upcoming interim meeting, this group should
> consider all of the "problem statement" drafts. Specifically, we
should
> make a list of problems that are called out by a majority of these
> drafts. We will identify these problems as the core data center
problem
> space.
> 
> only a small minority of drafts. Having made this second list, we will
> explain why the problem is not commonly viewed. Possible answers are:
> 
> - it is not a real problem
> - the problem is not unique to the data center
> - the problem is unique to a particular service being offered in the
DC
> - the problem is unique to a particular data center network
> architecture
> 
> It would be great if we could capture the output of this exercise in
an
> Internet Draft.
> 
> Comments?
> 
> 
> --------------------------
> Ron Bonica
> vcard:       www.bonica.org
 /ron/ron
an>
> 
> 
> _______________________________________________
> dc mailing list
> dc at ietf.org
> https://www.ietf.org/mailman/listinfo/dc

 

 

Best Regards
Gu Yingjie

 

--Boundary_(ID_nAvOAiciTOhUoR1kqhVNzw)-- From lufang@cisco.com Tue Dec 20 18:20:53 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB39F11E8095 for ; Tue, 20 Dec 2011 18:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMB7vVuwWWMS for ; Tue, 20 Dec 2011 18:20:53 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3A11C11E8073 for ; Tue, 20 Dec 2011 18:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=3676; q=dns/txt; s=iport; t=1324434053; x=1325643653; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AKlOwCjjeKp5C+EcCQTXZq76mDSV/OO6Kc/rQGA7pAA=; b=iAGS6/8v6ePQ1cVFMbChooyvNcOqnQXy0S1enFlwxs+DpaHukcIDIB/f jDjDUh0iwaoJQL9cxillDWx29wb51yuIuc9ezam1ngio8iukcZtu6Ix3a ke4bnNtIBraersTfcfu2IPudnhAKC++K3IB57CR3VXVfjgdHBeuDcpWTw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgAAPRB8U6tJV2c/2dsb2JhbAA5ChaEeZYsjzGBJYEFgXIBAQEDAQEBAQ8BEA0EFSULDAQCAQYCEQEDAQEBAgIGBhcBAgICAQElHwMGCAEBBBMIARmHWAiYegGMW5FagS+HJ4IjM2MEiDefGQ X-IronPort-AV: E=Sophos;i="4.71,385,1320624000"; d="scan'208";a="45711434" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 21 Dec 2011 02:20:52 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pBL2Kq3f011687; Wed, 21 Dec 2011 02:20:52 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 20:20:52 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 20 Dec 2011 20:20:02 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25078F49EF@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Scoping the Interim meeting Thread-Index: Acy/ciw7AQ/NktLvSgaP33WlNLq5GwAFLrcA References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <238542D917511A45B6B8AA806E875E25078F4933@XMB-RCD-201.cisco.com> From: "Luyuan Fang (lufang)" To: "Christopher LILJENSTOLPE" X-OriginalArrivalTime: 21 Dec 2011 02:20:52.0589 (UTC) FILETIME=[2992F9D0:01CCBF87] Cc: Thomas Narten , Ronald Bonica , dc@ietf.org Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 02:20:54 -0000 Q2hyaXMsDQoNCkdvb2QgaWRlYS4gV2lsbCByZWFjaCBvdXQgdG8gVG9tLg0KTHV5dWFuDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2hyaXN0b3BoZXIgTElMSkVOU1RP TFBFIFttYWlsdG86Y2RsQGFzZ2FhcmQub3JnXQ0KPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAy MCwgMjAxMSA2OjUxIFBNDQo+IFRvOiBMdXl1YW4gRmFuZyAobHVmYW5nKQ0KPiBDYzogUm9uYWxk IEJvbmljYTsgZGNAaWV0Zi5vcmc7IFRob21hcyBOYXJ0ZW4NCj4gU3ViamVjdDogUmU6IFtkY10g U2NvcGluZyB0aGUgSW50ZXJpbSBtZWV0aW5nDQo+IA0KPiBHcmVldGluZ3MsDQo+IA0KPiAJSSB3 b3VsZCBzdWdnZXN0IHRoYXQgVG9tIE5hZGVhdSBhbHNvIGJlIGluY2x1ZGVkLCBhcyBoZSBoYWQg cXVpdGUNCj4gYSBiaXQgb2YgaW5wdXQgcHVsbGluZyB0aGUgU0ROIHN0dWZmIHRvZ2V0aGVyLg0K PiANCj4gCUNocmlzDQo+IA0KPiBPbiAyMERlYzIwMTEsIGF0IDEzLjAwLCBMdXl1YW4gRmFuZyAo bHVmYW5nKSB3cm90ZToNCj4gDQo+ID4gUm9uLA0KPiA+DQo+ID4gV2UgdGhpbmsgdGhpcyBpcyBh IHZlcnkgZ29vZCBpZGVhLg0KPiA+IFdlJ2QgbGlrZSB0byB2b2x1bnRlZXIgdG8gZWRpdCB0aGlz IHByb2JsZW0gYW5hbHlzaXMgZHJhZnQgdG9nZXRoZXIuDQo+ID4gV2VsY29tZSBldmVyeW9uZSdz IGlucHV0Lg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IEx1eXVhbiBhbmQgVGhvbWFzDQo+ID4NCj4g Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBkYy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4+ IFJvbmFsZCBCb25pY2ENCj4gPj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjAsIDIwMTEgMjo0 OCBQTQ0KPiA+PiBUbzogZGNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogW2RjXSBTY29waW5nIHRo ZSBJbnRlcmltIG1lZXRpbmcNCj4gPj4NCj4gPj4gRm9sa3MsDQo+ID4+DQo+ID4+IER1cmluZyB0 aGUgbGFzdCBmZXcgZGF5cywgdGhpcyBsaXN0IGhhcyBwcm9kdWNlZCBhbiBpbXByZXNzaXZlDQo+ ID4+IGFubm90YXRlZCBiaWJsaW9ncmFwaHkgb2YgSW50ZXJuZXQgRHJhZnRzLiBUaGFua3MgdG8g YWxsIHdobyBoYXZlDQo+ID4+IGNvbnRyaWJ1dGVkLg0KPiA+Pg0KPiA+PiBJbiBwcmVwYXJhdGlv biBmb3IgdGhlIHVwY29taW5nIGludGVyaW0gbWVldGluZywgdGhpcyBncm91cCBzaG91bGQNCj4g Pj4gY29uc2lkZXIgYWxsIG9mIHRoZSAicHJvYmxlbSBzdGF0ZW1lbnQiIGRyYWZ0cy4gU3BlY2lm aWNhbGx5LCB3ZQ0KPiA+IHNob3VsZA0KPiA+PiBtYWtlIGEgbGlzdCBvZiBwcm9ibGVtcyB0aGF0 IGFyZSBjYWxsZWQgb3V0IGJ5IGEgbWFqb3JpdHkgb2YgdGhlc2UNCj4gPj4gZHJhZnRzLiBXZSB3 aWxsIGlkZW50aWZ5IHRoZXNlIHByb2JsZW1zIGFzIHRoZSBjb3JlIGRhdGEgY2VudGVyDQo+ID4g cHJvYmxlbQ0KPiA+PiBzcGFjZS4NCj4gPj4NCj4gPj4gV2Ugc2hvdWxkIGFsc28gbWFrZSBhbm90 aGVyIGxpc3Qgb2YgcHJvYmxlbXMgdGhhdCBhcmUgY2FsbGVkIG91dCBieQ0KPiA+PiBvbmx5IGEg c21hbGwgbWlub3JpdHkgb2YgZHJhZnRzLiBIYXZpbmcgbWFkZSB0aGlzIHNlY29uZCBsaXN0LCB3 ZQ0KPiA+PiB3aWxsIGV4cGxhaW4gd2h5IHRoZSBwcm9ibGVtIGlzIG5vdCBjb21tb25seSB2aWV3 ZWQuIFBvc3NpYmxlDQo+IGFuc3dlcnMgYXJlOg0KPiA+Pg0KPiA+PiAtIGl0IGlzIG5vdCBhIHJl YWwgcHJvYmxlbQ0KPiA+PiAtIHRoZSBwcm9ibGVtIGlzIG5vdCB1bmlxdWUgdG8gdGhlIGRhdGEg Y2VudGVyDQo+ID4+IC0gdGhlIHByb2JsZW0gaXMgdW5pcXVlIHRvIGEgcGFydGljdWxhciBzZXJ2 aWNlIGJlaW5nIG9mZmVyZWQgaW4gdGhlDQo+ID4gREMNCj4gPj4gLSB0aGUgcHJvYmxlbSBpcyB1 bmlxdWUgdG8gYSBwYXJ0aWN1bGFyIGRhdGEgY2VudGVyIG5ldHdvcmsNCj4gPj4gYXJjaGl0ZWN0 dXJlDQo+ID4+DQo+ID4+IEl0IHdvdWxkIGJlIGdyZWF0IGlmIHdlIGNvdWxkIGNhcHR1cmUgdGhl IG91dHB1dCBvZiB0aGlzIGV4ZXJjaXNlIGluDQo+ID4gYW4NCj4gPj4gSW50ZXJuZXQgRHJhZnQu DQo+ID4+DQo+ID4+IENvbW1lbnRzPw0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+PiBSb24gQm9uaWNhDQo+ID4+IHZjYXJkOiAgICAgICB3d3cuYm9uaWNh Lm9yZy9yb24vcm9uYm9uaWNhLnZjZg0KPiA+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBkYyBtYWlsaW5nIGxpc3QNCj4g Pj4gZGNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kYw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gZGMgbWFpbGluZyBsaXN0DQo+ID4gZGNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RjDQo+IA0KPiAtLQ0KPiDmnY7mn6/nnb8NCj4gQ2hl Y2sgbXkgUEdQIGtleSBoZXJlOiBodHRwczovL3d3dy5hc2dhYXJkLm9yZy9+Y2RsL2NkbC5hc2MN Cj4gQ3VycmVudCB2Q2FyZCBoZXJlOiBodHRwczovL3d3dy5hc2dhYXJkLm9yZy9+Y2RsL2NkbC52 Y2YNCg0K From lufang@cisco.com Tue Dec 20 18:48:09 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337D11F0C3B for ; Tue, 20 Dec 2011 18:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqIR0uWNyrWo for ; Tue, 20 Dec 2011 18:48:08 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9BB1F0C38 for ; Tue, 20 Dec 2011 18:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=2511; q=dns/txt; s=iport; t=1324435688; x=1325645288; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=xIRRLAdnJXrtihxNmtPJhRAM+evTaTW2M0oNoG1jizc=; b=KLIJlSw/ntTDdiadLvgMat+56KhoXwsujdRIibxQUdfFiHpkUasJnZfD FCa/hdxEC3Dy5a5lrSLVUhwxwLdiCxA5ckcV4N3/ORgaP4eAnnsjmFpay deg7EGzcsnVSAG6shpjzg7Uo4mE5O8j1yUwwNexjh9t/oEGHwFQLSHXF3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcAANxH8U6tJXHB/2dsb2JhbAA5Cps7kFaBBYFyAQEBAwEBAQEPAR0KDyUQBwQCAQgOAwEDAQELBhcBBgEmHwMGCAEBBAESCAEZh1gImQcBnjuIVoJWYwSIN58Z X-IronPort-AV: E=Sophos;i="4.71,385,1320624000"; d="scan'208";a="45718682" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 21 Dec 2011 02:48:07 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pBL2m78H012034; Wed, 21 Dec 2011 02:48:07 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 20:48:07 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Dec 2011 20:48:06 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25078F49F5@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Scoping the Interim meeting Thread-Index: Acy/UFjTkv7a6r5mTy699yqvnJVhAwAG2YiQAAfHuuA= References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> From: "Luyuan Fang (lufang)" To: "Pat Thaler" , "Ronald Bonica" , X-OriginalArrivalTime: 21 Dec 2011 02:48:07.0769 (UTC) FILETIME=[F837A490:01CCBF8A] Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 02:48:09 -0000 Make sense. Thx. Luyuan > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Pat > Thaler > Sent: Tuesday, December 20, 2011 6:12 PM > To: Ronald Bonica; dc@ietf.org > Subject: Re: [dc] Scoping the Interim meeting >=20 > There is a fifth possibility for why a problem might be only in a small > minority of drafts > - it is a real problem that should be in the core data center problem > space, but only a small group of authors have identified it >=20 > Probably that explanation won't apply to most of the set, but it is > possible in the early days of people looking at a problem space from > different perspectives and we should apply our judgment rather than > making the cut just based on the number of drafts that spotted the > issue. >=20 > Pat >=20 > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Tuesday, December 20, 2011 11:48 AM > To: dc@ietf.org > Subject: [dc] Scoping the Interim meeting >=20 > Folks, >=20 > During the last few days, this list has produced an impressive > annotated bibliography of Internet Drafts. Thanks to all who have > contributed. >=20 > In preparation for the upcoming interim meeting, this group should > consider all of the "problem statement" drafts. Specifically, we should > make a list of problems that are called out by a majority of these > drafts. We will identify these problems as the core data center problem > space. >=20 > We should also make another list of problems that are called out by > only a small minority of drafts. Having made this second list, we will > explain why the problem is not commonly viewed. Possible answers are: >=20 > - it is not a real problem > - the problem is not unique to the data center > - the problem is unique to a particular service being offered in the DC > - the problem is unique to a particular data center network > architecture >=20 > It would be great if we could capture the output of this exercise in an > Internet Draft. >=20 > Comments? >=20 >=20 > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf >=20 >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc >=20 >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From cdl@asgaard.org Tue Dec 20 15:50:37 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7A71F0C43 for ; Tue, 20 Dec 2011 15:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7YjluuKLyYt for ; Tue, 20 Dec 2011 15:50:36 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id DE70F1F0C38 for ; Tue, 20 Dec 2011 15:50:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 9DBF9A0632F; Tue, 20 Dec 2011 23:50:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDE-uuFUzUVn; Tue, 20 Dec 2011 23:50:34 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id 47088A06321; Tue, 20 Dec 2011 23:50:34 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_7F02CE0F-40B5-4257-9955-B0DC7E7FFE32"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Christopher LILJENSTOLPE In-Reply-To: <238542D917511A45B6B8AA806E875E25078F4933@XMB-RCD-201.cisco.com> Date: Tue, 20 Dec 2011 15:50:33 -0800 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <238542D917511A45B6B8AA806E875E25078F4933@XMB-RCD-201.cisco.com> To: Luyuan Fang (lufang) X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Wed, 21 Dec 2011 06:50:59 -0800 Cc: Thomas Narten , Ronald Bonica , dc@ietf.org Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 23:50:37 -0000 --Apple-Mail=_7F02CE0F-40B5-4257-9955-B0DC7E7FFE32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, I would suggest that Tom Nadeau also be included, as he had = quite a bit of input pulling the SDN stuff together. Chris On 20Dec2011, at 13.00, Luyuan Fang (lufang) wrote: > Ron, >=20 > We think this is a very good idea.=20 > We'd like to volunteer to edit this problem analysis draft together. > Welcome everyone's input. >=20 > Thanks, > Luyuan and Thomas >=20 >=20 >> -----Original Message----- >> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >> Ronald Bonica >> Sent: Tuesday, December 20, 2011 2:48 PM >> To: dc@ietf.org >> Subject: [dc] Scoping the Interim meeting >>=20 >> Folks, >>=20 >> During the last few days, this list has produced an impressive >> annotated bibliography of Internet Drafts. Thanks to all who have >> contributed. >>=20 >> In preparation for the upcoming interim meeting, this group should >> consider all of the "problem statement" drafts. Specifically, we > should >> make a list of problems that are called out by a majority of these >> drafts. We will identify these problems as the core data center > problem >> space. >>=20 >> We should also make another list of problems that are called out by >> only a small minority of drafts. Having made this second list, we = will >> explain why the problem is not commonly viewed. Possible answers are: >>=20 >> - it is not a real problem >> - the problem is not unique to the data center >> - the problem is unique to a particular service being offered in the > DC >> - the problem is unique to a particular data center network >> architecture >>=20 >> It would be great if we could capture the output of this exercise in > an >> Internet Draft. >>=20 >> Comments? >>=20 >>=20 >> -------------------------- >> Ron Bonica >> vcard: www.bonica.org/ron/ronbonica.vcf >>=20 >>=20 >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_7F02CE0F-40B5-4257-9955-B0DC7E7FFE32 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJO8R9JAAoJEGmx2Mt/+Iw/1DYH/1+fPo26T64os3rj1/aoYYO2 sMNPabcniJDK3QFSw8P3+nS5FQYKYEW4QkBVossVNxQl3gXmGZrD5Kmb4RfIW8DR F3TwQsjPLosfRa17vy5MmRlq0kJDGodJwLv5GsT2CZb1YLOjC6DY363S+LrC3rxH Lw+Fnqkc2gHtMvqzD3/7tL0wPAUKGPWYtZPC1BmH2J+Zsna5m4X3plYeh3OTg5G+ roaRp8Zu1nHCbygWmrUYe3TXha6IVi1F0X/caPkAUu6ONWeCaT2jiHkn0yxjruz2 v5H2n2hm5kx5U3mRvRCCwXGVAGn93PKvN/lBSS5VEaEsgvFKZCUOAwnmgTHeSas= =Sifg -----END PGP SIGNATURE----- --Apple-Mail=_7F02CE0F-40B5-4257-9955-B0DC7E7FFE32-- From cdl@asgaard.org Tue Dec 20 15:51:27 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463601F0C3F for ; Tue, 20 Dec 2011 15:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjQPBeG9aLtM for ; Tue, 20 Dec 2011 15:51:26 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id C054A1F0C38 for ; Tue, 20 Dec 2011 15:51:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 79287A0635B; Tue, 20 Dec 2011 23:51:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbKBI1N6MHoE; Tue, 20 Dec 2011 23:51:24 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id 872E3A0634D; Tue, 20 Dec 2011 23:51:24 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_4AAC3672-8FBF-431C-8880-D0816A71A4F0"; protocol="application/pkcs7-signature"; micalg=sha1 From: Christopher LILJENSTOLPE Resent-Cc: Thomas Narten , Ron Bonica Resent-From: Christopher LILJENSTOLPE In-Reply-To: <238542D917511A45B6B8AA806E875E25078F4933@XMB-RCD-201.cisco.com> Date: Tue, 20 Dec 2011 15:50:33 -0800 Resent-Date: Tue, 20 Dec 2011 15:51:24 -0800 Resent-To: dc@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <238542D917511A45B6B8AA806E875E25078F4933@XMB-RCD-201.cisco.com> Message-Id: To: Luyuan Fang (lufang) X-Mailer: Apple Mail (2.1251.1) Resent-Message-Id: <20111220235124.872E3A0634D@asgaard.org> X-Mailman-Approved-At: Wed, 21 Dec 2011 06:50:59 -0800 Cc: Thomas Narten , Ronald Bonica , dc@ietf.org Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 23:51:27 -0000 --Apple-Mail=_4AAC3672-8FBF-431C-8880-D0816A71A4F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, I would suggest that Tom Nadeau also be included, as he had = quite a bit of input pulling the SDN stuff together. Chris On 20Dec2011, at 13.00, Luyuan Fang (lufang) wrote: > Ron, >=20 > We think this is a very good idea.=20 > We'd like to volunteer to edit this problem analysis draft together. > Welcome everyone's input. >=20 > Thanks, > Luyuan and Thomas >=20 >=20 >> -----Original Message----- >> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >> Ronald Bonica >> Sent: Tuesday, December 20, 2011 2:48 PM >> To: dc@ietf.org >> Subject: [dc] Scoping the Interim meeting >>=20 >> Folks, >>=20 >> During the last few days, this list has produced an impressive >> annotated bibliography of Internet Drafts. Thanks to all who have >> contributed. >>=20 >> In preparation for the upcoming interim meeting, this group should >> consider all of the "problem statement" drafts. Specifically, we > should >> make a list of problems that are called out by a majority of these >> drafts. We will identify these problems as the core data center > problem >> space. >>=20 >> We should also make another list of problems that are called out by >> only a small minority of drafts. Having made this second list, we = will >> explain why the problem is not commonly viewed. Possible answers are: >>=20 >> - it is not a real problem >> - the problem is not unique to the data center >> - the problem is unique to a particular service being offered in the > DC >> - the problem is unique to a particular data center network >> architecture >>=20 >> It would be great if we could capture the output of this exercise in > an >> Internet Draft. >>=20 >> Comments? >>=20 >>=20 >> -------------------------- >> Ron Bonica >> vcard: www.bonica.org/ron/ronbonica.vcf >>=20 >>=20 >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_4AAC3672-8FBF-431C-8880-D0816A71A4F0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOkjCCBqgw ggWQoAMCAQICAwKDtzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTExMDUwNjIxNTgwN1oXDTEyMDUwNzA3MDYyNlowQjEgMB4GA1UEDRMXNDIwODEzLXEyMUxR NjVER3d5Ym1hOGgxHjAcBgkqhkiG9w0BCQEWD2NkbEBhc2dhYXJkLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAONTIaXeDIHfzoKXge4k72n2kIBMXfwfjjS//8R3GWQ2qUfaQMQN CjXzPSZmrV+Otrb7CwOsrJ+TEB4HXYMSZ2SpyYbwIVMscCA4ddrzzl6/WxTfyKnK7MtWPjGJomOI VuPvJUvYUSvdoZIKoTTEMQ93/erkSOOSe4iM1Xr1y5T4pA7eegj5iUFNGq1qIUotBuP6DNMgRNPL qqiZF3stBpVZVPBi3wfxdjvqi+ZMmAUouXAyKELBvIHHaf0UwYHh3DE1AXJjxa/JZGK5ITjQVmju gcteo34JTGHwK4CxzU+lM3R0f4JTXc7ca7xPXGRWkL5RYAMINqLIjah8wimLxGMCAwEAAaOCA1ow ggNWMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAdBgNVHQ4EFgQUKVx4B85WgL6IKSgFEwW4S4ttilEwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ ljVO8tS4UYIwGgYDVR0RBBMwEYEPY2RsQGFzZ2FhcmQub3JnMIIB0QYDVR0gBIIByDCCAcQwggHA BgsrBgEEAYG1NwECAjCCAa8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0 ZS5wZGYwggFFBggrBgEFBQcCAjCCATcwJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwAwIBARqCAQpUaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBD bGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSBwb2xpY3kgYW5kIG1heSBiZSByZWxpZWQgdXBvbiBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBhbmQgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4gTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkITA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS8wDQYJKoZIhvcNAQEFBQADggEBAIDI46nVmgDavMwuhB0iFv6g5X8uQtG+haOSbWiMENPIZ2Ob kHaugQ8kDxz6qY0rHSKJiV6OuL9lmvfC8z5ymQzKy2Vi5wGqGWK3v7Bz0zeufi7fIofA6ZZhjrVA EpnT6kupU4YV50VZxFeflBuDwC/eci1gypGZVCssKOan1tdw9AqMbWfSQyl6UfyFMJ//TeE5kxN3 7FEIJZ/Nm/Bg0OaQRiPQAZKboD57ac8CG0iXJdktOf0qSiY8LXtBXHRN+2qr42Ntm8mJ7YDgh6Rp wUkGHOWn99FShXWJr0xb6LyxNeDT8ke2pJXwW1bjcxBX5B+ss83un32DZydewNmHWwIwggfiMIIF yqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYD VQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTRaFw0x MjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+c QhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsu z9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89l GxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//j diSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggNbMIID VzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmC AQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0 dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRl czANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/Kf/HMM//gf8F zwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k6Glyoyvc7LMr dpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZNNfqZZK/5Oto 7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSCowBSItyD/5aF wZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9h5jnnMM9UaZD cxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbgF9uJBekCqJsw x5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3M6a5V+KoNLhs Vi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieBJTo49Iyt77EC Ohz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R5DqpA2bFIOE5 6pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgMCg7cwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTExMjIwMjM1MTI0WjAjBgkqhkiG9w0BCQQxFgQUT8Aq3vP4jrkLxQi1qMru WYzb60EwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC g7cwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwKD tzANBgkqhkiG9w0BAQEFAASCAQCXEfsy2BhMIDfowcEK42CBN6hxZfv4YAYs6A4QJSEscXbr4ZOz EGtRYXbjSwHVD9nNQnRjrwMdWw51S+jdHfhlMhoA4V4E9Jgpr9oqVCM5nIS5VJZSeIPUIi6aS0Cf 9HOnnME1zONVDIaOX9u40iHJC6YC/STOClgtgXbFjqt2rbjJkiPVUMIf9SgcyliFdFiioy3A5xZs D/HTKhePMJ+lXwIEmSrHqYDhwKvR14DzfoOTWcWTAxMYB4sSGU0jWXv7fobb9FR31jrEHBUxwZQC FLZ+MiedOPMh50B/RrHPYn4J1ly2jd3Blry3Bv93wk7NVMiqjoD+JF/yfPD5ZZgiAAAAAAAA --Apple-Mail=_4AAC3672-8FBF-431C-8880-D0816A71A4F0-- From linda.dunbar@huawei.com Wed Dec 21 06:55:33 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B506C21F8AB9 for ; Wed, 21 Dec 2011 06:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25QudHE4wAEh for ; Wed, 21 Dec 2011 06:55:33 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D6E3B21F8A70 for ; Wed, 21 Dec 2011 06:55:32 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABZ60840; Wed, 21 Dec 2011 09:55:32 -0500 (EST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Dec 2011 06:54:02 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 21 Dec 2011 06:54:01 -0800 From: Linda Dunbar To: "Luyuan Fang (lufang)" , Ronald Bonica , "dc@ietf.org" Thread-Topic: [dc] Scoping the Interim meeting Thread-Index: Acy/UFjTkv7a6r5mTy699yqvnJVhAwABZZ9AACaZPeA= Date: Wed, 21 Dec 2011 14:54:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F61A67B60A@dfweml505-mbx> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <238542D917511A45B6B8AA806E875E25078F4933@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E25078F4933@XMB-RCD-201.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 14:55:33 -0000 I would like to help too. Please keep me included.=20 Thanks, Linda Dunbar > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Luyuan Fang (lufang) > Sent: Tuesday, December 20, 2011 3:00 PM > To: Ronald Bonica; dc@ietf.org > Cc: Thomas Narten > Subject: Re: [dc] Scoping the Interim meeting >=20 > Ron, >=20 > We think this is a very good idea. > We'd like to volunteer to edit this problem analysis draft together. > Welcome everyone's input. >=20 > Thanks, > Luyuan and Thomas >=20 >=20 > > -----Original Message----- > > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > > Ronald Bonica > > Sent: Tuesday, December 20, 2011 2:48 PM > > To: dc@ietf.org > > Subject: [dc] Scoping the Interim meeting > > > > Folks, > > > > During the last few days, this list has produced an impressive > > annotated bibliography of Internet Drafts. Thanks to all who have > > contributed. > > > > In preparation for the upcoming interim meeting, this group should > > consider all of the "problem statement" drafts. Specifically, we > should > > make a list of problems that are called out by a majority of these > > drafts. We will identify these problems as the core data center > problem > > space. > > > > We should also make another list of problems that are called out by > > only a small minority of drafts. Having made this second list, we > will > > explain why the problem is not commonly viewed. Possible answers are: > > > > - it is not a real problem > > - the problem is not unique to the data center > > - the problem is unique to a particular service being offered in the > DC > > - the problem is unique to a particular data center network > > architecture > > > > It would be great if we could capture the output of this exercise in > an > > Internet Draft. > > > > Comments? > > > > > > -------------------------- > > Ron Bonica > > vcard: www.bonica.org/ron/ronbonica.vcf > > > > > > _______________________________________________ > > dc mailing list > > dc@ietf.org > > https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From ning.so@verizon.com Wed Dec 21 07:24:00 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7E221F867F for ; Wed, 21 Dec 2011 07:24:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WODnHQihTvJv for ; Wed, 21 Dec 2011 07:23:59 -0800 (PST) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id B4F8721F85A8 for ; Wed, 21 Dec 2011 07:23:58 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe03.verizon.com with ESMTP; 21 Dec 2011 15:23:32 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; d="scan'208";a="196258413" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 21 Dec 2011 15:23:32 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.26]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Wed, 21 Dec 2011 10:23:32 -0500 To: Ronald Bonica , "dc@ietf.org" Date: Wed, 21 Dec 2011 10:23:30 -0500 Thread-Topic: Scoping the Interim meeting Thread-Index: Acy/UFjTkv7a6r5mTy699yqvnJVhAwAo1mog Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 15:24:00 -0000 Looks like we have quite a few people who are willing to help. Has anyone = started "putting words down on paper"? Perhaps we can begin by formulating= a rough structure of the draft, and have one/two volunteer(s) focusing on = each section/problem, and all others can contribute text/ideas as they see = fit. =20 I would like to offer my service on this effort as well. =20 =A0 Best regards, =A0 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =A0 -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Ronald = Bonica Sent: Tuesday, December 20, 2011 1:48 PM To: dc@ietf.org Subject: [dc] Scoping the Interim meeting Folks, During the last few days, this list has produced an impressive annotated bi= bliography of Internet Drafts. Thanks to all who have contributed. In preparation for the upcoming interim meeting, this group should consider= all of the "problem statement" drafts. Specifically, we should make a list= of problems that are called out by a majority of these drafts. We will ide= ntify these problems as the core data center problem space. We should also make another list of problems that are called out by only a = small minority of drafts. Having made this second list, we will explain why= the problem is not commonly viewed. Possible answers are: - it is not a real problem - the problem is not unique to the data center - the problem is unique to a particular service being offered in the DC - the problem is unique to a particular data center network architecture It would be great if we could capture the output of this exercise in an Int= ernet Draft.=20 Comments? -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From vumip1@gmail.com Wed Dec 21 07:32:54 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7296C21F8AA8 for ; Wed, 21 Dec 2011 07:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd9ABQf2wDoj for ; Wed, 21 Dec 2011 07:32:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7AB21F8A80 for ; Wed, 21 Dec 2011 07:32:53 -0800 (PST) Received: by iaen33 with SMTP id n33so4032961iae.31 for ; Wed, 21 Dec 2011 07:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lbPQPwP2TcSqcH3EyLQPC3xoZdr7TXYkGfmB7K2OJUM=; b=oj9hEkuo8UW4es8rDgl4lXLt/0NaQj8LHS/b3sGZROycdE+d424JCxEdgUBOzcQwqM 5TtcYBLBQPRPmhlVsU3JxifIF69Bu6RsLsh4aal7zRu1w/+E/16Nhm83MoUU3RnPx61K ggrUKtajuH4Ih0QqSn2KBB3U4qzNSayA7hdBw= MIME-Version: 1.0 Received: by 10.50.194.225 with SMTP id hz1mr3962198igc.1.1324481571005; Wed, 21 Dec 2011 07:32:51 -0800 (PST) Received: by 10.50.170.105 with HTTP; Wed, 21 Dec 2011 07:32:50 -0800 (PST) In-Reply-To: <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> Date: Wed, 21 Dec 2011 10:32:50 -0500 Message-ID: From: Bhumip Khasnabish To: "So, Ning" Content-Type: multipart/alternative; boundary=14dae93411ab8d23ff04b49be5ff Cc: Ronald Bonica , "dc@ietf.org" Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 15:32:54 -0000 --14dae93411ab8d23ff04b49be5ff Content-Type: text/plain; charset=ISO-8859-1 We have an existing draft that surveys industry work items related to cloud computing, networking and services (DC items are included in it) http://tools.ietf.org/id/draft-khasnabish-cloud-industry-workitems-survey-01.txt We are planning to update that, and look forward to comments and suggestions. On Wed, Dec 21, 2011 at 10:23 AM, So, Ning wrote: > Looks like we have quite a few people who are willing to help. Has anyone > started "putting words down on paper"? Perhaps we can begin by formulating > a rough structure of the draft, and have one/two volunteer(s) focusing on > each section/problem, and all others can contribute text/ideas as they see > fit. > > I would like to offer my service on this effort as well. > > > Best regards, > > Ning So > Verizon Corporate Technology > (office) 972-729-7905 > (Cell) 972-955-0914 > > > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Tuesday, December 20, 2011 1:48 PM > To: dc@ietf.org > Subject: [dc] Scoping the Interim meeting > > Folks, > > During the last few days, this list has produced an impressive annotated > bibliography of Internet Drafts. Thanks to all who have contributed. > > In preparation for the upcoming interim meeting, this group should > consider all of the "problem statement" drafts. Specifically, we should > make a list of problems that are called out by a majority of these drafts. > We will identify these problems as the core data center problem space. > > We should also make another list of problems that are called out by only a > small minority of drafts. Having made this second list, we will explain why > the problem is not commonly viewed. Possible answers are: > > - it is not a real problem > - the problem is not unique to the data center > - the problem is unique to a particular service being offered in the DC > - the problem is unique to a particular data center network architecture > > It would be great if we could capture the output of this exercise in an > Internet Draft. > > Comments? > > > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf > > > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc > --14dae93411ab8d23ff04b49be5ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
We have an existing draft that surv= eys industry work items related to
cloud computing, networking and ser= vices (DC items are included in it)
=A0
=A0
We are planning to update that, and= look forward to comments and suggestions.
=A0
On Wed, Dec 21, 2011 at 10:23 AM, So, Ning <ning.so@verizon.com= > wrote:
Looks like we have quite a few people= who are willing to help. =A0Has anyone started "putting words down on= paper"? =A0Perhaps we can begin by formulating a rough structure of t= he draft, and have one/two volunteer(s) focusing on each section/problem, a= nd all others can contribute text/ideas as they see fit.

I would like to offer my service on this effort as well.

=A0
= Best regards,
=A0
Ning So
Verizon Corporat= e Technology
(office) 972-729-7905
(Cell) 972-955-0914=
=A0

-----Original Message-----
From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Ronald Bonic= a
Sent: Tuesday, December 20, 2011 1:48 PM
To: dc@ietf.org
Subject: [dc] Scoping the Interim meeting

Folks,

During the last few days, this list has pro= duced an impressive annotated bibliography of Internet Drafts. Thanks to al= l who have contributed.

In preparation for the upcoming interim meet= ing, this group should consider all of the "problem statement" dr= afts. Specifically, we should make a list of problems that are called out b= y a majority of these drafts. We will identify these problems as the core d= ata center problem space.

We should also make another list of problems that are called out by onl= y a small minority of drafts. Having made this second list, we will explain= why the problem is not commonly viewed. Possible answers are:

- it = is not a real problem
- the problem is not unique to the data center
- the problem is unique t= o a particular service being offered in the DC
- the problem is unique t= o a particular data center network architecture

It would be great if= we could capture the output of this exercise in an Internet Draft.

Comments?


--------------------------
Ron Bonica
vcard:= =A0 =A0 =A0 www.bonica.org/ron/ronbonica.vcf


___________________= ____________________________
dc mailing list
dc@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dc
_____________________________________= __________
dc mailing list
dc@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dc


=A0 --14dae93411ab8d23ff04b49be5ff-- From melinda.shore@gmail.com Wed Dec 21 08:26:37 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8271F0C51 for ; Wed, 21 Dec 2011 08:26:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gi2VGdngR7yn for ; Wed, 21 Dec 2011 08:26:37 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 476621F0C4F for ; Wed, 21 Dec 2011 08:26:37 -0800 (PST) Received: by ghbg18 with SMTP id g18so1900361ghb.31 for ; Wed, 21 Dec 2011 08:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xP8vCiOYBFHMtduHNsGu5xgzmuyL+6Jp7R019iO5EfM=; b=I3K4BAt7UE/3TO4+g5WNjOE8CvV9Qyeh2AVUznGdtIpXOcqVaAsihIMQ77nm1mLcCb ZhKdeOIWhs5+kCeESL1u1Q1/VWp8h2qFPMxeGmb9L0A7RrKSQTi8b0sYmOMZZfsu6jND RoC2YhdUtRv6NWtzjyxv2hLTK86U1OMvt2dM0= Received: by 10.50.40.199 with SMTP id z7mr4234233igk.13.1324484795297; Wed, 21 Dec 2011 08:26:35 -0800 (PST) Received: from polypro.local (66-230-87-15-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.87.15]) by mx.google.com with ESMTPS id ew6sm8739215igc.4.2011.12.21.08.26.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Dec 2011 08:26:34 -0800 (PST) Message-ID: <4EF208B6.9050008@gmail.com> Date: Wed, 21 Dec 2011 07:26:30 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.24) Gecko/20111103 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: dc@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 16:26:37 -0000 On 12/21/11 6:32 AM, Bhumip Khasnabish wrote: > We have an existing draft that surveys industry work items related to > cloud computing, networking and services (DC items are included in it) > http://tools.ietf.org/id/draft-khasnabish-cloud-industry-workitems-survey-01.txt I would be very, very disappointed to see this receive time on an IETF meeting agenda. I think your time would have been far better spent putting together an architectural framework document or another framework document - something problem-focused and coherent. And I'm *still* not clear why you're not referencing NIST work - that's a nontrivial oversight. Melinda From vumip1@gmail.com Wed Dec 21 08:50:44 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D162521F89B8 for ; Wed, 21 Dec 2011 08:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEQD6DdMHG99 for ; Wed, 21 Dec 2011 08:50:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEF211E8094 for ; Wed, 21 Dec 2011 08:50:44 -0800 (PST) Received: by iaen33 with SMTP id n33so4125034iae.31 for ; Wed, 21 Dec 2011 08:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7p1JjJnpSpwTWZOIgNMLneMI4TkoBZtLllFmbNcLeGk=; b=R52ZAr+9NT6lV0sQJirWgkK+ucOdUSNjqXLVx+dcwBOPRz5BFcLvRWeqKbExbFbc0i GmavTvkgAueg1mKEvG+oW5BeTGBqaWwjO1eBkIdnI+WdUDQF1WlVluTBJCZ6PZaanf3Y JF3O5HDd5AJ+CzkSwqbVg2omzqheJUkxprs6Q= MIME-Version: 1.0 Received: by 10.50.183.199 with SMTP id eo7mr4428510igc.5.1324486243886; Wed, 21 Dec 2011 08:50:43 -0800 (PST) Received: by 10.50.170.105 with HTTP; Wed, 21 Dec 2011 08:50:43 -0800 (PST) In-Reply-To: <4EF208B6.9050008@gmail.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <4EF208B6.9050008@gmail.com> Date: Wed, 21 Dec 2011 11:50:43 -0500 Message-ID: From: Bhumip Khasnabish To: Melinda Shore Content-Type: multipart/alternative; boundary=14dae934042d13a70904b49cfc76 Cc: dc@ietf.org Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 16:50:44 -0000 --14dae934042d13a70904b49cfc76 Content-Type: text/plain; charset=ISO-8859-1 * Pls let us know which NIST doc (URL please) you are referring to related to Cloud/DataCater work items. * Also, we'll be updating the Ref. framework draft soon, appreciate your constructive comments and suggestions .. http://tools.ietf.org/id/draft-khasnabish-cloud-reference-framework-01.txt On Wed, Dec 21, 2011 at 11:26 AM, Melinda Shore wrote: > On 12/21/11 6:32 AM, Bhumip Khasnabish wrote: > >> We have an existing draft that surveys industry work items related to >> cloud computing, networking and services (DC items are included in it) >> http://tools.ietf.org/id/**draft-khasnabish-cloud-** >> industry-workitems-survey-01.**txt >> > > I would be very, very disappointed to see this receive time on an > IETF meeting agenda. I think your time would have been far better > spent putting together an architectural framework document or another > framework document - something problem-focused and coherent. And > I'm *still* not clear why you're not referencing NIST work - that's > a nontrivial oversight. > > Melinda > > ______________________________**_________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/**listinfo/dc > --14dae934042d13a70904b49cfc76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
* Pls let us know which NIST doc (URL please)
you are referring to related to Cloud/DataCater work items.
=A0
* Also, we'll be updating the Ref. framework draft soon, appreciat= e your constructive
comments and suggestions ..
On Wed, Dec 21, 2011 at 11:26 AM, Melinda Shore = <melinda.sh= ore@gmail.com> wrote:
On 12/21/11 6:32 AM, Bhumip Khasnabish wrote:
We have an existing draft that survey= s industry work items related to
cloud computing, networking and service= s (DC items are included in it)
http://tools.ietf.org/id/draft-k= hasnabish-cloud-industry-workitems-survey-01.txt

I would be very, very disappointed to see this receive time on an=
IETF meeting agenda. =A0I think your time would have been far betterspent putting together an architectural framework document or another
framework document - something problem-focused and coherent. =A0And
I= 9;m *still* not clear why you're not referencing NIST work - that's=
a nontrivial oversight.

Melinda= =20

______________________________________________= _
dc mailing list
dc= @ietf.org
https://www.ietf.org/mailman/listinfo/dc


=A0 --14dae934042d13a70904b49cfc76-- From narten@us.ibm.com Wed Dec 21 10:31:09 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190E111E80AA for ; Wed, 21 Dec 2011 10:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G6aEKLMK5tf for ; Wed, 21 Dec 2011 10:31:08 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1943F11E80B5 for ; Wed, 21 Dec 2011 10:31:08 -0800 (PST) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 21 Dec 2011 11:31:07 -0700 Received: from d03relay01.boulder.ibm.com (9.17.195.226) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 21 Dec 2011 11:31:05 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBLIUrv4110348 for ; Wed, 21 Dec 2011 11:30:55 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBLIUnk5001130 for ; Wed, 21 Dec 2011 11:30:49 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-199-141.mts.ibm.com [9.65.199.141]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBLIUmeC000865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2011 11:30:49 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pBLIUiZA017188; Wed, 21 Dec 2011 13:30:45 -0500 Message-Id: <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> To: "So, Ning" In-reply-to: <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> Comments: In-reply-to "So, Ning" message dated "Wed, 21 Dec 2011 10:23:30 -0500." Date: Wed, 21 Dec 2011 13:30:44 -0500 From: Thomas Narten x-cbid: 11122118-1780-0000-0000-000001CCFFDA X-IBM-ISS-SpamDetectors: X-IBM-ISS-DetailInfo: BY=3.00000242; HX=3.00000180; KW=3.00000007; PH=3.00000001; SC=3.00000001; SDB=6.00098082; UDB=6.00025410; UTC=2011-12-21 18:31:06 Cc: Ronald Bonica , "dc@ietf.org" Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 18:31:09 -0000 We sure have a lot of volunteers wanting to help. That is fine at one level, but misses the bigger point. The best way to help is to articulate a specific problem or area. Do so on this list in a single message. We don't need yet more documents (at least not yet). 2-4 paragraphs (no more). Think "elevator pitch" (http://en.wikipedia.org/wiki/Elevator_pitch). You only get a couple of minutes to make your case, and if you can't do so, either you don't understand the problem yourself well enough, or the value-proposition just isn't compelling. So far, I haven't seen discussions of specific problems (or problem areas). What I'm seeing is pointers to lots of drafts, many of which (for those that I've looked at) don't crisply get at a real, tangible problem that I understand and think the IETF can/should work on. Bonus points for showing: 1) an operator (or some other clear customer/consumer technology) that says "yes, that is what I need, and if it was available today, I'd use it" 2) a vendor saying "here is what my customers are telling me will solve a problem of theirs", and we think an IETF standard is needed. 3) demonstration of a clear technical/protocol gap between what is available today, and what is needed to address the problem. Thomas From melinda.shore@gmail.com Wed Dec 21 10:39:43 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FF911E8089 for ; Wed, 21 Dec 2011 10:39:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW91tq2YhCaB for ; Wed, 21 Dec 2011 10:39:43 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1761111E80A6 for ; Wed, 21 Dec 2011 10:39:40 -0800 (PST) Received: by iaen33 with SMTP id n33so4259023iae.31 for ; Wed, 21 Dec 2011 10:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=p/kS8X00HrjWGCXlO0u4UpTjFQXBYfDifFvkX/w4ay8=; b=JrCJPiLZ49r5TBjR3g2Y11hfX+Ny9AFtXG7IKHnFLN4J/zoGNrh4hFZ7kk/M/GFyw9 rRTHJd8nz57XDw6PqhE77EOq/Vyxkm4Jwyq3dJ0DBm/AZISpJwkljWNe4mOzq5kHaI2r aWILxE1OwXdLqDiXlGarG/pR9nJs7b+9X1sIc= Received: by 10.43.45.137 with SMTP id uk9mr8002836icb.52.1324492779637; Wed, 21 Dec 2011 10:39:39 -0800 (PST) Received: from polypro.local (66-230-87-15-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.87.15]) by mx.google.com with ESMTPS id d19sm19682149ibh.8.2011.12.21.10.39.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Dec 2011 10:39:38 -0800 (PST) Message-ID: <4EF227E7.20104@gmail.com> Date: Wed, 21 Dec 2011 09:39:35 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.24) Gecko/20111103 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: dc@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> In-Reply-To: <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 18:39:43 -0000 On 12/21/11 9:30 AM, Thomas Narten wrote: > The best way to help is to articulate a specific problem or area. That bears repeating. > Do so on this list in a single message. We don't need yet more > documents (at least not yet). I'm working with a Yingjie Gu and Senthil Sivakumar on the state migration problem, but it's unclear to me that it belongs in an operations-focused group. The problem occurs in data centers but I don't think it's a data center problem per se. Totally the chairs' call. Melinda From narten@us.ibm.com Wed Dec 21 10:46:48 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E56211E8098 for ; Wed, 21 Dec 2011 10:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSlMqLUzIZll for ; Wed, 21 Dec 2011 10:46:47 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 7B56D11E8073 for ; Wed, 21 Dec 2011 10:46:47 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 21 Dec 2011 13:46:46 -0500 Received: from d01relay04.pok.ibm.com (9.56.227.236) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 21 Dec 2011 13:46:23 -0500 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBLIkJoq224652 for ; Wed, 21 Dec 2011 13:46:20 -0500 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBLIkGhD007296 for ; Wed, 21 Dec 2011 11:46:17 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-199-141.mts.ibm.com [9.65.199.141]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBLIkECR007183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2011 11:46:16 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pBLIkDdj017276; Wed, 21 Dec 2011 13:46:14 -0500 Message-Id: <201112211846.pBLIkDdj017276@cichlid.raleigh.ibm.com> To: Melinda Shore In-reply-to: <4EF227E7.20104@gmail.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <4EF227E7.20104@gmail.com> Comments: In-reply-to Melinda Shore message dated "Wed, 21 Dec 2011 09:39:35 -0900." Date: Wed, 21 Dec 2011 13:46:13 -0500 From: Thomas Narten x-cbid: 11122118-9360-0000-0000-000001BD9AE8 Cc: dc@ietf.org Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 18:46:48 -0000 Hi Melinda. > I'm working with a Yingjie Gu and Senthil Sivakumar on the state > migration problem, but it's unclear to me that it belongs in an > operations-focused group. The problem occurs in data centers but > I don't think it's a data center problem per se. Totally the > chairs' call. Great! That said, let me suggest we *not* get hung up on process and "what area is the right place to discuss" before we even start. Focus on the problem statement. If a problem has validity, we can easily figure out later *where* to discuss it. Thomas From spencer@wonderhamster.org Wed Dec 21 15:00:14 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9411E80CB for ; Wed, 21 Dec 2011 15:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5+8za+Dez9D for ; Wed, 21 Dec 2011 15:00:13 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 608B311E80CA for ; Wed, 21 Dec 2011 15:00:13 -0800 (PST) Received: from [192.168.12.176] ([50.58.7.243]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MU0ld-1RDH901Ks5-00REWk; Wed, 21 Dec 2011 18:00:12 -0500 Message-ID: <4EF264FA.5030205@wonderhamster.org> Date: Wed, 21 Dec 2011 17:00:10 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dc@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> In-Reply-To: <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:n2bmR2izK1j4SvBUUNFLLosIZAsZtq8rVfy6M6cN6Cl XiHMIsJ/dVhEXsjiNIB7+u3icvtBag2Rvge6feBwMjXKbAiSpQ 4hpw2uHqL6KwKz/0D7nLWQfV8wp15r6ca8755Z5Eaj8FyG9E/f aptYtjnUVysXcpbH/YmRgogLYwUUtzVQPSKfVU+nadR3sJE9cd 01fe4nf1R2BhR9gnSSqpV0BxF3fzBXKMPO5aZNcJZzoGAKvtRi /tjGUN8kbY4+JIkJTgy23ove6BGN+9z7SMYWWCILPeU7dig+3s Ap+IhIKb2ygBtVhHSER3YjbYja+cV1rqevI2TNrZgvCSZX8sXU VZAZLVxluYodhKOcXafeEKllP8eED1/mPplEXumJf Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 23:00:14 -0000 On 12/21/2011 12:30 PM, Thomas Narten wrote: > We sure have a lot of volunteers wanting to help. That is fine at one > level, but misses the bigger point. > > The best way to help is to articulate a specific problem or area. > > Do so on this list in a single message. We don't need yet more > documents (at least not yet). > > 2-4 paragraphs (no more). Think "elevator pitch" > (http://en.wikipedia.org/wiki/Elevator_pitch). > > You only get a couple of minutes to make your case, and if you can't > do so, either you don't understand the problem yourself well enough, > or the value-proposition just isn't compelling. Thomas may be too modest to suggest that people think about what's recommended in http://tools.ietf.org/html/rfc5434, but I can promise you that at least one IAB member is hoping to see people reading it :-) For reference, the first item on the list of goals in RFC 5434 is showing that - there is a problem that needs solving, and the IETF is the right group to attempt solving it. And, just in case "elevator pitch" is not a familiar idiom for you, the idea is that you get on an elevator, recognize someone on the elevator who will make a decision about your idea, and start talking - remembering that you don't know what floor your decision maker will get off on, so you need to say the most important thing first, then the second most, and so forth. I hope this is helpful. Spencer > So far, I haven't seen discussions of specific problems (or problem > areas). What I'm seeing is pointers to lots of drafts, many of which > (for those that I've looked at) don't crisply get at a real, tangible > problem that I understand and think the IETF can/should work on. Bonus > points for showing: > > 1) an operator (or some other clear customer/consumer technology) that > says "yes, that is what I need, and if it was available today, I'd > use it" > > 2) a vendor saying "here is what my customers are telling me will > solve a problem of theirs", and we think an IETF standard is > needed. > > 3) demonstration of a clear technical/protocol gap between what is > available today, and what is needed to address the problem. > > Thomas > > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc > From xuxiaohu@huawei.com Wed Dec 21 17:24:55 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B070F21F8AA8 for ; Wed, 21 Dec 2011 17:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFFAElP4V117 for ; Wed, 21 Dec 2011 17:24:54 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id AC8D921F8A58 for ; Wed, 21 Dec 2011 17:24:54 -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 <0LWK00CJEZVOML@szxga03-in.huawei.com> for dc@ietf.org; Thu, 22 Dec 2011 09:23:48 +0800 (CST) Received: from szxrg01-dlp.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 <0LWK000YDZVOYA@szxga03-in.huawei.com> for dc@ietf.org; Thu, 22 Dec 2011 09:23:48 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFY80137; Thu, 22 Dec 2011 09:23:48 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Dec 2011 09:23:42 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 22 Dec 2011 09:23:45 +0800 Date: Thu, 22 Dec 2011 01:23:45 +0000 From: Xuxiaohu In-reply-to: <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> X-Originating-IP: [10.108.4.80] To: Thomas Narten , "So, Ning" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762AF0@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dc] Scoping the Interim meeting Thread-index: Acy/UFjTkv7a6r5mTy699yqvnJVhAwAo1mog//+vywD//wTLcA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> Cc: Ronald Bonica , "dc@ietf.org" Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 01:24:55 -0000 RnVsbHkgYWdyZWUuIEl0J3Mgbm8gbGF0ZSB0byBzdW1tYXJpemUgdGhlIHJlYWwgcHJvYmxlbXMg aW4gb25lIGRvYyBhZnRlciB2YXJpb3VzIHByb2JsZW1zIGhhdmUgYmVlbiBmdWxseSBkaXNjdXNz ZWQgYW5kIHZlcmlmaWVkIG9uZS1ieS1vbmUgaW4gdGhlIG1haWxpbmctbGlzdC4NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogZGMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gVGhvbWFzDQo+ IE5hcnRlbg0KPiC3osvNyrG85DogMjAxMcTqMTLUwjIyyNUgMjozMQ0KPiDK1bz+yMs6IFNvLCBO aW5nDQo+ILOty806IFJvbmFsZCBCb25pY2E7IGRjQGlldGYub3JnDQo+INb3zOI6IFJlOiBbZGNd IFNjb3BpbmcgdGhlIEludGVyaW0gbWVldGluZw0KPiANCj4gV2Ugc3VyZSBoYXZlIGEgbG90IG9m IHZvbHVudGVlcnMgd2FudGluZyB0byBoZWxwLiBUaGF0IGlzIGZpbmUgYXQgb25lDQo+IGxldmVs LCBidXQgbWlzc2VzIHRoZSBiaWdnZXIgcG9pbnQuDQo+IA0KPiBUaGUgYmVzdCB3YXkgdG8gaGVs cCBpcyB0byBhcnRpY3VsYXRlIGEgc3BlY2lmaWMgcHJvYmxlbSBvciBhcmVhLg0KPiANCj4gRG8g c28gb24gdGhpcyBsaXN0IGluIGEgc2luZ2xlIG1lc3NhZ2UuIFdlIGRvbid0IG5lZWQgeWV0IG1v cmUNCj4gZG9jdW1lbnRzIChhdCBsZWFzdCBub3QgeWV0KS4NCj4gDQo+IDItNCBwYXJhZ3JhcGhz IChubyBtb3JlKS4gIFRoaW5rICJlbGV2YXRvciBwaXRjaCINCj4gKGh0dHA6Ly9lbi53aWtpcGVk aWEub3JnL3dpa2kvRWxldmF0b3JfcGl0Y2gpLg0KPiANCj4gWW91IG9ubHkgZ2V0IGEgY291cGxl IG9mIG1pbnV0ZXMgdG8gbWFrZSB5b3VyIGNhc2UsIGFuZCBpZiB5b3UgY2FuJ3QNCj4gZG8gc28s IGVpdGhlciB5b3UgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSB5b3Vyc2VsZiB3ZWxsIGVu b3VnaCwNCj4gb3IgdGhlIHZhbHVlLXByb3Bvc2l0aW9uIGp1c3QgaXNuJ3QgY29tcGVsbGluZy4N Cj4gDQo+IFNvIGZhciwgSSBoYXZlbid0IHNlZW4gZGlzY3Vzc2lvbnMgb2Ygc3BlY2lmaWMgcHJv YmxlbXMgKG9yIHByb2JsZW0NCj4gYXJlYXMpLiBXaGF0IEknbSBzZWVpbmcgaXMgcG9pbnRlcnMg dG8gbG90cyBvZiBkcmFmdHMsIG1hbnkgb2Ygd2hpY2gNCj4gKGZvciB0aG9zZSB0aGF0IEkndmUg bG9va2VkIGF0KSBkb24ndCBjcmlzcGx5IGdldCBhdCBhIHJlYWwsIHRhbmdpYmxlDQo+IHByb2Js ZW0gdGhhdCBJIHVuZGVyc3RhbmQgYW5kIHRoaW5rIHRoZSBJRVRGIGNhbi9zaG91bGQgd29yayBv bi4gQm9udXMNCj4gcG9pbnRzIGZvciBzaG93aW5nOg0KPiANCj4gMSkgYW4gb3BlcmF0b3IgKG9y IHNvbWUgb3RoZXIgY2xlYXIgY3VzdG9tZXIvY29uc3VtZXIgdGVjaG5vbG9neSkgdGhhdA0KPiAg ICBzYXlzICJ5ZXMsIHRoYXQgaXMgd2hhdCBJIG5lZWQsIGFuZCBpZiBpdCB3YXMgYXZhaWxhYmxl IHRvZGF5LCBJJ2QNCj4gICAgdXNlIGl0Ig0KPiANCj4gMikgYSB2ZW5kb3Igc2F5aW5nICJoZXJl IGlzIHdoYXQgbXkgY3VzdG9tZXJzIGFyZSB0ZWxsaW5nIG1lIHdpbGwNCj4gICAgc29sdmUgYSBw cm9ibGVtIG9mIHRoZWlycyIsIGFuZCB3ZSB0aGluayBhbiBJRVRGIHN0YW5kYXJkIGlzDQo+ICAg IG5lZWRlZC4NCj4gDQo+IDMpIGRlbW9uc3RyYXRpb24gb2YgYSBjbGVhciB0ZWNobmljYWwvcHJv dG9jb2wgZ2FwIGJldHdlZW4gd2hhdCBpcw0KPiAgICBhdmFpbGFibGUgdG9kYXksIGFuZCB3aGF0 IGlzIG5lZWRlZCB0byBhZGRyZXNzIHRoZSBwcm9ibGVtLg0KPiANCj4gVGhvbWFzDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkYyBtYWls aW5nIGxpc3QNCj4gZGNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kYw0K From melinda.shore@gmail.com Wed Dec 21 17:28:50 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E3F21F8ABE for ; Wed, 21 Dec 2011 17:28:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY30znXTp7fj for ; Wed, 21 Dec 2011 17:28:50 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBC321F8AAA for ; Wed, 21 Dec 2011 17:28:50 -0800 (PST) Received: by ghbg18 with SMTP id g18so2208788ghb.31 for ; Wed, 21 Dec 2011 17:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7WOuBlLG6maEDI4vBl7VS+HO707ppHE8jl0uaCLP7gE=; b=Mn9WNBpKyP3xXCyssTlZNZEu8utYrb/1uPbj5mrawAaW3tyU9uJyW2X0aP4EAGZPlF GQaCn6J3MkBnQdaG6zUBtgAC/qRYRORJmPO6vT1X4FxvQ0LSVba6GaHc6Jp59rSzL+D9 0I/IQK1e8JEIzBXkaXCZxUzG9tVZJEv4efp58= Received: by 10.236.128.242 with SMTP id f78mr13009979yhi.7.1324517329965; Wed, 21 Dec 2011 17:28:49 -0800 (PST) Received: from [137.229.12.236] (drake.swits.alaska.edu. [137.229.12.236]) by mx.google.com with ESMTPS id y58sm11970814yhi.17.2011.12.21.17.28.48 (version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 17:28:49 -0800 (PST) Message-ID: <4EF287E0.7030906@gmail.com> Date: Wed, 21 Dec 2011 16:29:04 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: dc@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762AF0@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762AF0@szxeml525-mbs.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 01:28:50 -0000 On 12/21/2011 04:23 PM, Xuxiaohu wrote: > Fully agree. It's no late to summarize the real problems in one doc after various problems have been fully discussed and verified one-by-one in the mailing-list. What would be that document's purpose? Melinda From xuxiaohu@huawei.com Wed Dec 21 17:38:54 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6911E8096 for ; Wed, 21 Dec 2011 17:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xePOZnPJmXAL for ; Wed, 21 Dec 2011 17:38:53 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 720B711E80C0 for ; Wed, 21 Dec 2011 17:38:53 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWL00JBE0KRHB@szxga05-in.huawei.com> for dc@ietf.org; Thu, 22 Dec 2011 09:38:51 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWL006AK0KRM8@szxga05-in.huawei.com> for dc@ietf.org; Thu, 22 Dec 2011 09:38:51 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFV97743; Thu, 22 Dec 2011 09:38:50 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Dec 2011 09:38:46 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Thu, 22 Dec 2011 09:38:49 +0800 Date: Thu, 22 Dec 2011 01:38:49 +0000 From: Xuxiaohu In-reply-to: <4EF287E0.7030906@gmail.com> X-Originating-IP: [10.108.4.80] To: Melinda Shore , "dc@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762B4E@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dc] Scoping the Interim meeting Thread-index: Acy/UFjTkv7a6r5mTy699yqvnJVhAwAo1mog//+vywD//wTLcIABcBcA//91GVA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762AF0@szxeml525-mbs.china.huawei.com> <4EF287E0.7030906@gmail.com> Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 01:38:54 -0000 QXMgYSBjb21wcmVoZW5zaXZlIHByb2JsZW0gc3RhdGVtZW50IGRvYywgaXQgY2FuIGJlIHJlZmVy ZW5jZWQgbGF0ZXIgZm9yIHNvbHV0aW9uIGRlc2lnbi4NCg0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+ 1K28/i0tLS0tDQo+ILeivP7IyzogZGMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRjLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gTWVsaW5kYQ0KPiBTaG9yZQ0KPiC3osvNyrG85DogMjAxMcTqMTLU wjIyyNUgOToyOQ0KPiDK1bz+yMs6IGRjQGlldGYub3JnDQo+INb3zOI6IFJlOiBbZGNdIFNjb3Bp bmcgdGhlIEludGVyaW0gbWVldGluZw0KPiANCj4gT24gMTIvMjEvMjAxMSAwNDoyMyBQTSwgWHV4 aWFvaHUgd3JvdGU6DQo+ID4gRnVsbHkgYWdyZWUuIEl0J3Mgbm8gbGF0ZSB0byBzdW1tYXJpemUg dGhlIHJlYWwgcHJvYmxlbXMgaW4gb25lIGRvYyBhZnRlcg0KPiB2YXJpb3VzIHByb2JsZW1zIGhh dmUgYmVlbiBmdWxseSBkaXNjdXNzZWQgYW5kIHZlcmlmaWVkIG9uZS1ieS1vbmUgaW4gdGhlDQo+ IG1haWxpbmctbGlzdC4NCj4gDQo+IFdoYXQgd291bGQgYmUgdGhhdCBkb2N1bWVudCdzIHB1cnBv c2U/DQo+IA0KPiBNZWxpbmRhDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGRjIG1haWxpbmcgbGlzdA0KPiBkY0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RjDQo= From adalela@cisco.com Wed Dec 21 22:47:11 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1A621F8B46 for ; Wed, 21 Dec 2011 22:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVFagf2zIJ9v for ; Wed, 21 Dec 2011 22:47:10 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id CC84021F8B44 for ; Wed, 21 Dec 2011 22:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=14327; q=dns/txt; s=iport; t=1324536429; x=1325746029; h=mime-version:subject:date:message-id:from:to; bh=PZ95hqwQ+ishx+PDPmezjPIgjdHze1RFjBxcI5hPwY4=; b=Nqf3r17/MVatqM3RgPgHiDQUd6BdPdLZeWxYJxSUg4v3esA7lNiWb2N+ AYqSA05Qep0lJMoEJOI2O3Pk+hTMa5JTshOlor3grM8at++EfGp8I2NWz hhRvbNASXXj1lSojc5bMntM+MmjfPRFFPlB+KsVzGuSLv8oXUqXEAEzEf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAI/R8k5Io8UY/2dsb2JhbABCgk6qYYFyAQEBBBIBCREDWwEIEhAGGAdIDwEECxATB58zgSYBnimLLGMEiDWIcZYU X-IronPort-AV: E=Sophos;i="4.71,391,1320624000"; d="scan'208,217";a="2159927" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 22 Dec 2011 06:47:07 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBM6l7DF003984 for ; Thu, 22 Dec 2011 06:47:07 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Dec 2011 12:17:06 +0530 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_01CCC075.857CCEC6" Date: Thu, 22 Dec 2011 12:17:07 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102A48656@XMB-BGL-416.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [dc] Scoping the Interim meeting Thread-Index: AczAdYW+VL2Yc0snSBGkbRUEa32olg== From: "Ashish Dalela (adalela)" To: X-OriginalArrivalTime: 22 Dec 2011 06:47:06.0973 (UTC) FILETIME=[857648D0:01CCC075] Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 06:47:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCC075.857CCEC6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I'm new to this list and have been reading the archives. Wanted to make a few comments. =20 First, issues of datacenter are mired in an "architecture" debate: flat vs. hierarchical, dumb edge vs. dumb core, network-based vs. server-based. If you go back in time, routing and switching protocols were agnostic to the network architecture itself. This needs to be revived. There should be effort in (a) recognizing architecture trends, but (b) dissociate technology from network architecture. I.e. the technology should work equally well with ANY architecture. Discussing "typical" DC architectures and then tying the problem to them isn't a very convincing way of going about this. =20 Second, to Ron's point about why datacenter problem is not widely viewed, this is mainly because the origin of the problem is virtual host scaling. L2 gives mobility but does not scale. L3 scales but does not give mobility. So, classical approaches don't work. Now, a new approach has to be devised, and there are many possible schemes, not all are optimal. The issue is how to solve the virtual host scaling in an optimal manner. And it is harder to recognize a problem that hinges on optimality and scaling. If you take away scaling, there is no problem. This group should recognize that the key problem is scaling, and the answers are around optimality, not functionality. That should be somewhere in the problem statement. =20 Third, there are multiple dimensions against which to evaluate optimality. This is like a bubble under the carpet, and there many ways you can push the bubble only to find that it is now somewhere else. To find the optimal solution, it is important to list all the factors against which to optimize. That makes this harder, but anything else would fall short of expectation. Below are some of the dimensions against which to optimize: =20 - Massive address scaling - Address mobility=20 - Segmentation and security - Ease of managing=20 - Distributed cloud control - the end-user AND the provider - Measurements and SLAs =20 Thanks, Ashish ------_=_NextPart_001_01CCC075.857CCEC6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I’m new to this list and have been reading the = archives. Wanted to make a few comments.

 

First, = issues of datacenter are mired in an “architecture” debate: = flat vs. hierarchical, dumb edge vs. dumb core, network-based vs. = server-based. If you go back in time, routing and switching protocols = were agnostic to the network architecture itself. This needs to be = revived. There should be effort in (a) recognizing architecture trends, = but (b) dissociate technology from network architecture. I.e. the = technology should work equally well with ANY architecture. Discussing = “typical” DC architectures and then tying the problem to = them isn’t a very convincing way of going about = this.

 

Second, = to Ron’s point about why datacenter problem is not widely viewed, = this is mainly because the origin of the problem is virtual host = scaling. L2 gives mobility but does not scale. L3 scales but does not = give mobility. So, classical approaches don’t work. Now, a new = approach has to be devised, and there are many possible schemes, not all = are optimal. The issue is how to solve the virtual host scaling in an = optimal manner. And it is harder to recognize a problem that hinges on = optimality and scaling. If you take away scaling, there is no problem. = This group should recognize that the key problem is scaling, and the = answers are around optimality, not functionality. That should be = somewhere in the problem statement.

 

Third, = there are multiple dimensions against which to evaluate optimality. This = is like a bubble under the carpet, and there many ways you can push the = bubble only to find that it is now somewhere else. To find the optimal = solution, it is important to list all the factors against which to = optimize. That makes this harder, but anything else would fall short of = expectation. Below are some of the dimensions against which to = optimize:

 

-    Massive = address scaling

-    = Address = mobility

-    = Segmentation and security

-    Ease of = managing

-    = Distributed cloud control – the end-user AND the = provider

-    = Measurements and SLAs

 

Thanks, = Ashish

------_=_NextPart_001_01CCC075.857CCEC6-- From xuxiaohu@huawei.com Thu Dec 22 00:12:29 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0FB21F8B72 for ; Thu, 22 Dec 2011 00:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O43G9q8pHfqe for ; Thu, 22 Dec 2011 00:12:28 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id ABA5821F8B4A for ; Thu, 22 Dec 2011 00:12:27 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWL00MXTISC2L@szxga05-in.huawei.com> for dc@ietf.org; Thu, 22 Dec 2011 16:12:12 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWL00J1FISC0F@szxga05-in.huawei.com> for dc@ietf.org; Thu, 22 Dec 2011 16:12:12 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFZ07334; Thu, 22 Dec 2011 16:12:12 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Dec 2011 16:12:07 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Thu, 22 Dec 2011 16:12:07 +0800 Date: Thu, 22 Dec 2011 08:12:06 +0000 From: Xuxiaohu In-reply-to: X-Originating-IP: [10.108.4.80] To: "Eggert, Lars" , "dc@ietf.org" , "dcrg-interest@irtf.org." Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762C3E@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: IP over IP solution for data center interconnect Thread-index: AQHMwIFlf3LDISJKgEmN00CCVuTZxQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: [dc] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 08:12:29 -0000 SGkgYWxsLA0KDQpUaGVyZSBoYXMgYmVlbiBhIGxvdCBvZiBMMiBvdmVyIEwzIHNvbHV0aW9ucyBv ciBwcm9wb3NhbHMgZm9yIGRhdGEgY2VudGVyIG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyIGludGVy Y29ubmVjdCB0aWxsIG5vdy4gSG93ZXZlciwgaXQgc2VlbXMgcmVjZW50bHkgdGhlcmUgYXJlIGlu Y3JlYXNpbmcgaW50ZXJlc3RzIG9uIEwzIG92ZXIgTDMgKGUuZy4sIElQIG92ZXIgSVApIHNvbHV0 aW9ucyBmb3IgZGF0YSBjZW50ZXIgbmV0d29yayBhbmQgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0 LCBwbGVhc2Ugc2VlIHRoZSBmb2xsb3dpbmcgdGV4dCBxdW90ZWQgZnJvbSBJRVRGODIgTDJWUE4g bWludXRlcyAoIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgyL21pbnV0ZXMvbDJ2 cG4udHh0KS4gSXQncyBhIGdlbmVyYWwgYmVsaWVmIHRoYXQgTDMgaXMgbW9yZSBzY2FsYWJsZSB0 aGFuIEwyLiBFc3BlY2lhbGx5IHdoZW4gY29uc2lkZXJpbmcgdGhlIGRhdGEgY2VudGVyIGludGVy Y29ubmVjdGlvbiBjYXNlLCB0aGUgTDMgb3ZlciBMMyBzb2x1dGlvbnMgY2FuIGJyaW5nIERDIG9w ZXJhdG9ycyBtb3JlIGJlbmVmaXRzIGNvbXBhcmVkIHRvIHRoZSBMMiBvdmVyIEwzIHNvbHV0aW9u cywgc3VjaCBhcyBwYXRoIG9wdGltaXphdGlvbiwgYWN0aXZlLWFjdGl2ZSBkYXRhIGNlbnRlcnMs IE1BQyB0YWJsZSByZWR1Y3Rpb24gb24gREMgc3dpdGNoZXMgYW5kIGJyb2FkY2FzdCBmbG9vZCBz dXBwcmVzc2lvbiBldGMgLiANCg0KQWx0aG91Z2ggTGF5ZXIgMiBjb25uZWN0aXZpdHkgaXMgc3Rp bGwgcmVxdWlyZWQgZm9yIHNvbWUgaGlnaC1hdmFpbGFiaWxpdHkgY2x1c3RlcnMgd2hpY2ggdXNl IG5vbi1JUCBhbmQgbGluay1sb2NhbCBtdWx0aWNhc3QgZm9yIGNvbW11bmljYXRpb24sIG1vcmUg YW5kIG1vcmUgY2x1c3RlciB2ZW5kb3JzIGFyZSBlaXRoZXIgYWxyZWFkeSBhYmxlIHRvIHN1cHBv cnQgY2x1c3RlciBzZXJ2aWNlcyBhdCBMYXllcjMgb3Igd2lsbCBzdXBwb3J0IGl0IGluIHRoZSBu ZWFyIGZ1dHVyZS4gSW4gYWRkaXRpb24sIHRoZSBHU0xCIG1lY2hhbmlzbSAoZS5nLiwgRE5TIGJh c2VkIEdTTEIpIHdvcmtzIHZlcnkgd2VsbCBpbiBtb3N0IGNhc2VzLCBpcyBnZW8tY2x1c3RlciBz ZXJ2aWNlIHN0aWxsIGEgY29tbW9uIHJlcXVpcmVtZW50IGZvciBkYXRhIGNlbnRlciBpbnRlcmNv bm5lY3Q/IElmIG5vdCwgY291bGQgd2Ugc3BlbmQgYW55IHRpbWUgb24gZXhwbG9yaW5nIHRoZSBw b3NzaWJpbGl0eSBvZiB1c2luZyBMMyBvdmVyIEwzIHNvbHV0aW9uIGZvciB0aGUgbW9zdCBkYXRh IGNlbnRlciBpbnRlcmNvbm5lY3Rpb24gc2NlbmFyaW9zIHdoZXJlIGdlby1jbHVzdGVyaW5nLCBl c3BlY2lhbGx5IG5vbi1JUCBiYXNlZCBnZW8tY2x1c3RlcmluZyBpcyBub3QgbmVlZGVkPw0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCktpcmVldGk6IEkga2VlcCBzZWVpbmcg SVNJRCwgUEJCLCBWTEFOcy4gIFdlIGhhdmUgdG8gc3RvcCBjb25jZWRpbmcgdG8gbGF5ZXIgMiBh bmQgc3RhcnQgbW92aW5nIHRvIGxheWVyIDMgKGFwcGxhdXNlKSBhbmQgbG90cyBvZiBwcm9ibGVt cyB3aWxsIGdvIGF3YXkuDQoNCkZsb3JpbjogV2Ugc2hvdWxkIHB1dCBWUE4gb24gdGhlIHNhbWUg cGFnZSB0byBtb2RpZnkgdGhlIHByaW9yaXRpZXMuIFlvdSBuZWVkIHRvIGV4cGFuZCBzbyBjYW4g bG9vayBhdCBMMyBvdmVyIEwzIGFzIHdlbGwgYXMgTDIgb3ZlciBMMy4gRm9yIGl0ZW0gbnVtYmVy IDIgd2UgbmVlZCB0byBsb29rIGF0IEwzIHRyYW5zcG9ydCBhcyB3ZWxsIGFzIEV0aGVybmV0IGFu ZCBNUExTLiAgQW5kIGZvciBudW1iZXIgMyB3ZSBuZWVkIHRvIHdvcmsgb24gdGhpcyBhcyB0aGVy ZSdzIGEgbG90IG9mIGV4cGVydGlzZSBpbiBMMiwgTDMgYW5kIG90aGVyIFdHcy4NCg0KDQpNYXJj OiBUaGUgcHJvYmxlbSBzdGF0ZW1lbnQgbmVlZHMgdG8gaW5jbHVkZSBtb3JlIG9mIHRoZSBMMyBp c3N1ZXMgYXJvdW5kIHNlbmRpbmcgTDIgb3ZlciBMMywgYXMgdGhlIEwyIHRyYWZmaWMgYWxyZWFk eSBjb250YWlucyBMMy4gIElzc3VlIGlzIGp1c3QgZnJhbWluZy4NCg0KRXJpYyBOb3JkbWFyazsg IlllcywgWWVzIGFuZCBZZXMiLiAgV2UgbmVlZCB0byBmb2N1cyBmcm9tIHRoZSBEQyBwcm9zcGVj dGl2ZSBhbmQgbm90IGZyb20gdGhlIFZQTiB2aWV3LiAgZG9uJ3QganVzdCB0aGluayBhYm91dCBF dGhlcm5ldCBvdmVyIElQLCBidXQgYWxzbyBJUCBvdmVyIElQLiAgSHlwZXJ2aXNvciBtYXkgZ2V0 IGRlY291cGxlZCBvdmVyIHRpbWUuDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4g t6K8/sjLOiBkYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10g tPqx7SBFZ2dlcnQsIExhcnMNCj4gt6LLzcqxvOQ6IDIwMTHE6jEy1MIxNsjVIDE2OjI0DQo+IMrV vP7IyzogZGNAaWV0Zi5vcmcNCj4g1vfM4jogW2RjXSBJUlRGIGRhdGFjZW50ZXIgcmVzZWFyY2gg Z3JvdXAgZGlzY3Vzc2lvbiBsaXN0DQo+IA0KPiBIaSwNCj4gDQo+IEkgd2FudGVkIHRvIG1ha2Ug eW91IGFsbCBhd2FyZSBvZiB0aGUgSVJURidzIGRjcmctaW50ZXJlc3QgbWFpbGluZyBsaXN0LCB3 aGljaA0KPiB3YXMgc2V0IHVwIGZvbGxvd2luZyBhIGZhY2UtdG8tZmFjZSBtZWV0aW5nIGF0IFNJ R0NPTU0gdGhpcyB5ZWFyIHRvIGRpc2N1c3MgYQ0KPiBwb3NzaWJsZSBJUlRGIHJlc2VhcmNoIGdy b3VwIG9uIGRhdGFjZW50ZXIgbmV0d29ya2luZzoNCj4gaHR0cDovL2lydGYub3JnL21haWxtYW4v bGlzdGluZm8vZGNyZy1pbnRlcmVzdA0KPiANCj4gVGhlcmUgaGFzIG5vdCBiZWVuIG11Y2ggYWN0 aXZpdHkgdG93YXJkcyB0aGUgZm9ybWF0aW9uIG9mIGFuIElSVEYgUkcgc2luY2UNCj4gU0lHQ09N TSwgYnV0IEkgYW0gaG9wZWZ1bCB0aGF0IHRoZSBoaWdoIGVuZXJneSBsZXZlbCBkZW1vbnN0cmF0 ZWQgaW4gdGhlDQo+IHZhcmlvdXMgVGFpcGVpIG1lZXRpbmdzIG9uIHRoZSB0b3BpYyB3aWxsIGlu amVjdCBzb21lIGVuZXJneSBoZXJlIC0gc2V2ZXJhbCBvZg0KPiB0aGUgdG9waWNzIHRoYXQgbWF5 IGJlIHRvbyBlYXJseSBmb3IgdGhlIElFVEYgdG8gc3RhbmRhcmRpemUgYXJvdW5kIHdvdWxkIGZp dCBhbg0KPiBJUlRGIFJHIHZlcnkgd2VsbC4gSSdtIGNlcnRhaW5seSBzdXBwb3J0aXZlIG9mIHRo aXMuDQo+IA0KPiBMYXJzDQo+IElSVEYgQ2hhaXINCj4gDQo+IA0KPiAtLQ0KPiBNb2JpbGUgbnVt YmVyIGR1cmluZyBEZWNlbWJlcjogICAgKzM1OCA0NiA1MjE1NTgyDQo+IE1vYmlsZSBudW1iZXIg c3RhcnRpbmcgSmFudWFyeTogICs0OSAxNTEgMTIwNTU3OTENCg0K From ping@pingpan.org Thu Dec 22 05:50:39 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF27021F8AEA for ; Thu, 22 Dec 2011 05:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfBf574yKEUb for ; Thu, 22 Dec 2011 05:50:38 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with SMTP id 5168721F8541 for ; Thu, 22 Dec 2011 05:50:37 -0800 (PST) Received: from mail-qy0-f181.google.com ([209.85.216.181]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTvM1rLpDNl/3j9Ym1SOpohmLWiMSwLfJ@postini.com; Thu, 22 Dec 2011 05:50:38 PST Received: by qcha6 with SMTP id a6so6281984qch.26 for ; Thu, 22 Dec 2011 05:50:35 -0800 (PST) Received: by 10.229.134.197 with SMTP id k5mr4002789qct.58.1324561835317; Thu, 22 Dec 2011 05:50:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.215.138 with HTTP; Thu, 22 Dec 2011 05:49:54 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762C3E@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762C3E@szxeml525-mbs.china.huawei.com> From: Ping Pan Date: Thu, 22 Dec 2011 05:49:54 -0800 Message-ID: To: Xuxiaohu Content-Type: multipart/alternative; boundary=00248c6a6742ad5b8404b4ae9519 Cc: "dcrg-interest@irtf.org." , "Eggert, Lars" , "dc@ietf.org" Subject: Re: [dc] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 13:50:39 -0000 --00248c6a6742ad5b8404b4ae9519 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2011/12/22 Xuxiaohu > Hi all, > > There has been a lot of L2 over L3 solutions or proposals for data center > network and data center interconnect till now. However, it seems recently > there are increasing interests on L3 over L3 (e.g., IP over IP) solutions > for data center network and data center interconnect, please see the > following text quoted from IETF82 L2VPN minutes ( > https://www.ietf.org/proceedings/82/minutes/l2vpn.txt). It's a general > belief that L3 is more scalable than L2. Especially when considering the > data center interconnection case, the L3 over L3 solutions can bring DC > operators more benefits compared to the L2 over L3 solutions, such as pat= h > optimization, active-active data centers, MAC table reduction on DC > switches and broadcast flood suppression etc . > > Although Layer 2 connectivity is still required for some high-availabilit= y > clusters which use non-IP and link-local multicast for communication, mor= e > and more cluster vendors are either already able to support cluster > services at Layer3 or will support it in the near future. In addition, th= e > GSLB mechanism (e.g., DNS based GSLB) works very well in most cases, is > geo-cluster service still a common requirement for data center > interconnect? If not, could we spend any time on exploring the possibilit= y > of using L3 over L3 solution for the most data center interconnection > scenarios where geo-clustering, especially non-IP based geo-clustering is > not needed? > > This makes perfect sense!! Ping > Best regards, > Xiaohu > > > *************************************************************************= ************************************************* > Kireeti: I keep seeing ISID, PBB, VLANs. We have to stop conceding to > layer 2 and start moving to layer 3 (applause) and lots of problems will = go > away. > > Florin: We should put VPN on the same page to modify the priorities. You > need to expand so can look at L3 over L3 as well as L2 over L3. For item > number 2 we need to look at L3 transport as well as Ethernet and MPLS. A= nd > for number 3 we need to work on this as there's a lot of expertise in L2, > L3 and other WGs. > > > Marc: The problem statement needs to include more of the L3 issues around > sending L2 over L3, as the L2 traffic already contains L3. Issue is just > framing. > > Eric Nordmark; "Yes, Yes and Yes". We need to focus from the DC > prospective and not from the VPN view. don't just think about Ethernet > over IP, but also IP over IP. Hypervisor may get decoupled over time. > > *************************************************************************= ************************************************* > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: dc-bounces@ietf.org [mailto:dc-bounces@iet= f.org] =E4=BB=A3=E8=A1=A8 Eggert, Lars > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B412=E6=9C=8816=E6=97= =A5 16:24 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: dc@ietf.org > > =E4=B8=BB=E9=A2=98: [dc] IRTF datacenter research group discussion list > > > > Hi, > > > > I wanted to make you all aware of the IRTF's dcrg-interest mailing list= , > which > > was set up following a face-to-face meeting at SIGCOMM this year to > discuss a > > possible IRTF research group on datacenter networking: > > http://irtf.org/mailman/listinfo/dcrg-interest > > > > There has not been much activity towards the formation of an IRTF RG > since > > SIGCOMM, but I am hopeful that the high energy level demonstrated in th= e > > various Taipei meetings on the topic will inject some energy here - > several of > > the topics that may be too early for the IETF to standardize around > would fit an > > IRTF RG very well. I'm certainly supportive of this. > > > > Lars > > IRTF Chair > > > > > > -- > > Mobile number during December: +358 46 5215582 > > Mobile number starting January: +49 151 12055791 > > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc > --00248c6a6742ad5b8404b4ae9519 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2011/12/22 Xuxiaohu <xuxiaohu@huawei.com>
Hi all,

There has been a lot of L2 over L3 solutions or proposals for data center n= etwork and data center interconnect till now. However, it seems recently th= ere are increasing interests on L3 over L3 (e.g., IP over IP) solutions for= data center network and data center interconnect, please see the following= text quoted from IETF82 L2VPN minutes ( https://www.ietf.org/proc= eedings/82/minutes/l2vpn.txt). It's a general belief that L3 is mor= e scalable than L2. Especially when considering the data center interconnec= tion case, the L3 over L3 solutions can bring DC operators more benefits co= mpared to the L2 over L3 solutions, such as path optimization, active-activ= e data centers, MAC table reduction on DC switches and broadcast flood supp= ression etc .

Although Layer 2 connectivity is still required for some high-availability = clusters which use non-IP and link-local multicast for communication, more = and more cluster vendors are either already able to support cluster service= s at Layer3 or will support it in the near future. In addition, the GSLB me= chanism (e.g., DNS based GSLB) works very well in most cases, is geo-cluste= r service still a common requirement for data center interconnect? If not, = could we spend any time on exploring the possibility of using L3 over L3 so= lution for the most data center interconnection scenarios where geo-cluster= ing, especially non-IP based geo-clustering is not needed?


This makes perfect sense!!
<= br>
Ping
=C2=A0
Best regards,
Xiaohu

***************************************************************************= ***********************************************
Kireeti: I keep seeing ISID, PBB, VLANs. =C2=A0We have to stop conceding to= layer 2 and start moving to layer 3 (applause) and lots of problems will g= o away.

Florin: We should put VPN on the same page to modify the priorities. You ne= ed to expand so can look at L3 over L3 as well as L2 over L3. For item numb= er 2 we need to look at L3 transport as well as Ethernet and MPLS. =C2=A0An= d for number 3 we need to work on this as there's a lot of expertise in= L2, L3 and other WGs.


Marc: The problem statement needs to include more of the L3 issues around s= ending L2 over L3, as the L2 traffic already contains L3. =C2=A0Issue is ju= st framing.

Eric Nordmark; "Yes, Yes and Yes". =C2=A0We need to focus from th= e DC prospective and not from the VPN view. =C2=A0don't just think abou= t Ethernet over IP, but also IP over IP. =C2=A0Hypervisor may get decoupled= over time.
***************************************************************************= ***********************************************
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: dc= -bounces@ietf.org [mailto:dc-bou= nces@ietf.org] =E4=BB=A3=E8=A1=A8 Eggert, Lars
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B412=E6=9C=8816=E6=97= =A5 16:24
> =E6=94=B6=E4=BB=B6=E4=BA=BA: dc@ietf.or= g
> =E4=B8=BB=E9=A2=98: [dc] IRTF datacenter research group discussion lis= t
>
> Hi,
>
> I wanted to make you all aware of the IRTF's dcrg-interest mailing= list, which
> was set up following a face-to-face meeting at SIGCOMM this year to di= scuss a
> possible IRTF research group on datacenter networking:
> http://irtf.org/mailman/listinfo/dcrg-interest
>
> There has not been much activity towards the formation of an IRTF RG s= ince
> SIGCOMM, but I am hopeful that the high energy level demonstrated in t= he
> various Taipei meetings on the topic will inject some energy here - se= veral of
> the topics that may be too early for the IETF to standardize around wo= uld fit an
> IRTF RG very well. I'm certainly supportive of this.
>
> Lars
> IRTF Chair
>
>
> --
> Mobile number during December: =C2=A0 =C2=A0+358 46 5215582
> Mobile number starting January: =C2=A0+49 151 12055791

_______________________________________________
dc mailing list
dc@ietf.org
http= s://www.ietf.org/mailman/listinfo/dc

--00248c6a6742ad5b8404b4ae9519-- From aldrin.isaac@gmail.com Thu Dec 22 09:12:44 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E94321F8558 for ; Thu, 22 Dec 2011 09:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX47ZBb6g376 for ; Thu, 22 Dec 2011 09:12:43 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADAD21F8531 for ; Thu, 22 Dec 2011 09:12:43 -0800 (PST) Received: by qadz3 with SMTP id z3so5707536qad.10 for ; Thu, 22 Dec 2011 09:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=DoObWquNLEDqvuUIEaDkbf6YX0H0UaOaDP27SnfplFo=; b=Q+g7gpK63y/UXd6JLqXG15SPQ60CoOEnBaQywb7TD+k2cxS+LYg1joTLP3xfNdF7rA SPJpBKiMZH03jKUvvrCdtw/hQIfgSgEy+RAynUYmQmekOa4LGN6KKDJKSZ4fgGc6jZvg Fgg3jUtFBKK9FtSHvtznEM8yKT9BWfrTW4piA= Received: by 10.224.10.19 with SMTP id n19mr14520369qan.68.1324573962602; Thu, 22 Dec 2011 09:12:42 -0800 (PST) Received: from mymac.home (ool-44c1c730.dyn.optonline.net. [68.193.199.48]) by mx.google.com with ESMTPS id hv20sm18364399qab.22.2011.12.22.09.12.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Dec 2011 09:12:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_2D78C01A-D320-47DE-95ED-2A8501D0C1DF" From: Aldrin Isaac In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102A48656@XMB-BGL-416.cisco.com> Date: Thu, 22 Dec 2011 12:12:38 -0500 Message-Id: References: <618BE8B40039924EB9AED233D4A09C5102A48656@XMB-BGL-416.cisco.com> To: "Ashish Dalela (adalela)" X-Mailer: Apple Mail (2.1251.1) Cc: dc@ietf.org Subject: Re: [dc] Scoping the Interim meeting X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 17:12:44 -0000 --Apple-Mail=_2D78C01A-D320-47DE-95ED-2A8501D0C1DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Coming at it as an operator, the following are my own challenges with = traditional LAN technology as well as some of my perspective that seem = to ring true to what Ashish says. Here's my elevator pitch. Optimizing network resources (access ports, backbone, routing, VPN, = VLAN, etc) and other resources (zone, rack, computer, storage, etc) with = a high degree of efficiency on both ends requires significant = coordination. Optimizing resources through interdepartmental = coordination is an operational "slow path" with high cost of operations, = poor economies of scale and results that are often far from ideal. It would be convenient to implement a fatter "dumb" core network (which = seems to be a key assumption being made by the overlay and smart-edge = drafts) where an end-station can be connected into any nearest available = access switch port. However since typical data center networks are = segmented into tiers of physical and virtual network domains and = subnets, to accomplish this would require a high degree of network = virtualization to achieve the best physical network hardware = utilization. Virtualization of IP networks can be accomplished quite = easily today using IPVPN technology, but the virtualization capability = of IPVPN begins only at the IP router interface. In order to enable the = nearest (virtual or physical) access switch port to be a member of any = network domain or subnet, the access switch port needs to have the = ability to be a working member of any virtual LAN (subnet). IPVPN and = virtual LAN are then interworked to complete the end-to-end picture. = (Additionally, multicast bandwidth, replication and state optimization = are important to many companies -- particularly those that deal with = large and/or numerous multicast flows so this can't be neglected.) Traditional virtual LAN technology does not scale well enough to be used = in the manner I describe above. A big part of why this problem exists = to begin with is the side effects of data plane learning, both in the = network (for which there are evolving solutions) and at the end-station = interface to the network (as far as I can tell there is no effort to = create a standardized UNI to exchange station MAC). There are obviously = other issues that have been raised such as ToR switch limitations, etc. The operators involved in router (inter-networking) versus access switch = (service attachment) deployment and provisioning in large data centers = also tend to be different, which highlights an operational dimension = that separates IPVPN from virtual LAN. Decoupling the attachment role = from the inter-networking role further cuts back on inter-role = coordination reducing the number of "touch points" to actuate service. I suppose we could move away from virtual LANs and go all-IP to the end = station, but consider these: 1. The stability of an IP network depends heavily on statically = configured subnets that act as a noise barrier from come-and-go = end-stations. IP networks extend into the Internet, business partners = and customers which require degrees of route aggregation. 2. Use of Ethernet-layer solutions such as Ethernet-layer VRRP-like high = availability, FCoE, RoCE, etc will not go away overnight. Furthermore, some companies use server virtualization extensively while = others do not (if the scope of this group is limited to optimizing VM = environments, it should be made clear early). A solution that creates new problems and does not have an intuitive and = simple way to transition to it is a failure. A solution that can = achieve the goals by building on top of existing standards is ideal. = Solutions should be evaluated for how broadly they would be accepted. On Dec 22, 2011, at 1:47 AM, Ashish Dalela (adalela) wrote: > I=92m new to this list and have been reading the archives. Wanted to = make a few comments. > =20 > First, issues of datacenter are mired in an =93architecture=94 debate: = flat vs. hierarchical, dumb edge vs. dumb core, network-based vs. = server-based. If you go back in time, routing and switching protocols = were agnostic to the network architecture itself. This needs to be = revived. There should be effort in (a) recognizing architecture trends, = but (b) dissociate technology from network architecture. I.e. the = technology should work equally well with ANY architecture. Discussing = =93typical=94 DC architectures and then tying the problem to them isn=92t = a very convincing way of going about this. > =20 > Second, to Ron=92s point about why datacenter problem is not widely = viewed, this is mainly because the origin of the problem is virtual host = scaling. L2 gives mobility but does not scale. L3 scales but does not = give mobility. So, classical approaches don=92t work. Now, a new = approach has to be devised, and there are many possible schemes, not all = are optimal. The issue is how to solve the virtual host scaling in an = optimal manner. And it is harder to recognize a problem that hinges on = optimality and scaling. If you take away scaling, there is no problem. = This group should recognize that the key problem is scaling, and the = answers are around optimality, not functionality. That should be = somewhere in the problem statement. > =20 > Third, there are multiple dimensions against which to evaluate = optimality. This is like a bubble under the carpet, and there many ways = you can push the bubble only to find that it is now somewhere else. To = find the optimal solution, it is important to list all the factors = against which to optimize. That makes this harder, but anything else = would fall short of expectation. Below are some of the dimensions = against which to optimize: > =20 > - Massive address scaling > - Address mobility > - Segmentation and security > - Ease of managing > - Distributed cloud control =96 the end-user AND the provider > - Measurements and SLAs > =20 > Thanks, Ashish > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc --Apple-Mail=_2D78C01A-D320-47DE-95ED-2A8501D0C1DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Coming at it as an operator, the following are = my own challenges with traditional LAN technology as well as some of my = perspective that seem to ring true to what Ashish says.  Here's my = elevator pitch.


It = would be convenient to implement a fatter "dumb" core network (which = seems to be a key assumption being made by the overlay and smart-edge = drafts) where an end-station can be connected into any nearest available = access switch port.  However since typical data center networks are = segmented into tiers of physical and virtual network domains and = subnets, to accomplish this would require a high degree of network = virtualization to achieve the best physical network hardware = utilization.  Virtualization of IP networks can be accomplished = quite easily today using IPVPN technology, but the virtualization = capability of IPVPN begins only at the IP router interface.  In = order to enable the nearest (virtual or physical) access switch port to = be a member of any network domain or subnet, the access switch port = needs to have the ability to be a working member of any virtual LAN = (subnet).  IPVPN and virtual LAN are then interworked to complete = the end-to-end picture.  (Additionally, multicast bandwidth, = replication and state optimization are important to many companies -- = particularly those that deal with large and/or numerous multicast flows = so this can't be neglected.)



I = suppose we could move away from virtual LANs and go all-IP to the end = station, but consider these:
1. The stability of an IP network = depends heavily on statically configured subnets that act as a noise = barrier from come-and-go end-stations.  IP networks extend into the = Internet, business partners and customers which require degrees of route = aggregation.
2. Use of Ethernet-layer solutions such as = Ethernet-layer VRRP-like high availability, FCoE, RoCE, etc will not go = away overnight.


A solution that creates new = problems and does not have an intuitive and simple way to transition to = it is a failure.  A solution that can achieve the goals by building = on top of existing standards is ideal.  Solutions should be = evaluated for how broadly they would be accepted.

On Dec 22, 2011, at 1:47 = AM, Ashish Dalela (adalela) wrote:

I=92m new to this list = and have been reading the archives. Wanted to make a few = comments.
First, issues of = datacenter are mired in an =93architecture=94 debate: flat vs. = hierarchical, dumb edge vs. dumb core, network-based vs. server-based. = If you go back in time, routing and switching protocols were agnostic to = the network architecture itself. This needs to be revived. There should = be effort in (a) recognizing architecture trends, but (b) dissociate = technology from network architecture. I.e. the technology should work = equally well with ANY architecture. Discussing =93typical=94 DC = architectures and then tying the problem to them isn=92t a very = convincing way of going about this.
 
Second, to Ron=92s point about why datacenter = problem is not widely viewed, this is mainly because the origin of the = problem is virtual host scaling. L2 gives mobility but does not scale. = L3 scales but does not give mobility. So, classical approaches don=92t = work. Now, a new approach has to be devised, and there are many possible = schemes, not all are optimal. The issue is how to solve the virtual host = scaling in an optimal manner. And it is harder to recognize a problem = that hinges on optimality and scaling. If you take away scaling, there = is no problem. This group should recognize that the key problem is = scaling, and the answers are around optimality, not functionality. That = should be somewhere in the problem = statement.
Third, there are = multiple dimensions against which to evaluate optimality. This is like a = bubble under the carpet, and there many ways you can push the bubble = only to find that it is now somewhere else. To find the optimal = solution, it is important to list all the factors against which to = optimize. That makes this harder, but anything else would fall short of = expectation. Below are some of the dimensions against which to = optimize:
-    -    -    - -    -    Thanks, = Ashish
______________________________________= _________
dc mailing list
Date: Thu, 22 Dec 2011 17:10:12 -0500 Thread-Topic: Elevator Pitch (was: Scoping the Interim meeting) Thread-Index: AczADr87rb22Yvi5TdytpvIXtnf/PwA5Jmhw Message-ID: <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> In-Reply-To: <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dc@ietf.org" Subject: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 22:13:55 -0000 Folks, Amplifying what Thomas said: At this point, the most helpful thing that anyone can do is to summarize th= e problem(s) that we are trying to solve in a relatively terse email. Once = we come to consensus on that brief summary, we can flesh it out into very s= hort Internet Draft. I look forward to hearing your elevator pitches. Happy Holidays, Ron > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Wednesday, December 21, 2011 1:31 PM > To: So, Ning > Cc: Ronald Bonica; dc@ietf.org > Subject: Re: [dc] Scoping the Interim meeting >=20 > We sure have a lot of volunteers wanting to help. That is fine at one > level, but misses the bigger point. >=20 > The best way to help is to articulate a specific problem or area. >=20 > Do so on this list in a single message. We don't need yet more > documents (at least not yet). >=20 > 2-4 paragraphs (no more). Think "elevator pitch" > (http://en.wikipedia.org/wiki/Elevator_pitch). >=20 > You only get a couple of minutes to make your case, and if you can't > do so, either you don't understand the problem yourself well enough, > or the value-proposition just isn't compelling. >=20 > So far, I haven't seen discussions of specific problems (or problem > areas). What I'm seeing is pointers to lots of drafts, many of which > (for those that I've looked at) don't crisply get at a real, tangible > problem that I understand and think the IETF can/should work on. Bonus > points for showing: >=20 > 1) an operator (or some other clear customer/consumer technology) that > says "yes, that is what I need, and if it was available today, I'd > use it" >=20 > 2) a vendor saying "here is what my customers are telling me will > solve a problem of theirs", and we think an IETF standard is > needed. >=20 > 3) demonstration of a clear technical/protocol gap between what is > available today, and what is needed to address the problem. >=20 > Thomas >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From adalela@cisco.com Thu Dec 22 19:24:58 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F70611E80CE for ; Thu, 22 Dec 2011 19:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4gFWU4Qr-kt for ; Thu, 22 Dec 2011 19:24:57 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 95D3E11E808C for ; Thu, 22 Dec 2011 19:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=5676; q=dns/txt; s=iport; t=1324610696; x=1325820296; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iP/31GnhP9szQxdi2HzLnAVqVEt262Z5S1C49MVZ+Es=; b=ecjySYTHWmquLElceX8PllWv0QryZrzU3gMAG0N031bGC4Khn0EEmAHI 4DrSeqBHrgVCIGwh1eZiTE9RgzEijAvUIaSkA0y6ucxViQqJ8yEBZMHrU W1tpGv64BcUMdujGgoSjQPn8V8v7V5Bo01cAFx6Ex4IxgkD5awqTBY44e o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEAAPXz805Io8UY/2dsb2JhbABDm1iNPIQjgXIBAQEEAQEBDwEdCjQLDAQCAQgOAwEDAQELBhcBBgEmHwMGCAEBBAEKCAgah2CYfQGeMIssYwSINZ8G X-IronPort-AV: E=Sophos;i="4.71,396,1320624000"; d="scan'208";a="2218557" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 23 Dec 2011 03:24:54 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBN3Osl4001897; Fri, 23 Dec 2011 03:24:54 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Dec 2011 08:54:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Dec 2011 08:54:53 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Elevator Pitch (was: Scoping the Interim meeting) Thread-Index: AczADr87rb22Yvi5TdytpvIXtnf/PwA5JmhwAAoxfjA= References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> From: "Ashish Dalela (adalela)" To: "Ronald Bonica" , "Thomas Narten" , "So, Ning" X-OriginalArrivalTime: 23 Dec 2011 03:24:55.0171 (UTC) FILETIME=[70C1F530:01CCC122] Cc: dc@ietf.org Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 03:24:58 -0000 Here's my elevator pitch. I'll assume that elevator has to go to the 140th floor, with a few stops. ------------- Large virtualized datacenters pose several networking challenges.=20 First, native L2 or L3 forwarding technologies do not work. L2 networks can't be large due to high number of broadcasts. L3 networks can't be used because of VM mobility, since routing uses subnets and the IP cannot be moved out of that subnet. Moving IP in a natively L3 network requires installing a host route, which is an approach that can't be scaled. Hence, a new approach is required. Second, datacenters will span across locations, and in the hybrid cloud case need to connect private-public domains. VM mobility across these sites has the same issues as mobility within a datacenter, although the technology to address it must run "over" the L3 Internet.=20 Third, the need of a new approach is reinforced by multi-tenancy of cloud networks. Native L2 networks are constrained by 4096 VLANs, which may be too few segments to distinguish customers in a public cloud. Further, when private and public clouds are connected, private VLAN identities will get extended into the public domain, causing VLAN overlap. Some method of uniquely identifying a customer in the public cloud is needed. Fourth, given that small, large, huge datacenters will need to be interconnected and need to work seamlessly, the technology for the datacenter must be agnostic of the architecture used in a specific case. Each datacenter may architect the network differently depending on their scale. This has been true of past of L2 (e.g. STP) and L3 (e.g. OSPF) technologies that are topology agnostic. Fifth, networking schemes spanning across these large domains must be cognizant of "convergence" issues, especially arising out of VM mobility and hardware / software failures, which will be common at a large scale. Network convergence on mobility and failure will require control plane signaling and forwarding plane churn. This churn needs to be minimized in order to keep the network stable.=20 Sixth, large cloud datacenters depend on economies of scale, and need to reduce equipment cost and energy. This is possible only when the technology scales easily both at a hardware and software level, keeping the cost and energy consumed low. As an example, technologies that do map-encap require per flow hardware entries, and per flow setup signaling, which is very expensive at scale. Seventh, move into a multi-tenant environment depends upon sufficient "controls" for a user (preferably easy to use). Loss of control will prevent users from using these facilities (cloud doesn't equal to fuzzy). The "control" problem requires a standard interface across private-public and public-public domains. This interface should facilitate discovery and management of services, including real-time debugging and statistics. ------------ Thanks, Ashish =09 -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Friday, December 23, 2011 3:40 AM To: Thomas Narten; So, Ning Cc: dc@ietf.org Subject: [dc] Elevator Pitch (was: Scoping the Interim meeting) Folks, Amplifying what Thomas said: At this point, the most helpful thing that anyone can do is to summarize the problem(s) that we are trying to solve in a relatively terse email. Once we come to consensus on that brief summary, we can flesh it out into very short Internet Draft. I look forward to hearing your elevator pitches. Happy Holidays, Ron > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Wednesday, December 21, 2011 1:31 PM > To: So, Ning > Cc: Ronald Bonica; dc@ietf.org > Subject: Re: [dc] Scoping the Interim meeting >=20 > We sure have a lot of volunteers wanting to help. That is fine at one > level, but misses the bigger point. >=20 > The best way to help is to articulate a specific problem or area. >=20 > Do so on this list in a single message. We don't need yet more > documents (at least not yet). >=20 > 2-4 paragraphs (no more). Think "elevator pitch" > (http://en.wikipedia.org/wiki/Elevator_pitch). >=20 > You only get a couple of minutes to make your case, and if you can't > do so, either you don't understand the problem yourself well enough, > or the value-proposition just isn't compelling. >=20 > So far, I haven't seen discussions of specific problems (or problem > areas). What I'm seeing is pointers to lots of drafts, many of which > (for those that I've looked at) don't crisply get at a real, tangible > problem that I understand and think the IETF can/should work on. Bonus > points for showing: >=20 > 1) an operator (or some other clear customer/consumer technology) that > says "yes, that is what I need, and if it was available today, I'd > use it" >=20 > 2) a vendor saying "here is what my customers are telling me will > solve a problem of theirs", and we think an IETF standard is > needed. >=20 > 3) demonstration of a clear technical/protocol gap between what is > available today, and what is needed to address the problem. >=20 > Thomas >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From xuxiaohu@huawei.com Thu Dec 22 20:13:25 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E90311E80DC for ; Thu, 22 Dec 2011 20:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl2unqxam-uZ for ; Thu, 22 Dec 2011 20:13:24 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 28C4F11E80BD for ; Thu, 22 Dec 2011 20:13:24 -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 <0LWN00A2D2CNBX@szxga03-in.huawei.com> for dc@ietf.org; Fri, 23 Dec 2011 12:12:23 +0800 (CST) Received: from szxrg02-dlp.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 <0LWN005O22CNGE@szxga03-in.huawei.com> for dc@ietf.org; Fri, 23 Dec 2011 12:12:23 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFW89104; Fri, 23 Dec 2011 12:12:22 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Dec 2011 12:12:15 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 23 Dec 2011 12:12:05 +0800 Date: Fri, 23 Dec 2011 04:12:01 +0000 From: Xuxiaohu In-reply-to: <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> X-Originating-IP: [10.108.4.80] To: "Ashish Dalela (adalela)" , Ronald Bonica , Thomas Narten , "So, Ning" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762E59@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dc] Elevator Pitch (was: Scoping the Interim meeting) Thread-index: AQHMwPcEsHC/9og0C0ufJ/SJpsCdP5XoPNSAgACRjIA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> Cc: "dc@ietf.org" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 04:13:25 -0000 SGksDQoNCkxldCBtZSBleHByZXNzIG15IG9waW5pb24gb24geW91ciBmaXJzdCBwb2ludC4gSXQn cyB0cnVlIHRoYXQgaW5zdGFsbGluZyBob3N0IHJvdXRlIGlzIG5vdCBzY2FsYWJsZSBpbiBnZW5l cmFsLiBIb3dldmVyLCBvbmNlIHRoZSBzdWJuZXQgaGFzIGJlZW4gZXh0ZW5kZWQgYWNyb3NzIG11 bHRpcGxlIGRhdGEgY2VudGVycyBmb3IgVk0gbW9iaWxpdHksIHlvdSBjYW4gJ3QgdXNlIHN1Ym5l dCBmb3Igcm91dGluZyBhbnkgbW9yZS4gRWl0aGVyIE1BQyBiYXNlZCBmb3J3YXJkaW5nIG9yIGhv c3Qgcm91dGUgYmFzZWQgcm91dGluZyAoYm90aCBvZiB0aGVtIGFyZSBpbiB0aGUgaG9zdCBncmFu dWxhcml0eSksIHlvdSBuZWVkIHRvIGNob29zZSBvbmUuIFVzaW5nIE1vYmlsZSBJUCBhbGlrZSBh cHByb2FjaCB3aWxsIHN0cmV0Y2ggdGhlIGZvcndhcmRpbmcgcGF0aCBhbmQgaGVuY2Ugd2lsbCBp bmNyZWFzZSB0aGUgZm9yd2FyZGluZyBsYXRlbmN5LiBPbmNlIHdlIGNob29zZSB0aGUgaG9zdCBy b3V0ZSBiYXNlZCBhcHByb2FjaCwgd2UgY2FuIHVzZSB0aGUgbWFwJmVuY2FwIHNjaGVtZSBsaWtl IEwzVlBOIHRvIGFkZHJlc3MgdGhlIHNjYWxpbmcgaXNzdWUgb24gdGhlIFAgcm91dGVycywgYW5k IGZ1cnRoZXIgd2UgY2FuIGV2ZW4gdXNlIHRoZSBvbi1kZW1hbmQgRklCLWluc3RhbGxhdGlvbiBv ciBvbi1kZW1hbmQgcm91dGluZyBhbm5vdW5jZW1lbnQgdG8gYWRkcmVzcyB0aGUgRklCL1JJQiBz Y2FsaW5nIGlzc3VlIG9uIHRoZSBQRSByb3V0ZXJzLiANCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1 DQouDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGRjLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpkYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEFzaGlzaA0KPiBEYWxlbGEgKGFkYWxl bGEpDQo+ILeiy83KsbzkOiAyMDExxOoxMtTCMjPI1SAxMToyNQ0KPiDK1bz+yMs6IFJvbmFsZCBC b25pY2E7IFRob21hcyBOYXJ0ZW47IFNvLCBOaW5nDQo+ILOty806IGRjQGlldGYub3JnDQo+INb3 zOI6IFJlOiBbZGNdIEVsZXZhdG9yIFBpdGNoICh3YXM6IFNjb3BpbmcgdGhlIEludGVyaW0gbWVl dGluZykNCj4gDQo+IA0KPiBIZXJlJ3MgbXkgZWxldmF0b3IgcGl0Y2guIEknbGwgYXNzdW1lIHRo YXQgZWxldmF0b3IgaGFzIHRvIGdvIHRvIHRoZQ0KPiAxNDB0aCBmbG9vciwgd2l0aCBhIGZldyBz dG9wcy4NCj4gDQo+IC0tLS0tLS0tLS0tLS0NCj4gDQo+IExhcmdlIHZpcnR1YWxpemVkIGRhdGFj ZW50ZXJzIHBvc2Ugc2V2ZXJhbCBuZXR3b3JraW5nIGNoYWxsZW5nZXMuDQo+IA0KPiBGaXJzdCwg bmF0aXZlIEwyIG9yIEwzIGZvcndhcmRpbmcgdGVjaG5vbG9naWVzIGRvIG5vdCB3b3JrLiBMMiBu ZXR3b3Jrcw0KPiBjYW4ndCBiZSBsYXJnZSBkdWUgdG8gaGlnaCBudW1iZXIgb2YgYnJvYWRjYXN0 cy4gTDMgbmV0d29ya3MgY2FuJ3QgYmUNCj4gdXNlZCBiZWNhdXNlIG9mIFZNIG1vYmlsaXR5LCBz aW5jZSByb3V0aW5nIHVzZXMgc3VibmV0cyBhbmQgdGhlIElQDQo+IGNhbm5vdCBiZSBtb3ZlZCBv dXQgb2YgdGhhdCBzdWJuZXQuIE1vdmluZyBJUCBpbiBhIG5hdGl2ZWx5IEwzIG5ldHdvcmsNCj4g cmVxdWlyZXMgaW5zdGFsbGluZyBhIGhvc3Qgcm91dGUsIHdoaWNoIGlzIGFuIGFwcHJvYWNoIHRo YXQgY2FuJ3QgYmUNCj4gc2NhbGVkLiBIZW5jZSwgYSBuZXcgYXBwcm9hY2ggaXMgcmVxdWlyZWQu DQo+IA0KPiBTZWNvbmQsIGRhdGFjZW50ZXJzIHdpbGwgc3BhbiBhY3Jvc3MgbG9jYXRpb25zLCBh bmQgaW4gdGhlIGh5YnJpZCBjbG91ZA0KPiBjYXNlIG5lZWQgdG8gY29ubmVjdCBwcml2YXRlLXB1 YmxpYyBkb21haW5zLiBWTSBtb2JpbGl0eSBhY3Jvc3MgdGhlc2UNCj4gc2l0ZXMgaGFzIHRoZSBz YW1lIGlzc3VlcyBhcyBtb2JpbGl0eSB3aXRoaW4gYSBkYXRhY2VudGVyLCBhbHRob3VnaCB0aGUN Cj4gdGVjaG5vbG9neSB0byBhZGRyZXNzIGl0IG11c3QgcnVuICJvdmVyIiB0aGUgTDMgSW50ZXJu ZXQuDQo+IA0KPiBUaGlyZCwgdGhlIG5lZWQgb2YgYSBuZXcgYXBwcm9hY2ggaXMgcmVpbmZvcmNl ZCBieSBtdWx0aS10ZW5hbmN5IG9mDQo+IGNsb3VkIG5ldHdvcmtzLiBOYXRpdmUgTDIgbmV0d29y a3MgYXJlIGNvbnN0cmFpbmVkIGJ5IDQwOTYgVkxBTnMsIHdoaWNoDQo+IG1heSBiZSB0b28gZmV3 IHNlZ21lbnRzIHRvIGRpc3Rpbmd1aXNoIGN1c3RvbWVycyBpbiBhIHB1YmxpYyBjbG91ZC4NCj4g RnVydGhlciwgd2hlbiBwcml2YXRlIGFuZCBwdWJsaWMgY2xvdWRzIGFyZSBjb25uZWN0ZWQsIHBy aXZhdGUgVkxBTg0KPiBpZGVudGl0aWVzIHdpbGwgZ2V0IGV4dGVuZGVkIGludG8gdGhlIHB1Ymxp YyBkb21haW4sIGNhdXNpbmcgVkxBTg0KPiBvdmVybGFwLiBTb21lIG1ldGhvZCBvZiB1bmlxdWVs eSBpZGVudGlmeWluZyBhIGN1c3RvbWVyIGluIHRoZSBwdWJsaWMNCj4gY2xvdWQgaXMgbmVlZGVk Lg0KPiANCj4gRm91cnRoLCBnaXZlbiB0aGF0IHNtYWxsLCBsYXJnZSwgaHVnZSBkYXRhY2VudGVy cyB3aWxsIG5lZWQgdG8gYmUNCj4gaW50ZXJjb25uZWN0ZWQgYW5kIG5lZWQgdG8gd29yayBzZWFt bGVzc2x5LCB0aGUgdGVjaG5vbG9neSBmb3IgdGhlDQo+IGRhdGFjZW50ZXIgbXVzdCBiZSBhZ25v c3RpYyBvZiB0aGUgYXJjaGl0ZWN0dXJlIHVzZWQgaW4gYSBzcGVjaWZpYyBjYXNlLg0KPiBFYWNo IGRhdGFjZW50ZXIgbWF5IGFyY2hpdGVjdCB0aGUgbmV0d29yayBkaWZmZXJlbnRseSBkZXBlbmRp bmcgb24gdGhlaXINCj4gc2NhbGUuIFRoaXMgaGFzIGJlZW4gdHJ1ZSBvZiBwYXN0IG9mIEwyIChl LmcuIFNUUCkgYW5kIEwzIChlLmcuIE9TUEYpDQo+IHRlY2hub2xvZ2llcyB0aGF0IGFyZSB0b3Bv bG9neSBhZ25vc3RpYy4NCj4gDQo+IEZpZnRoLCBuZXR3b3JraW5nIHNjaGVtZXMgc3Bhbm5pbmcg YWNyb3NzIHRoZXNlIGxhcmdlIGRvbWFpbnMgbXVzdCBiZQ0KPiBjb2duaXphbnQgb2YgImNvbnZl cmdlbmNlIiBpc3N1ZXMsIGVzcGVjaWFsbHkgYXJpc2luZyBvdXQgb2YgVk0gbW9iaWxpdHkNCj4g YW5kIGhhcmR3YXJlIC8gc29mdHdhcmUgZmFpbHVyZXMsIHdoaWNoIHdpbGwgYmUgY29tbW9uIGF0 IGEgbGFyZ2Ugc2NhbGUuDQo+IE5ldHdvcmsgY29udmVyZ2VuY2Ugb24gbW9iaWxpdHkgYW5kIGZh aWx1cmUgd2lsbCByZXF1aXJlIGNvbnRyb2wgcGxhbmUNCj4gc2lnbmFsaW5nIGFuZCBmb3J3YXJk aW5nIHBsYW5lIGNodXJuLiBUaGlzIGNodXJuIG5lZWRzIHRvIGJlIG1pbmltaXplZA0KPiBpbiBv cmRlciB0byBrZWVwIHRoZSBuZXR3b3JrIHN0YWJsZS4NCj4gDQo+IFNpeHRoLCBsYXJnZSBjbG91 ZCBkYXRhY2VudGVycyBkZXBlbmQgb24gZWNvbm9taWVzIG9mIHNjYWxlLCBhbmQgbmVlZCB0bw0K PiByZWR1Y2UgZXF1aXBtZW50IGNvc3QgYW5kIGVuZXJneS4gVGhpcyBpcyBwb3NzaWJsZSBvbmx5 IHdoZW4gdGhlDQo+IHRlY2hub2xvZ3kgc2NhbGVzIGVhc2lseSBib3RoIGF0IGEgaGFyZHdhcmUg YW5kIHNvZnR3YXJlIGxldmVsLCBrZWVwaW5nDQo+IHRoZSBjb3N0IGFuZCBlbmVyZ3kgY29uc3Vt ZWQgbG93LiBBcyBhbiBleGFtcGxlLCB0ZWNobm9sb2dpZXMgdGhhdCBkbw0KPiBtYXAtZW5jYXAg cmVxdWlyZSBwZXIgZmxvdyBoYXJkd2FyZSBlbnRyaWVzLCBhbmQgcGVyIGZsb3cgc2V0dXANCj4g c2lnbmFsaW5nLCB3aGljaCBpcyB2ZXJ5IGV4cGVuc2l2ZSBhdCBzY2FsZS4NCj4gDQo+IFNldmVu dGgsIG1vdmUgaW50byBhIG11bHRpLXRlbmFudCBlbnZpcm9ubWVudCBkZXBlbmRzIHVwb24gc3Vm ZmljaWVudA0KPiAiY29udHJvbHMiIGZvciBhIHVzZXIgKHByZWZlcmFibHkgZWFzeSB0byB1c2Up LiBMb3NzIG9mIGNvbnRyb2wgd2lsbA0KPiBwcmV2ZW50IHVzZXJzIGZyb20gdXNpbmcgdGhlc2Ug ZmFjaWxpdGllcyAoY2xvdWQgZG9lc24ndCBlcXVhbCB0bw0KPiBmdXp6eSkuIFRoZSAiY29udHJv bCIgcHJvYmxlbSByZXF1aXJlcyBhIHN0YW5kYXJkIGludGVyZmFjZSBhY3Jvc3MNCj4gcHJpdmF0 ZS1wdWJsaWMgYW5kIHB1YmxpYy1wdWJsaWMgZG9tYWlucy4gVGhpcyBpbnRlcmZhY2Ugc2hvdWxk DQo+IGZhY2lsaXRhdGUgZGlzY292ZXJ5IGFuZCBtYW5hZ2VtZW50IG9mIHNlcnZpY2VzLCBpbmNs dWRpbmcgcmVhbC10aW1lDQo+IGRlYnVnZ2luZyBhbmQgc3RhdGlzdGljcy4NCj4gDQo+IC0tLS0t LS0tLS0tLQ0KPiANCj4gVGhhbmtzLCBBc2hpc2gNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGMtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmRjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBSb25hbGQgQm9uaWNh DQo+IFNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMjMsIDIwMTEgMzo0MCBBTQ0KPiBUbzogVGhvbWFz IE5hcnRlbjsgU28sIE5pbmcNCj4gQ2M6IGRjQGlldGYub3JnDQo+IFN1YmplY3Q6IFtkY10gRWxl dmF0b3IgUGl0Y2ggKHdhczogU2NvcGluZyB0aGUgSW50ZXJpbSBtZWV0aW5nKQ0KPiANCj4gRm9s a3MsDQo+IA0KPiBBbXBsaWZ5aW5nIHdoYXQgVGhvbWFzIHNhaWQ6DQo+IA0KPiBBdCB0aGlzIHBv aW50LCB0aGUgbW9zdCBoZWxwZnVsIHRoaW5nIHRoYXQgYW55b25lIGNhbiBkbyBpcyB0byBzdW1t YXJpemUNCj4gdGhlIHByb2JsZW0ocykgdGhhdCB3ZSBhcmUgdHJ5aW5nIHRvIHNvbHZlIGluIGEg cmVsYXRpdmVseSB0ZXJzZSBlbWFpbC4NCj4gT25jZSB3ZSBjb21lIHRvIGNvbnNlbnN1cyBvbiB0 aGF0IGJyaWVmIHN1bW1hcnksIHdlIGNhbiBmbGVzaCBpdCBvdXQNCj4gaW50byB2ZXJ5IHNob3J0 IEludGVybmV0IERyYWZ0Lg0KPiANCj4gSSBsb29rIGZvcndhcmQgdG8gaGVhcmluZyB5b3VyIGVs ZXZhdG9yIHBpdGNoZXMuDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEhhcHB5DQo+IEhvbGlkYXlzLA0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KPiANCj4gDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBkYy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gVGhvbWFzIE5h cnRlbg0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMjEsIDIwMTEgMTozMSBQTQ0KPiA+ IFRvOiBTbywgTmluZw0KPiA+IENjOiBSb25hbGQgQm9uaWNhOyBkY0BpZXRmLm9yZw0KPiA+IFN1 YmplY3Q6IFJlOiBbZGNdIFNjb3BpbmcgdGhlIEludGVyaW0gbWVldGluZw0KPiA+DQo+ID4gV2Ug c3VyZSBoYXZlIGEgbG90IG9mIHZvbHVudGVlcnMgd2FudGluZyB0byBoZWxwLiBUaGF0IGlzIGZp bmUgYXQgb25lDQo+ID4gbGV2ZWwsIGJ1dCBtaXNzZXMgdGhlIGJpZ2dlciBwb2ludC4NCj4gPg0K PiA+IFRoZSBiZXN0IHdheSB0byBoZWxwIGlzIHRvIGFydGljdWxhdGUgYSBzcGVjaWZpYyBwcm9i bGVtIG9yIGFyZWEuDQo+ID4NCj4gPiBEbyBzbyBvbiB0aGlzIGxpc3QgaW4gYSBzaW5nbGUgbWVz c2FnZS4gV2UgZG9uJ3QgbmVlZCB5ZXQgbW9yZQ0KPiA+IGRvY3VtZW50cyAoYXQgbGVhc3Qgbm90 IHlldCkuDQo+ID4NCj4gPiAyLTQgcGFyYWdyYXBocyAobm8gbW9yZSkuICBUaGluayAiZWxldmF0 b3IgcGl0Y2giDQo+ID4gKGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRWxldmF0b3JfcGl0 Y2gpLg0KPiA+DQo+ID4gWW91IG9ubHkgZ2V0IGEgY291cGxlIG9mIG1pbnV0ZXMgdG8gbWFrZSB5 b3VyIGNhc2UsIGFuZCBpZiB5b3UgY2FuJ3QNCj4gPiBkbyBzbywgZWl0aGVyIHlvdSBkb24ndCB1 bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHlvdXJzZWxmIHdlbGwgZW5vdWdoLA0KPiA+IG9yIHRoZSB2 YWx1ZS1wcm9wb3NpdGlvbiBqdXN0IGlzbid0IGNvbXBlbGxpbmcuDQo+ID4NCj4gPiBTbyBmYXIs IEkgaGF2ZW4ndCBzZWVuIGRpc2N1c3Npb25zIG9mIHNwZWNpZmljIHByb2JsZW1zIChvciBwcm9i bGVtDQo+ID4gYXJlYXMpLiBXaGF0IEknbSBzZWVpbmcgaXMgcG9pbnRlcnMgdG8gbG90cyBvZiBk cmFmdHMsIG1hbnkgb2Ygd2hpY2gNCj4gPiAoZm9yIHRob3NlIHRoYXQgSSd2ZSBsb29rZWQgYXQp IGRvbid0IGNyaXNwbHkgZ2V0IGF0IGEgcmVhbCwgdGFuZ2libGUNCj4gPiBwcm9ibGVtIHRoYXQg SSB1bmRlcnN0YW5kIGFuZCB0aGluayB0aGUgSUVURiBjYW4vc2hvdWxkIHdvcmsgb24uIEJvbnVz DQo+ID4gcG9pbnRzIGZvciBzaG93aW5nOg0KPiA+DQo+ID4gMSkgYW4gb3BlcmF0b3IgKG9yIHNv bWUgb3RoZXIgY2xlYXIgY3VzdG9tZXIvY29uc3VtZXIgdGVjaG5vbG9neSkgdGhhdA0KPiA+ICAg IHNheXMgInllcywgdGhhdCBpcyB3aGF0IEkgbmVlZCwgYW5kIGlmIGl0IHdhcyBhdmFpbGFibGUg dG9kYXksIEknZA0KPiA+ICAgIHVzZSBpdCINCj4gPg0KPiA+IDIpIGEgdmVuZG9yIHNheWluZyAi aGVyZSBpcyB3aGF0IG15IGN1c3RvbWVycyBhcmUgdGVsbGluZyBtZSB3aWxsDQo+ID4gICAgc29s dmUgYSBwcm9ibGVtIG9mIHRoZWlycyIsIGFuZCB3ZSB0aGluayBhbiBJRVRGIHN0YW5kYXJkIGlz DQo+ID4gICAgbmVlZGVkLg0KPiA+DQo+ID4gMykgZGVtb25zdHJhdGlvbiBvZiBhIGNsZWFyIHRl Y2huaWNhbC9wcm90b2NvbCBnYXAgYmV0d2VlbiB3aGF0IGlzDQo+ID4gICAgYXZhaWxhYmxlIHRv ZGF5LCBhbmQgd2hhdCBpcyBuZWVkZWQgdG8gYWRkcmVzcyB0aGUgcHJvYmxlbS4NCj4gPg0KPiA+ IFRob21hcw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBkYyBtYWlsaW5nIGxpc3QNCj4gPiBkY0BpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGMNCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGMgbWFpbGluZyBsaXN0DQo+IGRjQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGMNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGMgbWFpbGlu ZyBsaXN0DQo+IGRjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGMNCg== From adalela@cisco.com Thu Dec 22 20:57:44 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8CB11E80E6 for ; Thu, 22 Dec 2011 20:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kODKFfvds8J6 for ; Thu, 22 Dec 2011 20:57:43 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id A4FF311E80DC for ; Thu, 22 Dec 2011 20:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=9498; q=dns/txt; s=iport; t=1324616262; x=1325825862; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZdrGbzKnIM9W0fR7WKL9NKUnxkHF+tVm0tTl62VE5hI=; b=kIsTgoGr1bd8smlA1uN6n9V01iB5CVMHyNi7B4DD5qp9pZBCe8l1Dx/c 3zx8V1mWbGnAiobGrZzpQSq9/cNeOB6GDpYitRwoZ/SY85SDN5PN4bg0d ely/qp5oyeIPd5MN+gjdUlWJLw5uPfr3VvFENCamlF1vW0MON4n1311Eu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEAAEYJ9E5Io8UY/2dsb2JhbABDhQ+WSY08hCOBcgEBAQQBAQEPAR0+AgkMBAIBBgIRAQMBAQUGBgUSAQQCASYfAwYIAgQBCggIEweHYJhwAYxVCJFOgSuHPoIMN2MEiDWfBg X-IronPort-AV: E=Sophos;i="4.71,397,1320624000"; d="scan'208";a="2224052" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 23 Dec 2011 04:57:40 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBN4vfrP018467; Fri, 23 Dec 2011 04:57:41 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Dec 2011 10:27:40 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Dec 2011 10:27:42 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102A4884B@XMB-BGL-416.cisco.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762E59@szxeml525-mbs.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Elevator Pitch (was: Scoping the Interim meeting) Thread-Index: AQHMwPcEsHC/9og0C0ufJ/SJpsCdP5XoPNSAgACRjICAAAUxYA== References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com><13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net><618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762E59@szxeml525-mbs.china.huawei.com> From: "Ashish Dalela (adalela)" To: "Xuxiaohu" , "Ronald Bonica" , "Thomas Narten" , "So, Ning" X-OriginalArrivalTime: 23 Dec 2011 04:57:40.0825 (UTC) FILETIME=[66255C90:01CCC12F] Cc: dc@ietf.org Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 04:57:44 -0000 Xuxiaohu, I'm trying to avoid getting into a specific solution at this point, as = the request is to offer problem statements.=20 Here are a couple of more requirements to the below: ----------------------- Eighth, the packet forwarding scheme must be able to use all available = paths to a destination (ECMP). This is for load-balancing available = paths and maximizing utilization of available bandwidth. In a way that = implies turning off STP because STP blocks many paths. The requirement = holds true for intra-dc and inter-dc forwarding. The intra-dc is = governed by server-to-server (east-west) flows, and inter-dc due to many = users and bursts. Ninth, there should be mechanisms to guarantee network SLAs in a = multi-tenant environment. In particular, high traffic from one tenant = should not adversely affect all other tenants on the network who are = using the same shared network medium to communicate. Users entering a = multi-tenant environment ought to be able to specify their network needs = just as they specify compute and storage needs. VM mobility needs to = take into account if sufficient network bandwidth will be available = after move. It might also take into account latency. Tenth, forwarding schemes must be optimized for unicast, broadcast and = multicast traffics. In broadcast cases, this might imply broadcast = control (if possible, both within and between a dc). In multicast, it = implies choosing the most optimal points of packet replication to reduce = bandwidth use (access, core, edge, etc). Note that multicast replication = points may need to change with VM mobility. ----------------------- Thanks, Ashish -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of = Xuxiaohu Sent: Friday, December 23, 2011 9:42 AM To: Ashish Dalela (adalela); Ronald Bonica; Thomas Narten; So, Ning Cc: dc@ietf.org Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) Hi, Let me express my opinion on your first point. It's true that installing = host route is not scalable in general. However, once the subnet has been = extended across multiple data centers for VM mobility, you can 't use = subnet for routing any more. Either MAC based forwarding or host route = based routing (both of them are in the host granularity), you need to = choose one. Using Mobile IP alike approach will stretch the forwarding = path and hence will increase the forwarding latency. Once we choose the = host route based approach, we can use the map&encap scheme like L3VPN to = address the scaling issue on the P routers, and further we can even use = the on-demand FIB-installation or on-demand routing announcement to = address the FIB/RIB scaling issue on the PE routers.=20 Best regards, Xiaohu . > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] = =B4=FA=B1=ED Ashish > Dalela (adalela) > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA12=D4=C223=C8=D5 11:25 > =CA=D5=BC=FE=C8=CB: Ronald Bonica; Thomas Narten; So, Ning > =B3=AD=CB=CD: dc@ietf.org > =D6=F7=CC=E2: Re: [dc] Elevator Pitch (was: Scoping the Interim = meeting) >=20 >=20 > Here's my elevator pitch. I'll assume that elevator has to go to the > 140th floor, with a few stops. >=20 > ------------- >=20 > Large virtualized datacenters pose several networking challenges. >=20 > First, native L2 or L3 forwarding technologies do not work. L2 = networks > can't be large due to high number of broadcasts. L3 networks can't be > used because of VM mobility, since routing uses subnets and the IP > cannot be moved out of that subnet. Moving IP in a natively L3 network > requires installing a host route, which is an approach that can't be > scaled. Hence, a new approach is required. >=20 > Second, datacenters will span across locations, and in the hybrid = cloud > case need to connect private-public domains. VM mobility across these > sites has the same issues as mobility within a datacenter, although = the > technology to address it must run "over" the L3 Internet. >=20 > Third, the need of a new approach is reinforced by multi-tenancy of > cloud networks. Native L2 networks are constrained by 4096 VLANs, = which > may be too few segments to distinguish customers in a public cloud. > Further, when private and public clouds are connected, private VLAN > identities will get extended into the public domain, causing VLAN > overlap. Some method of uniquely identifying a customer in the public > cloud is needed. >=20 > Fourth, given that small, large, huge datacenters will need to be > interconnected and need to work seamlessly, the technology for the > datacenter must be agnostic of the architecture used in a specific = case. > Each datacenter may architect the network differently depending on = their > scale. This has been true of past of L2 (e.g. STP) and L3 (e.g. OSPF) > technologies that are topology agnostic. >=20 > Fifth, networking schemes spanning across these large domains must be > cognizant of "convergence" issues, especially arising out of VM = mobility > and hardware / software failures, which will be common at a large = scale. > Network convergence on mobility and failure will require control plane > signaling and forwarding plane churn. This churn needs to be minimized > in order to keep the network stable. >=20 > Sixth, large cloud datacenters depend on economies of scale, and need = to > reduce equipment cost and energy. This is possible only when the > technology scales easily both at a hardware and software level, = keeping > the cost and energy consumed low. As an example, technologies that do > map-encap require per flow hardware entries, and per flow setup > signaling, which is very expensive at scale. >=20 > Seventh, move into a multi-tenant environment depends upon sufficient > "controls" for a user (preferably easy to use). Loss of control will > prevent users from using these facilities (cloud doesn't equal to > fuzzy). The "control" problem requires a standard interface across > private-public and public-public domains. This interface should > facilitate discovery and management of services, including real-time > debugging and statistics. >=20 > ------------ >=20 > Thanks, Ashish >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Friday, December 23, 2011 3:40 AM > To: Thomas Narten; So, Ning > Cc: dc@ietf.org > Subject: [dc] Elevator Pitch (was: Scoping the Interim meeting) >=20 > Folks, >=20 > Amplifying what Thomas said: >=20 > At this point, the most helpful thing that anyone can do is to = summarize > the problem(s) that we are trying to solve in a relatively terse = email. > Once we come to consensus on that brief summary, we can flesh it out > into very short Internet Draft. >=20 > I look forward to hearing your elevator pitches. >=20 > Happy > Holidays, > Ron >=20 >=20 > > -----Original Message----- > > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > > Thomas Narten > > Sent: Wednesday, December 21, 2011 1:31 PM > > To: So, Ning > > Cc: Ronald Bonica; dc@ietf.org > > Subject: Re: [dc] Scoping the Interim meeting > > > > We sure have a lot of volunteers wanting to help. That is fine at = one > > level, but misses the bigger point. > > > > The best way to help is to articulate a specific problem or area. > > > > Do so on this list in a single message. We don't need yet more > > documents (at least not yet). > > > > 2-4 paragraphs (no more). Think "elevator pitch" > > (http://en.wikipedia.org/wiki/Elevator_pitch). > > > > You only get a couple of minutes to make your case, and if you can't > > do so, either you don't understand the problem yourself well enough, > > or the value-proposition just isn't compelling. > > > > So far, I haven't seen discussions of specific problems (or problem > > areas). What I'm seeing is pointers to lots of drafts, many of which > > (for those that I've looked at) don't crisply get at a real, = tangible > > problem that I understand and think the IETF can/should work on. = Bonus > > points for showing: > > > > 1) an operator (or some other clear customer/consumer technology) = that > > says "yes, that is what I need, and if it was available today, = I'd > > use it" > > > > 2) a vendor saying "here is what my customers are telling me will > > solve a problem of theirs", and we think an IETF standard is > > needed. > > > > 3) demonstration of a clear technical/protocol gap between what is > > available today, and what is needed to address the problem. > > > > Thomas > > > > _______________________________________________ > > dc mailing list > > dc@ietf.org > > https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From xuxiaohu@huawei.com Thu Dec 22 22:11:25 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8711E8096 for ; Thu, 22 Dec 2011 22:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31zRPPibmibV for ; Thu, 22 Dec 2011 22:11:24 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDA921F8AB8 for ; Thu, 22 Dec 2011 22:11:23 -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 <0LWN00BY07R2RN@szxga03-in.huawei.com> for dc@ietf.org; Fri, 23 Dec 2011 14:09:02 +0800 (CST) Received: from szxrg02-dlp.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 <0LWN008ZE7R200@szxga03-in.huawei.com> for dc@ietf.org; Fri, 23 Dec 2011 14:09:02 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFW95756; Fri, 23 Dec 2011 14:09:02 +0800 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Dec 2011 14:08:54 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Fri, 23 Dec 2011 14:08:58 +0800 Date: Fri, 23 Dec 2011 06:08:58 +0000 From: Xuxiaohu In-reply-to: <618BE8B40039924EB9AED233D4A09C5102A4884B@XMB-BGL-416.cisco.com> X-Originating-IP: [10.108.4.80] To: "Ashish Dalela (adalela)" , Ronald Bonica , Thomas Narten , "So, Ning" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762E90@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dc] Elevator Pitch (was: Scoping the Interim meeting) Thread-index: AQHMwPcEsHC/9og0C0ufJ/SJpsCdP5XoPNSAgACRjICAAAUxYIAAHF6Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762E59@szxeml525-mbs.china.huawei.com> <618BE8B40039924EB9AED233D4A09C5102A4884B@XMB-BGL-416.cisco.com> Cc: "dc@ietf.org" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 06:11:25 -0000 PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKSBb bWFpbHRvOmFkYWxlbGFAY2lzY28uY29tXQ0KPiC3osvNyrG85DogMjAxMcTqMTLUwjIzyNUgMTI6 NTgNCj4gytW8/sjLOiBYdXhpYW9odTsgUm9uYWxkIEJvbmljYTsgVGhvbWFzIE5hcnRlbjsgU28s IE5pbmcNCj4gs63LzTogZGNAaWV0Zi5vcmcNCj4g1vfM4jogUkU6IFtkY10gRWxldmF0b3IgUGl0 Y2ggKHdhczogU2NvcGluZyB0aGUgSW50ZXJpbSBtZWV0aW5nKQ0KPiANCj4gWHV4aWFvaHUsDQo+ IA0KPiBJJ20gdHJ5aW5nIHRvIGF2b2lkIGdldHRpbmcgaW50byBhIHNwZWNpZmljIHNvbHV0aW9u IGF0IHRoaXMgcG9pbnQsIGFzIHRoZSByZXF1ZXN0IGlzDQo+IHRvIG9mZmVyIHByb2JsZW0gc3Rh dGVtZW50cy4NCg0KWWVzLCBJIHNlZS4gSSdtIGFsc28gdHJ5aW5nIHRvIGF2b2lkIG1lbnRpb25p bmcgc29sdXRpb25zLCBlc3BlY2lhbGx5IHRob3NlIHNvbHV0aW9ucyB0byBiZSBpbnZlbnRlZC4g DQoNClhpYW9odQ0KDQo+IEhlcmUgYXJlIGEgY291cGxlIG9mIG1vcmUgcmVxdWlyZW1lbnRzIHRv IHRoZSBiZWxvdzoNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBFaWdodGgs IHRoZSBwYWNrZXQgZm9yd2FyZGluZyBzY2hlbWUgbXVzdCBiZSBhYmxlIHRvIHVzZSBhbGwgYXZh aWxhYmxlIHBhdGhzIHRvDQo+IGEgZGVzdGluYXRpb24gKEVDTVApLiBUaGlzIGlzIGZvciBsb2Fk LWJhbGFuY2luZyBhdmFpbGFibGUgcGF0aHMgYW5kIG1heGltaXppbmcNCj4gdXRpbGl6YXRpb24g b2YgYXZhaWxhYmxlIGJhbmR3aWR0aC4gSW4gYSB3YXkgdGhhdCBpbXBsaWVzIHR1cm5pbmcgb2Zm IFNUUCBiZWNhdXNlDQo+IFNUUCBibG9ja3MgbWFueSBwYXRocy4gVGhlIHJlcXVpcmVtZW50IGhv bGRzIHRydWUgZm9yIGludHJhLWRjIGFuZCBpbnRlci1kYw0KPiBmb3J3YXJkaW5nLiBUaGUgaW50 cmEtZGMgaXMgZ292ZXJuZWQgYnkgc2VydmVyLXRvLXNlcnZlciAoZWFzdC13ZXN0KSBmbG93cywg YW5kDQo+IGludGVyLWRjIGR1ZSB0byBtYW55IHVzZXJzIGFuZCBidXJzdHMuDQo+IA0KPiBOaW50 aCwgdGhlcmUgc2hvdWxkIGJlIG1lY2hhbmlzbXMgdG8gZ3VhcmFudGVlIG5ldHdvcmsgU0xBcyBp biBhDQo+IG11bHRpLXRlbmFudCBlbnZpcm9ubWVudC4gSW4gcGFydGljdWxhciwgaGlnaCB0cmFm ZmljIGZyb20gb25lIHRlbmFudCBzaG91bGQgbm90DQo+IGFkdmVyc2VseSBhZmZlY3QgYWxsIG90 aGVyIHRlbmFudHMgb24gdGhlIG5ldHdvcmsgd2hvIGFyZSB1c2luZyB0aGUgc2FtZQ0KPiBzaGFy ZWQgbmV0d29yayBtZWRpdW0gdG8gY29tbXVuaWNhdGUuIFVzZXJzIGVudGVyaW5nIGEgbXVsdGkt dGVuYW50DQo+IGVudmlyb25tZW50IG91Z2h0IHRvIGJlIGFibGUgdG8gc3BlY2lmeSB0aGVpciBu ZXR3b3JrIG5lZWRzIGp1c3QgYXMgdGhleQ0KPiBzcGVjaWZ5IGNvbXB1dGUgYW5kIHN0b3JhZ2Ug bmVlZHMuIFZNIG1vYmlsaXR5IG5lZWRzIHRvIHRha2UgaW50byBhY2NvdW50IGlmDQo+IHN1ZmZp Y2llbnQgbmV0d29yayBiYW5kd2lkdGggd2lsbCBiZSBhdmFpbGFibGUgYWZ0ZXIgbW92ZS4gSXQg bWlnaHQgYWxzbyB0YWtlDQo+IGludG8gYWNjb3VudCBsYXRlbmN5Lg0KPiANCj4gVGVudGgsIGZv cndhcmRpbmcgc2NoZW1lcyBtdXN0IGJlIG9wdGltaXplZCBmb3IgdW5pY2FzdCwgYnJvYWRjYXN0 IGFuZA0KPiBtdWx0aWNhc3QgdHJhZmZpY3MuIEluIGJyb2FkY2FzdCBjYXNlcywgdGhpcyBtaWdo dCBpbXBseSBicm9hZGNhc3QgY29udHJvbCAoaWYNCj4gcG9zc2libGUsIGJvdGggd2l0aGluIGFu ZCBiZXR3ZWVuIGEgZGMpLiBJbiBtdWx0aWNhc3QsIGl0IGltcGxpZXMgY2hvb3NpbmcgdGhlDQo+ IG1vc3Qgb3B0aW1hbCBwb2ludHMgb2YgcGFja2V0IHJlcGxpY2F0aW9uIHRvIHJlZHVjZSBiYW5k d2lkdGggdXNlIChhY2Nlc3MsDQo+IGNvcmUsIGVkZ2UsIGV0YykuIE5vdGUgdGhhdCBtdWx0aWNh c3QgcmVwbGljYXRpb24gcG9pbnRzIG1heSBuZWVkIHRvIGNoYW5nZQ0KPiB3aXRoIFZNIG1vYmls aXR5Lg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5rcywgQXNoaXNo DQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmRjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBY dXhpYW9odQ0KPiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDIzLCAyMDExIDk6NDIgQU0NCj4gVG86 IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpOyBSb25hbGQgQm9uaWNhOyBUaG9tYXMgTmFydGVuOyBT bywgTmluZw0KPiBDYzogZGNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkY10gRWxldmF0b3Ig UGl0Y2ggKHdhczogU2NvcGluZyB0aGUgSW50ZXJpbSBtZWV0aW5nKQ0KPiANCj4gSGksDQo+IA0K PiBMZXQgbWUgZXhwcmVzcyBteSBvcGluaW9uIG9uIHlvdXIgZmlyc3QgcG9pbnQuIEl0J3MgdHJ1 ZSB0aGF0IGluc3RhbGxpbmcgaG9zdCByb3V0ZQ0KPiBpcyBub3Qgc2NhbGFibGUgaW4gZ2VuZXJh bC4gSG93ZXZlciwgb25jZSB0aGUgc3VibmV0IGhhcyBiZWVuIGV4dGVuZGVkIGFjcm9zcw0KPiBt dWx0aXBsZSBkYXRhIGNlbnRlcnMgZm9yIFZNIG1vYmlsaXR5LCB5b3UgY2FuICd0IHVzZSBzdWJu ZXQgZm9yIHJvdXRpbmcgYW55DQo+IG1vcmUuIEVpdGhlciBNQUMgYmFzZWQgZm9yd2FyZGluZyBv ciBob3N0IHJvdXRlIGJhc2VkIHJvdXRpbmcgKGJvdGggb2YgdGhlbQ0KPiBhcmUgaW4gdGhlIGhv c3QgZ3JhbnVsYXJpdHkpLCB5b3UgbmVlZCB0byBjaG9vc2Ugb25lLiBVc2luZyBNb2JpbGUgSVAg YWxpa2UNCj4gYXBwcm9hY2ggd2lsbCBzdHJldGNoIHRoZSBmb3J3YXJkaW5nIHBhdGggYW5kIGhl bmNlIHdpbGwgaW5jcmVhc2UgdGhlDQo+IGZvcndhcmRpbmcgbGF0ZW5jeS4gT25jZSB3ZSBjaG9v c2UgdGhlIGhvc3Qgcm91dGUgYmFzZWQgYXBwcm9hY2gsIHdlIGNhbg0KPiB1c2UgdGhlIG1hcCZl bmNhcCBzY2hlbWUgbGlrZSBMM1ZQTiB0byBhZGRyZXNzIHRoZSBzY2FsaW5nIGlzc3VlIG9uIHRo ZSBQDQo+IHJvdXRlcnMsIGFuZCBmdXJ0aGVyIHdlIGNhbiBldmVuIHVzZSB0aGUgb24tZGVtYW5k IEZJQi1pbnN0YWxsYXRpb24gb3INCj4gb24tZGVtYW5kIHJvdXRpbmcgYW5ub3VuY2VtZW50IHRv IGFkZHJlc3MgdGhlIEZJQi9SSUIgc2NhbGluZyBpc3N1ZSBvbiB0aGUNCj4gUEUgcm91dGVycy4N Cj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IC4NCj4gPiAtLS0tLdPKvP7Urbz+LS0t LS0NCj4gPiC3orz+yMs6IGRjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkYy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIEFzaGlzaA0KPiA+IERhbGVsYSAoYWRhbGVsYSkNCj4gPiC3osvNyrG85Dog MjAxMcTqMTLUwjIzyNUgMTE6MjUNCj4gPiDK1bz+yMs6IFJvbmFsZCBCb25pY2E7IFRob21hcyBO YXJ0ZW47IFNvLCBOaW5nDQo+ID4gs63LzTogZGNAaWV0Zi5vcmcNCj4gPiDW98ziOiBSZTogW2Rj XSBFbGV2YXRvciBQaXRjaCAod2FzOiBTY29waW5nIHRoZSBJbnRlcmltIG1lZXRpbmcpDQo+ID4N Cj4gPg0KPiA+IEhlcmUncyBteSBlbGV2YXRvciBwaXRjaC4gSSdsbCBhc3N1bWUgdGhhdCBlbGV2 YXRvciBoYXMgdG8gZ28gdG8gdGhlDQo+ID4gMTQwdGggZmxvb3IsIHdpdGggYSBmZXcgc3RvcHMu DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBMYXJnZSB2aXJ0dWFsaXplZCBkYXRh Y2VudGVycyBwb3NlIHNldmVyYWwgbmV0d29ya2luZyBjaGFsbGVuZ2VzLg0KPiA+DQo+ID4gRmly c3QsIG5hdGl2ZSBMMiBvciBMMyBmb3J3YXJkaW5nIHRlY2hub2xvZ2llcyBkbyBub3Qgd29yay4g TDIgbmV0d29ya3MNCj4gPiBjYW4ndCBiZSBsYXJnZSBkdWUgdG8gaGlnaCBudW1iZXIgb2YgYnJv YWRjYXN0cy4gTDMgbmV0d29ya3MgY2FuJ3QgYmUNCj4gPiB1c2VkIGJlY2F1c2Ugb2YgVk0gbW9i aWxpdHksIHNpbmNlIHJvdXRpbmcgdXNlcyBzdWJuZXRzIGFuZCB0aGUgSVANCj4gPiBjYW5ub3Qg YmUgbW92ZWQgb3V0IG9mIHRoYXQgc3VibmV0LiBNb3ZpbmcgSVAgaW4gYSBuYXRpdmVseSBMMyBu ZXR3b3JrDQo+ID4gcmVxdWlyZXMgaW5zdGFsbGluZyBhIGhvc3Qgcm91dGUsIHdoaWNoIGlzIGFu IGFwcHJvYWNoIHRoYXQgY2FuJ3QgYmUNCj4gPiBzY2FsZWQuIEhlbmNlLCBhIG5ldyBhcHByb2Fj aCBpcyByZXF1aXJlZC4NCj4gPg0KPiA+IFNlY29uZCwgZGF0YWNlbnRlcnMgd2lsbCBzcGFuIGFj cm9zcyBsb2NhdGlvbnMsIGFuZCBpbiB0aGUgaHlicmlkIGNsb3VkDQo+ID4gY2FzZSBuZWVkIHRv IGNvbm5lY3QgcHJpdmF0ZS1wdWJsaWMgZG9tYWlucy4gVk0gbW9iaWxpdHkgYWNyb3NzIHRoZXNl DQo+ID4gc2l0ZXMgaGFzIHRoZSBzYW1lIGlzc3VlcyBhcyBtb2JpbGl0eSB3aXRoaW4gYSBkYXRh Y2VudGVyLCBhbHRob3VnaCB0aGUNCj4gPiB0ZWNobm9sb2d5IHRvIGFkZHJlc3MgaXQgbXVzdCBy dW4gIm92ZXIiIHRoZSBMMyBJbnRlcm5ldC4NCj4gPg0KPiA+IFRoaXJkLCB0aGUgbmVlZCBvZiBh IG5ldyBhcHByb2FjaCBpcyByZWluZm9yY2VkIGJ5IG11bHRpLXRlbmFuY3kgb2YNCj4gPiBjbG91 ZCBuZXR3b3Jrcy4gTmF0aXZlIEwyIG5ldHdvcmtzIGFyZSBjb25zdHJhaW5lZCBieSA0MDk2IFZM QU5zLCB3aGljaA0KPiA+IG1heSBiZSB0b28gZmV3IHNlZ21lbnRzIHRvIGRpc3Rpbmd1aXNoIGN1 c3RvbWVycyBpbiBhIHB1YmxpYyBjbG91ZC4NCj4gPiBGdXJ0aGVyLCB3aGVuIHByaXZhdGUgYW5k IHB1YmxpYyBjbG91ZHMgYXJlIGNvbm5lY3RlZCwgcHJpdmF0ZSBWTEFODQo+ID4gaWRlbnRpdGll cyB3aWxsIGdldCBleHRlbmRlZCBpbnRvIHRoZSBwdWJsaWMgZG9tYWluLCBjYXVzaW5nIFZMQU4N Cj4gPiBvdmVybGFwLiBTb21lIG1ldGhvZCBvZiB1bmlxdWVseSBpZGVudGlmeWluZyBhIGN1c3Rv bWVyIGluIHRoZSBwdWJsaWMNCj4gPiBjbG91ZCBpcyBuZWVkZWQuDQo+ID4NCj4gPiBGb3VydGgs IGdpdmVuIHRoYXQgc21hbGwsIGxhcmdlLCBodWdlIGRhdGFjZW50ZXJzIHdpbGwgbmVlZCB0byBi ZQ0KPiA+IGludGVyY29ubmVjdGVkIGFuZCBuZWVkIHRvIHdvcmsgc2VhbWxlc3NseSwgdGhlIHRl Y2hub2xvZ3kgZm9yIHRoZQ0KPiA+IGRhdGFjZW50ZXIgbXVzdCBiZSBhZ25vc3RpYyBvZiB0aGUg YXJjaGl0ZWN0dXJlIHVzZWQgaW4gYSBzcGVjaWZpYyBjYXNlLg0KPiA+IEVhY2ggZGF0YWNlbnRl ciBtYXkgYXJjaGl0ZWN0IHRoZSBuZXR3b3JrIGRpZmZlcmVudGx5IGRlcGVuZGluZyBvbiB0aGVp cg0KPiA+IHNjYWxlLiBUaGlzIGhhcyBiZWVuIHRydWUgb2YgcGFzdCBvZiBMMiAoZS5nLiBTVFAp IGFuZCBMMyAoZS5nLiBPU1BGKQ0KPiA+IHRlY2hub2xvZ2llcyB0aGF0IGFyZSB0b3BvbG9neSBh Z25vc3RpYy4NCj4gPg0KPiA+IEZpZnRoLCBuZXR3b3JraW5nIHNjaGVtZXMgc3Bhbm5pbmcgYWNy b3NzIHRoZXNlIGxhcmdlIGRvbWFpbnMgbXVzdCBiZQ0KPiA+IGNvZ25pemFudCBvZiAiY29udmVy Z2VuY2UiIGlzc3VlcywgZXNwZWNpYWxseSBhcmlzaW5nIG91dCBvZiBWTSBtb2JpbGl0eQ0KPiA+ IGFuZCBoYXJkd2FyZSAvIHNvZnR3YXJlIGZhaWx1cmVzLCB3aGljaCB3aWxsIGJlIGNvbW1vbiBh dCBhIGxhcmdlIHNjYWxlLg0KPiA+IE5ldHdvcmsgY29udmVyZ2VuY2Ugb24gbW9iaWxpdHkgYW5k IGZhaWx1cmUgd2lsbCByZXF1aXJlIGNvbnRyb2wgcGxhbmUNCj4gPiBzaWduYWxpbmcgYW5kIGZv cndhcmRpbmcgcGxhbmUgY2h1cm4uIFRoaXMgY2h1cm4gbmVlZHMgdG8gYmUgbWluaW1pemVkDQo+ ID4gaW4gb3JkZXIgdG8ga2VlcCB0aGUgbmV0d29yayBzdGFibGUuDQo+ID4NCj4gPiBTaXh0aCwg bGFyZ2UgY2xvdWQgZGF0YWNlbnRlcnMgZGVwZW5kIG9uIGVjb25vbWllcyBvZiBzY2FsZSwgYW5k IG5lZWQgdG8NCj4gPiByZWR1Y2UgZXF1aXBtZW50IGNvc3QgYW5kIGVuZXJneS4gVGhpcyBpcyBw b3NzaWJsZSBvbmx5IHdoZW4gdGhlDQo+ID4gdGVjaG5vbG9neSBzY2FsZXMgZWFzaWx5IGJvdGgg YXQgYSBoYXJkd2FyZSBhbmQgc29mdHdhcmUgbGV2ZWwsIGtlZXBpbmcNCj4gPiB0aGUgY29zdCBh bmQgZW5lcmd5IGNvbnN1bWVkIGxvdy4gQXMgYW4gZXhhbXBsZSwgdGVjaG5vbG9naWVzIHRoYXQg ZG8NCj4gPiBtYXAtZW5jYXAgcmVxdWlyZSBwZXIgZmxvdyBoYXJkd2FyZSBlbnRyaWVzLCBhbmQg cGVyIGZsb3cgc2V0dXANCj4gPiBzaWduYWxpbmcsIHdoaWNoIGlzIHZlcnkgZXhwZW5zaXZlIGF0 IHNjYWxlLg0KPiA+DQo+ID4gU2V2ZW50aCwgbW92ZSBpbnRvIGEgbXVsdGktdGVuYW50IGVudmly b25tZW50IGRlcGVuZHMgdXBvbiBzdWZmaWNpZW50DQo+ID4gImNvbnRyb2xzIiBmb3IgYSB1c2Vy IChwcmVmZXJhYmx5IGVhc3kgdG8gdXNlKS4gTG9zcyBvZiBjb250cm9sIHdpbGwNCj4gPiBwcmV2 ZW50IHVzZXJzIGZyb20gdXNpbmcgdGhlc2UgZmFjaWxpdGllcyAoY2xvdWQgZG9lc24ndCBlcXVh bCB0bw0KPiA+IGZ1enp5KS4gVGhlICJjb250cm9sIiBwcm9ibGVtIHJlcXVpcmVzIGEgc3RhbmRh cmQgaW50ZXJmYWNlIGFjcm9zcw0KPiA+IHByaXZhdGUtcHVibGljIGFuZCBwdWJsaWMtcHVibGlj IGRvbWFpbnMuIFRoaXMgaW50ZXJmYWNlIHNob3VsZA0KPiA+IGZhY2lsaXRhdGUgZGlzY292ZXJ5 IGFuZCBtYW5hZ2VtZW50IG9mIHNlcnZpY2VzLCBpbmNsdWRpbmcgcmVhbC10aW1lDQo+ID4gZGVi dWdnaW5nIGFuZCBzdGF0aXN0aWNzLg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBU aGFua3MsIEFzaGlzaA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogZGMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmRjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+IFJvbmFsZCBCb25pY2ENCj4g PiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDIzLCAyMDExIDM6NDAgQU0NCj4gPiBUbzogVGhvbWFz IE5hcnRlbjsgU28sIE5pbmcNCj4gPiBDYzogZGNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbZGNd IEVsZXZhdG9yIFBpdGNoICh3YXM6IFNjb3BpbmcgdGhlIEludGVyaW0gbWVldGluZykNCj4gPg0K PiA+IEZvbGtzLA0KPiA+DQo+ID4gQW1wbGlmeWluZyB3aGF0IFRob21hcyBzYWlkOg0KPiA+DQo+ ID4gQXQgdGhpcyBwb2ludCwgdGhlIG1vc3QgaGVscGZ1bCB0aGluZyB0aGF0IGFueW9uZSBjYW4g ZG8gaXMgdG8gc3VtbWFyaXplDQo+ID4gdGhlIHByb2JsZW0ocykgdGhhdCB3ZSBhcmUgdHJ5aW5n IHRvIHNvbHZlIGluIGEgcmVsYXRpdmVseSB0ZXJzZSBlbWFpbC4NCj4gPiBPbmNlIHdlIGNvbWUg dG8gY29uc2Vuc3VzIG9uIHRoYXQgYnJpZWYgc3VtbWFyeSwgd2UgY2FuIGZsZXNoIGl0IG91dA0K PiA+IGludG8gdmVyeSBzaG9ydCBJbnRlcm5ldCBEcmFmdC4NCj4gPg0KPiA+IEkgbG9vayBmb3J3 YXJkIHRvIGhlYXJpbmcgeW91ciBlbGV2YXRvciBwaXRjaGVzLg0KPiA+DQo+ID4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIYXBweQ0KPiA+IEhv bGlkYXlzLA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUm9uDQo+ID4NCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiA+IEZyb206IGRjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiA+IFRob21hcyBOYXJ0ZW4NCj4gPiA+IFNlbnQ6IFdl ZG5lc2RheSwgRGVjZW1iZXIgMjEsIDIwMTEgMTozMSBQTQ0KPiA+ID4gVG86IFNvLCBOaW5nDQo+ ID4gPiBDYzogUm9uYWxkIEJvbmljYTsgZGNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBb ZGNdIFNjb3BpbmcgdGhlIEludGVyaW0gbWVldGluZw0KPiA+ID4NCj4gPiA+IFdlIHN1cmUgaGF2 ZSBhIGxvdCBvZiB2b2x1bnRlZXJzIHdhbnRpbmcgdG8gaGVscC4gVGhhdCBpcyBmaW5lIGF0IG9u ZQ0KPiA+ID4gbGV2ZWwsIGJ1dCBtaXNzZXMgdGhlIGJpZ2dlciBwb2ludC4NCj4gPiA+DQo+ID4g PiBUaGUgYmVzdCB3YXkgdG8gaGVscCBpcyB0byBhcnRpY3VsYXRlIGEgc3BlY2lmaWMgcHJvYmxl bSBvciBhcmVhLg0KPiA+ID4NCj4gPiA+IERvIHNvIG9uIHRoaXMgbGlzdCBpbiBhIHNpbmdsZSBt ZXNzYWdlLiBXZSBkb24ndCBuZWVkIHlldCBtb3JlDQo+ID4gPiBkb2N1bWVudHMgKGF0IGxlYXN0 IG5vdCB5ZXQpLg0KPiA+ID4NCj4gPiA+IDItNCBwYXJhZ3JhcGhzIChubyBtb3JlKS4gIFRoaW5r ICJlbGV2YXRvciBwaXRjaCINCj4gPiA+IChodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Vs ZXZhdG9yX3BpdGNoKS4NCj4gPiA+DQo+ID4gPiBZb3Ugb25seSBnZXQgYSBjb3VwbGUgb2YgbWlu dXRlcyB0byBtYWtlIHlvdXIgY2FzZSwgYW5kIGlmIHlvdSBjYW4ndA0KPiA+ID4gZG8gc28sIGVp dGhlciB5b3UgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSB5b3Vyc2VsZiB3ZWxsIGVub3Vn aCwNCj4gPiA+IG9yIHRoZSB2YWx1ZS1wcm9wb3NpdGlvbiBqdXN0IGlzbid0IGNvbXBlbGxpbmcu DQo+ID4gPg0KPiA+ID4gU28gZmFyLCBJIGhhdmVuJ3Qgc2VlbiBkaXNjdXNzaW9ucyBvZiBzcGVj aWZpYyBwcm9ibGVtcyAob3IgcHJvYmxlbQ0KPiA+ID4gYXJlYXMpLiBXaGF0IEknbSBzZWVpbmcg aXMgcG9pbnRlcnMgdG8gbG90cyBvZiBkcmFmdHMsIG1hbnkgb2Ygd2hpY2gNCj4gPiA+IChmb3Ig dGhvc2UgdGhhdCBJJ3ZlIGxvb2tlZCBhdCkgZG9uJ3QgY3Jpc3BseSBnZXQgYXQgYSByZWFsLCB0 YW5naWJsZQ0KPiA+ID4gcHJvYmxlbSB0aGF0IEkgdW5kZXJzdGFuZCBhbmQgdGhpbmsgdGhlIElF VEYgY2FuL3Nob3VsZCB3b3JrIG9uLiBCb251cw0KPiA+ID4gcG9pbnRzIGZvciBzaG93aW5nOg0K PiA+ID4NCj4gPiA+IDEpIGFuIG9wZXJhdG9yIChvciBzb21lIG90aGVyIGNsZWFyIGN1c3RvbWVy L2NvbnN1bWVyIHRlY2hub2xvZ3kpIHRoYXQNCj4gPiA+ICAgIHNheXMgInllcywgdGhhdCBpcyB3 aGF0IEkgbmVlZCwgYW5kIGlmIGl0IHdhcyBhdmFpbGFibGUgdG9kYXksIEknZA0KPiA+ID4gICAg dXNlIGl0Ig0KPiA+ID4NCj4gPiA+IDIpIGEgdmVuZG9yIHNheWluZyAiaGVyZSBpcyB3aGF0IG15 IGN1c3RvbWVycyBhcmUgdGVsbGluZyBtZSB3aWxsDQo+ID4gPiAgICBzb2x2ZSBhIHByb2JsZW0g b2YgdGhlaXJzIiwgYW5kIHdlIHRoaW5rIGFuIElFVEYgc3RhbmRhcmQgaXMNCj4gPiA+ICAgIG5l ZWRlZC4NCj4gPiA+DQo+ID4gPiAzKSBkZW1vbnN0cmF0aW9uIG9mIGEgY2xlYXIgdGVjaG5pY2Fs L3Byb3RvY29sIGdhcCBiZXR3ZWVuIHdoYXQgaXMNCj4gPiA+ICAgIGF2YWlsYWJsZSB0b2RheSwg YW5kIHdoYXQgaXMgbmVlZGVkIHRvIGFkZHJlc3MgdGhlIHByb2JsZW0uDQo+ID4gPg0KPiA+ID4g VGhvbWFzDQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA+IGRjIG1haWxpbmcgbGlzdA0KPiA+ID4gZGNAaWV0Zi5vcmcNCj4g PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGMNCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGRjIG1haWxpbmcg bGlzdA0KPiA+IGRjQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kYw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gZGMgbWFpbGluZyBsaXN0DQo+ID4gZGNAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RjDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRjIG1haWxpbmcgbGlzdA0KPiBkY0BpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RjDQo= From xuxiaohu@huawei.com Thu Dec 22 22:39:06 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC9211E80DC; Thu, 22 Dec 2011 22:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy952nuKUbPk; Thu, 22 Dec 2011 22:39:05 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB0621F8AAC; Thu, 22 Dec 2011 22:39:05 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWN00JOR94TH9@szxga04-in.huawei.com>; Fri, 23 Dec 2011 14:38:53 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWN00FZW94LO9@szxga04-in.huawei.com>; Fri, 23 Dec 2011 14:38:53 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFW98823; Fri, 23 Dec 2011 14:38:43 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Dec 2011 14:38:41 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0323.003; Fri, 23 Dec 2011 14:38:41 +0800 Date: Fri, 23 Dec 2011 06:38:40 +0000 From: Xuxiaohu X-Originating-IP: [10.108.4.80] To: "Eggert, Lars" , "dc@ietf.org" , "dcrg-interest@irtf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: IP over IP solution for data center interconnect Thread-index: AQHMwT2CzwDYBIw29UGeVkQ77HSrWQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "armd@ietf.org" Subject: Re: [dc] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 06:39:06 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IFh1eGlhb2h1DQo+ILeiy83KsbzkOiAy MDExxOoxMtTCMjLI1SAxNjoyOA0KPiDK1bz+yMs6ICdFZ2dlcnQsIExhcnMnOyBkY0BpZXRmLm9y ZzsgJ2RjcmctaW50ZXJlc3RAaXJ0Zi5vcmcuJw0KPiDW98ziOiBJUCBvdmVyIElQIHNvbHV0aW9u IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IFRoZXJl IGhhcyBiZWVuIGEgbG90IG9mIEwyIG92ZXIgTDMgc29sdXRpb25zIG9yIHByb3Bvc2FscyBmb3Ig ZGF0YSBjZW50ZXINCj4gbmV0d29yayBhbmQgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0IHRpbGwg bm93LiBIb3dldmVyLCBpdCBzZWVtcyByZWNlbnRseQ0KPiB0aGVyZSBhcmUgaW5jcmVhc2luZyBp bnRlcmVzdHMgb24gTDMgb3ZlciBMMyAoZS5nLiwgSVAgb3ZlciBJUCkgc29sdXRpb25zIGZvciBk YXRhDQo+IGNlbnRlciBuZXR3b3JrIGFuZCBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QsIHBsZWFz ZSBzZWUgdGhlIGZvbGxvd2luZyB0ZXh0DQo+IHF1b3RlZCBmcm9tIElFVEY4MiBMMlZQTiBtaW51 dGVzDQo+ICggaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODIvbWludXRlcy9sMnZw bi50eHQpLiBJdCdzIGEgZ2VuZXJhbCBiZWxpZWYNCj4gdGhhdCBMMyBpcyBtb3JlIHNjYWxhYmxl IHRoYW4gTDIuIEVzcGVjaWFsbHkgd2hlbiBjb25zaWRlcmluZyB0aGUgZGF0YSBjZW50ZXINCj4g aW50ZXJjb25uZWN0aW9uIGNhc2UsIHRoZSBMMyBvdmVyIEwzIHNvbHV0aW9ucyBjYW4gYnJpbmcg REMgb3BlcmF0b3JzIG1vcmUNCj4gYmVuZWZpdHMgY29tcGFyZWQgdG8gdGhlIEwyIG92ZXIgTDMg c29sdXRpb25zLCBzdWNoIGFzIHBhdGggb3B0aW1pemF0aW9uLA0KPiBhY3RpdmUtYWN0aXZlIGRh dGEgY2VudGVycywgTUFDIHRhYmxlIHJlZHVjdGlvbiBvbiBEQyBzd2l0Y2hlcyBhbmQgYnJvYWRj YXN0DQo+IGZsb29kIHN1cHByZXNzaW9uIGV0YyAuDQoNCkJ5IHRoZSB3YXksIHRoZSBBUlAgdGFi bGUgc2NhbGluZyBpc3N1ZSBvbiBEQyBnYXRld2F5cywgd2hpY2ggaXMgZGVlbWVkIGJ5IHRoZSBB Uk1EIFdHIGFzIHRoZSBvbmx5IHdvcnRoeSBBUlAgcHJvYmxlbSBpbiBkYXRhIGNlbnRlciBuZXR3 b3JrcywgY291bGQgYWxzbyBiZSBzb2x2ZWQgd2l0aCB0aGUgSVAgb3ZlciBJUCBzb2x1dGlvbi4N Cg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQogDQo+IA0KPiBBbHRob3VnaCBMYXllciAyIGNvbm5l Y3Rpdml0eSBpcyBzdGlsbCByZXF1aXJlZCBmb3Igc29tZSBoaWdoLWF2YWlsYWJpbGl0eSBjbHVz dGVycw0KPiB3aGljaCB1c2Ugbm9uLUlQIGFuZCBsaW5rLWxvY2FsIG11bHRpY2FzdCBmb3IgY29t bXVuaWNhdGlvbiwgbW9yZSBhbmQgbW9yZQ0KPiBjbHVzdGVyIHZlbmRvcnMgYXJlIGVpdGhlciBh bHJlYWR5IGFibGUgdG8gc3VwcG9ydCBjbHVzdGVyIHNlcnZpY2VzIGF0IExheWVyMyBvcg0KPiB3 aWxsIHN1cHBvcnQgaXQgaW4gdGhlIG5lYXIgZnV0dXJlLiBJbiBhZGRpdGlvbiwgdGhlIEdTTEIg bWVjaGFuaXNtIChlLmcuLCBETlMNCj4gYmFzZWQgR1NMQikgd29ya3MgdmVyeSB3ZWxsIGluIG1v c3QgY2FzZXMsIGlzIGdlby1jbHVzdGVyIHNlcnZpY2Ugc3RpbGwgYQ0KPiBjb21tb24gcmVxdWly ZW1lbnQgZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdD8gSWYgbm90LCBjb3VsZCB3ZSBzcGVu ZCBhbnkNCj4gdGltZSBvbiBleHBsb3JpbmcgdGhlIHBvc3NpYmlsaXR5IG9mIHVzaW5nIEwzIG92 ZXIgTDMgc29sdXRpb24gZm9yIHRoZSBtb3N0IGRhdGENCj4gY2VudGVyIGludGVyY29ubmVjdGlv biBzY2VuYXJpb3Mgd2hlcmUgZ2VvLWNsdXN0ZXJpbmcsIGVzcGVjaWFsbHkgbm9uLUlQIGJhc2Vk DQo+IGdlby1jbHVzdGVyaW5nIGlzIG5vdCBuZWVkZWQ/DQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+ IFhpYW9odQ0KPiANCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IEtpcmVldGk6IEkga2VlcCBzZWVpbmcgSVNJ RCwgUEJCLCBWTEFOcy4gIFdlIGhhdmUgdG8gc3RvcCBjb25jZWRpbmcgdG8gbGF5ZXIgMg0KPiBh bmQgc3RhcnQgbW92aW5nIHRvIGxheWVyIDMgKGFwcGxhdXNlKSBhbmQgbG90cyBvZiBwcm9ibGVt cyB3aWxsIGdvIGF3YXkuDQo+IA0KPiBGbG9yaW46IFdlIHNob3VsZCBwdXQgVlBOIG9uIHRoZSBz YW1lIHBhZ2UgdG8gbW9kaWZ5IHRoZSBwcmlvcml0aWVzLiBZb3UgbmVlZA0KPiB0byBleHBhbmQg c28gY2FuIGxvb2sgYXQgTDMgb3ZlciBMMyBhcyB3ZWxsIGFzIEwyIG92ZXIgTDMuIEZvciBpdGVt IG51bWJlciAyIHdlDQo+IG5lZWQgdG8gbG9vayBhdCBMMyB0cmFuc3BvcnQgYXMgd2VsbCBhcyBF dGhlcm5ldCBhbmQgTVBMUy4gIEFuZCBmb3IgbnVtYmVyIDMNCj4gd2UgbmVlZCB0byB3b3JrIG9u IHRoaXMgYXMgdGhlcmUncyBhIGxvdCBvZiBleHBlcnRpc2UgaW4gTDIsIEwzIGFuZCBvdGhlciBX R3MuDQo+IA0KPiANCj4gTWFyYzogVGhlIHByb2JsZW0gc3RhdGVtZW50IG5lZWRzIHRvIGluY2x1 ZGUgbW9yZSBvZiB0aGUgTDMgaXNzdWVzIGFyb3VuZA0KPiBzZW5kaW5nIEwyIG92ZXIgTDMsIGFz IHRoZSBMMiB0cmFmZmljIGFscmVhZHkgY29udGFpbnMgTDMuICBJc3N1ZSBpcyBqdXN0IGZyYW1p bmcuDQo+IA0KPiBFcmljIE5vcmRtYXJrOyAiWWVzLCBZZXMgYW5kIFllcyIuICBXZSBuZWVkIHRv IGZvY3VzIGZyb20gdGhlIERDIHByb3NwZWN0aXZlDQo+IGFuZCBub3QgZnJvbSB0aGUgVlBOIHZp ZXcuICBkb24ndCBqdXN0IHRoaW5rIGFib3V0IEV0aGVybmV0IG92ZXIgSVAsIGJ1dCBhbHNvIElQ DQo+IG92ZXIgSVAuICBIeXBlcnZpc29yIG1heSBnZXQgZGVjb3VwbGVkIG92ZXIgdGltZS4NCj4g KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQo+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiBkYy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBFZ2dlcnQsDQo+ IExhcnMNCj4gPiC3osvNyrG85DogMjAxMcTqMTLUwjE2yNUgMTY6MjQNCj4gPiDK1bz+yMs6IGRj QGlldGYub3JnDQo+ID4g1vfM4jogW2RjXSBJUlRGIGRhdGFjZW50ZXIgcmVzZWFyY2ggZ3JvdXAg ZGlzY3Vzc2lvbiBsaXN0DQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IEkgd2FudGVkIHRvIG1ha2Ug eW91IGFsbCBhd2FyZSBvZiB0aGUgSVJURidzIGRjcmctaW50ZXJlc3QgbWFpbGluZyBsaXN0LCB3 aGljaA0KPiA+IHdhcyBzZXQgdXAgZm9sbG93aW5nIGEgZmFjZS10by1mYWNlIG1lZXRpbmcgYXQg U0lHQ09NTSB0aGlzIHllYXIgdG8gZGlzY3Vzcw0KPiBhDQo+ID4gcG9zc2libGUgSVJURiByZXNl YXJjaCBncm91cCBvbiBkYXRhY2VudGVyIG5ldHdvcmtpbmc6DQo+ID4gaHR0cDovL2lydGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGNyZy1pbnRlcmVzdA0KPiA+DQo+ID4gVGhlcmUgaGFzIG5vdCBi ZWVuIG11Y2ggYWN0aXZpdHkgdG93YXJkcyB0aGUgZm9ybWF0aW9uIG9mIGFuIElSVEYgUkcgc2lu Y2UNCj4gPiBTSUdDT01NLCBidXQgSSBhbSBob3BlZnVsIHRoYXQgdGhlIGhpZ2ggZW5lcmd5IGxl dmVsIGRlbW9uc3RyYXRlZCBpbiB0aGUNCj4gPiB2YXJpb3VzIFRhaXBlaSBtZWV0aW5ncyBvbiB0 aGUgdG9waWMgd2lsbCBpbmplY3Qgc29tZSBlbmVyZ3kgaGVyZSAtIHNldmVyYWwgb2YNCj4gPiB0 aGUgdG9waWNzIHRoYXQgbWF5IGJlIHRvbyBlYXJseSBmb3IgdGhlIElFVEYgdG8gc3RhbmRhcmRp emUgYXJvdW5kIHdvdWxkIGZpdA0KPiBhbg0KPiA+IElSVEYgUkcgdmVyeSB3ZWxsLiBJJ20gY2Vy dGFpbmx5IHN1cHBvcnRpdmUgb2YgdGhpcy4NCj4gPg0KPiA+IExhcnMNCj4gPiBJUlRGIENoYWly DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4gTW9iaWxlIG51bWJlciBkdXJpbmcgRGVjZW1iZXI6ICAg ICszNTggNDYgNTIxNTU4Mg0KPiA+IE1vYmlsZSBudW1iZXIgc3RhcnRpbmcgSmFudWFyeTogICs0 OSAxNTEgMTIwNTU3OTENCg0K From dave.mcdysan@verizon.com Fri Dec 23 04:59:53 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BDB21F8B5A for ; Fri, 23 Dec 2011 04:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80C0QJc9dIfg for ; Fri, 23 Dec 2011 04:59:52 -0800 (PST) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4110821F8B47 for ; Fri, 23 Dec 2011 04:59:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe03.verizon.com with ESMTP; 23 Dec 2011 12:59:51 +0000 From: "Mcdysan, David E" To: Ronald Bonica , Thomas Narten , "So, Ning" X-IronPort-AV: E=Sophos;i="4.71,398,1320624000"; d="scan'208";a="197279030" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 23 Dec 2011 12:59:36 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.86]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Fri, 23 Dec 2011 07:59:36 -0500 Date: Fri, 23 Dec 2011 07:59:28 -0500 Thread-Topic: [dc] Elevator Pitch (was: Scoping the Interim meeting) Thread-Index: AczBcri0ykm4uVRjStCKqfclutf8HQ== Message-ID: In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dc@ietf.org" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 12:59:53 -0000 Pitch on an Elevator in a shorter building. ;) Support an infrastructure for multiple tenants, each with computing applications and associated resources ranging from a single VM to a very large tenant with a complex, multi-site computing application. An important case is supporting a very large single tenant computing application. Ensure that each tenant is securely separated from others and that only tenants who mutually agree to communicate and/or share resources can do so. Orchestrate all of the virtual and real appliances (e.g., firewalls. load balancers, security, etc.) needed for a complex computing application distributed across multiple sites. Provide methods to optimize the placement and interconnection of computing, storage, appliance and networking resources. Work across a diverse set of networking technologies and architectures, ranging from dedicated special-purpose networks (e.g., Ethernet/PBB L2/L3 VPNs) to access over the Inernet. Be scalable on the high end to support hundreds of millions of Virtual Machines -- think one VM pre wireless subscriber. Be capable of meeting the quality objectives across a range of performance profiles corresponding to classes of tenants. Hope this helps, Dave On Thursday12/22/11 5:10 PM, "Ronald Bonica" wrote: >Folks, > >Amplifying what Thomas said: > >At this point, the most helpful thing that anyone can do is to summarize >the problem(s) that we are trying to solve in a relatively terse email. >Once we come to consensus on that brief summary, we can flesh it out into >very short Internet Draft. > >I look forward to hearing your elevator pitches. > > Happy Holidays, > Ron > > >> -----Original Message----- >> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >> Thomas Narten >> Sent: Wednesday, December 21, 2011 1:31 PM >> To: So, Ning >> Cc: Ronald Bonica; dc@ietf.org >> Subject: Re: [dc] Scoping the Interim meeting >>=20 >> We sure have a lot of volunteers wanting to help. That is fine at one >> level, but misses the bigger point. >>=20 >> The best way to help is to articulate a specific problem or area. >>=20 >> Do so on this list in a single message. We don't need yet more >> documents (at least not yet). >>=20 >> 2-4 paragraphs (no more). Think "elevator pitch" >> (http://en.wikipedia.org/wiki/Elevator_pitch). >>=20 >> You only get a couple of minutes to make your case, and if you can't >> do so, either you don't understand the problem yourself well enough, >> or the value-proposition just isn't compelling. >>=20 >> So far, I haven't seen discussions of specific problems (or problem >> areas). What I'm seeing is pointers to lots of drafts, many of which >> (for those that I've looked at) don't crisply get at a real, tangible >> problem that I understand and think the IETF can/should work on. Bonus >> points for showing: >>=20 >> 1) an operator (or some other clear customer/consumer technology) that >> says "yes, that is what I need, and if it was available today, I'd >> use it" >>=20 >> 2) a vendor saying "here is what my customers are telling me will >> solve a problem of theirs", and we think an IETF standard is >> needed. >>=20 >> 3) demonstration of a clear technical/protocol gap between what is >> available today, and what is needed to address the problem. >>=20 >> Thomas >>=20 >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc >_______________________________________________ >dc mailing list >dc@ietf.org >https://www.ietf.org/mailman/listinfo/dc From bschlies@cisco.com Fri Dec 23 07:24:27 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F1E21F8B12 for ; Fri, 23 Dec 2011 07:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woKatslllh7n for ; Fri, 23 Dec 2011 07:24:26 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 29DA221F8560 for ; Fri, 23 Dec 2011 07:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=5070; q=dns/txt; s=iport; t=1324653866; x=1325863466; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9kzhRZ5kc6V7+Qz37Y+gMwWOOofCuc9IHk3mugOsr1Y=; b=j7cFWEyRnIX+3fSX6Tmy5zmDPNCM7KaAUzgChLmwjNs/FHYSSLsUo35M VnRgTw02B4Xs7Z0a3yXLVxVy+35R/QF6du4HxIc5aQM6BcPS7m7hhd1m9 2tLN3C03qi9JUzvGrdFgq6tv9StPE7s3sz+ziNhZ9WOj4BaOQo8ox47uz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoAAJWc9E6tJXG8/2dsb2JhbABDm1uNPoMfgQWBcgEBAQMBAQEBDwEnKwkLBQcECxEEAQEBJwcnHwkIBhMbB4dYCJk1AZ4hiyxjBIg3jEuFT40E X-IronPort-AV: E=Sophos;i="4.71,399,1320624000"; d="scan'208";a="46483370" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 23 Dec 2011 15:24:25 +0000 Received: from [192.168.226.197] (rtp-vpn3-223.cisco.com [10.82.216.223]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBNFOOsq020745; Fri, 23 Dec 2011 15:24:24 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Benson Schliesser In-Reply-To: Date: Fri, 23 Dec 2011 09:24:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <153FE8AE-555C-4FA1-9B20-8ADFEC70DA5F@cisco.com> References: To: "Mcdysan, David E" X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , Ronald Bonica , "dc@ietf.org" , "So, Ning" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 15:24:27 -0000 Thanks, Dave. This helps a lot. Would you please help a bit more, by (a) suggesting whether each "piece" = of this should be done in the IETF or elsewhere, and (b) commenting on = whether existing solutions, to the extent they exist, don't meet your = requirements? I think you gave some useful hints, but I'd like to see = if we can get more explicit. For example, is orchestration simply something that is done in = proprietary software and/or standardized in existing forums (DMTF, = OCCI/OGF, OpenStack, etc.)? Is the interconnection requirement = satisfied by a combination of L2VPN and L3VPN technology, driven by = orchestration platforms? (Please note: I'm not suggesting that we already have the right tools. = Rather, I'm trying to find a good description of the gaps.) Cheers, -Benson On Dec 23, 2011, at 6:59 AM, Mcdysan, David E wrote: > Pitch on an Elevator in a shorter building. ;) >=20 > Support an infrastructure for multiple tenants, each with computing > applications and associated resources ranging from a single VM to a = very > large tenant with a complex, multi-site computing application. An > important case is supporting a very large single tenant computing > application. >=20 > Ensure that each tenant is securely separated from others and that = only > tenants who mutually agree to communicate and/or share resources can = do so. >=20 > Orchestrate all of the virtual and real appliances (e.g., firewalls. = load > balancers, security, etc.) needed for a complex computing application > distributed across multiple sites. >=20 >=20 > Provide methods to optimize the placement and interconnection of > computing, storage, appliance and networking resources. >=20 > Work across a diverse set of networking technologies and = architectures, > ranging from dedicated special-purpose networks (e.g., Ethernet/PBB = L2/L3 > VPNs) to access over the Inernet. >=20 > Be scalable on the high end to support hundreds of millions of Virtual > Machines -- think one VM pre wireless subscriber. >=20 > Be capable of meeting the quality objectives across a range of = performance > profiles corresponding to classes of tenants. >=20 > Hope this helps, >=20 > Dave >=20 >=20 > On Thursday12/22/11 5:10 PM, "Ronald Bonica" = wrote: >=20 >> Folks, >>=20 >> Amplifying what Thomas said: >>=20 >> At this point, the most helpful thing that anyone can do is to = summarize >> the problem(s) that we are trying to solve in a relatively terse = email. >> Once we come to consensus on that brief summary, we can flesh it out = into >> very short Internet Draft. >>=20 >> I look forward to hearing your elevator pitches. >>=20 >> Happy Holidays, >> Ron >>=20 >>=20 >>> -----Original Message----- >>> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >>> Thomas Narten >>> Sent: Wednesday, December 21, 2011 1:31 PM >>> To: So, Ning >>> Cc: Ronald Bonica; dc@ietf.org >>> Subject: Re: [dc] Scoping the Interim meeting >>>=20 >>> We sure have a lot of volunteers wanting to help. That is fine at = one >>> level, but misses the bigger point. >>>=20 >>> The best way to help is to articulate a specific problem or area. >>>=20 >>> Do so on this list in a single message. We don't need yet more >>> documents (at least not yet). >>>=20 >>> 2-4 paragraphs (no more). Think "elevator pitch" >>> (http://en.wikipedia.org/wiki/Elevator_pitch). >>>=20 >>> You only get a couple of minutes to make your case, and if you can't >>> do so, either you don't understand the problem yourself well enough, >>> or the value-proposition just isn't compelling. >>>=20 >>> So far, I haven't seen discussions of specific problems (or problem >>> areas). What I'm seeing is pointers to lots of drafts, many of which >>> (for those that I've looked at) don't crisply get at a real, = tangible >>> problem that I understand and think the IETF can/should work on. = Bonus >>> points for showing: >>>=20 >>> 1) an operator (or some other clear customer/consumer technology) = that >>> says "yes, that is what I need, and if it was available today, I'd >>> use it" >>>=20 >>> 2) a vendor saying "here is what my customers are telling me will >>> solve a problem of theirs", and we think an IETF standard is >>> needed. >>>=20 >>> 3) demonstration of a clear technical/protocol gap between what is >>> available today, and what is needed to address the problem. >>>=20 >>> Thomas >>>=20 >>> _______________________________________________ >>> dc mailing list >>> dc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dc >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From bschlies@cisco.com Fri Dec 23 09:44:51 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3230721F8549; Fri, 23 Dec 2011 09:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnF-tmGOAbfH; Fri, 23 Dec 2011 09:44:50 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7335721F8512; Fri, 23 Dec 2011 09:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1417; q=dns/txt; s=iport; t=1324662290; x=1325871890; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ms3r2r0VUx1n32sAdAYF37wjBTVhmftj7ETXWvpN4RU=; b=aKOAgCFNWWBaAS9A3Ly2FpkDAoUfKvWSEqGisdl0MaF8gcywNyWTrEOm D8rDSeaHL/tLJoeNOz+Oj6db6i0nwJeVI57tOhXDVnyB6BLCC8vRyz0/h jmvhN3iG7Jt1q3PPS7+tZARDNBUnOy7O3uRQHyRRgXHFMXNGFvUs0XCtq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJW99E6tJV2a/2dsb2JhbABDrDeBBYFyAQEBAwESASc0CwULC0ZXBi4Hh1iZLAGeGYssYwSIN4xLhU+NBA X-IronPort-AV: E=Sophos;i="4.71,400,1320624000"; d="scan'208";a="46525420" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 23 Dec 2011 17:44:50 +0000 Received: from [192.168.226.197] (rtp-vpn3-223.cisco.com [10.82.216.223]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBNHinZC001261; Fri, 23 Dec 2011 17:44:49 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Benson Schliesser In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com> Date: Fri, 23 Dec 2011 11:44:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9BD2028E-A6B7-478F-8CFA-95F1A832611B@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1084) Cc: dcrg-interest@irtf.org, "Eggert, Lars" , dc@ietf.org, armd@ietf.org Subject: Re: [dc] [dcrg-interest] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 17:44:51 -0000 On Dec 23, 2011, at 12:38 AM, Xuxiaohu wrote: > By the way, the ARP table scaling issue on DC gateways, which is = deemed by the ARMD WG as the only worthy ARP problem in data center = networks, could also be solved with the IP over IP solution. Two comments: First, if anybody is interested in exploring additional address = resolution issues in the datacenter, please speak up now on the ARMD = mailing list. We are attempting to finish our Problem Statement soon. = The Problem Statement will only include those issues that are described = by WG contributors. So if you think we should deem other issues to be = worthy problems, please contribute to the discussion. Second, at a high-level I think that a number of ARMD participants will = agree with your comment about ARP scale issues being solved by "IP over = IP" solutions. In fact, it's not just IP-over-IP that can help. Any = map-and-encap scheme, including L2-over-IP, can help by shifting the = burden to a mapping mechanism. Local ARP/ND proxy functions (e.g. in the = VM v-switch, TOR, etc) could take advantage of the mapping mechanism to = facilitate address resolution. In my personal opinion: The real problem is figuring out how to do the = mapping, what the right mapping approach is for a datacenter, etc. This = is the topic of the NVO3 effort that was discussed during L2VPN in = Taipei. Cheers, -Benson From aldrin.isaac@gmail.com Fri Dec 23 10:02:17 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AD021F8512 for ; Fri, 23 Dec 2011 10:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=-2.494, BAYES_00=-2.599, CN_BODY_35=0.339, J_BACKHAIR_53=1, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu-coC7fFdxp for ; Fri, 23 Dec 2011 10:02:16 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94E6D21F84FC for ; Fri, 23 Dec 2011 10:02:16 -0800 (PST) Received: by qcsf15 with SMTP id f15so6988761qcs.31 for ; Fri, 23 Dec 2011 10:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=FaNoiLWS2cJlAu3ZejcRd09XK1vkfNc+e5z5aECM7k4=; b=XYceXejIdmC3zPLVfJPcOwyS7MuHKVStfq9alBOBmDcc2Md78Ba4qnvAeQZp3CLxus iukk9egoBwWvAAhDzr3BsuIlX6EHLtYlLEzot6k8cPtXdDgc/PH5jzo5NDPPVNBiWXBA TtRNNrod7LkdNC0K+1VN7Aa087JBqI4mBgHcc= Received: by 10.224.198.10 with SMTP id em10mr19664855qab.44.1324663336093; Fri, 23 Dec 2011 10:02:16 -0800 (PST) Received: from mymac.home (ool-44c1c730.dyn.optonline.net. [68.193.199.48]) by mx.google.com with ESMTPS id dj9sm25413465qab.18.2011.12.23.10.02.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Dec 2011 10:02:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=GB2312 From: Aldrin Isaac In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762E59@szxeml525-mbs.china.huawei.com> Date: Fri, 23 Dec 2011 13:02:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7E5C20EB-4D18-4FB2-A2FE-F2D6554A26DC@gmail.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762E59@szxeml525-mbs.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1251.1) Cc: Thomas Narten , Ronald Bonica , "Ashish Dalela \(adalela\)" , "dc@ietf.org" , "So, Ning" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 18:02:17 -0000 I'd be interested in knowing if large [cloud] data center operators = would want to run a virtual LAN active-active across multiple hub sites = except under some unusual circumstances. Given need for managing scaling, inter-site bandwidth, etc, the = following is how I would guess a scalable elastic environment might need = to look: 1) Use L3-only overlay-based solution for VM-based customers/services = that require spoke<->hub workload migration and that DO NOT require = L2-based services. 2) Keep any single virtual LAN (or "l3-group" if l3-only) pinned to a = single hub site. A virtual LAN (or l3-group) would be assigned an IP = subnet prefix and members would be assigned an address from that prefix. = A gateway at the site where the subnet is active would advertise the = subnet into the core network. 3) Each hub site may further have sub-domains into which subnets may be = pinned under normal circumstances. 4) Assign subnets to hub sites based on site capacity and other = requirements (latency, etc). 5) Ensure that hub sites have sufficient capacity to handle the failure = of peer hub site. 6) If all the members of a subnet cannot be hosted at a hub site for any = reason, then move the entire subnet to another hub site. 7) If a site fails, move it's subnets to another hub site. On Dec 22, 2011, at 11:12 PM, Xuxiaohu wrote: > Hi, >=20 > Let me express my opinion on your first point. It's true that = installing host route is not scalable in general. However, once the = subnet has been extended across multiple data centers for VM mobility, = you can 't use subnet for routing any more. Either MAC based forwarding = or host route based routing (both of them are in the host granularity), = you need to choose one. Using Mobile IP alike approach will stretch the = forwarding path and hence will increase the forwarding latency. Once we = choose the host route based approach, we can use the map&encap scheme = like L3VPN to address the scaling issue on the P routers, and further we = can even use the on-demand FIB-installation or on-demand routing = announcement to address the FIB/RIB scaling issue on the PE routers.=20 >=20 > Best regards, > Xiaohu > . >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] = =B4=FA=B1=ED Ashish >> Dalela (adalela) >> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA12=D4=C223=C8=D5 11:25 >> =CA=D5=BC=FE=C8=CB: Ronald Bonica; Thomas Narten; So, Ning >> =B3=AD=CB=CD: dc@ietf.org >> =D6=F7=CC=E2: Re: [dc] Elevator Pitch (was: Scoping the Interim = meeting) >>=20 >>=20 >> Here's my elevator pitch. I'll assume that elevator has to go to the >> 140th floor, with a few stops. >>=20 >> ------------- >>=20 >> Large virtualized datacenters pose several networking challenges. >>=20 >> First, native L2 or L3 forwarding technologies do not work. L2 = networks >> can't be large due to high number of broadcasts. L3 networks can't be >> used because of VM mobility, since routing uses subnets and the IP >> cannot be moved out of that subnet. Moving IP in a natively L3 = network >> requires installing a host route, which is an approach that can't be >> scaled. Hence, a new approach is required. >>=20 >> Second, datacenters will span across locations, and in the hybrid = cloud >> case need to connect private-public domains. VM mobility across these >> sites has the same issues as mobility within a datacenter, although = the >> technology to address it must run "over" the L3 Internet. >>=20 >> Third, the need of a new approach is reinforced by multi-tenancy of >> cloud networks. Native L2 networks are constrained by 4096 VLANs, = which >> may be too few segments to distinguish customers in a public cloud. >> Further, when private and public clouds are connected, private VLAN >> identities will get extended into the public domain, causing VLAN >> overlap. Some method of uniquely identifying a customer in the public >> cloud is needed. >>=20 >> Fourth, given that small, large, huge datacenters will need to be >> interconnected and need to work seamlessly, the technology for the >> datacenter must be agnostic of the architecture used in a specific = case. >> Each datacenter may architect the network differently depending on = their >> scale. This has been true of past of L2 (e.g. STP) and L3 (e.g. OSPF) >> technologies that are topology agnostic. >>=20 >> Fifth, networking schemes spanning across these large domains must be >> cognizant of "convergence" issues, especially arising out of VM = mobility >> and hardware / software failures, which will be common at a large = scale. >> Network convergence on mobility and failure will require control = plane >> signaling and forwarding plane churn. This churn needs to be = minimized >> in order to keep the network stable. >>=20 >> Sixth, large cloud datacenters depend on economies of scale, and need = to >> reduce equipment cost and energy. This is possible only when the >> technology scales easily both at a hardware and software level, = keeping >> the cost and energy consumed low. As an example, technologies that do >> map-encap require per flow hardware entries, and per flow setup >> signaling, which is very expensive at scale. >>=20 >> Seventh, move into a multi-tenant environment depends upon sufficient >> "controls" for a user (preferably easy to use). Loss of control will >> prevent users from using these facilities (cloud doesn't equal to >> fuzzy). The "control" problem requires a standard interface across >> private-public and public-public domains. This interface should >> facilitate discovery and management of services, including real-time >> debugging and statistics. >>=20 >> ------------ >>=20 >> Thanks, Ashish >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >> Ronald Bonica >> Sent: Friday, December 23, 2011 3:40 AM >> To: Thomas Narten; So, Ning >> Cc: dc@ietf.org >> Subject: [dc] Elevator Pitch (was: Scoping the Interim meeting) >>=20 >> Folks, >>=20 >> Amplifying what Thomas said: >>=20 >> At this point, the most helpful thing that anyone can do is to = summarize >> the problem(s) that we are trying to solve in a relatively terse = email. >> Once we come to consensus on that brief summary, we can flesh it out >> into very short Internet Draft. >>=20 >> I look forward to hearing your elevator pitches. >>=20 >> Happy >> Holidays, >> Ron >>=20 >>=20 >>> -----Original Message----- >>> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >>> Thomas Narten >>> Sent: Wednesday, December 21, 2011 1:31 PM >>> To: So, Ning >>> Cc: Ronald Bonica; dc@ietf.org >>> Subject: Re: [dc] Scoping the Interim meeting >>>=20 >>> We sure have a lot of volunteers wanting to help. That is fine at = one >>> level, but misses the bigger point. >>>=20 >>> The best way to help is to articulate a specific problem or area. >>>=20 >>> Do so on this list in a single message. We don't need yet more >>> documents (at least not yet). >>>=20 >>> 2-4 paragraphs (no more). Think "elevator pitch" >>> (http://en.wikipedia.org/wiki/Elevator_pitch). >>>=20 >>> You only get a couple of minutes to make your case, and if you can't >>> do so, either you don't understand the problem yourself well enough, >>> or the value-proposition just isn't compelling. >>>=20 >>> So far, I haven't seen discussions of specific problems (or problem >>> areas). What I'm seeing is pointers to lots of drafts, many of which >>> (for those that I've looked at) don't crisply get at a real, = tangible >>> problem that I understand and think the IETF can/should work on. = Bonus >>> points for showing: >>>=20 >>> 1) an operator (or some other clear customer/consumer technology) = that >>> says "yes, that is what I need, and if it was available today, I'd >>> use it" >>>=20 >>> 2) a vendor saying "here is what my customers are telling me will >>> solve a problem of theirs", and we think an IETF standard is >>> needed. >>>=20 >>> 3) demonstration of a clear technical/protocol gap between what is >>> available today, and what is needed to address the problem. >>>=20 >>> Thomas >>>=20 >>> _______________________________________________ >>> dc mailing list >>> dc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dc >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From bschlies@cisco.com Fri Dec 23 10:18:32 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE0521F84F5 for ; Fri, 23 Dec 2011 10:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_BACKHAIR_53=1, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xeb2rJFhCIF4 for ; Fri, 23 Dec 2011 10:18:31 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA4B21F852E for ; Fri, 23 Dec 2011 10:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=10451; q=dns/txt; s=iport; t=1324664310; x=1325873910; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ky9tNcIDfeb7gVBT+rfzKfdvNtrX6m0uIP8uAyZwrrk=; b=ha+/4ybgc52Hjieum/KxwaQEkl6SK1BQ1cYMXtg3ouB9o7AN+6CJtWxs A7A36dTY/uuYClBzBMoSXswKSubL+09UH8d2HoCpjLtmJ0Ltt+tuZYviW QeXVNtKmP/mXNYeqCZ8tqcTDOdRmCRjxXPA5tjIWBeuBIEOy3JClqeBsR Y=; X-IronPort-AV: E=Sophos;i="4.71,400,1320624000"; d="scan'208";a="124615762" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 23 Dec 2011 18:18:29 +0000 Received: from [192.168.226.197] (rtp-vpn3-223.cisco.com [10.82.216.223]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBNIIRKk000477; Fri, 23 Dec 2011 18:18:28 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=GB2312 From: Benson Schliesser In-Reply-To: <7E5C20EB-4D18-4FB2-A2FE-F2D6554A26DC@gmail.com> Date: Fri, 23 Dec 2011 12:18:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7CDF3181-68AC-4115-B484-7D4C0F430DB4@cisco.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762E59@szxeml525-mbs.china.huawei.com> <7E5C20EB-4D18-4FB2-A2FE-F2D6554A26DC@gmail.com> To: Aldrin Isaac X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , "So, Ning" , "dc@ietf.org" , Ronald Bonica , Xuxiaohu , "Ashish Dalela \(adalela\)" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 18:18:32 -0000 Hi, Aldrin. Thanks. There are several good comments in your message that probably = deserve more exploration. But one of them catches my attention = immediately: Why do you assume that an overlay should be a "L3-Group" = and not support L2? To elaborate: If the underlying mechanism (i.e. IP in the case of = X-over-IP) provides the architectural benefits you need, and we can map = inner packets (i.e. X in the case of X-over-IP) into the overlay based = on either destination IP or MAC address, then does it really matter what = kind of service it provides (L2 vs L3)? I suppose that L2 services = might have different bandwidth implications, given the presence of = broadcast traffic etc. But I don't see how it materially affects the = protocol architecture. (That said: I'm admittedly biased, as a collaborator, but I think the = phrase from Thomas Narten's NVO3 presentation is quite nice: "L3 when = you can, L2 when you must.") Thoughts? Cheers, -Benson On Dec 23, 2011, at 12:02 PM, Aldrin Isaac wrote: > I'd be interested in knowing if large [cloud] data center operators = would want to run a virtual LAN active-active across multiple hub sites = except under some unusual circumstances. >=20 > Given need for managing scaling, inter-site bandwidth, etc, the = following is how I would guess a scalable elastic environment might need = to look: >=20 > 1) Use L3-only overlay-based solution for VM-based customers/services = that require spoke<->hub workload migration and that DO NOT require = L2-based services. > 2) Keep any single virtual LAN (or "l3-group" if l3-only) pinned to a = single hub site. A virtual LAN (or l3-group) would be assigned an IP = subnet prefix and members would be assigned an address from that prefix. = A gateway at the site where the subnet is active would advertise the = subnet into the core network. > 3) Each hub site may further have sub-domains into which subnets may = be pinned under normal circumstances. > 4) Assign subnets to hub sites based on site capacity and other = requirements (latency, etc). > 5) Ensure that hub sites have sufficient capacity to handle the = failure of peer hub site. > 6) If all the members of a subnet cannot be hosted at a hub site for = any reason, then move the entire subnet to another hub site. > 7) If a site fails, move it's subnets to another hub site. >=20 >=20 > On Dec 22, 2011, at 11:12 PM, Xuxiaohu wrote: >=20 >> Hi, >>=20 >> Let me express my opinion on your first point. It's true that = installing host route is not scalable in general. However, once the = subnet has been extended across multiple data centers for VM mobility, = you can 't use subnet for routing any more. Either MAC based forwarding = or host route based routing (both of them are in the host granularity), = you need to choose one. Using Mobile IP alike approach will stretch the = forwarding path and hence will increase the forwarding latency. Once we = choose the host route based approach, we can use the map&encap scheme = like L3VPN to address the scaling issue on the P routers, and further we = can even use the on-demand FIB-installation or on-demand routing = announcement to address the FIB/RIB scaling issue on the PE routers.=20 >>=20 >> Best regards, >> Xiaohu >> . >>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>> =B7=A2=BC=FE=C8=CB: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] = =B4=FA=B1=ED Ashish >>> Dalela (adalela) >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA12=D4=C223=C8=D5 11:25 >>> =CA=D5=BC=FE=C8=CB: Ronald Bonica; Thomas Narten; So, Ning >>> =B3=AD=CB=CD: dc@ietf.org >>> =D6=F7=CC=E2: Re: [dc] Elevator Pitch (was: Scoping the Interim = meeting) >>>=20 >>>=20 >>> Here's my elevator pitch. I'll assume that elevator has to go to the >>> 140th floor, with a few stops. >>>=20 >>> ------------- >>>=20 >>> Large virtualized datacenters pose several networking challenges. >>>=20 >>> First, native L2 or L3 forwarding technologies do not work. L2 = networks >>> can't be large due to high number of broadcasts. L3 networks can't = be >>> used because of VM mobility, since routing uses subnets and the IP >>> cannot be moved out of that subnet. Moving IP in a natively L3 = network >>> requires installing a host route, which is an approach that can't be >>> scaled. Hence, a new approach is required. >>>=20 >>> Second, datacenters will span across locations, and in the hybrid = cloud >>> case need to connect private-public domains. VM mobility across = these >>> sites has the same issues as mobility within a datacenter, although = the >>> technology to address it must run "over" the L3 Internet. >>>=20 >>> Third, the need of a new approach is reinforced by multi-tenancy of >>> cloud networks. Native L2 networks are constrained by 4096 VLANs, = which >>> may be too few segments to distinguish customers in a public cloud. >>> Further, when private and public clouds are connected, private VLAN >>> identities will get extended into the public domain, causing VLAN >>> overlap. Some method of uniquely identifying a customer in the = public >>> cloud is needed. >>>=20 >>> Fourth, given that small, large, huge datacenters will need to be >>> interconnected and need to work seamlessly, the technology for the >>> datacenter must be agnostic of the architecture used in a specific = case. >>> Each datacenter may architect the network differently depending on = their >>> scale. This has been true of past of L2 (e.g. STP) and L3 (e.g. = OSPF) >>> technologies that are topology agnostic. >>>=20 >>> Fifth, networking schemes spanning across these large domains must = be >>> cognizant of "convergence" issues, especially arising out of VM = mobility >>> and hardware / software failures, which will be common at a large = scale. >>> Network convergence on mobility and failure will require control = plane >>> signaling and forwarding plane churn. This churn needs to be = minimized >>> in order to keep the network stable. >>>=20 >>> Sixth, large cloud datacenters depend on economies of scale, and = need to >>> reduce equipment cost and energy. This is possible only when the >>> technology scales easily both at a hardware and software level, = keeping >>> the cost and energy consumed low. As an example, technologies that = do >>> map-encap require per flow hardware entries, and per flow setup >>> signaling, which is very expensive at scale. >>>=20 >>> Seventh, move into a multi-tenant environment depends upon = sufficient >>> "controls" for a user (preferably easy to use). Loss of control will >>> prevent users from using these facilities (cloud doesn't equal to >>> fuzzy). The "control" problem requires a standard interface across >>> private-public and public-public domains. This interface should >>> facilitate discovery and management of services, including real-time >>> debugging and statistics. >>>=20 >>> ------------ >>>=20 >>> Thanks, Ashish >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >>> Ronald Bonica >>> Sent: Friday, December 23, 2011 3:40 AM >>> To: Thomas Narten; So, Ning >>> Cc: dc@ietf.org >>> Subject: [dc] Elevator Pitch (was: Scoping the Interim meeting) >>>=20 >>> Folks, >>>=20 >>> Amplifying what Thomas said: >>>=20 >>> At this point, the most helpful thing that anyone can do is to = summarize >>> the problem(s) that we are trying to solve in a relatively terse = email. >>> Once we come to consensus on that brief summary, we can flesh it out >>> into very short Internet Draft. >>>=20 >>> I look forward to hearing your elevator pitches. >>>=20 >>> Happy >>> Holidays, >>> Ron >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >>>> Thomas Narten >>>> Sent: Wednesday, December 21, 2011 1:31 PM >>>> To: So, Ning >>>> Cc: Ronald Bonica; dc@ietf.org >>>> Subject: Re: [dc] Scoping the Interim meeting >>>>=20 >>>> We sure have a lot of volunteers wanting to help. That is fine at = one >>>> level, but misses the bigger point. >>>>=20 >>>> The best way to help is to articulate a specific problem or area. >>>>=20 >>>> Do so on this list in a single message. We don't need yet more >>>> documents (at least not yet). >>>>=20 >>>> 2-4 paragraphs (no more). Think "elevator pitch" >>>> (http://en.wikipedia.org/wiki/Elevator_pitch). >>>>=20 >>>> You only get a couple of minutes to make your case, and if you = can't >>>> do so, either you don't understand the problem yourself well = enough, >>>> or the value-proposition just isn't compelling. >>>>=20 >>>> So far, I haven't seen discussions of specific problems (or problem >>>> areas). What I'm seeing is pointers to lots of drafts, many of = which >>>> (for those that I've looked at) don't crisply get at a real, = tangible >>>> problem that I understand and think the IETF can/should work on. = Bonus >>>> points for showing: >>>>=20 >>>> 1) an operator (or some other clear customer/consumer technology) = that >>>> says "yes, that is what I need, and if it was available today, I'd >>>> use it" >>>>=20 >>>> 2) a vendor saying "here is what my customers are telling me will >>>> solve a problem of theirs", and we think an IETF standard is >>>> needed. >>>>=20 >>>> 3) demonstration of a clear technical/protocol gap between what is >>>> available today, and what is needed to address the problem. >>>>=20 >>>> Thomas >>>>=20 >>>> _______________________________________________ >>>> dc mailing list >>>> dc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dc >>> _______________________________________________ >>> dc mailing list >>> dc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dc >>> _______________________________________________ >>> dc mailing list >>> dc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dc >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From narten@us.ibm.com Fri Dec 23 16:23:44 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6221F84F5 for ; Fri, 23 Dec 2011 16:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.442 X-Spam-Level: X-Spam-Status: No, score=-106.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O04Y2xHYj-8m for ; Fri, 23 Dec 2011 16:23:43 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4318F21F84E5 for ; Fri, 23 Dec 2011 16:23:43 -0800 (PST) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 23 Dec 2011 17:23:42 -0700 Received: from d03relay05.boulder.ibm.com (9.17.195.107) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 23 Dec 2011 17:23:39 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBO0Nd2x126344 for ; Fri, 23 Dec 2011 17:23:39 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBO0Ndmn006804 for ; Fri, 23 Dec 2011 17:23:39 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-229-197.mts.ibm.com [9.65.229.197]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBO0Nbp8006778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Dec 2011 17:23:38 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pBO0NaP2008085; Fri, 23 Dec 2011 19:23:36 -0500 Message-Id: <201112240023.pBO0NaP2008085@cichlid.raleigh.ibm.com> To: "Mcdysan, David E" In-reply-to: References: Comments: In-reply-to "Mcdysan, David E" message dated "Fri, 23 Dec 2011 07:59:28 -0500." Date: Fri, 23 Dec 2011 19:23:36 -0500 From: Thomas Narten x-cbid: 11122400-3352-0000-0000-0000018A0A33 Cc: Ronald Bonica , "dc@ietf.org" , "So, Ning" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 00:23:44 -0000 Hi Dave. Thanks for this. Let me see if I can summarize and further tease this out. "Mcdysan, David E" writes: > Pitch on an Elevator in a shorter building. ;) > Support an infrastructure for multiple tenants, each with computing > applications and associated resources ranging from a single VM to a very > large tenant with a complex, multi-site computing application. An > important case is supporting a very large single tenant computing > application. I think you are stating that a key requirement is support for multi-tenancy. (And I would assume pretty much everyone agrees this is a requirement...) > Ensure that each tenant is securely separated from others and that only > tenants who mutually agree to communicate and/or share resources can > do so. This sounds like sub-bullets under the definition of multi-tenancy. > Orchestrate all of the virtual and real appliances (e.g., firewalls. load > balancers, security, etc.) needed for a complex computing application > distributed across multiple sites. This sounds like something very different and potential very big. By "orchestration" do you mean the system by which you can place or move VMs and all their associated dependent devices (FWs, LBs, etc.) around? How you place them, how you move components around? If so, this seems to me to be a combination of a (possibly) centralized controller (of sorts), with a lot of individual components distributed around the DC that provide necessary hooks/mechanisms for the orchestrator to do its job. I.e., moving a VM (and a FW) requires a number of steps. The orchestrator (at a high level) initiates those steps, but there are other network components that also play a role (the hypervisor, switches, etc.) Where do you see the standardization gaps in the above? What would be some example areas where IETF (or some other SDO) work is needed? > Provide methods to optimize the placement and interconnection of > computing, storage, appliance and networking resources. What would the standardization angle of this be? (FWIW, I don't see one right off, but I probably just don't understand what is meant/needed here). > Work across a diverse set of networking technologies and architectures, > ranging from dedicated special-purpose networks (e.g., Ethernet/PBB L2/L3 > VPNs) to access over the Inernet. This is a sub-bullet of the orchestration requirements? > Be scalable on the high end to support hundreds of millions of Virtual > Machines -- think one VM pre wireless subscriber. Is this a sub-requirement of orchestration? or multi-tenancy? or both? > Be capable of meeting the quality objectives across a range of performance > profiles corresponding to classes of tenants. Could you elaborate on this? Is this about meeting SLAs? What is the standardization angle (i.e., where work is needed, where there is a gap today). Thomas From xuxiaohu@huawei.com Fri Dec 23 17:27:33 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EC521F86B3; Fri, 23 Dec 2011 17:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.537 X-Spam-Level: X-Spam-Status: No, score=0.537 tagged_above=-999 required=5 tests=[AWL=-2.251, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1JVdqO7Jrd6; Fri, 23 Dec 2011 17:27:33 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB0F21F85A8; Fri, 23 Dec 2011 17:27:33 -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 <0LWO00KKAPDGLM@szxga03-in.huawei.com>; Sat, 24 Dec 2011 09:27:16 +0800 (CST) Received: from szxrg02-dlp.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 <0LWO003UEPDFVR@szxga03-in.huawei.com>; Sat, 24 Dec 2011 09:27:16 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFX42859; Sat, 24 Dec 2011 09:27:13 +0800 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Dec 2011 09:27:10 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Sat, 24 Dec 2011 09:27:09 +0800 Date: Sat, 24 Dec 2011 01:27:09 +0000 From: Xuxiaohu In-reply-to: <9BD2028E-A6B7-478F-8CFA-95F1A832611B@cisco.com> X-Originating-IP: [10.108.4.80] To: Benson Schliesser Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762FC9@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dcrg-interest] IP over IP solution for data center interconnect Thread-index: AQHMwT2CzwDYBIw29UGeVkQ77HSrWZXpLIkAgAD+00A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com> <9BD2028E-A6B7-478F-8CFA-95F1A832611B@cisco.com> Cc: "dcrg-interest@irtf.org" , "Eggert, Lars" , "dc@ietf.org" , "armd@ietf.org" Subject: [dc] =?gb2312?b?tPC4tDogW2RjcmctaW50ZXJlc3RdIElQIG92ZXIgSVAgc29s?= =?gb2312?b?dXRpb24gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdA==?= X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 01:27:33 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IEJlbnNvbiBTY2hsaWVzc2VyIFttYWls dG86YnNjaGxpZXNAY2lzY28uY29tXQ0KPiC3osvNyrG85DogMjAxMcTqMTLUwjI0yNUgMTo0NQ0K PiDK1bz+yMs6IFh1eGlhb2h1DQo+ILOty806IEVnZ2VydCwgTGFyczsgZGNAaWV0Zi5vcmc7IGRj cmctaW50ZXJlc3RAaXJ0Zi5vcmc7IGFybWRAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtkY3JnLWlu dGVyZXN0XSBJUCBvdmVyIElQIHNvbHV0aW9uIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QN Cj4gDQo+IA0KPiBPbiBEZWMgMjMsIDIwMTEsIGF0IDEyOjM4IEFNLCBYdXhpYW9odSB3cm90ZToN Cj4gDQo+ID4gQnkgdGhlIHdheSwgdGhlIEFSUCB0YWJsZSBzY2FsaW5nIGlzc3VlIG9uIERDIGdh dGV3YXlzLCB3aGljaCBpcyBkZWVtZWQgYnkNCj4gdGhlIEFSTUQgV0cgYXMgdGhlIG9ubHkgd29y dGh5IEFSUCBwcm9ibGVtIGluIGRhdGEgY2VudGVyIG5ldHdvcmtzLCBjb3VsZA0KPiBhbHNvIGJl IHNvbHZlZCB3aXRoIHRoZSBJUCBvdmVyIElQIHNvbHV0aW9uLg0KPiANCj4gVHdvIGNvbW1lbnRz Og0KPiANCj4gRmlyc3QsIGlmIGFueWJvZHkgaXMgaW50ZXJlc3RlZCBpbiBleHBsb3JpbmcgYWRk aXRpb25hbCBhZGRyZXNzIHJlc29sdXRpb24gaXNzdWVzIGluDQo+IHRoZSBkYXRhY2VudGVyLCBw bGVhc2Ugc3BlYWsgdXAgbm93IG9uIHRoZSBBUk1EIG1haWxpbmcgbGlzdC4gV2UgYXJlDQo+IGF0 dGVtcHRpbmcgdG8gZmluaXNoIG91ciBQcm9ibGVtIFN0YXRlbWVudCBzb29uLiBUaGUgUHJvYmxl bSBTdGF0ZW1lbnQgd2lsbA0KPiBvbmx5IGluY2x1ZGUgdGhvc2UgaXNzdWVzIHRoYXQgYXJlIGRl c2NyaWJlZCBieSBXRyBjb250cmlidXRvcnMuIFNvIGlmIHlvdSB0aGluaw0KPiB3ZSBzaG91bGQg ZGVlbSBvdGhlciBpc3N1ZXMgdG8gYmUgd29ydGh5IHByb2JsZW1zLCBwbGVhc2UgY29udHJpYnV0 ZSB0byB0aGUNCj4gZGlzY3Vzc2lvbi4NCj4gDQo+IFNlY29uZCwgYXQgYSBoaWdoLWxldmVsIEkg dGhpbmsgdGhhdCBhIG51bWJlciBvZiBBUk1EIHBhcnRpY2lwYW50cyB3aWxsIGFncmVlDQo+IHdp dGggeW91ciBjb21tZW50IGFib3V0IEFSUCBzY2FsZSBpc3N1ZXMgYmVpbmcgc29sdmVkIGJ5ICJJ UCBvdmVyIElQIg0KPiBzb2x1dGlvbnMuIEluIGZhY3QsIGl0J3Mgbm90IGp1c3QgSVAtb3Zlci1J UCB0aGF0IGNhbiBoZWxwLiBBbnkgbWFwLWFuZC1lbmNhcA0KPiBzY2hlbWUsIGluY2x1ZGluZyBM Mi1vdmVyLUlQLCBjYW4gaGVscCBieSBzaGlmdGluZyB0aGUgYnVyZGVuIHRvIGEgbWFwcGluZw0K PiBtZWNoYW5pc20uIExvY2FsIEFSUC9ORCBwcm94eSBmdW5jdGlvbnMgKGUuZy4gaW4gdGhlIFZN IHYtc3dpdGNoLCBUT1IsIGV0YykNCj4gY291bGQgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIG1hcHBp bmcgbWVjaGFuaXNtIHRvIGZhY2lsaXRhdGUgYWRkcmVzcw0KPiByZXNvbHV0aW9uLg0KDQoNCkFz IGZvciBMMiBvdmVyIElQIHNvbHV0aW9ucywgSSBhZ3JlZSB0aGF0IHRoZSBBUlAgYnJvYWRjYXN0 IGZsb29kIGltcGFjdCBvbiB0aGUgc2VydmVycy9yb3V0ZXJzIGFuZCBuZXR3b3JrcyBjb3VsZCBi ZSBhbGxldmlhdGVkIGJ5IHVzaW5nIHRoZSBBUlAgY2FjaGUgbWVjaGFuaXNtICh0b29scy5pZXRm Lm9yZy9wZGYvZHJhZnQtc2hhaC1hcm1kLWFycC1yZWR1Y3Rpb24tMDIudHh0KSBvciBzb21lIEFS UCBtYXBwaW5nIHN5c3RlbS4NCg0KSG93ZXZlciwgc2luY2UgdGhlIERDIGdhdGV3YXlzIHVzdWFs bHkgbmVlZCB0byBmb3J3YXJkIHRyYWZmaWMgdG8gc28gbWFueSBob3N0cyBhdCBtb3N0IHRpbWUs IHRoZXkgbmVlZCBhIHZlcnkgbGFyZ2UgQVJQIGNhY2hlIHRhYmxlIHRvIGNvbnRhaW4gc28gbWFu eSBBUlAgZW50cmllcy4gT3RoZXJ3aXNlLCB0aGUgQVJQIGNhY2hlIGFnaW5nLW91dCB0aW1lciBz aG91bGQgYmUgc2V0IHNob3J0IGVub3VnaC4gSW4gdGhlIHdheSwgdGhlIERDIGdhdGV3YXlzIHdv dWxkIGhhdmUgdG8gc2VuZCBBUlAgcmVxdWVzdHMgbW9yZSBmcmVxdWVudGx5LCBpbiBhZGRpdGlv biwgdGhlIGdhdGV3YXlzIGFyZSByZXF1aXJlZCB0byBoYXZlIGEgbXVjaCBsYXJnZSBwYWNrZXQg Y2FjaGUgdG8gY2FjaGUgdGhlIHJlY2VpdmVkIHBhY2tldHMgZGVzdGluZWQgZm9yIHRoZSBob3N0 cyBiZWZvcmUgdGhlIEFSUCByZXNwb25zZXMgZm9yIHRoZW0gYXJlIHJldHVybmVkLCBvdGhlcndp c2UgdGhlIHJlY2VpdmVkIHBhY2tldHMgd291bGQgaGF2ZSB0byBiZSBkaXNjYXJkZWQgd2hlbiB0 aGUgY2FjaGUgaXMgb3ZlcmZsb3dlZC4gSW4gYSB3b3JkLCBJIGRvbid0IGtub3cgaG93IHRoZSBt YXBwaW5nIHN5c3RlbSBjb3VsZCBoZWxwIG9uIHRoaXMgQVJQIHRhYmxlIHNjYWxpbmcgaXNzdWUu DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IEluIG15IHBlcnNvbmFsIG9waW5pb246IFRo ZSByZWFsIHByb2JsZW0gaXMgZmlndXJpbmcgb3V0IGhvdyB0byBkbyB0aGUgbWFwcGluZywNCj4g d2hhdCB0aGUgcmlnaHQgbWFwcGluZyBhcHByb2FjaCBpcyBmb3IgYSBkYXRhY2VudGVyLCBldGMu ICBUaGlzIGlzIHRoZSB0b3BpYyBvZg0KPiB0aGUgTlZPMyBlZmZvcnQgdGhhdCB3YXMgZGlzY3Vz c2VkIGR1cmluZyBMMlZQTiBpbiBUYWlwZWkuDQo+IA0KPiBDaGVlcnMsDQo+IC1CZW5zb24NCj4g DQoNCg== From aldrin.isaac@gmail.com Sat Dec 24 10:27:12 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB86321F8469 for ; Sat, 24 Dec 2011 10:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.99 X-Spam-Level: * X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_BACKHAIR_53=1, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_35=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw0R2PJN+ezW for ; Sat, 24 Dec 2011 10:27:11 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 451F521F8466 for ; Sat, 24 Dec 2011 10:27:11 -0800 (PST) Received: by wibhj6 with SMTP id hj6so4658988wib.31 for ; Sat, 24 Dec 2011 10:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rKFBVBKIyAqlWlj1CcF07oqyOgjmO5ZpimuK28PcJic=; b=iFtrIZMaE+pM6aK+qs6IDDl6DQtKQXLpcYObRMuzTePKp7irjV/7X1d45VEVx+/mns dAvJR2RsHhJ8qVW2SKUGOQUVwHhn9WuQvkH3TF1EQV3OousDv3GNBGf9iQNq5ZG8eBzr otPRvk/KY/0dRd0fl9E48LPjyVSQbEZT19z+k= MIME-Version: 1.0 Received: by 10.180.83.69 with SMTP id o5mr42117846wiy.1.1324751229178; Sat, 24 Dec 2011 10:27:09 -0800 (PST) Received: by 10.180.95.197 with HTTP; Sat, 24 Dec 2011 10:27:09 -0800 (PST) In-Reply-To: <7CDF3181-68AC-4115-B484-7D4C0F430DB4@cisco.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762E59@szxeml525-mbs.china.huawei.com> <7E5C20EB-4D18-4FB2-A2FE-F2D6554A26DC@gmail.com> <7CDF3181-68AC-4115-B484-7D4C0F430DB4@cisco.com> Date: Sat, 24 Dec 2011 13:27:09 -0500 Message-ID: From: Aldrin Isaac To: Benson Schliesser Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "dc@ietf.org" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 18:27:13 -0000 Hi Benson, Looking beyond the encapsulation, spoke<->hub site VM migration service is, IMO, a WAN service for which LAN behavior (overlay or otherwise) may not be a good fit. That said, L3-only solutions appear to be realistic only for VM-only environments. Speaking for myself today, a realistic vpn4dc solution would support a mix of managed and colocated virtual and physical systems in the same virtual LAN. Best -- aldrin 2011/12/23 Benson Schliesser : > Hi, Aldrin. > > Thanks. There are several good comments in your message that probably des= erve more exploration. But one of them catches my attention immediately: = Why do you assume that an overlay should be a "L3-Group" and not support L2= ? > > To elaborate: If the underlying mechanism (i.e. IP in the case of X-over= -IP) provides the architectural benefits you need, and we can map inner pac= kets (i.e. X in the case of X-over-IP) into the overlay based on either des= tination IP or MAC address, then does it really matter what kind of service= it provides (L2 vs L3)? I suppose that L2 services might have different b= andwidth implications, given the presence of broadcast traffic etc. But I d= on't see how it materially affects the protocol architecture. > > (That said: I'm admittedly biased, as a collaborator, but I think the ph= rase from Thomas Narten's NVO3 presentation is quite nice: "L3 when you can= , L2 when you must.") > > Thoughts? > > Cheers, > -Benson > > > On Dec 23, 2011, at 12:02 PM, Aldrin Isaac wrote: > >> I'd be interested in knowing if large [cloud] data center operators woul= d want to run a virtual LAN active-active across multiple hub sites except = under some unusual circumstances. >> >> Given need for managing scaling, inter-site bandwidth, etc, the followin= g is how I would guess a scalable elastic environment might need to look: >> >> 1) Use L3-only overlay-based solution for VM-based customers/services th= at require spoke<->hub workload migration and that DO NOT require L2-based = services. >> 2) Keep any single virtual LAN (or "l3-group" if l3-only) pinned to a si= ngle hub site. A virtual LAN (or l3-group) would be assigned an IP subnet = prefix and members would be assigned an address from that prefix. A gatewa= y at the site where the subnet is active would advertise the subnet into th= e core network. >> 3) Each hub site may further have sub-domains into which subnets may be = pinned under normal circumstances. >> 4) Assign subnets to hub sites based on site capacity and other requirem= ents (latency, etc). >> 5) Ensure that hub sites have sufficient capacity to handle the failure = of peer hub site. >> 6) If all the members of a subnet cannot be hosted at a hub site for any= reason, then move the entire subnet to another hub site. >> 7) If a site fails, move it's subnets to another hub site. >> >> >> On Dec 22, 2011, at 11:12 PM, Xuxiaohu wrote: >> >>> Hi, >>> >>> Let me express my opinion on your first point. It's true that installin= g host route is not scalable in general. However, once the subnet has been = extended across multiple data centers for VM mobility, you can 't use subne= t for routing any more. Either MAC based forwarding or host route based rou= ting (both of them are in the host granularity), you need to choose one. Us= ing Mobile IP alike approach will stretch the forwarding path and hence wil= l increase the forwarding latency. Once we choose the host route based appr= oach, we can use the map&encap scheme like L3VPN to address the scaling iss= ue on the P routers, and further we can even use the on-demand FIB-installa= tion or on-demand routing announcement to address the FIB/RIB scaling issue= on the PE routers. >>> >>> Best regards, >>> Xiaohu >>> . >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>>> =B7=A2=BC=FE=C8=CB: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] = =B4=FA=B1=ED Ashish >>>> Dalela (adalela) >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA12=D4=C223=C8=D5 11:25 >>>> =CA=D5=BC=FE=C8=CB: Ronald Bonica; Thomas Narten; So, Ning >>>> =B3=AD=CB=CD: dc@ietf.org >>>> =D6=F7=CC=E2: Re: [dc] Elevator Pitch (was: Scoping the Interim meetin= g) >>>> >>>> >>>> Here's my elevator pitch. I'll assume that elevator has to go to the >>>> 140th floor, with a few stops. >>>> >>>> ------------- >>>> >>>> Large virtualized datacenters pose several networking challenges. >>>> >>>> First, native L2 or L3 forwarding technologies do not work. L2 network= s >>>> can't be large due to high number of broadcasts. L3 networks can't be >>>> used because of VM mobility, since routing uses subnets and the IP >>>> cannot be moved out of that subnet. Moving IP in a natively L3 network >>>> requires installing a host route, which is an approach that can't be >>>> scaled. Hence, a new approach is required. >>>> >>>> Second, datacenters will span across locations, and in the hybrid clou= d >>>> case need to connect private-public domains. VM mobility across these >>>> sites has the same issues as mobility within a datacenter, although th= e >>>> technology to address it must run "over" the L3 Internet. >>>> >>>> Third, the need of a new approach is reinforced by multi-tenancy of >>>> cloud networks. Native L2 networks are constrained by 4096 VLANs, whic= h >>>> may be too few segments to distinguish customers in a public cloud. >>>> Further, when private and public clouds are connected, private VLAN >>>> identities will get extended into the public domain, causing VLAN >>>> overlap. Some method of uniquely identifying a customer in the public >>>> cloud is needed. >>>> >>>> Fourth, given that small, large, huge datacenters will need to be >>>> interconnected and need to work seamlessly, the technology for the >>>> datacenter must be agnostic of the architecture used in a specific cas= e. >>>> Each datacenter may architect the network differently depending on the= ir >>>> scale. This has been true of past of L2 (e.g. STP) and L3 (e.g. OSPF) >>>> technologies that are topology agnostic. >>>> >>>> Fifth, networking schemes spanning across these large domains must be >>>> cognizant of "convergence" issues, especially arising out of VM mobili= ty >>>> and hardware / software failures, which will be common at a large scal= e. >>>> Network convergence on mobility and failure will require control plane >>>> signaling and forwarding plane churn. This churn needs to be minimized >>>> in order to keep the network stable. >>>> >>>> Sixth, large cloud datacenters depend on economies of scale, and need = to >>>> reduce equipment cost and energy. This is possible only when the >>>> technology scales easily both at a hardware and software level, keepin= g >>>> the cost and energy consumed low. As an example, technologies that do >>>> map-encap require per flow hardware entries, and per flow setup >>>> signaling, which is very expensive at scale. >>>> >>>> Seventh, move into a multi-tenant environment depends upon sufficient >>>> "controls" for a user (preferably easy to use). Loss of control will >>>> prevent users from using these facilities (cloud doesn't equal to >>>> fuzzy). The "control" problem requires a standard interface across >>>> private-public and public-public domains. This interface should >>>> facilitate discovery and management of services, including real-time >>>> debugging and statistics. >>>> >>>> ------------ >>>> >>>> Thanks, Ashish >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >>>> Ronald Bonica >>>> Sent: Friday, December 23, 2011 3:40 AM >>>> To: Thomas Narten; So, Ning >>>> Cc: dc@ietf.org >>>> Subject: [dc] Elevator Pitch (was: Scoping the Interim meeting) >>>> >>>> Folks, >>>> >>>> Amplifying what Thomas said: >>>> >>>> At this point, the most helpful thing that anyone can do is to summari= ze >>>> the problem(s) that we are trying to solve in a relatively terse email= . >>>> Once we come to consensus on that brief summary, we can flesh it out >>>> into very short Internet Draft. >>>> >>>> I look forward to hearing your elevator pitches. >>>> >>>> Happy >>>> Holidays, >>>> Ron >>>> >>>> >>>>> -----Original Message----- >>>>> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of >>>>> Thomas Narten >>>>> Sent: Wednesday, December 21, 2011 1:31 PM >>>>> To: So, Ning >>>>> Cc: Ronald Bonica; dc@ietf.org >>>>> Subject: Re: [dc] Scoping the Interim meeting >>>>> >>>>> We sure have a lot of volunteers wanting to help. That is fine at one >>>>> level, but misses the bigger point. >>>>> >>>>> The best way to help is to articulate a specific problem or area. >>>>> >>>>> Do so on this list in a single message. We don't need yet more >>>>> documents (at least not yet). >>>>> >>>>> 2-4 paragraphs (no more). Think "elevator pitch" >>>>> (http://en.wikipedia.org/wiki/Elevator_pitch). >>>>> >>>>> You only get a couple of minutes to make your case, and if you can't >>>>> do so, either you don't understand the problem yourself well enough, >>>>> or the value-proposition just isn't compelling. >>>>> >>>>> So far, I haven't seen discussions of specific problems (or problem >>>>> areas). What I'm seeing is pointers to lots of drafts, many of which >>>>> (for those that I've looked at) don't crisply get at a real, tangible >>>>> problem that I understand and think the IETF can/should work on. Bonu= s >>>>> points for showing: >>>>> >>>>> 1) an operator (or some other clear customer/consumer technology) tha= t >>>>> says "yes, that is what I need, and if it was available today, I'd >>>>> use it" >>>>> >>>>> 2) a vendor saying "here is what my customers are telling me will >>>>> solve a problem of theirs", and we think an IETF standard is >>>>> needed. >>>>> >>>>> 3) demonstration of a clear technical/protocol gap between what is >>>>> available today, and what is needed to address the problem. >>>>> >>>>> Thomas >>>>> >>>>> _______________________________________________ >>>>> dc mailing list >>>>> dc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dc >>>> _______________________________________________ >>>> dc mailing list >>>> dc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dc >>>> _______________________________________________ >>>> dc mailing list >>>> dc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dc >>> _______________________________________________ >>> dc mailing list >>> dc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dc >> >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > From vumip1@gmail.com Sat Dec 24 10:28:29 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9D621F8500 for ; Sat, 24 Dec 2011 10:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufd7VH3Q8aY1 for ; Sat, 24 Dec 2011 10:28:28 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C97D121F84F5 for ; Sat, 24 Dec 2011 10:28:28 -0800 (PST) Received: by iaen33 with SMTP id n33so9379441iae.31 for ; Sat, 24 Dec 2011 10:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hZFcCcnbLMy1QhB3ymikN6G0wmii269Mc4+E7pf+hPg=; b=NafrSrbcuHVnlqI0O5q2bIX+4Oy1xsPyZ1h3lWKOsuq0v4KCr/diCjs12BhZtENTcC NMWkytaaUT8KAsWm3r6tuyWWqSdPXZjLwAgZU9BTNeL9CJhPG4+K/d2HUFYAyjt194EE 2iTFoLizVCETrYPYODB4WzHpM6RTUF18ba3JA= MIME-Version: 1.0 Received: by 10.50.183.166 with SMTP id en6mr19146169igc.7.1324751305546; Sat, 24 Dec 2011 10:28:25 -0800 (PST) Received: by 10.50.77.197 with HTTP; Sat, 24 Dec 2011 10:28:25 -0800 (PST) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> Date: Sat, 24 Dec 2011 13:28:25 -0500 Message-ID: From: Bhumip Khasnabish To: Ronald Bonica Content-Type: multipart/alternative; boundary=14dae9340fe9fb99cc04b4dab255 Cc: Thomas Narten , "So, Ning" , "dc@ietf.org" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 18:28:29 -0000 --14dae9340fe9fb99cc04b4dab255 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =B7 Support of on-demand provisioning and management (availability) of distributed virtualized computing, communications, and storage resources =B7 Offering of seamless mobility of virtual machine (VM), virtualized interface (VI), virtualized network elements (VNE) and virtualized storage (VS) from one domain to another for load balancing and service continuity management =B7 Management of security, privacy, data integrity, and log of Dat= a center services for audit and verification =B7 Support of Distributed scaling and multi-tenancy support withou= t excessive complexity and resource consumption =B7 Support of Naming and addressing of virtualized entities for simplified mobility and service continuity management =B7 Support of Realistic Service level agreement parameters for Dat= a center resources and services * Support of Visualization of resources utilization and automation of provisioning Thanks for you kind attention. Happy Holidays and all the best for 2012. Bhumip On Thu, Dec 22, 2011 at 5:10 PM, Ronald Bonica wrote: > Folks, > > Amplifying what Thomas said: > > At this point, the most helpful thing that anyone can do is to summarize > the problem(s) that we are trying to solve in a relatively terse email. > Once we come to consensus on that brief summary, we can flesh it out into > very short Internet Draft. > > I look forward to hearing your elevator pitches. > > Happy Holidays, > Ron > > > > -----Original Message----- > > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > > Thomas Narten > > Sent: Wednesday, December 21, 2011 1:31 PM > > To: So, Ning > > Cc: Ronald Bonica; dc@ietf.org > > Subject: Re: [dc] Scoping the Interim meeting > > > > We sure have a lot of volunteers wanting to help. That is fine at one > > level, but misses the bigger point. > > > > The best way to help is to articulate a specific problem or area. > > > > Do so on this list in a single message. We don't need yet more > > documents (at least not yet). > > > > 2-4 paragraphs (no more). Think "elevator pitch" > > (http://en.wikipedia.org/wiki/Elevator_pitch). > > > > You only get a couple of minutes to make your case, and if you can't > > do so, either you don't understand the problem yourself well enough, > > or the value-proposition just isn't compelling. > > > > So far, I haven't seen discussions of specific problems (or problem > > areas). What I'm seeing is pointers to lots of drafts, many of which > > (for those that I've looked at) don't crisply get at a real, tangible > > problem that I understand and think the IETF can/should work on. Bonus > > points for showing: > > > > 1) an operator (or some other clear customer/consumer technology) that > > says "yes, that is what I need, and if it was available today, I'd > > use it" > > > > 2) a vendor saying "here is what my customers are telling me will > > solve a problem of theirs", and we think an IETF standard is > > needed. > > > > 3) demonstration of a clear technical/protocol gap between what is > > available today, and what is needed to address the problem. > > > > Thomas > > > > _______________________________________________ > > dc mailing list > > dc@ietf.org > > https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc > --14dae9340fe9fb99cc04b4dab255 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
=B7=A0=A0=A0=A0=A0= =A0=A0=A0 Support of on-demand provisioning and management= (availability) of distributed virtualized computing, communications, and s= torage resources=A0

= =A0<= /font>

= =B7=A0=A0=A0=A0=A0= =A0=A0=A0 Offering of seamless mobility of virtual machine= (VM), virtualized interface (VI), virtualized network elements (VNE) and v= irtualized storage (VS) from =A0one domain to another fo= r load balancing and service continuity management

= =A0<= /font>

= =B7=A0=A0=A0=A0=A0= =A0=A0=A0 Management of security, privacy, data integrity,= and log of Data center services for audit and verification <= /p>

= =A0<= /font>

= =B7=A0=A0=A0=A0=A0= =A0=A0=A0 Support of Distributed scaling and mul= ti-tenancy support without excessive complexity and resource consumption

= =A0<= /font>

= =B7=A0=A0=A0=A0=A0= =A0=A0=A0 Support of Naming and addressing of vi= rtualized entities for simplified mobility and service continuity managemen= t

= =A0<= /font>

=B7=A0=A0=A0=A0=A0= =A0=A0=A0 Support of Realistic Service level agr= eement parameters for Data center resources and services
=A0
* = Supp= ort of Visualization of= resources utilization and automation of provisioning
=A0
=A0
Thanks for you kind attention.
=A0
Happy Holidays and all the best for 2012.
=A0
Bhumip
=A0
=A0
On Thu, Dec 22, 2011 at 5:10 PM, Ronald Bonica <= span dir=3D"ltr"><rbonica@juniper= .net> wrote:
Folks,

Amplifying what Thomas = said:

At this point, the most helpful thing that anyone can do is to= summarize the problem(s) that we are trying to solve in a relatively terse= email. Once we come to consensus on that brief summary, we can flesh it ou= t into very short Internet Draft.

I look forward to hearing your elevator pitches.

=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Happy Holidays,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ron<= br>

> -----Original Message-----
> From: dc-bounces@ietf.org [= mailto:dc-bounces@ietf.org] On B= ehalf Of
> Thomas Narten
> Sent: Wednesday, December 21, 2011 1= :31 PM
> To: So, Ning
> Cc: Ronald Bonica; dc@ietf.org
> Subject: Re: [dc] Scoping the Interim meeting
&= gt;
> We sure have a lot of volunteers wanting to help. That is fine = at one
> level, but misses the bigger point.
>
> The best way to he= lp is to articulate a specific problem or area.
>
> Do so on th= is list in a single message. We don't need yet more
> documents (= at least not yet).
>
> 2-4 paragraphs (no more). =A0Think "elevator pitch"<= br>> (http://en.wikipedia.org/wiki/Elevator_pitch).
>
> Y= ou only get a couple of minutes to make your case, and if you can't
> do so, either you don't understand the problem yourself well enoug= h,
> or the value-proposition just isn't compelling.
>
&= gt; So far, I haven't seen discussions of specific problems (or problem=
> areas). What I'm seeing is pointers to lots of drafts, many of whi= ch
> (for those that I've looked at) don't crisply get at a r= eal, tangible
> problem that I understand and think the IETF can/shou= ld work on. Bonus
> points for showing:
>
> 1) an operator (or some other clea= r customer/consumer technology) that
> =A0 =A0says "yes, that is= what I need, and if it was available today, I'd
> =A0 =A0use it&= quot;
>
> 2) a vendor saying "here is what my customers are telling= me will
> =A0 =A0solve a problem of theirs", and we think an IE= TF standard is
> =A0 =A0needed.
>
> 3) demonstration of a= clear technical/protocol gap between what is
> =A0 =A0available today, and what is needed to address the problem.
= >
> Thomas
>
> _______________________________________= ________
> dc mailing list
> dc@= ietf.org
> https://www.ietf.org/mailman/listinfo/dc
__________________________= _____________________
dc mailing list
= dc@ietf.org
http= s://www.ietf.org/mailman/listinfo/dc


=A0 --14dae9340fe9fb99cc04b4dab255-- From russw@riw.us Sun Dec 25 15:22:58 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DF221F84A0 for ; Sun, 25 Dec 2011 15:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paoQEQD7locz for ; Sun, 25 Dec 2011 15:22:58 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id DAF3521F849C for ; Sun, 25 Dec 2011 15:22:57 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:59198 helo=[192.168.100.61]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RexP3-0001W1-Oi for dc@ietf.org; Sun, 25 Dec 2011 18:22:53 -0500 Message-ID: <4EF7B019.3030202@riw.us> Date: Sun, 25 Dec 2011 18:22:01 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dc@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 23:22:58 -0000 > First, native L2 or L3 forwarding technologies do not work. L2 networks > can't be large due to high number of broadcasts. L3 networks can't be > used because of VM mobility, since routing uses subnets and the IP > cannot be moved out of that subnet. Moving IP in a natively L3 network > requires installing a host route, which is an approach that can't be > scaled. Hence, a new approach is required. Two question... 1. How many host routes do we reach before we say it "won't scale?" If you're talking about leaf nodes in a routing protocol, 100k isn't really that big of a deal. Where you do run into problems is between the routing and forwarding tables --but that's an area for thought. 2. Why does this mobility need to be at layer 2 specifically? Are we assuming DDNS and other sorts of solutions in this space will simply never be fast enough/scale far enough/etc? > Network convergence on mobility and failure will require control plane > signaling and forwarding plane churn. This churn needs to be minimized > in order to keep the network stable. Convergence speed and stability are generally opposed to one another, but there are techniques that allow reasonable convergence speed for a confined set of network topology changes while providing stability on the back end by slowing down for subsequent changes. > Sixth, large cloud datacenters depend on economies of scale, and need to > reduce equipment cost and energy. This is possible only when the > technology scales easily both at a hardware and software level, keeping > the cost and energy consumed low. As an example, technologies that do > map-encap require per flow hardware entries, and per flow setup > signaling, which is very expensive at scale. I think the major challenge here is going to be forwarding table size --but we have to balance against going the "traditional" path of caching, or making the forwarding path dependent on the data being forwarded. Anything where you're waiting on data to flow in order to build a control plane entry is going to be very difficult to reconcile with fast convergence and mobility --we faced this problem with reactive protocols in the MANET space, and never really found a solid way to overcome them (at least that I know of). :-) Russ From xuxiaohu@huawei.com Sun Dec 25 17:44:09 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D34021F851F for ; Sun, 25 Dec 2011 17:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv8U8kU2JOVY for ; Sun, 25 Dec 2011 17:44:09 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7F44221F851A for ; Sun, 25 Dec 2011 17:44:08 -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 <0LWS00B7TFH9B1@szxga03-in.huawei.com> for dc@ietf.org; Mon, 26 Dec 2011 09:43:57 +0800 (CST) Received: from szxrg01-dlp.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 <0LWS006NFFH9C7@szxga03-in.huawei.com> for dc@ietf.org; Mon, 26 Dec 2011 09:43:57 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGA06911; Mon, 26 Dec 2011 09:43:56 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Dec 2011 09:43:55 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Mon, 26 Dec 2011 09:43:51 +0800 Date: Mon, 26 Dec 2011 01:43:49 +0000 From: Xuxiaohu In-reply-to: <4EF7B019.3030202@riw.us> X-Originating-IP: [10.108.4.80] To: Russ White , "dc@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE76318D@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dc] Elevator Pitch Thread-index: AQHMw1wuBgE5G7BjGEyEvGVWBnVRbZXtV9dg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 01:44:09 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGRjLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpkYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJ1c3MgV2hpdGUNCj4gt6LLzcqxvOQ6IDIw MTHE6jEy1MIyNsjVIDc6MjINCj4gytW8/sjLOiBkY0BpZXRmLm9yZw0KPiDW98ziOiBSZTogW2Rj XSBFbGV2YXRvciBQaXRjaA0KPiANCj4gDQo+ID4gRmlyc3QsIG5hdGl2ZSBMMiBvciBMMyBmb3J3 YXJkaW5nIHRlY2hub2xvZ2llcyBkbyBub3Qgd29yay4gTDIgbmV0d29ya3MNCj4gPiBjYW4ndCBi ZSBsYXJnZSBkdWUgdG8gaGlnaCBudW1iZXIgb2YgYnJvYWRjYXN0cy4gTDMgbmV0d29ya3MgY2Fu J3QgYmUNCj4gPiB1c2VkIGJlY2F1c2Ugb2YgVk0gbW9iaWxpdHksIHNpbmNlIHJvdXRpbmcgdXNl cyBzdWJuZXRzIGFuZCB0aGUgSVANCj4gPiBjYW5ub3QgYmUgbW92ZWQgb3V0IG9mIHRoYXQgc3Vi bmV0LiBNb3ZpbmcgSVAgaW4gYSBuYXRpdmVseSBMMyBuZXR3b3JrDQo+ID4gcmVxdWlyZXMgaW5z dGFsbGluZyBhIGhvc3Qgcm91dGUsIHdoaWNoIGlzIGFuIGFwcHJvYWNoIHRoYXQgY2FuJ3QgYmUN Cj4gPiBzY2FsZWQuIEhlbmNlLCBhIG5ldyBhcHByb2FjaCBpcyByZXF1aXJlZC4NCj4gDQo+IFR3 byBxdWVzdGlvbi4uLg0KPiANCj4gMS4gSG93IG1hbnkgaG9zdCByb3V0ZXMgZG8gd2UgcmVhY2gg YmVmb3JlIHdlIHNheSBpdCAid29uJ3Qgc2NhbGU/IiBJZg0KPiB5b3UncmUgdGFsa2luZyBhYm91 dCBsZWFmIG5vZGVzIGluIGEgcm91dGluZyBwcm90b2NvbCwgMTAwayBpc24ndCByZWFsbHkNCj4g dGhhdCBiaWcgb2YgYSBkZWFsLiBXaGVyZSB5b3UgZG8gcnVuIGludG8gcHJvYmxlbXMgaXMgYmV0 d2VlbiB0aGUNCj4gcm91dGluZyBhbmQgZm9yd2FyZGluZyB0YWJsZXMgLS1idXQgdGhhdCdzIGFu IGFyZWEgZm9yIHRob3VnaHQuDQoNCkZ1bGx5IGFncmVlLg0KDQo+IDIuIFdoeSBkb2VzIHRoaXMg bW9iaWxpdHkgbmVlZCB0byBiZSBhdCBsYXllciAyIHNwZWNpZmljYWxseT8gQXJlIHdlDQo+IGFz c3VtaW5nIERETlMgYW5kIG90aGVyIHNvcnRzIG9mIHNvbHV0aW9ucyBpbiB0aGlzIHNwYWNlIHdp bGwgc2ltcGx5DQo+IG5ldmVyIGJlIGZhc3QgZW5vdWdoL3NjYWxlIGZhciBlbm91Z2gvZXRjPw0K DQpHb29kIHF1ZXN0aW9uLg0KDQo+ID4gTmV0d29yayBjb252ZXJnZW5jZSBvbiBtb2JpbGl0eSBh bmQgZmFpbHVyZSB3aWxsIHJlcXVpcmUgY29udHJvbCBwbGFuZQ0KPiA+IHNpZ25hbGluZyBhbmQg Zm9yd2FyZGluZyBwbGFuZSBjaHVybi4gVGhpcyBjaHVybiBuZWVkcyB0byBiZSBtaW5pbWl6ZWQN Cj4gPiBpbiBvcmRlciB0byBrZWVwIHRoZSBuZXR3b3JrIHN0YWJsZS4NCj4gDQo+IENvbnZlcmdl bmNlIHNwZWVkIGFuZCBzdGFiaWxpdHkgYXJlIGdlbmVyYWxseSBvcHBvc2VkIHRvIG9uZSBhbm90 aGVyLA0KPiBidXQgdGhlcmUgYXJlIHRlY2huaXF1ZXMgdGhhdCBhbGxvdyByZWFzb25hYmxlIGNv bnZlcmdlbmNlIHNwZWVkIGZvciBhDQo+IGNvbmZpbmVkIHNldCBvZiBuZXR3b3JrIHRvcG9sb2d5 IGNoYW5nZXMgd2hpbGUgcHJvdmlkaW5nIHN0YWJpbGl0eSBvbg0KPiB0aGUgYmFjayBlbmQgYnkg c2xvd2luZyBkb3duIGZvciBzdWJzZXF1ZW50IGNoYW5nZXMuDQo+IA0KPiA+IFNpeHRoLCBsYXJn ZSBjbG91ZCBkYXRhY2VudGVycyBkZXBlbmQgb24gZWNvbm9taWVzIG9mIHNjYWxlLCBhbmQgbmVl ZCB0bw0KPiA+IHJlZHVjZSBlcXVpcG1lbnQgY29zdCBhbmQgZW5lcmd5LiBUaGlzIGlzIHBvc3Np YmxlIG9ubHkgd2hlbiB0aGUNCj4gPiB0ZWNobm9sb2d5IHNjYWxlcyBlYXNpbHkgYm90aCBhdCBh IGhhcmR3YXJlIGFuZCBzb2Z0d2FyZSBsZXZlbCwga2VlcGluZw0KPiA+IHRoZSBjb3N0IGFuZCBl bmVyZ3kgY29uc3VtZWQgbG93LiBBcyBhbiBleGFtcGxlLCB0ZWNobm9sb2dpZXMgdGhhdCBkbw0K PiA+IG1hcC1lbmNhcCByZXF1aXJlIHBlciBmbG93IGhhcmR3YXJlIGVudHJpZXMsIGFuZCBwZXIg ZmxvdyBzZXR1cA0KPiA+IHNpZ25hbGluZywgd2hpY2ggaXMgdmVyeSBleHBlbnNpdmUgYXQgc2Nh bGUuDQo+IA0KPiBJIHRoaW5rIHRoZSBtYWpvciBjaGFsbGVuZ2UgaGVyZSBpcyBnb2luZyB0byBi ZSBmb3J3YXJkaW5nIHRhYmxlIHNpemUNCj4gLS1idXQgd2UgaGF2ZSB0byBiYWxhbmNlIGFnYWlu c3QgZ29pbmcgdGhlICJ0cmFkaXRpb25hbCIgcGF0aCBvZg0KPiBjYWNoaW5nLCBvciBtYWtpbmcg dGhlIGZvcndhcmRpbmcgcGF0aCBkZXBlbmRlbnQgb24gdGhlIGRhdGEgYmVpbmcNCj4gZm9yd2Fy ZGVkLiBBbnl0aGluZyB3aGVyZSB5b3UncmUgd2FpdGluZyBvbiBkYXRhIHRvIGZsb3cgaW4gb3Jk ZXIgdG8NCj4gYnVpbGQgYSBjb250cm9sIHBsYW5lIGVudHJ5IGlzIGdvaW5nIHRvIGJlIHZlcnkg ZGlmZmljdWx0IHRvIHJlY29uY2lsZQ0KPiB3aXRoIGZhc3QgY29udmVyZ2VuY2UgYW5kIG1vYmls aXR5IC0td2UgZmFjZWQgdGhpcyBwcm9ibGVtIHdpdGggcmVhY3RpdmUNCj4gcHJvdG9jb2xzIGlu IHRoZSBNQU5FVCBzcGFjZSwgYW5kIG5ldmVyIHJlYWxseSBmb3VuZCBhIHNvbGlkIHdheSB0bw0K PiBvdmVyY29tZSB0aGVtIChhdCBsZWFzdCB0aGF0IEkga25vdyBvZikuDQoNCkZ1bGx5IGFncmVl LiBUaGUgYXBwcm9hY2ggb2YgbWFraW5nIHRoZSBmb3J3YXJkaW5nIHBhdGggZGVwZW5kZW50IG9u IHRoZSBkYXRhIGJlaW5nDQpmb3J3YXJkZWQgd2lsbCBwcm9iYWJseSBvcGVuIGEgY2FuIG9mIHdv cm1zLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiA6LSkNCj4gDQo+IFJ1c3MNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGMgbWFpbGlu ZyBsaXN0DQo+IGRjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGMNCg== From adalela@cisco.com Sun Dec 25 20:38:40 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3037B21F854D for ; Sun, 25 Dec 2011 20:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OevyKs+2Mpm0 for ; Sun, 25 Dec 2011 20:38:39 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 98C0121F851A for ; Sun, 25 Dec 2011 20:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=3535; q=dns/txt; s=iport; t=1324874318; x=1326083918; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tZDG0gcD64WkF+xeAeNtxBBbeDQ8dzsAhz9YYIzYFec=; b=lBL6qJDkBdJz8+bypSKX5UevLFfvW9awLUSckxOrrv0QSNP6XHZOOkYp hbGPIhcooY3hxHgtbJ0i7ud8obEBuejtyzjxpr123sELyDbfW7gYC2XN3 Na4IhoI2j698w1c0KZcWBEPi1uxCisLWoulu8+WKN8b7wWcMB6jefTKfl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYAAAf6905Io8UY/2dsb2JhbABEm16NPoQngXIBAQEDAQEBAQsEAR0KKwkQBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAEKCAgTB4dYCJgRAZ1DBIssYwSINZ8J X-IronPort-AV: E=Sophos;i="4.71,410,1320624000"; d="scan'208";a="2327814" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 26 Dec 2011 04:38:35 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBQ4cZwM032073; Mon, 26 Dec 2011 04:38:35 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Dec 2011 10:08:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Dec 2011 10:08:30 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102A489FF@XMB-BGL-416.cisco.com> In-Reply-To: <4EF7B019.3030202@riw.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Elevator Pitch Thread-Index: AczDXCkcbBWZ4ZlHRFC0l1OptLQR1QAF6DuQ References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com><13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net><618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> From: "Ashish Dalela (adalela)" To: "Russ White" , X-OriginalArrivalTime: 26 Dec 2011 04:38:35.0853 (UTC) FILETIME=[3AEDBFD0:01CCC388] Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 04:38:40 -0000 Russ, 1. The scaling numbers for a single DC are expected to be 1-100 million. It will reach the higher limits with 10G to the server. The numbers for DC connectivity are not well-known. The typical access switch numbers are much lower than 100K. E.g. if you are running OSPF with static L3/VLAN configuration how much do you really need? A drastic increase in table sizes at access is cost prohibitive. 2. I did not assume that mobility has to be L2, just that today's L2 will give mobility without any change. Today's L3 will not give that. So, I'm trying to state a problem that this group needs to work upon. Whether DDNS is a right approach, or other approaches, we can discuss once we can agree that we have a problem to be solved and the problem is clearly defined. Your point about challenges with reactive protocols are spot-on I think. Thanks, Ashish -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Russ White Sent: Monday, December 26, 2011 4:52 AM To: dc@ietf.org Subject: Re: [dc] Elevator Pitch > First, native L2 or L3 forwarding technologies do not work. L2 networks > can't be large due to high number of broadcasts. L3 networks can't be > used because of VM mobility, since routing uses subnets and the IP > cannot be moved out of that subnet. Moving IP in a natively L3 network > requires installing a host route, which is an approach that can't be > scaled. Hence, a new approach is required. Two question... 1. How many host routes do we reach before we say it "won't scale?" If you're talking about leaf nodes in a routing protocol, 100k isn't really that big of a deal. Where you do run into problems is between the routing and forwarding tables --but that's an area for thought. 2. Why does this mobility need to be at layer 2 specifically? Are we assuming DDNS and other sorts of solutions in this space will simply never be fast enough/scale far enough/etc? > Network convergence on mobility and failure will require control plane > signaling and forwarding plane churn. This churn needs to be minimized > in order to keep the network stable.=20 Convergence speed and stability are generally opposed to one another, but there are techniques that allow reasonable convergence speed for a confined set of network topology changes while providing stability on the back end by slowing down for subsequent changes. > Sixth, large cloud datacenters depend on economies of scale, and need to > reduce equipment cost and energy. This is possible only when the > technology scales easily both at a hardware and software level, keeping > the cost and energy consumed low. As an example, technologies that do > map-encap require per flow hardware entries, and per flow setup > signaling, which is very expensive at scale. I think the major challenge here is going to be forwarding table size --but we have to balance against going the "traditional" path of caching, or making the forwarding path dependent on the data being forwarded. Anything where you're waiting on data to flow in order to build a control plane entry is going to be very difficult to reconcile with fast convergence and mobility --we faced this problem with reactive protocols in the MANET space, and never really found a solid way to overcome them (at least that I know of). :-) Russ _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From aldrin.isaac@gmail.com Sun Dec 25 20:45:14 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C0F21F8505 for ; Sun, 25 Dec 2011 20:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=1.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK34aYOVKgu3 for ; Sun, 25 Dec 2011 20:45:14 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0103121F8490 for ; Sun, 25 Dec 2011 20:45:13 -0800 (PST) Received: by qcsf15 with SMTP id f15so7839189qcs.31 for ; Sun, 25 Dec 2011 20:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=ujbxK51uQmIkp1yZVoDU2Hp5nrafwtfc6YzBbPE1FD8=; b=PHbs4pPi/ryB8kHfq0UxlMQq5R7v32MO4qPNWquIyshk0JZWQDpL6dkDNLrGY4rxfs r6FcrhfNe0cC3rhtZLexqtVSi8UTywY1ONS6swAtZXlZGi+ct2tdyE4MLiAn1mUlATm+ Rhkrk7OrxcR9vY7fAU0fBxOqfRfawa0ta+9SA= Received: by 10.229.76.132 with SMTP id c4mr8357978qck.56.1324874713539; Sun, 25 Dec 2011 20:45:13 -0800 (PST) Received: from mymac.home (ool-44c1c730.dyn.optonline.net. [68.193.199.48]) by mx.google.com with ESMTPS id fe5sm16419854qab.5.2011.12.25.20.45.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Dec 2011 20:45:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Aldrin Isaac In-Reply-To: <4EF7B019.3030202@riw.us> Date: Sun, 25 Dec 2011 23:45:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> To: Russ White X-Mailer: Apple Mail (2.1251.1) Cc: dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 04:45:15 -0000 >> Network convergence on mobility and failure will require control = plane >> signaling and forwarding plane churn. This churn needs to be = minimized >> in order to keep the network stable.=20 >=20 > Convergence speed and stability are generally opposed to one another, > but there are techniques that allow reasonable convergence speed for a > confined set of network topology changes while providing stability on > the back end by slowing down for subsequent changes. Hi Russ, The network may have equipment with varying degrees of control-plane = horsepower. What if the "resting" update rate should become greater = than the minimum update processing rate available across the network to = maintain stability? Could you elaborate on what kinds of scaling = tools/techniques you have in mind? Best -- aldrin > :-) >=20 > Russ From diego@tid.es Sun Dec 25 23:59:31 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6857F21F8AB8 for ; Sun, 25 Dec 2011 23:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=1.843, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATLssM6YVByh for ; Sun, 25 Dec 2011 23:59:30 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE1721F8ABB for ; Sun, 25 Dec 2011 23:59:29 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWS00H05WV3KM@tid.hi.inet> for dc@ietf.org; Mon, 26 Dec 2011 08:59:27 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 9F.A9.02643.F5928FE4; Mon, 26 Dec 2011 08:59:27 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LWS00H01WV2KM@tid.hi.inet> for dc@ietf.org; Mon, 26 Dec 2011 08:59:26 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 26 Dec 2011 08:59:26 +0100 Date: Mon, 26 Dec 2011 08:59:26 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: "dc@ietf.org" Message-id: <17CB1CAF-EB48-451D-A532-C4DD88E4B828@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [dc] Elevator Pitch (was: Scoping the Interim meeting) Thread-index: AczDpEnlNeoallERRO2DDxji3crauQ== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-b3-4ef8295f29c6 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42Lhivcz1I3X/OFncPUmh0XL+busDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuPTpLWPBZsGKR7tXszQw9vN1MXJySAiYSDRsuMMGYYtJXLi3 Hsjm4hAS2MYo0dF7EMr5yiix5fRJdginkVHi+YtTjCAtLAKqEq0NT8BsNgF1iZaj31hAbGEB Z4k/d/6ygticAlYSjW9esYPYIgLyEk+37AKr4RWwlDhy+BUrhC0o8WPyPbA4s4CexMc/txkh bHGJ5tabUHFtiSfvLoDVMwKd+v3UGiaImS4SE1e8ZoOw9SRu72xkgqgRlbjTvp4R4jUBiSV7 zjND2KISLx//A5sjBHTD6g9TmSYwis1CcsYsJGfMQnLGLCRnLGBkWcUoVpxUlJmeUZKbmJmT bmCkl5Gpl5mXWrKJERIxmTsYl+9UOcQowMGoxMO7YP13PyHWxLLiytxDjJIcTEqivC6KP/yE +JLyUyozEosz4otKc1KLDzFKcDArifB2/QQq501JrKxKLcqHSclwcChJ8PZqALUJFqWmp1ak ZeYA0wJMmomDE6SdB6j9O0gNb3FBYm5xZjpE/hSjpJQ47ySQhABIIqM0D673FaM40JHCvMdB sjzABAbX9QpoIBPQwDhlsIEliQgpqQbGyZULuNXfdGQfKrIonGWz493bl3XHZJkc+hOrYr6n uy1tjvzV9fbDff0VxSWM5aERTi3Lnp5qnH9/s3Yb79GvCzdnPVim+1omp4tf18RBcnfzSl7l vQfkNLwehZevsntivSnn6AT7/WwX3lhVrtnTVL/6fOm3qvmyj/xlP3/2cLWYY37GelK7Ektx RqKhFnNRcSIA3xvbKh0DAAA= References: Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 07:59:31 -0000 Hi, On 23 Dec 2011, at 13:59 , Mcdysan, David E wrote: > Support an infrastructure for multiple tenants, each with computing > applications and associated resources ranging from a single VM to a very > large tenant with a complex, multi-site computing application. An > important case is supporting a very large single tenant computing > application. > > Ensure that each tenant is securely separated from others and that only > tenants who mutually agree to communicate and/or share resources can do s= o. > > Orchestrate all of the virtual and real appliances (e.g., firewalls. load > balancers, security, etc.) needed for a complex computing application > distributed across multiple sites. > > Provide methods to optimize the placement and interconnection of > computing, storage, appliance and networking resources. > > Work across a diverse set of networking technologies and architectures, > ranging from dedicated special-purpose networks (e.g., Ethernet/PBB L2/L3 > VPNs) to access over the Inernet. > > Be scalable on the high end to support hundreds of millions of Virtual > Machines -- think one VM pre wireless subscriber. > > Be capable of meeting the quality objectives across a range of performanc= e > profiles corresponding to classes of tenants. I'd add a couple of mentions: 1) To align these solutions with the interfaces in use and/or development b= y cloud providers and the user community (DMTF, OCCI/OGF, SCIM=85) 2) To IPv6 technologies as a possible source of solutions for some of the c= urrent problems, and certainly as part of the networking scenario to be add= ressed. All the best, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From Tina.Tsou.Zouting@huawei.com Mon Dec 26 00:12:35 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD35E21F86B3 for ; Mon, 26 Dec 2011 00:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.628 X-Spam-Level: X-Spam-Status: No, score=-6.628 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYUoWleGB9BQ for ; Mon, 26 Dec 2011 00:12:34 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 817C721F86A5 for ; Mon, 26 Dec 2011 00:12:34 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWS007QSXGXXK@szxga05-in.huawei.com> for dc@ietf.org; Mon, 26 Dec 2011 16:12:33 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWS004XVXGX56@szxga05-in.huawei.com> for dc@ietf.org; Mon, 26 Dec 2011 16:12:33 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGA33000; Mon, 26 Dec 2011 16:12:23 +0800 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Dec 2011 16:12:22 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Mon, 26 Dec 2011 16:12:15 +0800 Date: Mon, 26 Dec 2011 08:12:14 +0000 From: Tina TSOU In-reply-to: <17CB1CAF-EB48-451D-A532-C4DD88E4B828@tid.es> X-Originating-IP: [10.212.246.37] To: DIEGO LOPEZ GARCIA , "dc@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [dc] Elevator Pitch (was: Scoping the Interim meeting) Thread-index: AQHMwPcDmu25TxjmcESCKqVsBX3WfJXo3V4AgARjKgCAAIhM0A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <17CB1CAF-EB48-451D-A532-C4DD88E4B828@tid.es> Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 08:12:35 -0000 Tina -----Original Message----- From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of DIEGO L= OPEZ GARCIA Sent: Sunday, December 25, 2011 11:59 PM To: dc@ietf.org Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) Hi, On 23 Dec 2011, at 13:59 , Mcdysan, David E wrote: > Support an infrastructure for multiple tenants, each with computing > applications and associated resources ranging from a single VM to a very > large tenant with a complex, multi-site computing application. An > important case is supporting a very large single tenant computing > application. > > Ensure that each tenant is securely separated from others and that only > tenants who mutually agree to communicate and/or share resources can do s= o. > > Orchestrate all of the virtual and real appliances (e.g., firewalls. load > balancers, security, etc.) needed for a complex computing application > distributed across multiple sites. > > Provide methods to optimize the placement and interconnection of > computing, storage, appliance and networking resources. > > Work across a diverse set of networking technologies and architectures, > ranging from dedicated special-purpose networks (e.g., Ethernet/PBB L2/L3 > VPNs) to access over the Inernet. > > Be scalable on the high end to support hundreds of millions of Virtual > Machines -- think one VM pre wireless subscriber. > > Be capable of meeting the quality objectives across a range of performanc= e > profiles corresponding to classes of tenants. I'd add a couple of mentions: 1) To align these solutions with the interfaces in use and/or development b= y cloud providers and the user community (DMTF, OCCI/OGF, SCIM.) 2) To IPv6 technologies as a possible source of solutions for some of the c= urrent problems, and certainly as part of the networking scenario to be add= ressed. [Tina: IPv6 is easily added through a managed NAT service, no need for complicated= Cloud networking, no need for tunnels. IPv6 will be available for Cloud users...and Cloud Operators. ] All the best, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From adalela@cisco.com Mon Dec 26 22:13:51 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE8121F8551; Mon, 26 Dec 2011 22:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3hVyw5O4YSN; Mon, 26 Dec 2011 22:13:51 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id C659021F8557; Mon, 26 Dec 2011 22:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=8875; q=dns/txt; s=iport; t=1324966430; x=1326176030; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=pdZnmblKKp1YQsgdHjh3e3LsWjBGI4Fip2e02XAN30U=; b=AryXc0TC2HWsB1F1Cp1gRQPNVCv0HwA/10IZbGK86FAJGVyjghWh6ep6 4kkmHCD1x43cBzatllXfGjwxqlj+dmtj3SGTBVBW2t+56UUxGBpmoyFY2 wd+WjE0y+rBZssHQTBJNv3+8P19KvF6Tx2x+q/tbr4P1/FAW+tqFDqto0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMAAKpg+U5Io8UY/2dsb2JhbABChQ+WWpFkgXIBAQEDAQEBAQ8BHTUDAwMLDAQCAQYCEQQBAQUGBhcBBAIBJh8JCAIEAQoICBMHh1gIlxwBjFUIkROBK4lKN2MEiDWfCQ X-IronPort-AV: E=Sophos;i="4.71,414,1320624000"; d="scan'208";a="2369141" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 27 Dec 2011 06:13:47 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pBR6DDEB012522; Tue, 27 Dec 2011 06:13:47 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Dec 2011 11:43:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Dec 2011 11:43:15 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [armd] IP over IP solution for data center interconnect Thread-Index: AQHMwT2CzwDYBIw29UGeVkQ77HSrWZXvI1zQ References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com> From: "Ashish Dalela (adalela)" To: "Xuxiaohu" , "Eggert, Lars" , , X-OriginalArrivalTime: 27 Dec 2011 06:13:15.0888 (UTC) FILETIME=[9EE80F00:01CCC45E] Cc: armd@ietf.org Subject: Re: [dc] [armd] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 06:13:52 -0000 For all the proponents of L3, here is a thought. The biggest concern in cloud is data protection. That is just make or = break. Data can't move when the VM moves. It's just too expensive and = time consuming. Further, to reduce disk wastage you have to put data on = network storage. That's just easy for data backup, and cheap in terms of = total disk space you need. There is a lot going on here in terms of data = de-duplication. Now given network storage, you have two options - NAS and SAN. On the cloud each VM administrator has root privileges. And IP and MAC = addresses can be duplicated (if you are root just configure any IP and = MAC on a virtual interface of choice). So, you have to protect the = network storage from multiple tenants who can have the same IP address = and MAC address. NAS assumes your id on the UNIX is globally unique and = your permissions are unique - not true anymore. So, you have IP, MAC and = ID duplication. That means that if you have to protect data, you have to know somehow = which host is allowed to see which disks. Doing this end-to-end using = TCP/IP is problematic because the NAS controller doesn't know about = tenant id, and whether the MAC and IP are being duplicated across = customers. To make the storage aware of segmentation, you have to carry = some segment (GRE, MPLS, VLAN, etc.) into the storage box. That's not = true today. Network level isolation happens in SAN, but not in NAS. NAS just runs = end-to-end over TCP. In SAN you can say which host will see which disk. = The FC security is high because MAC and FC-ID is assigned by the network = and not in the control of the host. The network knows which port is = which host/MAC. So, if you only know which port is which customer, you = know which MAC can see which disk. Binding a port to a customer is not = hard. But mapping all of that to data security and disk visibility is = not trivial. E.g. you have to do GRE tunnel mapping to a set of disk = permissions. Who needs that? SAN does not use IP. It uses Fiber Channel. With convergence, we are = moving to FC over Ethernet (FCoE). FCIP and iSCSI have not worked very = well. Security for data comes from FC and lowering of cost comes from = use of FCoE. That needs native Ethernet (no IP).=20 When you have site-to-site VM mobility, data is not moving across sites. = E.g. an application server will connect to a set of load-balanced set of = database servers within a VLAN. The application and database servers can = be different sites, and they connect over a VLAN. Alternately, the = application and database servers can be in the same location and the DB = server accesses the SAN over the Internet. Even if data is replicated = across many sites, load-balancing across application or db servers uses = VLANs. In HPC as well, there is a lot of broadcast and discovery, and = this may use IP or not, the fact is that it depends on broadcast. The = HPC case externalizes the memory on a host to other hosts through RDMA. = Everything to do with Big Data will rely on this, and besides disk = externalization we will also see increase in memory externalization. I = just went to a IEEE HPC cloud conference :-) L3 assumes that all data (disk and memory) is inside the host. That = assumption changed a decade ago. Cloud just increases the distribution. = Just as compute is optimized by muxing the VMs on a physical machine, = storage is optimized by consolidating data separately on storage devices = and memory by hosting it in different hosts. Network has to deal with = all types of traffic and security/isolation (imagine someone changing = memory over the network). Storage and memory traffic uses L2. To = discover each other, hosts use L2. These L2 domains need to span across = sites and within the site. This are not corner cases. This is just central to what cloud means in = the long run.=20 Thanks, Ashish -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of = Xuxiaohu Sent: Friday, December 23, 2011 12:09 PM To: Eggert, Lars; dc@ietf.org; dcrg-interest@irtf.org Cc: armd@ietf.org Subject: Re: [armd] IP over IP solution for data center interconnect > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Xuxiaohu > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA12=D4=C222=C8=D5 16:28 > =CA=D5=BC=FE=C8=CB: 'Eggert, Lars'; dc@ietf.org; = 'dcrg-interest@irtf.org.' > =D6=F7=CC=E2: IP over IP solution for data center interconnect >=20 > Hi all, >=20 > There has been a lot of L2 over L3 solutions or proposals for data = center > network and data center interconnect till now. However, it seems = recently > there are increasing interests on L3 over L3 (e.g., IP over IP) = solutions for data > center network and data center interconnect, please see the following = text > quoted from IETF82 L2VPN minutes > ( https://www.ietf.org/proceedings/82/minutes/l2vpn.txt). It's a = general belief > that L3 is more scalable than L2. Especially when considering the data = center > interconnection case, the L3 over L3 solutions can bring DC operators = more > benefits compared to the L2 over L3 solutions, such as path = optimization, > active-active data centers, MAC table reduction on DC switches and = broadcast > flood suppression etc . By the way, the ARP table scaling issue on DC gateways, which is deemed = by the ARMD WG as the only worthy ARP problem in data center networks, = could also be solved with the IP over IP solution. Best regards, Xiaohu =20 >=20 > Although Layer 2 connectivity is still required for some = high-availability clusters > which use non-IP and link-local multicast for communication, more and = more > cluster vendors are either already able to support cluster services at = Layer3 or > will support it in the near future. In addition, the GSLB mechanism = (e.g., DNS > based GSLB) works very well in most cases, is geo-cluster service = still a > common requirement for data center interconnect? If not, could we = spend any > time on exploring the possibility of using L3 over L3 solution for the = most data > center interconnection scenarios where geo-clustering, especially = non-IP based > geo-clustering is not needed? >=20 > Best regards, > Xiaohu >=20 > **************************************************************** > ********************************************************** > Kireeti: I keep seeing ISID, PBB, VLANs. We have to stop conceding to = layer 2 > and start moving to layer 3 (applause) and lots of problems will go = away. >=20 > Florin: We should put VPN on the same page to modify the priorities. = You need > to expand so can look at L3 over L3 as well as L2 over L3. For item = number 2 we > need to look at L3 transport as well as Ethernet and MPLS. And for = number 3 > we need to work on this as there's a lot of expertise in L2, L3 and = other WGs. >=20 >=20 > Marc: The problem statement needs to include more of the L3 issues = around > sending L2 over L3, as the L2 traffic already contains L3. Issue is = just framing. >=20 > Eric Nordmark; "Yes, Yes and Yes". We need to focus from the DC = prospective > and not from the VPN view. don't just think about Ethernet over IP, = but also IP > over IP. Hypervisor may get decoupled over time. > **************************************************************** > ********************************************************** > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] = =B4=FA=B1=ED Eggert, > Lars > > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA12=D4=C216=C8=D5 16:24 > > =CA=D5=BC=FE=C8=CB: dc@ietf.org > > =D6=F7=CC=E2: [dc] IRTF datacenter research group discussion list > > > > Hi, > > > > I wanted to make you all aware of the IRTF's dcrg-interest mailing = list, which > > was set up following a face-to-face meeting at SIGCOMM this year to = discuss > a > > possible IRTF research group on datacenter networking: > > http://irtf.org/mailman/listinfo/dcrg-interest > > > > There has not been much activity towards the formation of an IRTF RG = since > > SIGCOMM, but I am hopeful that the high energy level demonstrated in = the > > various Taipei meetings on the topic will inject some energy here - = several of > > the topics that may be too early for the IETF to standardize around = would fit > an > > IRTF RG very well. I'm certainly supportive of this. > > > > Lars > > IRTF Chair > > > > > > -- > > Mobile number during December: +358 46 5215582 > > Mobile number starting January: +49 151 12055791 _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From pedro.r.marques@gmail.com Mon Dec 26 23:01:49 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A052921F88A0 for ; Mon, 26 Dec 2011 23:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrENEkSD7Krm for ; Mon, 26 Dec 2011 23:01:48 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7796021F867F for ; Mon, 26 Dec 2011 23:01:48 -0800 (PST) Received: by iaen33 with SMTP id n33so12842491iae.31 for ; Mon, 26 Dec 2011 23:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vcSF88wa7QxovV7G27p34SnOv68eVJzEN1GXXby3AWY=; b=ddO/aTtVU0DG4UGzunnIhFHmNWfGKMVWaxhp00yJf+DEv4/SLbHkTc16Tsp3Don6PT V6cFeErOTfr8vGdvAajDRpWX8WdkDQV/cGZ/mjC0wHqZf3kFMpCPtTSfRbDwwLu1eJ+V vXDdG4dP/05pdvrzPghEFknmBEaZaYDMdNJIo= MIME-Version: 1.0 Received: by 10.50.202.105 with SMTP id kh9mr28448992igc.3.1324969308107; Mon, 26 Dec 2011 23:01:48 -0800 (PST) Received: by 10.231.14.2 with HTTP; Mon, 26 Dec 2011 23:01:47 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com> <618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com> Date: Mon, 26 Dec 2011 23:01:48 -0800 Message-ID: From: Pedro Marques To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: dc@ietf.org Subject: Re: [dc] [armd] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 07:01:49 -0000 2011/12/26 Ashish Dalela (adalela) : > For all the proponents of L3, here is a thought. summary of the original email: multi-tenant storage solutions require FiberChannel; an L3 service model doesn't support FiberChannel. There are multiple storage solutions that support multi-tenancy that work on top of IP making the argument moot (1). At large scale running a separate network for data and for storage imposes very significant costs. I'd venture that the proponents of L3 have very little interest in FiberChannel. The same goes for the argument that load-balancing requires L2. There is existence proof of the contrary. There is a wide range of technology choices available in this space. I'm sure there is interest in L2 based solutions but the claim that L3 based solutions are not feasible has already been disproved by deployed solutions. 1 - Example: When a storage solution presents a block device to the VM (e.g. Amazon EBS) it is the host OS/hypervisor that maps the guest OS operations into network operations; doing so in the infrastructure network real rather than in the tenant's network realm. > > The biggest concern in cloud is data protection. That is just make or bre= ak. Data can't move when the VM moves. It's just too expensive and time con= suming. Further, to reduce disk wastage you have to put data on network sto= rage. That's just easy for data backup, and cheap in terms of total disk sp= ace you need. There is a lot going on here in terms of data de-duplication. > > Now given network storage, you have two options - NAS and SAN. > > On the cloud each VM administrator has root privileges. And IP and MAC ad= dresses can be duplicated (if you are root just configure any IP and MAC on= a virtual interface of choice). So, you have to protect the network storag= e from multiple tenants who can have the same IP address and MAC address. N= AS assumes your id on the UNIX is globally unique and your permissions are = unique - not true anymore. So, you have IP, MAC and ID duplication. > > That means that if you have to protect data, you have to know somehow whi= ch host is allowed to see which disks. Doing this end-to-end using TCP/IP i= s problematic because the NAS controller doesn't know about tenant id, and = whether the MAC and IP are being duplicated across customers. To make the s= torage aware of segmentation, you have to carry some segment (GRE, MPLS, VL= AN, etc.) into the storage box. That's not true today. > > Network level isolation happens in SAN, but not in NAS. NAS just runs end= -to-end over TCP. In SAN you can say which host will see which disk. The FC= security is high because MAC and FC-ID is assigned by the network and not = in the control of the host. The network knows which port is which host/MAC.= So, if you only know which port is which customer, you know which MAC can = see which disk. Binding a port to a customer is not hard. But mapping all o= f that to data security and disk visibility is not trivial. E.g. you have t= o do GRE tunnel mapping to a set of disk permissions. Who needs that? > > SAN does not use IP. It uses Fiber Channel. With convergence, we are movi= ng to FC over Ethernet (FCoE). FCIP and iSCSI have not worked very well. Se= curity for data comes from FC and lowering of cost comes from use of FCoE. = That needs native Ethernet (no IP). > > When you have site-to-site VM mobility, data is not moving across sites. = E.g. an application server will connect to a set of load-balanced set of da= tabase servers within a VLAN. The application and database servers can be d= ifferent sites, and they connect over a VLAN. Alternately, the application = and database servers can be in the same location and the DB server accesses= the SAN over the Internet. Even if data is replicated across many sites, l= oad-balancing across application or db servers uses VLANs. In HPC as well, = there is a lot of broadcast and discovery, and this may use IP or not, the = fact is that it depends on broadcast. The HPC case externalizes the memory = on a host to other hosts through RDMA. Everything to do with Big Data will = rely on this, and besides disk externalization we will also see increase in= memory externalization. I just went to a IEEE HPC cloud conference :-) > > L3 assumes that all data (disk and memory) is inside the host. That assum= ption changed a decade ago. Cloud just increases the distribution. Just as = compute is optimized by muxing the VMs on a physical machine, storage is op= timized by consolidating data separately on storage devices and memory by h= osting it in different hosts. Network has to deal with all types of traffic= and security/isolation (imagine someone changing memory over the network).= Storage and memory traffic uses L2. To discover each other, hosts use L2. = These L2 domains need to span across sites and within the site. > > This are not corner cases. This is just central to what cloud means in th= e long run. > > Thanks, Ashish > > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of X= uxiaohu > Sent: Friday, December 23, 2011 12:09 PM > To: Eggert, Lars; dc@ietf.org; dcrg-interest@irtf.org > Cc: armd@ietf.org > Subject: Re: [armd] IP over IP solution for data center interconnect > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Xuxiaohu >> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA12=D4=C222=C8=D5 16:28 >> =CA=D5=BC=FE=C8=CB: 'Eggert, Lars'; dc@ietf.org; 'dcrg-interest@irtf.org= .' >> =D6=F7=CC=E2: IP over IP solution for data center interconnect >> >> Hi all, >> >> There has been a lot of L2 over L3 solutions or proposals for data cente= r >> network and data center interconnect till now. However, it seems recentl= y >> there are increasing interests on L3 over L3 (e.g., IP over IP) solution= s for data >> center network and data center interconnect, please see the following te= xt >> quoted from IETF82 L2VPN minutes >> ( https://www.ietf.org/proceedings/82/minutes/l2vpn.txt). It's a general= belief >> that L3 is more scalable than L2. Especially when considering the data c= enter >> interconnection case, the L3 over L3 solutions can bring DC operators mo= re >> benefits compared to the L2 over L3 solutions, such as path optimization= , >> active-active data centers, MAC table reduction on DC switches and broad= cast >> flood suppression etc . > > By the way, the ARP table scaling issue on DC gateways, which is deemed b= y the ARMD WG as the only worthy ARP problem in data center networks, could= also be solved with the IP over IP solution. > > Best regards, > Xiaohu > >> >> Although Layer 2 connectivity is still required for some high-availabili= ty clusters >> which use non-IP and link-local multicast for communication, more and mo= re >> cluster vendors are either already able to support cluster services at L= ayer3 or >> will support it in the near future. In addition, the GSLB mechanism (e.g= ., DNS >> based GSLB) works very well in most cases, is geo-cluster service still = a >> common requirement for data center interconnect? If not, could we spend = any >> time on exploring the possibility of using L3 over L3 solution for the m= ost data >> center interconnection scenarios where geo-clustering, especially non-IP= based >> geo-clustering is not needed? >> >> Best regards, >> Xiaohu >> >> **************************************************************** >> ********************************************************** >> Kireeti: I keep seeing ISID, PBB, VLANs. We have to stop conceding to l= ayer 2 >> and start moving to layer 3 (applause) and lots of problems will go away= . >> >> Florin: We should put VPN on the same page to modify the priorities. You= need >> to expand so can look at L3 over L3 as well as L2 over L3. For item numb= er 2 we >> need to look at L3 transport as well as Ethernet and MPLS. And for numb= er 3 >> we need to work on this as there's a lot of expertise in L2, L3 and othe= r WGs. >> >> >> Marc: The problem statement needs to include more of the L3 issues aroun= d >> sending L2 over L3, as the L2 traffic already contains L3. Issue is jus= t framing. >> >> Eric Nordmark; "Yes, Yes and Yes". We need to focus from the DC prospec= tive >> and not from the VPN view. don't just think about Ethernet over IP, but= also IP >> over IP. Hypervisor may get decoupled over time. >> **************************************************************** >> ********************************************************** >> > -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> > =B7=A2=BC=FE=C8=CB: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] = =B4=FA=B1=ED Eggert, >> Lars >> > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA12=D4=C216=C8=D5 16:24 >> > =CA=D5=BC=FE=C8=CB: dc@ietf.org >> > =D6=F7=CC=E2: [dc] IRTF datacenter research group discussion list >> > >> > Hi, >> > >> > I wanted to make you all aware of the IRTF's dcrg-interest mailing lis= t, which >> > was set up following a face-to-face meeting at SIGCOMM this year to di= scuss >> a >> > possible IRTF research group on datacenter networking: >> > http://irtf.org/mailman/listinfo/dcrg-interest >> > >> > There has not been much activity towards the formation of an IRTF RG s= ince >> > SIGCOMM, but I am hopeful that the high energy level demonstrated in t= he >> > various Taipei meetings on the topic will inject some energy here - se= veral of >> > the topics that may be too early for the IETF to standardize around wo= uld fit >> an >> > IRTF RG very well. I'm certainly supportive of this. >> > >> > Lars >> > IRTF Chair >> > >> > >> > -- >> > Mobile number during December: +358 46 5215582 >> > Mobile number starting January: +49 151 12055791 > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From adalela@cisco.com Mon Dec 26 23:49:42 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1426921F8A4B for ; Mon, 26 Dec 2011 23:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJmDhI++QTNZ for ; Mon, 26 Dec 2011 23:49:40 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4211121F88A0 for ; Mon, 26 Dec 2011 23:49:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=11460; q=dns/txt; s=iport; t=1324972179; x=1326181779; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=m8O4VGKijgr8pzPntRv0QccrMk5+AZCMF6iNLN44qfs=; b=lMBreyAbBkAWkIn+O7kpNLojuZYYa0mLD1ofmKu9xEzFQSytPb4hjDVZ eujQBHXCKEwKwYLT7tNa7X/JO+ym9chqfpNYtqEpF+lmh0X4G8GQchzvz rVxZ36pOiN0P2IZHg52vb7pVG2YunK2bxDsCzg0C0Wu0fg6+TSrS3U1j3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMAALR3+U5Io8UY/2dsb2JhbABChQ+WWpFkgXIBAQEDAQEBAQ8BHTUDAwMLDAQCAQYCEQQBAQUGBhcBBAIBIAYfCQgBAQQLCAgTB4dYCJcNAYxVCJEQgSuJSjdjBIg1lzyHTQ X-IronPort-AV: E=Sophos;i="4.71,415,1320624000"; d="scan'208";a="2378967" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 27 Dec 2011 07:49:37 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBR7nbUM025657; Tue, 27 Dec 2011 07:49:37 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Dec 2011 13:19:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Dec 2011 13:19:34 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102B25104@XMB-BGL-416.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] [armd] IP over IP solution for data center interconnect Thread-Index: AczEZWs1enlNW5A7QzOC/pHf9VF1TgAATylA References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com><618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Pedro Marques" X-OriginalArrivalTime: 27 Dec 2011 07:49:37.0438 (UTC) FILETIME=[14FA93E0:01CCC46C] Cc: dc@ietf.org Subject: Re: [dc] [armd] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 07:49:42 -0000 There is InfiniBand besides FiberChannel. And we are talking about = converging not separating them. The question is converge over L2 or L3. = I think you did not read me correctly. IP based solutions have been = defined before Ethernet solutions but not used widely. We can discuss = why. I would be interested to know how the storage multi-tenancy solutions = deal with private IP, MAC and ID in the public domain, which can be = duplicated.=20 The argument was not around load-balancing, it is around discovery. Your example of the hypervisor is interesting. I'm aware that Amazon = does things in the hypervisor. They provide IP mobility through NAT. = Security through a hypervisor firewall. The consequence is that you pay = extra if you wanted a mobile VM, and you manage your own firewall (at = least the last time I checked). If tenant isolation is all the way into = the host, then network QoS, bandwidth etc is also moot.=20 Thanks, Ashish -----Original Message----- From: Pedro Marques [mailto:pedro.r.marques@gmail.com]=20 Sent: Tuesday, December 27, 2011 12:32 PM To: Ashish Dalela (adalela) Cc: dc@ietf.org Subject: Re: [dc] [armd] IP over IP solution for data center = interconnect 2011/12/26 Ashish Dalela (adalela) : > For all the proponents of L3, here is a thought. summary of the original email: multi-tenant storage solutions require FiberChannel; an L3 service model doesn't support FiberChannel. There are multiple storage solutions that support multi-tenancy that work on top of IP making the argument moot (1). At large scale running a separate network for data and for storage imposes very significant costs. I'd venture that the proponents of L3 have very little interest in FiberChannel. The same goes for the argument that load-balancing requires L2. There is existence proof of the contrary. There is a wide range of technology choices available in this space. I'm sure there is interest in L2 based solutions but the claim that L3 based solutions are not feasible has already been disproved by deployed solutions. 1 - Example: When a storage solution presents a block device to the VM (e.g. Amazon EBS) it is the host OS/hypervisor that maps the guest OS operations into network operations; doing so in the infrastructure network real rather than in the tenant's network realm. > > The biggest concern in cloud is data protection. That is just make or = break. Data can't move when the VM moves. It's just too expensive and = time consuming. Further, to reduce disk wastage you have to put data on = network storage. That's just easy for data backup, and cheap in terms of = total disk space you need. There is a lot going on here in terms of data = de-duplication. > > Now given network storage, you have two options - NAS and SAN. > > On the cloud each VM administrator has root privileges. And IP and MAC = addresses can be duplicated (if you are root just configure any IP and = MAC on a virtual interface of choice). So, you have to protect the = network storage from multiple tenants who can have the same IP address = and MAC address. NAS assumes your id on the UNIX is globally unique and = your permissions are unique - not true anymore. So, you have IP, MAC and = ID duplication. > > That means that if you have to protect data, you have to know somehow = which host is allowed to see which disks. Doing this end-to-end using = TCP/IP is problematic because the NAS controller doesn't know about = tenant id, and whether the MAC and IP are being duplicated across = customers. To make the storage aware of segmentation, you have to carry = some segment (GRE, MPLS, VLAN, etc.) into the storage box. That's not = true today. > > Network level isolation happens in SAN, but not in NAS. NAS just runs = end-to-end over TCP. In SAN you can say which host will see which disk. = The FC security is high because MAC and FC-ID is assigned by the network = and not in the control of the host. The network knows which port is = which host/MAC. So, if you only know which port is which customer, you = know which MAC can see which disk. Binding a port to a customer is not = hard. But mapping all of that to data security and disk visibility is = not trivial. E.g. you have to do GRE tunnel mapping to a set of disk = permissions. Who needs that? > > SAN does not use IP. It uses Fiber Channel. With convergence, we are = moving to FC over Ethernet (FCoE). FCIP and iSCSI have not worked very = well. Security for data comes from FC and lowering of cost comes from = use of FCoE. That needs native Ethernet (no IP). > > When you have site-to-site VM mobility, data is not moving across = sites. E.g. an application server will connect to a set of load-balanced = set of database servers within a VLAN. The application and database = servers can be different sites, and they connect over a VLAN. = Alternately, the application and database servers can be in the same = location and the DB server accesses the SAN over the Internet. Even if = data is replicated across many sites, load-balancing across application = or db servers uses VLANs. In HPC as well, there is a lot of broadcast = and discovery, and this may use IP or not, the fact is that it depends = on broadcast. The HPC case externalizes the memory on a host to other = hosts through RDMA. Everything to do with Big Data will rely on this, = and besides disk externalization we will also see increase in memory = externalization. I just went to a IEEE HPC cloud conference :-) > > L3 assumes that all data (disk and memory) is inside the host. That = assumption changed a decade ago. Cloud just increases the distribution. = Just as compute is optimized by muxing the VMs on a physical machine, = storage is optimized by consolidating data separately on storage devices = and memory by hosting it in different hosts. Network has to deal with = all types of traffic and security/isolation (imagine someone changing = memory over the network). Storage and memory traffic uses L2. To = discover each other, hosts use L2. These L2 domains need to span across = sites and within the site. > > This are not corner cases. This is just central to what cloud means in = the long run. > > Thanks, Ashish > > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf = Of Xuxiaohu > Sent: Friday, December 23, 2011 12:09 PM > To: Eggert, Lars; dc@ietf.org; dcrg-interest@irtf.org > Cc: armd@ietf.org > Subject: Re: [armd] IP over IP solution for data center interconnect > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Xuxiaohu >> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA12=D4=C222=C8=D5 16:28 >> =CA=D5=BC=FE=C8=CB: 'Eggert, Lars'; dc@ietf.org; = 'dcrg-interest@irtf.org.' >> =D6=F7=CC=E2: IP over IP solution for data center interconnect >> >> Hi all, >> >> There has been a lot of L2 over L3 solutions or proposals for data = center >> network and data center interconnect till now. However, it seems = recently >> there are increasing interests on L3 over L3 (e.g., IP over IP) = solutions for data >> center network and data center interconnect, please see the following = text >> quoted from IETF82 L2VPN minutes >> ( https://www.ietf.org/proceedings/82/minutes/l2vpn.txt). It's a = general belief >> that L3 is more scalable than L2. Especially when considering the = data center >> interconnection case, the L3 over L3 solutions can bring DC operators = more >> benefits compared to the L2 over L3 solutions, such as path = optimization, >> active-active data centers, MAC table reduction on DC switches and = broadcast >> flood suppression etc . > > By the way, the ARP table scaling issue on DC gateways, which is = deemed by the ARMD WG as the only worthy ARP problem in data center = networks, could also be solved with the IP over IP solution. > > Best regards, > Xiaohu > >> >> Although Layer 2 connectivity is still required for some = high-availability clusters >> which use non-IP and link-local multicast for communication, more and = more >> cluster vendors are either already able to support cluster services = at Layer3 or >> will support it in the near future. In addition, the GSLB mechanism = (e.g., DNS >> based GSLB) works very well in most cases, is geo-cluster service = still a >> common requirement for data center interconnect? If not, could we = spend any >> time on exploring the possibility of using L3 over L3 solution for = the most data >> center interconnection scenarios where geo-clustering, especially = non-IP based >> geo-clustering is not needed? >> >> Best regards, >> Xiaohu >> >> **************************************************************** >> ********************************************************** >> Kireeti: I keep seeing ISID, PBB, VLANs. We have to stop conceding = to layer 2 >> and start moving to layer 3 (applause) and lots of problems will go = away. >> >> Florin: We should put VPN on the same page to modify the priorities. = You need >> to expand so can look at L3 over L3 as well as L2 over L3. For item = number 2 we >> need to look at L3 transport as well as Ethernet and MPLS. And for = number 3 >> we need to work on this as there's a lot of expertise in L2, L3 and = other WGs. >> >> >> Marc: The problem statement needs to include more of the L3 issues = around >> sending L2 over L3, as the L2 traffic already contains L3. Issue is = just framing. >> >> Eric Nordmark; "Yes, Yes and Yes". We need to focus from the DC = prospective >> and not from the VPN view. don't just think about Ethernet over IP, = but also IP >> over IP. Hypervisor may get decoupled over time. >> **************************************************************** >> ********************************************************** >> > -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> > =B7=A2=BC=FE=C8=CB: dc-bounces@ietf.org = [mailto:dc-bounces@ietf.org] =B4=FA=B1=ED Eggert, >> Lars >> > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA12=D4=C216=C8=D5 16:24 >> > =CA=D5=BC=FE=C8=CB: dc@ietf.org >> > =D6=F7=CC=E2: [dc] IRTF datacenter research group discussion list >> > >> > Hi, >> > >> > I wanted to make you all aware of the IRTF's dcrg-interest mailing = list, which >> > was set up following a face-to-face meeting at SIGCOMM this year to = discuss >> a >> > possible IRTF research group on datacenter networking: >> > http://irtf.org/mailman/listinfo/dcrg-interest >> > >> > There has not been much activity towards the formation of an IRTF = RG since >> > SIGCOMM, but I am hopeful that the high energy level demonstrated = in the >> > various Taipei meetings on the topic will inject some energy here - = several of >> > the topics that may be too early for the IETF to standardize around = would fit >> an >> > IRTF RG very well. I'm certainly supportive of this. >> > >> > Lars >> > IRTF Chair >> > >> > >> > -- >> > Mobile number during December: +358 46 5215582 >> > Mobile number starting January: +49 151 12055791 > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From jari.arkko@piuha.net Tue Dec 27 00:36:35 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672CF21F87FA for ; Tue, 27 Dec 2011 00:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoZANUW2bGO2 for ; Tue, 27 Dec 2011 00:36:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id E323B21F85F2 for ; Tue, 27 Dec 2011 00:36:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 40B362CC43 for ; Tue, 27 Dec 2011 10:36:34 +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 VeGm+NNutOx8 for ; Tue, 27 Dec 2011 10:36:33 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9BE072CC31 for ; Tue, 27 Dec 2011 10:36:33 +0200 (EET) Message-ID: <4EF98391.6010500@piuha.net> Date: Tue, 27 Dec 2011 10:36:33 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: dc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dc] interim dates decided? X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 08:36:35 -0000 Has the date for the Interim meeting been firmed up? I assume Feb 22-23th based on the doodle, but it would be good to get a confirmation... and what about a location? Jari From david.black@emc.com Tue Dec 27 13:26:43 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852BF21F8A97 for ; Tue, 27 Dec 2011 13:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExjbXU8T-348 for ; Tue, 27 Dec 2011 13:26:42 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id D7FB321F8A91 for ; Tue, 27 Dec 2011 13:26:41 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pBRLQd8C017808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Dec 2011 16:26:40 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 27 Dec 2011 16:26:30 -0500 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pBRLQREf026643; Tue, 27 Dec 2011 16:26:29 -0500 Received: from mx14a.corp.emc.com ([169.254.1.216]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Tue, 27 Dec 2011 16:26:27 -0500 From: To: Date: Tue, 27 Dec 2011 16:26:26 -0500 Thread-Topic: [dc] [armd] IP over IP solution for data center interconnect Thread-Index: AczEZWs1enlNW5A7QzOC/pHf9VF1TgAATylAAB0c3tA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9499@MX14A.corp.emc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com><618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5102B25104@XMB-BGL-416.cisco.com> In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102B25104@XMB-BGL-416.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: dc@ietf.org Subject: Re: [dc] [armd] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 21:26:43 -0000 QXNoaXNoLA0KDQo+IEkgd291bGQgYmUgaW50ZXJlc3RlZCB0byBrbm93IGhvdyB0aGUgc3RvcmFn ZSBtdWx0aS10ZW5hbmN5IHNvbHV0aW9ucyBkZWFsIHdpdGggcHJpdmF0ZSBJUCwgTUFDIGFuZCBJ RA0KPiBpbiB0aGUgcHVibGljIGRvbWFpbiwgd2hpY2ggY2FuIGJlIGR1cGxpY2F0ZWQuDQoNCkEg Y29tbW9uIGN1cnJlbnQgdGVjaG5pcXVlIGlzIHRvIHVzZSBwZXItdGVuYW50IFZMQU5zIChhIHRl bmFudCBtYXkgaGF2ZSBtdWx0aXBsZSBWTEFOcykgYW5kIHVzZSBOQVQgKGFzIG5lZWRlZCkgYmV0 d2VlbiB0aGUgVkxBTnMgYW5kIHRoZSBwdWJsaWMgSW50ZXJuZXQgaW4gb3JkZXIgdG8gc2VwYXJh dGUgVkxBTiBhZGRyZXNzaW5nIGZyb20gcHVibGljIEludGVybmV0IGFkZHJlc3NpbmcsIGVmZmVj dGl2ZWx5IHJlc3VsdGluZyBpbiBhICh2aXJ0dWFsKSBOQVQgaW5zdGFuY2UgcGVyIFZMQU4uICBB IDEyLWJpdCBWTEFOIHRhZyBpcyBub3QgbGFyZ2UgZW5vdWdoIHRvIHNjYWxlIHVwIHRvIHRoZSBk ZXNpcmVkIGxhcmdlLXNjYWxlIGRhdGEgY2VudGVyIHNjb3BlLCBzbyBib3RoIFZ4TEFOIGFuZCBO VkdSRSB1c2UgYSAyNC1iaXQgdmlydHVhbCBuZXR3b3JrIGlkZW50aWZpZXIgdG8gcmVwbGFjZSB0 aGUgMTItYml0IFZMQU4gdGFnOyBWeExBTiBjYWxscyB0aGlzIGEgVk5JIChWeExBTiBbb3IgVmly dHVhbF0gTmV0d29yayBJZGVudGlmaWVyKSwgYW5kIE5WR1JFIGNhbGxzIGl0IGEgVE5JIChUZW5h bnQgTmV0d29yayBJZGVudGlmaWVyKS4gIFZOSSBhbmQgVE5JIGVuY2FwL2RlY2FwIGNhbiBiZSBo YW5kbGVkIGJ5IHRoZSBoeXBlcnZpc29yIGFuZCBhcmUgbGltaXRlZCB0byB0aGUgZGF0YWNlbnRl cjsgaW4gdGhpcyBzdHJ1Y3R1cmUsIFZNcyBjYW4ndCB1c2UgYSBWTkkgb3IgVE5JIGRpcmVjdGx5 LCBhbmQgdGhlICh2aXJ0dWFsKSBOQVQgaGFuZGxlcyBlbmNhcC9kZWNhcCBmb3IgaW5ib3VuZC9v dXRib3VuZCB0cmFmZmljIHNvIHRoYXQgdHJ5aW5nIHRvIHNlbmQgZW5jYXBzdWxhdGVkIChWeExB TiBvciBOR1JFKSB0cmFmZmljIGluIGZyb20gdGhlIG91dHNpZGUgcmVzdWx0cyBpbiBkb3VibGUg ZW5jYXBzdWxhdGlvbiB3aXRoIG5vIGVmZmVjdCBvbiB0ZW5hbnQgaXNvbGF0aW9uLg0KDQpCZWZv cmUgb25lIG9mIHRoZSBMMlZQTiBmb2xrcyBjb21lcyBhZnRlciBtZSBmb3IgdGhhdCAibGltaXRl ZCB0byB0aGUgZGF0YWNlbnRlciIgY29tbWVudCA7LSkgLi4uIGFuIEwyVlBOIGdhdGV3YXkgd291 bGQgcHJvYmFibHkgdHJhbnNsYXRlIGJldHdlZW4gYSAyNC1iaXQgVk5JL1ROSSBhbmQgYSAyNC1i aXQgVlBOIElEIC0gZW5kLXRvLWVuZCB1c2Ugb2YgYSBzaW5nbGUgaWRlbnRpZmllciBmb3IgdGhl IEwyVlBOIGFuZCB0aGUgdmlydHVhbCBuZXR3b3JrcyBvbiBib3RoIGVuZHMgaXMgcG9zc2libGUs IGJ1dCAoSU1ITykgZGlmZmljdWx0IHdoZW4gdGhlcmUgYXJlIG11bHRpcGxlIGFkbWluaXN0cmF0 aXZlIGRvbWFpbnMgaW52b2x2ZWQgaW4gbWFuYWdpbmcgdGhlIGlkZW50aWZpZXJzLg0KDQpVc2Ug b2YgVkxBTnMgdG8gc2NvcGUgZmlsZXN5c3RlbSB2aXNpYmlsaXR5IG9uIE5BUyBmaWxlc2VydmVy cyBpcyBhIGNvbW1vbiBkZXBsb3llZCBwcmFjdGljZSBpbiBkYXRhY2VudGVycyAoZGl0dG8gZm9y IFZMQU5zIHRvIGxpbWl0IGlTQ1NJIHN0b3JhZ2UgdmlzaWJpbGl0eSksIHRoZXJlYnkgZGVhbGlu ZyB3aXRoIHRoZSBmb2xsb3dpbmc6DQoNCj4gU28sIHlvdSBoYXZlIHRvDQo+IHByb3RlY3QgdGhl IG5ldHdvcmsgc3RvcmFnZSBmcm9tIG11bHRpcGxlIHRlbmFudHMgd2hvIGNhbiBoYXZlIHRoZSBz YW1lIElQIGFkZHJlc3MgYW5kIE1BQyBhZGRyZXNzLg0KPiBOQVMgYXNzdW1lcyB5b3VyIGlkIG9u IHRoZSBVTklYIGlzIGdsb2JhbGx5IHVuaXF1ZSBhbmQgeW91ciBwZXJtaXNzaW9ucyBhcmUgdW5p cXVlIC0gbm90IHRydWUgYW55bW9yZS4NCj4gU28sIHlvdSBoYXZlIElQLCBNQUMgYW5kIElEIGR1 cGxpY2F0aW9uLg0KDQpEdXBsaWNhdGlvbiBvZiBJUCwgTUFDIGFuZCBJRCBvbiBzZXBhcmF0ZSBW TEFOcyB3b3JrcyBmaW5lIC0gdGhpcyBtb2RlbCBpcyBjYXJyaWVkIG92ZXIgdG8gdmlydHVhbCBu ZXR3b3JrcyBiYXNlZCBvbiBWTkkgb3IgVE5JLiAgVGhlIHNlbnRlbmNlIGNvbnRhaW5pbmcgImds b2JhbGx5IHVuaXF1ZSIgKGluY29ycmVjdGx5KSBhc3N1bWVzIGEgc2luZ2xlIGZpbGVzZXJ2ZXI7 IGluc3RlYWQsIGNvbnNpZGVyIGEgc2luZ2xlIE5BUyBzeXN0ZW0gcHJlc2VudGluZyB3aGF0IGlz IGVmZmVjdGl2ZWx5IGEgdmlydHVhbCBmaWxlc2VydmVyIHBlciBWTEFOIChvciBWTkkvVE5JKSBh bmQgc2ltaWxhcmx5IGZvciBpU0NTSSAtIHRoYXQgaXMgd2hhdCBzb3J0cyBvdXQgdGhpcyBkdXBs aWNhdGlvbiwgaW5jbHVkaW5nIHVzZSBvZiBkaWZmZXJlbnQgaWRlbnRpdHkgc2VydmljZXMvc2Vy dmVzIHBlciBWTEFOIChvciBWTkkvVE5JKS4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGF2aWQgTC4gQmxh Y2ssIERpc3Rpbmd1aXNoZWQgRW5naW5lZXINCkVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0 LiwgSG9wa2ludG9uLCBNQcKgIDAxNzQ4DQorMSAoNTA4KSAyOTMtNzk1M8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBGQVg6ICsxICg1MDgpIDI5My03Nzg2DQpkYXZpZC5ibGFja0BlbWMuY29twqDC oMKgwqDCoMKgwqAgTW9iaWxlOiArMSAoOTc4KSAzOTQtNzc1NA0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGRjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkNCj4gU2VudDog VHVlc2RheSwgRGVjZW1iZXIgMjcsIDIwMTEgMjo1MCBBTQ0KPiBUbzogUGVkcm8gTWFycXVlcw0K PiBDYzogZGNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkY10gW2FybWRdIElQIG92ZXIgSVAg c29sdXRpb24gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdA0KPiANCj4gVGhlcmUgaXMgSW5m aW5pQmFuZCBiZXNpZGVzIEZpYmVyQ2hhbm5lbC4gQW5kIHdlIGFyZSB0YWxraW5nIGFib3V0IGNv bnZlcmdpbmcgbm90IHNlcGFyYXRpbmcgdGhlbS4gVGhlDQo+IHF1ZXN0aW9uIGlzIGNvbnZlcmdl IG92ZXIgTDIgb3IgTDMuIEkgdGhpbmsgeW91IGRpZCBub3QgcmVhZCBtZSBjb3JyZWN0bHkuIElQ IGJhc2VkIHNvbHV0aW9ucyBoYXZlDQo+IGJlZW4gZGVmaW5lZCBiZWZvcmUgRXRoZXJuZXQgc29s dXRpb25zIGJ1dCBub3QgdXNlZCB3aWRlbHkuIFdlIGNhbiBkaXNjdXNzIHdoeS4NCj4gDQo+IEkg d291bGQgYmUgaW50ZXJlc3RlZCB0byBrbm93IGhvdyB0aGUgc3RvcmFnZSBtdWx0aS10ZW5hbmN5 IHNvbHV0aW9ucyBkZWFsIHdpdGggcHJpdmF0ZSBJUCwgTUFDIGFuZCBJRA0KPiBpbiB0aGUgcHVi bGljIGRvbWFpbiwgd2hpY2ggY2FuIGJlIGR1cGxpY2F0ZWQuDQo+IA0KPiBUaGUgYXJndW1lbnQg d2FzIG5vdCBhcm91bmQgbG9hZC1iYWxhbmNpbmcsIGl0IGlzIGFyb3VuZCBkaXNjb3ZlcnkuDQo+ IA0KPiBZb3VyIGV4YW1wbGUgb2YgdGhlIGh5cGVydmlzb3IgaXMgaW50ZXJlc3RpbmcuIEknbSBh d2FyZSB0aGF0IEFtYXpvbiBkb2VzIHRoaW5ncyBpbiB0aGUgaHlwZXJ2aXNvci4NCj4gVGhleSBw cm92aWRlIElQIG1vYmlsaXR5IHRocm91Z2ggTkFULiBTZWN1cml0eSB0aHJvdWdoIGEgaHlwZXJ2 aXNvciBmaXJld2FsbC4gVGhlIGNvbnNlcXVlbmNlIGlzIHRoYXQNCj4geW91IHBheSBleHRyYSBp ZiB5b3Ugd2FudGVkIGEgbW9iaWxlIFZNLCBhbmQgeW91IG1hbmFnZSB5b3VyIG93biBmaXJld2Fs bCAoYXQgbGVhc3QgdGhlIGxhc3QgdGltZSBJDQo+IGNoZWNrZWQpLiBJZiB0ZW5hbnQgaXNvbGF0 aW9uIGlzIGFsbCB0aGUgd2F5IGludG8gdGhlIGhvc3QsIHRoZW4gbmV0d29yayBRb1MsIGJhbmR3 aWR0aCBldGMgaXMgYWxzbw0KPiBtb290Lg0KPiANCj4gVGhhbmtzLCBBc2hpc2gNCj4gDQo+IA0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZWRybyBNYXJxdWVzIFttYWls dG86cGVkcm8uci5tYXJxdWVzQGdtYWlsLmNvbV0NCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIg MjcsIDIwMTEgMTI6MzIgUE0NCj4gVG86IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQo+IENjOiBk Y0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2RjXSBbYXJtZF0gSVAgb3ZlciBJUCBzb2x1dGlv biBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0DQo+IA0KPiAyMDExLzEyLzI2IEFzaGlzaCBE YWxlbGEgKGFkYWxlbGEpIDxhZGFsZWxhQGNpc2NvLmNvbT46DQo+ID4gRm9yIGFsbCB0aGUgcHJv cG9uZW50cyBvZiBMMywgaGVyZSBpcyBhIHRob3VnaHQuDQo+IA0KPiBzdW1tYXJ5IG9mIHRoZSBv cmlnaW5hbCBlbWFpbDogbXVsdGktdGVuYW50IHN0b3JhZ2Ugc29sdXRpb25zIHJlcXVpcmUNCj4g RmliZXJDaGFubmVsOyBhbiBMMyBzZXJ2aWNlIG1vZGVsIGRvZXNuJ3Qgc3VwcG9ydCBGaWJlckNo YW5uZWwuDQo+IA0KPiBUaGVyZSBhcmUgbXVsdGlwbGUgc3RvcmFnZSBzb2x1dGlvbnMgdGhhdCBz dXBwb3J0IG11bHRpLXRlbmFuY3kgdGhhdA0KPiB3b3JrIG9uIHRvcCBvZiBJUCBtYWtpbmcgdGhl IGFyZ3VtZW50IG1vb3QgKDEpLiBBdCBsYXJnZSBzY2FsZSBydW5uaW5nDQo+IGEgc2VwYXJhdGUg bmV0d29yayBmb3IgZGF0YSBhbmQgZm9yIHN0b3JhZ2UgaW1wb3NlcyB2ZXJ5IHNpZ25pZmljYW50 DQo+IGNvc3RzLiBJJ2QgdmVudHVyZSB0aGF0IHRoZSBwcm9wb25lbnRzIG9mIEwzIGhhdmUgdmVy eSBsaXR0bGUgaW50ZXJlc3QNCj4gaW4gRmliZXJDaGFubmVsLg0KPiANCj4gVGhlIHNhbWUgZ29l cyBmb3IgdGhlIGFyZ3VtZW50IHRoYXQgbG9hZC1iYWxhbmNpbmcgcmVxdWlyZXMgTDIuIFRoZXJl DQo+IGlzIGV4aXN0ZW5jZSBwcm9vZiBvZiB0aGUgY29udHJhcnkuDQo+IA0KPiBUaGVyZSBpcyBh IHdpZGUgcmFuZ2Ugb2YgdGVjaG5vbG9neSBjaG9pY2VzIGF2YWlsYWJsZSBpbiB0aGlzIHNwYWNl Lg0KPiBJJ20gc3VyZSB0aGVyZSBpcyBpbnRlcmVzdCBpbiBMMiBiYXNlZCBzb2x1dGlvbnMgYnV0 IHRoZSBjbGFpbSB0aGF0IEwzDQo+IGJhc2VkIHNvbHV0aW9ucyBhcmUgbm90IGZlYXNpYmxlIGhh cyBhbHJlYWR5IGJlZW4gZGlzcHJvdmVkIGJ5DQo+IGRlcGxveWVkIHNvbHV0aW9ucy4NCj4gDQo+ IDEgLSBFeGFtcGxlOiBXaGVuIGEgc3RvcmFnZSBzb2x1dGlvbiBwcmVzZW50cyBhIGJsb2NrIGRl dmljZSB0byB0aGUgVk0NCj4gKGUuZy4gQW1hem9uIEVCUykgaXQgaXMgdGhlIGhvc3QgT1MvaHlw ZXJ2aXNvciB0aGF0IG1hcHMgdGhlIGd1ZXN0IE9TDQo+IG9wZXJhdGlvbnMgaW50byBuZXR3b3Jr IG9wZXJhdGlvbnM7IGRvaW5nIHNvIGluIHRoZSBpbmZyYXN0cnVjdHVyZQ0KPiBuZXR3b3JrIHJl YWwgcmF0aGVyIHRoYW4gaW4gdGhlIHRlbmFudCdzIG5ldHdvcmsgcmVhbG0uDQo+IA0KPiA+DQo+ ID4gVGhlIGJpZ2dlc3QgY29uY2VybiBpbiBjbG91ZCBpcyBkYXRhIHByb3RlY3Rpb24uIFRoYXQg aXMganVzdCBtYWtlIG9yIGJyZWFrLiBEYXRhIGNhbid0IG1vdmUgd2hlbg0KPiB0aGUgVk0gbW92 ZXMuIEl0J3MganVzdCB0b28gZXhwZW5zaXZlIGFuZCB0aW1lIGNvbnN1bWluZy4gRnVydGhlciwg dG8gcmVkdWNlIGRpc2sgd2FzdGFnZSB5b3UgaGF2ZSB0bw0KPiBwdXQgZGF0YSBvbiBuZXR3b3Jr IHN0b3JhZ2UuIFRoYXQncyBqdXN0IGVhc3kgZm9yIGRhdGEgYmFja3VwLCBhbmQgY2hlYXAgaW4g dGVybXMgb2YgdG90YWwgZGlzayBzcGFjZQ0KPiB5b3UgbmVlZC4gVGhlcmUgaXMgYSBsb3QgZ29p bmcgb24gaGVyZSBpbiB0ZXJtcyBvZiBkYXRhIGRlLWR1cGxpY2F0aW9uLg0KPiA+DQo+ID4gTm93 IGdpdmVuIG5ldHdvcmsgc3RvcmFnZSwgeW91IGhhdmUgdHdvIG9wdGlvbnMgLSBOQVMgYW5kIFNB Ti4NCj4gPg0KPiA+IE9uIHRoZSBjbG91ZCBlYWNoIFZNIGFkbWluaXN0cmF0b3IgaGFzIHJvb3Qg cHJpdmlsZWdlcy4gQW5kIElQIGFuZCBNQUMgYWRkcmVzc2VzIGNhbiBiZSBkdXBsaWNhdGVkDQo+ IChpZiB5b3UgYXJlIHJvb3QganVzdCBjb25maWd1cmUgYW55IElQIGFuZCBNQUMgb24gYSB2aXJ0 dWFsIGludGVyZmFjZSBvZiBjaG9pY2UpLiBTbywgeW91IGhhdmUgdG8NCj4gcHJvdGVjdCB0aGUg bmV0d29yayBzdG9yYWdlIGZyb20gbXVsdGlwbGUgdGVuYW50cyB3aG8gY2FuIGhhdmUgdGhlIHNh bWUgSVAgYWRkcmVzcyBhbmQgTUFDIGFkZHJlc3MuDQo+IE5BUyBhc3N1bWVzIHlvdXIgaWQgb24g dGhlIFVOSVggaXMgZ2xvYmFsbHkgdW5pcXVlIGFuZCB5b3VyIHBlcm1pc3Npb25zIGFyZSB1bmlx dWUgLSBub3QgdHJ1ZSBhbnltb3JlLg0KPiBTbywgeW91IGhhdmUgSVAsIE1BQyBhbmQgSUQgZHVw bGljYXRpb24uDQo+ID4NCj4gPiBUaGF0IG1lYW5zIHRoYXQgaWYgeW91IGhhdmUgdG8gcHJvdGVj dCBkYXRhLCB5b3UgaGF2ZSB0byBrbm93IHNvbWVob3cgd2hpY2ggaG9zdCBpcyBhbGxvd2VkIHRv IHNlZQ0KPiB3aGljaCBkaXNrcy4gRG9pbmcgdGhpcyBlbmQtdG8tZW5kIHVzaW5nIFRDUC9JUCBp cyBwcm9ibGVtYXRpYyBiZWNhdXNlIHRoZSBOQVMgY29udHJvbGxlciBkb2Vzbid0IGtub3cNCj4g YWJvdXQgdGVuYW50IGlkLCBhbmQgd2hldGhlciB0aGUgTUFDIGFuZCBJUCBhcmUgYmVpbmcgZHVw bGljYXRlZCBhY3Jvc3MgY3VzdG9tZXJzLiBUbyBtYWtlIHRoZSBzdG9yYWdlDQo+IGF3YXJlIG9m IHNlZ21lbnRhdGlvbiwgeW91IGhhdmUgdG8gY2Fycnkgc29tZSBzZWdtZW50IChHUkUsIE1QTFMs IFZMQU4sIGV0Yy4pIGludG8gdGhlIHN0b3JhZ2UgYm94Lg0KPiBUaGF0J3Mgbm90IHRydWUgdG9k YXkuDQo+ID4NCj4gPiBOZXR3b3JrIGxldmVsIGlzb2xhdGlvbiBoYXBwZW5zIGluIFNBTiwgYnV0 IG5vdCBpbiBOQVMuIE5BUyBqdXN0IHJ1bnMgZW5kLXRvLWVuZCBvdmVyIFRDUC4gSW4gU0FODQo+ IHlvdSBjYW4gc2F5IHdoaWNoIGhvc3Qgd2lsbCBzZWUgd2hpY2ggZGlzay4gVGhlIEZDIHNlY3Vy aXR5IGlzIGhpZ2ggYmVjYXVzZSBNQUMgYW5kIEZDLUlEIGlzIGFzc2lnbmVkDQo+IGJ5IHRoZSBu ZXR3b3JrIGFuZCBub3QgaW4gdGhlIGNvbnRyb2wgb2YgdGhlIGhvc3QuIFRoZSBuZXR3b3JrIGtu b3dzIHdoaWNoIHBvcnQgaXMgd2hpY2ggaG9zdC9NQUMuIFNvLA0KPiBpZiB5b3Ugb25seSBrbm93 IHdoaWNoIHBvcnQgaXMgd2hpY2ggY3VzdG9tZXIsIHlvdSBrbm93IHdoaWNoIE1BQyBjYW4gc2Vl IHdoaWNoIGRpc2suIEJpbmRpbmcgYSBwb3J0DQo+IHRvIGEgY3VzdG9tZXIgaXMgbm90IGhhcmQu IEJ1dCBtYXBwaW5nIGFsbCBvZiB0aGF0IHRvIGRhdGEgc2VjdXJpdHkgYW5kIGRpc2sgdmlzaWJp bGl0eSBpcyBub3QNCj4gdHJpdmlhbC4gRS5nLiB5b3UgaGF2ZSB0byBkbyBHUkUgdHVubmVsIG1h cHBpbmcgdG8gYSBzZXQgb2YgZGlzayBwZXJtaXNzaW9ucy4gV2hvIG5lZWRzIHRoYXQ/DQo+ID4N Cj4gPiBTQU4gZG9lcyBub3QgdXNlIElQLiBJdCB1c2VzIEZpYmVyIENoYW5uZWwuIFdpdGggY29u dmVyZ2VuY2UsIHdlIGFyZSBtb3ZpbmcgdG8gRkMgb3ZlciBFdGhlcm5ldA0KPiAoRkNvRSkuIEZD SVAgYW5kIGlTQ1NJIGhhdmUgbm90IHdvcmtlZCB2ZXJ5IHdlbGwuIFNlY3VyaXR5IGZvciBkYXRh IGNvbWVzIGZyb20gRkMgYW5kIGxvd2VyaW5nIG9mIGNvc3QNCj4gY29tZXMgZnJvbSB1c2Ugb2Yg RkNvRS4gVGhhdCBuZWVkcyBuYXRpdmUgRXRoZXJuZXQgKG5vIElQKS4NCj4gPg0KPiA+IFdoZW4g eW91IGhhdmUgc2l0ZS10by1zaXRlIFZNIG1vYmlsaXR5LCBkYXRhIGlzIG5vdCBtb3ZpbmcgYWNy b3NzIHNpdGVzLiBFLmcuIGFuIGFwcGxpY2F0aW9uIHNlcnZlcg0KPiB3aWxsIGNvbm5lY3QgdG8g YSBzZXQgb2YgbG9hZC1iYWxhbmNlZCBzZXQgb2YgZGF0YWJhc2Ugc2VydmVycyB3aXRoaW4gYSBW TEFOLiBUaGUgYXBwbGljYXRpb24gYW5kDQo+IGRhdGFiYXNlIHNlcnZlcnMgY2FuIGJlIGRpZmZl cmVudCBzaXRlcywgYW5kIHRoZXkgY29ubmVjdCBvdmVyIGEgVkxBTi4gQWx0ZXJuYXRlbHksIHRo ZSBhcHBsaWNhdGlvbg0KPiBhbmQgZGF0YWJhc2Ugc2VydmVycyBjYW4gYmUgaW4gdGhlIHNhbWUg bG9jYXRpb24gYW5kIHRoZSBEQiBzZXJ2ZXIgYWNjZXNzZXMgdGhlIFNBTiBvdmVyIHRoZSBJbnRl cm5ldC4NCj4gRXZlbiBpZiBkYXRhIGlzIHJlcGxpY2F0ZWQgYWNyb3NzIG1hbnkgc2l0ZXMsIGxv YWQtYmFsYW5jaW5nIGFjcm9zcyBhcHBsaWNhdGlvbiBvciBkYiBzZXJ2ZXJzIHVzZXMNCj4gVkxB TnMuIEluIEhQQyBhcyB3ZWxsLCB0aGVyZSBpcyBhIGxvdCBvZiBicm9hZGNhc3QgYW5kIGRpc2Nv dmVyeSwgYW5kIHRoaXMgbWF5IHVzZSBJUCBvciBub3QsIHRoZSBmYWN0DQo+IGlzIHRoYXQgaXQg ZGVwZW5kcyBvbiBicm9hZGNhc3QuIFRoZSBIUEMgY2FzZSBleHRlcm5hbGl6ZXMgdGhlIG1lbW9y eSBvbiBhIGhvc3QgdG8gb3RoZXIgaG9zdHMgdGhyb3VnaA0KPiBSRE1BLiBFdmVyeXRoaW5nIHRv IGRvIHdpdGggQmlnIERhdGEgd2lsbCByZWx5IG9uIHRoaXMsIGFuZCBiZXNpZGVzIGRpc2sgZXh0 ZXJuYWxpemF0aW9uIHdlIHdpbGwgYWxzbw0KPiBzZWUgaW5jcmVhc2UgaW4gbWVtb3J5IGV4dGVy bmFsaXphdGlvbi4gSSBqdXN0IHdlbnQgdG8gYSBJRUVFIEhQQyBjbG91ZCBjb25mZXJlbmNlIDot KQ0KPiA+DQo+ID4gTDMgYXNzdW1lcyB0aGF0IGFsbCBkYXRhIChkaXNrIGFuZCBtZW1vcnkpIGlz IGluc2lkZSB0aGUgaG9zdC4gVGhhdCBhc3N1bXB0aW9uIGNoYW5nZWQgYSBkZWNhZGUgYWdvLg0K PiBDbG91ZCBqdXN0IGluY3JlYXNlcyB0aGUgZGlzdHJpYnV0aW9uLiBKdXN0IGFzIGNvbXB1dGUg aXMgb3B0aW1pemVkIGJ5IG11eGluZyB0aGUgVk1zIG9uIGEgcGh5c2ljYWwNCj4gbWFjaGluZSwg c3RvcmFnZSBpcyBvcHRpbWl6ZWQgYnkgY29uc29saWRhdGluZyBkYXRhIHNlcGFyYXRlbHkgb24g c3RvcmFnZSBkZXZpY2VzIGFuZCBtZW1vcnkgYnkNCj4gaG9zdGluZyBpdCBpbiBkaWZmZXJlbnQg aG9zdHMuIE5ldHdvcmsgaGFzIHRvIGRlYWwgd2l0aCBhbGwgdHlwZXMgb2YgdHJhZmZpYyBhbmQg c2VjdXJpdHkvaXNvbGF0aW9uDQo+IChpbWFnaW5lIHNvbWVvbmUgY2hhbmdpbmcgbWVtb3J5IG92 ZXIgdGhlIG5ldHdvcmspLiBTdG9yYWdlIGFuZCBtZW1vcnkgdHJhZmZpYyB1c2VzIEwyLiBUbyBk aXNjb3Zlcg0KPiBlYWNoIG90aGVyLCBob3N0cyB1c2UgTDIuIFRoZXNlIEwyIGRvbWFpbnMgbmVl ZCB0byBzcGFuIGFjcm9zcyBzaXRlcyBhbmQgd2l0aGluIHRoZSBzaXRlLg0KPiA+DQo+ID4gVGhp cyBhcmUgbm90IGNvcm5lciBjYXNlcy4gVGhpcyBpcyBqdXN0IGNlbnRyYWwgdG8gd2hhdCBjbG91 ZCBtZWFucyBpbiB0aGUgbG9uZyBydW4uDQo+ID4NCj4gPiBUaGFua3MsIEFzaGlzaA0KPiA+DQo+ ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGFybWQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmFybWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1 eGlhb2h1DQo+ID4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAyMywgMjAxMSAxMjowOSBQTQ0KPiA+ IFRvOiBFZ2dlcnQsIExhcnM7IGRjQGlldGYub3JnOyBkY3JnLWludGVyZXN0QGlydGYub3JnDQo+ ID4gQ2M6IGFybWRAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW2FybWRdIElQIG92ZXIgSVAg c29sdXRpb24gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdA0KPiA+DQo+ID4NCj4gPj4gLS0t LS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+PiDlj5Hku7bkuro6IFh1eGlhb2h1DQo+ID4+IOWPkemA geaXtumXtDogMjAxMeW5tDEy5pyIMjLml6UgMTY6MjgNCj4gPj4g5pS25Lu25Lq6OiAnRWdnZXJ0 LCBMYXJzJzsgZGNAaWV0Zi5vcmc7ICdkY3JnLWludGVyZXN0QGlydGYub3JnLicNCj4gPj4g5Li7 6aKYOiBJUCBvdmVyIElQIHNvbHV0aW9uIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QNCj4g Pj4NCj4gPj4gSGkgYWxsLA0KPiA+Pg0KPiA+PiBUaGVyZSBoYXMgYmVlbiBhIGxvdCBvZiBMMiBv dmVyIEwzIHNvbHV0aW9ucyBvciBwcm9wb3NhbHMgZm9yIGRhdGEgY2VudGVyDQo+ID4+IG5ldHdv cmsgYW5kIGRhdGEgY2VudGVyIGludGVyY29ubmVjdCB0aWxsIG5vdy4gSG93ZXZlciwgaXQgc2Vl bXMgcmVjZW50bHkNCj4gPj4gdGhlcmUgYXJlIGluY3JlYXNpbmcgaW50ZXJlc3RzIG9uIEwzIG92 ZXIgTDMgKGUuZy4sIElQIG92ZXIgSVApIHNvbHV0aW9ucyBmb3IgZGF0YQ0KPiA+PiBjZW50ZXIg bmV0d29yayBhbmQgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0LCBwbGVhc2Ugc2VlIHRoZSBmb2xs b3dpbmcgdGV4dA0KPiA+PiBxdW90ZWQgZnJvbSBJRVRGODIgTDJWUE4gbWludXRlcw0KPiA+PiAo IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgyL21pbnV0ZXMvbDJ2cG4udHh0KS4g SXQncyBhIGdlbmVyYWwgYmVsaWVmDQo+ID4+IHRoYXQgTDMgaXMgbW9yZSBzY2FsYWJsZSB0aGFu IEwyLiBFc3BlY2lhbGx5IHdoZW4gY29uc2lkZXJpbmcgdGhlIGRhdGEgY2VudGVyDQo+ID4+IGlu dGVyY29ubmVjdGlvbiBjYXNlLCB0aGUgTDMgb3ZlciBMMyBzb2x1dGlvbnMgY2FuIGJyaW5nIERD IG9wZXJhdG9ycyBtb3JlDQo+ID4+IGJlbmVmaXRzIGNvbXBhcmVkIHRvIHRoZSBMMiBvdmVyIEwz IHNvbHV0aW9ucywgc3VjaCBhcyBwYXRoIG9wdGltaXphdGlvbiwNCj4gPj4gYWN0aXZlLWFjdGl2 ZSBkYXRhIGNlbnRlcnMsIE1BQyB0YWJsZSByZWR1Y3Rpb24gb24gREMgc3dpdGNoZXMgYW5kIGJy b2FkY2FzdA0KPiA+PiBmbG9vZCBzdXBwcmVzc2lvbiBldGMgLg0KPiA+DQo+ID4gQnkgdGhlIHdh eSwgdGhlIEFSUCB0YWJsZSBzY2FsaW5nIGlzc3VlIG9uIERDIGdhdGV3YXlzLCB3aGljaCBpcyBk ZWVtZWQgYnkgdGhlIEFSTUQgV0cgYXMgdGhlIG9ubHkNCj4gd29ydGh5IEFSUCBwcm9ibGVtIGlu IGRhdGEgY2VudGVyIG5ldHdvcmtzLCBjb3VsZCBhbHNvIGJlIHNvbHZlZCB3aXRoIHRoZSBJUCBv dmVyIElQIHNvbHV0aW9uLg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+ DQo+ID4+DQo+ID4+IEFsdGhvdWdoIExheWVyIDIgY29ubmVjdGl2aXR5IGlzIHN0aWxsIHJlcXVp cmVkIGZvciBzb21lIGhpZ2gtYXZhaWxhYmlsaXR5IGNsdXN0ZXJzDQo+ID4+IHdoaWNoIHVzZSBu b24tSVAgYW5kIGxpbmstbG9jYWwgbXVsdGljYXN0IGZvciBjb21tdW5pY2F0aW9uLCBtb3JlIGFu ZCBtb3JlDQo+ID4+IGNsdXN0ZXIgdmVuZG9ycyBhcmUgZWl0aGVyIGFscmVhZHkgYWJsZSB0byBz dXBwb3J0IGNsdXN0ZXIgc2VydmljZXMgYXQgTGF5ZXIzIG9yDQo+ID4+IHdpbGwgc3VwcG9ydCBp dCBpbiB0aGUgbmVhciBmdXR1cmUuIEluIGFkZGl0aW9uLCB0aGUgR1NMQiBtZWNoYW5pc20gKGUu Zy4sIEROUw0KPiA+PiBiYXNlZCBHU0xCKSB3b3JrcyB2ZXJ5IHdlbGwgaW4gbW9zdCBjYXNlcywg aXMgZ2VvLWNsdXN0ZXIgc2VydmljZSBzdGlsbCBhDQo+ID4+IGNvbW1vbiByZXF1aXJlbWVudCBm b3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0PyBJZiBub3QsIGNvdWxkIHdlIHNwZW5kIGFueQ0K PiA+PiB0aW1lIG9uIGV4cGxvcmluZyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgTDMgb3ZlciBM MyBzb2x1dGlvbiBmb3IgdGhlIG1vc3QgZGF0YQ0KPiA+PiBjZW50ZXIgaW50ZXJjb25uZWN0aW9u IHNjZW5hcmlvcyB3aGVyZSBnZW8tY2x1c3RlcmluZywgZXNwZWNpYWxseSBub24tSVAgYmFzZWQN Cj4gPj4gZ2VvLWNsdXN0ZXJpbmcgaXMgbm90IG5lZWRlZD8NCj4gPj4NCj4gPj4gQmVzdCByZWdh cmRzLA0KPiA+PiBYaWFvaHUNCj4gPj4NCj4gPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+PiAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4+IEtpcmVl dGk6IEkga2VlcCBzZWVpbmcgSVNJRCwgUEJCLCBWTEFOcy4gIFdlIGhhdmUgdG8gc3RvcCBjb25j ZWRpbmcgdG8gbGF5ZXIgMg0KPiA+PiBhbmQgc3RhcnQgbW92aW5nIHRvIGxheWVyIDMgKGFwcGxh dXNlKSBhbmQgbG90cyBvZiBwcm9ibGVtcyB3aWxsIGdvIGF3YXkuDQo+ID4+DQo+ID4+IEZsb3Jp bjogV2Ugc2hvdWxkIHB1dCBWUE4gb24gdGhlIHNhbWUgcGFnZSB0byBtb2RpZnkgdGhlIHByaW9y aXRpZXMuIFlvdSBuZWVkDQo+ID4+IHRvIGV4cGFuZCBzbyBjYW4gbG9vayBhdCBMMyBvdmVyIEwz IGFzIHdlbGwgYXMgTDIgb3ZlciBMMy4gRm9yIGl0ZW0gbnVtYmVyIDIgd2UNCj4gPj4gbmVlZCB0 byBsb29rIGF0IEwzIHRyYW5zcG9ydCBhcyB3ZWxsIGFzIEV0aGVybmV0IGFuZCBNUExTLiAgQW5k IGZvciBudW1iZXIgMw0KPiA+PiB3ZSBuZWVkIHRvIHdvcmsgb24gdGhpcyBhcyB0aGVyZSdzIGEg bG90IG9mIGV4cGVydGlzZSBpbiBMMiwgTDMgYW5kIG90aGVyIFdHcy4NCj4gPj4NCj4gPj4NCj4g Pj4gTWFyYzogVGhlIHByb2JsZW0gc3RhdGVtZW50IG5lZWRzIHRvIGluY2x1ZGUgbW9yZSBvZiB0 aGUgTDMgaXNzdWVzIGFyb3VuZA0KPiA+PiBzZW5kaW5nIEwyIG92ZXIgTDMsIGFzIHRoZSBMMiB0 cmFmZmljIGFscmVhZHkgY29udGFpbnMgTDMuICBJc3N1ZSBpcyBqdXN0IGZyYW1pbmcuDQo+ID4+ DQo+ID4+IEVyaWMgTm9yZG1hcms7ICJZZXMsIFllcyBhbmQgWWVzIi4gIFdlIG5lZWQgdG8gZm9j dXMgZnJvbSB0aGUgREMgcHJvc3BlY3RpdmUNCj4gPj4gYW5kIG5vdCBmcm9tIHRoZSBWUE4gdmll dy4gIGRvbid0IGp1c3QgdGhpbmsgYWJvdXQgRXRoZXJuZXQgb3ZlciBJUCwgYnV0IGFsc28gSVAN Cj4gPj4gb3ZlciBJUC4gIEh5cGVydmlzb3IgbWF5IGdldCBkZWNvdXBsZWQgb3ZlciB0aW1lLg0K PiA+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQo+ID4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCj4gPj4gPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+ ID4g5Y+R5Lu25Lq6OiBkYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRm Lm9yZ10g5Luj6KGoIEVnZ2VydCwNCj4gPj4gTGFycw0KPiA+PiA+IOWPkemAgeaXtumXtDogMjAx MeW5tDEy5pyIMTbml6UgMTY6MjQNCj4gPj4gPiDmlLbku7bkuro6IGRjQGlldGYub3JnDQo+ID4+ ID4g5Li76aKYOiBbZGNdIElSVEYgZGF0YWNlbnRlciByZXNlYXJjaCBncm91cCBkaXNjdXNzaW9u IGxpc3QNCj4gPj4gPg0KPiA+PiA+IEhpLA0KPiA+PiA+DQo+ID4+ID4gSSB3YW50ZWQgdG8gbWFr ZSB5b3UgYWxsIGF3YXJlIG9mIHRoZSBJUlRGJ3MgZGNyZy1pbnRlcmVzdCBtYWlsaW5nIGxpc3Qs IHdoaWNoDQo+ID4+ID4gd2FzIHNldCB1cCBmb2xsb3dpbmcgYSBmYWNlLXRvLWZhY2UgbWVldGlu ZyBhdCBTSUdDT01NIHRoaXMgeWVhciB0byBkaXNjdXNzDQo+ID4+IGENCj4gPj4gPiBwb3NzaWJs ZSBJUlRGIHJlc2VhcmNoIGdyb3VwIG9uIGRhdGFjZW50ZXIgbmV0d29ya2luZzoNCj4gPj4gPiBo dHRwOi8vaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kY3JnLWludGVyZXN0DQo+ID4+ID4NCj4g Pj4gPiBUaGVyZSBoYXMgbm90IGJlZW4gbXVjaCBhY3Rpdml0eSB0b3dhcmRzIHRoZSBmb3JtYXRp b24gb2YgYW4gSVJURiBSRyBzaW5jZQ0KPiA+PiA+IFNJR0NPTU0sIGJ1dCBJIGFtIGhvcGVmdWwg dGhhdCB0aGUgaGlnaCBlbmVyZ3kgbGV2ZWwgZGVtb25zdHJhdGVkIGluIHRoZQ0KPiA+PiA+IHZh cmlvdXMgVGFpcGVpIG1lZXRpbmdzIG9uIHRoZSB0b3BpYyB3aWxsIGluamVjdCBzb21lIGVuZXJn eSBoZXJlIC0gc2V2ZXJhbCBvZg0KPiA+PiA+IHRoZSB0b3BpY3MgdGhhdCBtYXkgYmUgdG9vIGVh cmx5IGZvciB0aGUgSUVURiB0byBzdGFuZGFyZGl6ZSBhcm91bmQgd291bGQgZml0DQo+ID4+IGFu DQo+ID4+ID4gSVJURiBSRyB2ZXJ5IHdlbGwuIEknbSBjZXJ0YWlubHkgc3VwcG9ydGl2ZSBvZiB0 aGlzLg0KPiA+PiA+DQo+ID4+ID4gTGFycw0KPiA+PiA+IElSVEYgQ2hhaXINCj4gPj4gPg0KPiA+ PiA+DQo+ID4+ID4gLS0NCj4gPj4gPiBNb2JpbGUgbnVtYmVyIGR1cmluZyBEZWNlbWJlcjogICAg KzM1OCA0NiA1MjE1NTgyDQo+ID4+ID4gTW9iaWxlIG51bWJlciBzdGFydGluZyBKYW51YXJ5OiAg KzQ5IDE1MSAxMjA1NTc5MQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBhcm1kIG1haWxpbmcgbGlzdA0KPiA+IGFybWRAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FybWQNCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGRjIG1h aWxpbmcgbGlzdA0KPiA+IGRjQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kYw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBkYyBtYWlsaW5nIGxpc3QNCj4gZGNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYw0K From adalela@cisco.com Tue Dec 27 20:07:39 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DFF11E8073 for ; Tue, 27 Dec 2011 20:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9wxLjV-xXHl for ; Tue, 27 Dec 2011 20:07:37 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B31E21F84E5 for ; Tue, 27 Dec 2011 20:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=20922; q=dns/txt; s=iport; t=1325045256; x=1326254856; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6NzcQf3v1UE0y3kiDYEA0fDrZ8TqVcc6uwA18RuAtXk=; b=LcJ8wQuF215OgQhZtiMkRU+89f75m5Hf5hYhzBKNqnmX6gk69oY1I5Dz eu8P+fBxLKRbQ2HzbwRCnObeFyS9St1UAaHThLIJD5kb/6u2lsYOHnveE 5TblKuKPUBXyDkUQc8D1cy7JM2GkcvNO4To9bSsL6AygXiNC2wVkzzixJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAANOU+k5Io8UY/2dsb2JhbAA5BgOFD5ZcjzOCMoFyAQEBAwEBAQEPARANBDECAQMDCwUHBAIBBgIRBAEBAwIGBhcBAgICAQEfBh8JCAEBBAsICBMHh1gIlygBjFuRKYEvhygZggkzYwSINZc8h00 X-IronPort-AV: E=Sophos;i="4.71,418,1320624000"; d="scan'208";a="2440307" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 28 Dec 2011 04:07:34 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBS47YsI013666; Wed, 28 Dec 2011 04:07:34 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Dec 2011 09:37:34 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 28 Dec 2011 09:37:34 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102B25158@XMB-BGL-416.cisco.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9499@MX14A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] [armd] IP over IP solution for data center interconnect Thread-Index: AczEZWs1enlNW5A7QzOC/pHf9VF1TgAATylAAB0c3tAACjXooA== References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com><618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5102B25104@XMB-BGL-416.cisco.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9499@MX14A.corp.emc.com> From: "Ashish Dalela (adalela)" To: X-OriginalArrivalTime: 28 Dec 2011 04:07:34.0870 (UTC) FILETIME=[3A85C760:01CCC516] Cc: dc@ietf.org Subject: Re: [dc] [armd] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 04:07:39 -0000 RGF2aWQsDQoNClRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9uLiBTbywgaXQgaXMgcG9zc2libGUg dG8gcHVsbCBuZXR3b3JrIGFic3RyYWN0aW9ucyAoVkxBTiBldGMpIGludG8gdGhlIHN0b3JhZ2Ug Y29udHJvbGxlci4gVGhlIHNjaGVtZSBpcyBhbHNvIGV4dGVuc2libGUgdG8gb3RoZXIgdGhpbmdz IGxpa2UgVlhMQU4gb3IgTlZHUkUuIFRoZW4geW91IHRpZSB0aGUgZmlsZSBzeXN0ZW0gcGVybWlz c2lvbnMgdG8gdGhlIFZMQU4uIEFtIEkgcmVhZGluZyB0aGlzIGNvcnJlY3RseT8NCg0KVGhhbmtz LCBBc2hpc2gNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRhdmlkLmJsYWNr QGVtYy5jb20gW21haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tXSANClNlbnQ6IFdlZG5lc2RheSwg RGVjZW1iZXIgMjgsIDIwMTEgMjo1NiBBTQ0KVG86IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQpD YzogZGNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbZGNdIFthcm1kXSBJUCBvdmVyIElQIHNvbHV0 aW9uIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QNCg0KQXNoaXNoLA0KDQo+IEkgd291bGQg YmUgaW50ZXJlc3RlZCB0byBrbm93IGhvdyB0aGUgc3RvcmFnZSBtdWx0aS10ZW5hbmN5IHNvbHV0 aW9ucyBkZWFsIHdpdGggcHJpdmF0ZSBJUCwgTUFDIGFuZCBJRA0KPiBpbiB0aGUgcHVibGljIGRv bWFpbiwgd2hpY2ggY2FuIGJlIGR1cGxpY2F0ZWQuDQoNCkEgY29tbW9uIGN1cnJlbnQgdGVjaG5p cXVlIGlzIHRvIHVzZSBwZXItdGVuYW50IFZMQU5zIChhIHRlbmFudCBtYXkgaGF2ZSBtdWx0aXBs ZSBWTEFOcykgYW5kIHVzZSBOQVQgKGFzIG5lZWRlZCkgYmV0d2VlbiB0aGUgVkxBTnMgYW5kIHRo ZSBwdWJsaWMgSW50ZXJuZXQgaW4gb3JkZXIgdG8gc2VwYXJhdGUgVkxBTiBhZGRyZXNzaW5nIGZy b20gcHVibGljIEludGVybmV0IGFkZHJlc3NpbmcsIGVmZmVjdGl2ZWx5IHJlc3VsdGluZyBpbiBh ICh2aXJ0dWFsKSBOQVQgaW5zdGFuY2UgcGVyIFZMQU4uICBBIDEyLWJpdCBWTEFOIHRhZyBpcyBu b3QgbGFyZ2UgZW5vdWdoIHRvIHNjYWxlIHVwIHRvIHRoZSBkZXNpcmVkIGxhcmdlLXNjYWxlIGRh dGEgY2VudGVyIHNjb3BlLCBzbyBib3RoIFZ4TEFOIGFuZCBOVkdSRSB1c2UgYSAyNC1iaXQgdmly dHVhbCBuZXR3b3JrIGlkZW50aWZpZXIgdG8gcmVwbGFjZSB0aGUgMTItYml0IFZMQU4gdGFnOyBW eExBTiBjYWxscyB0aGlzIGEgVk5JIChWeExBTiBbb3IgVmlydHVhbF0gTmV0d29yayBJZGVudGlm aWVyKSwgYW5kIE5WR1JFIGNhbGxzIGl0IGEgVE5JIChUZW5hbnQgTmV0d29yayBJZGVudGlmaWVy KS4gIFZOSSBhbmQgVE5JIGVuY2FwL2RlY2FwIGNhbiBiZSBoYW5kbGVkIGJ5IHRoZSBoeXBlcnZp c29yIGFuZCBhcmUgbGltaXRlZCB0byB0aGUgZGF0YWNlbnRlcjsgaW4gdGhpcyBzdHJ1Y3R1cmUs IFZNcyBjYW4ndCB1c2UgYSBWTkkgb3IgVE5JIGRpcmVjdGx5LCBhbmQgdGhlICh2aXJ0dWFsKSBO QVQgaGFuZGxlcyBlbmNhcC9kZWNhcCBmb3IgaW5ib3VuZC9vdXRib3VuZCB0cmFmZmljIHNvIHRo YXQgdHJ5aW5nIHRvIHNlbmQgZW5jYXBzdWxhdGVkIChWeExBTiBvciBOR1JFKSB0cmFmZmljIGlu IGZyb20gdGhlIG91dHNpZGUgcmVzdWx0cyBpbiBkb3VibGUgZW5jYXBzdWxhdGlvbiB3aXRoIG5v IGVmZmVjdCBvbiB0ZW5hbnQgaXNvbGF0aW9uLg0KDQpCZWZvcmUgb25lIG9mIHRoZSBMMlZQTiBm b2xrcyBjb21lcyBhZnRlciBtZSBmb3IgdGhhdCAibGltaXRlZCB0byB0aGUgZGF0YWNlbnRlciIg Y29tbWVudCA7LSkgLi4uIGFuIEwyVlBOIGdhdGV3YXkgd291bGQgcHJvYmFibHkgdHJhbnNsYXRl IGJldHdlZW4gYSAyNC1iaXQgVk5JL1ROSSBhbmQgYSAyNC1iaXQgVlBOIElEIC0gZW5kLXRvLWVu ZCB1c2Ugb2YgYSBzaW5nbGUgaWRlbnRpZmllciBmb3IgdGhlIEwyVlBOIGFuZCB0aGUgdmlydHVh bCBuZXR3b3JrcyBvbiBib3RoIGVuZHMgaXMgcG9zc2libGUsIGJ1dCAoSU1ITykgZGlmZmljdWx0 IHdoZW4gdGhlcmUgYXJlIG11bHRpcGxlIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMgaW52b2x2ZWQg aW4gbWFuYWdpbmcgdGhlIGlkZW50aWZpZXJzLg0KDQpVc2Ugb2YgVkxBTnMgdG8gc2NvcGUgZmls ZXN5c3RlbSB2aXNpYmlsaXR5IG9uIE5BUyBmaWxlc2VydmVycyBpcyBhIGNvbW1vbiBkZXBsb3ll ZCBwcmFjdGljZSBpbiBkYXRhY2VudGVycyAoZGl0dG8gZm9yIFZMQU5zIHRvIGxpbWl0IGlTQ1NJ IHN0b3JhZ2UgdmlzaWJpbGl0eSksIHRoZXJlYnkgZGVhbGluZyB3aXRoIHRoZSBmb2xsb3dpbmc6 DQoNCj4gU28sIHlvdSBoYXZlIHRvDQo+IHByb3RlY3QgdGhlIG5ldHdvcmsgc3RvcmFnZSBmcm9t IG11bHRpcGxlIHRlbmFudHMgd2hvIGNhbiBoYXZlIHRoZSBzYW1lIElQIGFkZHJlc3MgYW5kIE1B QyBhZGRyZXNzLg0KPiBOQVMgYXNzdW1lcyB5b3VyIGlkIG9uIHRoZSBVTklYIGlzIGdsb2JhbGx5 IHVuaXF1ZSBhbmQgeW91ciBwZXJtaXNzaW9ucyBhcmUgdW5pcXVlIC0gbm90IHRydWUgYW55bW9y ZS4NCj4gU28sIHlvdSBoYXZlIElQLCBNQUMgYW5kIElEIGR1cGxpY2F0aW9uLg0KDQpEdXBsaWNh dGlvbiBvZiBJUCwgTUFDIGFuZCBJRCBvbiBzZXBhcmF0ZSBWTEFOcyB3b3JrcyBmaW5lIC0gdGhp cyBtb2RlbCBpcyBjYXJyaWVkIG92ZXIgdG8gdmlydHVhbCBuZXR3b3JrcyBiYXNlZCBvbiBWTkkg b3IgVE5JLiAgVGhlIHNlbnRlbmNlIGNvbnRhaW5pbmcgImdsb2JhbGx5IHVuaXF1ZSIgKGluY29y cmVjdGx5KSBhc3N1bWVzIGEgc2luZ2xlIGZpbGVzZXJ2ZXI7IGluc3RlYWQsIGNvbnNpZGVyIGEg c2luZ2xlIE5BUyBzeXN0ZW0gcHJlc2VudGluZyB3aGF0IGlzIGVmZmVjdGl2ZWx5IGEgdmlydHVh bCBmaWxlc2VydmVyIHBlciBWTEFOIChvciBWTkkvVE5JKSBhbmQgc2ltaWxhcmx5IGZvciBpU0NT SSAtIHRoYXQgaXMgd2hhdCBzb3J0cyBvdXQgdGhpcyBkdXBsaWNhdGlvbiwgaW5jbHVkaW5nIHVz ZSBvZiBkaWZmZXJlbnQgaWRlbnRpdHkgc2VydmljZXMvc2VydmVzIHBlciBWTEFOIChvciBWTkkv VE5JKS4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGF2aWQgTC4gQmxhY2ssIERpc3Rpbmd1aXNoZWQgRW5n aW5lZXINCkVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0LiwgSG9wa2ludG9uLCBNQcKgIDAx NzQ4DQorMSAoNTA4KSAyOTMtNzk1M8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBGQVg6ICsxICg1 MDgpIDI5My03Nzg2DQpkYXZpZC5ibGFja0BlbWMuY29twqDCoMKgwqDCoMKgwqAgTW9iaWxlOiAr MSAoOTc4KSAzOTQtNzc1NA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRj LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkNCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjcs IDIwMTEgMjo1MCBBTQ0KPiBUbzogUGVkcm8gTWFycXVlcw0KPiBDYzogZGNAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtkY10gW2FybWRdIElQIG92ZXIgSVAgc29sdXRpb24gZm9yIGRhdGEgY2Vu dGVyIGludGVyY29ubmVjdA0KPiANCj4gVGhlcmUgaXMgSW5maW5pQmFuZCBiZXNpZGVzIEZpYmVy Q2hhbm5lbC4gQW5kIHdlIGFyZSB0YWxraW5nIGFib3V0IGNvbnZlcmdpbmcgbm90IHNlcGFyYXRp bmcgdGhlbS4gVGhlDQo+IHF1ZXN0aW9uIGlzIGNvbnZlcmdlIG92ZXIgTDIgb3IgTDMuIEkgdGhp bmsgeW91IGRpZCBub3QgcmVhZCBtZSBjb3JyZWN0bHkuIElQIGJhc2VkIHNvbHV0aW9ucyBoYXZl DQo+IGJlZW4gZGVmaW5lZCBiZWZvcmUgRXRoZXJuZXQgc29sdXRpb25zIGJ1dCBub3QgdXNlZCB3 aWRlbHkuIFdlIGNhbiBkaXNjdXNzIHdoeS4NCj4gDQo+IEkgd291bGQgYmUgaW50ZXJlc3RlZCB0 byBrbm93IGhvdyB0aGUgc3RvcmFnZSBtdWx0aS10ZW5hbmN5IHNvbHV0aW9ucyBkZWFsIHdpdGgg cHJpdmF0ZSBJUCwgTUFDIGFuZCBJRA0KPiBpbiB0aGUgcHVibGljIGRvbWFpbiwgd2hpY2ggY2Fu IGJlIGR1cGxpY2F0ZWQuDQo+IA0KPiBUaGUgYXJndW1lbnQgd2FzIG5vdCBhcm91bmQgbG9hZC1i YWxhbmNpbmcsIGl0IGlzIGFyb3VuZCBkaXNjb3ZlcnkuDQo+IA0KPiBZb3VyIGV4YW1wbGUgb2Yg dGhlIGh5cGVydmlzb3IgaXMgaW50ZXJlc3RpbmcuIEknbSBhd2FyZSB0aGF0IEFtYXpvbiBkb2Vz IHRoaW5ncyBpbiB0aGUgaHlwZXJ2aXNvci4NCj4gVGhleSBwcm92aWRlIElQIG1vYmlsaXR5IHRo cm91Z2ggTkFULiBTZWN1cml0eSB0aHJvdWdoIGEgaHlwZXJ2aXNvciBmaXJld2FsbC4gVGhlIGNv bnNlcXVlbmNlIGlzIHRoYXQNCj4geW91IHBheSBleHRyYSBpZiB5b3Ugd2FudGVkIGEgbW9iaWxl IFZNLCBhbmQgeW91IG1hbmFnZSB5b3VyIG93biBmaXJld2FsbCAoYXQgbGVhc3QgdGhlIGxhc3Qg dGltZSBJDQo+IGNoZWNrZWQpLiBJZiB0ZW5hbnQgaXNvbGF0aW9uIGlzIGFsbCB0aGUgd2F5IGlu dG8gdGhlIGhvc3QsIHRoZW4gbmV0d29yayBRb1MsIGJhbmR3aWR0aCBldGMgaXMgYWxzbw0KPiBt b290Lg0KPiANCj4gVGhhbmtzLCBBc2hpc2gNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBQZWRybyBNYXJxdWVzIFttYWlsdG86cGVkcm8uci5tYXJxdWVzQGdt YWlsLmNvbV0NCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjcsIDIwMTEgMTI6MzIgUE0NCj4g VG86IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQo+IENjOiBkY0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW2RjXSBbYXJtZF0gSVAgb3ZlciBJUCBzb2x1dGlvbiBmb3IgZGF0YSBjZW50ZXIgaW50 ZXJjb25uZWN0DQo+IA0KPiAyMDExLzEyLzI2IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpIDxhZGFs ZWxhQGNpc2NvLmNvbT46DQo+ID4gRm9yIGFsbCB0aGUgcHJvcG9uZW50cyBvZiBMMywgaGVyZSBp cyBhIHRob3VnaHQuDQo+IA0KPiBzdW1tYXJ5IG9mIHRoZSBvcmlnaW5hbCBlbWFpbDogbXVsdGkt dGVuYW50IHN0b3JhZ2Ugc29sdXRpb25zIHJlcXVpcmUNCj4gRmliZXJDaGFubmVsOyBhbiBMMyBz ZXJ2aWNlIG1vZGVsIGRvZXNuJ3Qgc3VwcG9ydCBGaWJlckNoYW5uZWwuDQo+IA0KPiBUaGVyZSBh cmUgbXVsdGlwbGUgc3RvcmFnZSBzb2x1dGlvbnMgdGhhdCBzdXBwb3J0IG11bHRpLXRlbmFuY3kg dGhhdA0KPiB3b3JrIG9uIHRvcCBvZiBJUCBtYWtpbmcgdGhlIGFyZ3VtZW50IG1vb3QgKDEpLiBB dCBsYXJnZSBzY2FsZSBydW5uaW5nDQo+IGEgc2VwYXJhdGUgbmV0d29yayBmb3IgZGF0YSBhbmQg Zm9yIHN0b3JhZ2UgaW1wb3NlcyB2ZXJ5IHNpZ25pZmljYW50DQo+IGNvc3RzLiBJJ2QgdmVudHVy ZSB0aGF0IHRoZSBwcm9wb25lbnRzIG9mIEwzIGhhdmUgdmVyeSBsaXR0bGUgaW50ZXJlc3QNCj4g aW4gRmliZXJDaGFubmVsLg0KPiANCj4gVGhlIHNhbWUgZ29lcyBmb3IgdGhlIGFyZ3VtZW50IHRo YXQgbG9hZC1iYWxhbmNpbmcgcmVxdWlyZXMgTDIuIFRoZXJlDQo+IGlzIGV4aXN0ZW5jZSBwcm9v ZiBvZiB0aGUgY29udHJhcnkuDQo+IA0KPiBUaGVyZSBpcyBhIHdpZGUgcmFuZ2Ugb2YgdGVjaG5v bG9neSBjaG9pY2VzIGF2YWlsYWJsZSBpbiB0aGlzIHNwYWNlLg0KPiBJJ20gc3VyZSB0aGVyZSBp cyBpbnRlcmVzdCBpbiBMMiBiYXNlZCBzb2x1dGlvbnMgYnV0IHRoZSBjbGFpbSB0aGF0IEwzDQo+ IGJhc2VkIHNvbHV0aW9ucyBhcmUgbm90IGZlYXNpYmxlIGhhcyBhbHJlYWR5IGJlZW4gZGlzcHJv dmVkIGJ5DQo+IGRlcGxveWVkIHNvbHV0aW9ucy4NCj4gDQo+IDEgLSBFeGFtcGxlOiBXaGVuIGEg c3RvcmFnZSBzb2x1dGlvbiBwcmVzZW50cyBhIGJsb2NrIGRldmljZSB0byB0aGUgVk0NCj4gKGUu Zy4gQW1hem9uIEVCUykgaXQgaXMgdGhlIGhvc3QgT1MvaHlwZXJ2aXNvciB0aGF0IG1hcHMgdGhl IGd1ZXN0IE9TDQo+IG9wZXJhdGlvbnMgaW50byBuZXR3b3JrIG9wZXJhdGlvbnM7IGRvaW5nIHNv IGluIHRoZSBpbmZyYXN0cnVjdHVyZQ0KPiBuZXR3b3JrIHJlYWwgcmF0aGVyIHRoYW4gaW4gdGhl IHRlbmFudCdzIG5ldHdvcmsgcmVhbG0uDQo+IA0KPiA+DQo+ID4gVGhlIGJpZ2dlc3QgY29uY2Vy biBpbiBjbG91ZCBpcyBkYXRhIHByb3RlY3Rpb24uIFRoYXQgaXMganVzdCBtYWtlIG9yIGJyZWFr LiBEYXRhIGNhbid0IG1vdmUgd2hlbg0KPiB0aGUgVk0gbW92ZXMuIEl0J3MganVzdCB0b28gZXhw ZW5zaXZlIGFuZCB0aW1lIGNvbnN1bWluZy4gRnVydGhlciwgdG8gcmVkdWNlIGRpc2sgd2FzdGFn ZSB5b3UgaGF2ZSB0bw0KPiBwdXQgZGF0YSBvbiBuZXR3b3JrIHN0b3JhZ2UuIFRoYXQncyBqdXN0 IGVhc3kgZm9yIGRhdGEgYmFja3VwLCBhbmQgY2hlYXAgaW4gdGVybXMgb2YgdG90YWwgZGlzayBz cGFjZQ0KPiB5b3UgbmVlZC4gVGhlcmUgaXMgYSBsb3QgZ29pbmcgb24gaGVyZSBpbiB0ZXJtcyBv ZiBkYXRhIGRlLWR1cGxpY2F0aW9uLg0KPiA+DQo+ID4gTm93IGdpdmVuIG5ldHdvcmsgc3RvcmFn ZSwgeW91IGhhdmUgdHdvIG9wdGlvbnMgLSBOQVMgYW5kIFNBTi4NCj4gPg0KPiA+IE9uIHRoZSBj bG91ZCBlYWNoIFZNIGFkbWluaXN0cmF0b3IgaGFzIHJvb3QgcHJpdmlsZWdlcy4gQW5kIElQIGFu ZCBNQUMgYWRkcmVzc2VzIGNhbiBiZSBkdXBsaWNhdGVkDQo+IChpZiB5b3UgYXJlIHJvb3QganVz dCBjb25maWd1cmUgYW55IElQIGFuZCBNQUMgb24gYSB2aXJ0dWFsIGludGVyZmFjZSBvZiBjaG9p Y2UpLiBTbywgeW91IGhhdmUgdG8NCj4gcHJvdGVjdCB0aGUgbmV0d29yayBzdG9yYWdlIGZyb20g bXVsdGlwbGUgdGVuYW50cyB3aG8gY2FuIGhhdmUgdGhlIHNhbWUgSVAgYWRkcmVzcyBhbmQgTUFD IGFkZHJlc3MuDQo+IE5BUyBhc3N1bWVzIHlvdXIgaWQgb24gdGhlIFVOSVggaXMgZ2xvYmFsbHkg dW5pcXVlIGFuZCB5b3VyIHBlcm1pc3Npb25zIGFyZSB1bmlxdWUgLSBub3QgdHJ1ZSBhbnltb3Jl Lg0KPiBTbywgeW91IGhhdmUgSVAsIE1BQyBhbmQgSUQgZHVwbGljYXRpb24uDQo+ID4NCj4gPiBU aGF0IG1lYW5zIHRoYXQgaWYgeW91IGhhdmUgdG8gcHJvdGVjdCBkYXRhLCB5b3UgaGF2ZSB0byBr bm93IHNvbWVob3cgd2hpY2ggaG9zdCBpcyBhbGxvd2VkIHRvIHNlZQ0KPiB3aGljaCBkaXNrcy4g RG9pbmcgdGhpcyBlbmQtdG8tZW5kIHVzaW5nIFRDUC9JUCBpcyBwcm9ibGVtYXRpYyBiZWNhdXNl IHRoZSBOQVMgY29udHJvbGxlciBkb2Vzbid0IGtub3cNCj4gYWJvdXQgdGVuYW50IGlkLCBhbmQg d2hldGhlciB0aGUgTUFDIGFuZCBJUCBhcmUgYmVpbmcgZHVwbGljYXRlZCBhY3Jvc3MgY3VzdG9t ZXJzLiBUbyBtYWtlIHRoZSBzdG9yYWdlDQo+IGF3YXJlIG9mIHNlZ21lbnRhdGlvbiwgeW91IGhh dmUgdG8gY2Fycnkgc29tZSBzZWdtZW50IChHUkUsIE1QTFMsIFZMQU4sIGV0Yy4pIGludG8gdGhl IHN0b3JhZ2UgYm94Lg0KPiBUaGF0J3Mgbm90IHRydWUgdG9kYXkuDQo+ID4NCj4gPiBOZXR3b3Jr IGxldmVsIGlzb2xhdGlvbiBoYXBwZW5zIGluIFNBTiwgYnV0IG5vdCBpbiBOQVMuIE5BUyBqdXN0 IHJ1bnMgZW5kLXRvLWVuZCBvdmVyIFRDUC4gSW4gU0FODQo+IHlvdSBjYW4gc2F5IHdoaWNoIGhv c3Qgd2lsbCBzZWUgd2hpY2ggZGlzay4gVGhlIEZDIHNlY3VyaXR5IGlzIGhpZ2ggYmVjYXVzZSBN QUMgYW5kIEZDLUlEIGlzIGFzc2lnbmVkDQo+IGJ5IHRoZSBuZXR3b3JrIGFuZCBub3QgaW4gdGhl IGNvbnRyb2wgb2YgdGhlIGhvc3QuIFRoZSBuZXR3b3JrIGtub3dzIHdoaWNoIHBvcnQgaXMgd2hp Y2ggaG9zdC9NQUMuIFNvLA0KPiBpZiB5b3Ugb25seSBrbm93IHdoaWNoIHBvcnQgaXMgd2hpY2gg Y3VzdG9tZXIsIHlvdSBrbm93IHdoaWNoIE1BQyBjYW4gc2VlIHdoaWNoIGRpc2suIEJpbmRpbmcg YSBwb3J0DQo+IHRvIGEgY3VzdG9tZXIgaXMgbm90IGhhcmQuIEJ1dCBtYXBwaW5nIGFsbCBvZiB0 aGF0IHRvIGRhdGEgc2VjdXJpdHkgYW5kIGRpc2sgdmlzaWJpbGl0eSBpcyBub3QNCj4gdHJpdmlh bC4gRS5nLiB5b3UgaGF2ZSB0byBkbyBHUkUgdHVubmVsIG1hcHBpbmcgdG8gYSBzZXQgb2YgZGlz ayBwZXJtaXNzaW9ucy4gV2hvIG5lZWRzIHRoYXQ/DQo+ID4NCj4gPiBTQU4gZG9lcyBub3QgdXNl IElQLiBJdCB1c2VzIEZpYmVyIENoYW5uZWwuIFdpdGggY29udmVyZ2VuY2UsIHdlIGFyZSBtb3Zp bmcgdG8gRkMgb3ZlciBFdGhlcm5ldA0KPiAoRkNvRSkuIEZDSVAgYW5kIGlTQ1NJIGhhdmUgbm90 IHdvcmtlZCB2ZXJ5IHdlbGwuIFNlY3VyaXR5IGZvciBkYXRhIGNvbWVzIGZyb20gRkMgYW5kIGxv d2VyaW5nIG9mIGNvc3QNCj4gY29tZXMgZnJvbSB1c2Ugb2YgRkNvRS4gVGhhdCBuZWVkcyBuYXRp dmUgRXRoZXJuZXQgKG5vIElQKS4NCj4gPg0KPiA+IFdoZW4geW91IGhhdmUgc2l0ZS10by1zaXRl IFZNIG1vYmlsaXR5LCBkYXRhIGlzIG5vdCBtb3ZpbmcgYWNyb3NzIHNpdGVzLiBFLmcuIGFuIGFw cGxpY2F0aW9uIHNlcnZlcg0KPiB3aWxsIGNvbm5lY3QgdG8gYSBzZXQgb2YgbG9hZC1iYWxhbmNl ZCBzZXQgb2YgZGF0YWJhc2Ugc2VydmVycyB3aXRoaW4gYSBWTEFOLiBUaGUgYXBwbGljYXRpb24g YW5kDQo+IGRhdGFiYXNlIHNlcnZlcnMgY2FuIGJlIGRpZmZlcmVudCBzaXRlcywgYW5kIHRoZXkg Y29ubmVjdCBvdmVyIGEgVkxBTi4gQWx0ZXJuYXRlbHksIHRoZSBhcHBsaWNhdGlvbg0KPiBhbmQg ZGF0YWJhc2Ugc2VydmVycyBjYW4gYmUgaW4gdGhlIHNhbWUgbG9jYXRpb24gYW5kIHRoZSBEQiBz ZXJ2ZXIgYWNjZXNzZXMgdGhlIFNBTiBvdmVyIHRoZSBJbnRlcm5ldC4NCj4gRXZlbiBpZiBkYXRh IGlzIHJlcGxpY2F0ZWQgYWNyb3NzIG1hbnkgc2l0ZXMsIGxvYWQtYmFsYW5jaW5nIGFjcm9zcyBh cHBsaWNhdGlvbiBvciBkYiBzZXJ2ZXJzIHVzZXMNCj4gVkxBTnMuIEluIEhQQyBhcyB3ZWxsLCB0 aGVyZSBpcyBhIGxvdCBvZiBicm9hZGNhc3QgYW5kIGRpc2NvdmVyeSwgYW5kIHRoaXMgbWF5IHVz ZSBJUCBvciBub3QsIHRoZSBmYWN0DQo+IGlzIHRoYXQgaXQgZGVwZW5kcyBvbiBicm9hZGNhc3Qu IFRoZSBIUEMgY2FzZSBleHRlcm5hbGl6ZXMgdGhlIG1lbW9yeSBvbiBhIGhvc3QgdG8gb3RoZXIg aG9zdHMgdGhyb3VnaA0KPiBSRE1BLiBFdmVyeXRoaW5nIHRvIGRvIHdpdGggQmlnIERhdGEgd2ls bCByZWx5IG9uIHRoaXMsIGFuZCBiZXNpZGVzIGRpc2sgZXh0ZXJuYWxpemF0aW9uIHdlIHdpbGwg YWxzbw0KPiBzZWUgaW5jcmVhc2UgaW4gbWVtb3J5IGV4dGVybmFsaXphdGlvbi4gSSBqdXN0IHdl bnQgdG8gYSBJRUVFIEhQQyBjbG91ZCBjb25mZXJlbmNlIDotKQ0KPiA+DQo+ID4gTDMgYXNzdW1l cyB0aGF0IGFsbCBkYXRhIChkaXNrIGFuZCBtZW1vcnkpIGlzIGluc2lkZSB0aGUgaG9zdC4gVGhh dCBhc3N1bXB0aW9uIGNoYW5nZWQgYSBkZWNhZGUgYWdvLg0KPiBDbG91ZCBqdXN0IGluY3JlYXNl cyB0aGUgZGlzdHJpYnV0aW9uLiBKdXN0IGFzIGNvbXB1dGUgaXMgb3B0aW1pemVkIGJ5IG11eGlu ZyB0aGUgVk1zIG9uIGEgcGh5c2ljYWwNCj4gbWFjaGluZSwgc3RvcmFnZSBpcyBvcHRpbWl6ZWQg YnkgY29uc29saWRhdGluZyBkYXRhIHNlcGFyYXRlbHkgb24gc3RvcmFnZSBkZXZpY2VzIGFuZCBt ZW1vcnkgYnkNCj4gaG9zdGluZyBpdCBpbiBkaWZmZXJlbnQgaG9zdHMuIE5ldHdvcmsgaGFzIHRv IGRlYWwgd2l0aCBhbGwgdHlwZXMgb2YgdHJhZmZpYyBhbmQgc2VjdXJpdHkvaXNvbGF0aW9uDQo+ IChpbWFnaW5lIHNvbWVvbmUgY2hhbmdpbmcgbWVtb3J5IG92ZXIgdGhlIG5ldHdvcmspLiBTdG9y YWdlIGFuZCBtZW1vcnkgdHJhZmZpYyB1c2VzIEwyLiBUbyBkaXNjb3Zlcg0KPiBlYWNoIG90aGVy LCBob3N0cyB1c2UgTDIuIFRoZXNlIEwyIGRvbWFpbnMgbmVlZCB0byBzcGFuIGFjcm9zcyBzaXRl cyBhbmQgd2l0aGluIHRoZSBzaXRlLg0KPiA+DQo+ID4gVGhpcyBhcmUgbm90IGNvcm5lciBjYXNl cy4gVGhpcyBpcyBqdXN0IGNlbnRyYWwgdG8gd2hhdCBjbG91ZCBtZWFucyBpbiB0aGUgbG9uZyBy dW4uDQo+ID4NCj4gPiBUaGFua3MsIEFzaGlzaA0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGFybWQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFy bWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQo+ID4gU2VudDogRnJp ZGF5LCBEZWNlbWJlciAyMywgMjAxMSAxMjowOSBQTQ0KPiA+IFRvOiBFZ2dlcnQsIExhcnM7IGRj QGlldGYub3JnOyBkY3JnLWludGVyZXN0QGlydGYub3JnDQo+ID4gQ2M6IGFybWRAaWV0Zi5vcmcN Cj4gPiBTdWJqZWN0OiBSZTogW2FybWRdIElQIG92ZXIgSVAgc29sdXRpb24gZm9yIGRhdGEgY2Vu dGVyIGludGVyY29ubmVjdA0KPiA+DQo+ID4NCj4gPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K PiA+PiDlj5Hku7bkuro6IFh1eGlhb2h1DQo+ID4+IOWPkemAgeaXtumXtDogMjAxMeW5tDEy5pyI MjLml6UgMTY6MjgNCj4gPj4g5pS25Lu25Lq6OiAnRWdnZXJ0LCBMYXJzJzsgZGNAaWV0Zi5vcmc7 ICdkY3JnLWludGVyZXN0QGlydGYub3JnLicNCj4gPj4g5Li76aKYOiBJUCBvdmVyIElQIHNvbHV0 aW9uIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QNCj4gPj4NCj4gPj4gSGkgYWxsLA0KPiA+ Pg0KPiA+PiBUaGVyZSBoYXMgYmVlbiBhIGxvdCBvZiBMMiBvdmVyIEwzIHNvbHV0aW9ucyBvciBw cm9wb3NhbHMgZm9yIGRhdGEgY2VudGVyDQo+ID4+IG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyIGlu dGVyY29ubmVjdCB0aWxsIG5vdy4gSG93ZXZlciwgaXQgc2VlbXMgcmVjZW50bHkNCj4gPj4gdGhl cmUgYXJlIGluY3JlYXNpbmcgaW50ZXJlc3RzIG9uIEwzIG92ZXIgTDMgKGUuZy4sIElQIG92ZXIg SVApIHNvbHV0aW9ucyBmb3IgZGF0YQ0KPiA+PiBjZW50ZXIgbmV0d29yayBhbmQgZGF0YSBjZW50 ZXIgaW50ZXJjb25uZWN0LCBwbGVhc2Ugc2VlIHRoZSBmb2xsb3dpbmcgdGV4dA0KPiA+PiBxdW90 ZWQgZnJvbSBJRVRGODIgTDJWUE4gbWludXRlcw0KPiA+PiAoIGh0dHBzOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzgyL21pbnV0ZXMvbDJ2cG4udHh0KS4gSXQncyBhIGdlbmVyYWwgYmVsaWVm DQo+ID4+IHRoYXQgTDMgaXMgbW9yZSBzY2FsYWJsZSB0aGFuIEwyLiBFc3BlY2lhbGx5IHdoZW4g Y29uc2lkZXJpbmcgdGhlIGRhdGEgY2VudGVyDQo+ID4+IGludGVyY29ubmVjdGlvbiBjYXNlLCB0 aGUgTDMgb3ZlciBMMyBzb2x1dGlvbnMgY2FuIGJyaW5nIERDIG9wZXJhdG9ycyBtb3JlDQo+ID4+ IGJlbmVmaXRzIGNvbXBhcmVkIHRvIHRoZSBMMiBvdmVyIEwzIHNvbHV0aW9ucywgc3VjaCBhcyBw YXRoIG9wdGltaXphdGlvbiwNCj4gPj4gYWN0aXZlLWFjdGl2ZSBkYXRhIGNlbnRlcnMsIE1BQyB0 YWJsZSByZWR1Y3Rpb24gb24gREMgc3dpdGNoZXMgYW5kIGJyb2FkY2FzdA0KPiA+PiBmbG9vZCBz dXBwcmVzc2lvbiBldGMgLg0KPiA+DQo+ID4gQnkgdGhlIHdheSwgdGhlIEFSUCB0YWJsZSBzY2Fs aW5nIGlzc3VlIG9uIERDIGdhdGV3YXlzLCB3aGljaCBpcyBkZWVtZWQgYnkgdGhlIEFSTUQgV0cg YXMgdGhlIG9ubHkNCj4gd29ydGh5IEFSUCBwcm9ibGVtIGluIGRhdGEgY2VudGVyIG5ldHdvcmtz LCBjb3VsZCBhbHNvIGJlIHNvbHZlZCB3aXRoIHRoZSBJUCBvdmVyIElQIHNvbHV0aW9uLg0KPiA+ DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4+DQo+ID4+IEFsdGhvdWdo IExheWVyIDIgY29ubmVjdGl2aXR5IGlzIHN0aWxsIHJlcXVpcmVkIGZvciBzb21lIGhpZ2gtYXZh aWxhYmlsaXR5IGNsdXN0ZXJzDQo+ID4+IHdoaWNoIHVzZSBub24tSVAgYW5kIGxpbmstbG9jYWwg bXVsdGljYXN0IGZvciBjb21tdW5pY2F0aW9uLCBtb3JlIGFuZCBtb3JlDQo+ID4+IGNsdXN0ZXIg dmVuZG9ycyBhcmUgZWl0aGVyIGFscmVhZHkgYWJsZSB0byBzdXBwb3J0IGNsdXN0ZXIgc2Vydmlj ZXMgYXQgTGF5ZXIzIG9yDQo+ID4+IHdpbGwgc3VwcG9ydCBpdCBpbiB0aGUgbmVhciBmdXR1cmUu IEluIGFkZGl0aW9uLCB0aGUgR1NMQiBtZWNoYW5pc20gKGUuZy4sIEROUw0KPiA+PiBiYXNlZCBH U0xCKSB3b3JrcyB2ZXJ5IHdlbGwgaW4gbW9zdCBjYXNlcywgaXMgZ2VvLWNsdXN0ZXIgc2Vydmlj ZSBzdGlsbCBhDQo+ID4+IGNvbW1vbiByZXF1aXJlbWVudCBmb3IgZGF0YSBjZW50ZXIgaW50ZXJj b25uZWN0PyBJZiBub3QsIGNvdWxkIHdlIHNwZW5kIGFueQ0KPiA+PiB0aW1lIG9uIGV4cGxvcmlu ZyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgTDMgb3ZlciBMMyBzb2x1dGlvbiBmb3IgdGhlIG1v c3QgZGF0YQ0KPiA+PiBjZW50ZXIgaW50ZXJjb25uZWN0aW9uIHNjZW5hcmlvcyB3aGVyZSBnZW8t Y2x1c3RlcmluZywgZXNwZWNpYWxseSBub24tSVAgYmFzZWQNCj4gPj4gZ2VvLWNsdXN0ZXJpbmcg aXMgbm90IG5lZWRlZD8NCj4gPj4NCj4gPj4gQmVzdCByZWdhcmRzLA0KPiA+PiBYaWFvaHUNCj4g Pj4NCj4gPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KPiA+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4+IEtpcmVldGk6IEkga2VlcCBzZWVpbmcgSVNJ RCwgUEJCLCBWTEFOcy4gIFdlIGhhdmUgdG8gc3RvcCBjb25jZWRpbmcgdG8gbGF5ZXIgMg0KPiA+ PiBhbmQgc3RhcnQgbW92aW5nIHRvIGxheWVyIDMgKGFwcGxhdXNlKSBhbmQgbG90cyBvZiBwcm9i bGVtcyB3aWxsIGdvIGF3YXkuDQo+ID4+DQo+ID4+IEZsb3JpbjogV2Ugc2hvdWxkIHB1dCBWUE4g b24gdGhlIHNhbWUgcGFnZSB0byBtb2RpZnkgdGhlIHByaW9yaXRpZXMuIFlvdSBuZWVkDQo+ID4+ IHRvIGV4cGFuZCBzbyBjYW4gbG9vayBhdCBMMyBvdmVyIEwzIGFzIHdlbGwgYXMgTDIgb3ZlciBM My4gRm9yIGl0ZW0gbnVtYmVyIDIgd2UNCj4gPj4gbmVlZCB0byBsb29rIGF0IEwzIHRyYW5zcG9y dCBhcyB3ZWxsIGFzIEV0aGVybmV0IGFuZCBNUExTLiAgQW5kIGZvciBudW1iZXIgMw0KPiA+PiB3 ZSBuZWVkIHRvIHdvcmsgb24gdGhpcyBhcyB0aGVyZSdzIGEgbG90IG9mIGV4cGVydGlzZSBpbiBM MiwgTDMgYW5kIG90aGVyIFdHcy4NCj4gPj4NCj4gPj4NCj4gPj4gTWFyYzogVGhlIHByb2JsZW0g c3RhdGVtZW50IG5lZWRzIHRvIGluY2x1ZGUgbW9yZSBvZiB0aGUgTDMgaXNzdWVzIGFyb3VuZA0K PiA+PiBzZW5kaW5nIEwyIG92ZXIgTDMsIGFzIHRoZSBMMiB0cmFmZmljIGFscmVhZHkgY29udGFp bnMgTDMuICBJc3N1ZSBpcyBqdXN0IGZyYW1pbmcuDQo+ID4+DQo+ID4+IEVyaWMgTm9yZG1hcms7 ICJZZXMsIFllcyBhbmQgWWVzIi4gIFdlIG5lZWQgdG8gZm9jdXMgZnJvbSB0aGUgREMgcHJvc3Bl Y3RpdmUNCj4gPj4gYW5kIG5vdCBmcm9tIHRoZSBWUE4gdmlldy4gIGRvbid0IGp1c3QgdGhpbmsg YWJvdXQgRXRoZXJuZXQgb3ZlciBJUCwgYnV0IGFsc28gSVANCj4gPj4gb3ZlciBJUC4gIEh5cGVy dmlzb3IgbWF5IGdldCBkZWNvdXBsZWQgb3ZlciB0aW1lLg0KPiA+PiAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4+ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cj4gPj4gPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+ID4g5Y+R5Lu25Lq6OiBkYy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEVnZ2VydCwN Cj4gPj4gTGFycw0KPiA+PiA+IOWPkemAgeaXtumXtDogMjAxMeW5tDEy5pyIMTbml6UgMTY6MjQN Cj4gPj4gPiDmlLbku7bkuro6IGRjQGlldGYub3JnDQo+ID4+ID4g5Li76aKYOiBbZGNdIElSVEYg ZGF0YWNlbnRlciByZXNlYXJjaCBncm91cCBkaXNjdXNzaW9uIGxpc3QNCj4gPj4gPg0KPiA+PiA+ IEhpLA0KPiA+PiA+DQo+ID4+ID4gSSB3YW50ZWQgdG8gbWFrZSB5b3UgYWxsIGF3YXJlIG9mIHRo ZSBJUlRGJ3MgZGNyZy1pbnRlcmVzdCBtYWlsaW5nIGxpc3QsIHdoaWNoDQo+ID4+ID4gd2FzIHNl dCB1cCBmb2xsb3dpbmcgYSBmYWNlLXRvLWZhY2UgbWVldGluZyBhdCBTSUdDT01NIHRoaXMgeWVh ciB0byBkaXNjdXNzDQo+ID4+IGENCj4gPj4gPiBwb3NzaWJsZSBJUlRGIHJlc2VhcmNoIGdyb3Vw IG9uIGRhdGFjZW50ZXIgbmV0d29ya2luZzoNCj4gPj4gPiBodHRwOi8vaXJ0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kY3JnLWludGVyZXN0DQo+ID4+ID4NCj4gPj4gPiBUaGVyZSBoYXMgbm90IGJl ZW4gbXVjaCBhY3Rpdml0eSB0b3dhcmRzIHRoZSBmb3JtYXRpb24gb2YgYW4gSVJURiBSRyBzaW5j ZQ0KPiA+PiA+IFNJR0NPTU0sIGJ1dCBJIGFtIGhvcGVmdWwgdGhhdCB0aGUgaGlnaCBlbmVyZ3kg bGV2ZWwgZGVtb25zdHJhdGVkIGluIHRoZQ0KPiA+PiA+IHZhcmlvdXMgVGFpcGVpIG1lZXRpbmdz IG9uIHRoZSB0b3BpYyB3aWxsIGluamVjdCBzb21lIGVuZXJneSBoZXJlIC0gc2V2ZXJhbCBvZg0K PiA+PiA+IHRoZSB0b3BpY3MgdGhhdCBtYXkgYmUgdG9vIGVhcmx5IGZvciB0aGUgSUVURiB0byBz dGFuZGFyZGl6ZSBhcm91bmQgd291bGQgZml0DQo+ID4+IGFuDQo+ID4+ID4gSVJURiBSRyB2ZXJ5 IHdlbGwuIEknbSBjZXJ0YWlubHkgc3VwcG9ydGl2ZSBvZiB0aGlzLg0KPiA+PiA+DQo+ID4+ID4g TGFycw0KPiA+PiA+IElSVEYgQ2hhaXINCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gLS0NCj4gPj4g PiBNb2JpbGUgbnVtYmVyIGR1cmluZyBEZWNlbWJlcjogICAgKzM1OCA0NiA1MjE1NTgyDQo+ID4+ ID4gTW9iaWxlIG51bWJlciBzdGFydGluZyBKYW51YXJ5OiAgKzQ5IDE1MSAxMjA1NTc5MQ0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBhcm1kIG1haWxpbmcgbGlzdA0KPiA+IGFybWRAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FybWQNCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGRjIG1haWxpbmcgbGlzdA0KPiA+IGRjQGll dGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYw0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkYyBtYWls aW5nIGxpc3QNCj4gZGNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kYw0K From david.black@emc.com Tue Dec 27 20:29:19 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE93621F8AF0 for ; Tue, 27 Dec 2011 20:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM9H8n0duCLg for ; Tue, 27 Dec 2011 20:29:18 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2A24E11E8081 for ; Tue, 27 Dec 2011 20:29:17 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pBS4TEwj011227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Dec 2011 23:29:15 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 27 Dec 2011 23:28:57 -0500 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pBS4SvrV026977; Tue, 27 Dec 2011 23:28:57 -0500 Received: from mx14a.corp.emc.com ([169.254.1.216]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Tue, 27 Dec 2011 23:28:56 -0500 From: To: Date: Tue, 27 Dec 2011 23:28:54 -0500 Thread-Topic: [dc] [armd] IP over IP solution for data center interconnect Thread-Index: AczEZWs1enlNW5A7QzOC/pHf9VF1TgAATylAAB0c3tAACjXooAAEnqNw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94CB@MX14A.corp.emc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com><618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5102B25104@XMB-BGL-416.cisco.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9499@MX14A.corp.emc.com> <618BE8B40039924EB9AED233D4A09C5102B25158@XMB-BGL-416.cisco.com> In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102B25158@XMB-BGL-416.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: dc@ietf.org Subject: Re: [dc] [armd] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 04:29:20 -0000 QXNoaXNoLA0KDQo+IFRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9uLiBTbywgaXQgaXMgcG9zc2li bGUgdG8gcHVsbCBuZXR3b3JrIGFic3RyYWN0aW9ucyAoVkxBTiBldGMpIGludG8gdGhlDQo+IHN0 b3JhZ2UgY29udHJvbGxlci4NCg0KU3VyZSAtIG5vdCBvbmx5IGlzIGl0IHBvc3NpYmxlLCB0aGVy ZSdzIGFsc28gcGxlbnR5IG9mIGRlcGxveWVkIHN0b3JhZ2UgZXF1aXBtZW50IHRoYXQgZG9lcyB0 aGlzLA0KdG9kYXkuICBBbHNvLCBwbGVhc2UgYXZvaWQgdXNlIG9mIHRoZSBwaHJhc2UgInN0b3Jh Z2UgY29udHJvbGxlciIgaW4gdGhpcyBkaXNjdXNzaW9uLCBhcyB0aGF0J3MNCm9mdGVuIGEgY29t cG9uZW50IG9mIGEgbXVjaCBsYXJnZXIgc3RvcmFnZSBzeXN0ZW0sIHN0b3JhZ2UgYXJyYXksIG9y IGZpbGVzZXJ2ZXIuDQoNCj4gVGhlIHNjaGVtZSBpcyBhbHNvIGV4dGVuc2libGUgdG8gb3RoZXIg dGhpbmdzIGxpa2UgVlhMQU4gb3IgTlZHUkUuDQoNClllcy4NCg0KPiBUaGVuIHlvdSB0aWUgdGhl IGZpbGUgc3lzdGVtIHBlcm1pc3Npb25zIHRvIHRoZSBWTEFOLiBBbSBJIHJlYWRpbmcgdGhpcyBj b3JyZWN0bHk/DQoNCk5vdCBleGFjdGx5IDstKS4gIFdoaWxlIG9uZSBjb3VsZCBkbyB0aGF0LCB0 aGUgcmVzdWx0IGNhbiBiZSAiaW50ZXJlc3RpbmciIGlmIHRoZXJlIGlzIElEDQpkdXBsaWNhdGlv biBhbW9uZyB0ZW5hbnRzLiAgSXQncyBiZXR0ZXIgdG8gdXNlIHNlcGFyYXRlIGZpbGVzeXN0ZW1z IHBlciB0ZW5hbnQgKHdpdGggZWFjaA0KZmlsZXN5c3RlbSB0aWVkIHRvIHRoZSBpZGVudGl0eSBz ZXJ2aWNlIGZvciB0aGUgY29ycmVzcG9uZGluZyB0ZW5hbnQpLCBhbmQgdGllIHRoZSBsaXN0IG9y DQpzZXQgb2YgZXhwb3J0ZWQgZmlsZXN5c3RlbXMgdG8gdGhlIFZMQU4gKG9yIHZpcnR1YWwgbmV0 d29yayBiYXNlZCBvbiBWTkkvVE5JKS4gIFRoZSByZXN1bHQNCmlzIHRoYXQgaWYgVGVuYW50IEEg aXMgb24gYSBWTEFOIChvciB2aXJ0dWFsIG5ldHdvcmspIHRoYXQgaXNuJ3Qgc3VwcG9zZWQgdG8g aGF2ZSBhY2Nlc3MgdG8NClRlbmFudCBCIGZpbGVzeXN0ZW1zLCBpdCBkb2Vzbid0IG1hdHRlciB3 aGF0IElEcyBvciBhZGRyZXNzZXMgYXJlIGR1cGxpY2F0ZWQgb3IgZm9yZ2VkIG9uDQpUZW5hbnQg QSdzIFZMQU4gKG9yIHZpcnR1YWwgbmV0d29yaykgLSBUZW5hbnQgQidzIGZpbGVzeXN0ZW1zIGFy ZSBpbmFjY2Vzc2libGUgKGUuZy4sIGNhbid0DQpiZSBtb3VudGVkKS4gIEZvciBpU0NTSSwgTFVO IG1hcHBpbmcvbWFza2luZyBpcyB0aGUgYW5hbG9nb3VzIGZ1bmN0aW9uYWxpdHksIGFuZCB0aGF0 DQpmdW5jdGlvbmFsaXR5IGlzIHdpZGVseSBpbXBsZW1lbnRlZCBpbiBzdG9yYWdlIHN5c3RlbXMu DQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBkYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2Vt YmVyIDI3LCAyMDExIDExOjA4IFBNDQo+IFRvOiBCbGFjaywgRGF2aWQNCj4gQ2M6IGRjQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbZGNdIFthcm1kXSBJUCBvdmVyIElQIHNvbHV0aW9uIGZvciBk YXRhIGNlbnRlciBpbnRlcmNvbm5lY3QNCj4NCj4gRGF2aWQsDQo+DQo+IFRoYW5rcyBmb3IgdGhl IGV4cGxhbmF0aW9uLiBTbywgaXQgaXMgcG9zc2libGUgdG8gcHVsbCBuZXR3b3JrIGFic3RyYWN0 aW9ucyAoVkxBTiBldGMpIGludG8gdGhlDQo+IHN0b3JhZ2UgY29udHJvbGxlci4gVGhlIHNjaGVt ZSBpcyBhbHNvIGV4dGVuc2libGUgdG8gb3RoZXIgdGhpbmdzIGxpa2UgVlhMQU4gb3IgTlZHUkUu IFRoZW4geW91IHRpZQ0KPiB0aGUgZmlsZSBzeXN0ZW0gcGVybWlzc2lvbnMgdG8gdGhlIFZMQU4u IEFtIEkgcmVhZGluZyB0aGlzIGNvcnJlY3RseT8NCj4NCj4gVGhhbmtzLCBBc2hpc2gNCj4NCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGF2aWQuYmxhY2tAZW1jLmNvbSBb bWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIg MjgsIDIwMTEgMjo1NiBBTQ0KPiBUbzogQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkNCj4gQ2M6IGRj QGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbZGNdIFthcm1kXSBJUCBvdmVyIElQIHNvbHV0aW9u IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QNCj4NCj4gQXNoaXNoLA0KPg0KPiA+IEkgd291 bGQgYmUgaW50ZXJlc3RlZCB0byBrbm93IGhvdyB0aGUgc3RvcmFnZSBtdWx0aS10ZW5hbmN5IHNv bHV0aW9ucyBkZWFsIHdpdGggcHJpdmF0ZSBJUCwgTUFDIGFuZA0KPiBJRA0KPiA+IGluIHRoZSBw dWJsaWMgZG9tYWluLCB3aGljaCBjYW4gYmUgZHVwbGljYXRlZC4NCj4NCj4gQSBjb21tb24gY3Vy cmVudCB0ZWNobmlxdWUgaXMgdG8gdXNlIHBlci10ZW5hbnQgVkxBTnMgKGEgdGVuYW50IG1heSBo YXZlIG11bHRpcGxlIFZMQU5zKSBhbmQgdXNlIE5BVA0KPiAoYXMgbmVlZGVkKSBiZXR3ZWVuIHRo ZSBWTEFOcyBhbmQgdGhlIHB1YmxpYyBJbnRlcm5ldCBpbiBvcmRlciB0byBzZXBhcmF0ZSBWTEFO IGFkZHJlc3NpbmcgZnJvbSBwdWJsaWMNCj4gSW50ZXJuZXQgYWRkcmVzc2luZywgZWZmZWN0aXZl bHkgcmVzdWx0aW5nIGluIGEgKHZpcnR1YWwpIE5BVCBpbnN0YW5jZSBwZXIgVkxBTi4gIEEgMTIt Yml0IFZMQU4gdGFnIGlzDQo+IG5vdCBsYXJnZSBlbm91Z2ggdG8gc2NhbGUgdXAgdG8gdGhlIGRl c2lyZWQgbGFyZ2Utc2NhbGUgZGF0YSBjZW50ZXIgc2NvcGUsIHNvIGJvdGggVnhMQU4gYW5kIE5W R1JFIHVzZQ0KPiBhIDI0LWJpdCB2aXJ0dWFsIG5ldHdvcmsgaWRlbnRpZmllciB0byByZXBsYWNl IHRoZSAxMi1iaXQgVkxBTiB0YWc7IFZ4TEFOIGNhbGxzIHRoaXMgYSBWTkkgKFZ4TEFOIFtvcg0K PiBWaXJ0dWFsXSBOZXR3b3JrIElkZW50aWZpZXIpLCBhbmQgTlZHUkUgY2FsbHMgaXQgYSBUTkkg KFRlbmFudCBOZXR3b3JrIElkZW50aWZpZXIpLiAgVk5JIGFuZCBUTkkNCj4gZW5jYXAvZGVjYXAg Y2FuIGJlIGhhbmRsZWQgYnkgdGhlIGh5cGVydmlzb3IgYW5kIGFyZSBsaW1pdGVkIHRvIHRoZSBk YXRhY2VudGVyOyBpbiB0aGlzIHN0cnVjdHVyZSwgVk1zDQo+IGNhbid0IHVzZSBhIFZOSSBvciBU TkkgZGlyZWN0bHksIGFuZCB0aGUgKHZpcnR1YWwpIE5BVCBoYW5kbGVzIGVuY2FwL2RlY2FwIGZv ciBpbmJvdW5kL291dGJvdW5kDQo+IHRyYWZmaWMgc28gdGhhdCB0cnlpbmcgdG8gc2VuZCBlbmNh cHN1bGF0ZWQgKFZ4TEFOIG9yIE5HUkUpIHRyYWZmaWMgaW4gZnJvbSB0aGUgb3V0c2lkZSByZXN1 bHRzIGluDQo+IGRvdWJsZSBlbmNhcHN1bGF0aW9uIHdpdGggbm8gZWZmZWN0IG9uIHRlbmFudCBp c29sYXRpb24uDQo+DQo+IEJlZm9yZSBvbmUgb2YgdGhlIEwyVlBOIGZvbGtzIGNvbWVzIGFmdGVy IG1lIGZvciB0aGF0ICJsaW1pdGVkIHRvIHRoZSBkYXRhY2VudGVyIiBjb21tZW50IDstKSAuLi4g YW4NCj4gTDJWUE4gZ2F0ZXdheSB3b3VsZCBwcm9iYWJseSB0cmFuc2xhdGUgYmV0d2VlbiBhIDI0 LWJpdCBWTkkvVE5JIGFuZCBhIDI0LWJpdCBWUE4gSUQgLSBlbmQtdG8tZW5kIHVzZQ0KPiBvZiBh IHNpbmdsZSBpZGVudGlmaWVyIGZvciB0aGUgTDJWUE4gYW5kIHRoZSB2aXJ0dWFsIG5ldHdvcmtz IG9uIGJvdGggZW5kcyBpcyBwb3NzaWJsZSwgYnV0IChJTUhPKQ0KPiBkaWZmaWN1bHQgd2hlbiB0 aGVyZSBhcmUgbXVsdGlwbGUgYWRtaW5pc3RyYXRpdmUgZG9tYWlucyBpbnZvbHZlZCBpbiBtYW5h Z2luZyB0aGUgaWRlbnRpZmllcnMuDQo+DQo+IFVzZSBvZiBWTEFOcyB0byBzY29wZSBmaWxlc3lz dGVtIHZpc2liaWxpdHkgb24gTkFTIGZpbGVzZXJ2ZXJzIGlzIGEgY29tbW9uIGRlcGxveWVkIHBy YWN0aWNlIGluDQo+IGRhdGFjZW50ZXJzIChkaXR0byBmb3IgVkxBTnMgdG8gbGltaXQgaVNDU0kg c3RvcmFnZSB2aXNpYmlsaXR5KSwgdGhlcmVieSBkZWFsaW5nIHdpdGggdGhlIGZvbGxvd2luZzoN Cj4NCj4gPiBTbywgeW91IGhhdmUgdG8NCj4gPiBwcm90ZWN0IHRoZSBuZXR3b3JrIHN0b3JhZ2Ug ZnJvbSBtdWx0aXBsZSB0ZW5hbnRzIHdobyBjYW4gaGF2ZSB0aGUgc2FtZSBJUCBhZGRyZXNzIGFu ZCBNQUMgYWRkcmVzcy4NCj4gPiBOQVMgYXNzdW1lcyB5b3VyIGlkIG9uIHRoZSBVTklYIGlzIGds b2JhbGx5IHVuaXF1ZSBhbmQgeW91ciBwZXJtaXNzaW9ucyBhcmUgdW5pcXVlIC0gbm90IHRydWUN Cj4gYW55bW9yZS4NCj4gPiBTbywgeW91IGhhdmUgSVAsIE1BQyBhbmQgSUQgZHVwbGljYXRpb24u DQo+DQo+IER1cGxpY2F0aW9uIG9mIElQLCBNQUMgYW5kIElEIG9uIHNlcGFyYXRlIFZMQU5zIHdv cmtzIGZpbmUgLSB0aGlzIG1vZGVsIGlzIGNhcnJpZWQgb3ZlciB0byB2aXJ0dWFsDQo+IG5ldHdv cmtzIGJhc2VkIG9uIFZOSSBvciBUTkkuICBUaGUgc2VudGVuY2UgY29udGFpbmluZyAiZ2xvYmFs bHkgdW5pcXVlIiAoaW5jb3JyZWN0bHkpIGFzc3VtZXMgYQ0KPiBzaW5nbGUgZmlsZXNlcnZlcjsg aW5zdGVhZCwgY29uc2lkZXIgYSBzaW5nbGUgTkFTIHN5c3RlbSBwcmVzZW50aW5nIHdoYXQgaXMg ZWZmZWN0aXZlbHkgYSB2aXJ0dWFsDQo+IGZpbGVzZXJ2ZXIgcGVyIFZMQU4gKG9yIFZOSS9UTkkp IGFuZCBzaW1pbGFybHkgZm9yIGlTQ1NJIC0gdGhhdCBpcyB3aGF0IHNvcnRzIG91dCB0aGlzIGR1 cGxpY2F0aW9uLA0KPiBpbmNsdWRpbmcgdXNlIG9mIGRpZmZlcmVudCBpZGVudGl0eSBzZXJ2aWNl cy9zZXJ2ZXJzIHBlciBWTEFOIChvciBWTkkvVE5JKS4NCj4NCj4gVGhhbmtzLA0KPiAtLURhdmlk DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gRGF2aWQgTC4gQmxhY2ssIERpc3Rpbmd1aXNoZWQgRW5naW5lZXINCj4gRU1DIENvcnBvcmF0 aW9uLCAxNzYgU291dGggU3QuLCBIb3BraW50b24sIE1BICAwMTc0OA0KPiArMSAoNTA4KSAyOTMt Nzk1MyAgICAgICAgICAgICBGQVg6ICsxICg1MDgpIDI5My03Nzg2DQo+IGRhdmlkLmJsYWNrQGVt Yy5jb20gICAgICAgIE1vYmlsZTogKzEgKDk3OCkgMzk0LTc3NTQNCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogZGMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKQ0K PiA+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDI3LCAyMDExIDI6NTAgQU0NCj4gPiBUbzogUGVk cm8gTWFycXVlcw0KPiA+IENjOiBkY0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbZGNdIFth cm1kXSBJUCBvdmVyIElQIHNvbHV0aW9uIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QNCj4g Pg0KPiA+IFRoZXJlIGlzIEluZmluaUJhbmQgYmVzaWRlcyBGaWJlckNoYW5uZWwuIEFuZCB3ZSBh cmUgdGFsa2luZyBhYm91dCBjb252ZXJnaW5nIG5vdCBzZXBhcmF0aW5nIHRoZW0uDQo+IFRoZQ0K PiA+IHF1ZXN0aW9uIGlzIGNvbnZlcmdlIG92ZXIgTDIgb3IgTDMuIEkgdGhpbmsgeW91IGRpZCBu b3QgcmVhZCBtZSBjb3JyZWN0bHkuIElQIGJhc2VkIHNvbHV0aW9ucyBoYXZlDQo+ID4gYmVlbiBk ZWZpbmVkIGJlZm9yZSBFdGhlcm5ldCBzb2x1dGlvbnMgYnV0IG5vdCB1c2VkIHdpZGVseS4gV2Ug Y2FuIGRpc2N1c3Mgd2h5Lg0KPiA+DQo+ID4gSSB3b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGtub3cg aG93IHRoZSBzdG9yYWdlIG11bHRpLXRlbmFuY3kgc29sdXRpb25zIGRlYWwgd2l0aCBwcml2YXRl IElQLCBNQUMgYW5kDQo+IElEDQo+ID4gaW4gdGhlIHB1YmxpYyBkb21haW4sIHdoaWNoIGNhbiBi ZSBkdXBsaWNhdGVkLg0KPiA+DQo+ID4gVGhlIGFyZ3VtZW50IHdhcyBub3QgYXJvdW5kIGxvYWQt YmFsYW5jaW5nLCBpdCBpcyBhcm91bmQgZGlzY292ZXJ5Lg0KPiA+DQo+ID4gWW91ciBleGFtcGxl IG9mIHRoZSBoeXBlcnZpc29yIGlzIGludGVyZXN0aW5nLiBJJ20gYXdhcmUgdGhhdCBBbWF6b24g ZG9lcyB0aGluZ3MgaW4gdGhlIGh5cGVydmlzb3IuDQo+ID4gVGhleSBwcm92aWRlIElQIG1vYmls aXR5IHRocm91Z2ggTkFULiBTZWN1cml0eSB0aHJvdWdoIGEgaHlwZXJ2aXNvciBmaXJld2FsbC4g VGhlIGNvbnNlcXVlbmNlIGlzDQo+IHRoYXQNCj4gPiB5b3UgcGF5IGV4dHJhIGlmIHlvdSB3YW50 ZWQgYSBtb2JpbGUgVk0sIGFuZCB5b3UgbWFuYWdlIHlvdXIgb3duIGZpcmV3YWxsIChhdCBsZWFz dCB0aGUgbGFzdCB0aW1lIEkNCj4gPiBjaGVja2VkKS4gSWYgdGVuYW50IGlzb2xhdGlvbiBpcyBh bGwgdGhlIHdheSBpbnRvIHRoZSBob3N0LCB0aGVuIG5ldHdvcmsgUW9TLCBiYW5kd2lkdGggZXRj IGlzIGFsc28NCj4gPiBtb290Lg0KPiA+DQo+ID4gVGhhbmtzLCBBc2hpc2gNCj4gPg0KPiA+DQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBQZWRybyBNYXJxdWVzIFtt YWlsdG86cGVkcm8uci5tYXJxdWVzQGdtYWlsLmNvbV0NCj4gPiBTZW50OiBUdWVzZGF5LCBEZWNl bWJlciAyNywgMjAxMSAxMjozMiBQTQ0KPiA+IFRvOiBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKQ0K PiA+IENjOiBkY0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbZGNdIFthcm1kXSBJUCBvdmVy IElQIHNvbHV0aW9uIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QNCj4gPg0KPiA+IDIwMTEv MTIvMjYgQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkgPGFkYWxlbGFAY2lzY28uY29tPjoNCj4gPiA+ IEZvciBhbGwgdGhlIHByb3BvbmVudHMgb2YgTDMsIGhlcmUgaXMgYSB0aG91Z2h0Lg0KPiA+DQo+ ID4gc3VtbWFyeSBvZiB0aGUgb3JpZ2luYWwgZW1haWw6IG11bHRpLXRlbmFudCBzdG9yYWdlIHNv bHV0aW9ucyByZXF1aXJlDQo+ID4gRmliZXJDaGFubmVsOyBhbiBMMyBzZXJ2aWNlIG1vZGVsIGRv ZXNuJ3Qgc3VwcG9ydCBGaWJlckNoYW5uZWwuDQo+ID4NCj4gPiBUaGVyZSBhcmUgbXVsdGlwbGUg c3RvcmFnZSBzb2x1dGlvbnMgdGhhdCBzdXBwb3J0IG11bHRpLXRlbmFuY3kgdGhhdA0KPiA+IHdv cmsgb24gdG9wIG9mIElQIG1ha2luZyB0aGUgYXJndW1lbnQgbW9vdCAoMSkuIEF0IGxhcmdlIHNj YWxlIHJ1bm5pbmcNCj4gPiBhIHNlcGFyYXRlIG5ldHdvcmsgZm9yIGRhdGEgYW5kIGZvciBzdG9y YWdlIGltcG9zZXMgdmVyeSBzaWduaWZpY2FudA0KPiA+IGNvc3RzLiBJJ2QgdmVudHVyZSB0aGF0 IHRoZSBwcm9wb25lbnRzIG9mIEwzIGhhdmUgdmVyeSBsaXR0bGUgaW50ZXJlc3QNCj4gPiBpbiBG aWJlckNoYW5uZWwuDQo+ID4NCj4gPiBUaGUgc2FtZSBnb2VzIGZvciB0aGUgYXJndW1lbnQgdGhh dCBsb2FkLWJhbGFuY2luZyByZXF1aXJlcyBMMi4gVGhlcmUNCj4gPiBpcyBleGlzdGVuY2UgcHJv b2Ygb2YgdGhlIGNvbnRyYXJ5Lg0KPiA+DQo+ID4gVGhlcmUgaXMgYSB3aWRlIHJhbmdlIG9mIHRl Y2hub2xvZ3kgY2hvaWNlcyBhdmFpbGFibGUgaW4gdGhpcyBzcGFjZS4NCj4gPiBJJ20gc3VyZSB0 aGVyZSBpcyBpbnRlcmVzdCBpbiBMMiBiYXNlZCBzb2x1dGlvbnMgYnV0IHRoZSBjbGFpbSB0aGF0 IEwzDQo+ID4gYmFzZWQgc29sdXRpb25zIGFyZSBub3QgZmVhc2libGUgaGFzIGFscmVhZHkgYmVl biBkaXNwcm92ZWQgYnkNCj4gPiBkZXBsb3llZCBzb2x1dGlvbnMuDQo+ID4NCj4gPiAxIC0gRXhh bXBsZTogV2hlbiBhIHN0b3JhZ2Ugc29sdXRpb24gcHJlc2VudHMgYSBibG9jayBkZXZpY2UgdG8g dGhlIFZNDQo+ID4gKGUuZy4gQW1hem9uIEVCUykgaXQgaXMgdGhlIGhvc3QgT1MvaHlwZXJ2aXNv ciB0aGF0IG1hcHMgdGhlIGd1ZXN0IE9TDQo+ID4gb3BlcmF0aW9ucyBpbnRvIG5ldHdvcmsgb3Bl cmF0aW9uczsgZG9pbmcgc28gaW4gdGhlIGluZnJhc3RydWN0dXJlDQo+ID4gbmV0d29yayByZWFs IHJhdGhlciB0aGFuIGluIHRoZSB0ZW5hbnQncyBuZXR3b3JrIHJlYWxtLg0KPiA+DQo+ID4gPg0K PiA+ID4gVGhlIGJpZ2dlc3QgY29uY2VybiBpbiBjbG91ZCBpcyBkYXRhIHByb3RlY3Rpb24uIFRo YXQgaXMganVzdCBtYWtlIG9yIGJyZWFrLiBEYXRhIGNhbid0IG1vdmUgd2hlbg0KPiA+IHRoZSBW TSBtb3Zlcy4gSXQncyBqdXN0IHRvbyBleHBlbnNpdmUgYW5kIHRpbWUgY29uc3VtaW5nLiBGdXJ0 aGVyLCB0byByZWR1Y2UgZGlzayB3YXN0YWdlIHlvdSBoYXZlDQo+IHRvDQo+ID4gcHV0IGRhdGEg b24gbmV0d29yayBzdG9yYWdlLiBUaGF0J3MganVzdCBlYXN5IGZvciBkYXRhIGJhY2t1cCwgYW5k IGNoZWFwIGluIHRlcm1zIG9mIHRvdGFsIGRpc2sNCj4gc3BhY2UNCj4gPiB5b3UgbmVlZC4gVGhl cmUgaXMgYSBsb3QgZ29pbmcgb24gaGVyZSBpbiB0ZXJtcyBvZiBkYXRhIGRlLWR1cGxpY2F0aW9u Lg0KPiA+ID4NCj4gPiA+IE5vdyBnaXZlbiBuZXR3b3JrIHN0b3JhZ2UsIHlvdSBoYXZlIHR3byBv cHRpb25zIC0gTkFTIGFuZCBTQU4uDQo+ID4gPg0KPiA+ID4gT24gdGhlIGNsb3VkIGVhY2ggVk0g YWRtaW5pc3RyYXRvciBoYXMgcm9vdCBwcml2aWxlZ2VzLiBBbmQgSVAgYW5kIE1BQyBhZGRyZXNz ZXMgY2FuIGJlIGR1cGxpY2F0ZWQNCj4gPiAoaWYgeW91IGFyZSByb290IGp1c3QgY29uZmlndXJl IGFueSBJUCBhbmQgTUFDIG9uIGEgdmlydHVhbCBpbnRlcmZhY2Ugb2YgY2hvaWNlKS4gU28sIHlv dSBoYXZlIHRvDQo+ID4gcHJvdGVjdCB0aGUgbmV0d29yayBzdG9yYWdlIGZyb20gbXVsdGlwbGUg dGVuYW50cyB3aG8gY2FuIGhhdmUgdGhlIHNhbWUgSVAgYWRkcmVzcyBhbmQgTUFDIGFkZHJlc3Mu DQo+ID4gTkFTIGFzc3VtZXMgeW91ciBpZCBvbiB0aGUgVU5JWCBpcyBnbG9iYWxseSB1bmlxdWUg YW5kIHlvdXIgcGVybWlzc2lvbnMgYXJlIHVuaXF1ZSAtIG5vdCB0cnVlDQo+IGFueW1vcmUuDQo+ ID4gU28sIHlvdSBoYXZlIElQLCBNQUMgYW5kIElEIGR1cGxpY2F0aW9uLg0KPiA+ID4NCj4gPiA+ IFRoYXQgbWVhbnMgdGhhdCBpZiB5b3UgaGF2ZSB0byBwcm90ZWN0IGRhdGEsIHlvdSBoYXZlIHRv IGtub3cgc29tZWhvdyB3aGljaCBob3N0IGlzIGFsbG93ZWQgdG8gc2VlDQo+ID4gd2hpY2ggZGlz a3MuIERvaW5nIHRoaXMgZW5kLXRvLWVuZCB1c2luZyBUQ1AvSVAgaXMgcHJvYmxlbWF0aWMgYmVj YXVzZSB0aGUgTkFTIGNvbnRyb2xsZXIgZG9lc24ndA0KPiBrbm93DQo+ID4gYWJvdXQgdGVuYW50 IGlkLCBhbmQgd2hldGhlciB0aGUgTUFDIGFuZCBJUCBhcmUgYmVpbmcgZHVwbGljYXRlZCBhY3Jv c3MgY3VzdG9tZXJzLiBUbyBtYWtlIHRoZQ0KPiBzdG9yYWdlDQo+ID4gYXdhcmUgb2Ygc2VnbWVu dGF0aW9uLCB5b3UgaGF2ZSB0byBjYXJyeSBzb21lIHNlZ21lbnQgKEdSRSwgTVBMUywgVkxBTiwg ZXRjLikgaW50byB0aGUgc3RvcmFnZSBib3guDQo+ID4gVGhhdCdzIG5vdCB0cnVlIHRvZGF5Lg0K PiA+ID4NCj4gPiA+IE5ldHdvcmsgbGV2ZWwgaXNvbGF0aW9uIGhhcHBlbnMgaW4gU0FOLCBidXQg bm90IGluIE5BUy4gTkFTIGp1c3QgcnVucyBlbmQtdG8tZW5kIG92ZXIgVENQLiBJbiBTQU4NCj4g PiB5b3UgY2FuIHNheSB3aGljaCBob3N0IHdpbGwgc2VlIHdoaWNoIGRpc2suIFRoZSBGQyBzZWN1 cml0eSBpcyBoaWdoIGJlY2F1c2UgTUFDIGFuZCBGQy1JRCBpcw0KPiBhc3NpZ25lZA0KPiA+IGJ5 IHRoZSBuZXR3b3JrIGFuZCBub3QgaW4gdGhlIGNvbnRyb2wgb2YgdGhlIGhvc3QuIFRoZSBuZXR3 b3JrIGtub3dzIHdoaWNoIHBvcnQgaXMgd2hpY2ggaG9zdC9NQUMuDQo+IFNvLA0KPiA+IGlmIHlv dSBvbmx5IGtub3cgd2hpY2ggcG9ydCBpcyB3aGljaCBjdXN0b21lciwgeW91IGtub3cgd2hpY2gg TUFDIGNhbiBzZWUgd2hpY2ggZGlzay4gQmluZGluZyBhIHBvcnQNCj4gPiB0byBhIGN1c3RvbWVy IGlzIG5vdCBoYXJkLiBCdXQgbWFwcGluZyBhbGwgb2YgdGhhdCB0byBkYXRhIHNlY3VyaXR5IGFu ZCBkaXNrIHZpc2liaWxpdHkgaXMgbm90DQo+ID4gdHJpdmlhbC4gRS5nLiB5b3UgaGF2ZSB0byBk byBHUkUgdHVubmVsIG1hcHBpbmcgdG8gYSBzZXQgb2YgZGlzayBwZXJtaXNzaW9ucy4gV2hvIG5l ZWRzIHRoYXQ/DQo+ID4gPg0KPiA+ID4gU0FOIGRvZXMgbm90IHVzZSBJUC4gSXQgdXNlcyBGaWJl ciBDaGFubmVsLiBXaXRoIGNvbnZlcmdlbmNlLCB3ZSBhcmUgbW92aW5nIHRvIEZDIG92ZXIgRXRo ZXJuZXQNCj4gPiAoRkNvRSkuIEZDSVAgYW5kIGlTQ1NJIGhhdmUgbm90IHdvcmtlZCB2ZXJ5IHdl bGwuIFNlY3VyaXR5IGZvciBkYXRhIGNvbWVzIGZyb20gRkMgYW5kIGxvd2VyaW5nIG9mDQo+IGNv c3QNCj4gPiBjb21lcyBmcm9tIHVzZSBvZiBGQ29FLiBUaGF0IG5lZWRzIG5hdGl2ZSBFdGhlcm5l dCAobm8gSVApLg0KPiA+ID4NCj4gPiA+IFdoZW4geW91IGhhdmUgc2l0ZS10by1zaXRlIFZNIG1v YmlsaXR5LCBkYXRhIGlzIG5vdCBtb3ZpbmcgYWNyb3NzIHNpdGVzLiBFLmcuIGFuIGFwcGxpY2F0 aW9uDQo+IHNlcnZlcg0KPiA+IHdpbGwgY29ubmVjdCB0byBhIHNldCBvZiBsb2FkLWJhbGFuY2Vk IHNldCBvZiBkYXRhYmFzZSBzZXJ2ZXJzIHdpdGhpbiBhIFZMQU4uIFRoZSBhcHBsaWNhdGlvbiBh bmQNCj4gPiBkYXRhYmFzZSBzZXJ2ZXJzIGNhbiBiZSBkaWZmZXJlbnQgc2l0ZXMsIGFuZCB0aGV5 IGNvbm5lY3Qgb3ZlciBhIFZMQU4uIEFsdGVybmF0ZWx5LCB0aGUgYXBwbGljYXRpb24NCj4gPiBh bmQgZGF0YWJhc2Ugc2VydmVycyBjYW4gYmUgaW4gdGhlIHNhbWUgbG9jYXRpb24gYW5kIHRoZSBE QiBzZXJ2ZXIgYWNjZXNzZXMgdGhlIFNBTiBvdmVyIHRoZQ0KPiBJbnRlcm5ldC4NCj4gPiBFdmVu IGlmIGRhdGEgaXMgcmVwbGljYXRlZCBhY3Jvc3MgbWFueSBzaXRlcywgbG9hZC1iYWxhbmNpbmcg YWNyb3NzIGFwcGxpY2F0aW9uIG9yIGRiIHNlcnZlcnMgdXNlcw0KPiA+IFZMQU5zLiBJbiBIUEMg YXMgd2VsbCwgdGhlcmUgaXMgYSBsb3Qgb2YgYnJvYWRjYXN0IGFuZCBkaXNjb3ZlcnksIGFuZCB0 aGlzIG1heSB1c2UgSVAgb3Igbm90LCB0aGUNCj4gZmFjdA0KPiA+IGlzIHRoYXQgaXQgZGVwZW5k cyBvbiBicm9hZGNhc3QuIFRoZSBIUEMgY2FzZSBleHRlcm5hbGl6ZXMgdGhlIG1lbW9yeSBvbiBh IGhvc3QgdG8gb3RoZXIgaG9zdHMNCj4gdGhyb3VnaA0KPiA+IFJETUEuIEV2ZXJ5dGhpbmcgdG8g ZG8gd2l0aCBCaWcgRGF0YSB3aWxsIHJlbHkgb24gdGhpcywgYW5kIGJlc2lkZXMgZGlzayBleHRl cm5hbGl6YXRpb24gd2Ugd2lsbA0KPiBhbHNvDQo+ID4gc2VlIGluY3JlYXNlIGluIG1lbW9yeSBl eHRlcm5hbGl6YXRpb24uIEkganVzdCB3ZW50IHRvIGEgSUVFRSBIUEMgY2xvdWQgY29uZmVyZW5j ZSA6LSkNCj4gPiA+DQo+ID4gPiBMMyBhc3N1bWVzIHRoYXQgYWxsIGRhdGEgKGRpc2sgYW5kIG1l bW9yeSkgaXMgaW5zaWRlIHRoZSBob3N0LiBUaGF0IGFzc3VtcHRpb24gY2hhbmdlZCBhIGRlY2Fk ZQ0KPiBhZ28uDQo+ID4gQ2xvdWQganVzdCBpbmNyZWFzZXMgdGhlIGRpc3RyaWJ1dGlvbi4gSnVz dCBhcyBjb21wdXRlIGlzIG9wdGltaXplZCBieSBtdXhpbmcgdGhlIFZNcyBvbiBhIHBoeXNpY2Fs DQo+ID4gbWFjaGluZSwgc3RvcmFnZSBpcyBvcHRpbWl6ZWQgYnkgY29uc29saWRhdGluZyBkYXRh IHNlcGFyYXRlbHkgb24gc3RvcmFnZSBkZXZpY2VzIGFuZCBtZW1vcnkgYnkNCj4gPiBob3N0aW5n IGl0IGluIGRpZmZlcmVudCBob3N0cy4gTmV0d29yayBoYXMgdG8gZGVhbCB3aXRoIGFsbCB0eXBl cyBvZiB0cmFmZmljIGFuZCBzZWN1cml0eS9pc29sYXRpb24NCj4gPiAoaW1hZ2luZSBzb21lb25l IGNoYW5naW5nIG1lbW9yeSBvdmVyIHRoZSBuZXR3b3JrKS4gU3RvcmFnZSBhbmQgbWVtb3J5IHRy YWZmaWMgdXNlcyBMMi4gVG8gZGlzY292ZXINCj4gPiBlYWNoIG90aGVyLCBob3N0cyB1c2UgTDIu IFRoZXNlIEwyIGRvbWFpbnMgbmVlZCB0byBzcGFuIGFjcm9zcyBzaXRlcyBhbmQgd2l0aGluIHRo ZSBzaXRlLg0KPiA+ID4NCj4gPiA+IFRoaXMgYXJlIG5vdCBjb3JuZXIgY2FzZXMuIFRoaXMgaXMg anVzdCBjZW50cmFsIHRvIHdoYXQgY2xvdWQgbWVhbnMgaW4gdGhlIGxvbmcgcnVuLg0KPiA+ID4N Cj4gPiA+IFRoYW5rcywgQXNoaXNoDQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBhcm1kLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzph cm1kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBYdXhpYW9odQ0KPiA+ID4gU2VudDog RnJpZGF5LCBEZWNlbWJlciAyMywgMjAxMSAxMjowOSBQTQ0KPiA+ID4gVG86IEVnZ2VydCwgTGFy czsgZGNAaWV0Zi5vcmc7IGRjcmctaW50ZXJlc3RAaXJ0Zi5vcmcNCj4gPiA+IENjOiBhcm1kQGll dGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW2FybWRdIElQIG92ZXIgSVAgc29sdXRpb24gZm9y IGRhdGEgY2VudGVyIGludGVyY29ubmVjdA0KPiA+ID4NCj4gPiA+DQo+ID4gPj4gLS0tLS3pgq7k u7bljp/ku7YtLS0tLQ0KPiA+ID4+IOWPkeS7tuS6ujogWHV4aWFvaHUNCj4gPiA+PiDlj5HpgIHm l7bpl7Q6IDIwMTHlubQxMuaciDIy5pelIDE2OjI4DQo+ID4gPj4g5pS25Lu25Lq6OiAnRWdnZXJ0 LCBMYXJzJzsgZGNAaWV0Zi5vcmc7ICdkY3JnLWludGVyZXN0QGlydGYub3JnLicNCj4gPiA+PiDk uLvpopg6IElQIG92ZXIgSVAgc29sdXRpb24gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdA0K PiA+ID4+DQo+ID4gPj4gSGkgYWxsLA0KPiA+ID4+DQo+ID4gPj4gVGhlcmUgaGFzIGJlZW4gYSBs b3Qgb2YgTDIgb3ZlciBMMyBzb2x1dGlvbnMgb3IgcHJvcG9zYWxzIGZvciBkYXRhIGNlbnRlcg0K PiA+ID4+IG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyIGludGVyY29ubmVjdCB0aWxsIG5vdy4gSG93 ZXZlciwgaXQgc2VlbXMgcmVjZW50bHkNCj4gPiA+PiB0aGVyZSBhcmUgaW5jcmVhc2luZyBpbnRl cmVzdHMgb24gTDMgb3ZlciBMMyAoZS5nLiwgSVAgb3ZlciBJUCkgc29sdXRpb25zIGZvciBkYXRh DQo+ID4gPj4gY2VudGVyIG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyIGludGVyY29ubmVjdCwgcGxl YXNlIHNlZSB0aGUgZm9sbG93aW5nIHRleHQNCj4gPiA+PiBxdW90ZWQgZnJvbSBJRVRGODIgTDJW UE4gbWludXRlcw0KPiA+ID4+ICggaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODIv bWludXRlcy9sMnZwbi50eHQpLiBJdCdzIGEgZ2VuZXJhbCBiZWxpZWYNCj4gPiA+PiB0aGF0IEwz IGlzIG1vcmUgc2NhbGFibGUgdGhhbiBMMi4gRXNwZWNpYWxseSB3aGVuIGNvbnNpZGVyaW5nIHRo ZSBkYXRhIGNlbnRlcg0KPiA+ID4+IGludGVyY29ubmVjdGlvbiBjYXNlLCB0aGUgTDMgb3ZlciBM MyBzb2x1dGlvbnMgY2FuIGJyaW5nIERDIG9wZXJhdG9ycyBtb3JlDQo+ID4gPj4gYmVuZWZpdHMg Y29tcGFyZWQgdG8gdGhlIEwyIG92ZXIgTDMgc29sdXRpb25zLCBzdWNoIGFzIHBhdGggb3B0aW1p emF0aW9uLA0KPiA+ID4+IGFjdGl2ZS1hY3RpdmUgZGF0YSBjZW50ZXJzLCBNQUMgdGFibGUgcmVk dWN0aW9uIG9uIERDIHN3aXRjaGVzIGFuZCBicm9hZGNhc3QNCj4gPiA+PiBmbG9vZCBzdXBwcmVz c2lvbiBldGMgLg0KPiA+ID4NCj4gPiA+IEJ5IHRoZSB3YXksIHRoZSBBUlAgdGFibGUgc2NhbGlu ZyBpc3N1ZSBvbiBEQyBnYXRld2F5cywgd2hpY2ggaXMgZGVlbWVkIGJ5IHRoZSBBUk1EIFdHIGFz IHRoZSBvbmx5DQo+ID4gd29ydGh5IEFSUCBwcm9ibGVtIGluIGRhdGEgY2VudGVyIG5ldHdvcmtz LCBjb3VsZCBhbHNvIGJlIHNvbHZlZCB3aXRoIHRoZSBJUCBvdmVyIElQIHNvbHV0aW9uLg0KPiA+ ID4NCj4gPiA+IEJlc3QgcmVnYXJkcywNCj4gPiA+IFhpYW9odQ0KPiA+ID4NCj4gPiA+Pg0KPiA+ ID4+IEFsdGhvdWdoIExheWVyIDIgY29ubmVjdGl2aXR5IGlzIHN0aWxsIHJlcXVpcmVkIGZvciBz b21lIGhpZ2gtYXZhaWxhYmlsaXR5IGNsdXN0ZXJzDQo+ID4gPj4gd2hpY2ggdXNlIG5vbi1JUCBh bmQgbGluay1sb2NhbCBtdWx0aWNhc3QgZm9yIGNvbW11bmljYXRpb24sIG1vcmUgYW5kIG1vcmUN Cj4gPiA+PiBjbHVzdGVyIHZlbmRvcnMgYXJlIGVpdGhlciBhbHJlYWR5IGFibGUgdG8gc3VwcG9y dCBjbHVzdGVyIHNlcnZpY2VzIGF0IExheWVyMyBvcg0KPiA+ID4+IHdpbGwgc3VwcG9ydCBpdCBp biB0aGUgbmVhciBmdXR1cmUuIEluIGFkZGl0aW9uLCB0aGUgR1NMQiBtZWNoYW5pc20gKGUuZy4s IEROUw0KPiA+ID4+IGJhc2VkIEdTTEIpIHdvcmtzIHZlcnkgd2VsbCBpbiBtb3N0IGNhc2VzLCBp cyBnZW8tY2x1c3RlciBzZXJ2aWNlIHN0aWxsIGENCj4gPiA+PiBjb21tb24gcmVxdWlyZW1lbnQg Zm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdD8gSWYgbm90LCBjb3VsZCB3ZSBzcGVuZCBhbnkN Cj4gPiA+PiB0aW1lIG9uIGV4cGxvcmluZyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgTDMgb3Zl ciBMMyBzb2x1dGlvbiBmb3IgdGhlIG1vc3QgZGF0YQ0KPiA+ID4+IGNlbnRlciBpbnRlcmNvbm5l Y3Rpb24gc2NlbmFyaW9zIHdoZXJlIGdlby1jbHVzdGVyaW5nLCBlc3BlY2lhbGx5IG5vbi1JUCBi YXNlZA0KPiA+ID4+IGdlby1jbHVzdGVyaW5nIGlzIG5vdCBuZWVkZWQ/DQo+ID4gPj4NCj4gPiA+ PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPj4gWGlhb2h1DQo+ID4gPj4NCj4gPiA+PiAqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ ID4gPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KPiA+ID4+IEtpcmVldGk6IEkga2VlcCBzZWVpbmcgSVNJRCwgUEJCLCBWTEFOcy4g IFdlIGhhdmUgdG8gc3RvcCBjb25jZWRpbmcgdG8gbGF5ZXIgMg0KPiA+ID4+IGFuZCBzdGFydCBt b3ZpbmcgdG8gbGF5ZXIgMyAoYXBwbGF1c2UpIGFuZCBsb3RzIG9mIHByb2JsZW1zIHdpbGwgZ28g YXdheS4NCj4gPiA+Pg0KPiA+ID4+IEZsb3JpbjogV2Ugc2hvdWxkIHB1dCBWUE4gb24gdGhlIHNh bWUgcGFnZSB0byBtb2RpZnkgdGhlIHByaW9yaXRpZXMuIFlvdSBuZWVkDQo+ID4gPj4gdG8gZXhw YW5kIHNvIGNhbiBsb29rIGF0IEwzIG92ZXIgTDMgYXMgd2VsbCBhcyBMMiBvdmVyIEwzLiBGb3Ig aXRlbSBudW1iZXIgMiB3ZQ0KPiA+ID4+IG5lZWQgdG8gbG9vayBhdCBMMyB0cmFuc3BvcnQgYXMg d2VsbCBhcyBFdGhlcm5ldCBhbmQgTVBMUy4gIEFuZCBmb3IgbnVtYmVyIDMNCj4gPiA+PiB3ZSBu ZWVkIHRvIHdvcmsgb24gdGhpcyBhcyB0aGVyZSdzIGEgbG90IG9mIGV4cGVydGlzZSBpbiBMMiwg TDMgYW5kIG90aGVyIFdHcy4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4gTWFyYzogVGhlIHByb2Js ZW0gc3RhdGVtZW50IG5lZWRzIHRvIGluY2x1ZGUgbW9yZSBvZiB0aGUgTDMgaXNzdWVzIGFyb3Vu ZA0KPiA+ID4+IHNlbmRpbmcgTDIgb3ZlciBMMywgYXMgdGhlIEwyIHRyYWZmaWMgYWxyZWFkeSBj b250YWlucyBMMy4gIElzc3VlIGlzIGp1c3QgZnJhbWluZy4NCj4gPiA+Pg0KPiA+ID4+IEVyaWMg Tm9yZG1hcms7ICJZZXMsIFllcyBhbmQgWWVzIi4gIFdlIG5lZWQgdG8gZm9jdXMgZnJvbSB0aGUg REMgcHJvc3BlY3RpdmUNCj4gPiA+PiBhbmQgbm90IGZyb20gdGhlIFZQTiB2aWV3LiAgZG9uJ3Qg anVzdCB0aGluayBhYm91dCBFdGhlcm5ldCBvdmVyIElQLCBidXQgYWxzbyBJUA0KPiA+ID4+IG92 ZXIgSVAuICBIeXBlcnZpc29yIG1heSBnZXQgZGVjb3VwbGVkIG92ZXIgdGltZS4NCj4gPiA+PiAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQo+ID4gPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KPiA+ID4+ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+ID4+ ID4g5Y+R5Lu25Lq6OiBkYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRm Lm9yZ10g5Luj6KGoIEVnZ2VydCwNCj4gPiA+PiBMYXJzDQo+ID4gPj4gPiDlj5HpgIHml7bpl7Q6 IDIwMTHlubQxMuaciDE25pelIDE2OjI0DQo+ID4gPj4gPiDmlLbku7bkuro6IGRjQGlldGYub3Jn DQo+ID4gPj4gPiDkuLvpopg6IFtkY10gSVJURiBkYXRhY2VudGVyIHJlc2VhcmNoIGdyb3VwIGRp c2N1c3Npb24gbGlzdA0KPiA+ID4+ID4NCj4gPiA+PiA+IEhpLA0KPiA+ID4+ID4NCj4gPiA+PiA+ IEkgd2FudGVkIHRvIG1ha2UgeW91IGFsbCBhd2FyZSBvZiB0aGUgSVJURidzIGRjcmctaW50ZXJl c3QgbWFpbGluZyBsaXN0LCB3aGljaA0KPiA+ID4+ID4gd2FzIHNldCB1cCBmb2xsb3dpbmcgYSBm YWNlLXRvLWZhY2UgbWVldGluZyBhdCBTSUdDT01NIHRoaXMgeWVhciB0byBkaXNjdXNzDQo+ID4g Pj4gYQ0KPiA+ID4+ID4gcG9zc2libGUgSVJURiByZXNlYXJjaCBncm91cCBvbiBkYXRhY2VudGVy IG5ldHdvcmtpbmc6DQo+ID4gPj4gPiBodHRwOi8vaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k Y3JnLWludGVyZXN0DQo+ID4gPj4gPg0KPiA+ID4+ID4gVGhlcmUgaGFzIG5vdCBiZWVuIG11Y2gg YWN0aXZpdHkgdG93YXJkcyB0aGUgZm9ybWF0aW9uIG9mIGFuIElSVEYgUkcgc2luY2UNCj4gPiA+ PiA+IFNJR0NPTU0sIGJ1dCBJIGFtIGhvcGVmdWwgdGhhdCB0aGUgaGlnaCBlbmVyZ3kgbGV2ZWwg ZGVtb25zdHJhdGVkIGluIHRoZQ0KPiA+ID4+ID4gdmFyaW91cyBUYWlwZWkgbWVldGluZ3Mgb24g dGhlIHRvcGljIHdpbGwgaW5qZWN0IHNvbWUgZW5lcmd5IGhlcmUgLSBzZXZlcmFsIG9mDQo+ID4g Pj4gPiB0aGUgdG9waWNzIHRoYXQgbWF5IGJlIHRvbyBlYXJseSBmb3IgdGhlIElFVEYgdG8gc3Rh bmRhcmRpemUgYXJvdW5kIHdvdWxkIGZpdA0KPiA+ID4+IGFuDQo+ID4gPj4gPiBJUlRGIFJHIHZl cnkgd2VsbC4gSSdtIGNlcnRhaW5seSBzdXBwb3J0aXZlIG9mIHRoaXMuDQo+ID4gPj4gPg0KPiA+ ID4+ID4gTGFycw0KPiA+ID4+ID4gSVJURiBDaGFpcg0KPiA+ID4+ID4NCj4gPiA+PiA+DQo+ID4g Pj4gPiAtLQ0KPiA+ID4+ID4gTW9iaWxlIG51bWJlciBkdXJpbmcgRGVjZW1iZXI6ICAgICszNTgg NDYgNTIxNTU4Mg0KPiA+ID4+ID4gTW9iaWxlIG51bWJlciBzdGFydGluZyBKYW51YXJ5OiAgKzQ5 IDE1MSAxMjA1NTc5MQ0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPiBhcm1kIG1haWxpbmcgbGlzdA0KPiA+ID4gYXJtZEBp ZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcm1k DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gZGMgbWFpbGluZyBsaXN0DQo+ID4gPiBkY0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYw0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gZGMgbWFpbGluZyBsaXN0DQo+ID4gZGNA aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RjDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRjIG1h aWxpbmcgbGlzdA0KPiBkY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RjDQo= From adalela@cisco.com Tue Dec 27 20:38:31 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E0021F84A6 for ; Tue, 27 Dec 2011 20:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.827 X-Spam-Level: X-Spam-Status: No, score=-3.827 tagged_above=-999 required=5 tests=[AWL=2.772, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3WPokn7bCzN for ; Tue, 27 Dec 2011 20:38:30 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EF59221F84A5 for ; Tue, 27 Dec 2011 20:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=25006; q=dns/txt; s=iport; t=1325047109; x=1326256709; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZjzcHkysnUomZ+ivu7lWGCJ+ibXJ+Gk6Y3E3MrdWUR4=; b=EnLDxGdtUwTIuLCSWOnfuX+mfk8gB9v29fjnK6goDGXWj7dp9Z//c+BB ytDBSaYHycrA2RRIWUgL06ZO5Qmd5gYDX2mUmLD5WdC6O/vcj0hClfwY4 vJixJ9zfUHILmb7cE+9NC6PkHZUSg6OHnaGGTVg/fEzmYt3fTfv2+CsEw Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8AAOib+k6rRDoJ/2dsb2JhbAA5BgOFD5ZcjzOBLYEFgXIBAQEDAQEBAQ8BEA0EMQIBAwMLBQcEAgEGAhEEAQEDAgYGFwECAgIBAR8GHwkIAQEECwgIEweHWAiXKgGMW5EqgS+HKBmCCTNjBIg1lzyHTQ X-IronPort-AV: E=Sophos;i="4.71,418,1320624000"; d="scan'208";a="21092850" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 28 Dec 2011 04:38:28 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBS4cQGF018884; Wed, 28 Dec 2011 04:38:27 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Dec 2011 10:08:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 28 Dec 2011 10:08:24 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102B2515C@XMB-BGL-416.cisco.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94CB@MX14A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] [armd] IP over IP solution for data center interconnect Thread-Index: AczEZWs1enlNW5A7QzOC/pHf9VF1TgAATylAAB0c3tAACjXooAAEnqNwAADXc3A= References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com><618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C5102B25104@XMB-BGL-416.cisco.com><7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9499@MX14A.corp.emc.com> <618BE8B40039924EB9AED233D4A09C5102B25158@XMB-BGL-416.cisco.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94CB@MX14A.corp.emc.com> From: "Ashish Dalela (adalela)" To: X-OriginalArrivalTime: 28 Dec 2011 04:38:26.0413 (UTC) FILETIME=[8A20D1D0:01CCC51A] Cc: dc@ietf.org Subject: Re: [dc] [armd] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 04:38:31 -0000 RGF2aWQsDQoNClRoYW5rcyBhZ2Fpbi4gU28gd2hhdCBpcyB5b3VyIHZpZXcgb2YgdGhlIEwyL0wz IGRlYmF0ZT8gSXMgdGhlIGRpcmVjdGlvbiB0byB1c2UgbW9yZSBvZiBpU0NTSSBhbmQgTkFTIG9y IHRvIGNvbnZlcmdlIEZDIG92ZXIgRXRoZXJuZXQ/IEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIG1h eSBiZSB2ZXJ5IGZldyBGQ29FIGRlcGxveW1lbnRzIHRvZGF5LCBidXQgSSdtIGFza2luZyBpbiB0 ZXJtcyBvZiB5b3VyIHBlcmNlcHRpb24gb2YgdGhlIGRpcmVjdGlvbi4gV2hhdCB0cmVuZHMgd2Ug cGVyY2VpdmUgdmlzLcOgLXZpcyBjbG91ZD8NCg0KVGhhbmtzLCBBc2hpc2gNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGF2aWQuYmxhY2tAZW1jLmNvbSBbbWFpbHRvOmRh dmlkLmJsYWNrQGVtYy5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAyOCwgMjAxMSA5 OjU5IEFNDQpUbzogQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkNCkNjOiBkY0BpZXRmLm9yZw0KU3Vi amVjdDogUkU6IFtkY10gW2FybWRdIElQIG92ZXIgSVAgc29sdXRpb24gZm9yIGRhdGEgY2VudGVy IGludGVyY29ubmVjdA0KDQpBc2hpc2gsDQoNCj4gVGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24u IFNvLCBpdCBpcyBwb3NzaWJsZSB0byBwdWxsIG5ldHdvcmsgYWJzdHJhY3Rpb25zIChWTEFOIGV0 YykgaW50byB0aGUNCj4gc3RvcmFnZSBjb250cm9sbGVyLg0KDQpTdXJlIC0gbm90IG9ubHkgaXMg aXQgcG9zc2libGUsIHRoZXJlJ3MgYWxzbyBwbGVudHkgb2YgZGVwbG95ZWQgc3RvcmFnZSBlcXVp cG1lbnQgdGhhdCBkb2VzIHRoaXMsDQp0b2RheS4gIEFsc28sIHBsZWFzZSBhdm9pZCB1c2Ugb2Yg dGhlIHBocmFzZSAic3RvcmFnZSBjb250cm9sbGVyIiBpbiB0aGlzIGRpc2N1c3Npb24sIGFzIHRo YXQncw0Kb2Z0ZW4gYSBjb21wb25lbnQgb2YgYSBtdWNoIGxhcmdlciBzdG9yYWdlIHN5c3RlbSwg c3RvcmFnZSBhcnJheSwgb3IgZmlsZXNlcnZlci4NCg0KPiBUaGUgc2NoZW1lIGlzIGFsc28gZXh0 ZW5zaWJsZSB0byBvdGhlciB0aGluZ3MgbGlrZSBWWExBTiBvciBOVkdSRS4NCg0KWWVzLg0KDQo+ IFRoZW4geW91IHRpZSB0aGUgZmlsZSBzeXN0ZW0gcGVybWlzc2lvbnMgdG8gdGhlIFZMQU4uIEFt IEkgcmVhZGluZyB0aGlzIGNvcnJlY3RseT8NCg0KTm90IGV4YWN0bHkgOy0pLiAgV2hpbGUgb25l IGNvdWxkIGRvIHRoYXQsIHRoZSByZXN1bHQgY2FuIGJlICJpbnRlcmVzdGluZyIgaWYgdGhlcmUg aXMgSUQNCmR1cGxpY2F0aW9uIGFtb25nIHRlbmFudHMuICBJdCdzIGJldHRlciB0byB1c2Ugc2Vw YXJhdGUgZmlsZXN5c3RlbXMgcGVyIHRlbmFudCAod2l0aCBlYWNoDQpmaWxlc3lzdGVtIHRpZWQg dG8gdGhlIGlkZW50aXR5IHNlcnZpY2UgZm9yIHRoZSBjb3JyZXNwb25kaW5nIHRlbmFudCksIGFu ZCB0aWUgdGhlIGxpc3Qgb3INCnNldCBvZiBleHBvcnRlZCBmaWxlc3lzdGVtcyB0byB0aGUgVkxB TiAob3IgdmlydHVhbCBuZXR3b3JrIGJhc2VkIG9uIFZOSS9UTkkpLiAgVGhlIHJlc3VsdA0KaXMg dGhhdCBpZiBUZW5hbnQgQSBpcyBvbiBhIFZMQU4gKG9yIHZpcnR1YWwgbmV0d29yaykgdGhhdCBp c24ndCBzdXBwb3NlZCB0byBoYXZlIGFjY2VzcyB0bw0KVGVuYW50IEIgZmlsZXN5c3RlbXMsIGl0 IGRvZXNuJ3QgbWF0dGVyIHdoYXQgSURzIG9yIGFkZHJlc3NlcyBhcmUgZHVwbGljYXRlZCBvciBm b3JnZWQgb24NClRlbmFudCBBJ3MgVkxBTiAob3IgdmlydHVhbCBuZXR3b3JrKSAtIFRlbmFudCBC J3MgZmlsZXN5c3RlbXMgYXJlIGluYWNjZXNzaWJsZSAoZS5nLiwgY2FuJ3QNCmJlIG1vdW50ZWQp LiAgRm9yIGlTQ1NJLCBMVU4gbWFwcGluZy9tYXNraW5nIGlzIHRoZSBhbmFsb2dvdXMgZnVuY3Rp b25hbGl0eSwgYW5kIHRoYXQNCmZ1bmN0aW9uYWxpdHkgaXMgd2lkZWx5IGltcGxlbWVudGVkIGlu IHN0b3JhZ2Ugc3lzdGVtcy4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGRjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkYy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkNCj4gU2Vu dDogVHVlc2RheSwgRGVjZW1iZXIgMjcsIDIwMTEgMTE6MDggUE0NCj4gVG86IEJsYWNrLCBEYXZp ZA0KPiBDYzogZGNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkY10gW2FybWRdIElQIG92ZXIg SVAgc29sdXRpb24gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdA0KPg0KPiBEYXZpZCwNCj4N Cj4gVGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24uIFNvLCBpdCBpcyBwb3NzaWJsZSB0byBwdWxs IG5ldHdvcmsgYWJzdHJhY3Rpb25zIChWTEFOIGV0YykgaW50byB0aGUNCj4gc3RvcmFnZSBjb250 cm9sbGVyLiBUaGUgc2NoZW1lIGlzIGFsc28gZXh0ZW5zaWJsZSB0byBvdGhlciB0aGluZ3MgbGlr ZSBWWExBTiBvciBOVkdSRS4gVGhlbiB5b3UgdGllDQo+IHRoZSBmaWxlIHN5c3RlbSBwZXJtaXNz aW9ucyB0byB0aGUgVkxBTi4gQW0gSSByZWFkaW5nIHRoaXMgY29ycmVjdGx5Pw0KPg0KPiBUaGFu a3MsIEFzaGlzaA0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkYXZp ZC5ibGFja0BlbWMuY29tIFttYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbV0NCj4gU2VudDogV2Vk bmVzZGF5LCBEZWNlbWJlciAyOCwgMjAxMSAyOjU2IEFNDQo+IFRvOiBBc2hpc2ggRGFsZWxhIChh ZGFsZWxhKQ0KPiBDYzogZGNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtkY10gW2FybWRdIElQ IG92ZXIgSVAgc29sdXRpb24gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdA0KPg0KPiBBc2hp c2gsDQo+DQo+ID4gSSB3b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGtub3cgaG93IHRoZSBzdG9yYWdl IG11bHRpLXRlbmFuY3kgc29sdXRpb25zIGRlYWwgd2l0aCBwcml2YXRlIElQLCBNQUMgYW5kDQo+ IElEDQo+ID4gaW4gdGhlIHB1YmxpYyBkb21haW4sIHdoaWNoIGNhbiBiZSBkdXBsaWNhdGVkLg0K Pg0KPiBBIGNvbW1vbiBjdXJyZW50IHRlY2huaXF1ZSBpcyB0byB1c2UgcGVyLXRlbmFudCBWTEFO cyAoYSB0ZW5hbnQgbWF5IGhhdmUgbXVsdGlwbGUgVkxBTnMpIGFuZCB1c2UgTkFUDQo+IChhcyBu ZWVkZWQpIGJldHdlZW4gdGhlIFZMQU5zIGFuZCB0aGUgcHVibGljIEludGVybmV0IGluIG9yZGVy IHRvIHNlcGFyYXRlIFZMQU4gYWRkcmVzc2luZyBmcm9tIHB1YmxpYw0KPiBJbnRlcm5ldCBhZGRy ZXNzaW5nLCBlZmZlY3RpdmVseSByZXN1bHRpbmcgaW4gYSAodmlydHVhbCkgTkFUIGluc3RhbmNl IHBlciBWTEFOLiAgQSAxMi1iaXQgVkxBTiB0YWcgaXMNCj4gbm90IGxhcmdlIGVub3VnaCB0byBz Y2FsZSB1cCB0byB0aGUgZGVzaXJlZCBsYXJnZS1zY2FsZSBkYXRhIGNlbnRlciBzY29wZSwgc28g Ym90aCBWeExBTiBhbmQgTlZHUkUgdXNlDQo+IGEgMjQtYml0IHZpcnR1YWwgbmV0d29yayBpZGVu dGlmaWVyIHRvIHJlcGxhY2UgdGhlIDEyLWJpdCBWTEFOIHRhZzsgVnhMQU4gY2FsbHMgdGhpcyBh IFZOSSAoVnhMQU4gW29yDQo+IFZpcnR1YWxdIE5ldHdvcmsgSWRlbnRpZmllciksIGFuZCBOVkdS RSBjYWxscyBpdCBhIFROSSAoVGVuYW50IE5ldHdvcmsgSWRlbnRpZmllcikuICBWTkkgYW5kIFRO SQ0KPiBlbmNhcC9kZWNhcCBjYW4gYmUgaGFuZGxlZCBieSB0aGUgaHlwZXJ2aXNvciBhbmQgYXJl IGxpbWl0ZWQgdG8gdGhlIGRhdGFjZW50ZXI7IGluIHRoaXMgc3RydWN0dXJlLCBWTXMNCj4gY2Fu J3QgdXNlIGEgVk5JIG9yIFROSSBkaXJlY3RseSwgYW5kIHRoZSAodmlydHVhbCkgTkFUIGhhbmRs ZXMgZW5jYXAvZGVjYXAgZm9yIGluYm91bmQvb3V0Ym91bmQNCj4gdHJhZmZpYyBzbyB0aGF0IHRy eWluZyB0byBzZW5kIGVuY2Fwc3VsYXRlZCAoVnhMQU4gb3IgTkdSRSkgdHJhZmZpYyBpbiBmcm9t IHRoZSBvdXRzaWRlIHJlc3VsdHMgaW4NCj4gZG91YmxlIGVuY2Fwc3VsYXRpb24gd2l0aCBubyBl ZmZlY3Qgb24gdGVuYW50IGlzb2xhdGlvbi4NCj4NCj4gQmVmb3JlIG9uZSBvZiB0aGUgTDJWUE4g Zm9sa3MgY29tZXMgYWZ0ZXIgbWUgZm9yIHRoYXQgImxpbWl0ZWQgdG8gdGhlIGRhdGFjZW50ZXIi IGNvbW1lbnQgOy0pIC4uLiBhbg0KPiBMMlZQTiBnYXRld2F5IHdvdWxkIHByb2JhYmx5IHRyYW5z bGF0ZSBiZXR3ZWVuIGEgMjQtYml0IFZOSS9UTkkgYW5kIGEgMjQtYml0IFZQTiBJRCAtIGVuZC10 by1lbmQgdXNlDQo+IG9mIGEgc2luZ2xlIGlkZW50aWZpZXIgZm9yIHRoZSBMMlZQTiBhbmQgdGhl IHZpcnR1YWwgbmV0d29ya3Mgb24gYm90aCBlbmRzIGlzIHBvc3NpYmxlLCBidXQgKElNSE8pDQo+ IGRpZmZpY3VsdCB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBhZG1pbmlzdHJhdGl2ZSBkb21haW5z IGludm9sdmVkIGluIG1hbmFnaW5nIHRoZSBpZGVudGlmaWVycy4NCj4NCj4gVXNlIG9mIFZMQU5z IHRvIHNjb3BlIGZpbGVzeXN0ZW0gdmlzaWJpbGl0eSBvbiBOQVMgZmlsZXNlcnZlcnMgaXMgYSBj b21tb24gZGVwbG95ZWQgcHJhY3RpY2UgaW4NCj4gZGF0YWNlbnRlcnMgKGRpdHRvIGZvciBWTEFO cyB0byBsaW1pdCBpU0NTSSBzdG9yYWdlIHZpc2liaWxpdHkpLCB0aGVyZWJ5IGRlYWxpbmcgd2l0 aCB0aGUgZm9sbG93aW5nOg0KPg0KPiA+IFNvLCB5b3UgaGF2ZSB0bw0KPiA+IHByb3RlY3QgdGhl IG5ldHdvcmsgc3RvcmFnZSBmcm9tIG11bHRpcGxlIHRlbmFudHMgd2hvIGNhbiBoYXZlIHRoZSBz YW1lIElQIGFkZHJlc3MgYW5kIE1BQyBhZGRyZXNzLg0KPiA+IE5BUyBhc3N1bWVzIHlvdXIgaWQg b24gdGhlIFVOSVggaXMgZ2xvYmFsbHkgdW5pcXVlIGFuZCB5b3VyIHBlcm1pc3Npb25zIGFyZSB1 bmlxdWUgLSBub3QgdHJ1ZQ0KPiBhbnltb3JlLg0KPiA+IFNvLCB5b3UgaGF2ZSBJUCwgTUFDIGFu ZCBJRCBkdXBsaWNhdGlvbi4NCj4NCj4gRHVwbGljYXRpb24gb2YgSVAsIE1BQyBhbmQgSUQgb24g c2VwYXJhdGUgVkxBTnMgd29ya3MgZmluZSAtIHRoaXMgbW9kZWwgaXMgY2FycmllZCBvdmVyIHRv IHZpcnR1YWwNCj4gbmV0d29ya3MgYmFzZWQgb24gVk5JIG9yIFROSS4gIFRoZSBzZW50ZW5jZSBj b250YWluaW5nICJnbG9iYWxseSB1bmlxdWUiIChpbmNvcnJlY3RseSkgYXNzdW1lcyBhDQo+IHNp bmdsZSBmaWxlc2VydmVyOyBpbnN0ZWFkLCBjb25zaWRlciBhIHNpbmdsZSBOQVMgc3lzdGVtIHBy ZXNlbnRpbmcgd2hhdCBpcyBlZmZlY3RpdmVseSBhIHZpcnR1YWwNCj4gZmlsZXNlcnZlciBwZXIg VkxBTiAob3IgVk5JL1ROSSkgYW5kIHNpbWlsYXJseSBmb3IgaVNDU0kgLSB0aGF0IGlzIHdoYXQg c29ydHMgb3V0IHRoaXMgZHVwbGljYXRpb24sDQo+IGluY2x1ZGluZyB1c2Ugb2YgZGlmZmVyZW50 IGlkZW50aXR5IHNlcnZpY2VzL3NlcnZlcnMgcGVyIFZMQU4gKG9yIFZOSS9UTkkpLg0KPg0KPiBU aGFua3MsDQo+IC0tRGF2aWQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiBEYXZpZCBMLiBCbGFjaywgRGlzdGluZ3Vpc2hlZCBFbmdpbmVl cg0KPiBFTUMgQ29ycG9yYXRpb24sIDE3NiBTb3V0aCBTdC4sIEhvcGtpbnRvbiwgTUEgIDAxNzQ4 DQo+ICsxICg1MDgpIDI5My03OTUzICAgICAgICAgICAgIEZBWDogKzEgKDUwOCkgMjkzLTc3ODYN Cj4gZGF2aWQuYmxhY2tAZW1jLmNvbSAgICAgICAgTW9iaWxlOiArMSAoOTc4KSAzOTQtNzc1NA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBkYy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFzaGlzaCBE YWxlbGEgKGFkYWxlbGEpDQo+ID4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjcsIDIwMTEgMjo1 MCBBTQ0KPiA+IFRvOiBQZWRybyBNYXJxdWVzDQo+ID4gQ2M6IGRjQGlldGYub3JnDQo+ID4gU3Vi amVjdDogUmU6IFtkY10gW2FybWRdIElQIG92ZXIgSVAgc29sdXRpb24gZm9yIGRhdGEgY2VudGVy IGludGVyY29ubmVjdA0KPiA+DQo+ID4gVGhlcmUgaXMgSW5maW5pQmFuZCBiZXNpZGVzIEZpYmVy Q2hhbm5lbC4gQW5kIHdlIGFyZSB0YWxraW5nIGFib3V0IGNvbnZlcmdpbmcgbm90IHNlcGFyYXRp bmcgdGhlbS4NCj4gVGhlDQo+ID4gcXVlc3Rpb24gaXMgY29udmVyZ2Ugb3ZlciBMMiBvciBMMy4g SSB0aGluayB5b3UgZGlkIG5vdCByZWFkIG1lIGNvcnJlY3RseS4gSVAgYmFzZWQgc29sdXRpb25z IGhhdmUNCj4gPiBiZWVuIGRlZmluZWQgYmVmb3JlIEV0aGVybmV0IHNvbHV0aW9ucyBidXQgbm90 IHVzZWQgd2lkZWx5LiBXZSBjYW4gZGlzY3VzcyB3aHkuDQo+ID4NCj4gPiBJIHdvdWxkIGJlIGlu dGVyZXN0ZWQgdG8ga25vdyBob3cgdGhlIHN0b3JhZ2UgbXVsdGktdGVuYW5jeSBzb2x1dGlvbnMg ZGVhbCB3aXRoIHByaXZhdGUgSVAsIE1BQyBhbmQNCj4gSUQNCj4gPiBpbiB0aGUgcHVibGljIGRv bWFpbiwgd2hpY2ggY2FuIGJlIGR1cGxpY2F0ZWQuDQo+ID4NCj4gPiBUaGUgYXJndW1lbnQgd2Fz IG5vdCBhcm91bmQgbG9hZC1iYWxhbmNpbmcsIGl0IGlzIGFyb3VuZCBkaXNjb3ZlcnkuDQo+ID4N Cj4gPiBZb3VyIGV4YW1wbGUgb2YgdGhlIGh5cGVydmlzb3IgaXMgaW50ZXJlc3RpbmcuIEknbSBh d2FyZSB0aGF0IEFtYXpvbiBkb2VzIHRoaW5ncyBpbiB0aGUgaHlwZXJ2aXNvci4NCj4gPiBUaGV5 IHByb3ZpZGUgSVAgbW9iaWxpdHkgdGhyb3VnaCBOQVQuIFNlY3VyaXR5IHRocm91Z2ggYSBoeXBl cnZpc29yIGZpcmV3YWxsLiBUaGUgY29uc2VxdWVuY2UgaXMNCj4gdGhhdA0KPiA+IHlvdSBwYXkg ZXh0cmEgaWYgeW91IHdhbnRlZCBhIG1vYmlsZSBWTSwgYW5kIHlvdSBtYW5hZ2UgeW91ciBvd24g ZmlyZXdhbGwgKGF0IGxlYXN0IHRoZSBsYXN0IHRpbWUgSQ0KPiA+IGNoZWNrZWQpLiBJZiB0ZW5h bnQgaXNvbGF0aW9uIGlzIGFsbCB0aGUgd2F5IGludG8gdGhlIGhvc3QsIHRoZW4gbmV0d29yayBR b1MsIGJhbmR3aWR0aCBldGMgaXMgYWxzbw0KPiA+IG1vb3QuDQo+ID4NCj4gPiBUaGFua3MsIEFz aGlzaA0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206 IFBlZHJvIE1hcnF1ZXMgW21haWx0bzpwZWRyby5yLm1hcnF1ZXNAZ21haWwuY29tXQ0KPiA+IFNl bnQ6IFR1ZXNkYXksIERlY2VtYmVyIDI3LCAyMDExIDEyOjMyIFBNDQo+ID4gVG86IEFzaGlzaCBE YWxlbGEgKGFkYWxlbGEpDQo+ID4gQ2M6IGRjQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtk Y10gW2FybWRdIElQIG92ZXIgSVAgc29sdXRpb24gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVj dA0KPiA+DQo+ID4gMjAxMS8xMi8yNiBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKSA8YWRhbGVsYUBj aXNjby5jb20+Og0KPiA+ID4gRm9yIGFsbCB0aGUgcHJvcG9uZW50cyBvZiBMMywgaGVyZSBpcyBh IHRob3VnaHQuDQo+ID4NCj4gPiBzdW1tYXJ5IG9mIHRoZSBvcmlnaW5hbCBlbWFpbDogbXVsdGkt dGVuYW50IHN0b3JhZ2Ugc29sdXRpb25zIHJlcXVpcmUNCj4gPiBGaWJlckNoYW5uZWw7IGFuIEwz IHNlcnZpY2UgbW9kZWwgZG9lc24ndCBzdXBwb3J0IEZpYmVyQ2hhbm5lbC4NCj4gPg0KPiA+IFRo ZXJlIGFyZSBtdWx0aXBsZSBzdG9yYWdlIHNvbHV0aW9ucyB0aGF0IHN1cHBvcnQgbXVsdGktdGVu YW5jeSB0aGF0DQo+ID4gd29yayBvbiB0b3Agb2YgSVAgbWFraW5nIHRoZSBhcmd1bWVudCBtb290 ICgxKS4gQXQgbGFyZ2Ugc2NhbGUgcnVubmluZw0KPiA+IGEgc2VwYXJhdGUgbmV0d29yayBmb3Ig ZGF0YSBhbmQgZm9yIHN0b3JhZ2UgaW1wb3NlcyB2ZXJ5IHNpZ25pZmljYW50DQo+ID4gY29zdHMu IEknZCB2ZW50dXJlIHRoYXQgdGhlIHByb3BvbmVudHMgb2YgTDMgaGF2ZSB2ZXJ5IGxpdHRsZSBp bnRlcmVzdA0KPiA+IGluIEZpYmVyQ2hhbm5lbC4NCj4gPg0KPiA+IFRoZSBzYW1lIGdvZXMgZm9y IHRoZSBhcmd1bWVudCB0aGF0IGxvYWQtYmFsYW5jaW5nIHJlcXVpcmVzIEwyLiBUaGVyZQ0KPiA+ IGlzIGV4aXN0ZW5jZSBwcm9vZiBvZiB0aGUgY29udHJhcnkuDQo+ID4NCj4gPiBUaGVyZSBpcyBh IHdpZGUgcmFuZ2Ugb2YgdGVjaG5vbG9neSBjaG9pY2VzIGF2YWlsYWJsZSBpbiB0aGlzIHNwYWNl Lg0KPiA+IEknbSBzdXJlIHRoZXJlIGlzIGludGVyZXN0IGluIEwyIGJhc2VkIHNvbHV0aW9ucyBi dXQgdGhlIGNsYWltIHRoYXQgTDMNCj4gPiBiYXNlZCBzb2x1dGlvbnMgYXJlIG5vdCBmZWFzaWJs ZSBoYXMgYWxyZWFkeSBiZWVuIGRpc3Byb3ZlZCBieQ0KPiA+IGRlcGxveWVkIHNvbHV0aW9ucy4N Cj4gPg0KPiA+IDEgLSBFeGFtcGxlOiBXaGVuIGEgc3RvcmFnZSBzb2x1dGlvbiBwcmVzZW50cyBh IGJsb2NrIGRldmljZSB0byB0aGUgVk0NCj4gPiAoZS5nLiBBbWF6b24gRUJTKSBpdCBpcyB0aGUg aG9zdCBPUy9oeXBlcnZpc29yIHRoYXQgbWFwcyB0aGUgZ3Vlc3QgT1MNCj4gPiBvcGVyYXRpb25z IGludG8gbmV0d29yayBvcGVyYXRpb25zOyBkb2luZyBzbyBpbiB0aGUgaW5mcmFzdHJ1Y3R1cmUN Cj4gPiBuZXR3b3JrIHJlYWwgcmF0aGVyIHRoYW4gaW4gdGhlIHRlbmFudCdzIG5ldHdvcmsgcmVh bG0uDQo+ID4NCj4gPiA+DQo+ID4gPiBUaGUgYmlnZ2VzdCBjb25jZXJuIGluIGNsb3VkIGlzIGRh dGEgcHJvdGVjdGlvbi4gVGhhdCBpcyBqdXN0IG1ha2Ugb3IgYnJlYWsuIERhdGEgY2FuJ3QgbW92 ZSB3aGVuDQo+ID4gdGhlIFZNIG1vdmVzLiBJdCdzIGp1c3QgdG9vIGV4cGVuc2l2ZSBhbmQgdGlt ZSBjb25zdW1pbmcuIEZ1cnRoZXIsIHRvIHJlZHVjZSBkaXNrIHdhc3RhZ2UgeW91IGhhdmUNCj4g dG8NCj4gPiBwdXQgZGF0YSBvbiBuZXR3b3JrIHN0b3JhZ2UuIFRoYXQncyBqdXN0IGVhc3kgZm9y IGRhdGEgYmFja3VwLCBhbmQgY2hlYXAgaW4gdGVybXMgb2YgdG90YWwgZGlzaw0KPiBzcGFjZQ0K PiA+IHlvdSBuZWVkLiBUaGVyZSBpcyBhIGxvdCBnb2luZyBvbiBoZXJlIGluIHRlcm1zIG9mIGRh dGEgZGUtZHVwbGljYXRpb24uDQo+ID4gPg0KPiA+ID4gTm93IGdpdmVuIG5ldHdvcmsgc3RvcmFn ZSwgeW91IGhhdmUgdHdvIG9wdGlvbnMgLSBOQVMgYW5kIFNBTi4NCj4gPiA+DQo+ID4gPiBPbiB0 aGUgY2xvdWQgZWFjaCBWTSBhZG1pbmlzdHJhdG9yIGhhcyByb290IHByaXZpbGVnZXMuIEFuZCBJ UCBhbmQgTUFDIGFkZHJlc3NlcyBjYW4gYmUgZHVwbGljYXRlZA0KPiA+IChpZiB5b3UgYXJlIHJv b3QganVzdCBjb25maWd1cmUgYW55IElQIGFuZCBNQUMgb24gYSB2aXJ0dWFsIGludGVyZmFjZSBv ZiBjaG9pY2UpLiBTbywgeW91IGhhdmUgdG8NCj4gPiBwcm90ZWN0IHRoZSBuZXR3b3JrIHN0b3Jh Z2UgZnJvbSBtdWx0aXBsZSB0ZW5hbnRzIHdobyBjYW4gaGF2ZSB0aGUgc2FtZSBJUCBhZGRyZXNz IGFuZCBNQUMgYWRkcmVzcy4NCj4gPiBOQVMgYXNzdW1lcyB5b3VyIGlkIG9uIHRoZSBVTklYIGlz IGdsb2JhbGx5IHVuaXF1ZSBhbmQgeW91ciBwZXJtaXNzaW9ucyBhcmUgdW5pcXVlIC0gbm90IHRy dWUNCj4gYW55bW9yZS4NCj4gPiBTbywgeW91IGhhdmUgSVAsIE1BQyBhbmQgSUQgZHVwbGljYXRp b24uDQo+ID4gPg0KPiA+ID4gVGhhdCBtZWFucyB0aGF0IGlmIHlvdSBoYXZlIHRvIHByb3RlY3Qg ZGF0YSwgeW91IGhhdmUgdG8ga25vdyBzb21laG93IHdoaWNoIGhvc3QgaXMgYWxsb3dlZCB0byBz ZWUNCj4gPiB3aGljaCBkaXNrcy4gRG9pbmcgdGhpcyBlbmQtdG8tZW5kIHVzaW5nIFRDUC9JUCBp cyBwcm9ibGVtYXRpYyBiZWNhdXNlIHRoZSBOQVMgY29udHJvbGxlciBkb2Vzbid0DQo+IGtub3cN Cj4gPiBhYm91dCB0ZW5hbnQgaWQsIGFuZCB3aGV0aGVyIHRoZSBNQUMgYW5kIElQIGFyZSBiZWlu ZyBkdXBsaWNhdGVkIGFjcm9zcyBjdXN0b21lcnMuIFRvIG1ha2UgdGhlDQo+IHN0b3JhZ2UNCj4g PiBhd2FyZSBvZiBzZWdtZW50YXRpb24sIHlvdSBoYXZlIHRvIGNhcnJ5IHNvbWUgc2VnbWVudCAo R1JFLCBNUExTLCBWTEFOLCBldGMuKSBpbnRvIHRoZSBzdG9yYWdlIGJveC4NCj4gPiBUaGF0J3Mg bm90IHRydWUgdG9kYXkuDQo+ID4gPg0KPiA+ID4gTmV0d29yayBsZXZlbCBpc29sYXRpb24gaGFw cGVucyBpbiBTQU4sIGJ1dCBub3QgaW4gTkFTLiBOQVMganVzdCBydW5zIGVuZC10by1lbmQgb3Zl ciBUQ1AuIEluIFNBTg0KPiA+IHlvdSBjYW4gc2F5IHdoaWNoIGhvc3Qgd2lsbCBzZWUgd2hpY2gg ZGlzay4gVGhlIEZDIHNlY3VyaXR5IGlzIGhpZ2ggYmVjYXVzZSBNQUMgYW5kIEZDLUlEIGlzDQo+ IGFzc2lnbmVkDQo+ID4gYnkgdGhlIG5ldHdvcmsgYW5kIG5vdCBpbiB0aGUgY29udHJvbCBvZiB0 aGUgaG9zdC4gVGhlIG5ldHdvcmsga25vd3Mgd2hpY2ggcG9ydCBpcyB3aGljaCBob3N0L01BQy4N Cj4gU28sDQo+ID4gaWYgeW91IG9ubHkga25vdyB3aGljaCBwb3J0IGlzIHdoaWNoIGN1c3RvbWVy LCB5b3Uga25vdyB3aGljaCBNQUMgY2FuIHNlZSB3aGljaCBkaXNrLiBCaW5kaW5nIGEgcG9ydA0K PiA+IHRvIGEgY3VzdG9tZXIgaXMgbm90IGhhcmQuIEJ1dCBtYXBwaW5nIGFsbCBvZiB0aGF0IHRv IGRhdGEgc2VjdXJpdHkgYW5kIGRpc2sgdmlzaWJpbGl0eSBpcyBub3QNCj4gPiB0cml2aWFsLiBF LmcuIHlvdSBoYXZlIHRvIGRvIEdSRSB0dW5uZWwgbWFwcGluZyB0byBhIHNldCBvZiBkaXNrIHBl cm1pc3Npb25zLiBXaG8gbmVlZHMgdGhhdD8NCj4gPiA+DQo+ID4gPiBTQU4gZG9lcyBub3QgdXNl IElQLiBJdCB1c2VzIEZpYmVyIENoYW5uZWwuIFdpdGggY29udmVyZ2VuY2UsIHdlIGFyZSBtb3Zp bmcgdG8gRkMgb3ZlciBFdGhlcm5ldA0KPiA+IChGQ29FKS4gRkNJUCBhbmQgaVNDU0kgaGF2ZSBu b3Qgd29ya2VkIHZlcnkgd2VsbC4gU2VjdXJpdHkgZm9yIGRhdGEgY29tZXMgZnJvbSBGQyBhbmQg bG93ZXJpbmcgb2YNCj4gY29zdA0KPiA+IGNvbWVzIGZyb20gdXNlIG9mIEZDb0UuIFRoYXQgbmVl ZHMgbmF0aXZlIEV0aGVybmV0IChubyBJUCkuDQo+ID4gPg0KPiA+ID4gV2hlbiB5b3UgaGF2ZSBz aXRlLXRvLXNpdGUgVk0gbW9iaWxpdHksIGRhdGEgaXMgbm90IG1vdmluZyBhY3Jvc3Mgc2l0ZXMu IEUuZy4gYW4gYXBwbGljYXRpb24NCj4gc2VydmVyDQo+ID4gd2lsbCBjb25uZWN0IHRvIGEgc2V0 IG9mIGxvYWQtYmFsYW5jZWQgc2V0IG9mIGRhdGFiYXNlIHNlcnZlcnMgd2l0aGluIGEgVkxBTi4g VGhlIGFwcGxpY2F0aW9uIGFuZA0KPiA+IGRhdGFiYXNlIHNlcnZlcnMgY2FuIGJlIGRpZmZlcmVu dCBzaXRlcywgYW5kIHRoZXkgY29ubmVjdCBvdmVyIGEgVkxBTi4gQWx0ZXJuYXRlbHksIHRoZSBh cHBsaWNhdGlvbg0KPiA+IGFuZCBkYXRhYmFzZSBzZXJ2ZXJzIGNhbiBiZSBpbiB0aGUgc2FtZSBs b2NhdGlvbiBhbmQgdGhlIERCIHNlcnZlciBhY2Nlc3NlcyB0aGUgU0FOIG92ZXIgdGhlDQo+IElu dGVybmV0Lg0KPiA+IEV2ZW4gaWYgZGF0YSBpcyByZXBsaWNhdGVkIGFjcm9zcyBtYW55IHNpdGVz LCBsb2FkLWJhbGFuY2luZyBhY3Jvc3MgYXBwbGljYXRpb24gb3IgZGIgc2VydmVycyB1c2VzDQo+ ID4gVkxBTnMuIEluIEhQQyBhcyB3ZWxsLCB0aGVyZSBpcyBhIGxvdCBvZiBicm9hZGNhc3QgYW5k IGRpc2NvdmVyeSwgYW5kIHRoaXMgbWF5IHVzZSBJUCBvciBub3QsIHRoZQ0KPiBmYWN0DQo+ID4g aXMgdGhhdCBpdCBkZXBlbmRzIG9uIGJyb2FkY2FzdC4gVGhlIEhQQyBjYXNlIGV4dGVybmFsaXpl cyB0aGUgbWVtb3J5IG9uIGEgaG9zdCB0byBvdGhlciBob3N0cw0KPiB0aHJvdWdoDQo+ID4gUkRN QS4gRXZlcnl0aGluZyB0byBkbyB3aXRoIEJpZyBEYXRhIHdpbGwgcmVseSBvbiB0aGlzLCBhbmQg YmVzaWRlcyBkaXNrIGV4dGVybmFsaXphdGlvbiB3ZSB3aWxsDQo+IGFsc28NCj4gPiBzZWUgaW5j cmVhc2UgaW4gbWVtb3J5IGV4dGVybmFsaXphdGlvbi4gSSBqdXN0IHdlbnQgdG8gYSBJRUVFIEhQ QyBjbG91ZCBjb25mZXJlbmNlIDotKQ0KPiA+ID4NCj4gPiA+IEwzIGFzc3VtZXMgdGhhdCBhbGwg ZGF0YSAoZGlzayBhbmQgbWVtb3J5KSBpcyBpbnNpZGUgdGhlIGhvc3QuIFRoYXQgYXNzdW1wdGlv biBjaGFuZ2VkIGEgZGVjYWRlDQo+IGFnby4NCj4gPiBDbG91ZCBqdXN0IGluY3JlYXNlcyB0aGUg ZGlzdHJpYnV0aW9uLiBKdXN0IGFzIGNvbXB1dGUgaXMgb3B0aW1pemVkIGJ5IG11eGluZyB0aGUg Vk1zIG9uIGEgcGh5c2ljYWwNCj4gPiBtYWNoaW5lLCBzdG9yYWdlIGlzIG9wdGltaXplZCBieSBj b25zb2xpZGF0aW5nIGRhdGEgc2VwYXJhdGVseSBvbiBzdG9yYWdlIGRldmljZXMgYW5kIG1lbW9y eSBieQ0KPiA+IGhvc3RpbmcgaXQgaW4gZGlmZmVyZW50IGhvc3RzLiBOZXR3b3JrIGhhcyB0byBk ZWFsIHdpdGggYWxsIHR5cGVzIG9mIHRyYWZmaWMgYW5kIHNlY3VyaXR5L2lzb2xhdGlvbg0KPiA+ IChpbWFnaW5lIHNvbWVvbmUgY2hhbmdpbmcgbWVtb3J5IG92ZXIgdGhlIG5ldHdvcmspLiBTdG9y YWdlIGFuZCBtZW1vcnkgdHJhZmZpYyB1c2VzIEwyLiBUbyBkaXNjb3Zlcg0KPiA+IGVhY2ggb3Ro ZXIsIGhvc3RzIHVzZSBMMi4gVGhlc2UgTDIgZG9tYWlucyBuZWVkIHRvIHNwYW4gYWNyb3NzIHNp dGVzIGFuZCB3aXRoaW4gdGhlIHNpdGUuDQo+ID4gPg0KPiA+ID4gVGhpcyBhcmUgbm90IGNvcm5l ciBjYXNlcy4gVGhpcyBpcyBqdXN0IGNlbnRyYWwgdG8gd2hhdCBjbG91ZCBtZWFucyBpbiB0aGUg bG9uZyBydW4uDQo+ID4gPg0KPiA+ID4gVGhhbmtzLCBBc2hpc2gNCj4gPiA+DQo+ID4gPg0KPiA+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IGFybWQtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmFybWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlh b2h1DQo+ID4gPiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDIzLCAyMDExIDEyOjA5IFBNDQo+ID4g PiBUbzogRWdnZXJ0LCBMYXJzOyBkY0BpZXRmLm9yZzsgZGNyZy1pbnRlcmVzdEBpcnRmLm9yZw0K PiA+ID4gQ2M6IGFybWRAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbYXJtZF0gSVAgb3Zl ciBJUCBzb2x1dGlvbiBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0DQo+ID4gPg0KPiA+ID4N Cj4gPiA+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4gPj4g5Y+R5Lu25Lq6OiBYdXhpYW9o dQ0KPiA+ID4+IOWPkemAgeaXtumXtDogMjAxMeW5tDEy5pyIMjLml6UgMTY6MjgNCj4gPiA+PiDm lLbku7bkuro6ICdFZ2dlcnQsIExhcnMnOyBkY0BpZXRmLm9yZzsgJ2RjcmctaW50ZXJlc3RAaXJ0 Zi5vcmcuJw0KPiA+ID4+IOS4u+mimDogSVAgb3ZlciBJUCBzb2x1dGlvbiBmb3IgZGF0YSBjZW50 ZXIgaW50ZXJjb25uZWN0DQo+ID4gPj4NCj4gPiA+PiBIaSBhbGwsDQo+ID4gPj4NCj4gPiA+PiBU aGVyZSBoYXMgYmVlbiBhIGxvdCBvZiBMMiBvdmVyIEwzIHNvbHV0aW9ucyBvciBwcm9wb3NhbHMg Zm9yIGRhdGEgY2VudGVyDQo+ID4gPj4gbmV0d29yayBhbmQgZGF0YSBjZW50ZXIgaW50ZXJjb25u ZWN0IHRpbGwgbm93LiBIb3dldmVyLCBpdCBzZWVtcyByZWNlbnRseQ0KPiA+ID4+IHRoZXJlIGFy ZSBpbmNyZWFzaW5nIGludGVyZXN0cyBvbiBMMyBvdmVyIEwzIChlLmcuLCBJUCBvdmVyIElQKSBz b2x1dGlvbnMgZm9yIGRhdGENCj4gPiA+PiBjZW50ZXIgbmV0d29yayBhbmQgZGF0YSBjZW50ZXIg aW50ZXJjb25uZWN0LCBwbGVhc2Ugc2VlIHRoZSBmb2xsb3dpbmcgdGV4dA0KPiA+ID4+IHF1b3Rl ZCBmcm9tIElFVEY4MiBMMlZQTiBtaW51dGVzDQo+ID4gPj4gKCBodHRwczovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy84Mi9taW51dGVzL2wydnBuLnR4dCkuIEl0J3MgYSBnZW5lcmFsIGJlbGll Zg0KPiA+ID4+IHRoYXQgTDMgaXMgbW9yZSBzY2FsYWJsZSB0aGFuIEwyLiBFc3BlY2lhbGx5IHdo ZW4gY29uc2lkZXJpbmcgdGhlIGRhdGEgY2VudGVyDQo+ID4gPj4gaW50ZXJjb25uZWN0aW9uIGNh c2UsIHRoZSBMMyBvdmVyIEwzIHNvbHV0aW9ucyBjYW4gYnJpbmcgREMgb3BlcmF0b3JzIG1vcmUN Cj4gPiA+PiBiZW5lZml0cyBjb21wYXJlZCB0byB0aGUgTDIgb3ZlciBMMyBzb2x1dGlvbnMsIHN1 Y2ggYXMgcGF0aCBvcHRpbWl6YXRpb24sDQo+ID4gPj4gYWN0aXZlLWFjdGl2ZSBkYXRhIGNlbnRl cnMsIE1BQyB0YWJsZSByZWR1Y3Rpb24gb24gREMgc3dpdGNoZXMgYW5kIGJyb2FkY2FzdA0KPiA+ ID4+IGZsb29kIHN1cHByZXNzaW9uIGV0YyAuDQo+ID4gPg0KPiA+ID4gQnkgdGhlIHdheSwgdGhl IEFSUCB0YWJsZSBzY2FsaW5nIGlzc3VlIG9uIERDIGdhdGV3YXlzLCB3aGljaCBpcyBkZWVtZWQg YnkgdGhlIEFSTUQgV0cgYXMgdGhlIG9ubHkNCj4gPiB3b3J0aHkgQVJQIHByb2JsZW0gaW4gZGF0 YSBjZW50ZXIgbmV0d29ya3MsIGNvdWxkIGFsc28gYmUgc29sdmVkIHdpdGggdGhlIElQIG92ZXIg SVAgc29sdXRpb24uDQo+ID4gPg0KPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gWGlhb2h1DQo+ ID4gPg0KPiA+ID4+DQo+ID4gPj4gQWx0aG91Z2ggTGF5ZXIgMiBjb25uZWN0aXZpdHkgaXMgc3Rp bGwgcmVxdWlyZWQgZm9yIHNvbWUgaGlnaC1hdmFpbGFiaWxpdHkgY2x1c3RlcnMNCj4gPiA+PiB3 aGljaCB1c2Ugbm9uLUlQIGFuZCBsaW5rLWxvY2FsIG11bHRpY2FzdCBmb3IgY29tbXVuaWNhdGlv biwgbW9yZSBhbmQgbW9yZQ0KPiA+ID4+IGNsdXN0ZXIgdmVuZG9ycyBhcmUgZWl0aGVyIGFscmVh ZHkgYWJsZSB0byBzdXBwb3J0IGNsdXN0ZXIgc2VydmljZXMgYXQgTGF5ZXIzIG9yDQo+ID4gPj4g d2lsbCBzdXBwb3J0IGl0IGluIHRoZSBuZWFyIGZ1dHVyZS4gSW4gYWRkaXRpb24sIHRoZSBHU0xC IG1lY2hhbmlzbSAoZS5nLiwgRE5TDQo+ID4gPj4gYmFzZWQgR1NMQikgd29ya3MgdmVyeSB3ZWxs IGluIG1vc3QgY2FzZXMsIGlzIGdlby1jbHVzdGVyIHNlcnZpY2Ugc3RpbGwgYQ0KPiA+ID4+IGNv bW1vbiByZXF1aXJlbWVudCBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0PyBJZiBub3QsIGNv dWxkIHdlIHNwZW5kIGFueQ0KPiA+ID4+IHRpbWUgb24gZXhwbG9yaW5nIHRoZSBwb3NzaWJpbGl0 eSBvZiB1c2luZyBMMyBvdmVyIEwzIHNvbHV0aW9uIGZvciB0aGUgbW9zdCBkYXRhDQo+ID4gPj4g Y2VudGVyIGludGVyY29ubmVjdGlvbiBzY2VuYXJpb3Mgd2hlcmUgZ2VvLWNsdXN0ZXJpbmcsIGVz cGVjaWFsbHkgbm9uLUlQIGJhc2VkDQo+ID4gPj4gZ2VvLWNsdXN0ZXJpbmcgaXMgbm90IG5lZWRl ZD8NCj4gPiA+Pg0KPiA+ID4+IEJlc3QgcmVnYXJkcywNCj4gPiA+PiBYaWFvaHUNCj4gPiA+Pg0K PiA+ID4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNCj4gPiA+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4gPj4gS2lyZWV0aTogSSBrZWVwIHNlZWluZyBJ U0lELCBQQkIsIFZMQU5zLiAgV2UgaGF2ZSB0byBzdG9wIGNvbmNlZGluZyB0byBsYXllciAyDQo+ ID4gPj4gYW5kIHN0YXJ0IG1vdmluZyB0byBsYXllciAzIChhcHBsYXVzZSkgYW5kIGxvdHMgb2Yg cHJvYmxlbXMgd2lsbCBnbyBhd2F5Lg0KPiA+ID4+DQo+ID4gPj4gRmxvcmluOiBXZSBzaG91bGQg cHV0IFZQTiBvbiB0aGUgc2FtZSBwYWdlIHRvIG1vZGlmeSB0aGUgcHJpb3JpdGllcy4gWW91IG5l ZWQNCj4gPiA+PiB0byBleHBhbmQgc28gY2FuIGxvb2sgYXQgTDMgb3ZlciBMMyBhcyB3ZWxsIGFz IEwyIG92ZXIgTDMuIEZvciBpdGVtIG51bWJlciAyIHdlDQo+ID4gPj4gbmVlZCB0byBsb29rIGF0 IEwzIHRyYW5zcG9ydCBhcyB3ZWxsIGFzIEV0aGVybmV0IGFuZCBNUExTLiAgQW5kIGZvciBudW1i ZXIgMw0KPiA+ID4+IHdlIG5lZWQgdG8gd29yayBvbiB0aGlzIGFzIHRoZXJlJ3MgYSBsb3Qgb2Yg ZXhwZXJ0aXNlIGluIEwyLCBMMyBhbmQgb3RoZXIgV0dzLg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+ PiBNYXJjOiBUaGUgcHJvYmxlbSBzdGF0ZW1lbnQgbmVlZHMgdG8gaW5jbHVkZSBtb3JlIG9mIHRo ZSBMMyBpc3N1ZXMgYXJvdW5kDQo+ID4gPj4gc2VuZGluZyBMMiBvdmVyIEwzLCBhcyB0aGUgTDIg dHJhZmZpYyBhbHJlYWR5IGNvbnRhaW5zIEwzLiAgSXNzdWUgaXMganVzdCBmcmFtaW5nLg0KPiA+ ID4+DQo+ID4gPj4gRXJpYyBOb3JkbWFyazsgIlllcywgWWVzIGFuZCBZZXMiLiAgV2UgbmVlZCB0 byBmb2N1cyBmcm9tIHRoZSBEQyBwcm9zcGVjdGl2ZQ0KPiA+ID4+IGFuZCBub3QgZnJvbSB0aGUg VlBOIHZpZXcuICBkb24ndCBqdXN0IHRoaW5rIGFib3V0IEV0aGVybmV0IG92ZXIgSVAsIGJ1dCBh bHNvIElQDQo+ID4gPj4gb3ZlciBJUC4gIEh5cGVydmlzb3IgbWF5IGdldCBkZWNvdXBsZWQgb3Zl ciB0aW1lLg0KPiA+ID4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCj4gPiA+PiAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4gPj4gPiAtLS0tLemCruS7tuWO n+S7ti0tLS0tDQo+ID4gPj4gPiDlj5Hku7bkuro6IGRjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpkYy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggRWdnZXJ0LA0KPiA+ID4+IExhcnMNCj4gPiA+ PiA+IOWPkemAgeaXtumXtDogMjAxMeW5tDEy5pyIMTbml6UgMTY6MjQNCj4gPiA+PiA+IOaUtuS7 tuS6ujogZGNAaWV0Zi5vcmcNCj4gPiA+PiA+IOS4u+mimDogW2RjXSBJUlRGIGRhdGFjZW50ZXIg cmVzZWFyY2ggZ3JvdXAgZGlzY3Vzc2lvbiBsaXN0DQo+ID4gPj4gPg0KPiA+ID4+ID4gSGksDQo+ ID4gPj4gPg0KPiA+ID4+ID4gSSB3YW50ZWQgdG8gbWFrZSB5b3UgYWxsIGF3YXJlIG9mIHRoZSBJ UlRGJ3MgZGNyZy1pbnRlcmVzdCBtYWlsaW5nIGxpc3QsIHdoaWNoDQo+ID4gPj4gPiB3YXMgc2V0 IHVwIGZvbGxvd2luZyBhIGZhY2UtdG8tZmFjZSBtZWV0aW5nIGF0IFNJR0NPTU0gdGhpcyB5ZWFy IHRvIGRpc2N1c3MNCj4gPiA+PiBhDQo+ID4gPj4gPiBwb3NzaWJsZSBJUlRGIHJlc2VhcmNoIGdy b3VwIG9uIGRhdGFjZW50ZXIgbmV0d29ya2luZzoNCj4gPiA+PiA+IGh0dHA6Ly9pcnRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RjcmctaW50ZXJlc3QNCj4gPiA+PiA+DQo+ID4gPj4gPiBUaGVyZSBo YXMgbm90IGJlZW4gbXVjaCBhY3Rpdml0eSB0b3dhcmRzIHRoZSBmb3JtYXRpb24gb2YgYW4gSVJU RiBSRyBzaW5jZQ0KPiA+ID4+ID4gU0lHQ09NTSwgYnV0IEkgYW0gaG9wZWZ1bCB0aGF0IHRoZSBo aWdoIGVuZXJneSBsZXZlbCBkZW1vbnN0cmF0ZWQgaW4gdGhlDQo+ID4gPj4gPiB2YXJpb3VzIFRh aXBlaSBtZWV0aW5ncyBvbiB0aGUgdG9waWMgd2lsbCBpbmplY3Qgc29tZSBlbmVyZ3kgaGVyZSAt IHNldmVyYWwgb2YNCj4gPiA+PiA+IHRoZSB0b3BpY3MgdGhhdCBtYXkgYmUgdG9vIGVhcmx5IGZv ciB0aGUgSUVURiB0byBzdGFuZGFyZGl6ZSBhcm91bmQgd291bGQgZml0DQo+ID4gPj4gYW4NCj4g PiA+PiA+IElSVEYgUkcgdmVyeSB3ZWxsLiBJJ20gY2VydGFpbmx5IHN1cHBvcnRpdmUgb2YgdGhp cy4NCj4gPiA+PiA+DQo+ID4gPj4gPiBMYXJzDQo+ID4gPj4gPiBJUlRGIENoYWlyDQo+ID4gPj4g Pg0KPiA+ID4+ID4NCj4gPiA+PiA+IC0tDQo+ID4gPj4gPiBNb2JpbGUgbnVtYmVyIGR1cmluZyBE ZWNlbWJlcjogICAgKzM1OCA0NiA1MjE1NTgyDQo+ID4gPj4gPiBNb2JpbGUgbnVtYmVyIHN0YXJ0 aW5nIEphbnVhcnk6ICArNDkgMTUxIDEyMDU1NzkxDQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IGFybWQgbWFpbGluZyBs aXN0DQo+ID4gPiBhcm1kQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FybWQNCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gPiBkYyBtYWlsaW5nIGxpc3QNCj4gPiA+IGRjQGlldGYub3Jn DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RjDQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBkYyBtYWls aW5nIGxpc3QNCj4gPiBkY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gZGMgbWFpbGluZyBsaXN0DQo+IGRjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGMNCg== From narten@us.ibm.com Wed Dec 28 08:50:40 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7C021F888A for ; Wed, 28 Dec 2011 08:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltMjbxwCXCCv for ; Wed, 28 Dec 2011 08:50:39 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4062121F87D3 for ; Wed, 28 Dec 2011 08:50:38 -0800 (PST) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 28 Dec 2011 09:50:37 -0700 Received: from d03relay02.boulder.ibm.com (9.17.195.227) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 28 Dec 2011 09:50:12 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBSGoAKx107778 for ; Wed, 28 Dec 2011 09:50:11 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBSGoAOk017119 for ; Wed, 28 Dec 2011 09:50:10 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-224-147.mts.ibm.com [9.65.224.147]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBSGo9nk016986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Dec 2011 09:50:10 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pBSGo7Mn011365; Wed, 28 Dec 2011 11:50:08 -0500 Message-Id: <201112281650.pBSGo7Mn011365@cichlid.raleigh.ibm.com> To: Bhumip Khasnabish In-reply-to: References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> Comments: In-reply-to Bhumip Khasnabish message dated "Sat, 24 Dec 2011 13:28:25 -0500." Date: Wed, 28 Dec 2011 11:50:07 -0500 From: Thomas Narten x-cbid: 11122816-7282-0000-0000-0000053CA4BA Cc: Ronald Bonica , "dc@ietf.org" , "So, Ning" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 16:50:40 -0000 Hi Bhumip. This post (and a few others) seem to me to be providing a laundry list of buzz words and generic "requirements". What this group needs to do is identify concrete problems for which lack of a standard is preventing solutions. For the items mentioned above, what is the actual concrete standards work that needs to be done? Bhumip Khasnabish writes: > · Support of on-demand provisioning and management (availability) of > distributed virtualized computing, communications, and > storage resources This is too broad and high-level to be helpful. That is, this comes across as a motherhood-and-apple-pie wish list. We need to drill down into something much more concrete. What standards are lacking today that prevent the above from being possible? How does the above translate into gaps that the IETF needs to fill? > · Offering of seamless mobility of virtual machine (VM), virtualized > interface (VI), virtualized network elements (VNE) and > virtualized storage (VS) from one domain to another for load > balancing and service continuity management Same comment again. Also, what is a "domain" above? Also, there are already proprietary systems/products that provide VM mobility. What is it that the IETF needs to do? > · Management of security, privacy, data integrity, and log of Data > center services for audit and verification Again, broad wish list. How does this translate into specific gaps that the IETF needs to fill? > · Support of Distributed scaling and multi-tenancy support without > excessive complexity and resource consumption Ditto. > · Support of Naming and addressing of virtualized entities for > simplified mobility and service continuity management Ditto > · Support of Realistic Service level agreement parameters for Data > center resources and services Ditto. > * Support of Visualization of resources utilization and automation of > provisioning Ditto. Thomas From narten@us.ibm.com Wed Dec 28 09:02:20 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D8321F84C3 for ; Wed, 28 Dec 2011 09:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWmANFdunkQP for ; Wed, 28 Dec 2011 09:02:20 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id BA78121F849B for ; Wed, 28 Dec 2011 09:02:19 -0800 (PST) Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 28 Dec 2011 12:02:18 -0500 Received: from d01relay01.pok.ibm.com (9.56.227.233) by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 28 Dec 2011 12:01:21 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBSH1Kib216936 for ; Wed, 28 Dec 2011 12:01:20 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBSH1ItK006386 for ; Wed, 28 Dec 2011 15:01:18 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-65-224-147.mts.ibm.com [9.65.224.147]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBSH0uWM003298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Dec 2011 15:00:56 -0200 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pBSH0kB2011575; Wed, 28 Dec 2011 12:00:51 -0500 Message-Id: <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> To: Russ White In-reply-to: <4EF7B019.3030202@riw.us> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> Comments: In-reply-to Russ White message dated "Sun, 25 Dec 2011 18:22:01 -0500." Date: Wed, 28 Dec 2011 12:00:46 -0500 From: Thomas Narten x-cbid: 11122817-1976-0000-0000-000008FAB0D1 Cc: dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 17:02:20 -0000 > 1. How many host routes do we reach before we say it "won't scale?" If > you're talking about leaf nodes in a routing protocol, 100k isn't really > that big of a deal. Where you do run into problems is between the > routing and forwarding tables --but that's an area for thought. Actually, 100K host routes in leaf nodes may well be a Big Deal. It depends on what type of devices need to understand host routes. For the scenarios NVO3 is looking at, the edge device includes edge switches and hypervisors. Yes, such devices can in theory support 100K host routes (and the routing protocol needed to make that converge). But at a cost. And I suspect the cost is too high. Do you think data center operators will want to run routing protocols in hypervisors that have to handle 100K host routes? Especially if such devices will need to be upgraded with better hardware to support such a load? Or will they want an alternative approach? > 2. Why does this mobility need to be at layer 2 specifically? Are we > assuming DDNS and other sorts of solutions in this space will simply > never be fast enough/scale far enough/etc? Like it or not, the key requirement for VM mobility is that the VM's IP address does not change. That means the VM can't really move from one IP subnet to another. That means either moving to bigger and bigger L2s (all under one IP subnet) as the DC expands or the need to inject /32 host routes. Neither of those approaches seems particularly scalable/desirable if you look 10 years down the road and think of 1M+ physical machines in a DC. Thomas From shao.weixiang@zte.com.cn Tue Dec 27 22:59:53 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFD321F87D3 for ; Tue, 27 Dec 2011 22:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.149 X-Spam-Level: X-Spam-Status: No, score=-91.149 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CN_BODY_46=0.256, HTML_FONT_FACE_BAD=0.884, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, J_CHICKENPOX_46=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udTQROWZDAcd for ; Tue, 27 Dec 2011 22:59:53 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 860DE21F85A8 for ; Tue, 27 Dec 2011 22:59:52 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690122734555; Wed, 28 Dec 2011 14:40:44 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 4315.3098549439; Wed, 28 Dec 2011 14:59:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pBS6xV8m087080; Wed, 28 Dec 2011 14:59:31 +0800 (GMT-8) (envelope-from shao.weixiang@zte.com.cn) To: Tina.Tsou.Zouting@huawei.com MIME-Version: 1.0 X-KeepSent: 8F297787:C131233F-48257974:0025C3CD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: shao.weixiang@zte.com.cn Date: Wed, 28 Dec 2011 14:59:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-28 14:59:32, Serialize complete at 2011-12-28 14:59:32 Content-Type: multipart/related; boundary="=_related 00266B2748257974_=" X-MAIL: mse01.zte.com.cn pBS6xV8m087080 X-Mailman-Approved-At: Wed, 28 Dec 2011 11:05:10 -0800 Cc: dc@ietf.org, vumip1@gmail.com Subject: [dc] feedback for http://www.ietf.org/mail-archive/web/dc/current/msg00038.html X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 06:59:53 -0000 This is a multipart message in MIME format. --=_related 00266B2748257974_= Content-Type: multipart/alternative; boundary="=_alternative 00266B2748257974_=" --=_alternative 00266B2748257974_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlIGZvbGxvd2luZyBkcmFmdCBvbiBDbG91ZCBTZXJ2aWNlIEJyb2tlciBpcyBubyByZWxhdGVk IHRvIA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXRzb3UtdnJvbS1wcm9ibGVtLXN0 YXRlbWVudC0wMi50eHQgDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc3RhZ2luZy9kcmFmdC1zaGFv LW9wc2F3Zy1jbG91ZC1zZXJ2aWNlLWJyb2tlci0wMi50eHQNCg0KZHJhZnQtdHNvdS12cm9tLXBy b2JsZW0tc3RhdGVtZW50LTAyIGlzIGp1c3QgYSBwcm9ibGVtIHN0YXRlbWVudCBhYm91dCANCmRh dGEgY2VudGVyIHZpcnR1YWwgcmVzb3VyY2VzIG9wZXJhdGlvbnMgYW5kIG1hbmFnZW1lbnQuIA0K QSBjbG91ZCBicm9rZXIgY2FuIGJlIGluIGRhdGEgY2VudGVyLCBvciBub3QuIEl0IGlzIGEgbmV3 IHJvbGUgaW4gY2xvdWQgDQplY29zeXN0ZW0uIEJ5IHRoZSB3YXksIHRoZSBkcmFmdCBpcyBhIHNv bHV0aW9uLg0KDQoNCg0KDQpTaGFvIFdlaXhpYW5nIMnbzrDP6A0KU3RhbmRhcmQgRGV2ZWxvcG1l bnQgQW5kIEluZHVzdHJ5IFJlbGF0aW9ucyBEZXB0Lg0KDQpQcm9kdWN0IFImRCBTeXN0ZW0gDQqy +sa30dC3oszlz7UNCkUzMDUsTm8uODg5LEJpYm8gUmQsWmhhbmdqaWFuZyBIaS1UZWNoIFBhcmss UHVkb25nLFNoYW5naGFpIA0KUC5SLkNoaW5hLCAyMDEyMDMNClRlbDorODYtMjEtNjg4OTY5NzYN Ck1vYmlsZTorODYtMTM5MTY2MTU4MTcNCkVtYWlsOnNoYW8ud2VpeGlhbmdAenRlLmNvbS5jbiAN Cg0KDQogDQo= --=_alternative 00266B2748257974_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0cj4NCjx0ZCB3aWR0aD0xMDAlPjxmb250IHNpemU9Mz5U aGUgZm9sbG93aW5nIGRyYWZ0IG9uIENsb3VkIFNlcnZpY2UgQnJva2VyDQppcyBubyByZWxhdGVk IHRvIDwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtdHNvdS12 cm9tLXByb2JsZW0tc3RhdGVtZW50LTAyLnR4dCI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iQ2FsaWJyaSI+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXRzb3UtdnJvbS1w cm9ibGVtLXN0YXRlbWVudC0wMi50eHQ8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4NCjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8vd3d3LmlldGYub3JnL3N0YWdpbmcvZHJh ZnQtc2hhby1vcHNhd2ctY2xvdWQtc2VydmljZS1icm9rZXItMDIudHh0PGJyPg0KPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNhbGlicmkiPjx1PmRyYWZ0LXRzb3Ut dnJvbS1wcm9ibGVtLXN0YXRlbWVudC0wMjwvdT48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5pcyBqdXN0 IGEgcHJvYmxlbSBzdGF0ZW1lbnQgYWJvdXQNCmRhdGEgY2VudGVyIHZpcnR1YWwgcmVzb3VyY2Vz IG9wZXJhdGlvbnMgYW5kIG1hbmFnZW1lbnQuIDwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj5BIGNsb3VkIGJyb2tlciBjYW4gYmUgaW4gZGF0YSBjZW50ZXIsDQpvciBu b3QuIEl0IGlzIGEgbmV3IHJvbGUgaW4gY2xvdWQgZWNvc3lzdGVtLiBCeSB0aGUgd2F5LCB0aGUg ZHJhZnQgaXMgYQ0Kc29sdXRpb24uPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBh bGlnbj1jZW50ZXI+PGltZyBzcmM9Y2lkOl8yXzBFRkJCRTFDMEVGQkJBMzQwMDI2NkIyNzQ4MjU3 OTc0PjwvZGl2Pg0KPHRkPg0KPGJyPjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0cj4NCjx0ZCBjb2xzcGFuPTI+PGZvbnQgc2l6ZT0zIGZhY2U9IruqzsS3 wsvOIj48Yj48aT5TaGFvIDwvaT48L2I+PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+ PGI+PGk+V2VpeGlhbmc8L2k+PC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iu6rOxLfCy84i PjxiPjxpPg0KydvOsM/oPC9pPjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IkFy aWFsIj5TdGFuZGFyZCBEZXZlbG9wbWVudCBBbmQgSW5kdXN0cnkgUmVsYXRpb25zDQpEZXB0Ljwv Zm9udD4NCjx0cj4NCjx0ZCByb3dzcGFuPTI+PGltZyBzcmM9Y2lkOl8yXzBFRkJFMzlDMEVGQkRG RTAwMDI2NkIyNzQ4MjU3OTc0Pg0KPHRkPjxmb250IHNpemU9MSBjb2xvcj0jOTA5MDkwIGZhY2U9 IkFyaWFsIj48Yj5Qcm9kdWN0IFImYW1wO0QgU3lzdGVtIDwvYj48L2ZvbnQ+DQo8dHI+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM5MDkwOTAgZmFjZT0iQXJpYWwiPjxiPrL6xrfR0LeizOXPtTwv Yj48L2ZvbnQ+DQo8dHI+DQo8dGQgY29sc3Bhbj0yPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+ RTMwNSxOby44ODksQmlibyBSZCxaaGFuZ2ppYW5nDQpIaS1UZWNoIFBhcmssUHVkb25nLFNoYW5n aGFpIDxicj4NClAuUi5DaGluYSwgMjAxMjAzPGJyPg0KVGVsOis4Ni0yMS02ODg5Njk3Njxicj4N Ck1vYmlsZTorODYtMTM5MTY2MTU4MTc8YnI+DQpFbWFpbDpzaGFvLndlaXhpYW5nQHp0ZS5jb20u Y24gPC9mb250PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCg== --=_alternative 00266B2748257974_=-- --=_related 00266B2748257974_= Content-Type: image/jpeg Content-ID: <_2_0EFBBE1C0EFBBA3400266B2748257974> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCACEAIkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gBKa8iRxs7sFVRkknAFUdW1ez0Wwe8vZQka9B3Y+gHc14t4q8X6j4lkaIs9tp4PyW6HBcf7Z7/Su ihhpVXpsZVKqgjY134l6rpniC6g026sr+xDAoxQgqT1XI649am034uald3dvaPokUssziNRFMQSS fcV51HZvPMlvBE8kjcJHGMk/hXe/Czw6Z9Yn1e5jxHaZiiDD/lp3P4dK9KrRoU6d2tUcMKlWc9Hu ewISUBYbWwMjrink4oyByTgVBJeW0X+snjX6sK8Wzex6ZIz1Cz00ajYvwLqEn/eFTBYZRlSrD1U5 pSjIV77EHmsv3Wx9act4BxIMe4oltm6o2fY1Ql3xnawwfesZScdRNtGwrq4ypyPWnVgpcPC25G57 jsa07S9S5GPuuOqmqhUUtAUky3RRRWpQUUUUAJVTUNQg0yxlu7lwkUYyff2q3Xl3jTWW1XUDaQt/ otsSOOjv6/hWtGn7SViJy5Vc5rxDrN34hv2ubg7Y1OIYc8Rj+pqLRfDl7r979ntF2ouPNmb7sY/q farml6NPq2oR2kHDNyzkcIvrXrVpaWHhvSBFGBHBGMk93b19ya9CrXVGPJDc5o0+d80irofhrS/D FqWhUebjMlxJjc349h7Cqr6zBaB4NJtUVWcsz4wCxPJx3qheahPq82XykAPyRD+Z9TU9taZA4rk5 X8U9WOVTpArzS313zPcSMD2BwPyqo9gDywz9ea6ZNObZkrhfWkaxXptzVKpFaIhwk9zkJtPT+7+l UytzaNvtriWI/wCwxFdlcWG0ZZMehNZNzZDnitoVE9GYTUobFSy8calYSBL+IXUI6sBtcf412mma xpuv2pe2lEgH3424ZD7ivOL2zxnisTzLnTbxbuyleGdD95e49CO4onhYVFeOgU8ZKLtM9bvrN7cF 1+eL9VrOEzRsrKcOvQ1L4S8W2/iO2aCUCK/iH72Lsw/vL6inatZfZG3pzA3GP7prwsTQlTfod11J c8TY07UFvYsHiReGFXq4iC7e1uFnQ/MOo9RXY206XMCTRnKMMiroVudWe5cJ8ysT0UUV0GhjeJNQ OnaPLIhxLJ+7T6nvXl5hxyfxPcmu18XTGa+htx92JdxHuelZGkacL7V7eFhlA29/oP8A69d9C1On zMxn7zsdR4S0ZdL0wSyLi5uAHcnqB2H5Vh61qratqJiQ/wCiwthR/ePr/hXQeK9TOnaK4jOJZj5a Y7ep/KuO0uMEqMcCopRc26kjHEVOX3EbNlB0zXQWtuEUOwxnoO9U9LthJukf7i8n3NaSvvbd0HQD 0FZVJ3diqUNLssAO4G48e1MdWU8GpUbApkhFYHT0IpJhIuyRc+9UZrCOcHyW+YfwnrVmTFRNG8sZ ePO9O464q07bGUlzaM5u+s2Qsrrhh1Brl9StMAkCvSfNgvl+z3eFk6K49a5XWtOe2laOQe6kdGFd dCtrZnm4ijZXR559pudI1GK/s3MdxC25T2I7qfUEV7do2qWvinw/FeRj5Jlw6d0buPzrxrVoNu41 tfCzWjZeILjR5G/c3amSMHoJAOfzFdGMoqpT510FgazjLkfU6e7ia1uJIH+8hwT6j1rW8M3+JpLN zw3zpn9ab4rttphu17/u2/pXO2l2bW/guAcbXGfpmvkXL2FY7XLkmemUtNRgyhh0IzTq9dHYcPqy mbVLlzz820fhV/wvbBbm4mI5ChRUNzETdTE93J/WtbQE2Qz+pYfyrrnL93YhLU5Lx5eGTXLW0B+W GLeR7k/4CmaPGzyKqjJIrJ8WTF/Gt4rfwBFH0x/9eup8GvEZnVgN+3IJ7Ct5Lkoqx51+evZm+6i1 torZfvYyx96WNuwpt6yveYXk4Ap6MsOP4n/QV57Z3LctIjEZY7R70rPCnT5jVUyu/wB459u1NLVH MXzdiZ7k/wAKIPwpkd6yygP908YAxUDGoJDRzIhye4l+Qs7q8SEHkdqZGkWrQNZTkh1GY3PUVPqQ 3QwTf3htNY0jvEd6MVccgjtVxlqY1HyvU4/xJp7WNzJBJ94d/UetcfYXjaZ4i0+8U7TDcISR1xnB /Q13/iWX7dFHcv8Afb9259CK801D5ZGYdVOR+de1QbnTszynaNZOJ9F+IohcaDcEc7VDg/rXnUj5 U+4/Wu81HUre28PRJcEq1xbBV+UkEleledM+Bj8PWvisyklUVj0cVJXVj1fR5vtGkWkpPLRir9cx 4R1W1m062sFkLXMaZdQpwoye+MV09eph5qdNNHbTkpRTRg3MGLiT/ezVvSV2eavrg1NcQ5lz6022 Xy5/Zhg11uV42KtqeUeNwbbx1c56SxxuPfjH9K3PC1wEFzL3WLiqvxXsWhvNO1VBhSDA59+o/rUP g0TXkN75S5VYhuNdzfNQTPLknDENHcWjtLZBhgzqvPrilWQVi6XqLRyiRfvZ5HqPSt2eFZoftVr8 yHlkHUHvXmTi07HVCfMroBJ70GSqXm0hmFZ8o/aItmQetRtIDVUy00y+9DiJ1DUuSG0aJu6vj+dY VycKSa0riYDRYV7tIawb642x7Ryx4A96qKbehnWkhunaVDqtvqLXMhSKJcjno2DzXk92nnXiQp8x eQIPfLAV2+qXkljDLbJKVaRC0wU8HjgVheDtNOseN7CHbujhfz5PZV6frivYoXhBzZxJKc4xSPdL rS4b7SFsZl+URgA91IHBry670y8t9VOnNGXuC21AOjj+99K9h5qFrSBrlLlokM6qVVyOQK+cxeEj XaezPUrYdVLGd4e0SLRbJYwA078yvjqf8K2aQZpa6qcIwiox2NoxUVZCMobrUZi9KloqyjD8U6Iv iHw9dWB4kZd0TH+Fx0P51434Z1i90i7ntSxhd8wzRnqDyK9/ry74jeEZBOfEOnRFiMG7iTqwH8Y9 x3rswtVa05bM4sXSbXPHdFCwv9p2MeQcE+9dNp2rvbuGQ5B4ZT0YVyOqaro2oQ2VxpC+XOV2zpja M4H61HBqDpgOCp962nQc1fY89VXTla56Q622pKZbRgk/Vo24yaypmeCQpIpRveuei1MghgxBHQg4 NaSeJHeMR3KJOnTLcEfjXN9XkjV4mE99CyZ6a09VRd2N0wW389JG/gVd3Nbmm+HZZ8S3blYuoUjB I96iUFHcceab90p39yRHa2yDfIqZ2jk5NZl/KmkQ+bOQ94w/dxddnuav65rljotxLBYx+Zdt9+Zu QvtXnuo6i88jyOxZ2OSSckmuihh3J3aIr1FF2vdlTUrxm812bczdT3r0b4TaCbPSJtZuEKzXxxHn qIgePz61xPhLwvN4s1UGRSumQMDPJ0Dn+4P617siJBEkUahUUBVVegGK0xlRRXso/M3wNJ/xGT0U g6UteaemFFFFABRRRQA3cBTGkjwQzLg9QTWP4qspLzQpxCzrLGPMXaSCcdq8qimkdvmlkP1Y13YX BfWIuSlax4+YZo8JUUHC9zoPFXw+WSeXUPDuxmb5prMNwx9V9DXExX9xaytb3CEOhw0Uy4K16H4b 12HSkaGa3yrnJlXlvx9a6K+0rw/4rhBnSKZwOHU7ZF/HrXT7WdB8lVXj3Mowp4qPPTdpdjyuHUrM 8yWPP+xIRV+LWNJi5/skyEdpJjitm++FkqMW03Usr2S4XP4bhWRN4A8RwE7beGUDoUmHP4EVtGph pr4jCWHxFN/D+paTxpcwr5en2Nnaj+8q5IHvWfd+KdSlJ/0+Uk/ebOAfYDsKkj8D+JpV2ixjjB/v TAVpWnwv1OYg3t/DAncRAufzNJvCw1uhqni56Wf5HE3N8WLOzZLHk9ya3fDngPUfEMiXF6slnp5w SWGJJR6D0Hua9D0rwToOhMJjF9ouB/y1uDuOfYdq3Hvdw2xDCjjca56uMuuWivmddDAqD5qrv5BY 2Vpo9lHZWcKxQxjCov8AnmrCkkknrVVOeevqatxIT8x6V58lbVnqRd9ETL0paKKzNAooooAKKKKA GMoZSCOCMV58fAtxJcXjpKsYEpNupGQw68/yr0Okwa2o4idG/I9zkxODpYm3tFex5Pcadeac+y6g dDnhuoP41JCzIQyMVI6FTivUZIUlQpKgdT1DDIrIufC2nTksiNC3rGePyrujmEZK1RHmvKpU3ekz nrXWdQhAAuXZR2cA1ox+IL3HzCNvfBFOfwnKh/dXKsPR15po8O3y9DC3vk/4VMpYeWprCGJho7k4 1y7boI1+goOoXUo+aUgHqF4pI9Cu+5jH41ci0SQf6yYfgKzbox2OiMa0tyopJOScnuTzVuCNpD8q 5/lV2HToY8ZBc+rGraqFGFGBWMqq2R0QovdkENqEwW5PpVjtS0Vg23ubpJKyCiiikMKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/9k= --=_related 00266B2748257974_= Content-Type: image/jpeg Content-ID: <_2_0EFBE39C0EFBDFE000266B2748257974> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAjAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDqvEut +OLbxHew6ZFeGyVwISlmHUjA77TnnNUfCXjXxFqfiqxsbu+8yCR2EiCFQThWPYeor0Dxrq/9ieFb y4RsTSL5MPrubj9Bk/hXCfCTR/NvrvWJFysA8iIn+8cFj+AwPxrvhKLoSlKK00MGmppJmXe+MvHG nEG8muLZXJCGa0Vd2PTK1r6D4k8YXMd7cX7XAtF0+aeKVrYKhcLlSGxz/WrXxj/499H/AN+X+S10 Vv8A8knH/YJP/ounKUXSjLlWoknzNX2PObPxl431EN9iuLm5KY3eTaq+3OeuFr0Pwvrt1b+GTe+L LtbKU3LRiS92wDHG0c4HrXnngPxbZ+FjfG8guJftATb5IBxt3dcketWfjJrdv4i+EMOoW0ckcTai ihZAAeA47ZqcWuXRRsu46Tvrct/Fv4lnStCsJvCXiKxe6e5KzfZpIpzs2nqOcc4ruNL8ceHJdLsn ufEmk/aXgQyBryMHeVGeM8c181+MPh7Z+G/APh/xFBfTzTaosZeJ1AVN0e/jHNS+P/h7Z+C9N8OX lte3Fw2pqXdZVACYCHjH++a4Tc99v/iLBa/EE+DvsjxXUtsXtrqY4jkmIyq/7p5GfUYx3rH+G3xD vde8M+ILnX2jF/pEkkkwVQoWPaWAx7FWHc8CuV+M+o6FeeIdEex1q3tNe0u7WKYyI48lPvhiQvO0 gdM/erk/EOs6LpEfjC80TxBb3sniGTyks7eGRfLjZ97uxYAD+JQBnh85oA9r+FHjLVPGvhN9Q1W3 hjminaASRcCXAU529uv/AOqu2vXaOxuJEOGSNip9CAa4L4PX2g/8IVaaPpOoRXVzZRLJe+WjDbJI Sx5IGecj/gNd5qP/ACDbr/ri/wDI0AfMHjvxJBcXekz60L66vJLDJkhn8oFRPKBwMc8Gis7xlpVn fHRZbjxBpunuNP2iK6juGYjz5vmHlxOMc4654PHTJWiqNKxyTwVOcnJt6+bPWPi1rBuNWtdIhJK2 6+bIo7u3Qfl/6FXonhLR/wCwvDVnZFcShN8vu7ct/h+Fed+Ifh94jv8AxFfX0HkTRzzGSNzLtYDs Me3H5VNoPgzxbZeIbC6vJibaKZWlH2wtkfTvXXNU5UVGMlp+ZaclNtotfGP/AI99HP8A00l/ktdD b/8AJJh/2CT/AOi6qfEXwzqfiSLT001I3MDOX3ybcZAx/I1t2mj3A8Dx6PMVjuTZG3Yg7grbcVk5 x9jBX1TL5Xzs82+Gfh/S9eOpjU7QXHkiPy9zEYzuz0I9BWr8WfCMs3w0GleHdOkk8m7Sf7PDl2x8 24gHk8sKwovhz4vti3keXHng+Xd7c/livSfA+lano+gta6s5a5M7OCZfM+U4xz+dXi7SfMp38hUr rRo+Y/F2reNJvC2k6P4i0qay02xKx2rS2bRElU2gbj1+Wr2vN8RPGdnpEOoeHL57axUC2aHT3UFS FGc454Uc17V8ZvB+s+M9A0+z0aCOWaC6MriSQIAuwjv9a77SoJLXR7K3mAEkUEcbgHOCFANcRseF /G7QfCOjGTVZUuJvEOpSq6wifChRgMxXsMDA9z7GqXj/AOHnhjwx4CttfsdH1Ez3Dw7457j/AI9w 3zEPgf8AAfqfwrvJvhMupfFa68U6rdfabAMktvauxYlwBw2f4FIyB+HQc+iavpNnrWlXWnX0Qltb mMxyIe4P9R1HoaAOQ+F/hvwrpmjHWfCzTmDUo0LiabftK5+X2ILEGu11H/kG3X/XF/5GuF+GHw9u fATazFLftcW1xOptlDEAIAfmK9A5zg/7oru71GewuERSWaNgAO5waAPjr4if8fWh/wDYM/8Abiei r3xL0y4sNR0a2voJLe4TTRujbGRmeY/1orvpZbXqQU42s/MlzSPr+iiiuAoKKKKACiiigAooooAK KKKACiiigDmfEXw+8L+K9Qjvtb0z7VcxxCFX+0SphASQMKwHVj+dFFFaxr1Yqyk0vVisj//Z --=_related 00266B2748257974_=-- From vumip1@gmail.com Wed Dec 28 17:40:55 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6ED21F84A6 for ; Wed, 28 Dec 2011 17:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okdgA2OruOz1 for ; Wed, 28 Dec 2011 17:40:54 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C96E21F84A4 for ; Wed, 28 Dec 2011 17:40:54 -0800 (PST) Received: by iabz21 with SMTP id z21so868725iab.31 for ; Wed, 28 Dec 2011 17:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1lY3DczNZGmjnwzz5ZA52UDU6KIxLEZVkBssxe73yUA=; b=V7Yft9eV28GuUJ+8/hikowLsyU3UQo6fICRIMQR4ijVS+uh40F0AqCo1hI1oDbRYQs mKhAOJ0B6WZS3sSheXEfD/PW0iYxWxZv4KbAxzKiG6csIPKgx9gHbkt03bpOBsRL+b6q k+h+XeqDui+jvL5VeKrvqbd1ClAghle8q5Qi8= MIME-Version: 1.0 Received: by 10.50.183.166 with SMTP id en6mr37996368igc.7.1325122852706; Wed, 28 Dec 2011 17:40:52 -0800 (PST) Received: by 10.50.77.197 with HTTP; Wed, 28 Dec 2011 17:40:52 -0800 (PST) In-Reply-To: <201112281650.pBSGo7Mn011365@cichlid.raleigh.ibm.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <201112281650.pBSGo7Mn011365@cichlid.raleigh.ibm.com> Date: Wed, 28 Dec 2011 20:40:52 -0500 Message-ID: From: Bhumip Khasnabish To: Thomas Narten Content-Type: multipart/alternative; boundary=14dae9340fe9eb59a304b531348b Cc: Ronald Bonica , "dc@ietf.org" , "So, Ning" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 01:40:55 -0000 --14dae9340fe9eb59a304b531348b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Thomas, Yes, these are high-level very important one-liner data center related topics/issues. We have a draft that covers SDO survey (http://tools.ietf.org/html/draft-khasnabish-cloud-sdo-survey-01= ). This is basically a summary of which SDO is trying to do what and what IETF can do. We need comments and suggestions from you and others to update this doc. We also have another draft covering potential work items ( http://tools.ietf.org/html/draft-khasnabish-cloud-industry-workitems-survey= -01 ). We can discuss these further in the interim mtg. In my email, the domain means admin. domain, apps/service domain, resource domain, etc There are many proprietary and app-/service-specific interim (neither scalable nor distributed) solution for many of the problems that I mention, but IETF can prioritize and focus on a few and can help develop scalable/distributed/interoperable solution, best practices, etc. We can develop a template to prepare a list of topics and issues for each of the items that IETF can contribute to. Any other suggestions? Thanks again. Best. Bhumip On Wed, Dec 28, 2011 at 11:50 AM, Thomas Narten wrote: > Hi Bhumip. > > This post (and a few others) seem to me to be providing a laundry list > of buzz words and generic "requirements". > > What this group needs to do is identify concrete problems for which > lack of a standard is preventing solutions. > > For the items mentioned above, what is the actual concrete standards > work that needs to be done? > > Bhumip Khasnabish writes: > > > > =B7 Support of on-demand provisioning and management (availability) of > > distributed virtualized computing, communications, and > > storage resources > > This is too broad and high-level to be helpful. That is, this comes > across as a motherhood-and-apple-pie wish list. We need to drill down > into something much more concrete. > > What standards are lacking today that prevent the above from being > possible? > > How does the above translate into gaps that the IETF needs to fill? > > > =B7 Offering of seamless mobility of virtual machine (VM), virtualized > > interface (VI), virtualized network elements (VNE) and > > virtualized storage (VS) from one domain to another for load > > balancing and service continuity management > > Same comment again. Also, what is a "domain" above? > > Also, there are already proprietary systems/products that provide VM > mobility. What is it that the IETF needs to do? > > > =B7 Management of security, privacy, data integrity, and log of Data > > center services for audit and verification > > Again, broad wish list. How does this translate into specific gaps > that the IETF needs to fill? > > > =B7 Support of Distributed scaling and multi-tenancy support without > > excessive complexity and resource consumption > > Ditto. > > > =B7 Support of Naming and addressing of virtualized entities for > > simplified mobility and service continuity management > > Ditto > > > =B7 Support of Realistic Service level agreement parameters for Data > > center resources and services > > Ditto. > > > * Support of Visualization of resources utilization and automation of > > provisioning > > Ditto. > > Thomas > > --14dae9340fe9eb59a304b531348b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Thomas,
=A0
Yes, these are high-level very important one-liner data center related= topics/issues.
=A0
We have a draft that covers
is basically a summary of which SDO=A0is trying to do what and what IE= TF can do.
We need comments and suggestions from you and others to update this do= c.
=A0
We also have another draft covering potential work items
=A0
We can discuss these further in the interim mtg.
=A0
In my email, the domain means admin. domain, apps/service domain,
resource domain, etc
There are many proprietary and app-/service-specific interim (neither = scalable nor distributed) solution for many of the problems that I mention,= but IETF
can prioritize and focus on a few and can help develop
scalable/distributed/interoperable solution, best practices, etc.
=A0
We can develop a template to prepare a list of topics and issues
fo= r each of the items that IETF can contribute to.
=A0
Any other suggestions?
=A0
Thanks again.
=A0
Best.
=A0
Bhumip
=A0
=A0
On Wed, Dec 28, 2011 at 11:50 AM, Thomas Narten = <narten@us.ibm.com> wrote:
Hi Bhumip.

This post (and a fe= w others) seem to me to be providing a laundry list
of buzz words and ge= neric "requirements".

What this group needs to do is identify concrete problems for which
= lack of a standard is preventing solutions.

For the items mentioned = above, what is the actual concrete standards
work that needs to be done?=

Bhumip Khasnabish <vumip1@gmail.com> writes:


> =B7 Support of on-dem= and provisioning and management (availability) of
> =A0 =A0 =A0 =A0 =A0 distributed virtualized computing, communicat= ions, and
> =A0 =A0 =A0 =A0 =A0 storage resources

This i= s too broad and high-level to be helpful. That is, this comes
across as = a motherhood-and-apple-pie wish list. We need to drill down
into something much more concrete.

What standards are lacking today = that prevent the above from being
possible?

How does the above tr= anslate into gaps that the IETF needs to fill?

> =B7 Offering of = seamless mobility of virtual machine (VM), virtualized
> =A0 =A0 =A0 =A0 =A0 interface (VI), virtualized network elements = (VNE) and
> =A0 =A0 =A0 =A0 =A0 virtualized storage (VS) from one dom= ain to another for load
> =A0 =A0 =A0 =A0 =A0 balancing and service c= ontinuity management

Same comment again. Also, what is a "domain" above?

= Also, there are already proprietary systems/products that provide VM
mob= ility. What is it that the IETF needs to do?

> =B7 Management of = security, privacy, data integrity, and log of Data
> =A0 =A0 =A0 =A0 =A0 center services for audit and verification
Again, broad wish list. How does this translate into specific ga= ps
that the IETF needs to fill?

> =B7 Support of Distributed s= caling and multi-tenancy support without
> =A0 =A0 =A0 =A0 =A0 excessive complexity and resource consumption=

Ditto.

> =B7 Support of Naming and addressing of vi= rtualized entities for
> =A0 =A0 =A0 =A0 =A0 simplified mobility and service continuity ma= nagement

Ditto

> =B7 Support of Realistic Service le= vel agreement parameters for Data
> =A0 =A0 =A0 =A0 =A0 center resour= ces and services

Ditto.

> * Support of Visualization of resources utilization and autom= ation of
> =A0 provisioning

Ditto.

Thomas



=A0=20 --14dae9340fe9eb59a304b531348b-- From warren@kumari.net Wed Dec 28 19:18:14 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D97321F8464 for ; Wed, 28 Dec 2011 19:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.459 X-Spam-Level: X-Spam-Status: No, score=-106.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk2YLOkS2e02 for ; Wed, 28 Dec 2011 19:18:14 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 824FC21F847A for ; Wed, 28 Dec 2011 19:18:13 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 66F441B4085D; Wed, 28 Dec 2011 22:18:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <4EF98391.6010500@piuha.net> Date: Wed, 28 Dec 2011 22:18:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EF98391.6010500@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: dc@ietf.org Subject: Re: [dc] interim dates decided? X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 03:18:14 -0000 On Dec 27, 2011, at 3:36 AM, Jari Arkko wrote: > Has the date for the Interim meeting been firmed up? I assume Feb = 22-23th based on the doodle, but it would be good to get a = confirmation... and what about a location? AFAIK, no, it hasn't been fully decided yet=85 Still digging out from under mail avalanche, maybe I'll find something = useful=85 W >=20 > Jari >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc >=20 --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net From david.black@emc.com Wed Dec 28 19:43:23 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0FB1F0C38 for ; Wed, 28 Dec 2011 19:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI+pO276XdZt for ; Wed, 28 Dec 2011 19:43:22 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A0B441F0C36 for ; Wed, 28 Dec 2011 19:43:22 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pBT3hJxC015345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Dec 2011 22:43:19 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 28 Dec 2011 22:43:06 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pBT3h5oP003107; Wed, 28 Dec 2011 22:43:05 -0500 Received: from mx14a.corp.emc.com ([169.254.1.216]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Wed, 28 Dec 2011 22:43:05 -0500 From: To: Date: Wed, 28 Dec 2011 22:43:03 -0500 Thread-Topic: Storage networking, L2 and L3 (was: IP over IP solution for data center interconnect) Thread-Index: AczEZWs1enlNW5A7QzOC/pHf9VF1TgAATylAAB0c3tAACjXooAAEnqNwAADXc3AAL1Z5AA== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC96B9@MX14A.corp.emc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com><618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com><618BE8B40039924EB9AED233D4A09C5102B25104@XMB-BGL-416.cisco.com><7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9499@MX14A.corp.emc.com> <618BE8B40039924EB9AED233D4A09C5102B25158@XMB-BGL-416.cisco.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94CB@MX14A.corp.emc.com> <618BE8B40039924EB9AED233D4A09C5102B2515C@XMB-BGL-416.cisco.com> In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102B2515C@XMB-BGL-416.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: david.black@emc.com, dc@ietf.org Subject: [dc] Storage networking, L2 and L3 (was: IP over IP solution for data center interconnect) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 03:43:24 -0000 SSd2ZSBjaGFuZ2VkIHRoZSB0aXRsZSBvZiB0aGlzIHRocmVhZCBpbiBvcmRlciB0byBzdW1tYXJp emUgdGhlIGludGVyYWN0aW9uIG9mDQpzdG9yYWdlIG5ldHdvcmtpbmcgcHJvdG9jb2xzIHdpdGgg dGhlIHNvcnQgb2YgbGFyZ2Ugc2NhbGUgTDIgYW5kIEwzIGRhdGEgY2VudGVyDQpuZXR3b3JraW5n IHRoYXQncyB1bmRlciBkaXNjdXNzaW9uIGhlcmUuICBUaGUgcXVpY2sgc3VtbWFyeSBvZiB0aGUg dGhyZWFkIGJlbG93DQppcyB0aGF0IHN0b3JhZ2Ugc3lzdGVtcyAoYm90aCBTQU4gYW5kIE5BUykg YXJlIGNhcGFibGUgb2YgbXVsdGktdGVuYW50IGlzb2xhdGlvbg0KYmFzZWQgb24gVkxBTnMsIGFu ZCBpZiBvbmUgdmlld3MgZW5jYXBzdWxhdGlvbi1iYXNlZCB2aXJ0dWFsIG5ldHdvcmtpbmcgYXMg YW4NCmV4dGVuc2lvbiB0byBWTEFOcywgdGhlbiB0aG9zZSBtdWx0aS10ZW5hbnQgaXNvbGF0aW9u IHByb3BlcnRpZXMgY2FuIGJlIGV4dGVuZGVkDQp0byBzdWNoIGVuY2Fwc3VsYXRpb24tYmFzZWQg YXBwcm9hY2hlcywgYm90aCBMMi1pbi1MMyBbTUFDLWluLUlQXSwgZS5nLiwgVnhMQU4sDQpOVkdS RSwgYW5kIEwyLWluLUwyIFtNQUMtaW4tTUFDXSwgZS5nLiwgVFJJTEwgd2l0aCAyNC1iaXQgaWRl bnRpZmllcnMuDQoNClRoZSBtYWpvciBkYXRhIGNlbnRlciBzdG9yYWdlIG5ldHdvcmtpbmcgcHJv dG9jb2xzIHRoYXQgcnVuIG92ZXIgSVAgYW5kL29yDQpFdGhlcm5ldCBuZXR3b3JrcyBhcmU6DQoN Ci0gTkFTIChmaWxlKTogTkZTIGFuZCBDSUZTLiAgVGhlc2UgYXJlIChvciBzaG91bGQgYmUpIHJ1 biBvdmVyIFRDUC9JUCwgYW5kIGhlbmNlDQoJYXJlIGFnbm9zdGljIGFzIHRvIHdoZXRoZXIgdGhl IG5ldHdvcmsgc2VydmljZSBpcyBMMiB2cy4gTDMuDQotIFNBTiAoYmxvY2spOiBpU0NTSSBhbmQg RkNvRQ0KCW8gaVNDU0kgdXNlcyBUQ1AsIGFuZCBoZW5jZSBpcyBhbHNvIGFnbm9zdGljIGFzIHRv IHdoZXRoZXIgdGhlIG5ldHdvcmtpbmcNCgkJc2VydmljZSBpcyBMMiB2cy4gTDMuDQoJbyBGQ29F IGRvZXMgbm90IHVzZSBUQ1Agb3IgSVAuICBGdXJ0aGVyIEZDb0UgZWZmZWN0aXZlbHkgcmVxdWly ZXMgRENCIGFzIHBhcnQNCgkJb2YgdGhlIEV0aGVybmV0IChMMikgc2VydmljZSBpbiBvcmRlciB0 byBhdm9pZCBmcmFtZSBkcm9wcy4gIEZpYnJlIENoYW5uZWwNCgkJKHRoZSBGQyBwYXJ0IG9mIEZD b0UpIHJlYWN0cyB2ZXJ5IHBvb3JseSB0byBkcm9wcywgdG8gcHV0IGl0IG1pbGRseS4NCg0KRm9y IEZDb0UsIHRoZSBlZmZlY3RpdmUgcmVxdWlyZW1lbnQgZm9yIERDQiBFdGhlcm5ldCBpcyBtdWNo IG1vcmUgaW1wb3J0YW50IChJTUhPKQ0KdGhhbiB0aGUgZmFjdCB0aGF0IEZDb0UgcmVxdWlyZXMg YW4gTDIgbmV0d29yayBzZXJ2aWNlICh0aGUgRSBpbiBGQ29FIGlzIEV0aGVybmV0KS4NCkZyb20g d2hhdCBJJ3ZlIHNlZW4sIERDQiBzdXBwb3J0IHRlbmRzIG5vdCB0byBiZSBwYXJ0IG9mIHRoZSBp bml0aWFsIGRlc2lnbnMgZm9yDQplaXRoZXIgTDItaW4tTDMgb3IgTDItaW4tTDIgZW5jYXBzdWxh dGlvbnMuICBJTUhPLCBEQ0IgRXRoZXJuZXQgZnVuY3Rpb25hbGl0eSBzaG91bGQNCmJlIGEgcG9z c2libGUgZW5oYW5jZW1lbnQgdG8gbmV0d29yayB2aXJ0dWFsaXphdGlvbiBmb3IgZGF0YSBjZW50 ZXJzLCBidXQgc2hvdWxkIG5vdA0KYmUgYSBiYXNlbGluZSByZXF1aXJlbWVudC4gIFdoZW4gRENC IEV0aGVybmV0IGlzIG5vdCBwcmVzZW50LCBpU0NTSSBjYW4gYmUgYQ0KcmVhc29uYWJsZSBhbHRl cm5hdGl2ZSB0byBGQ29FIGZvciBvcGVuIHN5c3RlbXMgc3RvcmFnZSBhY2Nlc3MuDQoNCkRDQiBF dGhlcm5ldCBpcyB0aGUgY29tYmluYXRpb24gb2YgUEZDIChQcmlvcml0eSBGbG93IENvbnRyb2wp LCBFVFMgKEVuaGFuY2VkDQpUcmFuc21pc3Npb24gU2VsZWN0aW9uKSBhbmQgRENCWCAoRGF0YSBD ZW50ZXIgQnJpZGdpbmcgZVhjaGFuZ2UpLiAgSWYgdGhlc2UgYXJlIG5ldw0KY29uY2VwdHMsIHRo aXMgbGluayBtYXkgYmUgdXNlZnVsIGZvciBiYWNrZ3JvdW5kIGluZm86DQoJaHR0cDovL2VuLndp a2lwZWRpYS5vcmcvd2lraS9EYXRhX2NlbnRlcl9icmlkZ2luZw0KDQpPVE9ILCBpZiBzdG9yYWdl IG5ldHdvcmtpbmcgaXRzZWxmIGlzIGEgbmV3IGNvbmNlcHQsIHRoaXMgbGluayBmcm9tIHRoZSBJ RVRGIFByYWd1ZQ0KcHJvY2VlZGluZ3MgLSBUcmFuc3BvcnQgQXJlYSBtZWV0aW5nIChNYXJjaCAy MDExKSBtYXkgYmUgdXNlZnVsIGZvciBiYWNrZ3JvdW5kIGluZm86DQoJaHR0cDovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy84MC9zbGlkZXMvdHN2YXJlYS0yLnBkZg0KDQpUaGFua3MsDQotLURh dmlkIChOQjogSSdtIGEgY28tY2hhaXIgb2YgdGhlIElFVEYgc3Rvcm0gV0cgdGhhdCBpcyBjdXJy ZW50bHkgZmluaXNoaW5nIHVwIGENCglyZXZpc2lvbiB0byB0aGUgaVNDU0kgc3BlY2lmaWNhdGlv bnMpLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFzaGlzaCBEYWxl bGEgKGFkYWxlbGEpIFttYWlsdG86YWRhbGVsYUBjaXNjby5jb21dDQo+IFNlbnQ6IFR1ZXNkYXks IERlY2VtYmVyIDI3LCAyMDExIDExOjM4IFBNDQo+IFRvOiBCbGFjaywgRGF2aWQNCj4gQ2M6IGRj QGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbZGNdIFthcm1kXSBJUCBvdmVyIElQIHNvbHV0aW9u IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QNCj4gDQo+IERhdmlkLA0KPiANCj4gVGhhbmtz IGFnYWluLiBTbyB3aGF0IGlzIHlvdXIgdmlldyBvZiB0aGUgTDIvTDMgZGViYXRlPyBJcyB0aGUg ZGlyZWN0aW9uIHRvIHVzZSBtb3JlIG9mIGlTQ1NJIGFuZCBOQVMNCj4gb3IgdG8gY29udmVyZ2Ug RkMgb3ZlciBFdGhlcm5ldD8gSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgbWF5IGJlIHZlcnkgZmV3 IEZDb0UgZGVwbG95bWVudHMgdG9kYXksIGJ1dA0KPiBJJ20gYXNraW5nIGluIHRlcm1zIG9mIHlv dXIgcGVyY2VwdGlvbiBvZiB0aGUgZGlyZWN0aW9uLiBXaGF0IHRyZW5kcyB3ZSBwZXJjZWl2ZSB2 aXMtw6AtdmlzIGNsb3VkPw0KPiANCj4gVGhhbmtzLCBBc2hpc2gNCj4gDQo+ICANCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGF2aWQuYmxhY2tAZW1jLmNvbSBbbWFpbHRv OmRhdmlkLmJsYWNrQGVtYy5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMjgsIDIw MTEgOTo1OSBBTQ0KPiBUbzogQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkNCj4gQ2M6IGRjQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJFOiBbZGNdIFthcm1kXSBJUCBvdmVyIElQIHNvbHV0aW9uIGZvciBk YXRhIGNlbnRlciBpbnRlcmNvbm5lY3QNCj4gDQo+IEFzaGlzaCwNCj4gDQo+ID4gVGhhbmtzIGZv ciB0aGUgZXhwbGFuYXRpb24uIFNvLCBpdCBpcyBwb3NzaWJsZSB0byBwdWxsIG5ldHdvcmsgYWJz dHJhY3Rpb25zIChWTEFOIGV0YykgaW50byB0aGUNCj4gPiBzdG9yYWdlIGNvbnRyb2xsZXIuDQo+ IA0KPiBTdXJlIC0gbm90IG9ubHkgaXMgaXQgcG9zc2libGUsIHRoZXJlJ3MgYWxzbyBwbGVudHkg b2YgZGVwbG95ZWQgc3RvcmFnZSBlcXVpcG1lbnQgdGhhdCBkb2VzIHRoaXMsDQo+IHRvZGF5LiAg QWxzbywgcGxlYXNlIGF2b2lkIHVzZSBvZiB0aGUgcGhyYXNlICJzdG9yYWdlIGNvbnRyb2xsZXIi IGluIHRoaXMgZGlzY3Vzc2lvbiwgYXMgdGhhdCdzDQo+IG9mdGVuIGEgY29tcG9uZW50IG9mIGEg bXVjaCBsYXJnZXIgc3RvcmFnZSBzeXN0ZW0sIHN0b3JhZ2UgYXJyYXksIG9yIGZpbGVzZXJ2ZXIu DQo+IA0KPiA+IFRoZSBzY2hlbWUgaXMgYWxzbyBleHRlbnNpYmxlIHRvIG90aGVyIHRoaW5ncyBs aWtlIFZYTEFOIG9yIE5WR1JFLg0KPiANCj4gWWVzLg0KPiANCj4gPiBUaGVuIHlvdSB0aWUgdGhl IGZpbGUgc3lzdGVtIHBlcm1pc3Npb25zIHRvIHRoZSBWTEFOLiBBbSBJIHJlYWRpbmcgdGhpcyBj b3JyZWN0bHk/DQo+IA0KPiBOb3QgZXhhY3RseSA7LSkuICBXaGlsZSBvbmUgY291bGQgZG8gdGhh dCwgdGhlIHJlc3VsdCBjYW4gYmUgImludGVyZXN0aW5nIiBpZiB0aGVyZSBpcyBJRA0KPiBkdXBs aWNhdGlvbiBhbW9uZyB0ZW5hbnRzLiAgSXQncyBiZXR0ZXIgdG8gdXNlIHNlcGFyYXRlIGZpbGVz eXN0ZW1zIHBlciB0ZW5hbnQgKHdpdGggZWFjaA0KPiBmaWxlc3lzdGVtIHRpZWQgdG8gdGhlIGlk ZW50aXR5IHNlcnZpY2UgZm9yIHRoZSBjb3JyZXNwb25kaW5nIHRlbmFudCksIGFuZCB0aWUgdGhl IGxpc3Qgb3INCj4gc2V0IG9mIGV4cG9ydGVkIGZpbGVzeXN0ZW1zIHRvIHRoZSBWTEFOIChvciB2 aXJ0dWFsIG5ldHdvcmsgYmFzZWQgb24gVk5JL1ROSSkuICBUaGUgcmVzdWx0DQo+IGlzIHRoYXQg aWYgVGVuYW50IEEgaXMgb24gYSBWTEFOIChvciB2aXJ0dWFsIG5ldHdvcmspIHRoYXQgaXNuJ3Qg c3VwcG9zZWQgdG8gaGF2ZSBhY2Nlc3MgdG8NCj4gVGVuYW50IEIgZmlsZXN5c3RlbXMsIGl0IGRv ZXNuJ3QgbWF0dGVyIHdoYXQgSURzIG9yIGFkZHJlc3NlcyBhcmUgZHVwbGljYXRlZCBvciBmb3Jn ZWQgb24NCj4gVGVuYW50IEEncyBWTEFOIChvciB2aXJ0dWFsIG5ldHdvcmspIC0gVGVuYW50IEIn cyBmaWxlc3lzdGVtcyBhcmUgaW5hY2Nlc3NpYmxlIChlLmcuLCBjYW4ndA0KPiBiZSBtb3VudGVk KS4gIEZvciBpU0NTSSwgTFVOIG1hcHBpbmcvbWFza2luZyBpcyB0aGUgYW5hbG9nb3VzIGZ1bmN0 aW9uYWxpdHksIGFuZCB0aGF0DQo+IGZ1bmN0aW9uYWxpdHkgaXMgd2lkZWx5IGltcGxlbWVudGVk IGluIHN0b3JhZ2Ugc3lzdGVtcy4NCj4gDQo+IFRoYW5rcywNCj4gLS1EYXZpZA0KPiANCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGRjLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpkYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQXNoaXNoIERhbGVsYSAo YWRhbGVsYSkNCj4gPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAyNywgMjAxMSAxMTowOCBQTQ0K PiA+IFRvOiBCbGFjaywgRGF2aWQNCj4gPiBDYzogZGNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS ZTogW2RjXSBbYXJtZF0gSVAgb3ZlciBJUCBzb2x1dGlvbiBmb3IgZGF0YSBjZW50ZXIgaW50ZXJj b25uZWN0DQo+ID4NCj4gPiBEYXZpZCwNCj4gPg0KPiA+IFRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0 aW9uLiBTbywgaXQgaXMgcG9zc2libGUgdG8gcHVsbCBuZXR3b3JrIGFic3RyYWN0aW9ucyAoVkxB TiBldGMpIGludG8gdGhlDQo+ID4gc3RvcmFnZSBjb250cm9sbGVyLiBUaGUgc2NoZW1lIGlzIGFs c28gZXh0ZW5zaWJsZSB0byBvdGhlciB0aGluZ3MgbGlrZSBWWExBTiBvciBOVkdSRS4gVGhlbiB5 b3UgdGllDQo+ID4gdGhlIGZpbGUgc3lzdGVtIHBlcm1pc3Npb25zIHRvIHRoZSBWTEFOLiBBbSBJ IHJlYWRpbmcgdGhpcyBjb3JyZWN0bHk/DQo+ID4NCj4gPiBUaGFua3MsIEFzaGlzaA0KPiA+DQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBkYXZpZC5ibGFja0BlbWMu Y29tIFttYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbV0NCj4gPiBTZW50OiBXZWRuZXNkYXksIERl Y2VtYmVyIDI4LCAyMDExIDI6NTYgQU0NCj4gPiBUbzogQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkN Cj4gPiBDYzogZGNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogW2RjXSBbYXJtZF0gSVAgb3Zl ciBJUCBzb2x1dGlvbiBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0DQo+ID4NCj4gPiBBc2hp c2gsDQo+ID4NCj4gPiA+IEkgd291bGQgYmUgaW50ZXJlc3RlZCB0byBrbm93IGhvdyB0aGUgc3Rv cmFnZSBtdWx0aS10ZW5hbmN5IHNvbHV0aW9ucyBkZWFsIHdpdGggcHJpdmF0ZSBJUCwgTUFDDQo+ ID4gPiBhbmQgSUQgIGluIHRoZSBwdWJsaWMgZG9tYWluLCB3aGljaCBjYW4gYmUgZHVwbGljYXRl ZC4NCj4gPg0KPiA+IEEgY29tbW9uIGN1cnJlbnQgdGVjaG5pcXVlIGlzIHRvIHVzZSBwZXItdGVu YW50IFZMQU5zIChhIHRlbmFudCBtYXkgaGF2ZSBtdWx0aXBsZSBWTEFOcykgYW5kIHVzZSBOQVQN Cj4gPiAoYXMgbmVlZGVkKSBiZXR3ZWVuIHRoZSBWTEFOcyBhbmQgdGhlIHB1YmxpYyBJbnRlcm5l dCBpbiBvcmRlciB0byBzZXBhcmF0ZSBWTEFOIGFkZHJlc3NpbmcgZnJvbQ0KPiA+IHB1YmxpYyBJ bnRlcm5ldCBhZGRyZXNzaW5nLCBlZmZlY3RpdmVseSByZXN1bHRpbmcgaW4gYSAodmlydHVhbCkg TkFUIGluc3RhbmNlIHBlciBWTEFOLiAgQSAxMi1iaXQNCj4gPiBWTEFOIHRhZyBpcyBub3QgbGFy Z2UgZW5vdWdoIHRvIHNjYWxlIHVwIHRvIHRoZSBkZXNpcmVkIGxhcmdlLXNjYWxlIGRhdGEgY2Vu dGVyIHNjb3BlLCBzbyBib3RoDQo+ID4gVnhMQU4gYW5kIE5WR1JFIHVzZSBhIDI0LWJpdCB2aXJ0 dWFsIG5ldHdvcmsgaWRlbnRpZmllciB0byByZXBsYWNlIHRoZSAxMi1iaXQgVkxBTiB0YWc7IFZ4 TEFODQo+ID4gY2FsbHMgdGhpcyBhIFZOSSAoVnhMQU4gW29yIFZpcnR1YWxdIE5ldHdvcmsgSWRl bnRpZmllciksIGFuZCBOVkdSRSBjYWxscyBpdCBhIFROSSAoVGVuYW50IE5ldHdvcmsNCj4gPiBJ ZGVudGlmaWVyKS4gIFZOSSBhbmQgVE5JIGVuY2FwL2RlY2FwIGNhbiBiZSBoYW5kbGVkIGJ5IHRo ZSBoeXBlcnZpc29yIGFuZCBhcmUgbGltaXRlZCB0byB0aGUNCj4gPiBkYXRhY2VudGVyOyBpbiB0 aGlzIHN0cnVjdHVyZSwgVk1zIGNhbid0IHVzZSBhIFZOSSBvciBUTkkgZGlyZWN0bHksIGFuZCB0 aGUgKHZpcnR1YWwpIE5BVCBoYW5kbGVzDQo+ID4gZW5jYXAvZGVjYXAgZm9yIGluYm91bmQvb3V0 Ym91bmQgdHJhZmZpYyBzbyB0aGF0IHRyeWluZyB0byBzZW5kIGVuY2Fwc3VsYXRlZCAoVnhMQU4g b3IgTkdSRSkgdHJhZmZpYw0KPiA+IGluIGZyb20gdGhlIG91dHNpZGUgcmVzdWx0cyBpbiBkb3Vi bGUgZW5jYXBzdWxhdGlvbiB3aXRoIG5vIGVmZmVjdCBvbiB0ZW5hbnQgaXNvbGF0aW9uLg0KPiA+ DQo+ID4gQmVmb3JlIG9uZSBvZiB0aGUgTDJWUE4gZm9sa3MgY29tZXMgYWZ0ZXIgbWUgZm9yIHRo YXQgImxpbWl0ZWQgdG8gdGhlIGRhdGFjZW50ZXIiIGNvbW1lbnQgOy0pIC4uLiBhbg0KPiA+IEwy VlBOIGdhdGV3YXkgd291bGQgcHJvYmFibHkgdHJhbnNsYXRlIGJldHdlZW4gYSAyNC1iaXQgVk5J L1ROSSBhbmQgYSAyNC1iaXQgVlBOIElEIC0gZW5kLXRvLWVuZCB1c2UNCj4gPiBvZiBhIHNpbmds ZSBpZGVudGlmaWVyIGZvciB0aGUgTDJWUE4gYW5kIHRoZSB2aXJ0dWFsIG5ldHdvcmtzIG9uIGJv dGggZW5kcyBpcyBwb3NzaWJsZSwgYnV0IChJTUhPKQ0KPiA+IGRpZmZpY3VsdCB3aGVuIHRoZXJl IGFyZSBtdWx0aXBsZSBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIGludm9sdmVkIGluIG1hbmFnaW5n IHRoZSBpZGVudGlmaWVycy4NCj4gPg0KPiA+IFVzZSBvZiBWTEFOcyB0byBzY29wZSBmaWxlc3lz dGVtIHZpc2liaWxpdHkgb24gTkFTIGZpbGVzZXJ2ZXJzIGlzIGEgY29tbW9uIGRlcGxveWVkIHBy YWN0aWNlIGluDQo+ID4gZGF0YWNlbnRlcnMgKGRpdHRvIGZvciBWTEFOcyB0byBsaW1pdCBpU0NT SSBzdG9yYWdlIHZpc2liaWxpdHkpLCB0aGVyZWJ5IGRlYWxpbmcgd2l0aCB0aGUgZm9sbG93aW5n Og0KPiA+DQo+ID4gPiBTbywgeW91IGhhdmUgdG8NCj4gPiA+IHByb3RlY3QgdGhlIG5ldHdvcmsg c3RvcmFnZSBmcm9tIG11bHRpcGxlIHRlbmFudHMgd2hvIGNhbiBoYXZlIHRoZSBzYW1lIElQIGFk ZHJlc3MgYW5kIE1BQw0KPiA+ID4gYWRkcmVzcy4gTkFTIGFzc3VtZXMgeW91ciBpZCBvbiB0aGUg VU5JWCBpcyBnbG9iYWxseSB1bmlxdWUgYW5kIHlvdXIgcGVybWlzc2lvbnMgYXJlIHVuaXF1ZSAt DQo+ID4gPiBub3QgdHJ1ZSBhbnltb3JlLiBTbywgeW91IGhhdmUgSVAsIE1BQyBhbmQgSUQgZHVw bGljYXRpb24uDQo+ID4NCj4gPiBEdXBsaWNhdGlvbgkgb2YgSVAsIE1BQyBhbmQgSUQgb24gc2Vw YXJhdGUgVkxBTnMgd29ya3MgZmluZSAtIHRoaXMgbW9kZWwgaXMgY2FycmllZCBvdmVyIHRvIHZp cnR1YWwNCj4gPiBuZXR3b3JrcyBiYXNlZCBvbiBWTkkgb3IgVE5JLiAgVGhlIHNlbnRlbmNlIGNv bnRhaW5pbmcgImdsb2JhbGx5IHVuaXF1ZSIgKGluY29ycmVjdGx5KSBhc3N1bWVzIGENCj4gPiBz aW5nbGUgZmlsZXNlcnZlcjsgaW5zdGVhZCwgY29uc2lkZXIgYSBzaW5nbGUgTkFTIHN5c3RlbSBw cmVzZW50aW5nIHdoYXQgaXMgZWZmZWN0aXZlbHkgYSB2aXJ0dWFsDQo+ID4gZmlsZXNlcnZlciBw ZXIgVkxBTiAob3IgVk5JL1ROSSkgYW5kIHNpbWlsYXJseSBmb3IgaVNDU0kgLSB0aGF0IGlzIHdo YXQgc29ydHMgb3V0IHRoaXMgZHVwbGljYXRpb24sDQo+ID4gaW5jbHVkaW5nIHVzZSBvZiBkaWZm ZXJlbnQgaWRlbnRpdHkgc2VydmljZXMvc2VydmVycyBwZXIgVkxBTiAob3IgVk5JL1ROSSkuDQo+ ID4NCj4gPiBUaGFua3MsDQo+ID4gLS1EYXZpZA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBEYXZpZCBMLiBCbGFjaywgRGlzdGlu Z3Vpc2hlZCBFbmdpbmVlcg0KPiA+IEVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0LiwgSG9w a2ludG9uLCBNQSAgMDE3NDgNCj4gPiArMSAoNTA4KSAyOTMtNzk1MyAgICAgICAgICAgICBGQVg6 ICsxICg1MDgpIDI5My03Nzg2DQo+ID4gZGF2aWQuYmxhY2tAZW1jLmNvbSAgICAgICAgTW9iaWxl OiArMSAoOTc4KSAzOTQtNzc1NA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KWy4uLiByZXN0IG9mIHRocmVhZCBzbmlwcGVkIC4uLl0N Cg== From xuxiaohu@huawei.com Wed Dec 28 20:09:03 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DEE11E807F for ; Wed, 28 Dec 2011 20:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=2.373, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LcRnexK2Pt7 for ; Wed, 28 Dec 2011 20:09:02 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C1DEE11E8083 for ; Wed, 28 Dec 2011 20:09:01 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWY002RL66SXH@szxga05-in.huawei.com> for dc@ietf.org; Thu, 29 Dec 2011 12:08:52 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWY0028W66STL@szxga05-in.huawei.com> for dc@ietf.org; Thu, 29 Dec 2011 12:08:52 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGB95755; Thu, 29 Dec 2011 12:08:51 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Dec 2011 12:08:33 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Thu, 29 Dec 2011 12:08:34 +0800 Date: Thu, 29 Dec 2011 04:08:34 +0000 From: Xuxiaohu In-reply-to: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC96B9@MX14A.corp.emc.com> X-Originating-IP: [10.108.4.80] To: "david.black@emc.com" , "adalela@cisco.com" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE763730@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dc] Storage networking, L2 and L3 (was: IP over IP solution for data center interconnect) Thread-index: AQHMxdwThX8LmcjDjEqv1ALyEHY9VZXyM7gQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com> <618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com> <618BE8B40039924EB9AED233D4A09C5102B25104@XMB-BGL-416.cisco.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9499@MX14A.corp.emc.com> <618BE8B40039924EB9AED233D4A09C5102B25158@XMB-BGL-416.cisco.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94CB@MX14A.corp.emc.com> <618BE8B40039924EB9AED233D4A09C5102B2515C@XMB-BGL-416.cisco.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC96B9@MX14A.corp.emc.com> Cc: "dc@ietf.org" Subject: Re: [dc] Storage networking, L2 and L3 (was: IP over IP solution for data center interconnect) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 04:09:03 -0000 DQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBkYy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoDQo+IGRhdmlkLmJsYWNrQGVt Yy5jb20NCj4g5Y+R6YCB5pe26Ze0OiAyMDEx5bm0MTLmnIgyOeaXpSAxMTo0Mw0KPiDmlLbku7bk uro6IGFkYWxlbGFAY2lzY28uY29tDQo+IOaKhOmAgTogZGF2aWQuYmxhY2tAZW1jLmNvbTsgZGNA aWV0Zi5vcmcNCj4g5Li76aKYOiBbZGNdIFN0b3JhZ2UgbmV0d29ya2luZywgTDIgYW5kIEwzICh3 YXM6IElQIG92ZXIgSVAgc29sdXRpb24gZm9yIGRhdGENCj4gY2VudGVyIGludGVyY29ubmVjdCkN Cj4gDQo+IEkndmUgY2hhbmdlZCB0aGUgdGl0bGUgb2YgdGhpcyB0aHJlYWQgaW4gb3JkZXIgdG8g c3VtbWFyaXplIHRoZSBpbnRlcmFjdGlvbiBvZg0KPiBzdG9yYWdlIG5ldHdvcmtpbmcgcHJvdG9j b2xzIHdpdGggdGhlIHNvcnQgb2YgbGFyZ2Ugc2NhbGUgTDIgYW5kIEwzIGRhdGEgY2VudGVyDQo+ IG5ldHdvcmtpbmcgdGhhdCdzIHVuZGVyIGRpc2N1c3Npb24gaGVyZS4gIFRoZSBxdWljayBzdW1t YXJ5IG9mIHRoZSB0aHJlYWQNCj4gYmVsb3cNCj4gaXMgdGhhdCBzdG9yYWdlIHN5c3RlbXMgKGJv dGggU0FOIGFuZCBOQVMpIGFyZSBjYXBhYmxlIG9mIG11bHRpLXRlbmFudA0KPiBpc29sYXRpb24N Cj4gYmFzZWQgb24gVkxBTnMsIGFuZCBpZiBvbmUgdmlld3MgZW5jYXBzdWxhdGlvbi1iYXNlZCB2 aXJ0dWFsIG5ldHdvcmtpbmcgYXMgYW4NCj4gZXh0ZW5zaW9uIHRvIFZMQU5zLCB0aGVuIHRob3Nl IG11bHRpLXRlbmFudCBpc29sYXRpb24gcHJvcGVydGllcyBjYW4gYmUNCj4gZXh0ZW5kZWQNCj4g dG8gc3VjaCBlbmNhcHN1bGF0aW9uLWJhc2VkIGFwcHJvYWNoZXMsIGJvdGggTDItaW4tTDMgW01B Qy1pbi1JUF0sIGUuZy4sDQo+IFZ4TEFOLA0KPiBOVkdSRSwgYW5kIEwyLWluLUwyIFtNQUMtaW4t TUFDXSwgZS5nLiwgVFJJTEwgd2l0aCAyNC1iaXQgaWRlbnRpZmllcnMuDQo+IA0KPiBUaGUgbWFq b3IgZGF0YSBjZW50ZXIgc3RvcmFnZSBuZXR3b3JraW5nIHByb3RvY29scyB0aGF0IHJ1biBvdmVy IElQIGFuZC9vcg0KPiBFdGhlcm5ldCBuZXR3b3JrcyBhcmU6DQo+IA0KPiAtIE5BUyAoZmlsZSk6 IE5GUyBhbmQgQ0lGUy4gIFRoZXNlIGFyZSAob3Igc2hvdWxkIGJlKSBydW4gb3ZlciBUQ1AvSVAs IGFuZCBoZW5jZQ0KPiAJYXJlIGFnbm9zdGljIGFzIHRvIHdoZXRoZXIgdGhlIG5ldHdvcmsgc2Vy dmljZSBpcyBMMiB2cy4gTDMuDQo+IC0gU0FOIChibG9jayk6IGlTQ1NJIGFuZCBGQ29FDQo+IAlv IGlTQ1NJIHVzZXMgVENQLCBhbmQgaGVuY2UgaXMgYWxzbyBhZ25vc3RpYyBhcyB0byB3aGV0aGVy IHRoZSBuZXR3b3JraW5nDQo+IAkJc2VydmljZSBpcyBMMiB2cy4gTDMuDQo+IAlvIEZDb0UgZG9l cyBub3QgdXNlIFRDUCBvciBJUC4gIEZ1cnRoZXIgRkNvRSBlZmZlY3RpdmVseSByZXF1aXJlcyBE Q0IgYXMNCj4gcGFydA0KPiAJCW9mIHRoZSBFdGhlcm5ldCAoTDIpIHNlcnZpY2UgaW4gb3JkZXIg dG8gYXZvaWQgZnJhbWUgZHJvcHMuICBGaWJyZQ0KPiBDaGFubmVsDQo+IAkJKHRoZSBGQyBwYXJ0 IG9mIEZDb0UpIHJlYWN0cyB2ZXJ5IHBvb3JseSB0byBkcm9wcywgdG8gcHV0IGl0IG1pbGRseS4N Cj4gDQo+IEZvciBGQ29FLCB0aGUgZWZmZWN0aXZlIHJlcXVpcmVtZW50IGZvciBEQ0IgRXRoZXJu ZXQgaXMgbXVjaCBtb3JlIGltcG9ydGFudA0KPiAoSU1ITykNCj4gdGhhbiB0aGUgZmFjdCB0aGF0 IEZDb0UgcmVxdWlyZXMgYW4gTDIgbmV0d29yayBzZXJ2aWNlICh0aGUgRSBpbiBGQ29FIGlzDQo+ IEV0aGVybmV0KS4NCj4gRnJvbSB3aGF0IEkndmUgc2VlbiwgRENCIHN1cHBvcnQgdGVuZHMgbm90 IHRvIGJlIHBhcnQgb2YgdGhlIGluaXRpYWwgZGVzaWducyBmb3INCj4gZWl0aGVyIEwyLWluLUwz IG9yIEwyLWluLUwyIGVuY2Fwc3VsYXRpb25zLiAgSU1ITywgRENCIEV0aGVybmV0IGZ1bmN0aW9u YWxpdHkNCj4gc2hvdWxkDQo+IGJlIGEgcG9zc2libGUgZW5oYW5jZW1lbnQgdG8gbmV0d29yayB2 aXJ0dWFsaXphdGlvbiBmb3IgZGF0YSBjZW50ZXJzLCBidXQNCj4gc2hvdWxkIG5vdA0KPiBiZSBh IGJhc2VsaW5lIHJlcXVpcmVtZW50LiAgV2hlbiBEQ0IgRXRoZXJuZXQgaXMgbm90IHByZXNlbnQs IGlTQ1NJIGNhbiBiZSBhDQo+IHJlYXNvbmFibGUgYWx0ZXJuYXRpdmUgdG8gRkNvRSBmb3Igb3Bl biBzeXN0ZW1zIHN0b3JhZ2UgYWNjZXNzLg0KDQpGdWxseSBhZ3JlZSB0aGF0IHRoZSBzdXBwb3J0 IGZvciBGQ29FIHNob3VsZCBub3QgYmUgYSBiYXNlbGluZSByZXF1aXJlbWVudC4gSW4gYWRkaXRp b24sIElNSE8sIHRoZSBtb3N0IHBvcHVsYXIgYW5kIHByYWN0aWNhbCBhcHBsaWNhdGlvbiBvZiBG Q29FIGlzIG9uZS1ob3AgRkNvRSwgcmF0aGVyIHRoYW4gbXVsdGktaG9wIEZDb0UuIE9uZS1ob3Ag RkNvRSBjb3VsZCBiZSBzdXBwb3J0ZWQgaW4gdGhlIElQIG92ZXIgSVAgc29sdXRpb24sIGUuZy4s IEwzVlBOLiAgQnkgdGhlIHdheSwgRkNvRSB3b3VsZCBub3QgYmUgdXNlZCBpbiB0aGUgRENJIHNj ZW5hcmlvIFNJTkNFIGxvc3NsZXNzIGNhbid0IGJlIGVuc3VyZWQgaGVyZS4NCg0KQmVzdCByZWdh cmRzLA0KWGlhb2h1DQoNCg0KPiBEQ0IgRXRoZXJuZXQgaXMgdGhlIGNvbWJpbmF0aW9uIG9mIFBG QyAoUHJpb3JpdHkgRmxvdyBDb250cm9sKSwgRVRTIChFbmhhbmNlZA0KPiBUcmFuc21pc3Npb24g U2VsZWN0aW9uKSBhbmQgRENCWCAoRGF0YSBDZW50ZXIgQnJpZGdpbmcgZVhjaGFuZ2UpLiAgSWYg dGhlc2UNCj4gYXJlIG5ldw0KPiBjb25jZXB0cywgdGhpcyBsaW5rIG1heSBiZSB1c2VmdWwgZm9y IGJhY2tncm91bmQgaW5mbzoNCj4gCWh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRGF0YV9j ZW50ZXJfYnJpZGdpbmcNCj4gDQo+IE9UT0gsIGlmIHN0b3JhZ2UgbmV0d29ya2luZyBpdHNlbGYg aXMgYSBuZXcgY29uY2VwdCwgdGhpcyBsaW5rIGZyb20gdGhlIElFVEYNCj4gUHJhZ3VlDQo+IHBy b2NlZWRpbmdzIC0gVHJhbnNwb3J0IEFyZWEgbWVldGluZyAoTWFyY2ggMjAxMSkgbWF5IGJlIHVz ZWZ1bCBmb3INCj4gYmFja2dyb3VuZCBpbmZvOg0KPiAJaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy84MC9zbGlkZXMvdHN2YXJlYS0yLnBkZg0KPiANCj4gVGhhbmtzLA0KPiAtLURhdmlk IChOQjogSSdtIGEgY28tY2hhaXIgb2YgdGhlIElFVEYgc3Rvcm0gV0cgdGhhdCBpcyBjdXJyZW50 bHkgZmluaXNoaW5nIHVwIGENCj4gCXJldmlzaW9uIHRvIHRoZSBpU0NTSSBzcGVjaWZpY2F0aW9u cykuDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogQXNoaXNo IERhbGVsYSAoYWRhbGVsYSkgW21haWx0bzphZGFsZWxhQGNpc2NvLmNvbV0NCj4gPiBTZW50OiBU dWVzZGF5LCBEZWNlbWJlciAyNywgMjAxMSAxMTozOCBQTQ0KPiA+IFRvOiBCbGFjaywgRGF2aWQN Cj4gPiBDYzogZGNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogW2RjXSBbYXJtZF0gSVAgb3Zl ciBJUCBzb2x1dGlvbiBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0DQo+ID4NCj4gPiBEYXZp ZCwNCj4gPg0KPiA+IFRoYW5rcyBhZ2Fpbi4gU28gd2hhdCBpcyB5b3VyIHZpZXcgb2YgdGhlIEwy L0wzIGRlYmF0ZT8gSXMgdGhlIGRpcmVjdGlvbiB0bw0KPiB1c2UgbW9yZSBvZiBpU0NTSSBhbmQg TkFTDQo+ID4gb3IgdG8gY29udmVyZ2UgRkMgb3ZlciBFdGhlcm5ldD8gSSB1bmRlcnN0YW5kIHRo YXQgdGhlcmUgbWF5IGJlIHZlcnkgZmV3DQo+IEZDb0UgZGVwbG95bWVudHMgdG9kYXksIGJ1dA0K PiA+IEknbSBhc2tpbmcgaW4gdGVybXMgb2YgeW91ciBwZXJjZXB0aW9uIG9mIHRoZSBkaXJlY3Rp b24uIFdoYXQgdHJlbmRzIHdlDQo+IHBlcmNlaXZlIHZpcy3DoC12aXMgY2xvdWQ/DQo+ID4NCj4g PiBUaGFua3MsIEFzaGlzaA0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+IEZyb206IGRhdmlkLmJsYWNrQGVtYy5jb20gW21haWx0bzpkYXZpZC5ibGFja0BlbWMu Y29tXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMjgsIDIwMTEgOTo1OSBBTQ0KPiA+ IFRvOiBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKQ0KPiA+IENjOiBkY0BpZXRmLm9yZw0KPiA+IFN1 YmplY3Q6IFJFOiBbZGNdIFthcm1kXSBJUCBvdmVyIElQIHNvbHV0aW9uIGZvciBkYXRhIGNlbnRl ciBpbnRlcmNvbm5lY3QNCj4gPg0KPiA+IEFzaGlzaCwNCj4gPg0KPiA+ID4gVGhhbmtzIGZvciB0 aGUgZXhwbGFuYXRpb24uIFNvLCBpdCBpcyBwb3NzaWJsZSB0byBwdWxsIG5ldHdvcmsgYWJzdHJh Y3Rpb25zDQo+IChWTEFOIGV0YykgaW50byB0aGUNCj4gPiA+IHN0b3JhZ2UgY29udHJvbGxlci4N Cj4gPg0KPiA+IFN1cmUgLSBub3Qgb25seSBpcyBpdCBwb3NzaWJsZSwgdGhlcmUncyBhbHNvIHBs ZW50eSBvZiBkZXBsb3llZCBzdG9yYWdlDQo+IGVxdWlwbWVudCB0aGF0IGRvZXMgdGhpcywNCj4g PiB0b2RheS4gIEFsc28sIHBsZWFzZSBhdm9pZCB1c2Ugb2YgdGhlIHBocmFzZSAic3RvcmFnZSBj b250cm9sbGVyIiBpbiB0aGlzDQo+IGRpc2N1c3Npb24sIGFzIHRoYXQncw0KPiA+IG9mdGVuIGEg Y29tcG9uZW50IG9mIGEgbXVjaCBsYXJnZXIgc3RvcmFnZSBzeXN0ZW0sIHN0b3JhZ2UgYXJyYXks IG9yDQo+IGZpbGVzZXJ2ZXIuDQo+ID4NCj4gPiA+IFRoZSBzY2hlbWUgaXMgYWxzbyBleHRlbnNp YmxlIHRvIG90aGVyIHRoaW5ncyBsaWtlIFZYTEFOIG9yIE5WR1JFLg0KPiA+DQo+ID4gWWVzLg0K PiA+DQo+ID4gPiBUaGVuIHlvdSB0aWUgdGhlIGZpbGUgc3lzdGVtIHBlcm1pc3Npb25zIHRvIHRo ZSBWTEFOLiBBbSBJIHJlYWRpbmcgdGhpcw0KPiBjb3JyZWN0bHk/DQo+ID4NCj4gPiBOb3QgZXhh Y3RseSA7LSkuICBXaGlsZSBvbmUgY291bGQgZG8gdGhhdCwgdGhlIHJlc3VsdCBjYW4gYmUgImlu dGVyZXN0aW5nIiBpZg0KPiB0aGVyZSBpcyBJRA0KPiA+IGR1cGxpY2F0aW9uIGFtb25nIHRlbmFu dHMuICBJdCdzIGJldHRlciB0byB1c2Ugc2VwYXJhdGUgZmlsZXN5c3RlbXMgcGVyDQo+IHRlbmFu dCAod2l0aCBlYWNoDQo+ID4gZmlsZXN5c3RlbSB0aWVkIHRvIHRoZSBpZGVudGl0eSBzZXJ2aWNl IGZvciB0aGUgY29ycmVzcG9uZGluZyB0ZW5hbnQpLCBhbmQgdGllDQo+IHRoZSBsaXN0IG9yDQo+ ID4gc2V0IG9mIGV4cG9ydGVkIGZpbGVzeXN0ZW1zIHRvIHRoZSBWTEFOIChvciB2aXJ0dWFsIG5l dHdvcmsgYmFzZWQgb24gVk5JL1ROSSkuDQo+IFRoZSByZXN1bHQNCj4gPiBpcyB0aGF0IGlmIFRl bmFudCBBIGlzIG9uIGEgVkxBTiAob3IgdmlydHVhbCBuZXR3b3JrKSB0aGF0IGlzbid0IHN1cHBv c2VkIHRvDQo+IGhhdmUgYWNjZXNzIHRvDQo+ID4gVGVuYW50IEIgZmlsZXN5c3RlbXMsIGl0IGRv ZXNuJ3QgbWF0dGVyIHdoYXQgSURzIG9yIGFkZHJlc3NlcyBhcmUgZHVwbGljYXRlZA0KPiBvciBm b3JnZWQgb24NCj4gPiBUZW5hbnQgQSdzIFZMQU4gKG9yIHZpcnR1YWwgbmV0d29yaykgLSBUZW5h bnQgQidzIGZpbGVzeXN0ZW1zIGFyZSBpbmFjY2Vzc2libGUNCj4gKGUuZy4sIGNhbid0DQo+ID4g YmUgbW91bnRlZCkuICBGb3IgaVNDU0ksIExVTiBtYXBwaW5nL21hc2tpbmcgaXMgdGhlIGFuYWxv Z291cw0KPiBmdW5jdGlvbmFsaXR5LCBhbmQgdGhhdA0KPiA+IGZ1bmN0aW9uYWxpdHkgaXMgd2lk ZWx5IGltcGxlbWVudGVkIGluIHN0b3JhZ2Ugc3lzdGVtcy4NCj4gPg0KPiA+IFRoYW5rcywNCj4g PiAtLURhdmlkDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBG cm9tOiBkYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mDQo+IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQo+ID4gPiBTZW50OiBUdWVzZGF5 LCBEZWNlbWJlciAyNywgMjAxMSAxMTowOCBQTQ0KPiA+ID4gVG86IEJsYWNrLCBEYXZpZA0KPiA+ ID4gQ2M6IGRjQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW2RjXSBbYXJtZF0gSVAgb3Zl ciBJUCBzb2x1dGlvbiBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0DQo+ID4gPg0KPiA+ID4g RGF2aWQsDQo+ID4gPg0KPiA+ID4gVGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24uIFNvLCBpdCBp cyBwb3NzaWJsZSB0byBwdWxsIG5ldHdvcmsgYWJzdHJhY3Rpb25zDQo+IChWTEFOIGV0YykgaW50 byB0aGUNCj4gPiA+IHN0b3JhZ2UgY29udHJvbGxlci4gVGhlIHNjaGVtZSBpcyBhbHNvIGV4dGVu c2libGUgdG8gb3RoZXIgdGhpbmdzIGxpa2UgVlhMQU4NCj4gb3IgTlZHUkUuIFRoZW4geW91IHRp ZQ0KPiA+ID4gdGhlIGZpbGUgc3lzdGVtIHBlcm1pc3Npb25zIHRvIHRoZSBWTEFOLiBBbSBJIHJl YWRpbmcgdGhpcyBjb3JyZWN0bHk/DQo+ID4gPg0KPiA+ID4gVGhhbmtzLCBBc2hpc2gNCj4gPiA+ DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogZGF2aWQuYmxh Y2tAZW1jLmNvbSBbbWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb21dDQo+ID4gPiBTZW50OiBXZWRu ZXNkYXksIERlY2VtYmVyIDI4LCAyMDExIDI6NTYgQU0NCj4gPiA+IFRvOiBBc2hpc2ggRGFsZWxh IChhZGFsZWxhKQ0KPiA+ID4gQ2M6IGRjQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogW2Rj XSBbYXJtZF0gSVAgb3ZlciBJUCBzb2x1dGlvbiBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0 DQo+ID4gPg0KPiA+ID4gQXNoaXNoLA0KPiA+ID4NCj4gPiA+ID4gSSB3b3VsZCBiZSBpbnRlcmVz dGVkIHRvIGtub3cgaG93IHRoZSBzdG9yYWdlIG11bHRpLXRlbmFuY3kgc29sdXRpb25zDQo+IGRl YWwgd2l0aCBwcml2YXRlIElQLCBNQUMNCj4gPiA+ID4gYW5kIElEICBpbiB0aGUgcHVibGljIGRv bWFpbiwgd2hpY2ggY2FuIGJlIGR1cGxpY2F0ZWQuDQo+ID4gPg0KPiA+ID4gQSBjb21tb24gY3Vy cmVudCB0ZWNobmlxdWUgaXMgdG8gdXNlIHBlci10ZW5hbnQgVkxBTnMgKGEgdGVuYW50IG1heQ0K PiBoYXZlIG11bHRpcGxlIFZMQU5zKSBhbmQgdXNlIE5BVA0KPiA+ID4gKGFzIG5lZWRlZCkgYmV0 d2VlbiB0aGUgVkxBTnMgYW5kIHRoZSBwdWJsaWMgSW50ZXJuZXQgaW4gb3JkZXIgdG8gc2VwYXJh dGUNCj4gVkxBTiBhZGRyZXNzaW5nIGZyb20NCj4gPiA+IHB1YmxpYyBJbnRlcm5ldCBhZGRyZXNz aW5nLCBlZmZlY3RpdmVseSByZXN1bHRpbmcgaW4gYSAodmlydHVhbCkgTkFUIGluc3RhbmNlDQo+ IHBlciBWTEFOLiAgQSAxMi1iaXQNCj4gPiA+IFZMQU4gdGFnIGlzIG5vdCBsYXJnZSBlbm91Z2gg dG8gc2NhbGUgdXAgdG8gdGhlIGRlc2lyZWQgbGFyZ2Utc2NhbGUgZGF0YQ0KPiBjZW50ZXIgc2Nv cGUsIHNvIGJvdGgNCj4gPiA+IFZ4TEFOIGFuZCBOVkdSRSB1c2UgYSAyNC1iaXQgdmlydHVhbCBu ZXR3b3JrIGlkZW50aWZpZXIgdG8gcmVwbGFjZSB0aGUNCj4gMTItYml0IFZMQU4gdGFnOyBWeExB Tg0KPiA+ID4gY2FsbHMgdGhpcyBhIFZOSSAoVnhMQU4gW29yIFZpcnR1YWxdIE5ldHdvcmsgSWRl bnRpZmllciksIGFuZCBOVkdSRSBjYWxscyBpdCBhDQo+IFROSSAoVGVuYW50IE5ldHdvcmsNCj4g PiA+IElkZW50aWZpZXIpLiAgVk5JIGFuZCBUTkkgZW5jYXAvZGVjYXAgY2FuIGJlIGhhbmRsZWQg YnkgdGhlIGh5cGVydmlzb3INCj4gYW5kIGFyZSBsaW1pdGVkIHRvIHRoZQ0KPiA+ID4gZGF0YWNl bnRlcjsgaW4gdGhpcyBzdHJ1Y3R1cmUsIFZNcyBjYW4ndCB1c2UgYSBWTkkgb3IgVE5JIGRpcmVj dGx5LCBhbmQgdGhlDQo+ICh2aXJ0dWFsKSBOQVQgaGFuZGxlcw0KPiA+ID4gZW5jYXAvZGVjYXAg Zm9yIGluYm91bmQvb3V0Ym91bmQgdHJhZmZpYyBzbyB0aGF0IHRyeWluZyB0byBzZW5kDQo+IGVu Y2Fwc3VsYXRlZCAoVnhMQU4gb3IgTkdSRSkgdHJhZmZpYw0KPiA+ID4gaW4gZnJvbSB0aGUgb3V0 c2lkZSByZXN1bHRzIGluIGRvdWJsZSBlbmNhcHN1bGF0aW9uIHdpdGggbm8gZWZmZWN0IG9uIHRl bmFudA0KPiBpc29sYXRpb24uDQo+ID4gPg0KPiA+ID4gQmVmb3JlIG9uZSBvZiB0aGUgTDJWUE4g Zm9sa3MgY29tZXMgYWZ0ZXIgbWUgZm9yIHRoYXQgImxpbWl0ZWQgdG8gdGhlDQo+IGRhdGFjZW50 ZXIiIGNvbW1lbnQgOy0pIC4uLiBhbg0KPiA+ID4gTDJWUE4gZ2F0ZXdheSB3b3VsZCBwcm9iYWJs eSB0cmFuc2xhdGUgYmV0d2VlbiBhIDI0LWJpdCBWTkkvVE5JIGFuZCBhDQo+IDI0LWJpdCBWUE4g SUQgLSBlbmQtdG8tZW5kIHVzZQ0KPiA+ID4gb2YgYSBzaW5nbGUgaWRlbnRpZmllciBmb3IgdGhl IEwyVlBOIGFuZCB0aGUgdmlydHVhbCBuZXR3b3JrcyBvbiBib3RoIGVuZHMgaXMNCj4gcG9zc2li bGUsIGJ1dCAoSU1ITykNCj4gPiA+IGRpZmZpY3VsdCB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBh ZG1pbmlzdHJhdGl2ZSBkb21haW5zIGludm9sdmVkIGluDQo+IG1hbmFnaW5nIHRoZSBpZGVudGlm aWVycy4NCj4gPiA+DQo+ID4gPiBVc2Ugb2YgVkxBTnMgdG8gc2NvcGUgZmlsZXN5c3RlbSB2aXNp YmlsaXR5IG9uIE5BUyBmaWxlc2VydmVycyBpcyBhIGNvbW1vbg0KPiBkZXBsb3llZCBwcmFjdGlj ZSBpbg0KPiA+ID4gZGF0YWNlbnRlcnMgKGRpdHRvIGZvciBWTEFOcyB0byBsaW1pdCBpU0NTSSBz dG9yYWdlIHZpc2liaWxpdHkpLCB0aGVyZWJ5IGRlYWxpbmcNCj4gd2l0aCB0aGUgZm9sbG93aW5n Og0KPiA+ID4NCj4gPiA+ID4gU28sIHlvdSBoYXZlIHRvDQo+ID4gPiA+IHByb3RlY3QgdGhlIG5l dHdvcmsgc3RvcmFnZSBmcm9tIG11bHRpcGxlIHRlbmFudHMgd2hvIGNhbiBoYXZlIHRoZQ0KPiBz YW1lIElQIGFkZHJlc3MgYW5kIE1BQw0KPiA+ID4gPiBhZGRyZXNzLiBOQVMgYXNzdW1lcyB5b3Vy IGlkIG9uIHRoZSBVTklYIGlzIGdsb2JhbGx5IHVuaXF1ZSBhbmQgeW91cg0KPiBwZXJtaXNzaW9u cyBhcmUgdW5pcXVlIC0NCj4gPiA+ID4gbm90IHRydWUgYW55bW9yZS4gU28sIHlvdSBoYXZlIElQ LCBNQUMgYW5kIElEIGR1cGxpY2F0aW9uLg0KPiA+ID4NCj4gPiA+IER1cGxpY2F0aW9uCSBvZiBJ UCwgTUFDIGFuZCBJRCBvbiBzZXBhcmF0ZSBWTEFOcyB3b3JrcyBmaW5lIC0gdGhpcw0KPiBtb2Rl bCBpcyBjYXJyaWVkIG92ZXIgdG8gdmlydHVhbA0KPiA+ID4gbmV0d29ya3MgYmFzZWQgb24gVk5J IG9yIFROSS4gIFRoZSBzZW50ZW5jZSBjb250YWluaW5nICJnbG9iYWxseSB1bmlxdWUiDQo+IChp bmNvcnJlY3RseSkgYXNzdW1lcyBhDQo+ID4gPiBzaW5nbGUgZmlsZXNlcnZlcjsgaW5zdGVhZCwg Y29uc2lkZXIgYSBzaW5nbGUgTkFTIHN5c3RlbSBwcmVzZW50aW5nIHdoYXQgaXMNCj4gZWZmZWN0 aXZlbHkgYSB2aXJ0dWFsDQo+ID4gPiBmaWxlc2VydmVyIHBlciBWTEFOIChvciBWTkkvVE5JKSBh bmQgc2ltaWxhcmx5IGZvciBpU0NTSSAtIHRoYXQgaXMgd2hhdCBzb3J0cw0KPiBvdXQgdGhpcyBk dXBsaWNhdGlvbiwNCj4gPiA+IGluY2x1ZGluZyB1c2Ugb2YgZGlmZmVyZW50IGlkZW50aXR5IHNl cnZpY2VzL3NlcnZlcnMgcGVyIFZMQU4gKG9yIFZOSS9UTkkpLg0KPiA+ID4NCj4gPiA+IFRoYW5r cywNCj4gPiA+IC0tRGF2aWQNCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IERhdmlkIEwuIEJsYWNrLCBEaXN0aW5ndWlzaGVk IEVuZ2luZWVyDQo+ID4gPiBFTUMgQ29ycG9yYXRpb24sIDE3NiBTb3V0aCBTdC4sIEhvcGtpbnRv biwgTUEgIDAxNzQ4DQo+ID4gPiArMSAoNTA4KSAyOTMtNzk1MyAgICAgICAgICAgICBGQVg6ICsx ICg1MDgpIDI5My03Nzg2DQo+ID4gPiBkYXZpZC5ibGFja0BlbWMuY29tICAgICAgICBNb2JpbGU6 ICsxICg5NzgpIDM5NC03NzU0DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBbLi4uIHJlc3Qgb2YgdGhyZWFkIHNuaXBwZWQg Li4uXQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBkYyBtYWlsaW5nIGxpc3QNCj4gZGNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kYw0K From ietf@cdl.asgaard.org Wed Dec 28 21:59:48 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460D321F84DB for ; Wed, 28 Dec 2011 21:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-NHqK-NaaGB for ; Wed, 28 Dec 2011 21:59:47 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 285C521F84D6 for ; Wed, 28 Dec 2011 21:59:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 04423A3BBB7; Thu, 29 Dec 2011 05:59:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHYkz-RFImHe; Thu, 29 Dec 2011 05:59:43 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id 1ED83A3BBAC; Thu, 29 Dec 2011 05:59:43 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: Date: Wed, 28 Dec 2011 21:59:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2E742C02-F621-497D-AE06-6A91EEEBA498@cdl.asgaard.org> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <201112281650.pBSGo7Mn011365@cichlid.raleigh.ibm.com> To: Bhumip Khasnabish X-Mailer: Apple Mail (2.1251.1) Cc: Thomas Narten , Ronald Bonica , dc@ietf.org, "So, Ning" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 05:59:48 -0000 Greetings Bhumip, This may sound harsh, and I don't want to diminish the amount of hard = work that went into the documents listed below, but I think we may need = to do a bit of a reset in this conversation. Comments in line.... On 28Dec2011, at 17.40, Bhumip Khasnabish wrote: > Hello Thomas, >=20 > Yes, these are high-level very important one-liner data center related > topics/issues. >=20 > We have a draft that covers > SDO survey = (http://tools.ietf.org/html/draft-khasnabish-cloud-sdo-survey-01). > This > is basically a summary of which SDO is trying to do what and what IETF = can > do. I'm not sure of the value of this survey, to be frank. It lists a = number of SDO's that may be involved in "cloud" in some way. Actually, = looking at the list, I see very few that are doing anything that is = actually driving the industry at this time. More of the development in = the industry of standards is coming from non-SDO or new semi-SDO = organizations and vendors/providers of services. For example, Amazon = has published a set of API's that a number of other entities are busy = implementing, ONF is busy standardizing the OpenFlow protocol, OpenFlow = operational models, and a management framework. OpenStack is busy = defining a complete "cloud" operating environment and stack. None of = them show up in the SDO document, but, to be frank, are probably having = a greater impact in this area than the majority of the SDO's listed in = the document. There are other examples if one wants to dig. Secondly, the question we should be asking is "What does the IETF NEED = to do" not "What can the IETF do" We can do a great many things, the = bulk of which will not be helpful or a good use of resources. > We need comments and suggestions from you and others to update this = doc. >=20 > We also have another draft covering potential work items > ( > = http://tools.ietf.org/html/draft-khasnabish-cloud-industry-workitems-surve= y-01 Again, I'm not sure of the value of this document. What is the source = for these "work items"? What real or near-to-mid term problems are they = trying to address? What ones are relevant to the IETF? I basically see = a catch-all list of a number of things that someone somewhere has = thought might be a problem that may need to be solved in a "cloud" = environment. Some of the real issues I hear operators talking about = (including myself if I channel myself from 8 months ago) (not = theoretical, but "I have this problem now or will soon" are somehow = covered in some of the work items - but the majority of work items = listed don't really cover what I've heard of as current problems. Even = the work items that cover existing problems are very broad, and cover = MUCH more than the real issues that are being discussed in the = operational community. > ). >=20 > We can discuss these further in the interim mtg. I'm not sure how fruitful such a conversation might be. A = boil-the-ocean interim meeting won't produce concrete actionable = directions unless we are VERY focused in the conversation - not an IETF = strong suit. I would like to propose a different approach, if I may. If we took a = focused set of problem statements and ran them through the following set = of filters: 1) Is this a current/real or near-to-mid term probable issue and is it = substantial? 2) If yes, is it being adequately covered by another SDO and is it in = that SDO's domain? 3) if no, is it in the domain of IETF competency? 4) if yes, do we want to work on it? There are many other interesting problems outlined in the various = documents that have been listed. They could, in time be picked up by = the IETF, liaised to some other SDO, or handed to the IRTF for in-depth = study. However, if we take the body of work that is being proposed, we = will fail at boiling an ocean that, in many cases, we don't even live = in. We will take too long, cast too broad a net, and be bypassed before = we even get WG drafts issued. In Taipei, we heard, I think, two good sets of problem statements, those = made by Tomas Narten, and Tom Nadeau. More contributions in that vein, = preferably with real operational input, would be very helpful in forming = the conversation for the interim meeting. >=20 > In my email, the domain means admin. domain, apps/service domain, > resource domain, etc > There are many proprietary and app-/service-specific interim (neither > scalable nor distributed) solution for many of the problems that I = mention, > but IETF > can prioritize and focus on a few and can help develop > scalable/distributed/interoperable solution, best practices, etc. In this we are closer in alignment, but I think we start from the = operational problem side of the house, rather than the whole universe of = possibilities. >=20 > We can develop a template to prepare a list of topics and issues > for each of the items that IETF can contribute to. The IETF doesn't as a rule, contribute. We either develop standards or = we observe and occasionally liaise. There is too broad a space here to = be effective if we try and "contribute" to the whole problem space, in = my opinion. >=20 > Any other suggestions? >=20 Thank you for starting the conversation, Chris > Thanks again. >=20 > Best. >=20 > Bhumip >=20 >=20 > On Wed, Dec 28, 2011 at 11:50 AM, Thomas Narten = wrote: >=20 >> Hi Bhumip. >>=20 >> This post (and a few others) seem to me to be providing a laundry = list >> of buzz words and generic "requirements". >>=20 >> What this group needs to do is identify concrete problems for which >> lack of a standard is preventing solutions. >>=20 >> For the items mentioned above, what is the actual concrete standards >> work that needs to be done? >>=20 >> Bhumip Khasnabish writes: >>=20 >>=20 >>> =C2=B7 Support of on-demand provisioning and management = (availability) of >>> distributed virtualized computing, communications, and >>> storage resources >>=20 >> This is too broad and high-level to be helpful. That is, this comes >> across as a motherhood-and-apple-pie wish list. We need to drill down >> into something much more concrete. >>=20 >> What standards are lacking today that prevent the above from being >> possible? >>=20 >> How does the above translate into gaps that the IETF needs to fill? >>=20 >>> =C2=B7 Offering of seamless mobility of virtual machine (VM), = virtualized >>> interface (VI), virtualized network elements (VNE) and >>> virtualized storage (VS) from one domain to another for = load >>> balancing and service continuity management >>=20 >> Same comment again. Also, what is a "domain" above? >>=20 >> Also, there are already proprietary systems/products that provide VM >> mobility. What is it that the IETF needs to do? >>=20 >>> =C2=B7 Management of security, privacy, data integrity, and log of = Data >>> center services for audit and verification >>=20 >> Again, broad wish list. How does this translate into specific gaps >> that the IETF needs to fill? >>=20 >>> =C2=B7 Support of Distributed scaling and multi-tenancy support = without >>> excessive complexity and resource consumption >>=20 >> Ditto. >>=20 >>> =C2=B7 Support of Naming and addressing of virtualized entities for >>> simplified mobility and service continuity management >>=20 >> Ditto >>=20 >>> =C2=B7 Support of Realistic Service level agreement parameters for = Data >>> center resources and services >>=20 >> Ditto. >>=20 >>> * Support of Visualization of resources utilization and automation = of >>> provisioning >>=20 >> Ditto. >>=20 >> Thomas >>=20 >>=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf From xuxiaohu@huawei.com Thu Dec 29 00:56:28 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9859121F85AE for ; Thu, 29 Dec 2011 00:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZywZCy2gpgQV for ; Thu, 29 Dec 2011 00:56:28 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9072121F8591 for ; Thu, 29 Dec 2011 00:56:27 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWY00G7IJHY6I@szxga05-in.huawei.com> for dc@ietf.org; Thu, 29 Dec 2011 16:56:22 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWY00BDEJHYYE@szxga05-in.huawei.com> for dc@ietf.org; Thu, 29 Dec 2011 16:56:22 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGC17018; Thu, 29 Dec 2011 16:56:10 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Dec 2011 16:55:50 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0323.003; Thu, 29 Dec 2011 16:55:53 +0800 Date: Thu, 29 Dec 2011 08:55:52 +0000 From: Xuxiaohu In-reply-to: <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> X-Originating-IP: [10.108.4.80] To: Thomas Narten , Russ White Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE76387F@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dc] Elevator Pitch Thread-index: AQHMw1wuBgE5G7BjGEyEvGVWBnVRbZXw96YAgAF/L4A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> Cc: "dc@ietf.org" Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 08:56:28 -0000 SGkgVGhvbWFzLA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGRjLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpkYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFRob21hcw0KPiBOYXJ0 ZW4NCj4gt6LLzcqxvOQ6IDIwMTHE6jEy1MIyOcjVIDE6MDENCj4gytW8/sjLOiBSdXNzIFdoaXRl DQo+ILOty806IGRjQGlldGYub3JnDQo+INb3zOI6IFJlOiBbZGNdIEVsZXZhdG9yIFBpdGNoDQo+ IA0KPiA+IDEuIEhvdyBtYW55IGhvc3Qgcm91dGVzIGRvIHdlIHJlYWNoIGJlZm9yZSB3ZSBzYXkg aXQgIndvbid0IHNjYWxlPyIgSWYNCj4gPiB5b3UncmUgdGFsa2luZyBhYm91dCBsZWFmIG5vZGVz IGluIGEgcm91dGluZyBwcm90b2NvbCwgMTAwayBpc24ndCByZWFsbHkNCj4gPiB0aGF0IGJpZyBv ZiBhIGRlYWwuIFdoZXJlIHlvdSBkbyBydW4gaW50byBwcm9ibGVtcyBpcyBiZXR3ZWVuIHRoZQ0K PiA+IHJvdXRpbmcgYW5kIGZvcndhcmRpbmcgdGFibGVzIC0tYnV0IHRoYXQncyBhbiBhcmVhIGZv ciB0aG91Z2h0Lg0KPiANCj4gQWN0dWFsbHksIDEwMEsgaG9zdCByb3V0ZXMgaW4gbGVhZiBub2Rl cyBtYXkgd2VsbCBiZSBhIEJpZyBEZWFsLiBJdA0KPiBkZXBlbmRzIG9uIHdoYXQgdHlwZSBvZiBk ZXZpY2VzIG5lZWQgdG8gdW5kZXJzdGFuZCBob3N0IHJvdXRlcy4NCj4gDQo+IEZvciB0aGUgc2Nl bmFyaW9zIE5WTzMgaXMgbG9va2luZyBhdCwgdGhlIGVkZ2UgZGV2aWNlIGluY2x1ZGVzIGVkZ2UN Cj4gc3dpdGNoZXMgYW5kIGh5cGVydmlzb3JzLiBZZXMsIHN1Y2ggZGV2aWNlcyBjYW4gaW4gdGhl b3J5IHN1cHBvcnQgMTAwSw0KPiBob3N0IHJvdXRlcyAoYW5kIHRoZSByb3V0aW5nIHByb3RvY29s IG5lZWRlZCB0byBtYWtlIHRoYXQgY29udmVyZ2UpLg0KPiANCj4gQnV0IGF0IGEgY29zdC4NCj4g DQo+IEFuZCBJIHN1c3BlY3QgdGhlIGNvc3QgaXMgdG9vIGhpZ2guDQo+IA0KPiBEbyB5b3UgdGhp bmsgZGF0YSBjZW50ZXIgb3BlcmF0b3JzIHdpbGwgd2FudCB0byBydW4gcm91dGluZyBwcm90b2Nv bHMNCj4gaW4gaHlwZXJ2aXNvcnMgdGhhdCBoYXZlIHRvIGhhbmRsZSAxMDBLIGhvc3Qgcm91dGVz PyBFc3BlY2lhbGx5IGlmDQo+IHN1Y2ggZGV2aWNlcyB3aWxsIG5lZWQgdG8gYmUgdXBncmFkZWQg d2l0aCBiZXR0ZXIgaGFyZHdhcmUgdG8gc3VwcG9ydA0KPiBzdWNoIGEgbG9hZD8NCg0KSWYgdGhl eSBuZWVkIHRvIGJlIHVwZ3JhZGVkIHdpdGggYmV0dGVyIGhhcmR3YXJlLCB3aHkgbm90IGRpcmVj dGx5IGNvbnNpZGVyIHRoZSBwaHlzaWNhbCBlZGdlIHN3aXRjaGVzIChlLmcuLCBUb1Igc3dpdGNo ZXMpIGFzIGxlYWYgbm9kZXM/IA0KDQpCVFcsIGluIHRoZSB0eXBpY2FsIG11bHRpLXRlbmFudCBj bG91ZCBkYXRhIGNlbnRlciBlbnZpcm9ubWVudCB3aGVyZSBtb3N0IG9mIHRoZSB0ZW5hbnRzIGFy ZSBiZWxpZXZlZCB0byBiZSBTTUJzLCB0aGUgcm91dGUgYW1vdW50IG9mIGFueSBnaXZlbiB0ZW5h bnQgZG9tYWluIHdvdWxkIG5vdCBiZSB0b28gbGFyZ2UuIEhlbmNlLCBldmVuIHRoZXJlIGFyZSBt b3JlIHRoYW4gMU0gaG9zdCByb3V0ZXMgaW4gdG90YWwsIHRoZSByb3V0ZSBhbW91bnQgb24gYW55 IGxlYWYgbm9kZSB3b3VsZCBub3QgYmUgdG9vIGxhcmdlIHNpbmNlIHRoZSB0ZW5hbnQgYW1vdW50 IG9uIGFueSBsZWFmIG5vZGUgd291bGQgbm90IGJlIHRvbyBsYXJnZS4gVGhlIG1heGltdW0gdGVu YW50IGFtb3VudCBvbiBhbnkgbGVhZiBub2RlIGlzIGxpbWl0ZWQgYnkgYXQgbGVhc3QgdGhlIGZv bGxvd2luZyB0d28gZmFjdG9yczogMSkgdGhlIHBvcnQgZGVuc2l0eSBvZiBsZWF2ZSBub2Rlczsg MikgdGhlIFZNIGRlbnNpdHkgb2YgcGh5c2ljYWwgc2VydmVycy4gSW4gYWRkaXRpb24sIGluIHRo ZSBjYXNlIHdoZXJlIHRoZSBub24tYmxvY2tpbmcgREMgZmFicmljIGlzIG5vdCB5ZXQgYSByZWFs aXR5IGR1ZSB0byBpdHMgaGlnaCBjb3N0LCB0aGUgVk1zIG9mIGEgZ2l2ZW4gdGVuYW50IHdvdWxk IGJlIHBsYWNlZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSwgZm9yIGV4YW1wbGUsIGJlaW5nIGF0dGFj aGVkIHRvIGEgc2luZ2xlIGxlYWYgbm9kZSBpZiBwb3NzaWJsZSwgc28gYXMgdG8gcmVkdWNlIHRo ZSBiYW5kd2lkdGggY29uc3VtcHRpb24gb24gdGhlIHVwbGlua3MuIEluIHRoaXMgd2F5LCB0aGUg YXZlcmFnZSB0ZW5hbnQgYW1vdW50IG9uIGEgZ2l2ZW4gbGVhZiBub2RlIHdvdWxkIGJlIGV2ZW4g bGVzcy4NCg0KDQo+IE9yIHdpbGwgdGhleSB3YW50IGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoPw0K PiANCj4gPiAyLiBXaHkgZG9lcyB0aGlzIG1vYmlsaXR5IG5lZWQgdG8gYmUgYXQgbGF5ZXIgMiBz cGVjaWZpY2FsbHk/IEFyZSB3ZQ0KPiA+IGFzc3VtaW5nIERETlMgYW5kIG90aGVyIHNvcnRzIG9m IHNvbHV0aW9ucyBpbiB0aGlzIHNwYWNlIHdpbGwgc2ltcGx5DQo+ID4gbmV2ZXIgYmUgZmFzdCBl bm91Z2gvc2NhbGUgZmFyIGVub3VnaC9ldGM/DQo+IA0KPiBMaWtlIGl0IG9yIG5vdCwgdGhlIGtl eSByZXF1aXJlbWVudCBmb3IgVk0gbW9iaWxpdHkgaXMgdGhhdCB0aGUgVk0ncw0KPiBJUCBhZGRy ZXNzIGRvZXMgbm90IGNoYW5nZS4gVGhhdCBtZWFucyB0aGUgVk0gY2FuJ3QgcmVhbGx5IG1vdmUg ZnJvbQ0KPiBvbmUgSVAgc3VibmV0IHRvIGFub3RoZXIuIFRoYXQgbWVhbnMgZWl0aGVyIG1vdmlu ZyB0byBiaWdnZXIgYW5kDQo+IGJpZ2dlciBMMnMgKGFsbCB1bmRlciBvbmUgSVAgc3VibmV0KSBh cyB0aGUgREMgZXhwYW5kcyBvciB0aGUgbmVlZCB0bw0KPiBpbmplY3QgLzMyIGhvc3Qgcm91dGVz Lg0KDQpJbiB0aGUgRENJIHNjZW5hcmlvIHdoZXJlIHRoZSBQRSByb3V0ZXJzIGFyZSB1c3VhbGx5 IHBlcmZvcm1lZCBhdCB0aGUgYWdncmVnYXRpb24gU1dzIG9yIGV2ZW4gY29yZSBTV3MsIHRoZSBQ RSByb3V0ZXJzIHdvdWxkIG5lZWQgYSBtdWNoIGxhcmdlIGZvcndhcmRpbmcgdGFibGUuIFByb3Zp ZGVkIHRoZSByb3V0aW5nIHRhYmxlIGNvbnRhaW5pbmcgbWlsbGlvbnMgb2YgZW50cmllcywgd2hp Y2ggaXMgYXZhaWxhYmxlIG9uIG1vc3QgdG9kYXkncyBoaWdoLWVuZCByb3V0ZXJzLCB3YXMgc3Rp bGwgbm90IGxhcmdlIGVub3VnaCwgdGhlIG9uLWRlbWFuZCBGSUIgaW5zdGFsbGF0aW9uIG9yIG9u LWRlbWFuZCByb3V0ZSBhbm5vdW5jZW1lbnQgbWVjaGFuaXNtcyBjYW4gYmUgdXNlZCBmdXJ0aGVy IHRvIHNjYWxlIHRoZSBzb2x1dGlvbi4gTm90ZSB0aGF0IHRoZSB0cmlnZ2VyIGZvciB0aGUgRklC IGluc3RhbGxhdGlvbiBvciByb3V0ZSBhbm5vdW5jZW1lbnQgaXMgQVJQIHJlcXVlc3QgcGFja2V0 cyByYXRoZXIgdGhhbiBkYXRhIHBhY2tldHMuIEhlbmNlIGl0IHdpbGwgbm90IGNhdXNlIHRoZSBz by1jYWxsZWQgaW5pdGlhbCBwYWNrZXQgbG9zcyBvciBsYXRlbmN5IGlzc3VlLg0KDQo+IE5laXRo ZXIgb2YgdGhvc2UgYXBwcm9hY2hlcyBzZWVtcyBwYXJ0aWN1bGFybHkgc2NhbGFibGUvZGVzaXJh YmxlIGlmDQo+IHlvdSBsb29rIDEwIHllYXJzIGRvd24gdGhlIHJvYWQgYW5kIHRoaW5rIG9mIDFN KyBwaHlzaWNhbCBtYWNoaW5lcyBpbg0KPiBhIERDLg0KDQpNYXliZSB3ZSBzaG91bGQgYWxzbyB0 YWtlIHRoZSBkZXZlbG9wbWVudCBzcGVlZCBvZiByb3V0aW5nL3N3aXRjaGluZyBjaGlwIGFuZCBD UFUgdGVjaG5vbG9naWVzIGludG8gYWNjb3VudDopDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K ICAgDQo+IFRob21hcw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gZGMgbWFpbGluZyBsaXN0DQo+IGRjQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGMNCg== From russw@riw.us Thu Dec 29 07:08:32 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6D021F8A4E for ; Thu, 29 Dec 2011 07:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTTqGNakg1Pg for ; Thu, 29 Dec 2011 07:08:32 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id D84B021F849E for ; Thu, 29 Dec 2011 07:08:31 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:64451 helo=[192.168.100.61]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RgHam-0002Mb-FB for dc@ietf.org; Thu, 29 Dec 2011 10:08:28 -0500 Message-ID: <4EFC826C.80708@riw.us> Date: Thu, 29 Dec 2011 10:08:28 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dc@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> In-Reply-To: <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 15:08:32 -0000 > Actually, 100K host routes in leaf nodes may well be a Big Deal. It > depends on what type of devices need to understand host routes. So let me try to abstract the problem a little... There are two things that cost money in building a network: 1. State --the more you carry, the more hardware is going to cost. 2. Bandwidth --the less optimal your bandwidth utilization, the more you're spending on something that's not used. The first rule of all network design is that the more state you put in a network, the more optimal your bandwidth usage. To reduce the cost of bandwidth, you have to spend money on state. To reduce the cost of state, you must increase your spending on bandwidth. The second of network design is the balance point where the network is cheapest is different in every network. So, IMHO, the point of protocol design should be to allow the design the maximum amount of flexibility and granularity in when and where to hide information, to make the right tradeoff for any particular network. Now, to return to the discussion at hand: If you don't want to pay for devices that will handle 100 million routes, but you have 100 million devices, then you're going to have some degree of suboptimal bandwidth utilization. There's simply no way around this reality. IMHO, however we resolve this problem, we need to resolve it in a way that allows an operator to support 100 million routes in every node, if they choose to optimize for bandwidth at the cost of hardware. Or to support 1 route in every node using really cheap hardware, if they want to optimize for state. Or for any point in the sliding scale in between (within reason). So this control plane needs to: 1. Be able to support 100 million destinations at the host level (that doesn't mean 100 million paths, but only 100 million destinations --two different problems). 2. Be able to aggregate to hide information at anyplace that's logical within the network. BTW, some folks would like to solve this problem by making the control plane react to the data plane --but this carries it's own baggage in complexity and in operational capabilities. Reactive control planes always converge more slowly, and waste bandwidth at a rate that's arguably higher than simple aggregation. So there's no "silver bullet" waiting in the wings in the form of caching at the control plane level. >> 2. Why does this mobility need to be at layer 2 specifically? Are we >> assuming DDNS and other sorts of solutions in this space will simply >> never be fast enough/scale far enough/etc? > > Like it or not, the key requirement for VM mobility is that the VM's > IP address does not change. That means the VM can't really move from > one IP subnet to another. That means either moving to bigger and > bigger L2s (all under one IP subnet) as the DC expands or the need to > inject /32 host routes. Again, the same tradeoff as above --moving to a bigger l2 domain also means losing the ability to optimally direct traffic through the network (unless you put another control plane on top of the l2 and l3 control planes already in existence --which just adds the complexity you're trying to get away from in the host routes back into the network state!). > Neither of those approaches seems particularly scalable/desirable if > you look 10 years down the road and think of 1M+ physical machines in > a DC. There is no "particularly desirable" solution, in reality, because building a network with no control plane state anyplace that uses bandwidth in a perfectly optimal way is simply impossible no matter how you slice it (unless you're going to go into quantum routing!). :-) Russ From lizhong.jin@zte.com.cn Thu Dec 29 07:29:27 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C5C21F8876 for ; Thu, 29 Dec 2011 07:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6203Aotq68U for ; Thu, 29 Dec 2011 07:29:26 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 551AA21F8801 for ; Thu, 29 Dec 2011 07:29:25 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690122734555; Thu, 29 Dec 2011 23:09:41 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 4315.3316216250; Thu, 29 Dec 2011 23:29:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pBTFT880013463; Thu, 29 Dec 2011 23:29:08 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: dc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Thu, 29 Dec 2011 23:28:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-29 23:29:11, Serialize complete at 2011-12-29 23:29:11 Content-Type: multipart/alternative; boundary="=_alternative 00550FBB48257975_=" X-MAIL: mse01.zte.com.cn pBTFT880013463 Cc: narten@us.ibm.com, Ning So , rbonica@juniper.net Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 15:29:27 -0000 This is a multipart message in MIME format. --=_alternative 00550FBB48257975_= Content-Type: text/plain; charset="US-ASCII" Hi, all I would like to raise one more requirement: The performance should be isolated amonge different service. That means one service should not have the capability to influence the performance of other service. To make it more clear, for example, the broadcast traffic of one service should not affect other service performance, especially when the VM migrating, the performance of different service should also be isolated. Note, the performance here refer to network performance of the service. One more point is, we should care about the performance of hypervisor, if we design too many features on software based hypervisor, there would be some risk. Thanks Lizhong > > -----From Ronald Bonica ,at Thu, 22 Dec > 2011 17:10:12 -0500 ----- > > to: > > Thomas Narten , "So, Ning" > > cc: > > "dc@ietf.org" > > Subject: > > [dc] Elevator Pitch (was: Scoping the Interim meeting) > > Folks, > > Amplifying what Thomas said: > > At this point, the most helpful thing that anyone can do is to > summarize the problem(s) that we are trying to solve in a relatively > terse email. Once we come to consensus on that brief summary, we can > flesh it out into very short Internet Draft. > > I look forward to hearing your elevator pitches. > > Happy Holidays, > Ron > > > > -----Original Message----- > > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > > Thomas Narten > > Sent: Wednesday, December 21, 2011 1:31 PM > > To: So, Ning > > Cc: Ronald Bonica; dc@ietf.org > > Subject: Re: [dc] Scoping the Interim meeting > > > > We sure have a lot of volunteers wanting to help. That is fine at one > > level, but misses the bigger point. > > > > The best way to help is to articulate a specific problem or area. > > > > Do so on this list in a single message. We don't need yet more > > documents (at least not yet). > > > > 2-4 paragraphs (no more). Think "elevator pitch" > > (http://en.wikipedia.org/wiki/Elevator_pitch). > > > > You only get a couple of minutes to make your case, and if you can't > > do so, either you don't understand the problem yourself well enough, > > or the value-proposition just isn't compelling. > > > > So far, I haven't seen discussions of specific problems (or problem > > areas). What I'm seeing is pointers to lots of drafts, many of which > > (for those that I've looked at) don't crisply get at a real, tangible > > problem that I understand and think the IETF can/should work on. Bonus > > points for showing: > > > > 1) an operator (or some other clear customer/consumer technology) that > > says "yes, that is what I need, and if it was available today, I'd > > use it" > > > > 2) a vendor saying "here is what my customers are telling me will > > solve a problem of theirs", and we think an IETF standard is > > needed. > > > > 3) demonstration of a clear technical/protocol gap between what is > > available today, and what is needed to address the problem. > > > > Thomas > > > > _______________________________________________ > > dc mailing list > > dc@ietf.org > > https://www.ietf.org/mailman/listinfo/dc > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00550FBB48257975_= Content-Type: text/html; charset="US-ASCII"
Hi, all
I would like to raise one more requirement:
The performance should be isolated amonge different service. That means one service should not have the capability to influence the performance of other service. To make it more clear, for example, the broadcast traffic of one service should not affect other service performance, especially when the VM migrating, the performance of different service should also be isolated.

Note, the performance here refer to network performance of the service.

One more point is, we should care about the performance of hypervisor, if we design too many features on software based hypervisor, there would be some risk.

Thanks
Lizhong


>
> -----From Ronald Bonica <rbonica@juniper.net> ,at Thu, 22 Dec
> 2011 17:10:12 -0500 -----
>
> to:
>
> Thomas Narten <narten@us.ibm.com>, "So, Ning" <ning.so@verizon.com>
>
> cc:
>
> "dc@ietf.org" <dc@ietf.org>
>
> Subject:
>
> [dc] Elevator Pitch (was: Scoping the Interim meeting)
>
> Folks,
>
> Amplifying what Thomas said:
>
> At this point, the most helpful thing that anyone can do is to
> summarize the problem(s) that we are trying to solve in a relatively
> terse email. Once we come to consensus on that brief summary, we can
> flesh it out into very short Internet Draft.
>
> I look forward to hearing your elevator pitches.
>
>                                                      Happy Holidays,
>                                                         Ron
>
>
> > -----Original Message-----
> > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of
> > Thomas Narten
> > Sent: Wednesday, December 21, 2011 1:31 PM
> > To: So, Ning
> > Cc: Ronald Bonica; dc@ietf.org
> > Subject: Re: [dc] Scoping the Interim meeting
> >
> > We sure have a lot of volunteers wanting to help. That is fine at one
> > level, but misses the bigger point.
> >
> > The best way to help is to articulate a specific problem or area.
> >
> > Do so on this list in a single message. We don't need yet more
> > documents (at least not yet).
> >
> > 2-4 paragraphs (no more).  Think "elevator pitch"
> > (http://en.wikipedia.org/wiki/Elevator_pitch).
> >
> > You only get a couple of minutes to make your case, and if you can't
> > do so, either you don't understand the problem yourself well enough,
> > or the value-proposition just isn't compelling.
> >
> > So far, I haven't seen discussions of specific problems (or problem
> > areas). What I'm seeing is pointers to lots of drafts, many of which
> > (for those that I've looked at) don't crisply get at a real, tangible
> > problem that I understand and think the IETF can/should work on. Bonus
> > points for showing:
> >
> > 1) an operator (or some other clear customer/consumer technology) that
> >    says "yes, that is what I need, and if it was available today, I'd
> >    use it"
> >
> > 2) a vendor saying "here is what my customers are telling me will
> >    solve a problem of theirs", and we think an IETF standard is
> >    needed.
> >
> > 3) demonstration of a clear technical/protocol gap between what is
> >    available today, and what is needed to address the problem.
> >
> > Thomas
> >
> > _______________________________________________
> > dc mailing list
> > dc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dc
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00550FBB48257975_=-- From russw@riw.us Thu Dec 29 08:25:32 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64B621F85CE for ; Thu, 29 Dec 2011 08:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g4KaM5QB0af for ; Thu, 29 Dec 2011 08:25:32 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5F93321F85B9 for ; Thu, 29 Dec 2011 08:25:32 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:49293 helo=[192.168.100.61]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RgInK-0002yf-Mq for dc@ietf.org; Thu, 29 Dec 2011 11:25:30 -0500 Message-ID: <4EFC947A.4020007@riw.us> Date: Thu, 29 Dec 2011 11:25:30 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dc@ietf.org References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE762EB4@szxeml525-mbs.china.huawei.com> <618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com> In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102B250DA@XMB-BGL-416.cisco.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [dc] [armd] IP over IP solution for data center interconnect X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 16:25:32 -0000 > That means that if you have to protect data, you have to know somehow which host is allowed to see which disks. Doing this end-to-end using TCP/IP is problematic because the NAS controller doesn't know about tenant id, and whether the MAC and IP are being duplicated across customers. To make the storage aware of segmentation, you have to carry some segment (GRE, MPLS, VLAN, etc.) into the storage box. That's not true today. Maybe I'm dense, but wouldn't it be just as easy to add the capability to differentiate based on IP address as it would be to design the entire network and all protocols around what the current software capabilities on the hypervisor are? :-) Russ From cdl@asgaard.org Thu Dec 29 09:20:08 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E7A21F8AF0 for ; Thu, 29 Dec 2011 09:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.744 X-Spam-Level: X-Spam-Status: No, score=-5.744 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL2UQbh25kqH for ; Thu, 29 Dec 2011 09:20:07 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id A338621F8ADC for ; Thu, 29 Dec 2011 09:20:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 9060AA4000C; Thu, 29 Dec 2011 17:20:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7iqeb6EvOSA; Thu, 29 Dec 2011 17:20:04 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id C6FF5A40004; Thu, 29 Dec 2011 17:20:04 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE76387F@szxeml525-mbs.china.huawei.com> Date: Thu, 29 Dec 2011 09:20:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <229A8E99-6EB2-49E5-B530-BA0F6C7C40AC@asgaard.org> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE76387F@szxeml525-mbs.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Thu, 29 Dec 2011 09:29:16 -0800 Cc: Thomas Narten , Russ White , "dc@ietf.org" Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 17:20:08 -0000 Greetings Xuxiaohu, On 29Dec2011, at 00.55, Xuxiaohu wrote: > Hi Thomas, >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: dc-bounces@ietf.org = [mailto:dc-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Thomas >> Narten >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B412=E6=9C=8829=E6=97=A5= 1:01 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Russ White >> =E6=8A=84=E9=80=81: dc@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [dc] Elevator Pitch >>=20 >>> 1. How many host routes do we reach before we say it "won't scale?" = If >>> you're talking about leaf nodes in a routing protocol, 100k isn't = really >>> that big of a deal. Where you do run into problems is between the >>> routing and forwarding tables --but that's an area for thought. >>=20 >> Actually, 100K host routes in leaf nodes may well be a Big Deal. It >> depends on what type of devices need to understand host routes. >>=20 >> For the scenarios NVO3 is looking at, the edge device includes edge >> switches and hypervisors. Yes, such devices can in theory support = 100K >> host routes (and the routing protocol needed to make that converge). >>=20 >> But at a cost. >>=20 >> And I suspect the cost is too high. >>=20 >> Do you think data center operators will want to run routing protocols >> in hypervisors that have to handle 100K host routes? Especially if >> such devices will need to be upgraded with better hardware to support >> such a load? >=20 > If they need to be upgraded with better hardware, why not directly = consider the physical edge switches (e.g., ToR switches) as leaf nodes?=20= >=20 > BTW, in the typical multi-tenant cloud data center environment where = most of the tenants are believed to be SMBs, the route amount of any = given tenant domain would not be too large. Hence, even there are more = than 1M host routes in total, the route amount on any leaf node would = not be too large since the tenant amount on any leaf node would not be = too large. The maximum tenant amount on any leaf node is limited by at = least the following two factors: 1) the port density of leave nodes; 2) = the VM density of physical servers. In addition, in the case where the = non-blocking DC fabric is not yet a reality due to its high cost, the = VMs of a given tenant would be placed as close as possible, for example, = being attached to a single leaf node if possible, so as to reduce the = bandwidth consumption on the uplinks. In this way, the average tenant = amount on a given leaf node would be even less. There are folks who are looking at the ToR as the leaf node, and, in my = opinion, any solution will probably be a hybrid of ToR and hypervisor. = However, remember that the hypervisor switch is still the first = aggregation point, and therefore, is the leaf in a network tree. Some = level of state aggregation (and accompanying loss) will occur at the = hypervisor switch, making it the leaf. Also, there are scaling issues = with having 10's (or 100's in the case of some operators) vm's running = on each server, and having 20-40 servers running into the ToR - all of a = sudden, the host-table alone on the ToR becomes mildly interesting, even = without other (intra-data center) routes on low CAM ToR switches. Not = all solutions will map to all (or most) customers. Also, the comment to limit the route-tabel of tenants due to small = numbers of hosts may not always (or usually) match reality. What of the = cross-data-center traffic for other services either provided by the = hoster, or other tenants? Continuing to route ALL of that traffic = through routing/switching nodes external to the "fabric" will lead to = it's own scaling issues. Don't assume that the only routes that an SMB = needs are it's own. >=20 >=20 >> Or will they want an alternative approach? >>=20 >>> 2. Why does this mobility need to be at layer 2 specifically? Are we >>> assuming DDNS and other sorts of solutions in this space will simply >>> never be fast enough/scale far enough/etc? >>=20 >> Like it or not, the key requirement for VM mobility is that the VM's >> IP address does not change. That means the VM can't really move from >> one IP subnet to another. That means either moving to bigger and >> bigger L2s (all under one IP subnet) as the DC expands or the need to >> inject /32 host routes. >=20 > In the DCI scenario where the PE routers are usually performed at the = aggregation SWs or even core SWs, the PE routers would need a much large = forwarding table. Provided the routing table containing millions of = entries, which is available on most today's high-end routers, was still = not large enough, the on-demand FIB installation or on-demand route = announcement mechanisms can be used further to scale the solution. Note = that the trigger for the FIB installation or route announcement is ARP = request packets rather than data packets. Hence it will not cause the = so-called initial packet loss or latency issue. >=20 >> Neither of those approaches seems particularly scalable/desirable if >> you look 10 years down the road and think of 1M+ physical machines in >> a DC. >=20 > Maybe we should also take the development speed of routing/switching = chip and CPU technologies into account:) It's more a question of cost/performance on off-chip memory/TCAMs. That = is a slightly different curve :) Chris >=20 > Best regards, > Xiaohu >=20 >> Thomas >>=20 >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf From cdl@asgaard.org Thu Dec 29 09:27:59 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0821F8B06 for ; Thu, 29 Dec 2011 09:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf2q6SCWU6No for ; Thu, 29 Dec 2011 09:27:58 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5425A21F8B01 for ; Thu, 29 Dec 2011 09:27:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 3FB34A400E1; Thu, 29 Dec 2011 17:27:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi3Q4twXBI9s; Thu, 29 Dec 2011 17:27:56 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id C618CA400D6; Thu, 29 Dec 2011 17:27:56 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: <4EFC826C.80708@riw.us> Date: Thu, 29 Dec 2011 09:27:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <4EFC826C.80708@riw.us> To: Russ White X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Thu, 29 Dec 2011 09:29:16 -0800 Cc: dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 17:27:59 -0000 Greetings Russ et.al., On 29Dec2011, at 07.08, Russ White wrote: >=20 >> Actually, 100K host routes in leaf nodes may well be a Big Deal. It >> depends on what type of devices need to understand host routes. >=20 > So let me try to abstract the problem a little... There are two things > that cost money in building a network: >=20 > 1. State --the more you carry, the more hardware is going to cost. > 2. Bandwidth --the less optimal your bandwidth utilization, the more > you're spending on something that's not used. >=20 > The first rule of all network design is that the more state you put in = a > network, the more optimal your bandwidth usage. To reduce the cost of > bandwidth, you have to spend money on state. To reduce the cost of > state, you must increase your spending on bandwidth. Agreed, mostly. The question is where the state resides, control plane = or data plane (do you differentiate between possible state and active = state). Control plane "possible state" should be cheaper (by orders of = magnitude) than data plane "active state" - however, transitioning = between the two is a complex problem (that has gotten somewhat easier as = we have gotten smarter about distributed systems over time) >=20 > The second of network design is the balance point where the network is > cheapest is different in every network. agreed >=20 > So, IMHO, the point of protocol design should be to allow the design = the > maximum amount of flexibility and granularity in when and where to = hide > information, to make the right tradeoff for any particular network. >=20 agreed > Now, to return to the discussion at hand: If you don't want to pay for > devices that will handle 100 million routes, but you have 100 million > devices, then you're going to have some degree of suboptimal bandwidth > utilization. There's simply no way around this reality. agreed >=20 > IMHO, however we resolve this problem, we need to resolve it in a way > that allows an operator to support 100 million routes in every node, = if > they choose to optimize for bandwidth at the cost of hardware. Or to > support 1 route in every node using really cheap hardware, if they = want > to optimize for state. Or for any point in the sliding scale in = between > (within reason). agreed >=20 > So this control plane needs to: >=20 > 1. Be able to support 100 million destinations at the host level (that > doesn't mean 100 million paths, but only 100 million destinations = --two > different problems). yes >=20 > 2. Be able to aggregate to hide information at anyplace that's logical > within the network. yes >=20 > BTW, some folks would like to solve this problem by making the control > plane react to the data plane --but this carries it's own baggage in > complexity and in operational capabilities. Reactive control planes > always converge more slowly, and waste bandwidth at a rate that's > arguably higher than simple aggregation. So there's no "silver bullet" > waiting in the wings in the form of caching at the control plane = level. however, I believe that aggregation time may be coming down, especially = in a more homogenous environment (like a DC) vs a heterogeneous = environment (like the DFZ). >=20 >>> 2. Why does this mobility need to be at layer 2 specifically? Are we >>> assuming DDNS and other sorts of solutions in this space will simply >>> never be fast enough/scale far enough/etc? >>=20 >> Like it or not, the key requirement for VM mobility is that the VM's >> IP address does not change. That means the VM can't really move from >> one IP subnet to another. That means either moving to bigger and >> bigger L2s (all under one IP subnet) as the DC expands or the need to >> inject /32 host routes. >=20 > Again, the same tradeoff as above --moving to a bigger l2 domain also > means losing the ability to optimally direct traffic through the = network > (unless you put another control plane on top of the l2 and l3 control > planes already in existence --which just adds the complexity you're > trying to get away from in the host routes back into the network = state!). Or replacing one or two of those L2/L3 control planes with a control = plane with a global view, which is easier to do in a constrained network = like a traffic engineering core or a data center. It's is a bounded = problem. As you stated, however, convergence MAY be slower, but I would = argue that converging a network of Nx10K switching/routing nodes takes a = non-trivial amount of time as well :) >=20 >> Neither of those approaches seems particularly scalable/desirable if >> you look 10 years down the road and think of 1M+ physical machines in >> a DC. >=20 > There is no "particularly desirable" solution, in reality, because > building a network with no control plane state anyplace that uses > bandwidth in a perfectly optimal way is simply impossible no matter = how > you slice it (unless you're going to go into quantum routing!). >=20 > :-) >=20 > Russ > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf From rbonica@juniper.net Thu Dec 29 09:45:13 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC1421F8B2B for ; Thu, 29 Dec 2011 09:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAdUgjl-w73X for ; Thu, 29 Dec 2011 09:45:13 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 58A7621F8AF3 for ; Thu, 29 Dec 2011 09:45:08 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTvynI8jYozNiww3uN2z1lkAto1B5iH+s@postini.com; Thu, 29 Dec 2011 09:45:12 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Dec 2011 09:41:06 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 29 Dec 2011 12:41:05 -0500 From: Ronald Bonica To: Warren Kumari , Jari Arkko Date: Thu, 29 Dec 2011 12:41:04 -0500 Thread-Topic: [dc] interim dates decided? Thread-Index: AczF2IRBC3iKCteDTWyptTIjq3JFyQAdwCHg Message-ID: <13205C286662DE4387D9AF3AC30EF456D74EB56784@EMBX01-WF.jnpr.net> References: <4EF98391.6010500@piuha.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dc@ietf.org" Subject: Re: [dc] interim dates decided? X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 17:45:13 -0000 Folks, The Doodle Poll indicates that February 22-23 is the most popular date, fol= lowed by February 20-21. We are currently evaluating an offer to host the meeting in suburban Boston= on February 21-22. If you indicated that you would be available on Februar= y 20-21 or February 22-23, but cannot be available on February 21-22, pleas= e send me unicast email. Please *do not make your travel reservations yet*. We are still evaluating = whether the proposed venue will work for us. If it doesn't work, we may mee= t somewhere else. Ron > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Warren Kumari > Sent: Wednesday, December 28, 2011 10:18 PM > To: Jari Arkko > Cc: dc@ietf.org > Subject: Re: [dc] interim dates decided? >=20 >=20 > On Dec 27, 2011, at 3:36 AM, Jari Arkko wrote: >=20 > > Has the date for the Interim meeting been firmed up? I assume Feb 22- > 23th based on the doodle, but it would be good to get a confirmation... > and what about a location? >=20 > AFAIK, no, it hasn't been fully decided yet... >=20 > Still digging out from under mail avalanche, maybe I'll find something > useful... >=20 > W >=20 > > > > Jari > > > > _______________________________________________ > > dc mailing list > > dc@ietf.org > > https://www.ietf.org/mailman/listinfo/dc > > >=20 >=20 > --- > Don't be impressed with unintelligible stuff said condescendingly . > -- Radia Perlman. >=20 > Warren Kumari > warren@kumari.net >=20 >=20 >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From cdl@asgaard.org Thu Dec 29 10:11:53 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A0921F8B18 for ; Thu, 29 Dec 2011 10:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0Ne1FkqvMtl for ; Thu, 29 Dec 2011 10:11:52 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id ADAE121F8AF9 for ; Thu, 29 Dec 2011 10:11:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 9F87CA40537 for ; Thu, 29 Dec 2011 18:11:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3njRZjjS9cZm for ; Thu, 29 Dec 2011 18:11:50 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id A0F8EA4052C for ; Thu, 29 Dec 2011 18:11:50 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: <4EFC826C.80708@riw.us> Resent-From: Christopher LILJENSTOLPE Date: Thu, 29 Dec 2011 09:27:55 -0800 Content-Transfer-Encoding: quoted-printable Resent-Date: Thu, 29 Dec 2011 10:11:50 -0800 Resent-To: dc@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <4EFC826C.80708@riw.us> Message-Id: <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> To: Russ White X-Mailer: Apple Mail (2.1251.1) Resent-Message-Id: <20111229181150.A0F8EA4052C@asgaard.org> Cc: dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 18:11:53 -0000 Greetings Russ et.al., On 29Dec2011, at 07.08, Russ White wrote: >=20 >> Actually, 100K host routes in leaf nodes may well be a Big Deal. It >> depends on what type of devices need to understand host routes. >=20 > So let me try to abstract the problem a little... There are two things > that cost money in building a network: >=20 > 1. State --the more you carry, the more hardware is going to cost. > 2. Bandwidth --the less optimal your bandwidth utilization, the more > you're spending on something that's not used. >=20 > The first rule of all network design is that the more state you put in = a > network, the more optimal your bandwidth usage. To reduce the cost of > bandwidth, you have to spend money on state. To reduce the cost of > state, you must increase your spending on bandwidth. Agreed, mostly. The question is where the state resides, control plane = or data plane (do you differentiate between possible state and active = state). Control plane "possible state" should be cheaper (by orders of = magnitude) than data plane "active state" - however, transitioning = between the two is a complex problem (that has gotten somewhat easier as = we have gotten smarter about distributed systems over time) >=20 > The second of network design is the balance point where the network is > cheapest is different in every network. agreed >=20 > So, IMHO, the point of protocol design should be to allow the design = the > maximum amount of flexibility and granularity in when and where to = hide > information, to make the right tradeoff for any particular network. >=20 agreed > Now, to return to the discussion at hand: If you don't want to pay for > devices that will handle 100 million routes, but you have 100 million > devices, then you're going to have some degree of suboptimal bandwidth > utilization. There's simply no way around this reality. agreed >=20 > IMHO, however we resolve this problem, we need to resolve it in a way > that allows an operator to support 100 million routes in every node, = if > they choose to optimize for bandwidth at the cost of hardware. Or to > support 1 route in every node using really cheap hardware, if they = want > to optimize for state. Or for any point in the sliding scale in = between > (within reason). agreed >=20 > So this control plane needs to: >=20 > 1. Be able to support 100 million destinations at the host level (that > doesn't mean 100 million paths, but only 100 million destinations = --two > different problems). yes >=20 > 2. Be able to aggregate to hide information at anyplace that's logical > within the network. yes >=20 > BTW, some folks would like to solve this problem by making the control > plane react to the data plane --but this carries it's own baggage in > complexity and in operational capabilities. Reactive control planes > always converge more slowly, and waste bandwidth at a rate that's > arguably higher than simple aggregation. So there's no "silver bullet" > waiting in the wings in the form of caching at the control plane = level. however, I believe that aggregation time may be coming down, especially = in a more homogenous environment (like a DC) vs a heterogeneous = environment (like the DFZ). >=20 >>> 2. Why does this mobility need to be at layer 2 specifically? Are we >>> assuming DDNS and other sorts of solutions in this space will simply >>> never be fast enough/scale far enough/etc? >>=20 >> Like it or not, the key requirement for VM mobility is that the VM's >> IP address does not change. That means the VM can't really move from >> one IP subnet to another. That means either moving to bigger and >> bigger L2s (all under one IP subnet) as the DC expands or the need to >> inject /32 host routes. >=20 > Again, the same tradeoff as above --moving to a bigger l2 domain also > means losing the ability to optimally direct traffic through the = network > (unless you put another control plane on top of the l2 and l3 control > planes already in existence --which just adds the complexity you're > trying to get away from in the host routes back into the network = state!). Or replacing one or two of those L2/L3 control planes with a control = plane with a global view, which is easier to do in a constrained network = like a traffic engineering core or a data center. It's is a bounded = problem. As you stated, however, convergence MAY be slower, but I would = argue that converging a network of Nx10K switching/routing nodes takes a = non-trivial amount of time as well :) >=20 >> Neither of those approaches seems particularly scalable/desirable if >> you look 10 years down the road and think of 1M+ physical machines in >> a DC. >=20 > There is no "particularly desirable" solution, in reality, because > building a network with no control plane state anyplace that uses > bandwidth in a perfectly optimal way is simply impossible no matter = how > you slice it (unless you're going to go into quantum routing!). >=20 > :-) >=20 > Russ > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From cdl@asgaard.org Thu Dec 29 10:12:05 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D7F21F8A70 for ; Thu, 29 Dec 2011 10:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1gp1SAn4VES for ; Thu, 29 Dec 2011 10:12:05 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 224E821F85A7 for ; Thu, 29 Dec 2011 10:12:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 18497A40544 for ; Thu, 29 Dec 2011 18:12:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lISORknBsyfu for ; Thu, 29 Dec 2011 18:12:04 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id D5173A40541 for ; Thu, 29 Dec 2011 18:12:04 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: <4EFC826C.80708@riw.us> Resent-From: Christopher LILJENSTOLPE Date: Thu, 29 Dec 2011 09:27:55 -0800 Content-Transfer-Encoding: quoted-printable Resent-Date: Thu, 29 Dec 2011 10:12:04 -0800 Resent-To: dc@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <4EFC826C.80708@riw.us> Message-Id: <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> To: Russ White X-Mailer: Apple Mail (2.1251.1) Resent-Message-Id: <20111229181204.D5173A40541@asgaard.org> Cc: dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 18:12:05 -0000 Greetings Russ et.al., On 29Dec2011, at 07.08, Russ White wrote: >=20 >> Actually, 100K host routes in leaf nodes may well be a Big Deal. It >> depends on what type of devices need to understand host routes. >=20 > So let me try to abstract the problem a little... There are two things > that cost money in building a network: >=20 > 1. State --the more you carry, the more hardware is going to cost. > 2. Bandwidth --the less optimal your bandwidth utilization, the more > you're spending on something that's not used. >=20 > The first rule of all network design is that the more state you put in = a > network, the more optimal your bandwidth usage. To reduce the cost of > bandwidth, you have to spend money on state. To reduce the cost of > state, you must increase your spending on bandwidth. Agreed, mostly. The question is where the state resides, control plane = or data plane (do you differentiate between possible state and active = state). Control plane "possible state" should be cheaper (by orders of = magnitude) than data plane "active state" - however, transitioning = between the two is a complex problem (that has gotten somewhat easier as = we have gotten smarter about distributed systems over time) >=20 > The second of network design is the balance point where the network is > cheapest is different in every network. agreed >=20 > So, IMHO, the point of protocol design should be to allow the design = the > maximum amount of flexibility and granularity in when and where to = hide > information, to make the right tradeoff for any particular network. >=20 agreed > Now, to return to the discussion at hand: If you don't want to pay for > devices that will handle 100 million routes, but you have 100 million > devices, then you're going to have some degree of suboptimal bandwidth > utilization. There's simply no way around this reality. agreed >=20 > IMHO, however we resolve this problem, we need to resolve it in a way > that allows an operator to support 100 million routes in every node, = if > they choose to optimize for bandwidth at the cost of hardware. Or to > support 1 route in every node using really cheap hardware, if they = want > to optimize for state. Or for any point in the sliding scale in = between > (within reason). agreed >=20 > So this control plane needs to: >=20 > 1. Be able to support 100 million destinations at the host level (that > doesn't mean 100 million paths, but only 100 million destinations = --two > different problems). yes >=20 > 2. Be able to aggregate to hide information at anyplace that's logical > within the network. yes >=20 > BTW, some folks would like to solve this problem by making the control > plane react to the data plane --but this carries it's own baggage in > complexity and in operational capabilities. Reactive control planes > always converge more slowly, and waste bandwidth at a rate that's > arguably higher than simple aggregation. So there's no "silver bullet" > waiting in the wings in the form of caching at the control plane = level. however, I believe that aggregation time may be coming down, especially = in a more homogenous environment (like a DC) vs a heterogeneous = environment (like the DFZ). >=20 >>> 2. Why does this mobility need to be at layer 2 specifically? Are we >>> assuming DDNS and other sorts of solutions in this space will simply >>> never be fast enough/scale far enough/etc? >>=20 >> Like it or not, the key requirement for VM mobility is that the VM's >> IP address does not change. That means the VM can't really move from >> one IP subnet to another. That means either moving to bigger and >> bigger L2s (all under one IP subnet) as the DC expands or the need to >> inject /32 host routes. >=20 > Again, the same tradeoff as above --moving to a bigger l2 domain also > means losing the ability to optimally direct traffic through the = network > (unless you put another control plane on top of the l2 and l3 control > planes already in existence --which just adds the complexity you're > trying to get away from in the host routes back into the network = state!). Or replacing one or two of those L2/L3 control planes with a control = plane with a global view, which is easier to do in a constrained network = like a traffic engineering core or a data center. It's is a bounded = problem. As you stated, however, convergence MAY be slower, but I would = argue that converging a network of Nx10K switching/routing nodes takes a = non-trivial amount of time as well :) >=20 >> Neither of those approaches seems particularly scalable/desirable if >> you look 10 years down the road and think of 1M+ physical machines in >> a DC. >=20 > There is no "particularly desirable" solution, in reality, because > building a network with no control plane state anyplace that uses > bandwidth in a perfectly optimal way is simply impossible no matter = how > you slice it (unless you're going to go into quantum routing!). >=20 > :-) >=20 > Russ > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc From aldrin.isaac@gmail.com Thu Dec 29 13:22:02 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECB621F8B98 for ; Thu, 29 Dec 2011 13:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9rcUvcJahd3 for ; Thu, 29 Dec 2011 13:22:02 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id CE7A421F8B8D for ; Thu, 29 Dec 2011 13:22:01 -0800 (PST) Received: by qadz3 with SMTP id z3so8853321qad.10 for ; Thu, 29 Dec 2011 13:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=OeOGlVJ8vvrW8tnkK4kUJA36MhJ1UctOI7feVlSo4Fk=; b=NTHugnSbvvKc1dVg84FgPC2yOSJ7TlcgEWJEa/PUWHfdWadE//LrHxzZ47LkuhFaDP yuUPRO/4wrHDGwpbXFi939+sRBlG6ArhjnohONLxseVYuubzJNVxplrsU0l95uZIMNx+ +osJJlZZ+bHEZ3QxU+HLOr6aUJ1xZpLRAU2Q8= Received: by 10.224.116.211 with SMTP id n19mr3559787qaq.67.1325193720183; Thu, 29 Dec 2011 13:22:00 -0800 (PST) Received: from mymac.home (ool-44c1c730.dyn.optonline.net. [68.193.199.48]) by mx.google.com with ESMTPS id gw5sm40009699qab.11.2011.12.29.13.21.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Dec 2011 13:21:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_C91A3185-3DFA-4CA7-B0E9-3A87DD6C7AD3" From: Aldrin Isaac In-Reply-To: <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> Date: Thu, 29 Dec 2011 16:21:57 -0500 Message-Id: <5223116C-2E89-4835-BBA3-1D8B2241FD43@gmail.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <4EFC826C.80708@riw.us> <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> To: Christopher LILJENSTOLPE X-Mailer: Apple Mail (2.1251.1) Cc: Russ White , dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 21:22:02 -0000 --Apple-Mail=_C91A3185-3DFA-4CA7-B0E9-3A87DD6C7AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Christopher, >>=20 >> BTW, some folks would like to solve this problem by making the = control >> plane react to the data plane --but this carries it's own baggage in >> complexity and in operational capabilities. Reactive control planes >> always converge more slowly, and waste bandwidth at a rate that's >> arguably higher than simple aggregation. So there's no "silver = bullet" >> waiting in the wings in the form of caching at the control plane = level. >=20 > however, I believe that aggregation time may be coming down, = especially in a more homogenous environment (like a DC) vs a = heterogeneous environment (like the DFZ). >=20 >>=20 >>>> 2. Why does this mobility need to be at layer 2 specifically? Are = we >>>> assuming DDNS and other sorts of solutions in this space will = simply >>>> never be fast enough/scale far enough/etc? >>>=20 >>> Like it or not, the key requirement for VM mobility is that the VM's >>> IP address does not change. That means the VM can't really move from >>> one IP subnet to another. That means either moving to bigger and >>> bigger L2s (all under one IP subnet) as the DC expands or the need = to >>> inject /32 host routes. >>=20 >> Again, the same tradeoff as above --moving to a bigger l2 domain also >> means losing the ability to optimally direct traffic through the = network >> (unless you put another control plane on top of the l2 and l3 control >> planes already in existence --which just adds the complexity you're >> trying to get away from in the host routes back into the network = state!). >=20 > Or replacing one or two of those L2/L3 control planes with a control = plane with a global view, which is easier to do in a constrained network = like a traffic engineering core or a data center. It's is a bounded = problem. As you stated, however, convergence MAY be slower, but I would = argue that converging a network of Nx10K switching/routing nodes takes a = non-trivial amount of time as well :) >=20 Wrt your responses above, are you speaking specifically regarding data = centers where end stations are 100% VM? Could you lend your thoughts on = how non-aggregating DCs ought to interwork with an aggregating global = WAN/Internet?=20 Thanks -- aldrin --Apple-Mail=_C91A3185-3DFA-4CA7-B0E9-3A87DD6C7AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Christopher,


BTW, some folks = would like to solve this problem by making the = control
plane react to the = data plane --but this carries it's own baggage = in
complexity and in = operational capabilities. Reactive control = planes
always converge more = slowly, and waste bandwidth at a rate that's
arguably higher than simple aggregation. So there's no = "silver bullet"
waiting in the = wings in the form of caching at the control plane = level.

however, I believe that aggregation time may = be coming down, especially in a more homogenous environment (like a DC) = vs a heterogeneous environment (like the DFZ).


2. Why does this mobility need = to be at layer 2 specifically? Are = we
assuming= DDNS and other sorts of solutions in this space will = simply
never = be fast enough/scale far = enough/etc?

Like it or not, the key = requirement for VM mobility is that the = VM's
IP address does not change. That means the VM can't really = move from
one IP subnet to another. That = means either moving to bigger = and
bigger L2s (all under one IP subnet) as the DC expands or = the need to
inject /32 host = routes.

Again, the same = tradeoff as above --moving to a bigger l2 domain = also
means losing the ability = to optimally direct traffic through the = network
(unless you put = another control plane on top of the l2 and l3 = control
planes already in = existence --which just adds the complexity = you're
trying to get away from = in the host routes back into the network state!).

Or = replacing one or two of those L2/L3 control planes with a control plane = with a global view, which is easier to do in a constrained network like = a traffic engineering core or a data center.  It's is a bounded = problem.  As you stated, however, convergence MAY be slower, but I = would argue that converging a network of Nx10K switching/routing nodes = takes a non-trivial amount of time as well :)


Wrt = your responses above, are you speaking specifically regarding data = centers where end stations are 100% VM?  Could you lend your = thoughts on how non-aggregating DCs ought to interwork with an = aggregating global WAN/Internet? 

Thanks = -- aldrin

= --Apple-Mail=_C91A3185-3DFA-4CA7-B0E9-3A87DD6C7AD3-- From cdl@asgaard.org Thu Dec 29 13:27:09 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDB721F8A70 for ; Thu, 29 Dec 2011 13:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQVw6ot+K9zf for ; Thu, 29 Dec 2011 13:27:08 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5A04C21F86A5 for ; Thu, 29 Dec 2011 13:27:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id A7A56A41B8E; Thu, 29 Dec 2011 21:27:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE1ObziCpGGZ; Thu, 29 Dec 2011 21:27:06 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id EF10BA41B83; Thu, 29 Dec 2011 21:27:05 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: <5223116C-2E89-4835-BBA3-1D8B2241FD43@gmail.com> Date: Thu, 29 Dec 2011 13:27:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <13FED1F2-74A2-41F7-AB5D-489EAAD958F8@asgaard.org> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <4EFC826C.80708@riw.us> <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> <5223116C-2E89-4835-BBA3-1D8B2241FD43@gmail.com> To: Aldrin Isaac X-Mailer: Apple Mail (2.1251.1) Cc: Russ White , dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 21:27:09 -0000 Greetings Aldrin, On 29Dec2011, at 13.21, Aldrin Isaac wrote: > Hi Christopher, >=20 >>>=20 >>> BTW, some folks would like to solve this problem by making the = control >>> plane react to the data plane --but this carries it's own baggage in >>> complexity and in operational capabilities. Reactive control planes >>> always converge more slowly, and waste bandwidth at a rate that's >>> arguably higher than simple aggregation. So there's no "silver = bullet" >>> waiting in the wings in the form of caching at the control plane = level. >>=20 >> however, I believe that aggregation time may be coming down, = especially in a more homogenous environment (like a DC) vs a = heterogeneous environment (like the DFZ). >>=20 >>>=20 >>>>> 2. Why does this mobility need to be at layer 2 specifically? Are = we >>>>> assuming DDNS and other sorts of solutions in this space will = simply >>>>> never be fast enough/scale far enough/etc? >>>>=20 >>>> Like it or not, the key requirement for VM mobility is that the = VM's >>>> IP address does not change. That means the VM can't really move = from >>>> one IP subnet to another. That means either moving to bigger and >>>> bigger L2s (all under one IP subnet) as the DC expands or the need = to >>>> inject /32 host routes. >>>=20 >>> Again, the same tradeoff as above --moving to a bigger l2 domain = also >>> means losing the ability to optimally direct traffic through the = network >>> (unless you put another control plane on top of the l2 and l3 = control >>> planes already in existence --which just adds the complexity you're >>> trying to get away from in the host routes back into the network = state!). >>=20 >> Or replacing one or two of those L2/L3 control planes with a control = plane with a global view, which is easier to do in a constrained network = like a traffic engineering core or a data center. It's is a bounded = problem. As you stated, however, convergence MAY be slower, but I would = argue that converging a network of Nx10K switching/routing nodes takes a = non-trivial amount of time as well :) >>=20 >=20 > Wrt your responses above, are you speaking specifically regarding data = centers where end stations are 100% VM? Could you lend your thoughts on = how non-aggregating DCs ought to interwork with an aggregating global = WAN/Internet?=20 No, I was not assuming a 100% VM datacenter (which I think is unlikely = in the near-to-mid term - there will be appliances, storage, etc for = sometime that is not behind a HV). However, I'm uncertain by what you = mean a "non-aggregating" data center. Any data center will, by nature = aggregate, the question is where, and how many layers of aggregation? = Leaf (hypervisor and/or ToR for non HV elements), ToR, spine, core = router? I seriously doubt that any DC will expose it's enitire fleet of = /32 (/128) hosts to the Internet (or a global WAN). Some level of = aggregation will be necessary. As to how a DC would interact with = another DC or a WAN backbone in a controller-based network, one could = envision each DC as a network element that aggregates into the WAN with, = potentially, cooperating controllers, or a controller hierarchy. Other = topologies are likely to exist, as well. Chris >=20 > Thanks -- aldrin >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf From cdl@asgaard.org Thu Dec 29 13:30:40 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590C821F8BA6 for ; Thu, 29 Dec 2011 13:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouWtLfjpBKHo for ; Thu, 29 Dec 2011 13:30:39 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7383721F8B79 for ; Thu, 29 Dec 2011 13:30:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 5590AA41BF1; Thu, 29 Dec 2011 21:30:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amXSSu7hJR91; Thu, 29 Dec 2011 21:30:36 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id 6CCCDA41BE6; Thu, 29 Dec 2011 21:30:36 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: <5223116C-2E89-4835-BBA3-1D8B2241FD43@gmail.com> Date: Thu, 29 Dec 2011 13:30:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <07ADF0F2-9A9B-4F5E-B19A-C211BBC3E4EE@asgaard.org> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <4EFC826C.80708@riw.us> <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> <5223116C-2E89-4835-BBA3-1D8B2241FD43@gmail.com> To: Aldrin Isaac X-Mailer: Apple Mail (2.1251.1) Cc: Russ White , dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 21:30:40 -0000 Another clarification... On 29Dec2011, at 13.21, Aldrin Isaac wrote: > Hi Christopher, >=20 >>>=20 >>> BTW, some folks would like to solve this problem by making the = control >>> plane react to the data plane --but this carries it's own baggage in >>> complexity and in operational capabilities. Reactive control planes >>> always converge more slowly, and waste bandwidth at a rate that's >>> arguably higher than simple aggregation. So there's no "silver = bullet" >>> waiting in the wings in the form of caching at the control plane = level. >>=20 >> however, I believe that aggregation time may be coming down, = especially in a more homogenous environment (like a DC) vs a = heterogeneous environment (like the DFZ). >>=20 >>>=20 >>>>> 2. Why does this mobility need to be at layer 2 specifically? Are = we >>>>> assuming DDNS and other sorts of solutions in this space will = simply >>>>> never be fast enough/scale far enough/etc? >>>>=20 >>>> Like it or not, the key requirement for VM mobility is that the = VM's >>>> IP address does not change. That means the VM can't really move = from >>>> one IP subnet to another. That means either moving to bigger and >>>> bigger L2s (all under one IP subnet) as the DC expands or the need = to >>>> inject /32 host routes. >>>=20 >>> Again, the same tradeoff as above --moving to a bigger l2 domain = also >>> means losing the ability to optimally direct traffic through the = network >>> (unless you put another control plane on top of the l2 and l3 = control >>> planes already in existence --which just adds the complexity you're >>> trying to get away from in the host routes back into the network = state!). >>=20 >> Or replacing one or two of those L2/L3 control planes with a control = plane with a global view, which is easier to do in a constrained network = like a traffic engineering core or a data center. It's is a bounded = problem. As you stated, however, convergence MAY be slower, but I would = argue that converging a network of Nx10K switching/routing nodes takes a = non-trivial amount of time as well :) >>=20 >=20 > Wrt your responses above, are you speaking specifically regarding data = centers where end stations are 100% VM? Could you lend your thoughts on = how non-aggregating DCs ought to interwork with an aggregating global = WAN/Internet?=20 Actually, I was making the case that, at large scale, convergence takes = time, if it is distributed as it is today (STP, IGPs) or in a = controller-based environment. The convergence time question becomes = more interesting, as it's a large computation problem, no mater if it is = distributed or centralized. Centralized may be faster, but there is = latency between forwarding plane and control plane. Less latency in the = distributed model, but more computation elements that must converge. =20 Chris >=20 > Thanks -- aldrin >=20 > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf From xuxiaohu@huawei.com Thu Dec 29 20:02:09 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E37721F845B for ; Thu, 29 Dec 2011 20:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[AWL=2.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4SOr5lzLOwX for ; Thu, 29 Dec 2011 20:02:08 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 26A2E21F8457 for ; Thu, 29 Dec 2011 20:02:08 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LX0006UM0JEM5@szxga04-in.huawei.com> for dc@ietf.org; Fri, 30 Dec 2011 12:02:02 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LX000CY80JEAN@szxga04-in.huawei.com> for dc@ietf.org; Fri, 30 Dec 2011 12:02:02 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGA26793; Fri, 30 Dec 2011 12:02:01 +0800 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Dec 2011 12:01:53 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 30 Dec 2011 12:01:51 +0800 Date: Fri, 30 Dec 2011 04:01:51 +0000 From: Xuxiaohu In-reply-to: <229A8E99-6EB2-49E5-B530-BA0F6C7C40AC@asgaard.org> X-Originating-IP: [10.108.4.80] To: Christopher LILJENSTOLPE Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7639B3@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dc] Elevator Pitch Thread-index: AQHMw1wuBgE5G7BjGEyEvGVWBnVRbZXw96YAgAF/L4CAABiKgIABPS+Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE76387F@szxeml525-mbs.china.huawei.com> <229A8E99-6EB2-49E5-B530-BA0F6C7C40AC@asgaard.org> Cc: Thomas Narten , Russ White , "dc@ietf.org" Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 04:02:09 -0000 DQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBDaHJpc3RvcGhlciBMSUxK RU5TVE9MUEUgW21haWx0bzpjZGxAYXNnYWFyZC5vcmddDQo+IOWPkemAgeaXtumXtDogMjAxMeW5 tDEy5pyIMzDml6UgMToyMA0KPiDmlLbku7bkuro6IFh1eGlhb2h1DQo+IOaKhOmAgTogVGhvbWFz IE5hcnRlbjsgUnVzcyBXaGl0ZTsgZGNAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW2RjXSBFbGV2 YXRvciBQaXRjaA0KPiANCj4gR3JlZXRpbmdzIFh1eGlhb2h1LA0KPiANCj4gT24gMjlEZWMyMDEx LCBhdCAwMC41NSwgWHV4aWFvaHUgd3JvdGU6DQo+IA0KPiA+IEhpIFRob21hcywNCj4gPg0KPiA+ PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+IOWPkeS7tuS6ujogZGMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmRjLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBUaG9tYXMNCj4gPj4gTmFy dGVuDQo+ID4+IOWPkemAgeaXtumXtDogMjAxMeW5tDEy5pyIMjnml6UgMTowMQ0KPiA+PiDmlLbk u7bkuro6IFJ1c3MgV2hpdGUNCj4gPj4g5oqE6YCBOiBkY0BpZXRmLm9yZw0KPiA+PiDkuLvpopg6 IFJlOiBbZGNdIEVsZXZhdG9yIFBpdGNoDQo+ID4+DQo+ID4+PiAxLiBIb3cgbWFueSBob3N0IHJv dXRlcyBkbyB3ZSByZWFjaCBiZWZvcmUgd2Ugc2F5IGl0ICJ3b24ndCBzY2FsZT8iIElmDQo+ID4+ PiB5b3UncmUgdGFsa2luZyBhYm91dCBsZWFmIG5vZGVzIGluIGEgcm91dGluZyBwcm90b2NvbCwg MTAwayBpc24ndCByZWFsbHkNCj4gPj4+IHRoYXQgYmlnIG9mIGEgZGVhbC4gV2hlcmUgeW91IGRv IHJ1biBpbnRvIHByb2JsZW1zIGlzIGJldHdlZW4gdGhlDQo+ID4+PiByb3V0aW5nIGFuZCBmb3J3 YXJkaW5nIHRhYmxlcyAtLWJ1dCB0aGF0J3MgYW4gYXJlYSBmb3IgdGhvdWdodC4NCj4gPj4NCj4g Pj4gQWN0dWFsbHksIDEwMEsgaG9zdCByb3V0ZXMgaW4gbGVhZiBub2RlcyBtYXkgd2VsbCBiZSBh IEJpZyBEZWFsLiBJdA0KPiA+PiBkZXBlbmRzIG9uIHdoYXQgdHlwZSBvZiBkZXZpY2VzIG5lZWQg dG8gdW5kZXJzdGFuZCBob3N0IHJvdXRlcy4NCj4gPj4NCj4gPj4gRm9yIHRoZSBzY2VuYXJpb3Mg TlZPMyBpcyBsb29raW5nIGF0LCB0aGUgZWRnZSBkZXZpY2UgaW5jbHVkZXMgZWRnZQ0KPiA+PiBz d2l0Y2hlcyBhbmQgaHlwZXJ2aXNvcnMuIFllcywgc3VjaCBkZXZpY2VzIGNhbiBpbiB0aGVvcnkg c3VwcG9ydCAxMDBLDQo+ID4+IGhvc3Qgcm91dGVzIChhbmQgdGhlIHJvdXRpbmcgcHJvdG9jb2wg bmVlZGVkIHRvIG1ha2UgdGhhdCBjb252ZXJnZSkuDQo+ID4+DQo+ID4+IEJ1dCBhdCBhIGNvc3Qu DQo+ID4+DQo+ID4+IEFuZCBJIHN1c3BlY3QgdGhlIGNvc3QgaXMgdG9vIGhpZ2guDQo+ID4+DQo+ ID4+IERvIHlvdSB0aGluayBkYXRhIGNlbnRlciBvcGVyYXRvcnMgd2lsbCB3YW50IHRvIHJ1biBy b3V0aW5nIHByb3RvY29scw0KPiA+PiBpbiBoeXBlcnZpc29ycyB0aGF0IGhhdmUgdG8gaGFuZGxl IDEwMEsgaG9zdCByb3V0ZXM/IEVzcGVjaWFsbHkgaWYNCj4gPj4gc3VjaCBkZXZpY2VzIHdpbGwg bmVlZCB0byBiZSB1cGdyYWRlZCB3aXRoIGJldHRlciBoYXJkd2FyZSB0byBzdXBwb3J0DQo+ID4+ IHN1Y2ggYSBsb2FkPw0KPiA+DQo+ID4gSWYgdGhleSBuZWVkIHRvIGJlIHVwZ3JhZGVkIHdpdGgg YmV0dGVyIGhhcmR3YXJlLCB3aHkgbm90IGRpcmVjdGx5IGNvbnNpZGVyDQo+IHRoZSBwaHlzaWNh bCBlZGdlIHN3aXRjaGVzIChlLmcuLCBUb1Igc3dpdGNoZXMpIGFzIGxlYWYgbm9kZXM/DQo+ID4N Cj4gPiBCVFcsIGluIHRoZSB0eXBpY2FsIG11bHRpLXRlbmFudCBjbG91ZCBkYXRhIGNlbnRlciBl bnZpcm9ubWVudCB3aGVyZSBtb3N0DQo+IG9mIHRoZSB0ZW5hbnRzIGFyZSBiZWxpZXZlZCB0byBi ZSBTTUJzLCB0aGUgcm91dGUgYW1vdW50IG9mIGFueSBnaXZlbiB0ZW5hbnQNCj4gZG9tYWluIHdv dWxkIG5vdCBiZSB0b28gbGFyZ2UuIEhlbmNlLCBldmVuIHRoZXJlIGFyZSBtb3JlIHRoYW4gMU0g aG9zdA0KPiByb3V0ZXMgaW4gdG90YWwsIHRoZSByb3V0ZSBhbW91bnQgb24gYW55IGxlYWYgbm9k ZSB3b3VsZCBub3QgYmUgdG9vIGxhcmdlIHNpbmNlDQo+IHRoZSB0ZW5hbnQgYW1vdW50IG9uIGFu eSBsZWFmIG5vZGUgd291bGQgbm90IGJlIHRvbyBsYXJnZS4gVGhlIG1heGltdW0NCj4gdGVuYW50 IGFtb3VudCBvbiBhbnkgbGVhZiBub2RlIGlzIGxpbWl0ZWQgYnkgYXQgbGVhc3QgdGhlIGZvbGxv d2luZyB0d28gZmFjdG9yczoNCj4gMSkgdGhlIHBvcnQgZGVuc2l0eSBvZiBsZWF2ZSBub2Rlczsg MikgdGhlIFZNIGRlbnNpdHkgb2YgcGh5c2ljYWwgc2VydmVycy4gSW4NCj4gYWRkaXRpb24sIGlu IHRoZSBjYXNlIHdoZXJlIHRoZSBub24tYmxvY2tpbmcgREMgZmFicmljIGlzIG5vdCB5ZXQgYSBy ZWFsaXR5IGR1ZSB0bw0KPiBpdHMgaGlnaCBjb3N0LCB0aGUgVk1zIG9mIGEgZ2l2ZW4gdGVuYW50 IHdvdWxkIGJlIHBsYWNlZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSwNCj4gZm9yIGV4YW1wbGUsIGJl aW5nIGF0dGFjaGVkIHRvIGEgc2luZ2xlIGxlYWYgbm9kZSBpZiBwb3NzaWJsZSwgc28gYXMgdG8g cmVkdWNlIHRoZQ0KPiBiYW5kd2lkdGggY29uc3VtcHRpb24gb24gdGhlIHVwbGlua3MuIEluIHRo aXMgd2F5LCB0aGUgYXZlcmFnZSB0ZW5hbnQgYW1vdW50DQo+IG9uIGEgZ2l2ZW4gbGVhZiBub2Rl IHdvdWxkIGJlIGV2ZW4gbGVzcy4NCj4gDQo+IFRoZXJlIGFyZSBmb2xrcyB3aG8gYXJlIGxvb2tp bmcgYXQgdGhlIFRvUiBhcyB0aGUgbGVhZiBub2RlLCBhbmQsIGluIG15IG9waW5pb24sDQo+IGFu eSBzb2x1dGlvbiB3aWxsIHByb2JhYmx5IGJlIGEgaHlicmlkIG9mIFRvUiBhbmQgaHlwZXJ2aXNv ci4gIEhvd2V2ZXIsDQo+IHJlbWVtYmVyIHRoYXQgdGhlIGh5cGVydmlzb3Igc3dpdGNoIGlzIHN0 aWxsIHRoZSBmaXJzdCBhZ2dyZWdhdGlvbiBwb2ludCwgYW5kDQo+IHRoZXJlZm9yZSwgaXMgdGhl IGxlYWYgaW4gYSBuZXR3b3JrIHRyZWUuICBTb21lIGxldmVsIG9mIHN0YXRlIGFnZ3JlZ2F0aW9u IChhbmQNCj4gYWNjb21wYW55aW5nIGxvc3MpIHdpbGwgb2NjdXIgYXQgdGhlIGh5cGVydmlzb3Ig c3dpdGNoLCBtYWtpbmcgaXQgdGhlIGxlYWYuDQo+IEFsc28sIHRoZXJlIGFyZSBzY2FsaW5nIGlz c3VlcyB3aXRoIGhhdmluZyAxMCdzIChvciAxMDAncyBpbiB0aGUgY2FzZSBvZiBzb21lDQo+IG9w ZXJhdG9ycykgdm0ncyBydW5uaW5nIG9uIGVhY2ggc2VydmVyLCBhbmQgaGF2aW5nIDIwLTQwIHNl cnZlcnMgcnVubmluZyBpbnRvDQo+IHRoZSBUb1IgLSBhbGwgb2YgYSBzdWRkZW4sIHRoZSBob3N0 LXRhYmxlIGFsb25lIG9uIHRoZSBUb1IgYmVjb21lcyBtaWxkbHkNCj4gaW50ZXJlc3RpbmcsIGV2 ZW4gd2l0aG91dCBvdGhlciAoaW50cmEtZGF0YSBjZW50ZXIpIHJvdXRlcyBvbiBsb3cgQ0FNIFRv Ug0KPiBzd2l0Y2hlcy4gIE5vdCBhbGwgc29sdXRpb25zIHdpbGwgbWFwIHRvIGFsbCAob3IgbW9z dCkgY3VzdG9tZXJzLg0KPiANCj4gQWxzbywgdGhlIGNvbW1lbnQgdG8gbGltaXQgdGhlIHJvdXRl LXRhYmVsIG9mIHRlbmFudHMgZHVlIHRvIHNtYWxsIG51bWJlcnMgb2YNCj4gaG9zdHMgbWF5IG5v dCBhbHdheXMgKG9yIHVzdWFsbHkpIG1hdGNoIHJlYWxpdHkuICBXaGF0IG9mIHRoZQ0KPiBjcm9z cy1kYXRhLWNlbnRlciB0cmFmZmljIGZvciBvdGhlciBzZXJ2aWNlcyBlaXRoZXIgcHJvdmlkZWQg YnkgdGhlIGhvc3Rlciwgb3INCj4gb3RoZXIgdGVuYW50cz8gIENvbnRpbnVpbmcgdG8gcm91dGUg QUxMIG9mIHRoYXQgdHJhZmZpYyB0aHJvdWdoDQo+IHJvdXRpbmcvc3dpdGNoaW5nIG5vZGVzIGV4 dGVybmFsIHRvIHRoZSAiZmFicmljIiB3aWxsIGxlYWQgdG8gaXQncyBvd24gc2NhbGluZw0KPiBp c3N1ZXMuICAgRG9uJ3QgYXNzdW1lIHRoYXQgdGhlIG9ubHkgcm91dGVzIHRoYXQgYW4gU01CIG5l ZWRzIGFyZSBpdCdzIG93bi4NCg0KSGkgQ2hyaXMsDQoNCldvdWxkIHlvdSBwbGVhc2UgZ2l2ZSBh IGNvbmNyZXRlIGV4YW1wbGUgd2hlcmUgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBkaWZmZXJl bnQgdGVuYW50cyBpcyB2ZXJ5IGNvbW1vbiBpbiB0aGUgbXVsdGktdGVuYW50IGNsb3VkIGRhdGEg Y2VudGVyPw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiA+DQo+ID4NCj4gPj4gT3Igd2ls bCB0aGV5IHdhbnQgYW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2g/DQo+ID4+DQo+ID4+PiAyLiBXaHkg ZG9lcyB0aGlzIG1vYmlsaXR5IG5lZWQgdG8gYmUgYXQgbGF5ZXIgMiBzcGVjaWZpY2FsbHk/IEFy ZSB3ZQ0KPiA+Pj4gYXNzdW1pbmcgREROUyBhbmQgb3RoZXIgc29ydHMgb2Ygc29sdXRpb25zIGlu IHRoaXMgc3BhY2Ugd2lsbCBzaW1wbHkNCj4gPj4+IG5ldmVyIGJlIGZhc3QgZW5vdWdoL3NjYWxl IGZhciBlbm91Z2gvZXRjPw0KPiA+Pg0KPiA+PiBMaWtlIGl0IG9yIG5vdCwgdGhlIGtleSByZXF1 aXJlbWVudCBmb3IgVk0gbW9iaWxpdHkgaXMgdGhhdCB0aGUgVk0ncw0KPiA+PiBJUCBhZGRyZXNz IGRvZXMgbm90IGNoYW5nZS4gVGhhdCBtZWFucyB0aGUgVk0gY2FuJ3QgcmVhbGx5IG1vdmUgZnJv bQ0KPiA+PiBvbmUgSVAgc3VibmV0IHRvIGFub3RoZXIuIFRoYXQgbWVhbnMgZWl0aGVyIG1vdmlu ZyB0byBiaWdnZXIgYW5kDQo+ID4+IGJpZ2dlciBMMnMgKGFsbCB1bmRlciBvbmUgSVAgc3VibmV0 KSBhcyB0aGUgREMgZXhwYW5kcyBvciB0aGUgbmVlZCB0bw0KPiA+PiBpbmplY3QgLzMyIGhvc3Qg cm91dGVzLg0KPiA+DQo+ID4gSW4gdGhlIERDSSBzY2VuYXJpbyB3aGVyZSB0aGUgUEUgcm91dGVy cyBhcmUgdXN1YWxseSBwZXJmb3JtZWQgYXQgdGhlDQo+IGFnZ3JlZ2F0aW9uIFNXcyBvciBldmVu IGNvcmUgU1dzLCB0aGUgUEUgcm91dGVycyB3b3VsZCBuZWVkIGEgbXVjaCBsYXJnZQ0KPiBmb3J3 YXJkaW5nIHRhYmxlLiBQcm92aWRlZCB0aGUgcm91dGluZyB0YWJsZSBjb250YWluaW5nIG1pbGxp b25zIG9mIGVudHJpZXMsDQo+IHdoaWNoIGlzIGF2YWlsYWJsZSBvbiBtb3N0IHRvZGF5J3MgaGln aC1lbmQgcm91dGVycywgd2FzIHN0aWxsIG5vdCBsYXJnZSBlbm91Z2gsDQo+IHRoZSBvbi1kZW1h bmQgRklCIGluc3RhbGxhdGlvbiBvciBvbi1kZW1hbmQgcm91dGUgYW5ub3VuY2VtZW50DQo+IG1l Y2hhbmlzbXMgY2FuIGJlIHVzZWQgZnVydGhlciB0byBzY2FsZSB0aGUgc29sdXRpb24uIE5vdGUg dGhhdCB0aGUgdHJpZ2dlciBmb3INCj4gdGhlIEZJQiBpbnN0YWxsYXRpb24gb3Igcm91dGUgYW5u b3VuY2VtZW50IGlzIEFSUCByZXF1ZXN0IHBhY2tldHMgcmF0aGVyIHRoYW4NCj4gZGF0YSBwYWNr ZXRzLiBIZW5jZSBpdCB3aWxsIG5vdCBjYXVzZSB0aGUgc28tY2FsbGVkIGluaXRpYWwgcGFja2V0 IGxvc3Mgb3IgbGF0ZW5jeQ0KPiBpc3N1ZS4NCj4gPg0KPiA+PiBOZWl0aGVyIG9mIHRob3NlIGFw cHJvYWNoZXMgc2VlbXMgcGFydGljdWxhcmx5IHNjYWxhYmxlL2Rlc2lyYWJsZSBpZg0KPiA+PiB5 b3UgbG9vayAxMCB5ZWFycyBkb3duIHRoZSByb2FkIGFuZCB0aGluayBvZiAxTSsgcGh5c2ljYWwg bWFjaGluZXMgaW4NCj4gPj4gYSBEQy4NCj4gPg0KPiA+IE1heWJlIHdlIHNob3VsZCBhbHNvIHRh a2UgdGhlIGRldmVsb3BtZW50IHNwZWVkIG9mIHJvdXRpbmcvc3dpdGNoaW5nIGNoaXANCj4gYW5k IENQVSB0ZWNobm9sb2dpZXMgaW50byBhY2NvdW50OikNCj4gDQo+IEl0J3MgbW9yZSBhIHF1ZXN0 aW9uIG9mIGNvc3QvcGVyZm9ybWFuY2Ugb24gb2ZmLWNoaXAgbWVtb3J5L1RDQU1zLiAgVGhhdCBp cw0KPiBhIHNsaWdodGx5IGRpZmZlcmVudCBjdXJ2ZSA6KQ0KPiANCj4gCUNocmlzDQo+IA0KPiA+ DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4+IFRob21hcw0KPiA+Pg0K PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ PiBkYyBtYWlsaW5nIGxpc3QNCj4gPj4gZGNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gZGMgbWFpbGluZyBsaXN0DQo+ID4gZGNAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RjDQo+IA0KPiAt LQ0KPiDmnY7mn6/nnb8NCj4gQ2hlY2sgbXkgUEdQIGtleSBoZXJlOiBodHRwczovL3d3dy5hc2dh YXJkLm9yZy9+Y2RsL2NkbC5hc2MNCj4gQ3VycmVudCB2Q2FyZCBoZXJlOiBodHRwczovL3d3dy5h c2dhYXJkLm9yZy9+Y2RsL2NkbC52Y2YNCg0K From aldrin.isaac@gmail.com Thu Dec 29 20:31:46 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583DC11E8093 for ; Thu, 29 Dec 2011 20:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ1TaOQJtdfx for ; Thu, 29 Dec 2011 20:31:45 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4939511E8087 for ; Thu, 29 Dec 2011 20:31:45 -0800 (PST) Received: by qcsf15 with SMTP id f15so9889601qcs.31 for ; Thu, 29 Dec 2011 20:31:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=NlQECKOn+jaeZ5C6ilGbAI+n3bRoX3QC3ifulzUy9HI=; b=dK/yjr64uawfbdVm4QxZGCdkMFdfL2FroxkSx0ZIG+o/t2uN78HfDxYrnjTy4lFtCd 7H4ZGGG5v9iCcdXMETqS9vXBQYqcItOP2xUd1rUkrhWavS7krU8UZchb2K3FJkpenNSW lXMMXIt1UJXtRZT4jbknTJqWBRT36XlgJge2w= Received: by 10.224.60.20 with SMTP id n20mr30031583qah.14.1325219504618; Thu, 29 Dec 2011 20:31:44 -0800 (PST) Received: from mymac.home (ool-44c1c730.dyn.optonline.net. [68.193.199.48]) by mx.google.com with ESMTPS id r10sm69905928qaz.7.2011.12.29.20.31.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Dec 2011 20:31:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_22AE0FBF-DE7F-49A6-A9C1-0C8D1FB06DCE" From: Aldrin Isaac In-Reply-To: <13FED1F2-74A2-41F7-AB5D-489EAAD958F8@asgaard.org> Date: Thu, 29 Dec 2011 23:31:41 -0500 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <4EFC826C.80708@riw.us> <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> <5223116C-2E89-4835-BBA3-1D8B2241FD43@gmail.com> <13FED1F2-74A2-41F7-AB5D-489EAAD958F8@asgaard.org> To: Christopher LILJENSTOLPE X-Mailer: Apple Mail (2.1251.1) Cc: Russ White , dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 04:31:46 -0000 --Apple-Mail=_22AE0FBF-DE7F-49A6-A9C1-0C8D1FB06DCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 29, 2011, at 4:27 PM, Christopher LILJENSTOLPE wrote: > Greetings Aldrin, > On 29Dec2011, at 13.21, Aldrin Isaac wrote: >=20 >> Hi Christopher, >>=20 >>>>=20 >>>> BTW, some folks would like to solve this problem by making the = control >>>> plane react to the data plane --but this carries it's own baggage = in >>>> complexity and in operational capabilities. Reactive control planes >>>> always converge more slowly, and waste bandwidth at a rate that's >>>> arguably higher than simple aggregation. So there's no "silver = bullet" >>>> waiting in the wings in the form of caching at the control plane = level. >>>=20 >>> however, I believe that aggregation time may be coming down, = especially in a more homogenous environment (like a DC) vs a = heterogeneous environment (like the DFZ). >>>=20 >> Wrt your responses above, are you speaking specifically regarding = data centers where end stations are 100% VM? Could you lend your = thoughts on how non-aggregating DCs ought to interwork with an = aggregating global WAN/Internet?=20 >=20 > No, I was not assuming a 100% VM datacenter (which I think is unlikely = in the near-to-mid term - there will be appliances, storage, etc for = sometime that is not behind a HV). However, I'm uncertain by what you = mean a "non-aggregating" data center. Any data center will, by nature = aggregate, the question is where, and how many layers of aggregation? = Leaf (hypervisor and/or ToR for non HV elements), ToR, spine, core = router? I seriously doubt that any DC will expose it's enitire fleet of = /32 (/128) hosts to the Internet (or a global WAN). Some level of = aggregation will be necessary. As to how a DC would interact with = another DC or a WAN backbone in a controller-based network, one could = envision each DC as a network element that aggregates into the WAN with, = potentially, cooperating controllers, or a controller hierarchy. Other = topologies are likely to exist, as well. > Chris Hi Chris,=20 I may have misunderstood your statement, "I believe that aggregation = time is coming down", to mean you are a proponent of dramatically = reducing or eliminating route aggregation in some way. Maybe I'm wrong, = but it seems there are at least a few folks that expect that hosts = should be independently mobile across more than one site and that a = solution should support that expectation at scale. I think we're on the same page wrt needing some levels of aggregation. = As a matter of fact, the run-of-the-mill DC network design already has = aggregation at the access gateway/router (in the form of subnet routes) = and "host routes" (mac routes) within the access LAN. You can make the = access LAN (host route domain) smaller or bigger (hopefully not relying = on STP) for varying degree of mobility. =20 Could you highlight, from your perspective, the features current = standards and design patterns cannot fundamentally support? Since we're = familiar with the limitations with STP, flooding and ARP for large LANs, = I'm interested in knowing, in technical terms, what other flaws you = believe exist and features you believe are missing. Thanks -- aldrin= --Apple-Mail=_22AE0FBF-DE7F-49A6-A9C1-0C8D1FB06DCE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Greetings Aldrin,
On 29Dec2011, at 13.21, Aldrin = Isaac wrote:

Hi = Christopher,


BTW, = some folks would like to solve this problem by making the = control
plane = react to the data plane --but this carries it's own baggage = in
complexity and in operational capabilities. Reactive = control planes
always = converge more slowly, and waste bandwidth at a rate = that's
arguably= higher than simple aggregation. So there's no "silver = bullet"
waiting = in the wings in the form of caching at the control plane = level.

however, I believe that = aggregation time may be coming down, especially in a more homogenous = environment (like a DC) vs a heterogeneous environment (like the = DFZ).

Wrt = your responses above, are you speaking specifically regarding data = centers where end stations are 100% VM?  Could you lend your = thoughts on how non-aggregating DCs ought to interwork with an = aggregating global WAN/Internet?

No, I was not = assuming a 100% VM datacenter (which I think is unlikely in the = near-to-mid term - there will be appliances, storage, etc for sometime = that is not behind a HV).  However, I'm uncertain by what you mean = a "non-aggregating" data center.  Any data center will, by nature = aggregate, the question is where, and how many layers of aggregation? =  Leaf (hypervisor and/or ToR for non HV elements), ToR, spine, core = router?  I seriously doubt that any DC will expose it's enitire = fleet of /32 (/128) hosts to the Internet (or a global WAN). =   Some level of aggregation will be necessary.  As to how = a DC would interact with another DC or a WAN backbone in a = controller-based network, one could envision each DC as a network = element that aggregates into the WAN with, potentially, cooperating = controllers, or a controller hierarchy.  Other topologies are = likely to exist, as well.
Chris

Hi = Chris, 

I may have misunderstood your = statement, "I believe that aggregation time is coming down", to mean you = are a proponent of dramatically reducing or eliminating route = aggregation in some way.  Maybe I'm wrong, but it seems there are = at least a few folks that expect that hosts should be independently = mobile across more than one site and that a solution should support that = expectation at scale.

I think we're on the same = page wrt needing some levels of aggregation.  As a matter of fact, = the run-of-the-mill DC network design already has aggregation at the = access gateway/router (in the form of subnet routes) and "host routes" = (mac routes) within the access LAN.  You can make the access LAN = (host route domain) smaller or bigger (hopefully not relying on STP) for = varying degree of mobility.  

Could you = highlight, from your perspective, the features current standards and = design patterns cannot fundamentally support?  Since we're familiar = with the limitations with STP, flooding and ARP for large LANs, I'm = interested in knowing, in technical terms, what other flaws you believe = exist and features you believe are = missing.

Thanks -- aldrin
= --Apple-Mail=_22AE0FBF-DE7F-49A6-A9C1-0C8D1FB06DCE-- From xuxiaohu@huawei.com Fri Dec 30 01:48:27 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9762521F8B73 for ; Fri, 30 Dec 2011 01:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[AWL=2.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yylE8yETknCZ for ; Fri, 30 Dec 2011 01:48:26 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBCE21F8B62 for ; Fri, 30 Dec 2011 01:48:26 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LX0005CXGGZII@szxga04-in.huawei.com> for dc@ietf.org; Fri, 30 Dec 2011 17:46:11 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LX000734GG9TZ@szxga04-in.huawei.com> for dc@ietf.org; Fri, 30 Dec 2011 17:46:11 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGC75677; Fri, 30 Dec 2011 17:46:02 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Dec 2011 17:45:53 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Fri, 30 Dec 2011 17:45:54 +0800 Date: Fri, 30 Dec 2011 09:45:53 +0000 From: Xuxiaohu X-Originating-IP: [10.108.4.80] To: Christopher LILJENSTOLPE Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7639E9@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dc] Elevator Pitch Thread-index: AQHMw1wuBgE5G7BjGEyEvGVWBnVRbZXw96YAgAF/L4CAABiKgIABPS+QgABdsOA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE76387F@szxeml525-mbs.china.huawei.com> <229A8E99-6EB2-49E5-B530-BA0F6C7C40AC@asgaard.org> Cc: Thomas Narten , Russ White , "dc@ietf.org" Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 09:48:27 -0000 PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogWHV4aWFvaHUNCj4g5Y+R6YCB 5pe26Ze0OiAyMDEx5bm0MTLmnIgzMOaXpSAxMjoxNw0KPiDmlLbku7bkuro6ICdDaHJpc3RvcGhl ciBMSUxKRU5TVE9MUEUnDQo+IOaKhOmAgTogVGhvbWFzIE5hcnRlbjsgUnVzcyBXaGl0ZTsgZGNA aWV0Zi5vcmcNCj4g5Li76aKYOiByZTogW2RjXSBFbGV2YXRvciBQaXRjaA0KPiANCj4gDQo+ID4g LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+IOWPkeS7tuS6ujogQ2hyaXN0b3BoZXIgTElMSkVO U1RPTFBFIFttYWlsdG86Y2RsQGFzZ2FhcmQub3JnXQ0KPiA+IOWPkemAgeaXtumXtDogMjAxMeW5 tDEy5pyIMzDml6UgMToyMA0KPiA+IOaUtuS7tuS6ujogWHV4aWFvaHUNCj4gPiDmioTpgIE6IFRo b21hcyBOYXJ0ZW47IFJ1c3MgV2hpdGU7IGRjQGlldGYub3JnDQo+ID4g5Li76aKYOiBSZTogW2Rj XSBFbGV2YXRvciBQaXRjaA0KPiA+DQo+ID4gR3JlZXRpbmdzIFh1eGlhb2h1LA0KPiA+DQo+ID4g T24gMjlEZWMyMDExLCBhdCAwMC41NSwgWHV4aWFvaHUgd3JvdGU6DQo+ID4NCj4gPiA+IEhpIFRo b21hcywNCj4gPiA+DQo+ID4gPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+ID4+IOWPkeS7 tuS6ujogZGMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRjLWJvdW5jZXNAaWV0Zi5vcmddIOS7 o+ihqA0KPiBUaG9tYXMNCj4gPiA+PiBOYXJ0ZW4NCj4gPiA+PiDlj5HpgIHml7bpl7Q6IDIwMTHl ubQxMuaciDI55pelIDE6MDENCj4gPiA+PiDmlLbku7bkuro6IFJ1c3MgV2hpdGUNCj4gPiA+PiDm ioTpgIE6IGRjQGlldGYub3JnDQo+ID4gPj4g5Li76aKYOiBSZTogW2RjXSBFbGV2YXRvciBQaXRj aA0KPiA+ID4+DQo+ID4gPj4+IDEuIEhvdyBtYW55IGhvc3Qgcm91dGVzIGRvIHdlIHJlYWNoIGJl Zm9yZSB3ZSBzYXkgaXQgIndvbid0IHNjYWxlPyIgSWYNCj4gPiA+Pj4geW91J3JlIHRhbGtpbmcg YWJvdXQgbGVhZiBub2RlcyBpbiBhIHJvdXRpbmcgcHJvdG9jb2wsIDEwMGsgaXNuJ3QgcmVhbGx5 DQo+ID4gPj4+IHRoYXQgYmlnIG9mIGEgZGVhbC4gV2hlcmUgeW91IGRvIHJ1biBpbnRvIHByb2Js ZW1zIGlzIGJldHdlZW4gdGhlDQo+ID4gPj4+IHJvdXRpbmcgYW5kIGZvcndhcmRpbmcgdGFibGVz IC0tYnV0IHRoYXQncyBhbiBhcmVhIGZvciB0aG91Z2h0Lg0KPiA+ID4+DQo+ID4gPj4gQWN0dWFs bHksIDEwMEsgaG9zdCByb3V0ZXMgaW4gbGVhZiBub2RlcyBtYXkgd2VsbCBiZSBhIEJpZyBEZWFs LiBJdA0KPiA+ID4+IGRlcGVuZHMgb24gd2hhdCB0eXBlIG9mIGRldmljZXMgbmVlZCB0byB1bmRl cnN0YW5kIGhvc3Qgcm91dGVzLg0KPiA+ID4+DQo+ID4gPj4gRm9yIHRoZSBzY2VuYXJpb3MgTlZP MyBpcyBsb29raW5nIGF0LCB0aGUgZWRnZSBkZXZpY2UgaW5jbHVkZXMgZWRnZQ0KPiA+ID4+IHN3 aXRjaGVzIGFuZCBoeXBlcnZpc29ycy4gWWVzLCBzdWNoIGRldmljZXMgY2FuIGluIHRoZW9yeSBz dXBwb3J0IDEwMEsNCj4gPiA+PiBob3N0IHJvdXRlcyAoYW5kIHRoZSByb3V0aW5nIHByb3RvY29s IG5lZWRlZCB0byBtYWtlIHRoYXQgY29udmVyZ2UpLg0KPiA+ID4+DQo+ID4gPj4gQnV0IGF0IGEg Y29zdC4NCj4gPiA+Pg0KPiA+ID4+IEFuZCBJIHN1c3BlY3QgdGhlIGNvc3QgaXMgdG9vIGhpZ2gu DQo+ID4gPj4NCj4gPiA+PiBEbyB5b3UgdGhpbmsgZGF0YSBjZW50ZXIgb3BlcmF0b3JzIHdpbGwg d2FudCB0byBydW4gcm91dGluZyBwcm90b2NvbHMNCj4gPiA+PiBpbiBoeXBlcnZpc29ycyB0aGF0 IGhhdmUgdG8gaGFuZGxlIDEwMEsgaG9zdCByb3V0ZXM/IEVzcGVjaWFsbHkgaWYNCj4gPiA+PiBz dWNoIGRldmljZXMgd2lsbCBuZWVkIHRvIGJlIHVwZ3JhZGVkIHdpdGggYmV0dGVyIGhhcmR3YXJl IHRvIHN1cHBvcnQNCj4gPiA+PiBzdWNoIGEgbG9hZD8NCj4gPiA+DQo+ID4gPiBJZiB0aGV5IG5l ZWQgdG8gYmUgdXBncmFkZWQgd2l0aCBiZXR0ZXIgaGFyZHdhcmUsIHdoeSBub3QgZGlyZWN0bHkg Y29uc2lkZXINCj4gPiB0aGUgcGh5c2ljYWwgZWRnZSBzd2l0Y2hlcyAoZS5nLiwgVG9SIHN3aXRj aGVzKSBhcyBsZWFmIG5vZGVzPw0KPiA+ID4NCj4gPiA+IEJUVywgaW4gdGhlIHR5cGljYWwgbXVs dGktdGVuYW50IGNsb3VkIGRhdGEgY2VudGVyIGVudmlyb25tZW50IHdoZXJlIG1vc3QNCj4gPiBv ZiB0aGUgdGVuYW50cyBhcmUgYmVsaWV2ZWQgdG8gYmUgU01CcywgdGhlIHJvdXRlIGFtb3VudCBv ZiBhbnkgZ2l2ZW4gdGVuYW50DQo+ID4gZG9tYWluIHdvdWxkIG5vdCBiZSB0b28gbGFyZ2UuIEhl bmNlLCBldmVuIHRoZXJlIGFyZSBtb3JlIHRoYW4gMU0gaG9zdA0KPiA+IHJvdXRlcyBpbiB0b3Rh bCwgdGhlIHJvdXRlIGFtb3VudCBvbiBhbnkgbGVhZiBub2RlIHdvdWxkIG5vdCBiZSB0b28gbGFy Z2UNCj4gc2luY2UNCj4gPiB0aGUgdGVuYW50IGFtb3VudCBvbiBhbnkgbGVhZiBub2RlIHdvdWxk IG5vdCBiZSB0b28gbGFyZ2UuIFRoZSBtYXhpbXVtDQo+ID4gdGVuYW50IGFtb3VudCBvbiBhbnkg bGVhZiBub2RlIGlzIGxpbWl0ZWQgYnkgYXQgbGVhc3QgdGhlIGZvbGxvd2luZyB0d28NCj4gZmFj dG9yczoNCj4gPiAxKSB0aGUgcG9ydCBkZW5zaXR5IG9mIGxlYXZlIG5vZGVzOyAyKSB0aGUgVk0g ZGVuc2l0eSBvZiBwaHlzaWNhbCBzZXJ2ZXJzLiBJbg0KPiA+IGFkZGl0aW9uLCBpbiB0aGUgY2Fz ZSB3aGVyZSB0aGUgbm9uLWJsb2NraW5nIERDIGZhYnJpYyBpcyBub3QgeWV0IGEgcmVhbGl0eSBk dWUNCj4gdG8NCj4gPiBpdHMgaGlnaCBjb3N0LCB0aGUgVk1zIG9mIGEgZ2l2ZW4gdGVuYW50IHdv dWxkIGJlIHBsYWNlZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSwNCj4gPiBmb3IgZXhhbXBsZSwgYmVp bmcgYXR0YWNoZWQgdG8gYSBzaW5nbGUgbGVhZiBub2RlIGlmIHBvc3NpYmxlLCBzbyBhcyB0byBy ZWR1Y2UNCj4gdGhlDQo+ID4gYmFuZHdpZHRoIGNvbnN1bXB0aW9uIG9uIHRoZSB1cGxpbmtzLiBJ biB0aGlzIHdheSwgdGhlIGF2ZXJhZ2UgdGVuYW50DQo+IGFtb3VudA0KPiA+IG9uIGEgZ2l2ZW4g bGVhZiBub2RlIHdvdWxkIGJlIGV2ZW4gbGVzcy4NCj4gPg0KPiA+IFRoZXJlIGFyZSBmb2xrcyB3 aG8gYXJlIGxvb2tpbmcgYXQgdGhlIFRvUiBhcyB0aGUgbGVhZiBub2RlLCBhbmQsIGluIG15DQo+ IG9waW5pb24sDQo+ID4gYW55IHNvbHV0aW9uIHdpbGwgcHJvYmFibHkgYmUgYSBoeWJyaWQgb2Yg VG9SIGFuZCBoeXBlcnZpc29yLiAgSG93ZXZlciwNCj4gPiByZW1lbWJlciB0aGF0IHRoZSBoeXBl cnZpc29yIHN3aXRjaCBpcyBzdGlsbCB0aGUgZmlyc3QgYWdncmVnYXRpb24gcG9pbnQsIGFuZA0K PiA+IHRoZXJlZm9yZSwgaXMgdGhlIGxlYWYgaW4gYSBuZXR3b3JrIHRyZWUuICBTb21lIGxldmVs IG9mIHN0YXRlIGFnZ3JlZ2F0aW9uDQo+IChhbmQNCj4gPiBhY2NvbXBhbnlpbmcgbG9zcykgd2ls bCBvY2N1ciBhdCB0aGUgaHlwZXJ2aXNvciBzd2l0Y2gsIG1ha2luZyBpdCB0aGUgbGVhZi4NCj4g PiBBbHNvLCB0aGVyZSBhcmUgc2NhbGluZyBpc3N1ZXMgd2l0aCBoYXZpbmcgMTAncyAob3IgMTAw J3MgaW4gdGhlIGNhc2Ugb2Ygc29tZQ0KPiA+IG9wZXJhdG9ycykgdm0ncyBydW5uaW5nIG9uIGVh Y2ggc2VydmVyLCBhbmQgaGF2aW5nIDIwLTQwIHNlcnZlcnMgcnVubmluZyBpbnRvDQo+ID4gdGhl IFRvUiAtIGFsbCBvZiBhIHN1ZGRlbiwgdGhlIGhvc3QtdGFibGUgYWxvbmUgb24gdGhlIFRvUiBi ZWNvbWVzIG1pbGRseQ0KPiA+IGludGVyZXN0aW5nLCBldmVuIHdpdGhvdXQgb3RoZXIgKGludHJh LWRhdGEgY2VudGVyKSByb3V0ZXMgb24gbG93IENBTSBUb1INCj4gPiBzd2l0Y2hlcy4gIE5vdCBh bGwgc29sdXRpb25zIHdpbGwgbWFwIHRvIGFsbCAob3IgbW9zdCkgY3VzdG9tZXJzLg0KPiA+DQo+ ID4gQWxzbywgdGhlIGNvbW1lbnQgdG8gbGltaXQgdGhlIHJvdXRlLXRhYmVsIG9mIHRlbmFudHMg ZHVlIHRvIHNtYWxsIG51bWJlcnMgb2YNCj4gPiBob3N0cyBtYXkgbm90IGFsd2F5cyAob3IgdXN1 YWxseSkgbWF0Y2ggcmVhbGl0eS4gIFdoYXQgb2YgdGhlDQo+ID4gY3Jvc3MtZGF0YS1jZW50ZXIg dHJhZmZpYyBmb3Igb3RoZXIgc2VydmljZXMgZWl0aGVyIHByb3ZpZGVkIGJ5IHRoZSBob3N0ZXIs IG9yDQo+ID4gb3RoZXIgdGVuYW50cz8gIENvbnRpbnVpbmcgdG8gcm91dGUgQUxMIG9mIHRoYXQg dHJhZmZpYyB0aHJvdWdoDQo+ID4gcm91dGluZy9zd2l0Y2hpbmcgbm9kZXMgZXh0ZXJuYWwgdG8g dGhlICJmYWJyaWMiIHdpbGwgbGVhZCB0byBpdCdzIG93biBzY2FsaW5nDQo+ID4gaXNzdWVzLiAg IERvbid0IGFzc3VtZSB0aGF0IHRoZSBvbmx5IHJvdXRlcyB0aGF0IGFuIFNNQiBuZWVkcyBhcmUg aXQncyBvd24uDQoNCkhpIENocmlzLA0KDQpCeSB0aGUgd2F5LCBpbiB0aGUgTUFDIG92ZXIgSVAg c29sdXRpb24sIHRoZSBmb3J3YXJkaW5nIHRhYmxlIG9mIHRoZSBsZWFmIG5vZGVzIGNvbnRhaW5z IHRoZSBNQUMgcm91dGVzIHRvIGhvc3RzIGFuZCB0aGUgZ2F0ZXdheXMsIHNpbWlsYXJseSwgaW4g dGhlIElQIG92ZXIgSVAgc29sdXRpb24sIHRoZSBmb3J3YXJkaW5nIHRhYmxlIG9mIGxlYWYgbm9k ZXMgY29udGFpbnMgdGhlIHJvdXRlcyB0byBob3N0cyBhbmQgb25lIG9yIG1vcmUgZGVmYXVsdCBy b3V0ZSB0byB0aGUgZ2F0ZXdheXMuIElmIHlvdSBiZWxpZXZlIHRoZSBkZWZhdWx0IHJvdXRlIGRp cmVjdGVkIHRvIHRoZSBnYXRld2F5IGluIHRoZSBJUCBvdmVyIElQIHNvbHV0aW9uIGlzIG5vdCBl bm91Z2ggZm9yIGZvcndhcmRpbmcgdGhlIGNyb3NzLWRhdGEtY2VudGVyIHRyYWZmaWMsIGRvZXMg dGhhdCBtZWFuIHRoZSBNQUMgb3ZlciBJUCBzb2x1dGlvbiBpcyB0b3RhbGx5IHVud29ya2FibGUg c2luY2UgdGhlcmUgaXMgb25seSBvbmUgTUFDIHJvdXRlIGRpcmVjdGVkIHRvIHRoZSBnYXRld2F5 IGZvciBmb3J3YXJkaW5nIHRoZSBjcm9zcy1kYXRhLWNlbnRlciB0cmFmZmljPw0KDQpCZXN0IHJl Z2FyZHMsDQpYaWFvaHUNCg0KPiBIaSBDaHJpcywNCj4gDQo+IFdvdWxkIHlvdSBwbGVhc2UgZ2l2 ZSBhIGNvbmNyZXRlIGV4YW1wbGUgd2hlcmUgdGhlIGNvbW11bmljYXRpb24gYmV0d2Vlbg0KPiBk aWZmZXJlbnQgdGVuYW50cyBpcyB2ZXJ5IGNvbW1vbiBpbiB0aGUgbXVsdGktdGVuYW50IGNsb3Vk IGRhdGEgY2VudGVyPw0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFvaHUNCj4gDQo+ID4gPg0K PiA+ID4NCj4gPiA+PiBPciB3aWxsIHRoZXkgd2FudCBhbiBhbHRlcm5hdGl2ZSBhcHByb2FjaD8N Cj4gPiA+Pg0KPiA+ID4+PiAyLiBXaHkgZG9lcyB0aGlzIG1vYmlsaXR5IG5lZWQgdG8gYmUgYXQg bGF5ZXIgMiBzcGVjaWZpY2FsbHk/IEFyZSB3ZQ0KPiA+ID4+PiBhc3N1bWluZyBERE5TIGFuZCBv dGhlciBzb3J0cyBvZiBzb2x1dGlvbnMgaW4gdGhpcyBzcGFjZSB3aWxsIHNpbXBseQ0KPiA+ID4+ PiBuZXZlciBiZSBmYXN0IGVub3VnaC9zY2FsZSBmYXIgZW5vdWdoL2V0Yz8NCj4gPiA+Pg0KPiA+ ID4+IExpa2UgaXQgb3Igbm90LCB0aGUga2V5IHJlcXVpcmVtZW50IGZvciBWTSBtb2JpbGl0eSBp cyB0aGF0IHRoZSBWTSdzDQo+ID4gPj4gSVAgYWRkcmVzcyBkb2VzIG5vdCBjaGFuZ2UuIFRoYXQg bWVhbnMgdGhlIFZNIGNhbid0IHJlYWxseSBtb3ZlIGZyb20NCj4gPiA+PiBvbmUgSVAgc3VibmV0 IHRvIGFub3RoZXIuIFRoYXQgbWVhbnMgZWl0aGVyIG1vdmluZyB0byBiaWdnZXIgYW5kDQo+ID4g Pj4gYmlnZ2VyIEwycyAoYWxsIHVuZGVyIG9uZSBJUCBzdWJuZXQpIGFzIHRoZSBEQyBleHBhbmRz IG9yIHRoZSBuZWVkIHRvDQo+ID4gPj4gaW5qZWN0IC8zMiBob3N0IHJvdXRlcy4NCj4gPiA+DQo+ ID4gPiBJbiB0aGUgRENJIHNjZW5hcmlvIHdoZXJlIHRoZSBQRSByb3V0ZXJzIGFyZSB1c3VhbGx5 IHBlcmZvcm1lZCBhdCB0aGUNCj4gPiBhZ2dyZWdhdGlvbiBTV3Mgb3IgZXZlbiBjb3JlIFNXcywg dGhlIFBFIHJvdXRlcnMgd291bGQgbmVlZCBhIG11Y2ggbGFyZ2UNCj4gPiBmb3J3YXJkaW5nIHRh YmxlLiBQcm92aWRlZCB0aGUgcm91dGluZyB0YWJsZSBjb250YWluaW5nIG1pbGxpb25zIG9mIGVu dHJpZXMsDQo+ID4gd2hpY2ggaXMgYXZhaWxhYmxlIG9uIG1vc3QgdG9kYXkncyBoaWdoLWVuZCBy b3V0ZXJzLCB3YXMgc3RpbGwgbm90IGxhcmdlDQo+IGVub3VnaCwNCj4gPiB0aGUgb24tZGVtYW5k IEZJQiBpbnN0YWxsYXRpb24gb3Igb24tZGVtYW5kIHJvdXRlIGFubm91bmNlbWVudA0KPiA+IG1l Y2hhbmlzbXMgY2FuIGJlIHVzZWQgZnVydGhlciB0byBzY2FsZSB0aGUgc29sdXRpb24uIE5vdGUg dGhhdCB0aGUgdHJpZ2dlcg0KPiBmb3INCj4gPiB0aGUgRklCIGluc3RhbGxhdGlvbiBvciByb3V0 ZSBhbm5vdW5jZW1lbnQgaXMgQVJQIHJlcXVlc3QgcGFja2V0cyByYXRoZXINCj4gdGhhbg0KPiA+ IGRhdGEgcGFja2V0cy4gSGVuY2UgaXQgd2lsbCBub3QgY2F1c2UgdGhlIHNvLWNhbGxlZCBpbml0 aWFsIHBhY2tldCBsb3NzIG9yDQo+IGxhdGVuY3kNCj4gPiBpc3N1ZS4NCj4gPiA+DQo+ID4gPj4g TmVpdGhlciBvZiB0aG9zZSBhcHByb2FjaGVzIHNlZW1zIHBhcnRpY3VsYXJseSBzY2FsYWJsZS9k ZXNpcmFibGUgaWYNCj4gPiA+PiB5b3UgbG9vayAxMCB5ZWFycyBkb3duIHRoZSByb2FkIGFuZCB0 aGluayBvZiAxTSsgcGh5c2ljYWwgbWFjaGluZXMgaW4NCj4gPiA+PiBhIERDLg0KPiA+ID4NCj4g PiA+IE1heWJlIHdlIHNob3VsZCBhbHNvIHRha2UgdGhlIGRldmVsb3BtZW50IHNwZWVkIG9mIHJv dXRpbmcvc3dpdGNoaW5nDQo+IGNoaXANCj4gPiBhbmQgQ1BVIHRlY2hub2xvZ2llcyBpbnRvIGFj Y291bnQ6KQ0KPiA+DQo+ID4gSXQncyBtb3JlIGEgcXVlc3Rpb24gb2YgY29zdC9wZXJmb3JtYW5j ZSBvbiBvZmYtY2hpcCBtZW1vcnkvVENBTXMuICBUaGF0DQo+IGlzDQo+ID4gYSBzbGlnaHRseSBk aWZmZXJlbnQgY3VydmUgOikNCj4gPg0KPiA+IAlDaHJpcw0KPiA+DQo+ID4gPg0KPiA+ID4gQmVz dCByZWdhcmRzLA0KPiA+ID4gWGlhb2h1DQo+ID4gPg0KPiA+ID4+IFRob21hcw0KPiA+ID4+DQo+ ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+PiBkYyBtYWlsaW5nIGxpc3QNCj4gPiA+PiBkY0BpZXRmLm9yZw0KPiA+ID4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGMNCj4gPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBkYyBtYWlsaW5nIGxpc3QNCj4g PiA+IGRjQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RjDQo+ID4NCj4gPiAtLQ0KPiA+IOadjuafr+edvw0KPiA+IENoZWNrIG15IFBHUCBrZXkg aGVyZTogaHR0cHM6Ly93d3cuYXNnYWFyZC5vcmcvfmNkbC9jZGwuYXNjDQo+ID4gQ3VycmVudCB2 Q2FyZCBoZXJlOiBodHRwczovL3d3dy5hc2dhYXJkLm9yZy9+Y2RsL2NkbC52Y2YNCg0K From adalela@cisco.com Fri Dec 30 03:00:49 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BBC21F8C33 for ; Fri, 30 Dec 2011 03:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuNi+G1WLm-t for ; Fri, 30 Dec 2011 03:00:49 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCE121F8C30 for ; Fri, 30 Dec 2011 03:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=4789; q=dns/txt; s=iport; t=1325242848; x=1326452448; h=mime-version:subject:date:message-id:from:to; bh=T3Ne0bKfx5RLONlSKwEyzR+DNItoFae3ho/RGLGnMPY=; b=hnf6ZhWtmXFjgrdvaDuBbY0lnW9p8Ro+e+m6ewrWfJtdKU5eEY/FPUwg 9uEoI5Rmgy+opGYbEBBzRoW9+CPKrRJFRpHmaXHRhKMliYjyOmcW8c4/w Jzd5SaauY5RYsnmektQtYYLOCdV0Q8PD18qcQVDbD9mwcxQ90fI16OBn+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAFOZ/U5Io8UY/2dsb2JhbABCgk6rIYF0AQQSAQkRA1sBKgYYB0AQBwEECxABGYdglk6BJgGeHIh1gjdjBIg1nwk X-IronPort-AV: E=Sophos;i="4.71,432,1320624000"; d="scan'208,217";a="2541992" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 30 Dec 2011 11:00:46 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBUB0kwH007360 for ; Fri, 30 Dec 2011 11:00:46 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Dec 2011 16:30:46 +0530 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_01CCC6E2.489BFCF7" Date: Fri, 30 Dec 2011 16:30:45 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102B2527A@XMB-BGL-416.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new drafts Thread-Index: AczG4kerX+iDB/pDTTeHuOUSSQYPaQ== From: "Ashish Dalela (adalela)" To: X-OriginalArrivalTime: 30 Dec 2011 11:00:46.0658 (UTC) FILETIME=[4867EA20:01CCC6E2] Subject: [dc] new drafts X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 11:00:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCC6E2.489BFCF7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Folks, =20 I have posted 2 drafts for this group to review. =20 http://www.ietf.org/id/draft-dalela-dc-requirements-00.txt http://www.ietf.org/id/draft-dalela-dc-approaches-00.txt =20 The first draft captures 10 requirements / problems to be addressed in the datacenter space. These were described over the email earlier.=20 =20 The second draft discusses various approaches to addressing these requirements. This draft analyzes the scaling properties of various approaches and makes recommendations at the end for future work that can be taken by this group. =20 Request your feedback and discussion. =20 Thanks, Ashish ------_=_NextPart_001_01CCC6E2.489BFCF7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

Folks,

 

I have posted 2 = drafts for this group to review.

 

http:= //www.ietf.org/id/draft-dalela-dc-requirements-00.txt

http://= www.ietf.org/id/draft-dalela-dc-approaches-00.txt

 

The first draft = captures 10 requirements / problems to be addressed in the datacenter = space. These were described over the email earlier. =

 

The second draft = discusses various approaches to addressing these requirements. This = draft analyzes the scaling properties of various approaches and makes = recommendations at the end for future work that can be taken by this = group.

 

Request your = feedback and discussion.

 

Thanks, = Ashish

------_=_NextPart_001_01CCC6E2.489BFCF7-- From vumip1@gmail.com Fri Dec 30 09:56:29 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE7021F85B9 for ; Fri, 30 Dec 2011 09:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MdmB7B0divz for ; Fri, 30 Dec 2011 09:56:27 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 396F321F8510 for ; Fri, 30 Dec 2011 09:56:27 -0800 (PST) Received: by obcuz6 with SMTP id uz6so11952300obc.31 for ; Fri, 30 Dec 2011 09:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=niG9DgqJHJLWjlxOBd6EfIlbTxPwSCPFFOb+EcsvL9M=; b=ea1OAsZ2nGUwwtfsf2lSlPlmnrHekjeh24xVXmQcZDpJeUpFSZ8J9LTBirQLqUVgzk XXC1XKml7Ed6jefgcUBMq7PBx17Xk6EZk8U3zd9pffERlsnRetVdrxjFdp8X4l09ien/ 52DA+jjm7JMjOvcmJ+qoQN83UmM+5NmQNJwwY= MIME-Version: 1.0 Received: by 10.50.197.169 with SMTP id iv9mr16407775igc.7.1325267784165; Fri, 30 Dec 2011 09:56:24 -0800 (PST) Received: by 10.50.77.197 with HTTP; Fri, 30 Dec 2011 09:56:24 -0800 (PST) In-Reply-To: <2E742C02-F621-497D-AE06-6A91EEEBA498@cdl.asgaard.org> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <201112281650.pBSGo7Mn011365@cichlid.raleigh.ibm.com> <2E742C02-F621-497D-AE06-6A91EEEBA498@cdl.asgaard.org> Date: Fri, 30 Dec 2011 12:56:24 -0500 Message-ID: From: Bhumip Khasnabish To: Christopher LILJENSTOLPE Content-Type: multipart/alternative; boundary=14dae93404c581e9cb04b552f325 Cc: Thomas Narten , Ronald Bonica , dc@ietf.org, "So, Ning" Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting) X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 17:56:29 -0000 --14dae93404c581e9cb04b552f325 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Chris, Thank you very much for your comments and suggestions. If you do not mind, please provide write ups, as appropriate, on Amazon API, ONF, OpenFlow, Open Stack, etc. that you mention below for inclusion in the next version of the SDO survey draft. For the work item survey draft, the intention is to provide a list. We have seen many followup drafts during the last two IETF mtgs articulating problems and possible solutions (VDCS, VPN4DC, VEPC, VPN-O-CS, VPN-O-DCS, VRM, security framewor= k for VDCS, etc.) from both service providers and solution providers. We'll be updating this draft soon, and can work on providing priority, if that is helpful. If we want to work on one near-term high-priority work item, may be virtual machine (and virtual network element) mobility and interconnection can be the focus.. (may be we need to use distributed control, distributed hash, etc.) Any others? Thanks and best wishes. Bhumip On Thu, Dec 29, 2011 at 12:59 AM, Christopher LILJENSTOLPE < ietf@cdl.asgaard.org> wrote: > Greetings Bhumip, > > This may sound harsh, and I don't want to diminish the amount of hard wor= k > that went into the documents listed below, but I think we may need to do = a > bit of a reset in this conversation. Comments in line.... > > On 28Dec2011, at 17.40, Bhumip Khasnabish wrote: > > > Hello Thomas, > > > > Yes, these are high-level very important one-liner data center related > > topics/issues. > > > > We have a draft that covers > > SDO survey ( > http://tools.ietf.org/html/draft-khasnabish-cloud-sdo-survey-01). > > This > > is basically a summary of which SDO is trying to do what and what IETF > can > > do. > > I'm not sure of the value of this survey, to be frank. It lists a number > of SDO's that may be involved in "cloud" in some way. Actually, looking = at > the list, I see very few that are doing anything that is actually driving > the industry at this time. More of the development in the industry of > standards is coming from non-SDO or new semi-SDO organizations and > vendors/providers of services. For example, Amazon has published a set o= f > API's that a number of other entities are busy implementing, ONF is busy > standardizing the OpenFlow protocol, OpenFlow operational models, and a > management framework. OpenStack is busy defining a complete "cloud" > operating environment and stack. None of them show up in the SDO documen= t, > but, to be frank, are probably having a greater impact in this area than > the majority of the SDO's listed in the document. There are other exampl= es > if one wants to dig. > > Secondly, the question we should be asking is "What does the IETF NEED to > do" not "What can the IETF do" We can do a great many things, the bulk o= f > which will not be helpful or a good use of resources. > > > We need comments and suggestions from you and others to update this doc= . > > > > We also have another draft covering potential work items > > ( > > > http://tools.ietf.org/html/draft-khasnabish-cloud-industry-workitems-surv= ey-01 > > Again, I'm not sure of the value of this document. What is the source fo= r > these "work items"? What real or near-to-mid term problems are they tryi= ng > to address? What ones are relevant to the IETF? I basically see a > catch-all list of a number of things that someone somewhere has thought > might be a problem that may need to be solved in a "cloud" environment. > Some of the real issues I hear operators talking about (including myself > if I channel myself from 8 months ago) (not theoretical, but "I have this > problem now or will soon" are somehow covered in some of the work items - > but the majority of work items listed don't really cover what I've heard = of > as current problems. Even the work items that cover existing problems ar= e > very broad, and cover MUCH more than the real issues that are being > discussed in the operational community. > > > ). > > > > We can discuss these further in the interim mtg. > > I'm not sure how fruitful such a conversation might be. A boil-the-ocean > interim meeting won't produce concrete actionable directions unless we ar= e > VERY focused in the conversation - not an IETF strong suit. > > I would like to propose a different approach, if I may. If we took a > focused set of problem statements and ran them through the following set = of > filters: > > 1) Is this a current/real or near-to-mid term probable issue and is it > substantial? > 2) If yes, is it being adequately covered by another SDO and is it in tha= t > SDO's domain? > 3) if no, is it in the domain of IETF competency? > 4) if yes, do we want to work on it? > > There are many other interesting problems outlined in the various > documents that have been listed. They could, in time be picked up by the > IETF, liaised to some other SDO, or handed to the IRTF for in-depth study= . > However, if we take the body of work that is being proposed, we will fa= il > at boiling an ocean that, in many cases, we don't even live in. We will > take too long, cast too broad a net, and be bypassed before we even get W= G > drafts issued. > > In Taipei, we heard, I think, two good sets of problem statements, those > made by Tomas Narten, and Tom Nadeau. More contributions in that vein, > preferably with real operational input, would be very helpful in forming > the conversation for the interim meeting. > > > > > In my email, the domain means admin. domain, apps/service domain, > > resource domain, etc > > There are many proprietary and app-/service-specific interim (neither > > scalable nor distributed) solution for many of the problems that I > mention, > > but IETF > > can prioritize and focus on a few and can help develop > > scalable/distributed/interoperable solution, best practices, etc. > > In this we are closer in alignment, but I think we start from the > operational problem side of the house, rather than the whole universe of > possibilities. > > > > We can develop a template to prepare a list of topics and issues > > for each of the items that IETF can contribute to. > > The IETF doesn't as a rule, contribute. We either develop standards or w= e > observe and occasionally liaise. There is too broad a space here to be > effective if we try and "contribute" to the whole problem space, in my > opinion. > > > > Any other suggestions? > > > > Thank you for starting the conversation, > Chris > > > Thanks again. > > > > Best. > > > > Bhumip > > > > > > On Wed, Dec 28, 2011 at 11:50 AM, Thomas Narten > wrote: > > > >> Hi Bhumip. > >> > >> This post (and a few others) seem to me to be providing a laundry list > >> of buzz words and generic "requirements". > >> > >> What this group needs to do is identify concrete problems for which > >> lack of a standard is preventing solutions. > >> > >> For the items mentioned above, what is the actual concrete standards > >> work that needs to be done? > >> > >> Bhumip Khasnabish writes: > >> > >> > >>> =C2=B7 Support of on-demand provisioning and management (availability= ) of > >>> distributed virtualized computing, communications, and > >>> storage resources > >> > >> This is too broad and high-level to be helpful. That is, this comes > >> across as a motherhood-and-apple-pie wish list. We need to drill down > >> into something much more concrete. > >> > >> What standards are lacking today that prevent the above from being > >> possible? > >> > >> How does the above translate into gaps that the IETF needs to fill? > >> > >>> =C2=B7 Offering of seamless mobility of virtual machine (VM), virtual= ized > >>> interface (VI), virtualized network elements (VNE) and > >>> virtualized storage (VS) from one domain to another for load > >>> balancing and service continuity management > >> > >> Same comment again. Also, what is a "domain" above? > >> > >> Also, there are already proprietary systems/products that provide VM > >> mobility. What is it that the IETF needs to do? > >> > >>> =C2=B7 Management of security, privacy, data integrity, and log of Da= ta > >>> center services for audit and verification > >> > >> Again, broad wish list. How does this translate into specific gaps > >> that the IETF needs to fill? > >> > >>> =C2=B7 Support of Distributed scaling and multi-tenancy support witho= ut > >>> excessive complexity and resource consumption > >> > >> Ditto. > >> > >>> =C2=B7 Support of Naming and addressing of virtualized entities for > >>> simplified mobility and service continuity management > >> > >> Ditto > >> > >>> =C2=B7 Support of Realistic Service level agreement parameters for Da= ta > >>> center resources and services > >> > >> Ditto. > >> > >>> * Support of Visualization of resources utilization and automation of > >>> provisioning > >> > >> Ditto. > >> > >> Thomas > >> > >> > > _______________________________________________ > > dc mailing list > > dc@ietf.org > > https://www.ietf.org/mailman/listinfo/dc > > -- > =E6=9D=8E=E6=9F=AF=E7=9D=BF > Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc > Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf > > --=20 Best. Bhumip Khasnabish vumip1@gmail.com bhumip.khasnabish@zteusa.com +1-781-752-8003 (mobile) http://tinyurl.com/bhumip __o _ `\ <, _ .......... ( =E2=80=A2 ) / ( =E2=80=A2 ) ...................... --14dae93404c581e9cb04b552f325 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Chris,
=C2=A0
Thank you very much for your comments and suggestions.
=C2=A0
If you do not mind, please provide write ups, as appropriate, on Amazo= n API, ONF, OpenFlow, Open Stack, etc.
that you mention below for inclusion in the next version of the SDO su= rvey draft.
For the work item survey draft, the intention is to provide a list. We= have seen many
followup drafts during the last two IETF mtgs articulating problems an= d possible
solutions=C2=A0 (VDCS, VPN4DC, VEPC, VPN-O-CS, VPN-O-DCS, VRM, securit= y framework
for VDCS, etc.) from both service providers and solution providers.
We'll be updating this draft soon, and can work on providing prior= ity, if that is helpful.
=C2=A0
If we want to work on one near-term high-priority work item, may be
virtual machine (and virtual network element) mobility and interconnec= tion can be the focus..
(may be we need to use distributed control, distributed hash, etc.)=C2= =A0
=C2=A0
Any others?
=C2=A0
Thanks and best wishes.
=C2=A0
Bhumip
=C2=A0
=C2=A0

=C2=A0
On Thu, Dec 29, 2011 at 12:59 AM, Christopher LI= LJENSTOLPE <ietf@cdl.asgaard.org> wrote:
Greetings Bhumip,

This may sou= nd harsh, and I don't want to diminish the amount of hard work that wen= t into the documents listed below, but I think we may need to do a bit of a= reset in this conversation. =C2=A0Comments in line....

On 28Dec2011, at 17.40, Bhumip Khasnabish wrote:

> Hello= Thomas,
>
> Yes, these are high-level very important one-liner= data center related
> topics/issues.
>
> We have a draft= that covers
> SDO survey (http://tools.ietf.org/html/draft-khasna= bish-cloud-sdo-survey-01).
> This
> is basically a summary = of which SDO is trying to do what and what IETF can
> do.

I'm not sure of the value of this survey, to be f= rank. =C2=A0It lists a number of SDO's that may be involved in "cl= oud" in some way. =C2=A0Actually, looking at the list, I see very few = that are doing anything that is actually driving the industry at this time.= =C2=A0More of the development in the industry of standards is coming from = non-SDO or new semi-SDO organizations and vendors/providers of services. = =C2=A0For example, Amazon has published a set of API's that a number of= other entities are busy implementing, ONF is busy standardizing the OpenFl= ow protocol, OpenFlow operational models, and a management framework. =C2= =A0OpenStack is busy defining a complete "cloud" operating enviro= nment and stack. =C2=A0None of them show up in the SDO document, but, to be= frank, are probably having a greater impact in this area than the majority= of the SDO's listed in the document. =C2=A0There are other examples if= one wants to dig.

Secondly, the question we should be asking is "What does the IETF = NEED to do" not "What can the IETF do" =C2=A0We can do a gre= at many things, the bulk of which will not be helpful or a good use of reso= urces.

> We need comments and suggestions from you and others to updat= e this doc.
>
> We also have another draft covering potential w= ork items
> (
> http://tools.= ietf.org/html/draft-khasnabish-cloud-industry-workitems-survey-01

Again, I'm not sure of the value of this document. =C2=A0What= is the source for these "work items"? =C2=A0What real or near-to= -mid term problems are they trying to address? =C2=A0What ones are relevant= to the IETF? =C2=A0I basically see a catch-all list of a number of things = that someone somewhere has thought might be a problem that may need to be s= olved in a "cloud" environment. =C2=A0Some of the real issues I h= ear operators talking about (including myself if I channel myself from 8 mo= nths ago) (not theoretical, but "I have this problem now or will soon&= quot; are somehow covered in some of the work items - but the majority of w= ork items listed don't really cover what I've heard of as current p= roblems. =C2=A0Even the work items that cover existing problems are very br= oad, and cover MUCH more than the real issues that are being discussed in t= he operational community.

> ).
>
> We can discuss these further in the interi= m mtg.

I'm not sure how fruitful such a conversation might= be. =C2=A0A boil-the-ocean interim meeting won't produce concrete acti= onable directions unless we are VERY focused in the conversation - not an I= ETF strong suit.

I would like to propose a different approach, if I may. =C2=A0If we too= k a focused set of problem statements and ran them through the following se= t of filters:

1) Is this a current/real or near-to-mid term probable= issue and is it substantial?
2) If yes, is it being adequately covered by another SDO and is it in that = SDO's domain?
3) if no, is it in the domain of IETF competency?
4= ) if yes, do we want to work on it?

There are many other interesting= problems outlined in the various documents that have been listed. =C2=A0Th= ey could, in time be picked up by the IETF, liaised to some other SDO, or h= anded to the IRTF for in-depth study. =C2=A0 However, if we take the body o= f work that is being proposed, we will fail at boiling an ocean that, in ma= ny cases, we don't even live in. =C2=A0We will take too long, cast too = broad a net, and be bypassed before we even get WG drafts issued.

In Taipei, we heard, I think, two good sets of problem statements, thos= e made by Tomas Narten, and Tom Nadeau. =C2=A0More contributions in that ve= in, preferably with real operational input, would be very helpful in formin= g the conversation for the interim meeting.

>
> In my email, the domain means admin. domain, apps/ser= vice domain,
> resource domain, etc
> There are many proprietar= y and app-/service-specific interim (neither
> scalable nor distribut= ed) solution for many of the problems that I mention,
> but IETF
> can prioritize and focus on a few and can help develo= p
> scalable/distributed/interoperable solution, best practices, etc.=

In this we are closer in alignment, but I think we start from= the operational problem side of the house, rather than the whole universe = of possibilities.
>
> We can develop a template to prepare a list of topics and= issues
> for each of the items that IETF can contribute to.

<= /div>The IETF doesn't as a rule, contribute. =C2=A0We either develop st= andards or we observe and occasionally liaise. =C2=A0There is too broad a s= pace here to be effective if we try and "contribute" to the whole= problem space, in my opinion.
>
> Any other suggestions?
>

Thank you for starting t= he conversation,
=C2=A0 =C2=A0 =C2=A0 =C2=A0Chris

> Thanks again.
>
> Best.
>
> Bhumip>
>
> On Wed, Dec 28, 2011 at 11:50 AM, Thomas Narten <<= a href=3D"mailto:narten@us.ibm.com" target=3D"_blank">narten@us.ibm.com= > wrote:
>
>> Hi Bhumip.
>>
>> This post (and a few ot= hers) seem to me to be providing a laundry list
>> of buzz words a= nd generic "requirements".
>>
>> What this grou= p needs to do is identify concrete problems for which
>> lack of a standard is preventing solutions.
>>
>>= ; For the items mentioned above, what is the actual concrete standards
&= gt;> work that needs to be done?
>>
>> Bhumip Khasnabi= sh <vumip1@gmail.c= om> writes:
>>
>>
>>> =C2=B7 Support of on-demand provisioni= ng and management (availability) of
>>> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0distributed virtualized computing, communications, and
>= >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0storage resources
>>
>> This is too broad and high-level to be helpful. That i= s, this comes
>> across as a motherhood-and-apple-pie wish list. W= e need to drill down
>> into something much more concrete.
>>
>> What standards are lacking today that prevent the abov= e from being
>> possible?
>>
>> How does the abo= ve translate into gaps that the IETF needs to fill?
>>
>>= > =C2=B7 Offering of seamless mobility of virtual machine (VM), virtuali= zed
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface (VI), virtualized = network elements (VNE) and
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0virtualized storage (VS) from one domain to another for load
>>= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0balancing and service continuity man= agement
>>
>> Same comment again. Also, what is a "domain"= above?
>>
>> Also, there are already proprietary systems= /products that provide VM
>> mobility. What is it that the IETF ne= eds to do?
>>
>>> =C2=B7 Management of security, privacy, data integ= rity, and log of Data
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cen= ter services for audit and verification
>>
>> Again, broa= d wish list. How does this translate into specific gaps
>> that the IETF needs to fill?
>>
>>> =C2=B7 Su= pport of Distributed scaling and multi-tenancy support without
>>&= gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0excessive complexity and resource con= sumption
>>
>> Ditto.
>>
>>> =C2=B7 Support of Naming and addressing of virtual= ized entities for
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simplif= ied mobility and service continuity management
>>
>> Ditt= o
>>
>>> =C2=B7 Support of Realistic Service level agr= eement parameters for Data
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0center resources and service= s
>>
>> Ditto.
>>
>>> * Support of V= isualization of resources utilization and automation of
>>> =C2= =A0provisioning
>>
>> Ditto.
>>
>> Thomas
>>
>>
<= /div>
> _______________________________________________
> dc mailin= g list
> dc@ietf.org=
> https://www.ietf.org/mailman/listinfo/dc

--
=E6=9D=8E=E6=9F=AF=E7=9D=BF
Check my PGP key here: https://www.a= sgaard.org/~cdl/cdl.asc
Current vCard here: https://www.asgaard.org/~cdl/cdl= .vcf




--
Best.

Bhumip Khasnabish

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __o
=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _ `\ <, _
.......... ( =E2= =80=A2 ) / ( =E2=80=A2 ) ......................

--14dae93404c581e9cb04b552f325-- From aldrin.isaac@gmail.com Fri Dec 30 14:37:08 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF1421F84A5 for ; Fri, 30 Dec 2011 14:37:08 -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.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad9IEjWay5tb for ; Fri, 30 Dec 2011 14:37:07 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD921F8462 for ; Fri, 30 Dec 2011 14:37:07 -0800 (PST) Received: by qcsf15 with SMTP id f15so10288501qcs.31 for ; Fri, 30 Dec 2011 14:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=7T3okJe5UJoSisDxqQBCWorJ357SdPyX/9CG6hBPv8A=; b=ZrV43ek64oB59PosDcdmHES4jTYD/zvJFo4/h8wfVQmzEptTXEwu8upz4ocIJoX5dA QpgeeL4M26ZgMqtCTahNYfitVSHBfgg5JIIXJQbEmZf92yRWd40T5WezjfQZzPVvvt+k zkr0hYRXQliUElcthDHWkcqkeMmVIWI4iVASA= Received: by 10.224.109.67 with SMTP id i3mr39774385qap.11.1325284626699; Fri, 30 Dec 2011 14:37:06 -0800 (PST) Received: from mymac.home (ool-44c1c730.dyn.optonline.net. [68.193.199.48]) by mx.google.com with ESMTPS id z1sm75109210qao.1.2011.12.30.14.37.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Dec 2011 14:37:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_636F9ADE-DE46-460F-9B86-C38BDF1F419B" From: Aldrin Isaac In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102B2527A@XMB-BGL-416.cisco.com> Date: Fri, 30 Dec 2011 17:37:03 -0500 Message-Id: References: <618BE8B40039924EB9AED233D4A09C5102B2527A@XMB-BGL-416.cisco.com> To: Ashish Dalela (adalela) X-Mailer: Apple Mail (2.1251.1) Cc: dc@ietf.org Subject: Re: [dc] new drafts X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 22:37:08 -0000 --Apple-Mail=_636F9ADE-DE46-460F-9B86-C38BDF1F419B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ashish, How would you address gratuitous ARP when using the hierarchical MAC = addressing with a registry to store MAC-IP bindings? Also, when using MAC prefixes in complex L2VPN topologies how could we = address the risk of a hub forwarding into the wrong spoke context on the = leaf switch? Each egress port on the leaf switch may be in a different = context (ex: EVI in EVPN). Thanks -- aldrin On Dec 30, 2011, at 6:00 AM, Ashish Dalela (adalela) wrote: > =20 > Folks, > =20 > I have posted 2 drafts for this group to review. > =20 > http://www.ietf.org/id/draft-dalela-dc-requirements-00.txt > http://www.ietf.org/id/draft-dalela-dc-approaches-00.txt > =20 > The first draft captures 10 requirements / problems to be addressed in = the datacenter space. These were described over the email earlier. > =20 > The second draft discusses various approaches to addressing these = requirements. This draft analyzes the scaling properties of various = approaches and makes recommendations at the end for future work that can = be taken by this group. > =20 > Request your feedback and discussion. > =20 > Thanks, Ashish > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc --Apple-Mail=_636F9ADE-DE46-460F-9B86-C38BDF1F419B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Ashish,

How would you address = gratuitous ARP when using the hierarchical MAC addressing with a = registry to store MAC-IP bindings?

Also, when = using MAC prefixes in complex L2VPN topologies how could we address the = risk of a hub forwarding into the wrong spoke context on the leaf = switch?  Each egress port on the leaf switch may be in a different = context (ex: EVI in EVPN).

Thanks -- = aldrin


On Dec 30, 2011, at 6:00 = AM, Ashish Dalela (adalela) wrote:

 
Folks,
 
I have posted 2 drafts for this group to = review.
 
______________________________________= _________
dc mailing list
 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] new drafts Thread-Index: AczHQ5Ibz3rgY/6nRheu6Vl9HF22ngAF9URQ References: <618BE8B40039924EB9AED233D4A09C5102B2527A@XMB-BGL-416.cisco.com> From: "Ashish Dalela (adalela)" To: "Aldrin Isaac" X-OriginalArrivalTime: 31 Dec 2011 01:54:12.0042 (UTC) FILETIME=[17B462A0:01CCC75F] Cc: dc@ietf.org Subject: Re: [dc] new drafts X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 01:54:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCC75F.175C20B8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Aldrin, =20 >> How would you address gratuitous ARP when using the hierarchical MAC addressing with a registry to store MAC-IP bindings? =20 We should ideally have a protocol that maps ARP messages into the registry and vice versa. Why new protocol? Greater security and reliability plus avoiding ARP broadcasts. Gratuitous ARP doesn't have an acknowledge, so if you want to perform some actions based on this, you need to get an "acknowledge" for it. Gratuitous ARP can get dropped.=20 =20 The other issue is that a user can misuse it do MAC hijacking. But if you have a hierarchical MAC you can't hijack because network knows your location. Things like dot1x which solved these issues in the campus space are not used in datacenter.=20 =20 >> Also, when using MAC prefixes in complex L2VPN topologies how could we address the risk of a hub forwarding into the wrong spoke context on the leaf switch? Each egress port on the leaf switch may be in a different context (ex: EVI in EVPN). =20 We should avoid building any kind of VRF at the control plane, because that's just not scalable. With hierarchical MAC, you have global L2 addressing so from a forwarding perspective it looks like static L3 routing and anyone can send packets anywhere. When a VM moves, this doesn't change the global forwarding table (unless a virtual switch moves - which is also possible). To segment customers we tag packets with some tenant id, and it will be dropped at destination. The tags will be present both at ingress and egress ports. =20 There are only two possible approaches - drop at source or drop at destination. If we try to drop at source, we need a mapping to which destinations are allowed (too many, and the scale is unpredictable). If we drop at destination, we still need to know which destinations are allowed, but that's just comprised of local host entries (no new entries).=20 =20 I'm not totally certain if I answered your question, so let me know. =20 Thanks, Ashish =20 From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]=20 Sent: Saturday, December 31, 2011 4:07 AM To: Ashish Dalela (adalela) Cc: dc@ietf.org Subject: Re: [dc] new drafts =20 Hi Ashish, =20 How would you address gratuitous ARP when using the hierarchical MAC addressing with a registry to store MAC-IP bindings? =20 Also, when using MAC prefixes in complex L2VPN topologies how could we address the risk of a hub forwarding into the wrong spoke context on the leaf switch? Each egress port on the leaf switch may be in a different context (ex: EVI in EVPN). =20 Thanks -- aldrin =20 =20 On Dec 30, 2011, at 6:00 AM, Ashish Dalela (adalela) wrote: =20 Folks, =20 I have posted 2 drafts for this group to review. =20 http://www.ietf.org/id/draft-dalela-dc-requirements-00.txt http://www.ietf.org/id/draft-dalela-dc-approaches-00.txt =20 The first draft captures 10 requirements / problems to be addressed in the datacenter space. These were described over the email earlier. =20 The second draft discusses various approaches to addressing these requirements. This draft analyzes the scaling properties of various approaches and makes recommendations at the end for future work that can be taken by this group. =20 Request your feedback and discussion. =20 Thanks, Ashish _______________________________________________ dc mailing list dc@ietf.org https://www.ietf.org/mailman/listinfo/dc =20 ------_=_NextPart_001_01CCC75F.175C20B8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Aldrin,

 

>> How would you address gratuitous ARP when using the = hierarchical MAC addressing with a registry to store MAC-IP = bindings?

 

We should ideally have a protocol that maps ARP messages into the = registry and vice versa. Why new protocol? Greater security and = reliability plus avoiding ARP broadcasts. Gratuitous ARP doesn’t = have an acknowledge, so if you want to perform some actions based on = this, you need to get an “acknowledge” for it. Gratuitous = ARP can get dropped.

 

The other issue is that a user can misuse it do MAC hijacking. But if = you have a hierarchical MAC you can’t hijack because network knows = your location. Things like dot1x which solved these issues in the campus = space are not used in datacenter.

 

>> Also, when using MAC prefixes in complex L2VPN = topologies how could we address the risk of a hub forwarding into the = wrong spoke context on the leaf switch?  Each egress port on the = leaf switch may be in a different context (ex: EVI in = EVPN).

 

We should avoid building any kind of VRF at the control plane, = because that’s just not scalable. With hierarchical MAC, you have = global L2 addressing so from a forwarding perspective it looks like = static L3 routing and anyone can send packets anywhere. When a VM moves, = this doesn’t change the global forwarding table (unless a virtual = switch moves – which is also possible). To segment customers we = tag packets with some tenant id, and it will be dropped at destination. = The tags will be present both at ingress and egress = ports.

 

There are only two possible approaches – drop at source or drop = at destination. If we try to drop at source, we need a mapping to which = destinations are allowed (too many, and the scale is unpredictable). If = we drop at destination, we still need to know which destinations are = allowed, but that’s just comprised of local host entries (no new = entries).

 

I’m not totally certain if I answered your question, so let me = know.

 

Thanks, Ashish

 

From:= = Aldrin Isaac [mailto:aldrin.isaac@gmail.com]
Sent: Saturday, = December 31, 2011 4:07 AM
To: Ashish Dalela = (adalela)
Cc: dc@ietf.org
Subject: Re: [dc] new = drafts

 

Hi = Ashish,

 

How would you address gratuitous ARP when using the = hierarchical MAC addressing with a registry to store MAC-IP = bindings?

 

Also, when using MAC prefixes in complex L2VPN = topologies how could we address the risk of a hub forwarding into the = wrong spoke context on the leaf switch?  Each egress port on the = leaf switch may be in a different context (ex: EVI in = EVPN).

 

Thanks -- aldrin

 

 

On = Dec 30, 2011, at 6:00 AM, Ashish Dalela (adalela) = wrote:



 =

Folks,=

 =

I have posted 2 drafts = for this group to review.=

 =

 =

The first draft captures = 10 requirements / problems to be addressed in the datacenter space. = These were described over the email earlier.=

 =

The second draft = discusses various approaches to addressing these requirements. This = draft analyzes the scaling properties of various approaches and makes = recommendations at the end for future work that can be taken by this = group.=

 =

Request your feedback = and discussion.=

 =

Thanks, = Ashish=

_________________= ______________________________
dc mailing list
dc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dc

 

------_=_NextPart_001_01CCC75F.175C20B8-- From xuxiaohu@huawei.com Fri Dec 30 18:34:02 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D654E21F84C1 for ; Fri, 30 Dec 2011 18:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.357 X-Spam-Level: X-Spam-Status: No, score=-4.357 tagged_above=-999 required=5 tests=[AWL=1.927, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUXjSoGHoLYc for ; Fri, 30 Dec 2011 18:34:01 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4A021F84BB for ; Fri, 30 Dec 2011 18:34:01 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LX100HHZR4GZ5@szxga05-in.huawei.com> for dc@ietf.org; Sat, 31 Dec 2011 10:33:52 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LX1002HZR4GFW@szxga05-in.huawei.com> for dc@ietf.org; Sat, 31 Dec 2011 10:33:52 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGC95504; Sat, 31 Dec 2011 10:33:51 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 31 Dec 2011 10:33:45 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Sat, 31 Dec 2011 10:33:43 +0800 Date: Sat, 31 Dec 2011 02:33:42 +0000 From: Xuxiaohu In-reply-to: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7639B3@szxeml525-mbs.china.huawei.com> X-Originating-IP: [10.108.4.80] To: "dc@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE763ACD@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dc] Elevator Pitch Thread-index: AQHMw1wuBgE5G7BjGEyEvGVWBnVRbZXw96YAgAF/L4CAABiKgIABPS+QgAFrhJA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE76387F@szxeml525-mbs.china.huawei.com> <229A8E99-6EB2-49E5-B530-BA0F6C7C40AC@asgaard.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7639B3@szxeml525-mbs.china.huawei.com> Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 02:34:03 -0000 SGkgYWxsLA0KDQpTaW5jZSB0aGVyZSBhcmUgc29tZSBkaWZmZXJlbmNlcyBpbiB0aGUgcHJvYmxl bXMgYW5kIHJlcXVpcmVtZW50cyBiZXR3ZWVuIGRhdGEgY2VudGVyIG5ldHdvcmsgKERDTikgYW5k IGRhdGEgY2VudGVyIGludGVyY29ubmVjdCAoRENJKSwgSSB0cnkgdG8gbGlzdCBzZXZlcmFsIHBy b2JsZW1zIGFuZCByZXF1aXJlbWVudHMgZm9yIERDTiBhbmQgRENJIHNlcGFyYXRlbHkgYXMgZm9s bG93cy4gSGVyZSB0aGUgZGF0YSBjZW50ZXJzIG1haW5seSByZWZlciB0byB0aG9zZSBtdWx0aS10 ZW5hbnQgZGF0YSBjZW50ZXJzIHdoaWNoIGFyZSBvcGVyYXRlZCBieSBwdWJsaWMgY2xvdWQgcHJv dmlkZXJzIHRvIGRlbGl2ZXIgY2xvdWQgc2VydmljZSAoaS5lLiwgSWFhUykgdG8gdGhlaXIgY3Vz dG9tZXJzIChpLmUuLCB0ZW5hbnRzKS4NCg0KMS4gRENOIHByb2JsZW1zIGFuZCByZXF1aXJlbWVu dHM6DQoNCjEpIFZNIG1vYmlsaXR5IGFjcm9zcyBtdWx0aXBsZSBwb2RzIC0+IExBTi9zdWJuZXQg ZXh0ZW5zaW9uIGFjcm9zcyBwb2RzDQoNCjIpIFNvbWUgY2x1c3RlciBhcHBsaWNhdGlvbnMgdXNl IG5vbi1JUCBvciBsaW5rLWxvY2FsIG11bHRpY2FzdCAob3B0aW9uYWwpIC0+IExheWVyMiBuZXR3 b3JraW5nDQoNCjMpIE11bHRpLXRlbmFuY3kgaXNvbGF0aW9uIC0+IFZQTi9WTEFOIGluc3RhbmNl IHNjYWxhYmlsaXR5DQoNCjQpIE1pbGxpb25zIG9mIFZNcyAtPiBNQUMvSVAgZm9yd2FyZGluZyB0 YWJsZSBzY2FsYWJpbGl0eQ0KDQo1KSBJbmNyZWFzaW5nIGJhbmR3aWR0aCBkZW1hbmRzIGZvciBz ZXJ2ZXItdG8tc2VydmVyIGNvbm5lY3Rpdml0eSAoaS5lLiwgZWFzdC13ZXN0IHRyYWZmaWMpLT4g RUNNUCBhbmQgc2hvcnRlc3QgcGF0aCBmb3J3YXJkaW5nIGNhcGFiaWxpdGllcw0KDQo2KSBOZXR3 b3JrIHJlc2lsaWVuY3kgLT4gRmFzdCBjb252ZXJnZW5jZSBhbmQgbXVsdGktaG9taW5nDQoNCjcp IFRob3VzYW5kcyBvZiBuZXR3b3JrIGRldmljZXMgLT4gU2ltcGxpZmllZCBwcm92aXNpb25pbmcg YW5kIG9wZXJhdGlvbg0KDQoNCg0KMi4gRENJIHByb2JsZW1zIGFuZCByZXF1aXJlbWVudHM6DQoN CjEpIFZNcyBtb2JpbGl0eSBhY3Jvc3MgZGF0YSBjZW50ZXJzIC0+IExBTi9zdWJuZXQgZXh0ZW5z aW9uIGFjcm9zcyBkYXRhIGNlbnRlcnMuDQoNCjIpIE11bHRpLXRlbmFuY3kgaXNvbGF0aW9uIC0+ IFZMQU4vVlBOIGluc3RhbmNlIHNjYWxhYmlsaXR5DQoNCjMpIE1pbGxpb25zIG9mIFZNcyAtPiBN QUMvSVAgZm9yd2FyZGluZyB0YWJsZSBzY2FsYWJpbGl0eQ0KDQo0KSBPcHRpbWFsIHV0aWxpemF0 aW9uIG9mIFdBTiBiYW5kd2lkdGggcmVzb3VyY2UgLT4gVW5rbm93biB1bmljYXN0IGFuZCBBUlAg YnJvYWRjYXN0IHN1cHByZXNzaW9uDQoNCjUpIE5ldHdvcmsgcmVzaWxpZW5jeSAtPiBGYXN0IGNv bnZlcmdlbmNlIGFuZCBtdWx0aS1ob21pbmcNCg0KNikgTG9hZC1iYWxhbmNpbmcgYWNyb3NzIGRh dGEgY2VudGVycyAtPiBBY3RpdmUtYWN0aXZlIERDIGV4aXRzDQoNCjcpIFN1Ym9wdGltYWwgcGF0 aCBjYXVzZWQgYnkgTEFOL3N1Ym5ldCBleHRlbnNpb24gYWNyb3NzIGRhdGEgY2VudGVyIC0+IFBh dGggb3B0aW1pemF0aW9uIGZvciBib3RoIFZQTiBhY2Nlc3MgYW5kIEludGVybmV0IGFjY2Vzcw0K DQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWP keS7tuS6ujogZGMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRjLWJvdW5jZXNAaWV0Zi5vcmdd IOS7o+ihqCBYdXhpYW9odQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTHlubQxMuaciDMw5pelIDEyOjAy DQo+IOaUtuS7tuS6ujogQ2hyaXN0b3BoZXIgTElMSkVOU1RPTFBFDQo+IOaKhOmAgTogVGhvbWFz IE5hcnRlbjsgUnVzcyBXaGl0ZTsgZGNAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW2RjXSBFbGV2 YXRvciBQaXRjaA0KPiANCj4gDQo+ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+IOWPkeS7 tuS6ujogQ2hyaXN0b3BoZXIgTElMSkVOU1RPTFBFIFttYWlsdG86Y2RsQGFzZ2FhcmQub3JnXQ0K PiA+IOWPkemAgeaXtumXtDogMjAxMeW5tDEy5pyIMzDml6UgMToyMA0KPiA+IOaUtuS7tuS6ujog WHV4aWFvaHUNCj4gPiDmioTpgIE6IFRob21hcyBOYXJ0ZW47IFJ1c3MgV2hpdGU7IGRjQGlldGYu b3JnDQo+ID4g5Li76aKYOiBSZTogW2RjXSBFbGV2YXRvciBQaXRjaA0KPiA+DQo+ID4gR3JlZXRp bmdzIFh1eGlhb2h1LA0KPiA+DQo+ID4gT24gMjlEZWMyMDExLCBhdCAwMC41NSwgWHV4aWFvaHUg d3JvdGU6DQo+ID4NCj4gPiA+IEhpIFRob21hcywNCj4gPiA+DQo+ID4gPj4gLS0tLS3pgq7ku7bl jp/ku7YtLS0tLQ0KPiA+ID4+IOWPkeS7tuS6ujogZGMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmRjLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqA0KPiBUaG9tYXMNCj4gPiA+PiBOYXJ0ZW4NCj4g PiA+PiDlj5HpgIHml7bpl7Q6IDIwMTHlubQxMuaciDI55pelIDE6MDENCj4gPiA+PiDmlLbku7bk uro6IFJ1c3MgV2hpdGUNCj4gPiA+PiDmioTpgIE6IGRjQGlldGYub3JnDQo+ID4gPj4g5Li76aKY OiBSZTogW2RjXSBFbGV2YXRvciBQaXRjaA0KPiA+ID4+DQo+ID4gPj4+IDEuIEhvdyBtYW55IGhv c3Qgcm91dGVzIGRvIHdlIHJlYWNoIGJlZm9yZSB3ZSBzYXkgaXQgIndvbid0IHNjYWxlPyIgSWYN Cj4gPiA+Pj4geW91J3JlIHRhbGtpbmcgYWJvdXQgbGVhZiBub2RlcyBpbiBhIHJvdXRpbmcgcHJv dG9jb2wsIDEwMGsgaXNuJ3QgcmVhbGx5DQo+ID4gPj4+IHRoYXQgYmlnIG9mIGEgZGVhbC4gV2hl cmUgeW91IGRvIHJ1biBpbnRvIHByb2JsZW1zIGlzIGJldHdlZW4gdGhlDQo+ID4gPj4+IHJvdXRp bmcgYW5kIGZvcndhcmRpbmcgdGFibGVzIC0tYnV0IHRoYXQncyBhbiBhcmVhIGZvciB0aG91Z2h0 Lg0KPiA+ID4+DQo+ID4gPj4gQWN0dWFsbHksIDEwMEsgaG9zdCByb3V0ZXMgaW4gbGVhZiBub2Rl cyBtYXkgd2VsbCBiZSBhIEJpZyBEZWFsLiBJdA0KPiA+ID4+IGRlcGVuZHMgb24gd2hhdCB0eXBl IG9mIGRldmljZXMgbmVlZCB0byB1bmRlcnN0YW5kIGhvc3Qgcm91dGVzLg0KPiA+ID4+DQo+ID4g Pj4gRm9yIHRoZSBzY2VuYXJpb3MgTlZPMyBpcyBsb29raW5nIGF0LCB0aGUgZWRnZSBkZXZpY2Ug aW5jbHVkZXMgZWRnZQ0KPiA+ID4+IHN3aXRjaGVzIGFuZCBoeXBlcnZpc29ycy4gWWVzLCBzdWNo IGRldmljZXMgY2FuIGluIHRoZW9yeSBzdXBwb3J0IDEwMEsNCj4gPiA+PiBob3N0IHJvdXRlcyAo YW5kIHRoZSByb3V0aW5nIHByb3RvY29sIG5lZWRlZCB0byBtYWtlIHRoYXQgY29udmVyZ2UpDQo+ ID4gPj4NCj4gPiA+PiBCdXQgYXQgYSBjb3N0Lg0KPiA+ID4+DQo+ID4gPj4gQW5kIEkgc3VzcGVj dCB0aGUgY29zdCBpcyB0b28gaGlnaC4NCj4gPiA+Pg0KPiA+ID4+IERvIHlvdSB0aGluayBkYXRh IGNlbnRlciBvcGVyYXRvcnMgd2lsbCB3YW50IHRvIHJ1biByb3V0aW5nIHByb3RvY29scw0KPiA+ ID4+IGluIGh5cGVydmlzb3JzIHRoYXQgaGF2ZSB0byBoYW5kbGUgMTAwSyBob3N0IHJvdXRlcz8g RXNwZWNpYWxseSBpZg0KPiA+ID4+IHN1Y2ggZGV2aWNlcyB3aWxsIG5lZWQgdG8gYmUgdXBncmFk ZWQgd2l0aCBiZXR0ZXIgaGFyZHdhcmUgdG8gc3VwcG9ydA0KPiA+ID4+IHN1Y2ggYSBsb2FkPw0K PiA+ID4NCj4gPiA+IElmIHRoZXkgbmVlZCB0byBiZSB1cGdyYWRlZCB3aXRoIGJldHRlciBoYXJk d2FyZSwgd2h5IG5vdCBkaXJlY3RseSBjb25zaWRlcg0KPiA+IHRoZSBwaHlzaWNhbCBlZGdlIHN3 aXRjaGVzIChlLmcuLCBUb1Igc3dpdGNoZXMpIGFzIGxlYWYgbm9kZXM/DQo+ID4gPg0KPiA+ID4g QlRXLCBpbiB0aGUgdHlwaWNhbCBtdWx0aS10ZW5hbnQgY2xvdWQgZGF0YSBjZW50ZXIgZW52aXJv bm1lbnQgd2hlcmUgbW9zdA0KPiA+IG9mIHRoZSB0ZW5hbnRzIGFyZSBiZWxpZXZlZCB0byBiZSBT TUJzLCB0aGUgcm91dGUgYW1vdW50IG9mIGFueSBnaXZlbiB0ZW5hbnQNCj4gPiBkb21haW4gd291 bGQgbm90IGJlIHRvbyBsYXJnZS4gSGVuY2UsIGV2ZW4gdGhlcmUgYXJlIG1vcmUgdGhhbiAxTSBo b3N0DQo+ID4gcm91dGVzIGluIHRvdGFsLCB0aGUgcm91dGUgYW1vdW50IG9uIGFueSBsZWFmIG5v ZGUgd291bGQgbm90IGJlIHRvbyBsYXJnZQ0KPiBzaW5jZQ0KPiA+IHRoZSB0ZW5hbnQgYW1vdW50 IG9uIGFueSBsZWFmIG5vZGUgd291bGQgbm90IGJlIHRvbyBsYXJnZS4gVGhlIG1heGltdW0NCj4g PiB0ZW5hbnQgYW1vdW50IG9uIGFueSBsZWFmIG5vZGUgaXMgbGltaXRlZCBieSBhdCBsZWFzdCB0 aGUgZm9sbG93aW5nIHR3bw0KPiBmYWN0b3JzOg0KPiA+IDEpIHRoZSBwb3J0IGRlbnNpdHkgb2Yg bGVhdmUgbm9kZXM7IDIpIHRoZSBWTSBkZW5zaXR5IG9mIHBoeXNpY2FsIHNlcnZlcnMuIEluDQo+ ID4gYWRkaXRpb24sIGluIHRoZSBjYXNlIHdoZXJlIHRoZSBub24tYmxvY2tpbmcgREMgZmFicmlj IGlzIG5vdCB5ZXQgYSByZWFsaXR5IGR1ZQ0KPiB0bw0KPiA+IGl0cyBoaWdoIGNvc3QsIHRoZSBW TXMgb2YgYSBnaXZlbiB0ZW5hbnQgd291bGQgYmUgcGxhY2VkIGFzIGNsb3NlIGFzIHBvc3NpYmxl LA0KPiA+IGZvciBleGFtcGxlLCBiZWluZyBhdHRhY2hlZCB0byBhIHNpbmdsZSBsZWFmIG5vZGUg aWYgcG9zc2libGUsIHNvIGFzIHRvIHJlZHVjZQ0KPiB0aGUNCj4gPiBiYW5kd2lkdGggY29uc3Vt cHRpb24gb24gdGhlIHVwbGlua3MuIEluIHRoaXMgd2F5LCB0aGUgYXZlcmFnZSB0ZW5hbnQNCj4g YW1vdW50DQo+ID4gb24gYSBnaXZlbiBsZWFmIG5vZGUgd291bGQgYmUgZXZlbiBsZXNzLg0KPiA+ DQo+ID4gVGhlcmUgYXJlIGZvbGtzIHdobyBhcmUgbG9va2luZyBhdCB0aGUgVG9SIGFzIHRoZSBs ZWFmIG5vZGUsIGFuZCwgaW4gbXkNCj4gb3BpbmlvbiwNCj4gPiBhbnkgc29sdXRpb24gd2lsbCBw cm9iYWJseSBiZSBhIGh5YnJpZCBvZiBUb1IgYW5kIGh5cGVydmlzb3IuICBIb3dldmVyLA0KPiA+ IHJlbWVtYmVyIHRoYXQgdGhlIGh5cGVydmlzb3Igc3dpdGNoIGlzIHN0aWxsIHRoZSBmaXJzdCBh Z2dyZWdhdGlvbiBwb2ludCwgYW5kDQo+ID4gdGhlcmVmb3JlLCBpcyB0aGUgbGVhZiBpbiBhIG5l dHdvcmsgdHJlZS4gIFNvbWUgbGV2ZWwgb2Ygc3RhdGUgYWdncmVnYXRpb24NCj4gKGFuZA0KPiA+ IGFjY29tcGFueWluZyBsb3NzKSB3aWxsIG9jY3VyIGF0IHRoZSBoeXBlcnZpc29yIHN3aXRjaCwg bWFraW5nIGl0IHRoZSBsZWFmLg0KPiA+IEFsc28sIHRoZXJlIGFyZSBzY2FsaW5nIGlzc3VlcyB3 aXRoIGhhdmluZyAxMCdzIChvciAxMDAncyBpbiB0aGUgY2FzZSBvZiBzb21lDQo+ID4gb3BlcmF0 b3JzKSB2bSdzIHJ1bm5pbmcgb24gZWFjaCBzZXJ2ZXIsIGFuZCBoYXZpbmcgMjAtNDAgc2VydmVy cyBydW5uaW5nIGludG8NCj4gPiB0aGUgVG9SIC0gYWxsIG9mIGEgc3VkZGVuLCB0aGUgaG9zdC10 YWJsZSBhbG9uZSBvbiB0aGUgVG9SIGJlY29tZXMgbWlsZGx5DQo+ID4gaW50ZXJlc3RpbmcsIGV2 ZW4gd2l0aG91dCBvdGhlciAoaW50cmEtZGF0YSBjZW50ZXIpIHJvdXRlcyBvbiBsb3cgQ0FNIFRv Ug0KPiA+IHN3aXRjaGVzLiAgTm90IGFsbCBzb2x1dGlvbnMgd2lsbCBtYXAgdG8gYWxsIChvciBt b3N0KSBjdXN0b21lcnMuDQo+ID4NCj4gPiBBbHNvLCB0aGUgY29tbWVudCB0byBsaW1pdCB0aGUg cm91dGUtdGFiZWwgb2YgdGVuYW50cyBkdWUgdG8gc21hbGwgbnVtYmVycyBvZg0KPiA+IGhvc3Rz IG1heSBub3QgYWx3YXlzIChvciB1c3VhbGx5KSBtYXRjaCByZWFsaXR5LiAgV2hhdCBvZiB0aGUN Cj4gPiBjcm9zcy1kYXRhLWNlbnRlciB0cmFmZmljIGZvciBvdGhlciBzZXJ2aWNlcyBlaXRoZXIg cHJvdmlkZWQgYnkgdGhlIGhvc3Rlciwgb3INCj4gPiBvdGhlciB0ZW5hbnRzPyAgQ29udGludWlu ZyB0byByb3V0ZSBBTEwgb2YgdGhhdCB0cmFmZmljIHRocm91Z2gNCj4gPiByb3V0aW5nL3N3aXRj aGluZyBub2RlcyBleHRlcm5hbCB0byB0aGUgImZhYnJpYyIgd2lsbCBsZWFkIHRvIGl0J3Mgb3du IHNjYWxpbmcNCj4gPiBpc3N1ZXMuICAgRG9uJ3QgYXNzdW1lIHRoYXQgdGhlIG9ubHkgcm91dGVz IHRoYXQgYW4gU01CIG5lZWRzIGFyZSBpdCdzIG93bi4NCj4gDQo+IEhpIENocmlzLA0KPiANCj4g V291bGQgeW91IHBsZWFzZSBnaXZlIGEgY29uY3JldGUgZXhhbXBsZSB3aGVyZSB0aGUgY29tbXVu aWNhdGlvbiBiZXR3ZWVuDQo+IGRpZmZlcmVudCB0ZW5hbnRzIGlzIHZlcnkgY29tbW9uIGluIHRo ZSBtdWx0aS10ZW5hbnQgY2xvdWQgZGF0YSBjZW50ZXI/DQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+ IFhpYW9odQ0KPiANCj4gPiA+DQo+ID4gPg0KPiA+ID4+IE9yIHdpbGwgdGhleSB3YW50IGFuIGFs dGVybmF0aXZlIGFwcHJvYWNoPw0KPiA+ID4+DQo+ID4gPj4+IDIuIFdoeSBkb2VzIHRoaXMgbW9i aWxpdHkgbmVlZCB0byBiZSBhdCBsYXllciAyIHNwZWNpZmljYWxseT8gQXJlIHdlDQo+ID4gPj4+ IGFzc3VtaW5nIERETlMgYW5kIG90aGVyIHNvcnRzIG9mIHNvbHV0aW9ucyBpbiB0aGlzIHNwYWNl IHdpbGwgc2ltcGx5DQo+ID4gPj4+IG5ldmVyIGJlIGZhc3QgZW5vdWdoL3NjYWxlIGZhciBlbm91 Z2gvZXRjPw0KPiA+ID4+DQo+ID4gPj4gTGlrZSBpdCBvciBub3QsIHRoZSBrZXkgcmVxdWlyZW1l bnQgZm9yIFZNIG1vYmlsaXR5IGlzIHRoYXQgdGhlIFZNJ3MNCj4gPiA+PiBJUCBhZGRyZXNzIGRv ZXMgbm90IGNoYW5nZS4gVGhhdCBtZWFucyB0aGUgVk0gY2FuJ3QgcmVhbGx5IG1vdmUgZnJvbQ0K PiA+ID4+IG9uZSBJUCBzdWJuZXQgdG8gYW5vdGhlci4gVGhhdCBtZWFucyBlaXRoZXIgbW92aW5n IHRvIGJpZ2dlciBhbmQNCj4gPiA+PiBiaWdnZXIgTDJzIChhbGwgdW5kZXIgb25lIElQIHN1Ym5l dCkgYXMgdGhlIERDIGV4cGFuZHMgb3IgdGhlIG5lZWQgdG8NCj4gPiA+PiBpbmplY3QgLzMyIGhv c3Qgcm91dGVzLg0KPiA+ID4NCj4gPiA+IEluIHRoZSBEQ0kgc2NlbmFyaW8gd2hlcmUgdGhlIFBF IHJvdXRlcnMgYXJlIHVzdWFsbHkgcGVyZm9ybWVkIGF0IHRoZQ0KPiA+IGFnZ3JlZ2F0aW9uIFNX cyBvciBldmVuIGNvcmUgU1dzLCB0aGUgUEUgcm91dGVycyB3b3VsZCBuZWVkIGEgbXVjaCBsYXJn ZQ0KPiA+IGZvcndhcmRpbmcgdGFibGUuIFByb3ZpZGVkIHRoZSByb3V0aW5nIHRhYmxlIGNvbnRh aW5pbmcgbWlsbGlvbnMgb2YgZW50cmllcywNCj4gPiB3aGljaCBpcyBhdmFpbGFibGUgb24gbW9z dCB0b2RheSdzIGhpZ2gtZW5kIHJvdXRlcnMsIHdhcyBzdGlsbCBub3QgbGFyZ2UNCj4gZW5vdWdo LA0KPiA+IHRoZSBvbi1kZW1hbmQgRklCIGluc3RhbGxhdGlvbiBvciBvbi1kZW1hbmQgcm91dGUg YW5ub3VuY2VtZW50DQo+ID4gbWVjaGFuaXNtcyBjYW4gYmUgdXNlZCBmdXJ0aGVyIHRvIHNjYWxl IHRoZSBzb2x1dGlvbi4gTm90ZSB0aGF0IHRoZSB0cmlnZ2VyDQo+IGZvcg0KPiA+IHRoZSBGSUIg aW5zdGFsbGF0aW9uIG9yIHJvdXRlIGFubm91bmNlbWVudCBpcyBBUlAgcmVxdWVzdCBwYWNrZXRz IHJhdGhlcg0KPiB0aGFuDQo+ID4gZGF0YSBwYWNrZXRzLiBIZW5jZSBpdCB3aWxsIG5vdCBjYXVz ZSB0aGUgc28tY2FsbGVkIGluaXRpYWwgcGFja2V0IGxvc3Mgb3INCj4gbGF0ZW5jeQ0KPiA+IGlz c3VlLg0KPiA+ID4NCj4gPiA+PiBOZWl0aGVyIG9mIHRob3NlIGFwcHJvYWNoZXMgc2VlbXMgcGFy dGljdWxhcmx5IHNjYWxhYmxlL2Rlc2lyYWJsZSBpZg0KPiA+ID4+IHlvdSBsb29rIDEwIHllYXJz IGRvd24gdGhlIHJvYWQgYW5kIHRoaW5rIG9mIDFNKyBwaHlzaWNhbCBtYWNoaW5lcyBpbg0KPiA+ ID4+IGEgREMuDQo+ID4gPg0KPiA+ID4gTWF5YmUgd2Ugc2hvdWxkIGFsc28gdGFrZSB0aGUgZGV2 ZWxvcG1lbnQgc3BlZWQgb2Ygcm91dGluZy9zd2l0Y2hpbmcNCj4gY2hpcA0KPiA+IGFuZCBDUFUg dGVjaG5vbG9naWVzIGludG8gYWNjb3VudDopDQo+ID4NCj4gPiBJdCdzIG1vcmUgYSBxdWVzdGlv biBvZiBjb3N0L3BlcmZvcm1hbmNlIG9uIG9mZi1jaGlwIG1lbW9yeS9UQ0FNcy4gIFRoYXQNCj4g aXMNCj4gPiBhIHNsaWdodGx5IGRpZmZlcmVudCBjdXJ2ZSA6KQ0KPiA+DQo+ID4gCUNocmlzDQo+ ID4NCj4gPiA+DQo+ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiBYaWFvaHUNCj4gPiA+DQo+ID4g Pj4gVGhvbWFzDQo+ID4gPj4NCj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4+IGRjIG1haWxpbmcgbGlzdA0KPiA+ID4+IGRjQGlldGYu b3JnDQo+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYw0KPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ IGRjIG1haWxpbmcgbGlzdA0KPiA+ID4gZGNAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGMNCj4gPg0KPiA+IC0tDQo+ID4g5p2O5p+v552/DQo+ ID4gQ2hlY2sgbXkgUEdQIGtleSBoZXJlOiBodHRwczovL3d3dy5hc2dhYXJkLm9yZy9+Y2RsL2Nk bC5hc2MNCj4gPiBDdXJyZW50IHZDYXJkIGhlcmU6IGh0dHBzOi8vd3d3LmFzZ2FhcmQub3JnL35j ZGwvY2RsLnZjZg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gZGMgbWFpbGluZyBsaXN0DQo+IGRjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGMNCg== From adalela@cisco.com Fri Dec 30 19:03:20 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CFD21F851F for ; Fri, 30 Dec 2011 19:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVx05TxAe2kK for ; Fri, 30 Dec 2011 19:03:19 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id D1A2C21F851A for ; Fri, 30 Dec 2011 19:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=12542; q=dns/txt; s=iport; t=1325300598; x=1326510198; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=dbLSn1/Grz6E5H4aGX0vipLczVl5f1ZXEZIqli7iMT0=; b=SveDmCo3TumQ86JyP0WihJFSWxSC6A/VuBtzf0y97ngEeRUYEQRhtXUF s94ONHIoL/quIdPDcqMOQOSG0k4m058NzrLanmLf14qFY7B/iOsykaQ1A GJOYI7ZeSwj7i20K28AZXZfPxmLZd3JsRkET9Wc93XG7l0KvnWXnVrHPV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowAABN6/k5Io8UY/2dsb2JhbABDFoR5lwmPN4IKgXIBAQEEAQEBDwEQBAkEOhcEAgEGAhEEAQEBAgIGBgUSAQICAgEBJR8JCAIEAQoICBMHh2CXGwGMW5EgBIEvhzqCEDNjBIg1nwk X-IronPort-AV: E=Sophos;i="4.71,435,1320624000"; d="scan'208";a="2558725" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 31 Dec 2011 03:03:16 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBV33GG1023179; Sat, 31 Dec 2011 03:03:16 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Dec 2011 08:33:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sat, 31 Dec 2011 08:33:17 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102B25312@XMB-BGL-416.cisco.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE763ACD@szxeml525-mbs.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Elevator Pitch Thread-Index: AQHMw1wuBgE5G7BjGEyEvGVWBnVRbZXw96YAgAF/L4CAABiKgIABPS+QgAFrhJCAABDmcA== References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com><13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net><618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com><4EF7B019.3030202@riw.us><201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com><1FEE3F8F5CCDE64C9A8E8F4AD27C19EE76387F@szxeml525-mbs.china.huawei.com><229A8E99-6EB2-49E5-B530-BA0F6C7C40AC@asgaard.org><1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7639B3@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE763ACD@szxeml525-mbs.china.huawei.com> From: "Ashish Dalela (adalela)" To: "Xuxiaohu" , X-OriginalArrivalTime: 31 Dec 2011 03:03:15.0956 (UTC) FILETIME=[BDAB7B40:01CCC768] Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 03:03:20 -0000 V2hhdCBpcyB0aGUgZGlmZmVyZW5jZT8gTXVsdGktaG9taW5nID0gbXVsdGktcGF0aCA9IGFjdGl2 ZS1hY3RpdmUuIFdoYXQgeW91IG5lZWQgaW4gb25lIHBsYWNlIHRoYXQgeW91IGRvbid0IG5lZWQg aW4gb3RoZXI/DQoNClRoYW5rcywgQXNoaXNoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBkYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFh1eGlhb2h1DQpTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMzEsIDIwMTEg ODowNCBBTQ0KVG86IGRjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RjXSBFbGV2YXRvciBQaXRj aA0KDQpIaSBhbGwsDQoNClNpbmNlIHRoZXJlIGFyZSBzb21lIGRpZmZlcmVuY2VzIGluIHRoZSBw cm9ibGVtcyBhbmQgcmVxdWlyZW1lbnRzIGJldHdlZW4gZGF0YSBjZW50ZXIgbmV0d29yayAoRENO KSBhbmQgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0IChEQ0kpLCBJIHRyeSB0byBsaXN0IHNldmVy YWwgcHJvYmxlbXMgYW5kIHJlcXVpcmVtZW50cyBmb3IgRENOIGFuZCBEQ0kgc2VwYXJhdGVseSBh cyBmb2xsb3dzLiBIZXJlIHRoZSBkYXRhIGNlbnRlcnMgbWFpbmx5IHJlZmVyIHRvIHRob3NlIG11 bHRpLXRlbmFudCBkYXRhIGNlbnRlcnMgd2hpY2ggYXJlIG9wZXJhdGVkIGJ5IHB1YmxpYyBjbG91 ZCBwcm92aWRlcnMgdG8gZGVsaXZlciBjbG91ZCBzZXJ2aWNlIChpLmUuLCBJYWFTKSB0byB0aGVp ciBjdXN0b21lcnMgKGkuZS4sIHRlbmFudHMpLg0KDQoxLiBEQ04gcHJvYmxlbXMgYW5kIHJlcXVp cmVtZW50czoNCg0KMSkgVk0gbW9iaWxpdHkgYWNyb3NzIG11bHRpcGxlIHBvZHMgLT4gTEFOL3N1 Ym5ldCBleHRlbnNpb24gYWNyb3NzIHBvZHMNCg0KMikgU29tZSBjbHVzdGVyIGFwcGxpY2F0aW9u cyB1c2Ugbm9uLUlQIG9yIGxpbmstbG9jYWwgbXVsdGljYXN0IChvcHRpb25hbCkgLT4gTGF5ZXIy IG5ldHdvcmtpbmcNCg0KMykgTXVsdGktdGVuYW5jeSBpc29sYXRpb24gLT4gVlBOL1ZMQU4gaW5z dGFuY2Ugc2NhbGFiaWxpdHkNCg0KNCkgTWlsbGlvbnMgb2YgVk1zIC0+IE1BQy9JUCBmb3J3YXJk aW5nIHRhYmxlIHNjYWxhYmlsaXR5DQoNCjUpIEluY3JlYXNpbmcgYmFuZHdpZHRoIGRlbWFuZHMg Zm9yIHNlcnZlci10by1zZXJ2ZXIgY29ubmVjdGl2aXR5IChpLmUuLCBlYXN0LXdlc3QgdHJhZmZp YyktPiBFQ01QIGFuZCBzaG9ydGVzdCBwYXRoIGZvcndhcmRpbmcgY2FwYWJpbGl0aWVzDQoNCjYp IE5ldHdvcmsgcmVzaWxpZW5jeSAtPiBGYXN0IGNvbnZlcmdlbmNlIGFuZCBtdWx0aS1ob21pbmcN Cg0KNykgVGhvdXNhbmRzIG9mIG5ldHdvcmsgZGV2aWNlcyAtPiBTaW1wbGlmaWVkIHByb3Zpc2lv bmluZyBhbmQgb3BlcmF0aW9uDQoNCg0KDQoyLiBEQ0kgcHJvYmxlbXMgYW5kIHJlcXVpcmVtZW50 czoNCg0KMSkgVk1zIG1vYmlsaXR5IGFjcm9zcyBkYXRhIGNlbnRlcnMgLT4gTEFOL3N1Ym5ldCBl eHRlbnNpb24gYWNyb3NzIGRhdGEgY2VudGVycy4NCg0KMikgTXVsdGktdGVuYW5jeSBpc29sYXRp b24gLT4gVkxBTi9WUE4gaW5zdGFuY2Ugc2NhbGFiaWxpdHkNCg0KMykgTWlsbGlvbnMgb2YgVk1z IC0+IE1BQy9JUCBmb3J3YXJkaW5nIHRhYmxlIHNjYWxhYmlsaXR5DQoNCjQpIE9wdGltYWwgdXRp bGl6YXRpb24gb2YgV0FOIGJhbmR3aWR0aCByZXNvdXJjZSAtPiBVbmtub3duIHVuaWNhc3QgYW5k IEFSUCBicm9hZGNhc3Qgc3VwcHJlc3Npb24NCg0KNSkgTmV0d29yayByZXNpbGllbmN5IC0+IEZh c3QgY29udmVyZ2VuY2UgYW5kIG11bHRpLWhvbWluZw0KDQo2KSBMb2FkLWJhbGFuY2luZyBhY3Jv c3MgZGF0YSBjZW50ZXJzIC0+IEFjdGl2ZS1hY3RpdmUgREMgZXhpdHMNCg0KNykgU3Vib3B0aW1h bCBwYXRoIGNhdXNlZCBieSBMQU4vc3VibmV0IGV4dGVuc2lvbiBhY3Jvc3MgZGF0YSBjZW50ZXIg LT4gUGF0aCBvcHRpbWl6YXRpb24gZm9yIGJvdGggVlBOIGFjY2VzcyBhbmQgSW50ZXJuZXQgYWNj ZXNzDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0N Cj4g5Y+R5Lu25Lq6OiBkYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGMtYm91bmNlc0BpZXRm Lm9yZ10g5Luj6KGoIFh1eGlhb2h1DQo+IOWPkemAgeaXtumXtDogMjAxMeW5tDEy5pyIMzDml6Ug MTI6MDINCj4g5pS25Lu25Lq6OiBDaHJpc3RvcGhlciBMSUxKRU5TVE9MUEUNCj4g5oqE6YCBOiBU aG9tYXMgTmFydGVuOyBSdXNzIFdoaXRlOyBkY0BpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbZGNd IEVsZXZhdG9yIFBpdGNoDQo+IA0KPiANCj4gPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4g 5Y+R5Lu25Lq6OiBDaHJpc3RvcGhlciBMSUxKRU5TVE9MUEUgW21haWx0bzpjZGxAYXNnYWFyZC5v cmddDQo+ID4g5Y+R6YCB5pe26Ze0OiAyMDEx5bm0MTLmnIgzMOaXpSAxOjIwDQo+ID4g5pS25Lu2 5Lq6OiBYdXhpYW9odQ0KPiA+IOaKhOmAgTogVGhvbWFzIE5hcnRlbjsgUnVzcyBXaGl0ZTsgZGNA aWV0Zi5vcmcNCj4gPiDkuLvpopg6IFJlOiBbZGNdIEVsZXZhdG9yIFBpdGNoDQo+ID4NCj4gPiBH cmVldGluZ3MgWHV4aWFvaHUsDQo+ID4NCj4gPiBPbiAyOURlYzIwMTEsIGF0IDAwLjU1LCBYdXhp YW9odSB3cm90ZToNCj4gPg0KPiA+ID4gSGkgVGhvbWFzLA0KPiA+ID4NCj4gPiA+PiAtLS0tLemC ruS7tuWOn+S7ti0tLS0tDQo+ID4gPj4g5Y+R5Lu25Lq6OiBkYy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86ZGMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoDQo+IFRob21hcw0KPiA+ID4+IE5hcnRl bg0KPiA+ID4+IOWPkemAgeaXtumXtDogMjAxMeW5tDEy5pyIMjnml6UgMTowMQ0KPiA+ID4+IOaU tuS7tuS6ujogUnVzcyBXaGl0ZQ0KPiA+ID4+IOaKhOmAgTogZGNAaWV0Zi5vcmcNCj4gPiA+PiDk uLvpopg6IFJlOiBbZGNdIEVsZXZhdG9yIFBpdGNoDQo+ID4gPj4NCj4gPiA+Pj4gMS4gSG93IG1h bnkgaG9zdCByb3V0ZXMgZG8gd2UgcmVhY2ggYmVmb3JlIHdlIHNheSBpdCAid29uJ3Qgc2NhbGU/ IiBJZg0KPiA+ID4+PiB5b3UncmUgdGFsa2luZyBhYm91dCBsZWFmIG5vZGVzIGluIGEgcm91dGlu ZyBwcm90b2NvbCwgMTAwayBpc24ndCByZWFsbHkNCj4gPiA+Pj4gdGhhdCBiaWcgb2YgYSBkZWFs LiBXaGVyZSB5b3UgZG8gcnVuIGludG8gcHJvYmxlbXMgaXMgYmV0d2VlbiB0aGUNCj4gPiA+Pj4g cm91dGluZyBhbmQgZm9yd2FyZGluZyB0YWJsZXMgLS1idXQgdGhhdCdzIGFuIGFyZWEgZm9yIHRo b3VnaHQuDQo+ID4gPj4NCj4gPiA+PiBBY3R1YWxseSwgMTAwSyBob3N0IHJvdXRlcyBpbiBsZWFm IG5vZGVzIG1heSB3ZWxsIGJlIGEgQmlnIERlYWwuIEl0DQo+ID4gPj4gZGVwZW5kcyBvbiB3aGF0 IHR5cGUgb2YgZGV2aWNlcyBuZWVkIHRvIHVuZGVyc3RhbmQgaG9zdCByb3V0ZXMuDQo+ID4gPj4N Cj4gPiA+PiBGb3IgdGhlIHNjZW5hcmlvcyBOVk8zIGlzIGxvb2tpbmcgYXQsIHRoZSBlZGdlIGRl dmljZSBpbmNsdWRlcyBlZGdlDQo+ID4gPj4gc3dpdGNoZXMgYW5kIGh5cGVydmlzb3JzLiBZZXMs IHN1Y2ggZGV2aWNlcyBjYW4gaW4gdGhlb3J5IHN1cHBvcnQgMTAwSw0KPiA+ID4+IGhvc3Qgcm91 dGVzIChhbmQgdGhlIHJvdXRpbmcgcHJvdG9jb2wgbmVlZGVkIHRvIG1ha2UgdGhhdCBjb252ZXJn ZSkNCj4gPiA+Pg0KPiA+ID4+IEJ1dCBhdCBhIGNvc3QuDQo+ID4gPj4NCj4gPiA+PiBBbmQgSSBz dXNwZWN0IHRoZSBjb3N0IGlzIHRvbyBoaWdoLg0KPiA+ID4+DQo+ID4gPj4gRG8geW91IHRoaW5r IGRhdGEgY2VudGVyIG9wZXJhdG9ycyB3aWxsIHdhbnQgdG8gcnVuIHJvdXRpbmcgcHJvdG9jb2xz DQo+ID4gPj4gaW4gaHlwZXJ2aXNvcnMgdGhhdCBoYXZlIHRvIGhhbmRsZSAxMDBLIGhvc3Qgcm91 dGVzPyBFc3BlY2lhbGx5IGlmDQo+ID4gPj4gc3VjaCBkZXZpY2VzIHdpbGwgbmVlZCB0byBiZSB1 cGdyYWRlZCB3aXRoIGJldHRlciBoYXJkd2FyZSB0byBzdXBwb3J0DQo+ID4gPj4gc3VjaCBhIGxv YWQ/DQo+ID4gPg0KPiA+ID4gSWYgdGhleSBuZWVkIHRvIGJlIHVwZ3JhZGVkIHdpdGggYmV0dGVy IGhhcmR3YXJlLCB3aHkgbm90IGRpcmVjdGx5IGNvbnNpZGVyDQo+ID4gdGhlIHBoeXNpY2FsIGVk Z2Ugc3dpdGNoZXMgKGUuZy4sIFRvUiBzd2l0Y2hlcykgYXMgbGVhZiBub2Rlcz8NCj4gPiA+DQo+ ID4gPiBCVFcsIGluIHRoZSB0eXBpY2FsIG11bHRpLXRlbmFudCBjbG91ZCBkYXRhIGNlbnRlciBl bnZpcm9ubWVudCB3aGVyZSBtb3N0DQo+ID4gb2YgdGhlIHRlbmFudHMgYXJlIGJlbGlldmVkIHRv IGJlIFNNQnMsIHRoZSByb3V0ZSBhbW91bnQgb2YgYW55IGdpdmVuIHRlbmFudA0KPiA+IGRvbWFp biB3b3VsZCBub3QgYmUgdG9vIGxhcmdlLiBIZW5jZSwgZXZlbiB0aGVyZSBhcmUgbW9yZSB0aGFu IDFNIGhvc3QNCj4gPiByb3V0ZXMgaW4gdG90YWwsIHRoZSByb3V0ZSBhbW91bnQgb24gYW55IGxl YWYgbm9kZSB3b3VsZCBub3QgYmUgdG9vIGxhcmdlDQo+IHNpbmNlDQo+ID4gdGhlIHRlbmFudCBh bW91bnQgb24gYW55IGxlYWYgbm9kZSB3b3VsZCBub3QgYmUgdG9vIGxhcmdlLiBUaGUgbWF4aW11 bQ0KPiA+IHRlbmFudCBhbW91bnQgb24gYW55IGxlYWYgbm9kZSBpcyBsaW1pdGVkIGJ5IGF0IGxl YXN0IHRoZSBmb2xsb3dpbmcgdHdvDQo+IGZhY3RvcnM6DQo+ID4gMSkgdGhlIHBvcnQgZGVuc2l0 eSBvZiBsZWF2ZSBub2RlczsgMikgdGhlIFZNIGRlbnNpdHkgb2YgcGh5c2ljYWwgc2VydmVycy4g SW4NCj4gPiBhZGRpdGlvbiwgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIG5vbi1ibG9ja2luZyBEQyBm YWJyaWMgaXMgbm90IHlldCBhIHJlYWxpdHkgZHVlDQo+IHRvDQo+ID4gaXRzIGhpZ2ggY29zdCwg dGhlIFZNcyBvZiBhIGdpdmVuIHRlbmFudCB3b3VsZCBiZSBwbGFjZWQgYXMgY2xvc2UgYXMgcG9z c2libGUsDQo+ID4gZm9yIGV4YW1wbGUsIGJlaW5nIGF0dGFjaGVkIHRvIGEgc2luZ2xlIGxlYWYg bm9kZSBpZiBwb3NzaWJsZSwgc28gYXMgdG8gcmVkdWNlDQo+IHRoZQ0KPiA+IGJhbmR3aWR0aCBj b25zdW1wdGlvbiBvbiB0aGUgdXBsaW5rcy4gSW4gdGhpcyB3YXksIHRoZSBhdmVyYWdlIHRlbmFu dA0KPiBhbW91bnQNCj4gPiBvbiBhIGdpdmVuIGxlYWYgbm9kZSB3b3VsZCBiZSBldmVuIGxlc3Mu DQo+ID4NCj4gPiBUaGVyZSBhcmUgZm9sa3Mgd2hvIGFyZSBsb29raW5nIGF0IHRoZSBUb1IgYXMg dGhlIGxlYWYgbm9kZSwgYW5kLCBpbiBteQ0KPiBvcGluaW9uLA0KPiA+IGFueSBzb2x1dGlvbiB3 aWxsIHByb2JhYmx5IGJlIGEgaHlicmlkIG9mIFRvUiBhbmQgaHlwZXJ2aXNvci4gIEhvd2V2ZXIs DQo+ID4gcmVtZW1iZXIgdGhhdCB0aGUgaHlwZXJ2aXNvciBzd2l0Y2ggaXMgc3RpbGwgdGhlIGZp cnN0IGFnZ3JlZ2F0aW9uIHBvaW50LCBhbmQNCj4gPiB0aGVyZWZvcmUsIGlzIHRoZSBsZWFmIGlu IGEgbmV0d29yayB0cmVlLiAgU29tZSBsZXZlbCBvZiBzdGF0ZSBhZ2dyZWdhdGlvbg0KPiAoYW5k DQo+ID4gYWNjb21wYW55aW5nIGxvc3MpIHdpbGwgb2NjdXIgYXQgdGhlIGh5cGVydmlzb3Igc3dp dGNoLCBtYWtpbmcgaXQgdGhlIGxlYWYuDQo+ID4gQWxzbywgdGhlcmUgYXJlIHNjYWxpbmcgaXNz dWVzIHdpdGggaGF2aW5nIDEwJ3MgKG9yIDEwMCdzIGluIHRoZSBjYXNlIG9mIHNvbWUNCj4gPiBv cGVyYXRvcnMpIHZtJ3MgcnVubmluZyBvbiBlYWNoIHNlcnZlciwgYW5kIGhhdmluZyAyMC00MCBz ZXJ2ZXJzIHJ1bm5pbmcgaW50bw0KPiA+IHRoZSBUb1IgLSBhbGwgb2YgYSBzdWRkZW4sIHRoZSBo b3N0LXRhYmxlIGFsb25lIG9uIHRoZSBUb1IgYmVjb21lcyBtaWxkbHkNCj4gPiBpbnRlcmVzdGlu ZywgZXZlbiB3aXRob3V0IG90aGVyIChpbnRyYS1kYXRhIGNlbnRlcikgcm91dGVzIG9uIGxvdyBD QU0gVG9SDQo+ID4gc3dpdGNoZXMuICBOb3QgYWxsIHNvbHV0aW9ucyB3aWxsIG1hcCB0byBhbGwg KG9yIG1vc3QpIGN1c3RvbWVycy4NCj4gPg0KPiA+IEFsc28sIHRoZSBjb21tZW50IHRvIGxpbWl0 IHRoZSByb3V0ZS10YWJlbCBvZiB0ZW5hbnRzIGR1ZSB0byBzbWFsbCBudW1iZXJzIG9mDQo+ID4g aG9zdHMgbWF5IG5vdCBhbHdheXMgKG9yIHVzdWFsbHkpIG1hdGNoIHJlYWxpdHkuICBXaGF0IG9m IHRoZQ0KPiA+IGNyb3NzLWRhdGEtY2VudGVyIHRyYWZmaWMgZm9yIG90aGVyIHNlcnZpY2VzIGVp dGhlciBwcm92aWRlZCBieSB0aGUgaG9zdGVyLCBvcg0KPiA+IG90aGVyIHRlbmFudHM/ICBDb250 aW51aW5nIHRvIHJvdXRlIEFMTCBvZiB0aGF0IHRyYWZmaWMgdGhyb3VnaA0KPiA+IHJvdXRpbmcv c3dpdGNoaW5nIG5vZGVzIGV4dGVybmFsIHRvIHRoZSAiZmFicmljIiB3aWxsIGxlYWQgdG8gaXQn cyBvd24gc2NhbGluZw0KPiA+IGlzc3Vlcy4gICBEb24ndCBhc3N1bWUgdGhhdCB0aGUgb25seSBy b3V0ZXMgdGhhdCBhbiBTTUIgbmVlZHMgYXJlIGl0J3Mgb3duLg0KPiANCj4gSGkgQ2hyaXMsDQo+ IA0KPiBXb3VsZCB5b3UgcGxlYXNlIGdpdmUgYSBjb25jcmV0ZSBleGFtcGxlIHdoZXJlIHRoZSBj b21tdW5pY2F0aW9uIGJldHdlZW4NCj4gZGlmZmVyZW50IHRlbmFudHMgaXMgdmVyeSBjb21tb24g aW4gdGhlIG11bHRpLXRlbmFudCBjbG91ZCBkYXRhIGNlbnRlcj8NCj4gDQo+IEJlc3QgcmVnYXJk cywNCj4gWGlhb2h1DQo+IA0KPiA+ID4NCj4gPiA+DQo+ID4gPj4gT3Igd2lsbCB0aGV5IHdhbnQg YW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2g/DQo+ID4gPj4NCj4gPiA+Pj4gMi4gV2h5IGRvZXMgdGhp cyBtb2JpbGl0eSBuZWVkIHRvIGJlIGF0IGxheWVyIDIgc3BlY2lmaWNhbGx5PyBBcmUgd2UNCj4g PiA+Pj4gYXNzdW1pbmcgREROUyBhbmQgb3RoZXIgc29ydHMgb2Ygc29sdXRpb25zIGluIHRoaXMg c3BhY2Ugd2lsbCBzaW1wbHkNCj4gPiA+Pj4gbmV2ZXIgYmUgZmFzdCBlbm91Z2gvc2NhbGUgZmFy IGVub3VnaC9ldGM/DQo+ID4gPj4NCj4gPiA+PiBMaWtlIGl0IG9yIG5vdCwgdGhlIGtleSByZXF1 aXJlbWVudCBmb3IgVk0gbW9iaWxpdHkgaXMgdGhhdCB0aGUgVk0ncw0KPiA+ID4+IElQIGFkZHJl c3MgZG9lcyBub3QgY2hhbmdlLiBUaGF0IG1lYW5zIHRoZSBWTSBjYW4ndCByZWFsbHkgbW92ZSBm cm9tDQo+ID4gPj4gb25lIElQIHN1Ym5ldCB0byBhbm90aGVyLiBUaGF0IG1lYW5zIGVpdGhlciBt b3ZpbmcgdG8gYmlnZ2VyIGFuZA0KPiA+ID4+IGJpZ2dlciBMMnMgKGFsbCB1bmRlciBvbmUgSVAg c3VibmV0KSBhcyB0aGUgREMgZXhwYW5kcyBvciB0aGUgbmVlZCB0bw0KPiA+ID4+IGluamVjdCAv MzIgaG9zdCByb3V0ZXMuDQo+ID4gPg0KPiA+ID4gSW4gdGhlIERDSSBzY2VuYXJpbyB3aGVyZSB0 aGUgUEUgcm91dGVycyBhcmUgdXN1YWxseSBwZXJmb3JtZWQgYXQgdGhlDQo+ID4gYWdncmVnYXRp b24gU1dzIG9yIGV2ZW4gY29yZSBTV3MsIHRoZSBQRSByb3V0ZXJzIHdvdWxkIG5lZWQgYSBtdWNo IGxhcmdlDQo+ID4gZm9yd2FyZGluZyB0YWJsZS4gUHJvdmlkZWQgdGhlIHJvdXRpbmcgdGFibGUg Y29udGFpbmluZyBtaWxsaW9ucyBvZiBlbnRyaWVzLA0KPiA+IHdoaWNoIGlzIGF2YWlsYWJsZSBv biBtb3N0IHRvZGF5J3MgaGlnaC1lbmQgcm91dGVycywgd2FzIHN0aWxsIG5vdCBsYXJnZQ0KPiBl bm91Z2gsDQo+ID4gdGhlIG9uLWRlbWFuZCBGSUIgaW5zdGFsbGF0aW9uIG9yIG9uLWRlbWFuZCBy b3V0ZSBhbm5vdW5jZW1lbnQNCj4gPiBtZWNoYW5pc21zIGNhbiBiZSB1c2VkIGZ1cnRoZXIgdG8g c2NhbGUgdGhlIHNvbHV0aW9uLiBOb3RlIHRoYXQgdGhlIHRyaWdnZXINCj4gZm9yDQo+ID4gdGhl IEZJQiBpbnN0YWxsYXRpb24gb3Igcm91dGUgYW5ub3VuY2VtZW50IGlzIEFSUCByZXF1ZXN0IHBh Y2tldHMgcmF0aGVyDQo+IHRoYW4NCj4gPiBkYXRhIHBhY2tldHMuIEhlbmNlIGl0IHdpbGwgbm90 IGNhdXNlIHRoZSBzby1jYWxsZWQgaW5pdGlhbCBwYWNrZXQgbG9zcyBvcg0KPiBsYXRlbmN5DQo+ ID4gaXNzdWUuDQo+ID4gPg0KPiA+ID4+IE5laXRoZXIgb2YgdGhvc2UgYXBwcm9hY2hlcyBzZWVt cyBwYXJ0aWN1bGFybHkgc2NhbGFibGUvZGVzaXJhYmxlIGlmDQo+ID4gPj4geW91IGxvb2sgMTAg eWVhcnMgZG93biB0aGUgcm9hZCBhbmQgdGhpbmsgb2YgMU0rIHBoeXNpY2FsIG1hY2hpbmVzIGlu DQo+ID4gPj4gYSBEQy4NCj4gPiA+DQo+ID4gPiBNYXliZSB3ZSBzaG91bGQgYWxzbyB0YWtlIHRo ZSBkZXZlbG9wbWVudCBzcGVlZCBvZiByb3V0aW5nL3N3aXRjaGluZw0KPiBjaGlwDQo+ID4gYW5k IENQVSB0ZWNobm9sb2dpZXMgaW50byBhY2NvdW50OikNCj4gPg0KPiA+IEl0J3MgbW9yZSBhIHF1 ZXN0aW9uIG9mIGNvc3QvcGVyZm9ybWFuY2Ugb24gb2ZmLWNoaXAgbWVtb3J5L1RDQU1zLiAgVGhh dA0KPiBpcw0KPiA+IGEgc2xpZ2h0bHkgZGlmZmVyZW50IGN1cnZlIDopDQo+ID4NCj4gPiAJQ2hy aXMNCj4gPg0KPiA+ID4NCj4gPiA+IEJlc3QgcmVnYXJkcywNCj4gPiA+IFhpYW9odQ0KPiA+ID4N Cj4gPiA+PiBUaG9tYXMNCj4gPiA+Pg0KPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4gZGMgbWFpbGluZyBsaXN0DQo+ID4gPj4gZGNA aWV0Zi5vcmcNCj4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rj DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gZGMgbWFpbGluZyBsaXN0DQo+ID4gPiBkY0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYw0KPiA+DQo+ID4gLS0NCj4gPiDmnY7mn6/n nb8NCj4gPiBDaGVjayBteSBQR1Aga2V5IGhlcmU6IGh0dHBzOi8vd3d3LmFzZ2FhcmQub3JnL35j ZGwvY2RsLmFzYw0KPiA+IEN1cnJlbnQgdkNhcmQgaGVyZTogaHR0cHM6Ly93d3cuYXNnYWFyZC5v cmcvfmNkbC9jZGwudmNmDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBkYyBtYWlsaW5nIGxpc3QNCj4gZGNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYw0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmRjIG1haWxpbmcgbGlzdA0KZGNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGMNCg== From aldrin.isaac@gmail.com Fri Dec 30 20:38:33 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68FD21F84FA for ; Fri, 30 Dec 2011 20:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYdAjfzvS0ZU for ; Fri, 30 Dec 2011 20:38:33 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBD1721F84F9 for ; Fri, 30 Dec 2011 20:38:32 -0800 (PST) Received: by qcsf15 with SMTP id f15so10374693qcs.31 for ; Fri, 30 Dec 2011 20:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=uY8H4IRVyTAiew3F7ItKL6GU3AUQvOzh+rGcGoRazFY=; b=DhiIFSeV5XbdRoKeY/5yUz9k6vRGV77oMcS+MJhy7/4tHd8+zjUTfbXI089mYUOt1E NQIZIBqUYDAP2fJKBS+jYgDAXIuVpm30M5b/AJ2sNyWmcERGphN7KEQA4B99CzE2Gpky cYXRCNnk58V9DgiPNBDpOfZAevRqoCVMnvXgw= Received: by 10.229.105.68 with SMTP id s4mr15484784qco.81.1325306310570; Fri, 30 Dec 2011 20:38:30 -0800 (PST) Received: from mymac.home (ool-44c1c730.dyn.optonline.net. [68.193.199.48]) by mx.google.com with ESMTPS id dh10sm76825711qab.19.2011.12.30.20.38.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Dec 2011 20:38:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Aldrin Isaac In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE763ACD@szxeml525-mbs.china.huawei.com> Date: Fri, 30 Dec 2011 23:38:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <90C84A4D-C6E3-412B-9ECF-F36C80EFB6D2@gmail.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE76387F@szxeml525-mbs.china.huawei.com> <229A8E99-6EB2-49E5-B530-BA0F6C7C40AC@asgaard.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7639B3@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE763ACD@szxeml525-mbs.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1251.1) Cc: "dc@ietf.org" Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 04:38:33 -0000 Xuxiaohu Good summary. I would add to that: * Support for both VM and physical end stations in same LAN/subnet. * Support for flexible virtual topologies -- ex: a host can be a member = of one or more LAN topologies (think private vlan on steroids) The following subgoals would fall under the scalability goals, but = highlighting them here anyway. * Resource load on any network node should be proportional (or better) = to the number of virtual networks joined by downstream nodes and the = size of those virtual networks. * Eliminate data plane learning at all network points including at the = (physical and virtual) host-network interface (please). A proper UNI is = needed for this purpose. Thank you. On Dec 30, 2011, at 9:33 PM, Xuxiaohu wrote: > Hi all, >=20 > Since there are some differences in the problems and requirements = between data center network (DCN) and data center interconnect (DCI), I = try to list several problems and requirements for DCN and DCI separately = as follows. Here the data centers mainly refer to those multi-tenant = data centers which are operated by public cloud providers to deliver = cloud service (i.e., IaaS) to their customers (i.e., tenants). >=20 > 1. DCN problems and requirements: >=20 > 1) VM mobility across multiple pods -> LAN/subnet extension across = pods >=20 > 2) Some cluster applications use non-IP or link-local multicast = (optional) -> Layer2 networking >=20 > 3) Multi-tenancy isolation -> VPN/VLAN instance scalability >=20 > 4) Millions of VMs -> MAC/IP forwarding table scalability >=20 > 5) Increasing bandwidth demands for server-to-server connectivity = (i.e., east-west traffic)-> ECMP and shortest path forwarding = capabilities >=20 > 6) Network resiliency -> Fast convergence and multi-homing >=20 > 7) Thousands of network devices -> Simplified provisioning and = operation >=20 >=20 >=20 > 2. DCI problems and requirements: >=20 > 1) VMs mobility across data centers -> LAN/subnet extension across = data centers. >=20 > 2) Multi-tenancy isolation -> VLAN/VPN instance scalability >=20 > 3) Millions of VMs -> MAC/IP forwarding table scalability >=20 > 4) Optimal utilization of WAN bandwidth resource -> Unknown unicast = and ARP broadcast suppression >=20 > 5) Network resiliency -> Fast convergence and multi-homing >=20 > 6) Load-balancing across data centers -> Active-active DC exits >=20 > 7) Suboptimal path caused by LAN/subnet extension across data center = -> Path optimization for both VPN access and Internet access >=20 > Best regards, > Xiaohu >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: dc-bounces@ietf.org = [mailto:dc-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Xuxiaohu >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B412=E6=9C=8830=E6=97=A5= 12:02 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Christopher LILJENSTOLPE >> =E6=8A=84=E9=80=81: Thomas Narten; Russ White; dc@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [dc] Elevator Pitch >>=20 >>=20 >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Christopher LILJENSTOLPE = [mailto:cdl@asgaard.org] >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B412=E6=9C=8830=E6=97= =A5 1:20 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu >>> =E6=8A=84=E9=80=81: Thomas Narten; Russ White; dc@ietf.org >>> =E4=B8=BB=E9=A2=98: Re: [dc] Elevator Pitch >>>=20 >>> Greetings Xuxiaohu, >>>=20 >>> On 29Dec2011, at 00.55, Xuxiaohu wrote: >>>=20 >>>> Hi Thomas, >>>>=20 >>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: dc-bounces@ietf.org = [mailto:dc-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 >> Thomas >>>>> Narten >>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B412=E6=9C=8829=E6=97= =A5 1:01 >>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Russ White >>>>> =E6=8A=84=E9=80=81: dc@ietf.org >>>>> =E4=B8=BB=E9=A2=98: Re: [dc] Elevator Pitch >>>>>=20 >>>>>> 1. How many host routes do we reach before we say it "won't = scale?" If >>>>>> you're talking about leaf nodes in a routing protocol, 100k isn't = really >>>>>> that big of a deal. Where you do run into problems is between the >>>>>> routing and forwarding tables --but that's an area for thought. >>>>>=20 >>>>> Actually, 100K host routes in leaf nodes may well be a Big Deal. = It >>>>> depends on what type of devices need to understand host routes. >>>>>=20 >>>>> For the scenarios NVO3 is looking at, the edge device includes = edge >>>>> switches and hypervisors. Yes, such devices can in theory support = 100K >>>>> host routes (and the routing protocol needed to make that = converge) >>>>>=20 >>>>> But at a cost. >>>>>=20 >>>>> And I suspect the cost is too high. >>>>>=20 >>>>> Do you think data center operators will want to run routing = protocols >>>>> in hypervisors that have to handle 100K host routes? Especially if >>>>> such devices will need to be upgraded with better hardware to = support >>>>> such a load? >>>>=20 >>>> If they need to be upgraded with better hardware, why not directly = consider >>> the physical edge switches (e.g., ToR switches) as leaf nodes? >>>>=20 >>>> BTW, in the typical multi-tenant cloud data center environment = where most >>> of the tenants are believed to be SMBs, the route amount of any = given tenant >>> domain would not be too large. Hence, even there are more than 1M = host >>> routes in total, the route amount on any leaf node would not be too = large >> since >>> the tenant amount on any leaf node would not be too large. The = maximum >>> tenant amount on any leaf node is limited by at least the following = two >> factors: >>> 1) the port density of leave nodes; 2) the VM density of physical = servers. In >>> addition, in the case where the non-blocking DC fabric is not yet a = reality due >> to >>> its high cost, the VMs of a given tenant would be placed as close as = possible, >>> for example, being attached to a single leaf node if possible, so as = to reduce >> the >>> bandwidth consumption on the uplinks. In this way, the average = tenant >> amount >>> on a given leaf node would be even less. >>>=20 >>> There are folks who are looking at the ToR as the leaf node, and, in = my >> opinion, >>> any solution will probably be a hybrid of ToR and hypervisor. = However, >>> remember that the hypervisor switch is still the first aggregation = point, and >>> therefore, is the leaf in a network tree. Some level of state = aggregation >> (and >>> accompanying loss) will occur at the hypervisor switch, making it = the leaf. >>> Also, there are scaling issues with having 10's (or 100's in the = case of some >>> operators) vm's running on each server, and having 20-40 servers = running into >>> the ToR - all of a sudden, the host-table alone on the ToR becomes = mildly >>> interesting, even without other (intra-data center) routes on low = CAM ToR >>> switches. Not all solutions will map to all (or most) customers. >>>=20 >>> Also, the comment to limit the route-tabel of tenants due to small = numbers of >>> hosts may not always (or usually) match reality. What of the >>> cross-data-center traffic for other services either provided by the = hoster, or >>> other tenants? Continuing to route ALL of that traffic through >>> routing/switching nodes external to the "fabric" will lead to it's = own scaling >>> issues. Don't assume that the only routes that an SMB needs are = it's own. >>=20 >> Hi Chris, >>=20 >> Would you please give a concrete example where the communication = between >> different tenants is very common in the multi-tenant cloud data = center? >>=20 >> Best regards, >> Xiaohu >>=20 >>>>=20 >>>>=20 >>>>> Or will they want an alternative approach? >>>>>=20 >>>>>> 2. Why does this mobility need to be at layer 2 specifically? Are = we >>>>>> assuming DDNS and other sorts of solutions in this space will = simply >>>>>> never be fast enough/scale far enough/etc? >>>>>=20 >>>>> Like it or not, the key requirement for VM mobility is that the = VM's >>>>> IP address does not change. That means the VM can't really move = from >>>>> one IP subnet to another. That means either moving to bigger and >>>>> bigger L2s (all under one IP subnet) as the DC expands or the need = to >>>>> inject /32 host routes. >>>>=20 >>>> In the DCI scenario where the PE routers are usually performed at = the >>> aggregation SWs or even core SWs, the PE routers would need a much = large >>> forwarding table. Provided the routing table containing millions of = entries, >>> which is available on most today's high-end routers, was still not = large >> enough, >>> the on-demand FIB installation or on-demand route announcement >>> mechanisms can be used further to scale the solution. Note that the = trigger >> for >>> the FIB installation or route announcement is ARP request packets = rather >> than >>> data packets. Hence it will not cause the so-called initial packet = loss or >> latency >>> issue. >>>>=20 >>>>> Neither of those approaches seems particularly scalable/desirable = if >>>>> you look 10 years down the road and think of 1M+ physical machines = in >>>>> a DC. >>>>=20 >>>> Maybe we should also take the development speed of = routing/switching >> chip >>> and CPU technologies into account:) >>>=20 >>> It's more a question of cost/performance on off-chip memory/TCAMs. = That >> is >>> a slightly different curve :) >>>=20 >>> Chris >>>=20 >>>>=20 >>>> Best regards, >>>> Xiaohu >>>>=20 >>>>> Thomas >>>>>=20 >>>>> _______________________________________________ >>>>> dc mailing list >>>>> dc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dc >>>> _______________________________________________ >>>> dc mailing list >>>> dc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dc >>>=20 >>> -- >>> =E6=9D=8E=E6=9F=AF=E7=9D=BF >>> Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc >>> Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf >>=20 >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From russw@riw.us Sat Dec 31 05:27:44 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECCB21F8463 for ; Sat, 31 Dec 2011 05:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsLiIlM3RXlj for ; Sat, 31 Dec 2011 05:27:44 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id EA3B521F845F for ; Sat, 31 Dec 2011 05:27:43 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:57996 helo=[192.168.100.61]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RgyyI-0007qB-DT; Sat, 31 Dec 2011 08:27:38 -0500 Message-ID: <4EFF0DCA.5090707@riw.us> Date: Sat, 31 Dec 2011 08:27:38 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Christopher LILJENSTOLPE References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <4EFC826C.80708@riw.us> <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> In-Reply-To: <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 13:27:44 -0000 >> BTW, some folks would like to solve this problem by making the control >> plane react to the data plane --but this carries it's own baggage in >> complexity and in operational capabilities. Reactive control planes >> always converge more slowly, and waste bandwidth at a rate that's >> arguably higher than simple aggregation. So there's no "silver bullet" >> waiting in the wings in the form of caching at the control plane level. > > however, I believe that aggregation time may be coming down, especially in a more homogenous environment (like a DC) vs a heterogeneous environment (like the DFZ). Do you mean aggregation levels may be coming down? I would argue that aggregation is used to solve two problems: 1. Rate of state change. 2. Physical table size. Note that you don't need both everywhere. For instance, it doesn't cost much, in the way of hardware, to hold millions of routes in the control plane, nor to provide the processor to deal with those routes. If you can afford 150k servers with moderately good processors and the memory to go with them, then you can afford 15k network devices with moderately good processors and the memory to go with them. Where the cost is, is in the data plane, it seems --the forwarding table size. But we already know how to do aggregation (and even caching) between the control plane and the forwarding table. BTW, and aside on caching in the forwarding table. It appears to be a magic bullet for the problem of forwarding table size at first glance, but really it all depends on a lot of things... As long as the 80/20 rule holds, caching works at this level. The question is --when you reach 50/50, does caching still work? What about 40/60? Or 20/80? And how does caching fail? It always fails catastrophically. Cliffs are not good hidden away in unmonitored/not well understood pieces of the network. And of course when we try to cache at the control plane level in order to solve the forwarding table size problem, and when we try to mix cached control planes with data plane driven information, we are, IMHO, in "bad juju." Note also that the speed at which topology changes impact the convergence of the protocol, and the scope of those changes, can be controlled effectively separately from the rate of change in leaf nodes on the tree --so long as the protocol is designed to handle this sort of separation effectively. So if we break the problem down into its component parts, and define what we need from each component, we might be able to reach a reasonable solution that provides convergence and mobility. There will always be a tradeoff, but it should be up to the operator to make that ultimate tradeoff along the points where it's simply impossible for a protocol to go beyond. And to deal with the information hiding verses optimal bandwidth usage problem, of course. :-) >> Again, the same tradeoff as above --moving to a bigger l2 domain also >> means losing the ability to optimally direct traffic through the network >> (unless you put another control plane on top of the l2 and l3 control >> planes already in existence --which just adds the complexity you're >> trying to get away from in the host routes back into the network state!). > > Or replacing one or two of those L2/L3 control planes with a control plane with a global view, which is easier to do in a constrained network like a traffic engineering core or a data center. It's is a bounded problem. As you stated, however, convergence MAY be slower, but I would argue that converging a network of Nx10K switching/routing nodes takes a non-trivial amount of time as well :) I'm not certain I understand this... I think you mean like a DFZ, a control plane that knows every possible destination. But you have to separate knowing every possible destination from knowing every possible route to that destination. Even the DFZ in the 'net is really an aggregated suboptimal subset. I don't know of any network on this scale that has an optimal route to every destination, and I don't think it's really possible to build one unless you want to make processing power and control plane bandwidth usage unbounded. It's quite possible to know every destination as a host, but not know the entire path to every one of those destinations in detail (a form of fisheye routing, for instance). Aggregation is, in reality, just a form of fisheye routing --you know the path to the aggregation point in detail, but you don't know the path beyond that. The difference in aggregation at the reachability level is that you also don't know the actual state of the destinations hidden in the aggregate itself. To the degree that mobility isn't an issue, it's okay to tie topology to reachability in this way. When mobility becomes an issue, you need to unbundle the two in some way, treating detailed topology as one problem, and detailed reachability as another problem altogether. I'm guessing that unbundling these two is the most "logical" or "free and clear" path towards scaling for the requirements as they appear to exist. The issue of convergence presents another problem to think about... If convergence ends up being slower than the application timing out and searching for a new destination IP address, then why is switching IP addresses worse? The only way any of this makes sense is if it converges faster than a human would notice --and, increasingly, faster than a computer would notice. :-) Russ From adalela@cisco.com Sat Dec 31 06:33:19 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AF821F845A for ; Sat, 31 Dec 2011 06:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUQDIPTd36DZ for ; Sat, 31 Dec 2011 06:33:18 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id A5E7B21F8437 for ; Sat, 31 Dec 2011 06:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=9476; q=dns/txt; s=iport; t=1325341997; x=1326551597; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nDQTrxJ/V2XrV2G3ffZku131AoHaIvatyaBcyqALnZc=; b=O1/DqDMnjscfTrtOb1D1ZEFXgFOK/83aBo/IVyYfPj3XUEv1gHIGzHiq 9UV2vJaXcjwOTiRf3odz5LbJ31L9vXwH/a/2u8qrtrBDN3+OPH1ukf/61 nsbj54LtpSUhGdPRLXXDWrXuvfEKUNz52819xCMrt7Vouli4iyadKGSj3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAAoc/05Io8UY/2dsb2JhbABCARaEeZcJjzeCCoFyAQEBAwEBAQELBAEQDQQxAgcLBQcEAgEGAhEEAQEDAgYGCQIMAQICAgEBJR8JCAEBBAEKCAgTB4dYCJZSAYxbkHoEgS+HVwGBcjNjBIg1nwk X-IronPort-AV: E=Sophos;i="4.71,436,1320624000"; d="scan'208";a="2571780" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 31 Dec 2011 14:33:14 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBVEXExo026925; Sat, 31 Dec 2011 14:33:14 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Dec 2011 20:03:14 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 x-cr-hashedpuzzle: Az1A DbxB EmPK E+Qe GJBX ORGz QV3s SHRV TA/9 V/kV XPFo Xjhk ZYXi aSTX asKH cT/c; 3; YwBkAGwAQABhAHMAZwBhAGEAcgBkAC4AbwByAGcAOwBkAGMAQABpAGUAdABmAC4AbwByAGcAOwByAHUAcwBzAHcAQAByAGkAdwAuAHUAcwA=; Sosha1_v1; 7; {48148014-87B1-4BDA-B945-A0C0245D9843}; YQBkAGEAbABlAGwAYQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Sat, 31 Dec 2011 14:32:39 GMT; UgBFADoAIABbAGQAYwBdACAARQBsAGUAdgBhAHQAbwByACAAUABpAHQAYwBoAA== x-cr-puzzleid: {48148014-87B1-4BDA-B945-A0C0245D9843} Content-class: urn:content-classes:message Date: Sat, 31 Dec 2011 20:02:39 +0530 Message-ID: <618BE8B40039924EB9AED233D4A09C5102B2533C@XMB-BGL-416.cisco.com> In-Reply-To: <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dc] Elevator Pitch Thread-Index: AczGT2kn9NSOOaJESoGZbstWV4dKHgBeA+7g References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net><6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com><201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com><13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net><618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com><4EF7B019.3030202@riw.us><201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com><4EFC826C.80708@riw.us> <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> From: "Ashish Dalela (adalela)" To: "Christopher LILJENSTOLPE" , "Russ White" X-OriginalArrivalTime: 31 Dec 2011 14:33:14.0531 (UTC) FILETIME=[2124B730:01CCC7C9] Cc: dc@ietf.org Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 14:33:19 -0000 DQoxMDBLIG9yIHdoYXRldmVyIHRoYXQgbnVtYmVyIGlzLCBpcyBhIGJpZyBkZWFsIGF0IHRoZSBh Y2Nlc3MuIEFuZCB0aGF0IG51bWJlciB3aWxsIGluY3JlYXNlIHdpdGggdGltZS4gVGhlIHRoaW5n IHRvIGJlYXIgaW4gbWluZCBpcyB0aGF0IHRoZXNlIGFyZSBBRERJVElPTkFMIGVudHJpZXMsIG5v dCBpbiBsaWV1IG9mIG90aGVyIGVudHJpZXMuIEUuZy4gbmV0d29yayByb3V0ZXMsIGxvY2FsIGhv c3QtcG9ydCBlbnRyaWVzLCBBQ0xzIGV0YyBleGlzdCB0b2RheSBhbmQgd2lsbCBjb250aW51ZSB0 byBleGlzdC4gSG9zdCByb3V0ZXMgYXJlIGluIGFkZGl0aW9uIHRvIHRoYXQuIEFjY2VzcyBzd2l0 Y2hlcyBnZW5lcmFsbHkgaGFkIGFib3V0IDE2SyBvciAzMksgdGFibGUgc2l6ZXMuIEFuZCB3ZSBh cmUgdGFsa2luZyBhYm91dCBhZGRpbmcgMy00IHRpbWVzIG1vcmUgdG8gdGhhdC4NCg0KVGhlIG90 aGVyIHRoaW5nIGlzIHRoYXQgYWNjZXNzIHRvIGNvcmUgcmF0aW8gaXMgYWJvdXQgMTAwMDoxLiBT bywgd2UgbmVlZCB0byBtdWx0aXBseSB0aGUgaW5jcmVtZW50YWwgY29zdHMgYnkgMTAwMCB0byBn ZXQgdGhlIGZ1bGwgaW1wYWN0IHRvIFRDTy4NCg0KSW4gcmVnYXJkIHRvIHNjYWxpbmcsIHRoZXJl IGFyZSA0IHBsYWNlcyB0byBsb29rIGF0Og0KDQoxLiBBY2Nlc3MNCjIuIENvcmUNCjMuIEludGVy LWRhdGFjZW50ZXINCjQuIERhdGFjZW50ZXItaW50ZXJuZXQNCg0KVGhlc2UgaGF2ZSBkaWZmZXJl bnQgc2NhbGluZyBwcm9wZXJ0aWVzLiANCg0KSWYgeW91IGhhdmUgZGlmZmVyZW50IERDIGFuZCBE Q0kgdGVjaG5vbG9naWVzLCBhbmQgeW91IHVzZSBFbmNhcCwgeW91IGhhdmUgaGlnaCBlbnRyaWVz IGF0IEFjY2VzcywgRENJIGFuZCBEYXRhY2VudGVyLUludGVybmV0LiANCg0KSWYgeW91IGhhdmUg Y29tbW9uIERDIGFuZCBEQ0kgdGVjaG5vbG9naWVzLCB5b3UgaGF2ZSBoaWdoIEFjY2VzcyBhbmQg RGF0YWNlbnRlci1JbnRlcm5ldCBlbnRyaWVzLg0KDQpJZiB5b3UgaGF2ZSBoaWVyYXJjaGljYWwg TUFDLCB0aGVuIHlvdSBoYXZlIG9ubHkgaGlnaCBpbiBEYXRhY2VudGVyLUludGVybmV0IGJvdW5k YXJ5LiANCg0KTmV0LW5ldCwgb3V0IG9mIHRoZSA0IHRoaW5ncyBhYm92ZSwgeW91IGNhbiBzb2x2 ZSAzIChmaXJzdCAzKS4gVGhlIGZvdXJ0aCB3ZSBoYXZlIHRvIGRpc3RyaWJ1dGUgb3ZlciBtdWx0 aXBsZSByb3V0ZXJzLCB3aGljaCBpcyBub3QgaGFyZCBiZWNhdXNlIGl0IGlzIGFsd2F5cyBub3J0 aC1zb3V0aCB0cmFmZmljLiANCg0KVGhhbmtzLCBBc2hpc2gNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogZGMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRjLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RvcGhlciBMSUxKRU5TVE9MUEUNClNlbnQ6IFRo dXJzZGF5LCBEZWNlbWJlciAyOSwgMjAxMSAxMDo1OCBQTQ0KVG86IFJ1c3MgV2hpdGUNCkNjOiBk Y0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkY10gRWxldmF0b3IgUGl0Y2gNCg0KR3JlZXRpbmdz IFJ1c3MgZXQuYWwuLA0KDQpPbiAyOURlYzIwMTEsIGF0IDA3LjA4LCBSdXNzIFdoaXRlIHdyb3Rl Og0KDQo+IA0KPj4gQWN0dWFsbHksIDEwMEsgaG9zdCByb3V0ZXMgaW4gbGVhZiBub2RlcyBtYXkg d2VsbCBiZSBhIEJpZyBEZWFsLiBJdA0KPj4gZGVwZW5kcyBvbiB3aGF0IHR5cGUgb2YgZGV2aWNl cyBuZWVkIHRvIHVuZGVyc3RhbmQgaG9zdCByb3V0ZXMuDQo+IA0KPiBTbyBsZXQgbWUgdHJ5IHRv IGFic3RyYWN0IHRoZSBwcm9ibGVtIGEgbGl0dGxlLi4uIFRoZXJlIGFyZSB0d28gdGhpbmdzDQo+ IHRoYXQgY29zdCBtb25leSBpbiBidWlsZGluZyBhIG5ldHdvcms6DQo+IA0KPiAxLiBTdGF0ZSAt LXRoZSBtb3JlIHlvdSBjYXJyeSwgdGhlIG1vcmUgaGFyZHdhcmUgaXMgZ29pbmcgdG8gY29zdC4N Cj4gMi4gQmFuZHdpZHRoIC0tdGhlIGxlc3Mgb3B0aW1hbCB5b3VyIGJhbmR3aWR0aCB1dGlsaXph dGlvbiwgdGhlIG1vcmUNCj4geW91J3JlIHNwZW5kaW5nIG9uIHNvbWV0aGluZyB0aGF0J3Mgbm90 IHVzZWQuDQo+IA0KPiBUaGUgZmlyc3QgcnVsZSBvZiBhbGwgbmV0d29yayBkZXNpZ24gaXMgdGhh dCB0aGUgbW9yZSBzdGF0ZSB5b3UgcHV0IGluIGENCj4gbmV0d29yaywgdGhlIG1vcmUgb3B0aW1h bCB5b3VyIGJhbmR3aWR0aCB1c2FnZS4gVG8gcmVkdWNlIHRoZSBjb3N0IG9mDQo+IGJhbmR3aWR0 aCwgeW91IGhhdmUgdG8gc3BlbmQgbW9uZXkgb24gc3RhdGUuIFRvIHJlZHVjZSB0aGUgY29zdCBv Zg0KPiBzdGF0ZSwgeW91IG11c3QgaW5jcmVhc2UgeW91ciBzcGVuZGluZyBvbiBiYW5kd2lkdGgu DQoNCkFncmVlZCwgbW9zdGx5LiAgVGhlIHF1ZXN0aW9uIGlzIHdoZXJlIHRoZSBzdGF0ZSByZXNp ZGVzLCBjb250cm9sIHBsYW5lIG9yIGRhdGEgcGxhbmUgKGRvIHlvdSBkaWZmZXJlbnRpYXRlIGJl dHdlZW4gcG9zc2libGUgc3RhdGUgYW5kIGFjdGl2ZSBzdGF0ZSkuICBDb250cm9sIHBsYW5lICJw b3NzaWJsZSBzdGF0ZSIgc2hvdWxkIGJlIGNoZWFwZXIgKGJ5IG9yZGVycyBvZiBtYWduaXR1ZGUp IHRoYW4gZGF0YSBwbGFuZSAiYWN0aXZlIHN0YXRlIiAtIGhvd2V2ZXIsIHRyYW5zaXRpb25pbmcg YmV0d2VlbiB0aGUgdHdvIGlzIGEgY29tcGxleCBwcm9ibGVtICh0aGF0IGhhcyBnb3R0ZW4gc29t ZXdoYXQgZWFzaWVyIGFzIHdlIGhhdmUgZ290dGVuIHNtYXJ0ZXIgYWJvdXQgZGlzdHJpYnV0ZWQg c3lzdGVtcyBvdmVyIHRpbWUpDQo+IA0KPiBUaGUgc2Vjb25kIG9mIG5ldHdvcmsgZGVzaWduIGlz IHRoZSBiYWxhbmNlIHBvaW50IHdoZXJlIHRoZSBuZXR3b3JrIGlzDQo+IGNoZWFwZXN0IGlzIGRp ZmZlcmVudCBpbiBldmVyeSBuZXR3b3JrLg0KDQphZ3JlZWQNCg0KPiANCj4gU28sIElNSE8sIHRo ZSBwb2ludCBvZiBwcm90b2NvbCBkZXNpZ24gc2hvdWxkIGJlIHRvIGFsbG93IHRoZSBkZXNpZ24g dGhlDQo+IG1heGltdW0gYW1vdW50IG9mIGZsZXhpYmlsaXR5IGFuZCBncmFudWxhcml0eSBpbiB3 aGVuIGFuZCB3aGVyZSB0byBoaWRlDQo+IGluZm9ybWF0aW9uLCB0byBtYWtlIHRoZSByaWdodCB0 cmFkZW9mZiBmb3IgYW55IHBhcnRpY3VsYXIgbmV0d29yay4NCj4gDQphZ3JlZWQNCg0KPiBOb3cs IHRvIHJldHVybiB0byB0aGUgZGlzY3Vzc2lvbiBhdCBoYW5kOiBJZiB5b3UgZG9uJ3Qgd2FudCB0 byBwYXkgZm9yDQo+IGRldmljZXMgdGhhdCB3aWxsIGhhbmRsZSAxMDAgbWlsbGlvbiByb3V0ZXMs IGJ1dCB5b3UgaGF2ZSAxMDAgbWlsbGlvbg0KPiBkZXZpY2VzLCB0aGVuIHlvdSdyZSBnb2luZyB0 byBoYXZlIHNvbWUgZGVncmVlIG9mIHN1Ym9wdGltYWwgYmFuZHdpZHRoDQo+IHV0aWxpemF0aW9u LiBUaGVyZSdzIHNpbXBseSBubyB3YXkgYXJvdW5kIHRoaXMgcmVhbGl0eS4NCg0KYWdyZWVkDQo+ IA0KPiBJTUhPLCBob3dldmVyIHdlIHJlc29sdmUgdGhpcyBwcm9ibGVtLCB3ZSBuZWVkIHRvIHJl c29sdmUgaXQgaW4gYSB3YXkNCj4gdGhhdCBhbGxvd3MgYW4gb3BlcmF0b3IgdG8gc3VwcG9ydCAx MDAgbWlsbGlvbiByb3V0ZXMgaW4gZXZlcnkgbm9kZSwgaWYNCj4gdGhleSBjaG9vc2UgdG8gb3B0 aW1pemUgZm9yIGJhbmR3aWR0aCBhdCB0aGUgY29zdCBvZiBoYXJkd2FyZS4gT3IgdG8NCj4gc3Vw cG9ydCAxIHJvdXRlIGluIGV2ZXJ5IG5vZGUgdXNpbmcgcmVhbGx5IGNoZWFwIGhhcmR3YXJlLCBp ZiB0aGV5IHdhbnQNCj4gdG8gb3B0aW1pemUgZm9yIHN0YXRlLiBPciBmb3IgYW55IHBvaW50IGlu IHRoZSBzbGlkaW5nIHNjYWxlIGluIGJldHdlZW4NCj4gKHdpdGhpbiByZWFzb24pLg0KDQphZ3Jl ZWQNCg0KPiANCj4gU28gdGhpcyBjb250cm9sIHBsYW5lIG5lZWRzIHRvOg0KPiANCj4gMS4gQmUg YWJsZSB0byBzdXBwb3J0IDEwMCBtaWxsaW9uIGRlc3RpbmF0aW9ucyBhdCB0aGUgaG9zdCBsZXZl bCAodGhhdA0KPiBkb2Vzbid0IG1lYW4gMTAwIG1pbGxpb24gcGF0aHMsIGJ1dCBvbmx5IDEwMCBt aWxsaW9uIGRlc3RpbmF0aW9ucyAtLXR3bw0KPiBkaWZmZXJlbnQgcHJvYmxlbXMpLg0KDQp5ZXMN Cg0KPiANCj4gMi4gQmUgYWJsZSB0byBhZ2dyZWdhdGUgdG8gaGlkZSBpbmZvcm1hdGlvbiBhdCBh bnlwbGFjZSB0aGF0J3MgbG9naWNhbA0KPiB3aXRoaW4gdGhlIG5ldHdvcmsuDQoNCnllcw0KDQo+ IA0KPiBCVFcsIHNvbWUgZm9sa3Mgd291bGQgbGlrZSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gYnkg bWFraW5nIHRoZSBjb250cm9sDQo+IHBsYW5lIHJlYWN0IHRvIHRoZSBkYXRhIHBsYW5lIC0tYnV0 IHRoaXMgY2FycmllcyBpdCdzIG93biBiYWdnYWdlIGluDQo+IGNvbXBsZXhpdHkgYW5kIGluIG9w ZXJhdGlvbmFsIGNhcGFiaWxpdGllcy4gUmVhY3RpdmUgY29udHJvbCBwbGFuZXMNCj4gYWx3YXlz IGNvbnZlcmdlIG1vcmUgc2xvd2x5LCBhbmQgd2FzdGUgYmFuZHdpZHRoIGF0IGEgcmF0ZSB0aGF0 J3MNCj4gYXJndWFibHkgaGlnaGVyIHRoYW4gc2ltcGxlIGFnZ3JlZ2F0aW9uLiBTbyB0aGVyZSdz IG5vICJzaWx2ZXIgYnVsbGV0Ig0KPiB3YWl0aW5nIGluIHRoZSB3aW5ncyBpbiB0aGUgZm9ybSBv ZiBjYWNoaW5nIGF0IHRoZSBjb250cm9sIHBsYW5lIGxldmVsLg0KDQpob3dldmVyLCBJIGJlbGll dmUgdGhhdCBhZ2dyZWdhdGlvbiB0aW1lIG1heSBiZSBjb21pbmcgZG93biwgZXNwZWNpYWxseSBp biBhIG1vcmUgaG9tb2dlbm91cyBlbnZpcm9ubWVudCAobGlrZSBhIERDKSB2cyBhIGhldGVyb2dl bmVvdXMgZW52aXJvbm1lbnQgKGxpa2UgdGhlIERGWikuDQoNCj4gDQo+Pj4gMi4gV2h5IGRvZXMg dGhpcyBtb2JpbGl0eSBuZWVkIHRvIGJlIGF0IGxheWVyIDIgc3BlY2lmaWNhbGx5PyBBcmUgd2UN Cj4+PiBhc3N1bWluZyBERE5TIGFuZCBvdGhlciBzb3J0cyBvZiBzb2x1dGlvbnMgaW4gdGhpcyBz cGFjZSB3aWxsIHNpbXBseQ0KPj4+IG5ldmVyIGJlIGZhc3QgZW5vdWdoL3NjYWxlIGZhciBlbm91 Z2gvZXRjPw0KPj4gDQo+PiBMaWtlIGl0IG9yIG5vdCwgdGhlIGtleSByZXF1aXJlbWVudCBmb3Ig Vk0gbW9iaWxpdHkgaXMgdGhhdCB0aGUgVk0ncw0KPj4gSVAgYWRkcmVzcyBkb2VzIG5vdCBjaGFu Z2UuIFRoYXQgbWVhbnMgdGhlIFZNIGNhbid0IHJlYWxseSBtb3ZlIGZyb20NCj4+IG9uZSBJUCBz dWJuZXQgdG8gYW5vdGhlci4gVGhhdCBtZWFucyBlaXRoZXIgbW92aW5nIHRvIGJpZ2dlciBhbmQN Cj4+IGJpZ2dlciBMMnMgKGFsbCB1bmRlciBvbmUgSVAgc3VibmV0KSBhcyB0aGUgREMgZXhwYW5k cyBvciB0aGUgbmVlZCB0bw0KPj4gaW5qZWN0IC8zMiBob3N0IHJvdXRlcy4NCj4gDQo+IEFnYWlu LCB0aGUgc2FtZSB0cmFkZW9mZiBhcyBhYm92ZSAtLW1vdmluZyB0byBhIGJpZ2dlciBsMiBkb21h aW4gYWxzbw0KPiBtZWFucyBsb3NpbmcgdGhlIGFiaWxpdHkgdG8gb3B0aW1hbGx5IGRpcmVjdCB0 cmFmZmljIHRocm91Z2ggdGhlIG5ldHdvcmsNCj4gKHVubGVzcyB5b3UgcHV0IGFub3RoZXIgY29u dHJvbCBwbGFuZSBvbiB0b3Agb2YgdGhlIGwyIGFuZCBsMyBjb250cm9sDQo+IHBsYW5lcyBhbHJl YWR5IGluIGV4aXN0ZW5jZSAtLXdoaWNoIGp1c3QgYWRkcyB0aGUgY29tcGxleGl0eSB5b3UncmUN Cj4gdHJ5aW5nIHRvIGdldCBhd2F5IGZyb20gaW4gdGhlIGhvc3Qgcm91dGVzIGJhY2sgaW50byB0 aGUgbmV0d29yayBzdGF0ZSEpLg0KDQpPciByZXBsYWNpbmcgb25lIG9yIHR3byBvZiB0aG9zZSBM Mi9MMyBjb250cm9sIHBsYW5lcyB3aXRoIGEgY29udHJvbCBwbGFuZSB3aXRoIGEgZ2xvYmFsIHZp ZXcsIHdoaWNoIGlzIGVhc2llciB0byBkbyBpbiBhIGNvbnN0cmFpbmVkIG5ldHdvcmsgbGlrZSBh IHRyYWZmaWMgZW5naW5lZXJpbmcgY29yZSBvciBhIGRhdGEgY2VudGVyLiAgSXQncyBpcyBhIGJv dW5kZWQgcHJvYmxlbS4gIEFzIHlvdSBzdGF0ZWQsIGhvd2V2ZXIsIGNvbnZlcmdlbmNlIE1BWSBi ZSBzbG93ZXIsIGJ1dCBJIHdvdWxkIGFyZ3VlIHRoYXQgY29udmVyZ2luZyBhIG5ldHdvcmsgb2Yg TngxMEsgc3dpdGNoaW5nL3JvdXRpbmcgbm9kZXMgdGFrZXMgYSBub24tdHJpdmlhbCBhbW91bnQg b2YgdGltZSBhcyB3ZWxsIDopDQoNCj4gDQo+PiBOZWl0aGVyIG9mIHRob3NlIGFwcHJvYWNoZXMg c2VlbXMgcGFydGljdWxhcmx5IHNjYWxhYmxlL2Rlc2lyYWJsZSBpZg0KPj4geW91IGxvb2sgMTAg eWVhcnMgZG93biB0aGUgcm9hZCBhbmQgdGhpbmsgb2YgMU0rIHBoeXNpY2FsIG1hY2hpbmVzIGlu DQo+PiBhIERDLg0KPiANCj4gVGhlcmUgaXMgbm8gInBhcnRpY3VsYXJseSBkZXNpcmFibGUiIHNv bHV0aW9uLCBpbiByZWFsaXR5LCBiZWNhdXNlDQo+IGJ1aWxkaW5nIGEgbmV0d29yayB3aXRoIG5v IGNvbnRyb2wgcGxhbmUgc3RhdGUgYW55cGxhY2UgdGhhdCB1c2VzDQo+IGJhbmR3aWR0aCBpbiBh IHBlcmZlY3RseSBvcHRpbWFsIHdheSBpcyBzaW1wbHkgaW1wb3NzaWJsZSBubyBtYXR0ZXIgaG93 DQo+IHlvdSBzbGljZSBpdCAodW5sZXNzIHlvdSdyZSBnb2luZyB0byBnbyBpbnRvIHF1YW50dW0g cm91dGluZyEpLg0KPiANCj4gOi0pDQo+IA0KPiBSdXNzDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRjIG1haWxpbmcgbGlzdA0KPiBkY0BpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RjDQoNCi0tICAN Cuadjuafr+edvw0KQ2hlY2sgbXkgUEdQIGtleSBoZXJlOiBodHRwczovL3d3dy5hc2dhYXJkLm9y Zy9+Y2RsL2NkbC5hc2MNCkN1cnJlbnQgdkNhcmQgaGVyZTogaHR0cHM6Ly93d3cuYXNnYWFyZC5v cmcvfmNkbC9jZGwudmNmDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpkYyBtYWlsaW5nIGxpc3QNCmRjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RjDQo= From ccie15672@gmail.com Sat Dec 31 06:42:15 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4978621F843D for ; Sat, 31 Dec 2011 06:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqjmJAj6epxF for ; Sat, 31 Dec 2011 06:42:14 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0321F843C for ; Sat, 31 Dec 2011 06:42:14 -0800 (PST) Received: by obcuz6 with SMTP id uz6so12455150obc.31 for ; Sat, 31 Dec 2011 06:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cRjbb2GD1KklM8dgck5JaKqoO2HoyxT6sm4aHcxR6mw=; b=c6nItpi222kbPTRb4UCjQW2vTFdolHE4Sue68H2d29C1H/wfO91VgEBQX8x4qNZDRP K3OosnhJgXp7IqoTnNSCIXrVD3TnHDk0l0GBJwWZYXS0wwILndR69kpxHZ2QRay92Kg6 qTj2Rya6sVWDA/QgGFp6TVKq3sf9CZ5Jr4y+k= MIME-Version: 1.0 Received: by 10.182.49.66 with SMTP id s2mr36906720obn.58.1325342532323; Sat, 31 Dec 2011 06:42:12 -0800 (PST) Received: by 10.182.171.101 with HTTP; Sat, 31 Dec 2011 06:42:12 -0800 (PST) In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102B2533C@XMB-BGL-416.cisco.com> References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <4EFC826C.80708@riw.us> <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> <618BE8B40039924EB9AED233D4A09C5102B2533C@XMB-BGL-416.cisco.com> Date: Sat, 31 Dec 2011 08:42:12 -0600 Message-ID: From: Derick Winkworth To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Russ White , dc@ietf.org, Christopher LILJENSTOLPE Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 14:42:15 -0000 100,000 VMs is how many physical servers? At some point you have to eat the cost of putting the right gear in. You can't drive down to Best Buy to buy your switches if you think you'll have 100k host route entries (or MAC addresses) in your access switches. Russ is right, there are multiple platforms/vendors now supporting millions of routes/MAC addresses. Maybe what you thought of as a distribution or core device is now and end-of-row "access" device? Which kind of leads me to a point I wanted to make with regard to some of the lists of "requirements" I've seen. Some of these things should be considered a network design problem, not an IETF protocol problem. Specifically, I'm thinking of hyperscale requirements... On Sat, Dec 31, 2011 at 8:32 AM, Ashish Dalela (adalela) wrote: > > 100K or whatever that number is, is a big deal at the access. And that nu= mber will increase with time. The thing to bear in mind is that these are A= DDITIONAL entries, not in lieu of other entries. E.g. network routes, local= host-port entries, ACLs etc exist today and will continue to exist. Host r= outes are in addition to that. Access switches generally had about 16K or 3= 2K table sizes. And we are talking about adding 3-4 times more to that. > > The other thing is that access to core ratio is about 1000:1. So, we need= to multiply the incremental costs by 1000 to get the full impact to TCO. > > In regard to scaling, there are 4 places to look at: > > 1. Access > 2. Core > 3. Inter-datacenter > 4. Datacenter-internet > > These have different scaling properties. > > If you have different DC and DCI technologies, and you use Encap, you hav= e high entries at Access, DCI and Datacenter-Internet. > > If you have common DC and DCI technologies, you have high Access and Data= center-Internet entries. > > If you have hierarchical MAC, then you have only high in Datacenter-Inter= net boundary. > > Net-net, out of the 4 things above, you can solve 3 (first 3). The fourth= we have to distribute over multiple routers, which is not hard because it = is always north-south traffic. > > Thanks, Ashish > > > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Chris= topher LILJENSTOLPE > Sent: Thursday, December 29, 2011 10:58 PM > To: Russ White > Cc: dc@ietf.org > Subject: Re: [dc] Elevator Pitch > > Greetings Russ et.al., > > On 29Dec2011, at 07.08, Russ White wrote: > >> >>> Actually, 100K host routes in leaf nodes may well be a Big Deal. It >>> depends on what type of devices need to understand host routes. >> >> So let me try to abstract the problem a little... There are two things >> that cost money in building a network: >> >> 1. State --the more you carry, the more hardware is going to cost. >> 2. Bandwidth --the less optimal your bandwidth utilization, the more >> you're spending on something that's not used. >> >> The first rule of all network design is that the more state you put in a >> network, the more optimal your bandwidth usage. To reduce the cost of >> bandwidth, you have to spend money on state. To reduce the cost of >> state, you must increase your spending on bandwidth. > > Agreed, mostly. =C2=A0The question is where the state resides, control pl= ane or data plane (do you differentiate between possible state and active s= tate). =C2=A0Control plane "possible state" should be cheaper (by orders of= magnitude) than data plane "active state" - however, transitioning between= the two is a complex problem (that has gotten somewhat easier as we have g= otten smarter about distributed systems over time) >> >> The second of network design is the balance point where the network is >> cheapest is different in every network. > > agreed > >> >> So, IMHO, the point of protocol design should be to allow the design the >> maximum amount of flexibility and granularity in when and where to hide >> information, to make the right tradeoff for any particular network. >> > agreed > >> Now, to return to the discussion at hand: If you don't want to pay for >> devices that will handle 100 million routes, but you have 100 million >> devices, then you're going to have some degree of suboptimal bandwidth >> utilization. There's simply no way around this reality. > > agreed >> >> IMHO, however we resolve this problem, we need to resolve it in a way >> that allows an operator to support 100 million routes in every node, if >> they choose to optimize for bandwidth at the cost of hardware. Or to >> support 1 route in every node using really cheap hardware, if they want >> to optimize for state. Or for any point in the sliding scale in between >> (within reason). > > agreed > >> >> So this control plane needs to: >> >> 1. Be able to support 100 million destinations at the host level (that >> doesn't mean 100 million paths, but only 100 million destinations --two >> different problems). > > yes > >> >> 2. Be able to aggregate to hide information at anyplace that's logical >> within the network. > > yes > >> >> BTW, some folks would like to solve this problem by making the control >> plane react to the data plane --but this carries it's own baggage in >> complexity and in operational capabilities. Reactive control planes >> always converge more slowly, and waste bandwidth at a rate that's >> arguably higher than simple aggregation. So there's no "silver bullet" >> waiting in the wings in the form of caching at the control plane level. > > however, I believe that aggregation time may be coming down, especially i= n a more homogenous environment (like a DC) vs a heterogeneous environment = (like the DFZ). > >> >>>> 2. Why does this mobility need to be at layer 2 specifically? Are we >>>> assuming DDNS and other sorts of solutions in this space will simply >>>> never be fast enough/scale far enough/etc? >>> >>> Like it or not, the key requirement for VM mobility is that the VM's >>> IP address does not change. That means the VM can't really move from >>> one IP subnet to another. That means either moving to bigger and >>> bigger L2s (all under one IP subnet) as the DC expands or the need to >>> inject /32 host routes. >> >> Again, the same tradeoff as above --moving to a bigger l2 domain also >> means losing the ability to optimally direct traffic through the network >> (unless you put another control plane on top of the l2 and l3 control >> planes already in existence --which just adds the complexity you're >> trying to get away from in the host routes back into the network state!)= . > > Or replacing one or two of those L2/L3 control planes with a control plan= e with a global view, which is easier to do in a constrained network like a= traffic engineering core or a data center. =C2=A0It's is a bounded problem= . =C2=A0As you stated, however, convergence MAY be slower, but I would argu= e that converging a network of Nx10K switching/routing nodes takes a non-tr= ivial amount of time as well :) > >> >>> Neither of those approaches seems particularly scalable/desirable if >>> you look 10 years down the road and think of 1M+ physical machines in >>> a DC. >> >> There is no "particularly desirable" solution, in reality, because >> building a network with no control plane state anyplace that uses >> bandwidth in a perfectly optimal way is simply impossible no matter how >> you slice it (unless you're going to go into quantum routing!). >> >> :-) >> >> Russ >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > > -- > =E6=9D=8E=E6=9F=AF=E7=9D=BF > Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc > Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf > > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From joelja@bogus.com Sat Dec 31 16:38:45 2011 Return-Path: X-Original-To: dc@ietfa.amsl.com Delivered-To: dc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878B321F84A2 for ; Sat, 31 Dec 2011 16:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS0d9khZ7Tie for ; Sat, 31 Dec 2011 16:38:44 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8204821F849E for ; Sat, 31 Dec 2011 16:38:44 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-76-115-174-157.hsd1.wa.comcast.net [76.115.174.157]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q010ccke029334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 1 Jan 2012 00:38:38 GMT (envelope-from joelja@bogus.com) Message-ID: <4EFFAB08.3000608@bogus.com> Date: Sat, 31 Dec 2011 16:38:32 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Derick Winkworth References: <13205C286662DE4387D9AF3AC30EF456D74E7BD952@EMBX01-WF.jnpr.net> <6665BC1FEA04AB47B1F75FA641C43BC0926D106C@FHDP1LUMXC7V41.us.one.verizon.com> <201112211830.pBLIUiZA017188@cichlid.raleigh.ibm.com> <13205C286662DE4387D9AF3AC30EF456D74E91DBFD@EMBX01-WF.jnpr.net> <618BE8B40039924EB9AED233D4A09C5102A4881E@XMB-BGL-416.cisco.com> <4EF7B019.3030202@riw.us> <201112281700.pBSH0kB2011575@cichlid.raleigh.ibm.com> <4EFC826C.80708@riw.us> <682C5C0D-10FD-49D7-BF48-28EB6EFBA72B@asgaard.org> <618BE8B40039924EB9AED233D4A09C5102B2533C@XMB-BGL-416.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 01 Jan 2012 00:38:40 +0000 (UTC) Cc: Russ White , "Ashish Dalela \(adalela\)" , dc@ietf.org, Christopher LILJENSTOLPE Subject: Re: [dc] Elevator Pitch X-BeenThere: dc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Data Center Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 00:38:45 -0000 On 12/31/11 06:42 , Derick Winkworth wrote: > 100,000 VMs is how many physical servers? At some point you have to > eat the cost of putting the right gear in. You can't drive down to > Best Buy to buy your switches if you think you'll have 100k host route > entries (or MAC addresses) in your access switches. As a DC operator I have no interest in having 1m 100k or even 10k routes in a tor... > Russ is right, there are multiple platforms/vendors now supporting > millions of routes/MAC addresses. Maybe what you thought of as a > distribution or core device is now and end-of-row "access" device? > > Which kind of leads me to a point I wanted to make with regard to some > of the lists of "requirements" I've seen. Some of these things should > be considered a network design problem, not an IETF protocol problem. > Specifically, I'm thinking of hyperscale requirements... > > > > On Sat, Dec 31, 2011 at 8:32 AM, Ashish Dalela (adalela) > wrote: >> >> 100K or whatever that number is, is a big deal at the access. And that number will increase with time. The thing to bear in mind is that these are ADDITIONAL entries, not in lieu of other entries. E.g. network routes, local host-port entries, ACLs etc exist today and will continue to exist. Host routes are in addition to that. Access switches generally had about 16K or 32K table sizes. And we are talking about adding 3-4 times more to that. >> >> The other thing is that access to core ratio is about 1000:1. So, we need to multiply the incremental costs by 1000 to get the full impact to TCO. >> >> In regard to scaling, there are 4 places to look at: >> >> 1. Access >> 2. Core >> 3. Inter-datacenter >> 4. Datacenter-internet >> >> These have different scaling properties. >> >> If you have different DC and DCI technologies, and you use Encap, you have high entries at Access, DCI and Datacenter-Internet. >> >> If you have common DC and DCI technologies, you have high Access and Datacenter-Internet entries. >> >> If you have hierarchical MAC, then you have only high in Datacenter-Internet boundary. >> >> Net-net, out of the 4 things above, you can solve 3 (first 3). The fourth we have to distribute over multiple routers, which is not hard because it is always north-south traffic. >> >> Thanks, Ashish >> >> >> -----Original Message----- >> From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Christopher LILJENSTOLPE >> Sent: Thursday, December 29, 2011 10:58 PM >> To: Russ White >> Cc: dc@ietf.org >> Subject: Re: [dc] Elevator Pitch >> >> Greetings Russ et.al., >> >> On 29Dec2011, at 07.08, Russ White wrote: >> >>> >>>> Actually, 100K host routes in leaf nodes may well be a Big Deal. It >>>> depends on what type of devices need to understand host routes. >>> >>> So let me try to abstract the problem a little... There are two things >>> that cost money in building a network: >>> >>> 1. State --the more you carry, the more hardware is going to cost. >>> 2. Bandwidth --the less optimal your bandwidth utilization, the more >>> you're spending on something that's not used. >>> >>> The first rule of all network design is that the more state you put in a >>> network, the more optimal your bandwidth usage. To reduce the cost of >>> bandwidth, you have to spend money on state. To reduce the cost of >>> state, you must increase your spending on bandwidth. >> >> Agreed, mostly. The question is where the state resides, control plane or data plane (do you differentiate between possible state and active state). Control plane "possible state" should be cheaper (by orders of magnitude) than data plane "active state" - however, transitioning between the two is a complex problem (that has gotten somewhat easier as we have gotten smarter about distributed systems over time) >>> >>> The second of network design is the balance point where the network is >>> cheapest is different in every network. >> >> agreed >> >>> >>> So, IMHO, the point of protocol design should be to allow the design the >>> maximum amount of flexibility and granularity in when and where to hide >>> information, to make the right tradeoff for any particular network. >>> >> agreed >> >>> Now, to return to the discussion at hand: If you don't want to pay for >>> devices that will handle 100 million routes, but you have 100 million >>> devices, then you're going to have some degree of suboptimal bandwidth >>> utilization. There's simply no way around this reality. >> >> agreed >>> >>> IMHO, however we resolve this problem, we need to resolve it in a way >>> that allows an operator to support 100 million routes in every node, if >>> they choose to optimize for bandwidth at the cost of hardware. Or to >>> support 1 route in every node using really cheap hardware, if they want >>> to optimize for state. Or for any point in the sliding scale in between >>> (within reason). >> >> agreed >> >>> >>> So this control plane needs to: >>> >>> 1. Be able to support 100 million destinations at the host level (that >>> doesn't mean 100 million paths, but only 100 million destinations --two >>> different problems). >> >> yes >> >>> >>> 2. Be able to aggregate to hide information at anyplace that's logical >>> within the network. >> >> yes >> >>> >>> BTW, some folks would like to solve this problem by making the control >>> plane react to the data plane --but this carries it's own baggage in >>> complexity and in operational capabilities. Reactive control planes >>> always converge more slowly, and waste bandwidth at a rate that's >>> arguably higher than simple aggregation. So there's no "silver bullet" >>> waiting in the wings in the form of caching at the control plane level. >> >> however, I believe that aggregation time may be coming down, especially in a more homogenous environment (like a DC) vs a heterogeneous environment (like the DFZ). >> >>> >>>>> 2. Why does this mobility need to be at layer 2 specifically? Are we >>>>> assuming DDNS and other sorts of solutions in this space will simply >>>>> never be fast enough/scale far enough/etc? >>>> >>>> Like it or not, the key requirement for VM mobility is that the VM's >>>> IP address does not change. That means the VM can't really move from >>>> one IP subnet to another. That means either moving to bigger and >>>> bigger L2s (all under one IP subnet) as the DC expands or the need to >>>> inject /32 host routes. >>> >>> Again, the same tradeoff as above --moving to a bigger l2 domain also >>> means losing the ability to optimally direct traffic through the network >>> (unless you put another control plane on top of the l2 and l3 control >>> planes already in existence --which just adds the complexity you're >>> trying to get away from in the host routes back into the network state!). >> >> Or replacing one or two of those L2/L3 control planes with a control plane with a global view, which is easier to do in a constrained network like a traffic engineering core or a data center. It's is a bounded problem. As you stated, however, convergence MAY be slower, but I would argue that converging a network of Nx10K switching/routing nodes takes a non-trivial amount of time as well :) >> >>> >>>> Neither of those approaches seems particularly scalable/desirable if >>>> you look 10 years down the road and think of 1M+ physical machines in >>>> a DC. >>> >>> There is no "particularly desirable" solution, in reality, because >>> building a network with no control plane state anyplace that uses >>> bandwidth in a perfectly optimal way is simply impossible no matter how >>> you slice it (unless you're going to go into quantum routing!). >>> >>> :-) >>> >>> Russ >>> _______________________________________________ >>> dc mailing list >>> dc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dc >> >> -- >> 李柯睿 >> Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc >> Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf >> >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc >> _______________________________________________ >> dc mailing list >> dc@ietf.org >> https://www.ietf.org/mailman/listinfo/dc > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc >