From internet-drafts@ietf.org Sun Oct 2 22:44:05 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E236521F8753; Sun, 2 Oct 2011 22:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 aGMavp0HdR4q; Sun, 2 Oct 2011 22:44:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784E921F8669; Sun, 2 Oct 2011 22:44:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-acceptown-community-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111003054405.28975.30608.idtracker@ietfa.amsl.com> Date: Sun, 02 Oct 2011 22:44:05 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 05:44:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Work= ing Group of the IETF. Title : BGP ACCEPT_OWN Community Attribute Author(s) : James Uttaro Pradosh Mohapatra David J. Smith Robert Raszuk John Scudder Filename : draft-ietf-l3vpn-acceptown-community-04.txt Pages : 9 Date : 2011-10-02 Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, allowing the technique to be used in a standard manner throughout an autonomous system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-acceptown-community-04= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-acceptown-community-04.= txt From marshall.eubanks@gmail.com Tue Oct 4 11:17:28 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3915921F8BE9 for ; Tue, 4 Oct 2011 11:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.662 X-Spam-Level: X-Spam-Status: No, score=-102.662 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, 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 863o+n+QHZ+v for ; Tue, 4 Oct 2011 11:17:27 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B437321F8B4F for ; Tue, 4 Oct 2011 11:17:27 -0700 (PDT) Received: by gyd12 with SMTP id 12so921951gyd.31 for ; Tue, 04 Oct 2011 11:20:30 -0700 (PDT) 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=yvddymBzR7Ng7CLSLRen06iecK9BANSSWw49qfcEY/I=; b=UZ7NRYtYi84DuBtayoPK5+VHj2bGblQepyoXm0j4+gOE2RpL1JpLK+IIGztRG6yVzy hK1ZiA/u+KyseSk58mzgymwOV7FJZiJwj2n1jUu/J9a5kXUAOzmQawGBbVmUyTEWPk1Z 1HlmK2v8wtFOUYP0ATJgELNg/Ot4Hg9Xik6IU= MIME-Version: 1.0 Received: by 10.150.219.13 with SMTP id r13mr1393123ybg.425.1317752430485; Tue, 04 Oct 2011 11:20:30 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Tue, 4 Oct 2011 11:20:30 -0700 (PDT) Date: Tue, 4 Oct 2011 14:20:30 -0400 Message-ID: Subject: VPN4DC at L3VPN in Taipei. From: Marshall Eubanks To: L3VPN , lufang@cisco.com, Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:17:28 -0000 Stewart Bryant has requested that we hold an L3VPN meeting at IETF 82 to consider and discuss VPN4DC. Specifically, we would "need to emerge understanding the problem, the usage, the requirements, and the necessary charter changes." This would be preparation for VPN4DC becoming a BOF. Adrian set up some requirements for this meeting : The problem needs to be discussed on the L3VPN list. You need to have viable -00 drafts before the cutoff. Luyuan Fang has promised a draft before the cutoff. If there is not significant discussion here on this issue, the session is likely to be canceled. Please keep discussion of VPN4DC here on the L3VPN list. Due to the tentative nature and special purpose of this meeting I don't think it is appropriate to make a general call for papers. However, if you would like to speak on VPN4DC, please prepare a draft and let us (the WG Co-chairs) know. Regards Marshall P.S. Some background : http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) http://tools.ietf.org/id/draft-so-vdcs-01.txt From lufang@cisco.com Tue Oct 4 11:34:01 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C0621F8DC8 for ; Tue, 4 Oct 2011 11:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 L3Nr1gJ6tjDk for ; Tue, 4 Oct 2011 11:34:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1522821F8DC0 for ; Tue, 4 Oct 2011 11:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1532; q=dns/txt; s=iport; t=1317753427; x=1318963027; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=GafWR3rxEZurWddq85kA9S8OMafrUob5hjQiB4kQamc=; b=J6bQxuSh7S23PqEijMZKoqA5ASL3b/N5wMG1p4ZrHr6+sPFwvyJmgleF S5ErMvRwfylC4qm6JPHA1FJMeTo/5ifcK3tWFz+zfq3QevLjJYgLYptg1 9gUEu/6Rp1sxh2t8Fbu63l4sQRpUVVXz6FDBb8JgjLkORy1+GmahrGNUO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwAAPZRi06tJV2a/2dsb2JhbABCmG+PFIEFgVMBAQEBAQISAQoTCksEAgEIEQQBAQsGFwEGASAlCQgBAQQBEggah2GaUQGeAoZCYQSHeJEehHCHQA X-IronPort-AV: E=Sophos;i="4.68,486,1312156800"; d="scan'208";a="26014493" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 04 Oct 2011 18:37:06 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p94Ib6ml024773; Tue, 4 Oct 2011 18:37:06 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); Tue, 4 Oct 2011 13:37:06 -0500 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 Subject: RE: VPN4DC at L3VPN in Taipei. Date: Tue, 4 Oct 2011 13:36:06 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2507005EA9@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN4DC at L3VPN in Taipei. Thread-Index: AcyCwkzbvWIb8FIyTLOuo69zVCCI+gAAWTvw References: From: "Luyuan Fang (lufang)" To: "Marshall Eubanks" , "L3VPN" , "Adrian Farrel" X-OriginalArrivalTime: 04 Oct 2011 18:37:06.0176 (UTC) FILETIME=[9DEE9000:01CC82C4] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:34:01 -0000 Marshall, I forwarded your mail to folks currently working on / interested in vpn4dc project. Thanks, Luyuan =20 > -----Original Message----- > From: Marshall Eubanks [mailto:marshall.eubanks@gmail.com] > Sent: Tuesday, October 04, 2011 2:21 PM > To: L3VPN; Luyuan Fang (lufang); Adrian Farrel > Subject: VPN4DC at L3VPN in Taipei. >=20 > Stewart Bryant has requested that we hold an L3VPN meeting at IETF 82 > to consider and discuss VPN4DC. > Specifically, we would >=20 > "need to emerge understanding the problem, > the usage, the requirements, and the necessary charter changes." >=20 > This would be preparation for VPN4DC becoming a BOF. >=20 > Adrian set up some requirements for this meeting : >=20 > The problem needs to be discussed on the L3VPN list. >=20 > You need to have viable -00 drafts before the cutoff. >=20 > Luyuan Fang has promised a draft before the cutoff. >=20 > If there is not significant discussion here on this issue, the session > is likely to be canceled. >=20 > Please keep discussion of VPN4DC here on the L3VPN list. >=20 > Due to the tentative nature and special purpose of this meeting I > don't think it is appropriate to make > a general call for papers. However, if you would like to speak on > VPN4DC, please prepare a draft and let us (the WG Co-chairs) know. >=20 > Regards > Marshall >=20 > P.S. Some background : >=20 > http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) > http://tools.ietf.org/id/draft-so-vdcs-01.txt From ning.so@verizon.com Tue Oct 4 12:11:01 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D6821F8DEB for ; Tue, 4 Oct 2011 12:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 6wyh2om7qFKy for ; Tue, 4 Oct 2011 12:11:00 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 35D1A21F8DE2 for ; Tue, 4 Oct 2011 12:10:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 04 Oct 2011 19:14:04 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.68,486,1312156800"; d="scan'208";a="151646182" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 04 Oct 2011 19:14:04 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.60]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Tue, 4 Oct 2011 15:14:04 -0400 To: "l3vpn@ietf.org" Date: Tue, 4 Oct 2011 15:14:02 -0400 Subject: VPN4DC Thread-Topic: VPN4DC Thread-Index: AcyCyO1X/6RaGFyqSeyCA+pOwAnYQQ== Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08E2171B5@FHDP1LUMXC7V41.us.one.verizon.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-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 19:11:01 -0000 All, I would like to start the conversation on the topic of VPN4DC since we are = still working on the drafts (problem statement, requirements, and use case = drafts). Below is a very high level description of what we want to do. Th= e scope of work has been narrowed significantly if you have followed this w= ork in OPSAWG before, so that we can better focus our attention to have for= ward progress. Hopefully it can stir up some interests and additional part= icipation and contributions. The purpose of VPN4DC is to define requirements and solutions for hosts and= applications in Data Centers to automatically join or leave an IP VPN whic= h interconnects multiple customer premises and data centers.=20 Today when two or more data centers are inter-connected through VPNs or any= WAN networks, hosts or VMs within data centers are managed separately from= the VPN provider's management system. The provisioning process for servic= es provided by Service Providers' data centers to join enterprise VPNs, is = often manual, and thus has long turn up time. Security, scalability, and op= erational efficiency are issues due to lack of standardized automation proc= edure for hosts in provider data centers to join VPN. =20 Modern data-centers require multi-tenant support for applications. For secu= rity and administrative reasons it is desirable to isolate the resources as= sociated with a particular tenant in a VPN. This WG will define requirement= s and protocol solutions to enable hosts in a data center to join a specifi= c layer 3 VPN automatically through control protocols, using IP VPN to prov= ide secure any to any connections. The VPN Gateway function which provides = seamless VPN connectivity between the segments of the networks will be defi= ned. There are two ways for hosts/applications within a data center to join a sp= ecific VPN which interconnect multiple sites: via Management plane or via i= n-band data plane.=20 1. Management Plane: i.e. having the wide area VPN's management system comm= unicate with data center management system to allow a group of hosts or app= lications to join a specific VPN.=20 If the two management systems can communicate directly to allow a group of = VMs in a Data Center to join a VPN, then the automation can be achieved wit= hout any new protocol work for IETF.=20 2. In-band data plane: However, several service providers have indicated th= at their VPN management system can't communicate with Data Center managemen= t system automatically. They want the automation to go through in-band sign= al between DC gateway and VPN PEs. Then new protocol work is needed for IET= F: like request to join (or leave), authentication, etc. The design principle for the protocols and solution development is to lever= age existing layer 3 VPN technologies already defined in IETF whenever poss= ible, including various IP and MPLS VPN technologies. This work supports th= e creation of new protocols, extension to existing protocols, and solutions= proposed to use new and existing protocols. =A0 Best regards, =A0 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =A0 -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of l= 3vpn-request@ietf.org Sent: Tuesday, October 04, 2011 2:00 PM To: l3vpn@ietf.org Subject: L3VPN Digest, Vol 88, Issue 2 If you have received this digest without all the individual message attachm= ents you will need to update your digest options in your list subscription.= To do so, go to=20 https://www.ietf.org/mailman/listinfo/l3vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME o= r Plain Text Digests?" to MIME. You can set this option globally for all t= he list digests you receive at this point. Send L3VPN mailing list submissions to l3vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l3vpn or, via email, send a message with subject or body 'help' to l3vpn-request@ietf.org You can reach the person managing the list at l3vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of L3VPN digest..." Today's Topics: 1. VPN4DC at L3VPN in Taipei. (Marshall Eubanks) 2. RE: VPN4DC at L3VPN in Taipei. (Luyuan Fang (lufang)) ---------------------------------------------------------------------- Message: 1 Date: Tue, 4 Oct 2011 14:20:30 -0400 From: Marshall Eubanks To: L3VPN , lufang@cisco.com, Adrian Farrel Subject: VPN4DC at L3VPN in Taipei. Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 Stewart Bryant has requested that we hold an L3VPN meeting at IETF 82 to co= nsider and discuss VPN4DC. Specifically, we would "need to emerge understanding the problem, the usage, the requirements, and= the necessary charter changes." This would be preparation for VPN4DC becoming a BOF. Adrian set up some requirements for this meeting : The problem needs to be discussed on the L3VPN list. You need to have viable -00 drafts before the cutoff. Luyuan Fang has promised a draft before the cutoff. If there is not significant discussion here on this issue, the session is l= ikely to be canceled. Please keep discussion of VPN4DC here on the L3VPN list. Due to the tentative nature and special purpose of this meeting I don't thi= nk it is appropriate to make a general call for papers. However, if you wou= ld like to speak on VPN4DC, please prepare a draft and let us (the WG Co-c= hairs) know. Regards Marshall P.S. Some background : http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) http://to= ols.ietf.org/id/draft-so-vdcs-01.txt ------------------------------ Message: 2 Date: Tue, 4 Oct 2011 13:36:06 -0500 From: "Luyuan Fang (lufang)" To: "Marshall Eubanks" , "L3VPN" , "Adrian Farrel" Subject: RE: VPN4DC at L3VPN in Taipei. Message-ID: <238542D917511A45B6B8AA806E875E2507005EA9@XMB-RCD-201.cisco.com> Content-Type: text/plain; charset=3D"us-ascii" Marshall, I forwarded your mail to folks currently working on / interested in vpn4dc = project. Thanks, Luyuan =20 > -----Original Message----- > From: Marshall Eubanks [mailto:marshall.eubanks@gmail.com] > Sent: Tuesday, October 04, 2011 2:21 PM > To: L3VPN; Luyuan Fang (lufang); Adrian Farrel > Subject: VPN4DC at L3VPN in Taipei. >=20 > Stewart Bryant has requested that we hold an L3VPN meeting at IETF 82=20 > to consider and discuss VPN4DC. > Specifically, we would >=20 > "need to emerge understanding the problem, the usage, the=20 > requirements, and the necessary charter changes." >=20 > This would be preparation for VPN4DC becoming a BOF. >=20 > Adrian set up some requirements for this meeting : >=20 > The problem needs to be discussed on the L3VPN list. >=20 > You need to have viable -00 drafts before the cutoff. >=20 > Luyuan Fang has promised a draft before the cutoff. >=20 > If there is not significant discussion here on this issue, the session=20 > is likely to be canceled. >=20 > Please keep discussion of VPN4DC here on the L3VPN list. >=20 > Due to the tentative nature and special purpose of this meeting I=20 > don't think it is appropriate to make a general call for papers.=20 > However, if you would like to speak on VPN4DC, please prepare a draft=20 > and let us (the WG Co-chairs) know. >=20 > Regards > Marshall >=20 > P.S. Some background : >=20 > http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17)=20 > http://tools.ietf.org/id/draft-so-vdcs-01.txt ------------------------------ _______________________________________________ L3VPN mailing list L3VPN@ietf.org https://www.ietf.org/mailman/listinfo/l3vpn End of L3VPN Digest, Vol 88, Issue 2 ************************************ From danny@tcb.net Wed Oct 5 09:48:58 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3677B11E809C for ; Wed, 5 Oct 2011 09:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.002 X-Spam-Level: X-Spam-Status: No, score=-106.002 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 C7bbN+0AkafC for ; Wed, 5 Oct 2011 09:48:57 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id EC42E11E8094 for ; Wed, 5 Oct 2011 09:48:56 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP; Wed, 05 Oct 2011 09:52:05 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p95Gq40H021462 for ; Wed, 5 Oct 2011 12:52:04 -0400 Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com ([10.131.210.13]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 12:52:04 -0400 From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: New Non-WG Mailing List: vpn4dc Date: Wed, 5 Oct 2011 12:52:04 -0400 References: <20111005162229.74DF421F8C98@ietfa.amsl.com> To: l3vpn@ietf.org Message-Id: <90084D67-DBE5-491A-91AB-699C432A42D7@tcb.net> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 05 Oct 2011 16:52:04.0002 (UTC) FILETIME=[1BF4E020:01CC837F] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:48:58 -0000 FYI.... Note that this topic is planned to be discussed at the upcoming = L3VPN meeting in Taipei, assuming publication of the relevant -00 drafts = by the I-D cutoff period. -danny Begin forwarded message: > From: IETF Secretariat > Date: October 5, 2011 12:22:21 PM EDT > To: IETF Announcement list > Cc: So@ietfa.amsl.com, Luyuan Fang , Ning = , vpn4dc@ietf.org > Subject: New Non-WG Mailing List: vpn4dc=20 >=20 >=20 >=20 > A new IETF non-working group email list has been created. >=20 > List address: vpn4dc@ietf.org > Archive: http://www.ietf.org/mail-archive/web/vpn4dc/ > To subscribe: https://www.ietf.org/mailman/listinfo/vpn4dc >=20 > Purpose: This mailing list will be used to discuss requirements and = solutions > for establishing end-to-end IP connectivity through through > VPNs for data center and cloud services. >=20 > For additional information, please contact the list administrators. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From marshall.eubanks@gmail.com Wed Oct 5 11:51:28 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105001F0C74 for ; Wed, 5 Oct 2011 11:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_32=0.6, 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 c8DBQpPntMNg for ; Wed, 5 Oct 2011 11:51:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 228781F0C57 for ; Wed, 5 Oct 2011 11:51:26 -0700 (PDT) Received: by ywm3 with SMTP id 3so2279173ywm.31 for ; Wed, 05 Oct 2011 11:54:34 -0700 (PDT) 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=OauUjbu3h4nWuGEOom2BQcNGH+KdGFE4ik+wFgVE/1s=; b=aAVPz892agY4W1GLZC4WOwGhFaDrjJhLw2Jhbcdc2INbNoMVPttjtbrRIQanQLwqda brIZSJ70DN0CrCPX4pY7UTEZET2i3E6PU1MmL1QrdkVfKmwmF8KlDQRrtAucHvU5RXlS NZZ6pui0hAcMpQe45kzrcV8i7raRm+gyI7fdk= MIME-Version: 1.0 Received: by 10.150.143.2 with SMTP id q2mr2528834ybd.368.1317840874617; Wed, 05 Oct 2011 11:54:34 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Wed, 5 Oct 2011 11:54:34 -0700 (PDT) Date: Wed, 5 Oct 2011 14:54:34 -0400 Message-ID: Subject: Question about the scope of VPN4DC From: Marshall Eubanks To: L3VPN , Adrian Farrel , "Stewart Bryant (stbryant)" , Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 18:51:28 -0000 As I was not present in the BOF call, I am not sure if requesting that L3VPN means that the scope of VPN4DC has been narrowed to only consider L3VPNs as suitable for VPN4DC. Is this true ? Or are L2VPNs and IPSec VPNs in scope for VPN4DC ? Regards Marshall From ning.so@verizon.com Wed Oct 5 12:07:10 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE60C21F84D3 for ; Wed, 5 Oct 2011 12:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 cMevwZY4Uglf for ; Wed, 5 Oct 2011 12:07:10 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA8521F84B7 for ; Wed, 5 Oct 2011 12:07:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 05 Oct 2011 19:10:18 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.68,492,1312156800"; d="scan'208";a="152649535" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 05 Oct 2011 19:10:18 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.60]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Wed, 5 Oct 2011 15:10:18 -0400 To: "l3vpn@ietf.org" Date: Wed, 5 Oct 2011 15:10:16 -0400 Subject: RE: Question about the scope of VPN4DC Thread-Topic: Question about the scope of VPN4DC Thread-Index: AcyDkfdFjA9W///9S7mt6Yw5ow8Z+w== Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08E2177E2@FHDP1LUMXC7V41.us.one.verizon.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-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 19:07:10 -0000 Marshall, You are correct. The current VPN4DC scope focuses on L3VPN only. To say = it more precisely, the scope of VPN4DC is about the problems and protocol = solutions for hosts in data centers automatically joining L3VPN to form hos= t-to-host connectivity through L3VPN. =20 =A0 Best regards, =A0 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =A0 Date: Wed, 5 Oct 2011 14:54:34 -0400 From: Marshall Eubanks To: L3VPN , Adrian Farrel , "Stewart Bryant (stbryant)" , Danny McPherson Subject:=20 Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 As I was not present in the BOF call, I am not sure if requesting that L3VPN means that the scope of VPN4DC has been narrowed to only consider L3VPNs as suitable for VPN4DC. Is this true ? Or are L2VPNs and IPSec VPNs in scope for VPN4DC ? Regards Marshall ------------------------------ _______________________________________________ L3VPN mailing list L3VPN@ietf.org https://www.ietf.org/mailman/listinfo/l3vpn End of L3VPN Digest, Vol 88, Issue 3 ************************************ From pedro.r.marques@gmail.com Wed Oct 5 19:46:21 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5BC21F8D76 for ; Wed, 5 Oct 2011 19:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vFQA6KG9d3u for ; Wed, 5 Oct 2011 19:46:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96B2021F8D36 for ; Wed, 5 Oct 2011 19:46:20 -0700 (PDT) Received: by iaby26 with SMTP id y26so3018766iab.31 for ; Wed, 05 Oct 2011 19:49:30 -0700 (PDT) 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=DhzGUHDUuLZCqiS0ZymT61FjpwZpZxacLEV78d2mDI0=; b=DJ6rSjgfBEsy0MDtSMHAuHL3Nb4vXheMrXwKnU8yQ2Q3lU1Jn8W0RSG5Zj3bkveJ1f AlYYOwkB/jY0cWaXaDkRj/l/zhZuhhEH9HvklD8jJCVGhJk7hNm+wLx/otgdB16PXd0P RbCaygR3LX6YR2CY8dPBy3VRO/49zBNvPASzE= MIME-Version: 1.0 Received: by 10.231.28.209 with SMTP id n17mr359433ibc.89.1317869369886; Wed, 05 Oct 2011 19:49:29 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Wed, 5 Oct 2011 19:49:29 -0700 (PDT) Date: Wed, 5 Oct 2011 19:49:29 -0700 Message-ID: Subject: l3vpn-end-system draft From: Pedro Marques To: l3vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 02:46:21 -0000 Given the recent interest on the topic of VPN technologies for data-center applications, myself and my co-authors would like to submit the following proposal for your consideration: http://datatracker.ietf.org/doc/draft-marques-l3vpn-end-system/ thanks, Pedro. From tnadeau@lucidvision.com Fri Oct 7 07:47:00 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BFF21F84F8 for ; Fri, 7 Oct 2011 07:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, 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 0Ks6CgKUIQ5p for ; Fri, 7 Oct 2011 07:47:00 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 60A7321F84D9 for ; Fri, 7 Oct 2011 07:47:00 -0700 (PDT) Received: from [10.100.68.205] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id D076F1EB197B for ; Fri, 7 Oct 2011 10:40:24 -0400 (EDT) From: Thomas Nadeau Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Software Defined Networks (SDN) BoF in Taipei Date: Fri, 7 Oct 2011 10:40:18 -0400 Message-Id: <6E104BEB-7355-455B-9F49-69A328AFBF63@lucidvision.com> To: L3VPN WG mailing list Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 14:47:00 -0000 I wanted to pass on some information regarding a BoF that is = planned for Taipei that is relevant to=20 participants of this mailing list/WG area. =20 The IAB and IESG met today to discuss BoFs for Taipei and agreed = that we will hold a BoF SDN with a goal of "discussing the technology and identifying work = items". The BoF is nominally=20 in the Routing Area, but we expect considerable involvement from the OPS = Area as well.=20 The following is a link to the drafts and other documentation = around the SDN effort including some presentations, and a link to join the BoF mailing list.=20= =09 http://trac.tools.ietf.org/bof/trac/ We encourage you to join the list, review the materials and = participate on the mailing list as well as come to the BoF if you have an interest in this work. --Tom From pedro.r.marques@gmail.com Mon Oct 10 21:30:22 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AAF21F8B28 for ; Mon, 10 Oct 2011 21:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUUdm3GHJvHq for ; Mon, 10 Oct 2011 21:30:22 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E90AB21F8ACE for ; Mon, 10 Oct 2011 21:30:21 -0700 (PDT) Received: by iaby26 with SMTP id y26so10011605iab.31 for ; Mon, 10 Oct 2011 21:30:21 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=47GD+3McDwDHpAOrHwAa0iU1q3bSrv2sx3MjxQusCcc=; b=Wmfq7p8audLqVaFXixK9UP+3yBeZBacFmxQccd0DrAM9ZCiFH8T4NVAARcSu9Q9moY zmJMi9LzUpVh/5CTRsmOkv+wBfx9eJWXgNP90QO3zY1gdKSbZCYv+XVSC7BdFK2I4LcL J5RO6dA2pjcm9KMs1az8bPmbnLuATO/vrxf68= MIME-Version: 1.0 Received: by 10.231.81.199 with SMTP id y7mr9405522ibk.76.1318307421464; Mon, 10 Oct 2011 21:30:21 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Mon, 10 Oct 2011 21:30:21 -0700 (PDT) In-Reply-To: <20111011042629.1343.88114.idtracker@ietfa.amsl.com> References: <20111011042629.1343.88114.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2011 21:30:21 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-marques-sdnp-flow-spec-00.txt From: Pedro Marques To: sdnp@lucidvision.com, l3vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 04:30:23 -0000 I posted a new draft that complements the end-system VPN proposal by adding support for fine grain traffic classification policies. I hope it merits your attention. regards, Pedro. ---------- Forwarded message ---------- From: Date: Mon, Oct 10, 2011 at 9:26 PM Subject: New Version Notification for draft-marques-sdnp-flow-spec-00.txt To: pedro.r.marques@gmail.com Cc: pedro.r.marques@gmail.com, ppan@infinera.com, lufang@cisco.com, amit@juniper.net A new version of I-D, draft-marques-sdnp-flow-spec-00.txt has been successfully submitted by Pedro Marques and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-marques-sdnp-flow-spec Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 Traffic classification, filtering and redirectio= n for end-system IP VPNs. Creation date: =A0 2011-10-11 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 15 Abstract: =A0 When IP VPNs are used to interconnect end-systems =A0 [I-D.marques-l3vpn-end-system] it may be desirable to introduce =A0 traffic control rules at a finer level of granularity than an IP =A0 destination address. =A0 This document extends the end-system IP VPN specification with =A0 support for fine grain traffic classification, filtering and =A0 redirection rules. =A0It applies the existing BGP IP VPN flow =A0 specification dissemination mechanism [RFC5575] to end-system IP VPNs =A0 in order to provide the ability to control IP packets that match a =A0 specific pattern, which may include fields other than the IP =A0 destination address. The IETF Secretariat From lufang@cisco.com Tue Oct 11 00:36:23 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7F521F8D1D for ; Tue, 11 Oct 2011 00:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 mpg-EAQDWyzk for ; Tue, 11 Oct 2011 00:36:21 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7950521F893C for ; Tue, 11 Oct 2011 00:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=10916; q=dns/txt; s=iport; t=1318318578; x=1319528178; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=HYu27fBWKQaqgx9vbd0hFp5tuo6jw4kwCkUliu4PcoI=; b=Z9aypmIVLYTPCJ89kt/6XUEjJnFOYOLvJVMmgJWBLsPxAWvRq70qeeK3 +PDAjGrR9wSfJ+K0Zlr4yxMP4qCc8LN3fLqm2YwIrBO69OeAHTOK9aIbb vLNS4stJSKJn2k5mHFJyjFQ4LUxmKVtmrc/+/hJL1MeR8DXVADqMKOdcF 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0AAALxk06tJV2b/2dsb2JhbAA5Cph6jyOBBYFTAQEBAgIBAQEPAQoTCjQXBAIBCBEDAQEBCwYXAQYBIAYfCQgBAQQTCBMHh2OaRAGeSYQdgk5hBId+kSeEeodF X-IronPort-AV: E=Sophos;i="4.68,522,1312156800"; d="scan'208";a="27446083" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 11 Oct 2011 07:36:14 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9B7aFBl022088 for ; Tue, 11 Oct 2011 07:36:15 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, 11 Oct 2011 02:36:14 -0500 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 Subject: RE: VPN4DC at L3VPN in Taipei Date: Tue, 11 Oct 2011 02:36:11 -0500 Message-ID: <238542D917511A45B6B8AA806E875E250709B7CF@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN4DC at L3VPN in Taipei Thread-Index: AcyCyGAvMy1n7PIQT3mJE3w1u7CcbQFFSu9A References: From: "Luyuan Fang (lufang)" To: X-OriginalArrivalTime: 11 Oct 2011 07:36:14.0470 (UTC) FILETIME=[7490A260:01CC87E8] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 07:36:24 -0000 As Marshall indicated last week: VPN4DC will be discussed in the L3VPN WG meeting in Taipei per Routing ADs' arrangement.=20 There will be no BOF. I am posting the VPN4DC BOF proposal (provided to AD on 10/2/2011) here for the record.=20 Hope this helps to provide additional background information, and attract more interested participants. =20 VPN4DC BOF Proposal: Working Group Name: Virtual Private Networks for Data Centers (VPN4DC) IETF Area: Routing Area Routing Area Director: Stewart Bryant (stbryant@cisco.com) Description of the Working Group: The purpose of the VPN4DC is to define requirements and solutions for establishing end-to-end (host-to-host) connectivity through layer 3 VPN for Data Center and Cloud Services.=20 (Note: The term layer 3 VPN here implies any type of IP technologies for VPN. For example, IP VPN, BGP/MPLS VPN, or the combination of different types of layer 3 VPNs to form end-to-end VPN solutions. These VPNs may or may not be provisioned by Service Providers.) Today when Data Centers are inter-connected through VPNs or other WAN networks, the provisioning process for cloud services cross Service Providers' and Enterprise's Data Centers, or cross different Service Providers' Data Centers, is often manual, with long turn up time. Security, scalability, and operational efficiency are issues due to lack of standardized host-to-host VPN solutions.=20 Modern data-centers require multi-tenant support for applications. For security and administrative reasons it is desirable to isolate the resources associated with a particular tenant in a VPN. This workgroup will propose standard mechanisms to provide Layer 3 VPN connectivity to end-systems while meeting scaling and manageability goals. This WG will define requirements and protocol solutions to enable hosts in a Data Center to join a specific Layer 3 VPN automatically through control protocols, using Layer 3 VPN to provide secure any to any connections. The Layer 3 VPN Gateway function which provides seamless VPN connectivity between the segments of the networks will be defined. In addition to proposing one or more layer 3 VPN technologies which support(s) end-systems, the WG will focus on interoperability between inter and intra DC VPN technologies and in making the VPN network topology information available and controllable by applications. Both of the following scenarios will be in scope: 1. When VPN management system and Data Center management system can communicate with each other, the WG will identify the requirement and protocols to automatically enable hosts in a Data Center to join a specific VPN=20 2. When VPN management system and Data Center management system can't communicate (which is often the case), the WG will identify the requirement and protocols to automatically enable hosts in a Data Center to join a specific VPN.=20 The scope of the charter is limited to Layer 3 VPN solutions for Data Center and Cloud Services with end-to-end connectivity.=20 =20 Non-goals: Layer 2 connectivity, and layer 3 Multicast. The design principle for the protocols and solution development is to leverage existing layer 3 VPN technologies already defined in IETF whenever possible, including various IP and MPLS technologies. This charter supports the creation of new protocols, extension to existing protocols, and solutions proposed to use new and existing protocols. When extending existing protocols, this WG will work with the WG(s) responsible for the protocol being extended.=20 BOF Agenda for IETF 82 November, 2011, Taibei - Discuss and agree on charter definitions: problems space, scope, requirements, candidate solutions, general interests, encourage participation from DC groups and from SP groups - Present initial draft of problem statements - Present initial draft of requirements - Present initial draft of use cases - Present one or more initial draft(s) of protocol solution(s) Goals and Milestones for the proposed Working Group March 2012 Post strawman WG goals and charter description March 2012 Identify and document a limited set of candidate L3 VPN solutions for DC March 2012 Build small design teams for each proposed solution and requirement doc March 2012 Submit additional protocol definition draft(s)=20 July 2012 Submit problem statements, use case, and requirement drafts as WG documents July 2012 Submit initial draft of Framework document July 2012 Submit protocol solutions as WG documents=20 July 2012 Design teams to narrow down to small set of solutions to be focused by WG July 2012 Submit applicability statements for solutions proposed July 2012 Post modified WG goals and charter with more details on solutions and timelines Nov. 2012 Submit problem statements, use cases, and requirements draft to IESG for review Nov. 2012 Submit the protocol solutions to IESG for review Nov. 2012 Submit Framework document as WG document Nov. 2012 Submit applicability statements as WG documents=20 Nov. 2012 Submit more protocol solutions as WG documents=20 Nov. 2012 Submit initial OAM drafts=20 Nov. 2012 Submit initial discovery protocol drafts Nov. 2012 Submit initial security framework draft Nov. 2012 Submit initial MIB drafts=20 March 2013 Submit framework draft to IESG for review March 2013 Submit more protocol solutions and applicability drafts to IESG for review March 2013 Submit OAM drafts as WG document March 2013 Submit more protocols and applicability drafts as WG document March 2013 Post modified charter based on the progress of the WG July 2013 Submit more protocol solutions and applicability drafts to IESG for review July 2013 Submit more protocol solutions and applicability drafts as WG doc July 2013 Submit security framework draft as WG document=20 July 2013 Submit discovery protocol drafts as WG documents July 2013 Submit MIB drafts as WG documents July 2013 Submit more protocols and applicability drafts =20 Nov. 2013 Submit OAM drafts for IESG review=20 Nov. 2013 Submit discovery protocol drafts for IESG review Nov. 2013 Submit more protocol solutions and applicability drafts to IESG for review Nov. 2013 Submit more protocol solutions and applicability drafts as WG doc Nov 2013 Submit Inter-op report Nov 2013 Post modified charter based on the progress of the WG=20 March 2014 Submit security framework draft for IESG review March 2014 Submit MIB drafts for IESG review March 2014 Submit more protocol solutions and applicability drafts to IESG for review In addition to the meeting in L3VPN WG session, we will also hold Bar BOF meeting(s) in Taipei for those who are interested working on the subject to discuss and work together.=20 Thanks, Luyuan > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 4 Oct 2011 14:20:30 -0400 > From: Marshall Eubanks > To: L3VPN , lufang@cisco.com, Adrian Farrel > > Subject: VPN4DC at L3VPN in Taipei. > Message-ID: > 3yiUOfMpq_QaP17fBA7EBrR5r14NP+T9ZL62bKrdvw@mail.gmail.com> > Content-Type: text/plain; charset=3DISO-8859-1 >=20 > Stewart Bryant has requested that we hold an L3VPN meeting at IETF 82 > to consider and discuss VPN4DC. > Specifically, we would >=20 > "need to emerge understanding the problem, > the usage, the requirements, and the necessary charter changes." >=20 > This would be preparation for VPN4DC becoming a BOF. >=20 > Adrian set up some requirements for this meeting : >=20 > The problem needs to be discussed on the L3VPN list. >=20 > You need to have viable -00 drafts before the cutoff. >=20 > Luyuan Fang has promised a draft before the cutoff. >=20 > If there is not significant discussion here on this issue, the session > is likely to be canceled. >=20 > Please keep discussion of VPN4DC here on the L3VPN list. >=20 > Due to the tentative nature and special purpose of this meeting I > don't think it is appropriate to make > a general call for papers. However, if you would like to speak on > VPN4DC, please prepare a draft and let us (the WG Co-chairs) know. >=20 > Regards > Marshall >=20 > P.S. Some background : >=20 > http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) > http://tools.ietf.org/id/draft-so-vdcs-01.txt >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Tue, 4 Oct 2011 13:36:06 -0500 > From: "Luyuan Fang (lufang)" > To: "Marshall Eubanks" , "L3VPN" > , "Adrian Farrel" > Subject: RE: VPN4DC at L3VPN in Taipei. > Message-ID: > <238542D917511A45B6B8AA806E875E2507005EA9@XMB-RCD-201.cisco.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Marshall, >=20 > I forwarded your mail to folks currently working on / interested in > vpn4dc project. > Thanks, > Luyuan >=20 >=20 > > -----Original Message----- > > From: Marshall Eubanks [mailto:marshall.eubanks@gmail.com] > > Sent: Tuesday, October 04, 2011 2:21 PM > > To: L3VPN; Luyuan Fang (lufang); Adrian Farrel > > Subject: VPN4DC at L3VPN in Taipei. > > > > Stewart Bryant has requested that we hold an L3VPN meeting at IETF 82 > > to consider and discuss VPN4DC. > > Specifically, we would > > > > "need to emerge understanding the problem, > > the usage, the requirements, and the necessary charter changes." > > > > This would be preparation for VPN4DC becoming a BOF. > > > > Adrian set up some requirements for this meeting : > > > > The problem needs to be discussed on the L3VPN list. > > > > You need to have viable -00 drafts before the cutoff. > > > > Luyuan Fang has promised a draft before the cutoff. > > > > If there is not significant discussion here on this issue, the > session > > is likely to be canceled. > > > > Please keep discussion of VPN4DC here on the L3VPN list. > > > > Due to the tentative nature and special purpose of this meeting I > > don't think it is appropriate to make > > a general call for papers. However, if you would like to speak on > > VPN4DC, please prepare a draft and let us (the WG Co-chairs) know. > > > > Regards > > Marshall > > > > P.S. Some background : > > > > http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) > > http://tools.ietf.org/id/draft-so-vdcs-01.txt >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > L3VPN mailing list > L3VPN@ietf.org > https://www.ietf.org/mailman/listinfo/l3vpn >=20 >=20 > End of L3VPN Digest, Vol 88, Issue 2 > ************************************ From tnadeau@lucidvision.com Tue Oct 11 06:20:26 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2340821F8696 for ; Tue, 11 Oct 2011 06:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 ui0nwnAh7Fus for ; Tue, 11 Oct 2011 06:20:25 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 321CA21F85F1 for ; Tue, 11 Oct 2011 06:20:25 -0700 (PDT) Received: from [10.100.68.132] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id 08D361ECDD2B; Tue, 11 Oct 2011 09:20:23 -0400 (EDT) References: <20111011042629.1343.88114.idtracker@ietfa.amsl.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6B71CDDD-F2E5-45EC-A0C9-B06F6C95B03C@lucidvision.com> X-Mailer: iPad Mail (8L1) From: Thomas Nadeau Subject: Re: [Sdnp] Fwd: New Version Notification for draft-marques-sdnp-flow-spec-00.txt Date: Tue, 11 Oct 2011 09:20:21 -0400 To: Pedro Marques Cc: "sdnp@lucidvision.com" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 13:20:26 -0000 Pedro thanks for the update. I have a question about your draft. Can you e= xplain how it differs from similar use cases that were discussed and also ho= w it applies to the proposed architecture for SDN either in its current form= or modified? Tom Sent from my iPad On Oct 11, 2011, at 12:30 AM, Pedro Marques wrot= e: > I posted a new draft that complements the end-system VPN proposal by > adding support for fine grain traffic classification policies. > I hope it merits your attention. >=20 > regards, > Pedro. >=20 >=20 > ---------- Forwarded message ---------- > From: > Date: Mon, Oct 10, 2011 at 9:26 PM > Subject: New Version Notification for draft-marques-sdnp-flow-spec-00.txt > To: pedro.r.marques@gmail.com > Cc: pedro.r.marques@gmail.com, ppan@infinera.com, lufang@cisco.com, > amit@juniper.net >=20 >=20 > A new version of I-D, draft-marques-sdnp-flow-spec-00.txt has been > successfully submitted by Pedro Marques and posted to the IETF > repository. >=20 > Filename: draft-marques-sdnp-flow-spec > Revision: 00 > Title: Traffic classification, filtering and redirection for > end-system IP VPNs. > Creation date: 2011-10-11 > WG ID: Individual Submission > Number of pages: 15 >=20 > Abstract: > When IP VPNs are used to interconnect end-systems > [I-D.marques-l3vpn-end-system] it may be desirable to introduce > traffic control rules at a finer level of granularity than an IP > destination address. >=20 > This document extends the end-system IP VPN specification with > support for fine grain traffic classification, filtering and > redirection rules. It applies the existing BGP IP VPN flow > specification dissemination mechanism [RFC5575] to end-system IP VPNs > in order to provide the ability to control IP packets that match a > specific pattern, which may include fields other than the IP > destination address. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp >=20 From pedro.r.marques@gmail.com Tue Oct 11 09:28:16 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07CE21F8E7D for ; Tue, 11 Oct 2011 09:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSVWANW91QLV for ; Tue, 11 Oct 2011 09:28:16 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9D8C21F8E80 for ; Tue, 11 Oct 2011 09:28:15 -0700 (PDT) Received: by iaby26 with SMTP id y26so10848289iab.31 for ; Tue, 11 Oct 2011 09:28:09 -0700 (PDT) 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=NdWRsqQB4CL8JdttZgrZ66KFrBF050yxXJRJbYYAQFI=; b=fZnStm2hAWDyQEMoCXEd+KQlKgu5QrQixe+kNkfNLjgrhRjLRAk5k+/muizAbk5Qul mWDCO7w72i8Jz49Q28FOBGHVNKuQR+xi2eoT6iJROuR+BicTZIaL+lwHa+SL40wpIHVE 3jAVSpQdop7kIb1Q1Vk8DlhMuzt0HkDvFyawI= MIME-Version: 1.0 Received: by 10.231.28.209 with SMTP id n17mr10463968ibc.89.1318350489018; Tue, 11 Oct 2011 09:28:09 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Tue, 11 Oct 2011 09:28:08 -0700 (PDT) In-Reply-To: <6B71CDDD-F2E5-45EC-A0C9-B06F6C95B03C@lucidvision.com> References: <20111011042629.1343.88114.idtracker@ietfa.amsl.com> <6B71CDDD-F2E5-45EC-A0C9-B06F6C95B03C@lucidvision.com> Date: Tue, 11 Oct 2011 09:28:08 -0700 Message-ID: Subject: Re: [Sdnp] Fwd: New Version Notification for draft-marques-sdnp-flow-spec-00.txt From: Pedro Marques To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sdnp@lucidvision.com" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:28:16 -0000 Tom, In terms of fit within a broader context, my understanding is that these proposals are largely inline with the SDN ecosystem/vision. The following are some of the underlying assumptions which i believe are inline with the "sdnp" documents: - There is the assumption that VM provisioning is performed by an orchestration system. This orchestration system has a notion of user/tenant and which services the tenant is allowed to access. - The orchestration system allocates a "sticky" IP address per VM; when a VM is provisioned, the (VPN IP address, vpn-name) is passed along to the host OS. - There is a centralized data-base (possibly with a distributed implementation) that contains the provisioning information regarding vpn-names and the services they are able to access. This database schema is standardized and signaling gateways are able to retrieve the vpn configuration from this database. The orchestration system is most likely the publisher. - Advanced functionality such as fine grain traffic policies is able to inject rules into the network by pushing information through the XMPP interface. - The network operates independently from applications and orchestration. But the network signaling works as a "message bus" to which the orchestration layer can push information to and also receive information from. - It is important to leverage other IETF standards. For instance the virtualized network solution should support an ALTO API for application to access network distance information. In my mind these proposals are one possible approach to implement what is most likely the most immediate problem in the SDN space. It is my belief that by reusing existing standards, that multiple interoperable implementation can surface in a short period of time. And in my opinion they are a natural progression of the SDN work so far. But i do apologize in advance in case i misinterpreted the existing SDN architecture. regards, Pedro On Tue, Oct 11, 2011 at 6:20 AM, Thomas Nadeau wr= ote: > Pedro thanks for the update. =A0I have a question about your draft. =A0Ca= n you explain how it differs from similar use cases that were discussed and= also how it applies to the proposed architecture for SDN either in its cur= rent form or modified? > > Tom > > Sent from my iPad > > On Oct 11, 2011, at 12:30 AM, Pedro Marques w= rote: > >> I posted a new draft that complements the end-system VPN proposal by >> adding support for fine grain traffic classification policies. >> I hope it merits your attention. >> >> regards, >> =A0Pedro. >> >> >> ---------- Forwarded message ---------- >> From: =A0 >> Date: Mon, Oct 10, 2011 at 9:26 PM >> Subject: New Version Notification for draft-marques-sdnp-flow-spec-00.tx= t >> To: pedro.r.marques@gmail.com >> Cc: pedro.r.marques@gmail.com, ppan@infinera.com, lufang@cisco.com, >> amit@juniper.net >> >> >> A new version of I-D, draft-marques-sdnp-flow-spec-00.txt has been >> successfully submitted by Pedro Marques and posted to the IETF >> repository. >> >> Filename: =A0 =A0 =A0 =A0draft-marques-sdnp-flow-spec >> Revision: =A0 =A0 =A0 =A000 >> Title: =A0 =A0 =A0 =A0 =A0 Traffic classification, filtering and redirec= tion for >> end-system IP VPNs. >> Creation date: =A0 2011-10-11 >> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission >> Number of pages: 15 >> >> Abstract: >> =A0 When IP VPNs are used to interconnect end-systems >> =A0 [I-D.marques-l3vpn-end-system] it may be desirable to introduce >> =A0 traffic control rules at a finer level of granularity than an IP >> =A0 destination address. >> >> =A0 This document extends the end-system IP VPN specification with >> =A0 support for fine grain traffic classification, filtering and >> =A0 redirection rules. =A0It applies the existing BGP IP VPN flow >> =A0 specification dissemination mechanism [RFC5575] to end-system IP VPN= s >> =A0 in order to provide the ability to control IP packets that match a >> =A0 specific pattern, which may include fields other than the IP >> =A0 destination address. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> SDNP mailing list >> SDNP@lucidvision.com >> http://lucidvision.com/mailman/listinfo/sdnp >> > From lufang@cisco.com Tue Oct 11 10:27:00 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C75221F8C1C for ; Tue, 11 Oct 2011 10:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 51TdR9lpTml0 for ; Tue, 11 Oct 2011 10:26:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2376721F8C14 for ; Tue, 11 Oct 2011 10:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=8224; q=dns/txt; s=iport; t=1318354019; x=1319563619; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=M9vIuYGM9TgDcQzPDm01akVN+9kr7uopwOmBe58oeeA=; b=Wg4g+UU1+V9p6a82rrsho7OLg6DH/hxvMc4suB/Lc0hiwB17QyLM9VL1 EcPkEot0gOT5MhbJ+CM+fnXy2X6pKr+l+yKtFBl7heMFEtendeREyzI0S ZWuD6+inrYwfYSoXlH/Aq1rN3dMyvfdseRMZHz/besO+dT1A1tlXBCztS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAADt7lE6tJXHA/2dsb2JhbABDmQaMc4IxgQWBUwEBAQQBAQEPAR0+CQIMBAIBCBEBAgEBAQEKAgQXAQYBIAYfAwYIAQEEARIIDAcHh2OaCQGeVoZrYQSHTzCRJ4R6h0U X-IronPort-AV: E=Sophos;i="4.68,524,1312156800"; d="scan'208";a="27608292" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 11 Oct 2011 17:26:58 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9BHQwfv032364; Tue, 11 Oct 2011 17:26:58 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 12:26:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sdnp] Fwd: New Version Notification fordraft-marques-sdnp-flow-spec-00.txt Date: Tue, 11 Oct 2011 12:26:55 -0500 Message-ID: <238542D917511A45B6B8AA806E875E250709B9A8@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sdnp] Fwd: New Version Notification fordraft-marques-sdnp-flow-spec-00.txt Thread-Index: AcyIOlfq4gTE8jqgSq2sbmqVNkMpdQAADtqA References: <20111011042629.1343.88114.idtracker@ietfa.amsl.com><6B71CDDD-F2E5-45EC-A0C9-B06F6C95B03C@lucidvision.com><4E947703.6060501@kot-begemot.co.uk> From: "Luyuan Fang (lufang)" To: "Pedro Marques" , "Anton Ivanov" X-OriginalArrivalTime: 11 Oct 2011 17:26:58.0614 (UTC) FILETIME=[FAEBCD60:01CC883A] Cc: sdnp@lucidvision.com, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:27:00 -0000 Include l3vpn list here (under vpn4dc topic). > -----Original Message----- > From: sdnp-bounces@lucidvision.com [mailto:sdnp- > bounces@lucidvision.com] On Behalf Of Pedro Marques > Sent: Tuesday, October 11, 2011 1:22 PM > To: Anton Ivanov > Cc: sdnp@lucidvision.com > Subject: Re: [Sdnp] Fwd: New Version Notification fordraft-marques- > sdnp-flow-spec-00.txt >=20 > Anton, > In my view the requirements for the client to server channel are: > - persistent sessions. > - mutual authentication. > - transport arbitrary xml schema. > - publish / subscribe semantics. >=20 > In my opinion, XMPP was the most reusable component out there. There > are client libraries available, and i don't believe the developers > would really care so much about the transport, as > long as that transport does the job. >=20 > The APIs that are presented in the documents are targeted at the Host > OS infrastructure software. These are not APIs targeted at the > end-user application running on top of the guest VM. For the later, > e.g. an ALTO API that provides access to network distance, REST would > probably be a better choice. >=20 > That said, i believe that in the IETF choice is considered to be a > good thing. I suspect that most people would welcome a REST API that > has the same capabilities described in the drafts. That would allow > implementors to decide on either or both of these APIs. >=20 > regards, > Pedro. >=20 > On Tue, Oct 11, 2011 at 10:04 AM, Anton Ivanov > wrote: > > XMPP is the only other obvious candidate for stuff like this besides > REST. > > > > Personally, I think that Joe Average Developer will prefer REST. It > is > > something the developer's community understands and likes. > > > > If however, for whatever reason, we decide that REST does not fit = the > bill, > > the next in line IMO is XMPP - it allows you to ferry structured = data > with > > authentication, authorisation, replication, high availability, etc > from > > point A to point B and there are libraries and APIs for most > platforms. > > > > So it is rather unsurprising that it comes up in this context. > > > > In any case, we can look at XMPP as a possible plugin protocol :) > > > > My 2c. > > > > Brgds, > > > > On 11/10/11 17:28, Pedro Marques wrote: > >> > >> Tom, > >> In terms of fit within a broader context, my understanding is that > >> these proposals are largely inline with the SDN ecosystem/vision. > The > >> following are some of the underlying assumptions which i believe = are > >> inline with the "sdnp" documents: > >> > >> =A0 - There is the assumption that VM provisioning is performed by = an > >> orchestration system. This orchestration system has a notion of > >> user/tenant and which services the tenant is allowed to access. > >> > >> =A0 - The orchestration system allocates a "sticky" IP address per = VM; > >> when a VM =A0is provisioned, the (VPN IP address, vpn-name) is = passed > >> along to the host OS. > >> > >> =A0 - There is a centralized data-base (possibly with a distributed > >> implementation) that contains the provisioning information = regarding > >> vpn-names and the services they are able to access. This database > >> schema is standardized and signaling gateways are able to retrieve > the > >> vpn configuration from this database. The orchestration system is > most > >> likely the publisher. > >> > >> =A0 - Advanced functionality such as fine grain traffic policies is > able > >> to inject rules into the network by pushing information through the > >> XMPP interface. > >> > >> =A0 - The network operates independently from applications and > >> orchestration. But the network signaling works as a "message bus" = to > >> which the orchestration layer can push information to and also > receive > >> information from. > >> > >> =A0 - It is important to leverage other IETF standards. For = instance > the > >> virtualized network solution should support an ALTO API for > >> application to access network distance information. > >> > >> In my mind these proposals are one possible approach to implement > what > >> is most likely the most immediate problem in the SDN space. It is = my > >> belief that by reusing existing standards, that multiple > interoperable > >> implementation can surface in a short period of time. And in my > >> opinion they are a natural progression of the SDN work so far. But = i > >> do apologize in advance in case i misinterpreted the existing SDN > >> architecture. > >> > >> regards, > >> =A0 Pedro > >> > >> On Tue, Oct 11, 2011 at 6:20 AM, Thomas > Nadeau > >> =A0wrote: > >> > >>> > >>> Pedro thanks for the update. =A0I have a question about your = draft. > =A0Can > >>> you explain how it differs from similar use cases that were > discussed and > >>> also how it applies to the proposed architecture for SDN either in > its > >>> current form or modified? > >>> > >>> Tom > >>> > >>> Sent from my iPad > >>> > >>> On Oct 11, 2011, at 12:30 AM, Pedro > Marques > >>> =A0wrote: > >>> > >>> > >>>> > >>>> I posted a new draft that complements the end-system VPN proposal > by > >>>> adding support for fine grain traffic classification policies. > >>>> I hope it merits your attention. > >>>> > >>>> regards, > >>>> =A0Pedro. > >>>> > >>>> > >>>> ---------- Forwarded message ---------- > >>>> From: > >>>> Date: Mon, Oct 10, 2011 at 9:26 PM > >>>> Subject: New Version Notification for > >>>> draft-marques-sdnp-flow-spec-00.txt > >>>> To: pedro.r.marques@gmail.com > >>>> Cc: pedro.r.marques@gmail.com, ppan@infinera.com, > lufang@cisco.com, > >>>> amit@juniper.net > >>>> > >>>> > >>>> A new version of I-D, draft-marques-sdnp-flow-spec-00.txt has = been > >>>> successfully submitted by Pedro Marques and posted to the IETF > >>>> repository. > >>>> > >>>> Filename: =A0 =A0 =A0 =A0draft-marques-sdnp-flow-spec > >>>> Revision: =A0 =A0 =A0 =A000 > >>>> Title: =A0 =A0 =A0 =A0 =A0 Traffic classification, filtering and = redirection > for > >>>> end-system IP VPNs. > >>>> Creation date: =A0 2011-10-11 > >>>> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission > >>>> Number of pages: 15 > >>>> > >>>> Abstract: > >>>> =A0 When IP VPNs are used to interconnect end-systems > >>>> =A0 [I-D.marques-l3vpn-end-system] it may be desirable to = introduce > >>>> =A0 traffic control rules at a finer level of granularity than an = IP > >>>> =A0 destination address. > >>>> > >>>> =A0 This document extends the end-system IP VPN specification = with > >>>> =A0 support for fine grain traffic classification, filtering and > >>>> =A0 redirection rules. =A0It applies the existing BGP IP VPN flow > >>>> =A0 specification dissemination mechanism [RFC5575] to end-system = IP > VPNs > >>>> =A0 in order to provide the ability to control IP packets that = match > a > >>>> =A0 specific pattern, which may include fields other than the IP > >>>> =A0 destination address. > >>>> > >>>> > >>>> > >>>> > >>>> The IETF Secretariat > >>>> _______________________________________________ > >>>> SDNP mailing list > >>>> SDNP@lucidvision.com > >>>> http://lucidvision.com/mailman/listinfo/sdnp > >>>> > >>>> > >>> > >>> > >> > >> _______________________________________________ > >> SDNP mailing list > >> SDNP@lucidvision.com > >> http://lucidvision.com/mailman/listinfo/sdnp > >> > >> > > > > > > -- > > =A0 =A0Humans are allergic to change. They love to say, "We've = always > > done it this way." I try to fight that. That's why I have a clock > > on my wall that runs counter-clockwise. =A0 -- R.A. Grace Hopper > > > > A. R. Ivanov > > E-mail: =A0anton.ivanov@kot-begemot.co.uk > > > > _______________________________________________ > > SDNP mailing list > > SDNP@lucidvision.com > > http://lucidvision.com/mailman/listinfo/sdnp > > > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp From ben@niven-jenkins.co.uk Tue Oct 11 11:12:39 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33F721F8E24 for ; Tue, 11 Oct 2011 11:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_32=0.6, 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 0aOgM0y5dGEp for ; Tue, 11 Oct 2011 11:12:38 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3C32521F8CBB for ; Tue, 11 Oct 2011 11:12:38 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RDgoe-0007Zr-Lk; Tue, 11 Oct 2011 19:12:37 +0100 Subject: Re: VPN4DC at L3VPN in Taipei Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <238542D917511A45B6B8AA806E875E250709B7CF@XMB-RCD-201.cisco.com> Date: Tue, 11 Oct 2011 19:12:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3B6CD5F5-9510-487E-AC30-575CE1B7427B@niven-jenkins.co.uk> References: <238542D917511A45B6B8AA806E875E250709B7CF@XMB-RCD-201.cisco.com> To: Luyuan Fang (lufang) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:12:39 -0000 Luyuan, Some comments inline. On 11 Oct 2011, at 08:36, Luyuan Fang (lufang) wrote: > As Marshall indicated last week: VPN4DC will be discussed in the L3VPN > WG meeting in Taipei per Routing ADs' arrangement.=20 > There will be no BOF. > I am posting the VPN4DC BOF proposal (provided to AD on 10/2/2011) = here > for the record.=20 > Hope this helps to provide additional background information, and > attract more interested participants. > VPN4DC BOF Proposal: >=20 > Working Group Name: Virtual Private Networks for Data Centers (VPN4DC) > IETF Area: Routing Area > Routing Area Director: Stewart Bryant (stbryant@cisco.com) > Description of the Working Group: >=20 > The purpose of the VPN4DC is to define requirements and solutions for > establishing end-to-end (host-to-host) connectivity through layer 3 = VPN > for Data Center and Cloud Services.=20 >=20 > (Note: The term layer 3 VPN here implies any type of IP technologies = for > VPN. For example, IP VPN, BGP/MPLS VPN, or the combination of = different > types of layer 3 VPNs to form end-to-end VPN solutions. These VPNs may > or may not be provisioned by Service Providers.) >=20 > Today when Data Centers are inter-connected through VPNs or other WAN > networks, the provisioning process for cloud services cross Service > Providers' and Enterprise's Data Centers, or cross different Service > Providers' Data Centers, is often manual, with long turn up time. > Security, scalability, and operational efficiency are issues due to = lack > of standardized host-to-host VPN solutions.=20 > Modern data-centers require multi-tenant support for applications. For > security and administrative reasons it is desirable to isolate the > resources associated with a particular tenant in a VPN. This workgroup > will propose standard mechanisms to provide Layer 3 VPN connectivity = to > end-systems while meeting scaling and manageability goals. This WG = will > define requirements and protocol solutions to enable hosts in a Data > Center to join a specific Layer 3 VPN automatically through control > protocols, using Layer 3 VPN to provide secure any to any connections. > The Layer 3 VPN Gateway function which provides seamless VPN > connectivity between the segments of the networks will be defined. >=20 > In addition to proposing one or more layer 3 VPN technologies which > support(s) end-systems, the WG will focus on interoperability between > inter and intra DC VPN technologies and in making the VPN network > topology information available and controllable by applications. >=20 > Both of the following scenarios will be in scope: >=20 > 1. When VPN management system and Data Center management system can > communicate with each other, the WG will identify the requirement and > protocols to automatically enable hosts in a Data Center to join a > specific VPN=20 >=20 > 2. When VPN management system and Data Center management system > can't communicate (which is often the case), the WG will identify the > requirement and protocols to automatically enable hosts in a Data = Center > to join a specific VPN.=20 > The scope of the charter is limited to Layer 3 VPN solutions for Data > Center and Cloud Services with end-to-end connectivity.=20 I will admit I may not have read all the related drafts but IMO it would = be good if the proposal or the drafts could be more explicit with regard = to what functionality is already performed by L3VPN, what functionality = is missing but you think comes under the remit of L3VPN and what = functionality is required but is (at least currently) out of scope for = L3VPN. For example, (and I may have got the wrong end of the stick here) but my = understanding from what I have read is that the goal is to interconnect = machines (virtual or physical) in data centers via L3VPNs to other = machines (virtual or physical) in the same or different data centers = while also considering that those machines may move over time due to any = number of reasons. Today a customer of a VPN service can advertise which IP addresses are = in which sites attached to that VPN service using a routing protocol = over the CE-PE link (e.g. via OSPF) and that information is reflected to = the relevant PEs in that VPN service using MP-BGP. It would be useful IMO if you could describe why that is not sufficient = for your needs and how the current capabilities of L3VPNs map (or do = not) to your needs. Is it just that the "CE" is no longer the access = router for a VPN site but now starts to be implemented within a = switch/router/hypervisor sat behind the access router? Is it that the CE = (access router) still advertises routing to the PE as it would today but = you are proposing some additional mechanism for installing state into = switches/routers/hypervisors behind that CE and for how those = switches/routers/hypervisors advertise that state to the CE for onward = advertisement (by existing L3VPN mechanisms) to the upstream PE for that = VPN site? Is it that the existing CE-PE advertisement mechanisms are = unsuitable for some reason and a new CE-PE protocol is required? etc. >=20 > Non-goals: Layer 2 connectivity, and layer 3 Multicast. >=20 > The design principle for the protocols and solution development is to > leverage existing layer 3 VPN technologies already defined in IETF > whenever possible, including various IP and MPLS technologies. This > charter supports the creation of new protocols, extension to existing > protocols, and solutions proposed to use new and existing protocols. > When extending existing protocols, this WG will work with the WG(s) > responsible for the protocol being extended.=20 >=20 > BOF Agenda for IETF 82 > November, 2011, Taibei > - Discuss and agree on charter definitions: problems space, scope, > requirements, candidate solutions, general interests, encourage > participation from DC groups and from SP groups > - Present initial draft of problem statements > - Present initial draft of requirements > - Present initial draft of use cases > - Present one or more initial draft(s) of protocol solution(s) While the topics above are valid topics to discuss I think it would also = be beneficial to include specific aims for what you think the meeting = should achieve beyond just presenting drafts and discussing material. For example: - Is the aim to discuss the work in general and receive feedback on it = from the IETF community but nothing further at this stage? - Is the aim to determine if there is consensus that the work is work = that is required and should be taken on by IETF? - Is the aim to determine if the work does/does not fit within the scope = of L3VPN? - etc (including some combination of the above). > Goals and Milestones for the proposed Working Group I think this list is far too long and likely to end up with any related = discussion becoming unfocussed. Furthermore some of the milestones are = pretty vague and essentially consist of "submit some more stuff for = publication". I'd suggest cutting it down considerably and focussing it on the most = important items required to articulate the problem space, requirements & = solutions in order to do something meaningful as a first step and have = the scope/charter/problem space drafts describe why that initial focus = is what you are proposing it should be in order to firstly help focus = any discussions on the most important elements in order to reduce the = risk of significant tangential discussions and secondly in order to = demonstrate that there is a clear focus/outcome that you can envisage = and that this is not intended to be an open ended project without clear = goals and without any definition of when an acceptable (first stage) = "end game" result has been achieved. I'm happy to work with you (and I'm sure Marshall is too) either on the = list of off-list (before bringing it back to the list to invite = additional discussion on any changes) to iterate your proposal and the = structure of the agenda/charter/milestones to try and ensure the = discussion and outcome of the meeting is as fruitful as possible for = you. Ben >=20 > March 2012 Post strawman WG goals and charter description > March 2012 Identify and document a limited set of candidate L3 VPN > solutions for DC > March 2012 Build small design teams for each proposed solution and > requirement doc > March 2012 Submit additional protocol definition draft(s)=20 > July 2012 Submit problem statements, use case, and requirement > drafts as WG documents > July 2012 Submit initial draft of Framework document > July 2012 Submit protocol solutions as WG documents=20 > July 2012 Design teams to narrow down to small set of solutions > to be focused by WG > July 2012 Submit applicability statements for solutions proposed >=20 > July 2012 Post modified WG goals and charter with more details on > solutions and timelines > Nov. 2012 Submit problem statements, use cases, and requirements > draft to IESG for review > Nov. 2012 Submit the protocol solutions to IESG for review > Nov. 2012 Submit Framework document as WG document > Nov. 2012 Submit applicability statements as WG documents=20 > Nov. 2012 Submit more protocol solutions as WG documents=20 > Nov. 2012 Submit initial OAM drafts=20 > Nov. 2012 Submit initial discovery protocol drafts > Nov. 2012 Submit initial security framework draft > Nov. 2012 Submit initial MIB drafts=20 > March 2013 Submit framework draft to IESG for review > March 2013 Submit more protocol solutions and applicability > drafts to IESG for review > March 2013 Submit OAM drafts as WG document > March 2013 Submit more protocols and applicability drafts as WG > document > March 2013 Post modified charter based on the progress of the WG > July 2013 Submit more protocol solutions and applicability drafts = to > IESG for review > July 2013 Submit more protocol solutions and applicability drafts = as > WG doc > July 2013 Submit security framework draft as WG document=20 > July 2013 Submit discovery protocol drafts as WG documents > July 2013 Submit MIB drafts as WG documents > July 2013 Submit more protocols and applicability drafts =20 > Nov. 2013 Submit OAM drafts for IESG review=20 > Nov. 2013 Submit discovery protocol drafts for IESG review > Nov. 2013 Submit more protocol solutions and applicability > drafts to IESG for review > Nov. 2013 Submit more protocol solutions and applicability drafts = as > WG doc > Nov 2013 Submit Inter-op report > Nov 2013 Post modified charter based on the progress of the WG=20= > March 2014 Submit security framework draft for IESG review > March 2014 Submit MIB drafts for IESG review > March 2014 Submit more protocol solutions and applicability > drafts to IESG for review >=20 > In addition to the meeting in L3VPN WG session, we will also hold Bar > BOF meeting(s) in Taipei for those who are interested working on the > subject to discuss and work together.=20 >=20 > Thanks, > Luyuan >=20 >=20 >=20 >> = ---------------------------------------------------------------------- >>=20 >> Message: 1 >> Date: Tue, 4 Oct 2011 14:20:30 -0400 >> From: Marshall Eubanks >> To: L3VPN , lufang@cisco.com, Adrian Farrel >> >> Subject: VPN4DC at L3VPN in Taipei. >> Message-ID: >> > 3yiUOfMpq_QaP17fBA7EBrR5r14NP+T9ZL62bKrdvw@mail.gmail.com> >> Content-Type: text/plain; charset=3DISO-8859-1 >>=20 >> Stewart Bryant has requested that we hold an L3VPN meeting at IETF 82 >> to consider and discuss VPN4DC. >> Specifically, we would >>=20 >> "need to emerge understanding the problem, >> the usage, the requirements, and the necessary charter changes." >>=20 >> This would be preparation for VPN4DC becoming a BOF. >>=20 >> Adrian set up some requirements for this meeting : >>=20 >> The problem needs to be discussed on the L3VPN list. >>=20 >> You need to have viable -00 drafts before the cutoff. >>=20 >> Luyuan Fang has promised a draft before the cutoff. >>=20 >> If there is not significant discussion here on this issue, the = session >> is likely to be canceled. >>=20 >> Please keep discussion of VPN4DC here on the L3VPN list. >>=20 >> Due to the tentative nature and special purpose of this meeting I >> don't think it is appropriate to make >> a general call for papers. However, if you would like to speak on >> VPN4DC, please prepare a draft and let us (the WG Co-chairs) know. >>=20 >> Regards >> Marshall >>=20 >> P.S. Some background : >>=20 >> http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) >> http://tools.ietf.org/id/draft-so-vdcs-01.txt >>=20 >>=20 >> ------------------------------ >>=20 >> Message: 2 >> Date: Tue, 4 Oct 2011 13:36:06 -0500 >> From: "Luyuan Fang (lufang)" >> To: "Marshall Eubanks" , "L3VPN" >> , "Adrian Farrel" >> Subject: RE: VPN4DC at L3VPN in Taipei. >> Message-ID: >> <238542D917511A45B6B8AA806E875E2507005EA9@XMB-RCD-201.cisco.com> >> Content-Type: text/plain; charset=3D"us-ascii" >>=20 >> Marshall, >>=20 >> I forwarded your mail to folks currently working on / interested in >> vpn4dc project. >> Thanks, >> Luyuan >>=20 >>=20 >>> -----Original Message----- >>> From: Marshall Eubanks [mailto:marshall.eubanks@gmail.com] >>> Sent: Tuesday, October 04, 2011 2:21 PM >>> To: L3VPN; Luyuan Fang (lufang); Adrian Farrel >>> Subject: VPN4DC at L3VPN in Taipei. >>>=20 >>> Stewart Bryant has requested that we hold an L3VPN meeting at IETF > 82 >>> to consider and discuss VPN4DC. >>> Specifically, we would >>>=20 >>> "need to emerge understanding the problem, >>> the usage, the requirements, and the necessary charter changes." >>>=20 >>> This would be preparation for VPN4DC becoming a BOF. >>>=20 >>> Adrian set up some requirements for this meeting : >>>=20 >>> The problem needs to be discussed on the L3VPN list. >>>=20 >>> You need to have viable -00 drafts before the cutoff. >>>=20 >>> Luyuan Fang has promised a draft before the cutoff. >>>=20 >>> If there is not significant discussion here on this issue, the >> session >>> is likely to be canceled. >>>=20 >>> Please keep discussion of VPN4DC here on the L3VPN list. >>>=20 >>> Due to the tentative nature and special purpose of this meeting I >>> don't think it is appropriate to make >>> a general call for papers. However, if you would like to speak on >>> VPN4DC, please prepare a draft and let us (the WG Co-chairs) know. >>>=20 >>> Regards >>> Marshall >>>=20 >>> P.S. Some background : >>>=20 >>> http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) >>> http://tools.ietf.org/id/draft-so-vdcs-01.txt >>=20 >>=20 >> ------------------------------ >>=20 >> _______________________________________________ >> L3VPN mailing list >> L3VPN@ietf.org >> https://www.ietf.org/mailman/listinfo/l3vpn >>=20 >>=20 >> End of L3VPN Digest, Vol 88, Issue 2 >> ************************************ From tnadeau@lucidvision.com Tue Oct 11 11:46:37 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3176221F8F04 for ; Tue, 11 Oct 2011 11:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 6HqCQUnVoxzT for ; Tue, 11 Oct 2011 11:46:36 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 72EF121F8E2D for ; Tue, 11 Oct 2011 11:46:31 -0700 (PDT) Received: from [10.100.69.9] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id 5FDD31ECFE40; Tue, 11 Oct 2011 14:46:30 -0400 (EDT) Subject: Re: [Sdnp] Fwd: New Version Notification for draft-marques-sdnp-flow-spec-00.txt Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <4E947703.6060501@kot-begemot.co.uk> Date: Tue, 11 Oct 2011 14:46:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8F569725-D5E4-4C20-BF18-483E946C98D0@lucidvision.com> References: <20111011042629.1343.88114.idtracker@ietfa.amsl.com> <6B71CDDD-F2E5-45EC-A0C9-B06F6C95B03C@lucidvision.com> <4E947703.6060501@kot-begemot.co.uk> To: Anton Ivanov X-Mailer: Apple Mail (2.1244.3) Cc: sdnp@lucidvision.com, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:46:37 -0000 [Adding cross-post to l3vpn] > XMPP is the only other obvious candidate for stuff like this besides = REST. >=20 > Personally, I think that Joe Average Developer will prefer REST. It is = something the developer's community understands and likes. >=20 > If however, for whatever reason, we decide that REST does not fit the = bill, the next in line IMO is XMPP - it allows you to ferry structured = data with authentication, authorisation, replication, high availability, = etc from point A to point B and there are libraries and APIs for most = platforms. >=20 > So it is rather unsurprising that it comes up in this context. >=20 > In any case, we can look at XMPP as a possible plugin protocol :) Yes, I agree. We need to consider other non-ReST interfaces. = This was something expressed during the Bar BoF in Quebec, and is = something I've heard since.=20 --Tom >=20 > My 2c. >=20 > Brgds, >=20 > On 11/10/11 17:28, Pedro Marques wrote: >> Tom, >> In terms of fit within a broader context, my understanding is that >> these proposals are largely inline with the SDN ecosystem/vision. The >> following are some of the underlying assumptions which i believe are >> inline with the "sdnp" documents: >>=20 >> - There is the assumption that VM provisioning is performed by an >> orchestration system. This orchestration system has a notion of >> user/tenant and which services the tenant is allowed to access. >>=20 >> - The orchestration system allocates a "sticky" IP address per VM; >> when a VM is provisioned, the (VPN IP address, vpn-name) is passed >> along to the host OS. >>=20 >> - There is a centralized data-base (possibly with a distributed >> implementation) that contains the provisioning information regarding >> vpn-names and the services they are able to access. This database >> schema is standardized and signaling gateways are able to retrieve = the >> vpn configuration from this database. The orchestration system is = most >> likely the publisher. >>=20 >> - Advanced functionality such as fine grain traffic policies is = able >> to inject rules into the network by pushing information through the >> XMPP interface. >>=20 >> - The network operates independently from applications and >> orchestration. But the network signaling works as a "message bus" to >> which the orchestration layer can push information to and also = receive >> information from. >>=20 >> - It is important to leverage other IETF standards. For instance = the >> virtualized network solution should support an ALTO API for >> application to access network distance information. >>=20 >> In my mind these proposals are one possible approach to implement = what >> is most likely the most immediate problem in the SDN space. It is my >> belief that by reusing existing standards, that multiple = interoperable >> implementation can surface in a short period of time. And in my >> opinion they are a natural progression of the SDN work so far. But i >> do apologize in advance in case i misinterpreted the existing SDN >> architecture. >>=20 >> regards, >> Pedro >>=20 >> On Tue, Oct 11, 2011 at 6:20 AM, Thomas = Nadeau wrote: >> =20 >>> Pedro thanks for the update. I have a question about your draft. = Can you explain how it differs from similar use cases that were = discussed and also how it applies to the proposed architecture for SDN = either in its current form or modified? >>>=20 >>> Tom >>>=20 >>> Sent from my iPad >>>=20 >>> On Oct 11, 2011, at 12:30 AM, Pedro = Marques wrote: >>>=20 >>> =20 >>>> I posted a new draft that complements the end-system VPN proposal = by >>>> adding support for fine grain traffic classification policies. >>>> I hope it merits your attention. >>>>=20 >>>> regards, >>>> Pedro. >>>>=20 >>>>=20 >>>> ---------- Forwarded message ---------- >>>> From: >>>> Date: Mon, Oct 10, 2011 at 9:26 PM >>>> Subject: New Version Notification for = draft-marques-sdnp-flow-spec-00.txt >>>> To: pedro.r.marques@gmail.com >>>> Cc: pedro.r.marques@gmail.com, ppan@infinera.com, lufang@cisco.com, >>>> amit@juniper.net >>>>=20 >>>>=20 >>>> A new version of I-D, draft-marques-sdnp-flow-spec-00.txt has been >>>> successfully submitted by Pedro Marques and posted to the IETF >>>> repository. >>>>=20 >>>> Filename: draft-marques-sdnp-flow-spec >>>> Revision: 00 >>>> Title: Traffic classification, filtering and redirection = for >>>> end-system IP VPNs. >>>> Creation date: 2011-10-11 >>>> WG ID: Individual Submission >>>> Number of pages: 15 >>>>=20 >>>> Abstract: >>>> When IP VPNs are used to interconnect end-systems >>>> [I-D.marques-l3vpn-end-system] it may be desirable to introduce >>>> traffic control rules at a finer level of granularity than an IP >>>> destination address. >>>>=20 >>>> This document extends the end-system IP VPN specification with >>>> support for fine grain traffic classification, filtering and >>>> redirection rules. It applies the existing BGP IP VPN flow >>>> specification dissemination mechanism [RFC5575] to end-system IP = VPNs >>>> in order to provide the ability to control IP packets that match = a >>>> specific pattern, which may include fields other than the IP >>>> destination address. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>> _______________________________________________ >>>> SDNP mailing list >>>> SDNP@lucidvision.com >>>> http://lucidvision.com/mailman/listinfo/sdnp >>>>=20 >>>> =20 >>> =20 >> _______________________________________________ >> SDNP mailing list >> SDNP@lucidvision.com >> http://lucidvision.com/mailman/listinfo/sdnp >>=20 >> =20 >=20 >=20 > --=20 > Humans are allergic to change. They love to say, "We've always > done it this way." I try to fight that. That's why I have a clock > on my wall that runs counter-clockwise. -- R.A. Grace Hopper >=20 > A. R. Ivanov > E-mail: anton.ivanov@kot-begemot.co.uk >=20 > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp >=20 From tnadeau@lucidvision.com Tue Oct 11 11:48:54 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E8D21F8F58 for ; Tue, 11 Oct 2011 11:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, J_CHICKENPOX_13=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 X916a-ivIF8Q for ; Tue, 11 Oct 2011 11:48:53 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 659CF21F8E2D for ; Tue, 11 Oct 2011 11:48:52 -0700 (PDT) Received: from [10.100.69.9] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id A7EBD1ECFF08; Tue, 11 Oct 2011 14:48:51 -0400 (EDT) Subject: Re: [Sdnp] Fwd: New Version Notification for draft-marques-sdnp-flow-spec-00.txt Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Nadeau In-Reply-To: Date: Tue, 11 Oct 2011 14:48:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0BF2104A-044A-459C-9122-181780EAE3D4@lucidvision.com> References: <20111011042629.1343.88114.idtracker@ietfa.amsl.com> <6B71CDDD-F2E5-45EC-A0C9-B06F6C95B03C@lucidvision.com> <4E947703.6060501@kot-begemot.co.uk> To: Pedro Marques X-Mailer: Apple Mail (2.1244.3) Cc: sdnp@lucidvision.com, Anton Ivanov , l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:48:54 -0000 [Cross-post to l3vpn again. Please include this in future posts.] On Oct 11, 2011, at 1:21 PM, Pedro Marques wrote: > Anton, > In my view the requirements for the client to server channel are: > - persistent sessions. > - mutual authentication. > - transport arbitrary xml schema. > - publish / subscribe semantics. The other thing we need is asynchronous notification. > In my opinion, XMPP was the most reusable component out there. There > are client libraries available, and i don't believe the developers > would really care so much about the transport, as > long as that transport does the job. >=20 > The APIs that are presented in the documents are targeted at the Host > OS infrastructure software. These are not APIs targeted at the > end-user application running on top of the guest VM. For the later, > e.g. an ALTO API that provides access to network distance, REST would > probably be a better choice. Although please keep in mind that it is a very real possibility = that some SDN components are running on VMs, including routers/switches/NAT gateways, = etc... > That said, i believe that in the IETF choice is considered to be a > good thing. I suspect that most people would welcome a REST API that > has the same capabilities described in the drafts. That would allow > implementors to decide on either or both of these APIs. Agreed. --Tom >=20 > regards, > Pedro. >=20 > On Tue, Oct 11, 2011 at 10:04 AM, Anton Ivanov > wrote: >> XMPP is the only other obvious candidate for stuff like this besides = REST. >>=20 >> Personally, I think that Joe Average Developer will prefer REST. It = is >> something the developer's community understands and likes. >>=20 >> If however, for whatever reason, we decide that REST does not fit the = bill, >> the next in line IMO is XMPP - it allows you to ferry structured data = with >> authentication, authorisation, replication, high availability, etc = from >> point A to point B and there are libraries and APIs for most = platforms. >>=20 >> So it is rather unsurprising that it comes up in this context. >>=20 >> In any case, we can look at XMPP as a possible plugin protocol :) >>=20 >> My 2c. >>=20 >> Brgds, >>=20 >> On 11/10/11 17:28, Pedro Marques wrote: >>>=20 >>> Tom, >>> In terms of fit within a broader context, my understanding is that >>> these proposals are largely inline with the SDN ecosystem/vision. = The >>> following are some of the underlying assumptions which i believe are >>> inline with the "sdnp" documents: >>>=20 >>> - There is the assumption that VM provisioning is performed by an >>> orchestration system. This orchestration system has a notion of >>> user/tenant and which services the tenant is allowed to access. >>>=20 >>> - The orchestration system allocates a "sticky" IP address per VM; >>> when a VM is provisioned, the (VPN IP address, vpn-name) is passed >>> along to the host OS. >>>=20 >>> - There is a centralized data-base (possibly with a distributed >>> implementation) that contains the provisioning information regarding >>> vpn-names and the services they are able to access. This database >>> schema is standardized and signaling gateways are able to retrieve = the >>> vpn configuration from this database. The orchestration system is = most >>> likely the publisher. >>>=20 >>> - Advanced functionality such as fine grain traffic policies is = able >>> to inject rules into the network by pushing information through the >>> XMPP interface. >>>=20 >>> - The network operates independently from applications and >>> orchestration. But the network signaling works as a "message bus" to >>> which the orchestration layer can push information to and also = receive >>> information from. >>>=20 >>> - It is important to leverage other IETF standards. For instance = the >>> virtualized network solution should support an ALTO API for >>> application to access network distance information. >>>=20 >>> In my mind these proposals are one possible approach to implement = what >>> is most likely the most immediate problem in the SDN space. It is my >>> belief that by reusing existing standards, that multiple = interoperable >>> implementation can surface in a short period of time. And in my >>> opinion they are a natural progression of the SDN work so far. But i >>> do apologize in advance in case i misinterpreted the existing SDN >>> architecture. >>>=20 >>> regards, >>> Pedro >>>=20 >>> On Tue, Oct 11, 2011 at 6:20 AM, Thomas = Nadeau >>> wrote: >>>=20 >>>>=20 >>>> Pedro thanks for the update. I have a question about your draft. = Can >>>> you explain how it differs from similar use cases that were = discussed and >>>> also how it applies to the proposed architecture for SDN either in = its >>>> current form or modified? >>>>=20 >>>> Tom >>>>=20 >>>> Sent from my iPad >>>>=20 >>>> On Oct 11, 2011, at 12:30 AM, Pedro = Marques >>>> wrote: >>>>=20 >>>>=20 >>>>>=20 >>>>> I posted a new draft that complements the end-system VPN proposal = by >>>>> adding support for fine grain traffic classification policies. >>>>> I hope it merits your attention. >>>>>=20 >>>>> regards, >>>>> Pedro. >>>>>=20 >>>>>=20 >>>>> ---------- Forwarded message ---------- >>>>> From: >>>>> Date: Mon, Oct 10, 2011 at 9:26 PM >>>>> Subject: New Version Notification for >>>>> draft-marques-sdnp-flow-spec-00.txt >>>>> To: pedro.r.marques@gmail.com >>>>> Cc: pedro.r.marques@gmail.com, ppan@infinera.com, = lufang@cisco.com, >>>>> amit@juniper.net >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-marques-sdnp-flow-spec-00.txt has been >>>>> successfully submitted by Pedro Marques and posted to the IETF >>>>> repository. >>>>>=20 >>>>> Filename: draft-marques-sdnp-flow-spec >>>>> Revision: 00 >>>>> Title: Traffic classification, filtering and redirection = for >>>>> end-system IP VPNs. >>>>> Creation date: 2011-10-11 >>>>> WG ID: Individual Submission >>>>> Number of pages: 15 >>>>>=20 >>>>> Abstract: >>>>> When IP VPNs are used to interconnect end-systems >>>>> [I-D.marques-l3vpn-end-system] it may be desirable to introduce >>>>> traffic control rules at a finer level of granularity than an IP >>>>> destination address. >>>>>=20 >>>>> This document extends the end-system IP VPN specification with >>>>> support for fine grain traffic classification, filtering and >>>>> redirection rules. It applies the existing BGP IP VPN flow >>>>> specification dissemination mechanism [RFC5575] to end-system IP = VPNs >>>>> in order to provide the ability to control IP packets that match = a >>>>> specific pattern, which may include fields other than the IP >>>>> destination address. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>> _______________________________________________ >>>>> SDNP mailing list >>>>> SDNP@lucidvision.com >>>>> http://lucidvision.com/mailman/listinfo/sdnp >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> SDNP mailing list >>> SDNP@lucidvision.com >>> http://lucidvision.com/mailman/listinfo/sdnp >>>=20 >>>=20 >>=20 >>=20 >> -- >> Humans are allergic to change. They love to say, "We've always >> done it this way." I try to fight that. That's why I have a clock >> on my wall that runs counter-clockwise. -- R.A. Grace Hopper >>=20 >> A. R. Ivanov >> E-mail: anton.ivanov@kot-begemot.co.uk >>=20 >> _______________________________________________ >> SDNP mailing list >> SDNP@lucidvision.com >> http://lucidvision.com/mailman/listinfo/sdnp >>=20 > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp >=20 From tnadeau@lucidvision.com Tue Oct 11 11:49:55 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCB821F8F59 for ; Tue, 11 Oct 2011 11:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 2NpL8tKB369C for ; Tue, 11 Oct 2011 11:49:54 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4C421F8F04 for ; Tue, 11 Oct 2011 11:49:54 -0700 (PDT) Received: from [10.100.69.9] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id 931BA1ECFF56; Tue, 11 Oct 2011 14:49:53 -0400 (EDT) Subject: Re: [Sdnp] Fwd: New Version Notification for draft-marques-sdnp-flow-spec-00.txt Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <4E9484D1.3050906@kot-begemot.co.uk> Date: Tue, 11 Oct 2011 14:49:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111011042629.1343.88114.idtracker@ietfa.amsl.com> <6B71CDDD-F2E5-45EC-A0C9-B06F6C95B03C@lucidvision.com> <4E947703.6060501@kot-begemot.co.uk> <4E9484D1.3050906@kot-begemot.co.uk> To: Anton Ivanov X-Mailer: Apple Mail (2.1244.3) Cc: sdnp@lucidvision.com, l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:49:55 -0000 [Cross-post to l3vpn] On Oct 11, 2011, at 2:02 PM, Anton Ivanov wrote: > Hi Pedro, >=20 > First, you have inserted a requirement here on the fly - "arbitrary = xml schema". While that may be a good idea to describe a system or = transfer structured data it is not the only one. >=20 > Second, I understand you very well. The last several times I have = looked at similar problems (SDNI, etc) XMPP has always shown up as a = viable candidate. >=20 > It is however still too heavy for joe average developer. So IMO we = should give REST a first chance especially for the "north" API. >=20 > Brgds, >=20 > On 11/10/11 18:21, Pedro Marques wrote: >> Anton, >> In my view the requirements for the client to server channel are: >> - persistent sessions. >> - mutual authentication. >> - transport arbitrary xml schema. >> - publish / subscribe semantics. >>=20 >> In my opinion, XMPP was the most reusable component out there. There >> are client libraries available, and i don't believe the developers >> would really care so much about the transport, as >> long as that transport does the job. >>=20 >> The APIs that are presented in the documents are targeted at the Host >> OS infrastructure software. These are not APIs targeted at the >> end-user application running on top of the guest VM. For the later, >> e.g. an ALTO API that provides access to network distance, REST would >> probably be a better choice. >>=20 >> That said, i believe that in the IETF choice is considered to be a >> good thing. I suspect that most people would welcome a REST API that >> has the same capabilities described in the drafts. That would allow >> implementors to decide on either or both of these APIs. >>=20 >> regards, >> Pedro. >>=20 >> On Tue, Oct 11, 2011 at 10:04 AM, Anton Ivanov >> wrote: >> =20 >>> XMPP is the only other obvious candidate for stuff like this besides = REST. >>>=20 >>> Personally, I think that Joe Average Developer will prefer REST. It = is >>> something the developer's community understands and likes. >>>=20 >>> If however, for whatever reason, we decide that REST does not fit = the bill, >>> the next in line IMO is XMPP - it allows you to ferry structured = data with >>> authentication, authorisation, replication, high availability, etc = from >>> point A to point B and there are libraries and APIs for most = platforms. >>>=20 >>> So it is rather unsurprising that it comes up in this context. >>>=20 >>> In any case, we can look at XMPP as a possible plugin protocol :) >>>=20 >>> My 2c. >>>=20 >>> Brgds, >>>=20 >>> On 11/10/11 17:28, Pedro Marques wrote: >>> =20 >>>> Tom, >>>> In terms of fit within a broader context, my understanding is that >>>> these proposals are largely inline with the SDN ecosystem/vision. = The >>>> following are some of the underlying assumptions which i believe = are >>>> inline with the "sdnp" documents: >>>>=20 >>>> - There is the assumption that VM provisioning is performed by an >>>> orchestration system. This orchestration system has a notion of >>>> user/tenant and which services the tenant is allowed to access. >>>>=20 >>>> - The orchestration system allocates a "sticky" IP address per = VM; >>>> when a VM is provisioned, the (VPN IP address, vpn-name) is passed >>>> along to the host OS. >>>>=20 >>>> - There is a centralized data-base (possibly with a distributed >>>> implementation) that contains the provisioning information = regarding >>>> vpn-names and the services they are able to access. This database >>>> schema is standardized and signaling gateways are able to retrieve = the >>>> vpn configuration from this database. The orchestration system is = most >>>> likely the publisher. >>>>=20 >>>> - Advanced functionality such as fine grain traffic policies is = able >>>> to inject rules into the network by pushing information through the >>>> XMPP interface. >>>>=20 >>>> - The network operates independently from applications and >>>> orchestration. But the network signaling works as a "message bus" = to >>>> which the orchestration layer can push information to and also = receive >>>> information from. >>>>=20 >>>> - It is important to leverage other IETF standards. For instance = the >>>> virtualized network solution should support an ALTO API for >>>> application to access network distance information. >>>>=20 >>>> In my mind these proposals are one possible approach to implement = what >>>> is most likely the most immediate problem in the SDN space. It is = my >>>> belief that by reusing existing standards, that multiple = interoperable >>>> implementation can surface in a short period of time. And in my >>>> opinion they are a natural progression of the SDN work so far. But = i >>>> do apologize in advance in case i misinterpreted the existing SDN >>>> architecture. >>>>=20 >>>> regards, >>>> Pedro >>>>=20 >>>> On Tue, Oct 11, 2011 at 6:20 AM, Thomas = Nadeau >>>> wrote: >>>>=20 >>>> =20 >>>>> Pedro thanks for the update. I have a question about your draft. = Can >>>>> you explain how it differs from similar use cases that were = discussed and >>>>> also how it applies to the proposed architecture for SDN either in = its >>>>> current form or modified? >>>>>=20 >>>>> Tom >>>>>=20 >>>>> Sent from my iPad >>>>>=20 >>>>> On Oct 11, 2011, at 12:30 AM, Pedro = Marques >>>>> wrote: >>>>>=20 >>>>>=20 >>>>> =20 >>>>>> I posted a new draft that complements the end-system VPN proposal = by >>>>>> adding support for fine grain traffic classification policies. >>>>>> I hope it merits your attention. >>>>>>=20 >>>>>> regards, >>>>>> Pedro. >>>>>>=20 >>>>>>=20 >>>>>> ---------- Forwarded message ---------- >>>>>> From: >>>>>> Date: Mon, Oct 10, 2011 at 9:26 PM >>>>>> Subject: New Version Notification for >>>>>> draft-marques-sdnp-flow-spec-00.txt >>>>>> To: pedro.r.marques@gmail.com >>>>>> Cc: pedro.r.marques@gmail.com, ppan@infinera.com, = lufang@cisco.com, >>>>>> amit@juniper.net >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-marques-sdnp-flow-spec-00.txt has = been >>>>>> successfully submitted by Pedro Marques and posted to the IETF >>>>>> repository. >>>>>>=20 >>>>>> Filename: draft-marques-sdnp-flow-spec >>>>>> Revision: 00 >>>>>> Title: Traffic classification, filtering and = redirection for >>>>>> end-system IP VPNs. >>>>>> Creation date: 2011-10-11 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 15 >>>>>>=20 >>>>>> Abstract: >>>>>> When IP VPNs are used to interconnect end-systems >>>>>> [I-D.marques-l3vpn-end-system] it may be desirable to introduce >>>>>> traffic control rules at a finer level of granularity than an = IP >>>>>> destination address. >>>>>>=20 >>>>>> This document extends the end-system IP VPN specification with >>>>>> support for fine grain traffic classification, filtering and >>>>>> redirection rules. It applies the existing BGP IP VPN flow >>>>>> specification dissemination mechanism [RFC5575] to end-system = IP VPNs >>>>>> in order to provide the ability to control IP packets that = match a >>>>>> specific pattern, which may include fields other than the IP >>>>>> destination address. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF Secretariat >>>>>> _______________________________________________ >>>>>> SDNP mailing list >>>>>> SDNP@lucidvision.com >>>>>> http://lucidvision.com/mailman/listinfo/sdnp >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>=20 >>>>> =20 >>>> _______________________________________________ >>>> SDNP mailing list >>>> SDNP@lucidvision.com >>>> http://lucidvision.com/mailman/listinfo/sdnp >>>>=20 >>>>=20 >>>> =20 >>>=20 >>> -- >>> Humans are allergic to change. They love to say, "We've always >>> done it this way." I try to fight that. That's why I have a clock >>> on my wall that runs counter-clockwise. -- R.A. Grace Hopper >>>=20 >>> A. R. Ivanov >>> E-mail: anton.ivanov@kot-begemot.co.uk >>>=20 >>> _______________________________________________ >>> SDNP mailing list >>> SDNP@lucidvision.com >>> http://lucidvision.com/mailman/listinfo/sdnp >>>=20 >>> =20 >> =20 >=20 >=20 > --=20 > Humans are allergic to change. They love to say, "We've always > done it this way." I try to fight that. That's why I have a clock > on my wall that runs counter-clockwise. -- R.A. Grace Hopper >=20 > A. R. Ivanov > E-mail: anton.ivanov@kot-begemot.co.uk >=20 > _______________________________________________ > SDNP mailing list > SDNP@lucidvision.com > http://lucidvision.com/mailman/listinfo/sdnp >=20 From pedro.r.marques@gmail.com Tue Oct 11 13:36:59 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C5321F8E06 for ; Tue, 11 Oct 2011 13:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 sm7qMYGh6N73 for ; Tue, 11 Oct 2011 13:36:58 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8D021F8E01 for ; Tue, 11 Oct 2011 13:36:58 -0700 (PDT) Received: by iaby26 with SMTP id y26so11126243iab.31 for ; Tue, 11 Oct 2011 13:36:58 -0700 (PDT) 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=+sVRRj+D/ZRkzcOnuaJYBDyeQUIuqn8aEXc1aZpy0io=; b=oPTzVldi+CgxkPx0llcyqUlDHvqctz3bsmBIhbfhQ9KZ9D8/kS2H8o2QjMXEfyNJus 1H2u7m9JYnXpvmKoxgXG5X/XJsKYUb0tFbRlsb++GBTz00tzFyT99x/2rYPj3poHqaxz T3FaP4owo4YwMi0/jNZVACRdYFb2rv8smIgzE= MIME-Version: 1.0 Received: by 10.231.21.217 with SMTP id k25mr3995340ibb.63.1318365418200; Tue, 11 Oct 2011 13:36:58 -0700 (PDT) Received: by 10.231.16.69 with HTTP; Tue, 11 Oct 2011 13:36:58 -0700 (PDT) In-Reply-To: <3B6CD5F5-9510-487E-AC30-575CE1B7427B@niven-jenkins.co.uk> References: <238542D917511A45B6B8AA806E875E250709B7CF@XMB-RCD-201.cisco.com> <3B6CD5F5-9510-487E-AC30-575CE1B7427B@niven-jenkins.co.uk> Date: Tue, 11 Oct 2011 13:36:58 -0700 Message-ID: Subject: Re: VPN4DC at L3VPN in Taipei From: Pedro Marques To: Ben Niven-Jenkins Content-Type: text/plain; charset=ISO-8859-1 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 20:36:59 -0000 Ben, On Tue, Oct 11, 2011 at 11:12 AM, Ben Niven-Jenkins wrote: > It would be useful IMO if you could describe why that is not sufficient for your needs and how the current capabilities of L3VPNs map (or do not) to your needs. The proposition is that l3vpn technology and capabilities map to the problem of creating virtual networks for virtual machines, within and spanning data-centers. One common view point today, is that the VM connectivity problem should be solved by spanning VLANs across the data-center, given the capability to dynamically create them and adjust their membership programatically. In that light, IP VPNs appear to be a promising approach. In order to achieve that, there need to be additional standardization from what exists today. At the very least the "provisioning" interface needs to be defined and there needs to be an appropriate interface with the host. It is undesirable, in this space, to have IP VPN forwarding knowledge in the data-center switching infrastructure, thus the host becomes the CE and the PE simultaneously when it comes to forwarding. There are several other problems of interfacing between the orchestration and the network control plane, which may or not be a good fit for this group vs other groups. My understanding is that the rational behind the vpn4dc bof proposal is to find a home to standardize IP VPN connectivity solutions for VMs. The work required is probably very incremental on top of what l3vpn has achieved so it isn't clear whether this work fits the existing WG or if it requires some additional structure (or even if it fits some other bof). What is believe is clear is that there is space for a IP based solution for VM virtual networking. regards, Pedro. From lufang@cisco.com Tue Oct 11 15:17:36 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A26121F8B44 for ; Tue, 11 Oct 2011 15:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 hAjPYyZTdOxu for ; Tue, 11 Oct 2011 15:17:35 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8E83021F8B42 for ; Tue, 11 Oct 2011 15:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=19054; q=dns/txt; s=iport; t=1318371454; x=1319581054; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=eUYWVHHv8jPSDtup3724PL9StMRZnneRfbbcvryan9c=; b=ea82drtkj1RGgCrOUgEWIbH2CqOgFWqtvcxu0J2/qo0DyuDsyj6G2ATx JmNXMoyofZrx46XP2YTZF1l9nUrd0av9qvIdv/iGQOGXlxjr7ZSnYea4T 1Owcyi0BwmWBK/cEYgjbNaz2Z04K+DIDm0OscfwRaZ/TwIq7t94MkITBX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgAAA3AlE6tJXHA/2dsb2JhbAA5CpkKjySBBYFTAQEBAgEBAQEBDwEKEwo0BgUFBwQCAQgRAwEBAQEKBhcBBgEgBh8JCAEBBBMIAQsHB4dcB5lTAZ5JhB2CTmEEh3+RJ4R6h0U X-IronPort-AV: E=Sophos;i="4.68,525,1312156800"; d="scan'208";a="27677834" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 11 Oct 2011 22:17:33 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9BMHXVW013875; Tue, 11 Oct 2011 22:17:33 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 17:17:33 -0500 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 Subject: RE: VPN4DC at L3VPN in Taipei Date: Tue, 11 Oct 2011 17:17:20 -0500 Message-ID: <238542D917511A45B6B8AA806E875E250709BB60@XMB-RCD-201.cisco.com> In-Reply-To: <3B6CD5F5-9510-487E-AC30-575CE1B7427B@niven-jenkins.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN4DC at L3VPN in Taipei Thread-Index: AcyIQVzws4bgNs/hSByPuAWL/CUPOAAFedcg References: <238542D917511A45B6B8AA806E875E250709B7CF@XMB-RCD-201.cisco.com> <3B6CD5F5-9510-487E-AC30-575CE1B7427B@niven-jenkins.co.uk> From: "Luyuan Fang (lufang)" To: "Ben Niven-Jenkins" X-OriginalArrivalTime: 11 Oct 2011 22:17:33.0620 (UTC) FILETIME=[92FE9740:01CC8863] Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 22:17:36 -0000 Ben, Thanks for your comments. See in-line. > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Tuesday, October 11, 2011 2:13 PM > To: Luyuan Fang (lufang) > Cc: l3vpn@ietf.org > Subject: Re: VPN4DC at L3VPN in Taipei >=20 > Luyuan, >=20 > >=20 > Some comments inline. >=20 > On 11 Oct 2011, at 08:36, Luyuan Fang (lufang) wrote: >=20 > > As Marshall indicated last week: VPN4DC will be discussed in the > L3VPN > > WG meeting in Taipei per Routing ADs' arrangement. > > There will be no BOF. > > I am posting the VPN4DC BOF proposal (provided to AD on 10/2/2011) > here > > for the record. > > Hope this helps to provide additional background information, and > > attract more interested participants. >=20 > > VPN4DC BOF Proposal: > > > > Working Group Name: Virtual Private Networks for Data Centers > (VPN4DC) > > IETF Area: Routing Area > > Routing Area Director: Stewart Bryant (stbryant@cisco.com) > > Description of the Working Group: > > > > The purpose of the VPN4DC is to define requirements and solutions for > > establishing end-to-end (host-to-host) connectivity through layer 3 > VPN > > for Data Center and Cloud Services. > > > > (Note: The term layer 3 VPN here implies any type of IP technologies > for > > VPN. For example, IP VPN, BGP/MPLS VPN, or the combination of > different > > types of layer 3 VPNs to form end-to-end VPN solutions. These VPNs > may > > or may not be provisioned by Service Providers.) > > > > Today when Data Centers are inter-connected through VPNs or other WAN > > networks, the provisioning process for cloud services cross Service > > Providers' and Enterprise's Data Centers, or cross different Service > > Providers' Data Centers, is often manual, with long turn up time. > > Security, scalability, and operational efficiency are issues due to > lack > > of standardized host-to-host VPN solutions. > > Modern data-centers require multi-tenant support for applications. > For > > security and administrative reasons it is desirable to isolate the > > resources associated with a particular tenant in a VPN. This > workgroup > > will propose standard mechanisms to provide Layer 3 VPN connectivity > to > > end-systems while meeting scaling and manageability goals. This WG > will > > define requirements and protocol solutions to enable hosts in a Data > > Center to join a specific Layer 3 VPN automatically through control > > protocols, using Layer 3 VPN to provide secure any to any > connections. > > The Layer 3 VPN Gateway function which provides seamless VPN > > connectivity between the segments of the networks will be defined. > > > > In addition to proposing one or more layer 3 VPN technologies which > > support(s) end-systems, the WG will focus on interoperability between > > inter and intra DC VPN technologies and in making the VPN network > > topology information available and controllable by applications. > > > > Both of the following scenarios will be in scope: > > > > 1. When VPN management system and Data Center management system can > > communicate with each other, the WG will identify the requirement > and > > protocols to automatically enable hosts in a Data Center to join a > > specific VPN > > > > 2. When VPN management system and Data Center management system > > can't communicate (which is often the case), the WG will identify the > > requirement and protocols to automatically enable hosts in a Data > Center > > to join a specific VPN. > > The scope of the charter is limited to Layer 3 VPN solutions for Data > > Center and Cloud Services with end-to-end connectivity. >=20 > I will admit I may not have read all the related drafts but IMO it > would be good if the proposal or the drafts could be more explicit with > regard to what functionality is already performed by L3VPN, what > functionality is missing but you think comes under the remit of L3VPN > and what functionality is required but is (at least currently) out of > scope for L3VPN. >=20 Sure, Ning is updating the requirement draft. The old version is at=20 http://tools.ietf.org/id/draft-so-vdcs-01.txt For protocol examples, check these two new drafts. http://tools.ietf.org/html/draft-marques-l3vpn-end-system-00 http://www.ietf.org/id/draft-marques-sdnp-flow-spec-00.txt > For example, (and I may have got the wrong end of the stick here) but > my understanding from what I have read is that the goal is to > interconnect machines (virtual or physical) in data centers via L3VPNs > to other machines (virtual or physical) in the same or different data > centers while also considering that those machines may move over time > due to any number of reasons. >=20 Correct. > Today a customer of a VPN service can advertise which IP addresses are > in which sites attached to that VPN service using a routing protocol > over the CE-PE link (e.g. via OSPF) and that information is reflected > to the relevant PEs in that VPN service using MP-BGP. >=20 > It would be useful IMO if you could describe why that is not sufficient > for your needs and how the current capabilities of L3VPNs map (or do > not) to your needs. Is it just that the "CE" is no longer the access > router for a VPN site but now starts to be implemented within a > switch/router/hypervisor sat behind the access router? Is it that the > CE (access router) still advertises routing to the PE as it would today > but you are proposing some additional mechanism for installing state > into switches/routers/hypervisors behind that CE and for how those > switches/routers/hypervisors advertise that state to the CE for onward > advertisement (by existing L3VPN mechanisms) to the upstream PE for > that VPN site? Is it that the existing CE-PE advertisement mechanisms > are unsuitable for some reason and a new CE-PE protocol is required? > etc. >=20 Today's BGP/MPLS VPNs work well in the regular enterprise VPN scenarios. It has been more 12 years since we first working on it. It is one of the great technology success stories over the last decade.=20 This BOF took a different focus on where and how we want to apply what VPN technologies. It is about data center, cloud services, where the end system is most suited with light weight control protocols. The provisioning process today is rather segmented as we learned from Service Providers, there is strong desire to have a standard, scalable mechanism to solve the end-to-end/machine-to-machine connectivity issues. Ning is updating his requirements draft to shade more light on this.=20 > > > > Non-goals: Layer 2 connectivity, and layer 3 Multicast. > > > > The design principle for the protocols and solution development is to > > leverage existing layer 3 VPN technologies already defined in IETF > > whenever possible, including various IP and MPLS technologies. This > > charter supports the creation of new protocols, extension to existing > > protocols, and solutions proposed to use new and existing protocols. > > When extending existing protocols, this WG will work with the WG(s) > > responsible for the protocol being extended. > > > > BOF Agenda for IETF 82 > > November, 2011, Taibei > > - Discuss and agree on charter definitions: problems space, scope, > > requirements, candidate solutions, general interests, encourage > > participation from DC groups and from SP groups > > - Present initial draft of problem statements > > - Present initial draft of requirements > > - Present initial draft of use cases > > - Present one or more initial draft(s) of protocol solution(s) >=20 > While the topics above are valid topics to discuss I think it would > also be beneficial to include specific aims for what you think the > meeting should achieve beyond just presenting drafts and discussing > material. >=20 > For example: > - Is the aim to discuss the work in general and receive feedback on it > from the IETF community but nothing further at this stage? > - Is the aim to determine if there is consensus that the work is work > that is required and should be taken on by IETF? > - Is the aim to determine if the work does/does not fit within the > scope of L3VPN? > - etc (including some combination of the above). >=20 This proposed BOF had a goal to form a new WG to work on the topic, separately from L3VPN.=20 AD suggested to use L3VPN meeting session to discuss this work in Taipei, so Chairs from L3VPN requested session for this purpose, under the condition that we have mailing list discussion, and have at least one vpn4dc related draft posted, otherwise there would be no L3VPN meeting in Taipei as Marshall said in the earlier mail.=20 We currently submitted two drafts, have at least two more coming soon, and glad to see discussion picking up on the list. We also received off-line mails from several folks expressed interests to this work. Our goal is to together a group of people who are interested and willing to work on the requirements and solutions, produce useful work to the end users (SPs, DCs, Enterprises, etc.) as soon as possible. Regarding charter, ADs/IESG will decide, I'd assume largely based on the outcome of the meeting in Taipei, and the current mailing list discussion. Keep in mind, there are several places involving not quite the same but DC related discussion, some are more L2 focused, or has application driven aspect, etc. Would be helpful for folks interested in this work also check out the discussions in SDNP BOF (Tom forwarded the info to this list), and NOV3 BOF (the discussion will take place in L2VPN session and on L2VPN list). We are using the list to discuss the vpn4dc topic as ADs instructed (instead of using vpn4dc list), to clarify, there is no intention to change what's working in L3VPN. This is kind of like borrowing the "room". >=20 > > Goals and Milestones for the proposed Working Group >=20 > I think this list is far too long and likely to end up with any related > discussion becoming unfocussed. Furthermore some of the milestones are > pretty vague and essentially consist of "submit some more stuff for > publication". >=20 > I'd suggest cutting it down considerably and focussing it on the most > important items required to articulate the problem space, requirements > & solutions in order to do something meaningful as a first step and > have the scope/charter/problem space drafts describe why that initial > focus is what you are proposing it should be in order to firstly help > focus any discussions on the most important elements in order to reduce > the risk of significant tangential discussions and secondly in order to > demonstrate that there is a clear focus/outcome that you can envisage > and that this is not intended to be an open ended project without clear > goals and without any definition of when an acceptable (first stage) > "end game" result has been achieved. >=20 > I'm happy to work with you (and I'm sure Marshall is too) either on the > list of off-list (before bringing it back to the list to invite > additional discussion on any changes) to iterate your proposal and the > structure of the agenda/charter/milestones to try and ensure the > discussion and outcome of the meeting is as fruitful as possible for > you. >=20 Sure, be happy to chat with you off-line, will ping you. We plan to have Bar BOF meeting(s) as well to get things going. Will let everyone know where and when once we get the room. Thanks, Luyuan > Ben >=20 > > > > March 2012 Post strawman WG goals and charter description > > March 2012 Identify and document a limited set of candidate L3 VPN > > solutions for DC > > March 2012 Build small design teams for each proposed solution and > > requirement doc > > March 2012 Submit additional protocol definition draft(s) > > July 2012 Submit problem statements, use case, and requirement > > drafts as WG documents > > July 2012 Submit initial draft of Framework document > > July 2012 Submit protocol solutions as WG documents > > July 2012 Design teams to narrow down to small set of solutions > > to be focused by WG > > July 2012 Submit applicability statements for solutions > proposed > > > > July 2012 Post modified WG goals and charter with more details on > > solutions and timelines > > Nov. 2012 Submit problem statements, use cases, and requirements > > draft to IESG for review > > Nov. 2012 Submit the protocol solutions to IESG for review > > Nov. 2012 Submit Framework document as WG document > > Nov. 2012 Submit applicability statements as WG documents > > Nov. 2012 Submit more protocol solutions as WG documents > > Nov. 2012 Submit initial OAM drafts > > Nov. 2012 Submit initial discovery protocol drafts > > Nov. 2012 Submit initial security framework draft > > Nov. 2012 Submit initial MIB drafts > > March 2013 Submit framework draft to IESG for review > > March 2013 Submit more protocol solutions and applicability > > drafts to IESG for review > > March 2013 Submit OAM drafts as WG document > > March 2013 Submit more protocols and applicability drafts as WG > > document > > March 2013 Post modified charter based on the progress of the WG > > July 2013 Submit more protocol solutions and applicability drafts > to > > IESG for review > > July 2013 Submit more protocol solutions and applicability drafts > as > > WG doc > > July 2013 Submit security framework draft as WG document > > July 2013 Submit discovery protocol drafts as WG documents > > July 2013 Submit MIB drafts as WG documents > > July 2013 Submit more protocols and applicability drafts > > Nov. 2013 Submit OAM drafts for IESG review > > Nov. 2013 Submit discovery protocol drafts for IESG review > > Nov. 2013 Submit more protocol solutions and applicability > > drafts to IESG for review > > Nov. 2013 Submit more protocol solutions and applicability drafts > as > > WG doc > > Nov 2013 Submit Inter-op report > > Nov 2013 Post modified charter based on the progress of the WG > > March 2014 Submit security framework draft for IESG review > > March 2014 Submit MIB drafts for IESG review > > March 2014 Submit more protocol solutions and applicability > > drafts to IESG for review > > > > In addition to the meeting in L3VPN WG session, we will also hold Bar > > BOF meeting(s) in Taipei for those who are interested working on the > > subject to discuss and work together. > > > > Thanks, > > Luyuan > > > > > > > >> -------------------------------------------------------------------- > -- > >> > >> Message: 1 > >> Date: Tue, 4 Oct 2011 14:20:30 -0400 > >> From: Marshall Eubanks > >> To: L3VPN , lufang@cisco.com, Adrian Farrel > >> > >> Subject: VPN4DC at L3VPN in Taipei. > >> Message-ID: > >> >> 3yiUOfMpq_QaP17fBA7EBrR5r14NP+T9ZL62bKrdvw@mail.gmail.com> > >> Content-Type: text/plain; charset=3DISO-8859-1 > >> > >> Stewart Bryant has requested that we hold an L3VPN meeting at IETF > 82 > >> to consider and discuss VPN4DC. > >> Specifically, we would > >> > >> "need to emerge understanding the problem, > >> the usage, the requirements, and the necessary charter changes." > >> > >> This would be preparation for VPN4DC becoming a BOF. > >> > >> Adrian set up some requirements for this meeting : > >> > >> The problem needs to be discussed on the L3VPN list. > >> > >> You need to have viable -00 drafts before the cutoff. > >> > >> Luyuan Fang has promised a draft before the cutoff. > >> > >> If there is not significant discussion here on this issue, the > session > >> is likely to be canceled. > >> > >> Please keep discussion of VPN4DC here on the L3VPN list. > >> > >> Due to the tentative nature and special purpose of this meeting I > >> don't think it is appropriate to make > >> a general call for papers. However, if you would like to speak on > >> VPN4DC, please prepare a draft and let us (the WG Co-chairs) know. > >> > >> Regards > >> Marshall > >> > >> P.S. Some background : > >> > >> http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) > >> http://tools.ietf.org/id/draft-so-vdcs-01.txt > >> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Tue, 4 Oct 2011 13:36:06 -0500 > >> From: "Luyuan Fang (lufang)" > >> To: "Marshall Eubanks" , "L3VPN" > >> , "Adrian Farrel" > >> Subject: RE: VPN4DC at L3VPN in Taipei. > >> Message-ID: > >> <238542D917511A45B6B8AA806E875E2507005EA9@XMB-RCD-201.cisco.com> > >> Content-Type: text/plain; charset=3D"us-ascii" > >> > >> Marshall, > >> > >> I forwarded your mail to folks currently working on / interested in > >> vpn4dc project. > >> Thanks, > >> Luyuan > >> > >> > >>> -----Original Message----- > >>> From: Marshall Eubanks [mailto:marshall.eubanks@gmail.com] > >>> Sent: Tuesday, October 04, 2011 2:21 PM > >>> To: L3VPN; Luyuan Fang (lufang); Adrian Farrel > >>> Subject: VPN4DC at L3VPN in Taipei. > >>> > >>> Stewart Bryant has requested that we hold an L3VPN meeting at IETF > > 82 > >>> to consider and discuss VPN4DC. > >>> Specifically, we would > >>> > >>> "need to emerge understanding the problem, > >>> the usage, the requirements, and the necessary charter changes." > >>> > >>> This would be preparation for VPN4DC becoming a BOF. > >>> > >>> Adrian set up some requirements for this meeting : > >>> > >>> The problem needs to be discussed on the L3VPN list. > >>> > >>> You need to have viable -00 drafts before the cutoff. > >>> > >>> Luyuan Fang has promised a draft before the cutoff. > >>> > >>> If there is not significant discussion here on this issue, the > >> session > >>> is likely to be canceled. > >>> > >>> Please keep discussion of VPN4DC here on the L3VPN list. > >>> > >>> Due to the tentative nature and special purpose of this meeting I > >>> don't think it is appropriate to make > >>> a general call for papers. However, if you would like to speak on > >>> VPN4DC, please prepare a draft and let us (the WG Co-chairs) know. > >>> > >>> Regards > >>> Marshall > >>> > >>> P.S. Some background : > >>> > >>> http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) > >>> http://tools.ietf.org/id/draft-so-vdcs-01.txt > >> > >> > >> ------------------------------ > >> > >> _______________________________________________ > >> L3VPN mailing list > >> L3VPN@ietf.org > >> https://www.ietf.org/mailman/listinfo/l3vpn > >> > >> > >> End of L3VPN Digest, Vol 88, Issue 2 > >> ************************************ From lufang@cisco.com Tue Oct 11 15:18:56 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473E021F8DE6 for ; Tue, 11 Oct 2011 15:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 KKGAPVE8FgKQ for ; Tue, 11 Oct 2011 15:18:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD7421F8B44 for ; Tue, 11 Oct 2011 15:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=16678; q=dns/txt; s=iport; t=1318371534; x=1319581134; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=XZ0frv16GHHa01QFhs951tAjLax+o1UzCLT0qmGhK2k=; b=JRtVMcLvtntDkOwnCm5hFCTiHpc7pOAm8KXlus8hF0fJSXN/yF4K1xhP 8VIEfsEfiPRp/fjxmHSKYAK726On36/F/2w1WdaUMBqoo0D7UXUq6NOLX GwejDQLnCC4luYu8Q0c7NkaVswQ/8AhPV9ErapZQO6EeAd3JJkyHauhD0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgAAA3AlE6tJXG//2dsb2JhbAA5CpkKjySBBYFTAQEBAgEBAQEBDwEKEwo0BgUMBAIBCBEDAQEBAQoGFwEGASAGHwkIAQEEARIIDAcHh1wHmVMBnkmEHYJOYQSHf5EnhHqHRQ X-IronPort-AV: E=Sophos;i="4.68,525,1312156800"; d="scan'208";a="27678056" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 11 Oct 2011 22:18:54 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9BMIrJN023623; Tue, 11 Oct 2011 22:18:53 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, 11 Oct 2011 17:18:53 -0500 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 Subject: RE: VPN4DC at L3VPN in Taipei Date: Tue, 11 Oct 2011 17:18:50 -0500 Message-ID: <238542D917511A45B6B8AA806E875E250709BB63@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN4DC at L3VPN in Taipei Thread-Index: AcyCyGAvMy1n7PIQT3mJE3w1u7CcbQFFSu9AACFVawAAA6anUAADeBHg References: <238542D917511A45B6B8AA806E875E250709B7CF@XMB-RCD-201.cisco.com> <3B6CD5F5-9510-487E-AC30-575CE1B7427B@niven-jenkins.co.uk> From: "Luyuan Fang (lufang)" To: "UTTARO, JAMES" , "Ben Niven-Jenkins" X-OriginalArrivalTime: 11 Oct 2011 22:18:53.0915 (UTC) FILETIME=[C2DAA2B0:01CC8863] Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 22:18:56 -0000 See my reply to Ben. Luyuan > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Tuesday, October 11, 2011 4:31 PM > To: 'Ben Niven-Jenkins'; Luyuan Fang (lufang) > Cc: l3vpn@ietf.org > Subject: RE: VPN4DC at L3VPN in Taipei >=20 > +1 on Ben's comments in re what functionality is missing in the current > L3VPN specification. I believe a detailed set of requirements will go a > long way in making this work applicable.. >=20 > Jim Uttaro >=20 > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: Tuesday, October 11, 2011 2:13 PM > To: Luyuan Fang > Cc: l3vpn@ietf.org > Subject: Re: VPN4DC at L3VPN in Taipei >=20 > Luyuan, >=20 > >=20 > Some comments inline. >=20 > On 11 Oct 2011, at 08:36, Luyuan Fang (lufang) wrote: >=20 > > As Marshall indicated last week: VPN4DC will be discussed in the > L3VPN > > WG meeting in Taipei per Routing ADs' arrangement. > > There will be no BOF. > > I am posting the VPN4DC BOF proposal (provided to AD on 10/2/2011) > here > > for the record. > > Hope this helps to provide additional background information, and > > attract more interested participants. >=20 > > VPN4DC BOF Proposal: > > > > Working Group Name: Virtual Private Networks for Data Centers > (VPN4DC) > > IETF Area: Routing Area > > Routing Area Director: Stewart Bryant (stbryant@cisco.com) > > Description of the Working Group: > > > > The purpose of the VPN4DC is to define requirements and solutions for > > establishing end-to-end (host-to-host) connectivity through layer 3 > VPN > > for Data Center and Cloud Services. > > > > (Note: The term layer 3 VPN here implies any type of IP technologies > for > > VPN. For example, IP VPN, BGP/MPLS VPN, or the combination of > different > > types of layer 3 VPNs to form end-to-end VPN solutions. These VPNs > may > > or may not be provisioned by Service Providers.) > > > > Today when Data Centers are inter-connected through VPNs or other WAN > > networks, the provisioning process for cloud services cross Service > > Providers' and Enterprise's Data Centers, or cross different Service > > Providers' Data Centers, is often manual, with long turn up time. > > Security, scalability, and operational efficiency are issues due to > lack > > of standardized host-to-host VPN solutions. > > Modern data-centers require multi-tenant support for applications. > For > > security and administrative reasons it is desirable to isolate the > > resources associated with a particular tenant in a VPN. This > workgroup > > will propose standard mechanisms to provide Layer 3 VPN connectivity > to > > end-systems while meeting scaling and manageability goals. This WG > will > > define requirements and protocol solutions to enable hosts in a Data > > Center to join a specific Layer 3 VPN automatically through control > > protocols, using Layer 3 VPN to provide secure any to any > connections. > > The Layer 3 VPN Gateway function which provides seamless VPN > > connectivity between the segments of the networks will be defined. > > > > In addition to proposing one or more layer 3 VPN technologies which > > support(s) end-systems, the WG will focus on interoperability between > > inter and intra DC VPN technologies and in making the VPN network > > topology information available and controllable by applications. > > > > Both of the following scenarios will be in scope: > > > > 1. When VPN management system and Data Center management system can > > communicate with each other, the WG will identify the requirement > and > > protocols to automatically enable hosts in a Data Center to join a > > specific VPN > > > > 2. When VPN management system and Data Center management system > > can't communicate (which is often the case), the WG will identify the > > requirement and protocols to automatically enable hosts in a Data > Center > > to join a specific VPN. > > The scope of the charter is limited to Layer 3 VPN solutions for Data > > Center and Cloud Services with end-to-end connectivity. >=20 > I will admit I may not have read all the related drafts but IMO it > would be good if the proposal or the drafts could be more explicit with > regard to what functionality is already performed by L3VPN, what > functionality is missing but you think comes under the remit of L3VPN > and what functionality is required but is (at least currently) out of > scope for L3VPN. >=20 > For example, (and I may have got the wrong end of the stick here) but > my understanding from what I have read is that the goal is to > interconnect machines (virtual or physical) in data centers via L3VPNs > to other machines (virtual or physical) in the same or different data > centers while also considering that those machines may move over time > due to any number of reasons. >=20 > Today a customer of a VPN service can advertise which IP addresses are > in which sites attached to that VPN service using a routing protocol > over the CE-PE link (e.g. via OSPF) and that information is reflected > to the relevant PEs in that VPN service using MP-BGP. >=20 > It would be useful IMO if you could describe why that is not sufficient > for your needs and how the current capabilities of L3VPNs map (or do > not) to your needs. Is it just that the "CE" is no longer the access > router for a VPN site but now starts to be implemented within a > switch/router/hypervisor sat behind the access router? Is it that the > CE (access router) still advertises routing to the PE as it would today > but you are proposing some additional mechanism for installing state > into switches/routers/hypervisors behind that CE and for how those > switches/routers/hypervisors advertise that state to the CE for onward > advertisement (by existing L3VPN mechanisms) to the upstream PE for > that VPN site? Is it that the existing CE-PE advertisement mechanisms > are unsuitable for some reason and a new CE-PE protocol is required? > etc. >=20 > > > > Non-goals: Layer 2 connectivity, and layer 3 Multicast. > > > > The design principle for the protocols and solution development is to > > leverage existing layer 3 VPN technologies already defined in IETF > > whenever possible, including various IP and MPLS technologies. This > > charter supports the creation of new protocols, extension to existing > > protocols, and solutions proposed to use new and existing protocols. > > When extending existing protocols, this WG will work with the WG(s) > > responsible for the protocol being extended. > > > > BOF Agenda for IETF 82 > > November, 2011, Taibei > > - Discuss and agree on charter definitions: problems space, scope, > > requirements, candidate solutions, general interests, encourage > > participation from DC groups and from SP groups > > - Present initial draft of problem statements > > - Present initial draft of requirements > > - Present initial draft of use cases > > - Present one or more initial draft(s) of protocol solution(s) >=20 > While the topics above are valid topics to discuss I think it would > also be beneficial to include specific aims for what you think the > meeting should achieve beyond just presenting drafts and discussing > material. >=20 > For example: > - Is the aim to discuss the work in general and receive feedback on it > from the IETF community but nothing further at this stage? > - Is the aim to determine if there is consensus that the work is work > that is required and should be taken on by IETF? > - Is the aim to determine if the work does/does not fit within the > scope of L3VPN? > - etc (including some combination of the above). >=20 >=20 > > Goals and Milestones for the proposed Working Group >=20 > I think this list is far too long and likely to end up with any related > discussion becoming unfocussed. Furthermore some of the milestones are > pretty vague and essentially consist of "submit some more stuff for > publication". >=20 > I'd suggest cutting it down considerably and focussing it on the most > important items required to articulate the problem space, requirements > & solutions in order to do something meaningful as a first step and > have the scope/charter/problem space drafts describe why that initial > focus is what you are proposing it should be in order to firstly help > focus any discussions on the most important elements in order to reduce > the risk of significant tangential discussions and secondly in order to > demonstrate that there is a clear focus/outcome that you can envisage > and that this is not intended to be an open ended project without clear > goals and without any definition of when an acceptable (first stage) > "end game" result has been achieved. >=20 > I'm happy to work with you (and I'm sure Marshall is too) either on the > list of off-list (before bringing it back to the list to invite > additional discussion on any changes) to iterate your proposal and the > structure of the agenda/charter/milestones to try and ensure the > discussion and outcome of the meeting is as fruitful as possible for > you. >=20 > Ben >=20 > > > > March 2012 Post strawman WG goals and charter description > > March 2012 Identify and document a limited set of candidate L3 VPN > > solutions for DC > > March 2012 Build small design teams for each proposed solution and > > requirement doc > > March 2012 Submit additional protocol definition draft(s) > > July 2012 Submit problem statements, use case, and requirement > > drafts as WG documents > > July 2012 Submit initial draft of Framework document > > July 2012 Submit protocol solutions as WG documents > > July 2012 Design teams to narrow down to small set of solutions > > to be focused by WG > > July 2012 Submit applicability statements for solutions > proposed > > > > July 2012 Post modified WG goals and charter with more details on > > solutions and timelines > > Nov. 2012 Submit problem statements, use cases, and requirements > > draft to IESG for review > > Nov. 2012 Submit the protocol solutions to IESG for review > > Nov. 2012 Submit Framework document as WG document > > Nov. 2012 Submit applicability statements as WG documents > > Nov. 2012 Submit more protocol solutions as WG documents > > Nov. 2012 Submit initial OAM drafts > > Nov. 2012 Submit initial discovery protocol drafts > > Nov. 2012 Submit initial security framework draft > > Nov. 2012 Submit initial MIB drafts > > March 2013 Submit framework draft to IESG for review > > March 2013 Submit more protocol solutions and applicability > > drafts to IESG for review > > March 2013 Submit OAM drafts as WG document > > March 2013 Submit more protocols and applicability drafts as WG > > document > > March 2013 Post modified charter based on the progress of the WG > > July 2013 Submit more protocol solutions and applicability drafts > to > > IESG for review > > July 2013 Submit more protocol solutions and applicability drafts > as > > WG doc > > July 2013 Submit security framework draft as WG document > > July 2013 Submit discovery protocol drafts as WG documents > > July 2013 Submit MIB drafts as WG documents > > July 2013 Submit more protocols and applicability drafts > > Nov. 2013 Submit OAM drafts for IESG review > > Nov. 2013 Submit discovery protocol drafts for IESG review > > Nov. 2013 Submit more protocol solutions and applicability > > drafts to IESG for review > > Nov. 2013 Submit more protocol solutions and applicability drafts > as > > WG doc > > Nov 2013 Submit Inter-op report > > Nov 2013 Post modified charter based on the progress of the WG > > March 2014 Submit security framework draft for IESG review > > March 2014 Submit MIB drafts for IESG review > > March 2014 Submit more protocol solutions and applicability > > drafts to IESG for review > > > > In addition to the meeting in L3VPN WG session, we will also hold Bar > > BOF meeting(s) in Taipei for those who are interested working on the > > subject to discuss and work together. > > > > Thanks, > > Luyuan > > > > > > > >> -------------------------------------------------------------------- > -- > >> > >> Message: 1 > >> Date: Tue, 4 Oct 2011 14:20:30 -0400 > >> From: Marshall Eubanks > >> To: L3VPN , lufang@cisco.com, Adrian Farrel > >> > >> Subject: VPN4DC at L3VPN in Taipei. > >> Message-ID: > >> >> 3yiUOfMpq_QaP17fBA7EBrR5r14NP+T9ZL62bKrdvw@mail.gmail.com> > >> Content-Type: text/plain; charset=3DISO-8859-1 > >> > >> Stewart Bryant has requested that we hold an L3VPN meeting at IETF > 82 > >> to consider and discuss VPN4DC. > >> Specifically, we would > >> > >> "need to emerge understanding the problem, > >> the usage, the requirements, and the necessary charter changes." > >> > >> This would be preparation for VPN4DC becoming a BOF. > >> > >> Adrian set up some requirements for this meeting : > >> > >> The problem needs to be discussed on the L3VPN list. > >> > >> You need to have viable -00 drafts before the cutoff. > >> > >> Luyuan Fang has promised a draft before the cutoff. > >> > >> If there is not significant discussion here on this issue, the > session > >> is likely to be canceled. > >> > >> Please keep discussion of VPN4DC here on the L3VPN list. > >> > >> Due to the tentative nature and special purpose of this meeting I > >> don't think it is appropriate to make > >> a general call for papers. However, if you would like to speak on > >> VPN4DC, please prepare a draft and let us (the WG Co-chairs) know. > >> > >> Regards > >> Marshall > >> > >> P.S. Some background : > >> > >> http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) > >> http://tools.ietf.org/id/draft-so-vdcs-01.txt > >> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Tue, 4 Oct 2011 13:36:06 -0500 > >> From: "Luyuan Fang (lufang)" > >> To: "Marshall Eubanks" , "L3VPN" > >> , "Adrian Farrel" > >> Subject: RE: VPN4DC at L3VPN in Taipei. > >> Message-ID: > >> <238542D917511A45B6B8AA806E875E2507005EA9@XMB-RCD-201.cisco.com> > >> Content-Type: text/plain; charset=3D"us-ascii" > >> > >> Marshall, > >> > >> I forwarded your mail to folks currently working on / interested in > >> vpn4dc project. > >> Thanks, > >> Luyuan > >> > >> > >>> -----Original Message----- > >>> From: Marshall Eubanks [mailto:marshall.eubanks@gmail.com] > >>> Sent: Tuesday, October 04, 2011 2:21 PM > >>> To: L3VPN; Luyuan Fang (lufang); Adrian Farrel > >>> Subject: VPN4DC at L3VPN in Taipei. > >>> > >>> Stewart Bryant has requested that we hold an L3VPN meeting at IETF > > 82 > >>> to consider and discuss VPN4DC. > >>> Specifically, we would > >>> > >>> "need to emerge understanding the problem, > >>> the usage, the requirements, and the necessary charter changes." > >>> > >>> This would be preparation for VPN4DC becoming a BOF. > >>> > >>> Adrian set up some requirements for this meeting : > >>> > >>> The problem needs to be discussed on the L3VPN list. > >>> > >>> You need to have viable -00 drafts before the cutoff. > >>> > >>> Luyuan Fang has promised a draft before the cutoff. > >>> > >>> If there is not significant discussion here on this issue, the > >> session > >>> is likely to be canceled. > >>> > >>> Please keep discussion of VPN4DC here on the L3VPN list. > >>> > >>> Due to the tentative nature and special purpose of this meeting I > >>> don't think it is appropriate to make > >>> a general call for papers. However, if you would like to speak on > >>> VPN4DC, please prepare a draft and let us (the WG Co-chairs) know. > >>> > >>> Regards > >>> Marshall > >>> > >>> P.S. Some background : > >>> > >>> http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17) > >>> http://tools.ietf.org/id/draft-so-vdcs-01.txt > >> > >> > >> ------------------------------ > >> > >> _______________________________________________ > >> L3VPN mailing list > >> L3VPN@ietf.org > >> https://www.ietf.org/mailman/listinfo/l3vpn > >> > >> > >> End of L3VPN Digest, Vol 88, Issue 2 > >> ************************************ From ben@niven-jenkins.co.uk Tue Oct 11 17:03:12 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8957A21F8CC5 for ; Tue, 11 Oct 2011 17:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_32=0.6, 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 6wDkGL2xWpcI for ; Tue, 11 Oct 2011 17:03:11 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 98D7221F8B55 for ; Tue, 11 Oct 2011 17:03:10 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RDmHt-0001aA-AV; Wed, 12 Oct 2011 01:03:09 +0100 Subject: Re: VPN4DC at L3VPN in Taipei Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <238542D917511A45B6B8AA806E875E250709BB60@XMB-RCD-201.cisco.com> Date: Wed, 12 Oct 2011 01:03:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <69D0559E-67A5-4111-9816-64E40F3847C4@niven-jenkins.co.uk> References: <238542D917511A45B6B8AA806E875E250709B7CF@XMB-RCD-201.cisco.com> <3B6CD5F5-9510-487E-AC30-575CE1B7427B@niven-jenkins.co.uk> <238542D917511A45B6B8AA806E875E250709BB60@XMB-RCD-201.cisco.com> To: "Luyuan Fang (lufang)" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 00:03:12 -0000 Luyuan, Thanks for your response. Let me say upfront that my interest in this = work at this stage is purely that Marshall and I are going to have to = chair your session in Taipei and so I'm just trying to understand a bit = better what it is and the context of any discussion I'm expected to = moderate. More inline. =20 On 11 Oct 2011, at 23:17, Luyuan Fang (lufang) wrote: >> Today a customer of a VPN service can advertise which IP addresses = are >> in which sites attached to that VPN service using a routing protocol >> over the CE-PE link (e.g. via OSPF) and that information is reflected >> to the relevant PEs in that VPN service using MP-BGP. >>=20 >> It would be useful IMO if you could describe why that is not > sufficient >> for your needs and how the current capabilities of L3VPNs map (or do >> not) to your needs. Is it just that the "CE" is no longer the access >> router for a VPN site but now starts to be implemented within a >> switch/router/hypervisor sat behind the access router? Is it that the >> CE (access router) still advertises routing to the PE as it would > today >> but you are proposing some additional mechanism for installing state >> into switches/routers/hypervisors behind that CE and for how those >> switches/routers/hypervisors advertise that state to the CE for = onward >> advertisement (by existing L3VPN mechanisms) to the upstream PE for >> that VPN site? Is it that the existing CE-PE advertisement mechanisms >> are unsuitable for some reason and a new CE-PE protocol is required? >> etc. >=20 > Today's BGP/MPLS VPNs work well in the regular enterprise VPN = scenarios. > It has been more 12 years since we first working on it. It is one of = the > great technology success stories over the last decade.=20 >=20 > This BOF took a different focus on where and how we want to apply what > VPN technologies. It is about data center, cloud services, where the = end > system is most suited with light weight control protocols. One of the things I'm trying to understand is when & how these new light = weight control protocols running on end systems in data centers are = expected to interact with the existing L3VPN control protocols. > The > provisioning process today is rather segmented as we learned from > Service Providers, there is strong desire to have a standard, scalable > mechanism to solve the end-to-end/machine-to-machine connectivity > issues. Ning is updating his requirements draft to shade more light on > this.=20 One thing that might help my understanding at least would be a diagram = or some prose that shows the components (hosts, gateways, CEs, PEs, = etc.) sitting between a pair of hosts within the same VPN and showing = what portion of that end to end flow is satisfied by existing mechanisms = versus what portions require new mechanisms. I guess it might need to = show two dimensions: (1) the existing/new portions required to advertise = the necessary forwarding between the different components and (2) the = new/existing portions required to provision services/state that is = separate to the forwarding state in the different components. Figures 1-3 in draft-so-vdcs-01 start to do that a little bit by showing = different physical/logical views with respect to what a PE sees but = aren't very specific in where new versus existing functionality is used = to achieve the end result. =20 >>> BOF Agenda for IETF 82 >>> November, 2011, Taibei >>> - Discuss and agree on charter definitions: problems space, scope, >>> requirements, candidate solutions, general interests, encourage >>> participation from DC groups and from SP groups >>> - Present initial draft of problem statements >>> - Present initial draft of requirements >>> - Present initial draft of use cases >>> - Present one or more initial draft(s) of protocol solution(s) >>=20 >> While the topics above are valid topics to discuss I think it would >> also be beneficial to include specific aims for what you think the >> meeting should achieve beyond just presenting drafts and discussing >> material. >>=20 >> For example: >> - Is the aim to discuss the work in general and receive feedback on = it >> from the IETF community but nothing further at this stage? >> - Is the aim to determine if there is consensus that the work is work >> that is required and should be taken on by IETF? >> - Is the aim to determine if the work does/does not fit within the >> scope of L3VPN? >> - etc (including some combination of the above). >>=20 >=20 > This proposed BOF had a goal to form a new WG to work on the topic, > separately from L3VPN.=20 >=20 > AD suggested to use L3VPN meeting session to discuss this work in > Taipei, so Chairs from L3VPN requested session for this purpose, under > the condition that we have mailing list discussion, and have at least > one vpn4dc related draft posted, otherwise there would be no L3VPN > meeting in Taipei as Marshall said in the earlier mail.=20 >=20 > We currently submitted two drafts, have at least two more coming soon, > and glad to see discussion picking up on the list. We also received > off-line mails from several folks expressed interests to this work. = Our > goal is to together a group of people who are interested and willing = to > work on the requirements and solutions, produce useful work to the end > users (SPs, DCs, Enterprises, etc.) as soon as possible. >=20 > Regarding charter, ADs/IESG will decide, I'd assume largely based on = the > outcome of the meeting in Taipei, and the current mailing list > discussion. So part of my job is to chair/moderate that discussion and my questions = above were meant to dig a little into what it is you want to achieve = beyond just discussing some drafts, for example what sorts of questions = I might be expected to ask the room to help the ADs gauge if there is = consensus for whatever outcome you would ideally like to have. If your goal is to form a WG then the most important things to present = and demonstrate IMO is that you have a well understood and clearly = scoped problem statement as well as a draft charter that folks agree = fairly reflects the work that needs to be undertaken to address the = problem statement and an initial set of milestones that are realistic = and that folks agree will achieve the cited aims. We can then focus the discussion and the available time on ensuring that = folks reach a common understanding and (hopefully) consensus on those = things, rather than for example letting the discussion get bogged down = in the specifics of a particular solution proposal. That is one of the reasons I suggested you significantly reduce the = number of milestones you're proposing to just the most important items = required to articulate the problem space, requirements & solutions = needed in order to do something meaningful as a first step because I'm = highly doubtful that it will be possible for us to have a focussed = discussion that results in consensus for a charter that contains 39 = milestones...=20 Ben From lufang@cisco.com Tue Oct 11 18:21:38 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D9E21F8BBC for ; Tue, 11 Oct 2011 18:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 nQuSgkZbDkou for ; Tue, 11 Oct 2011 18:21:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4265721F8B7D for ; Tue, 11 Oct 2011 18:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=8391; q=dns/txt; s=iport; t=1318382497; x=1319592097; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=XV/euyy7aP/FQRqCuAAC0A5/srRBTpbuGsoBW8rY9g0=; b=EluSY6tRHXfqHzvG3F+PySHytvp6ulrvD7iVxvg/7Z+CHJW4LNvJ39zq T+4z6yA+PS3MsEPTwFTqPI4vkXyXWeG535Bq/B0RXds2qNf9lr3ylcyip /A99fY8Rdae6wMfnE519Ic86eOPw0GcYLY3EprfX9W+O3bQoYLgdnKjkt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgAAFzrlE6tJXG9/2dsb2JhbABDmQqPJIEFgVMBAQEEEgEdCjQGBQwEAgEIEQQBAQEKBhcBBgFFCQgBAQQTCAwHB6FDAZ5MhmthBId/kSeMPw X-IronPort-AV: E=Sophos;i="4.68,526,1312156800"; d="scan'208";a="27705584" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 12 Oct 2011 01:21:36 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9C1La4M020518; Wed, 12 Oct 2011 01:21:36 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 20:21:36 -0500 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 Subject: RE: VPN4DC at L3VPN in Taipei Date: Tue, 11 Oct 2011 20:21:32 -0500 Message-ID: <238542D917511A45B6B8AA806E875E250709BC03@XMB-RCD-201.cisco.com> In-Reply-To: <69D0559E-67A5-4111-9816-64E40F3847C4@niven-jenkins.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN4DC at L3VPN in Taipei Thread-Index: AcyIclSEbCVhtZWxSSCAl2nkOcuWQgABXKpg References: <238542D917511A45B6B8AA806E875E250709B7CF@XMB-RCD-201.cisco.com> <3B6CD5F5-9510-487E-AC30-575CE1B7427B@niven-jenkins.co.uk> <238542D917511A45B6B8AA806E875E250709BB60@XMB-RCD-201.cisco.com> <69D0559E-67A5-4111-9816-64E40F3847C4@niven-jenkins.co.uk> From: "Luyuan Fang (lufang)" To: "Ben Niven-Jenkins" X-OriginalArrivalTime: 12 Oct 2011 01:21:36.0437 (UTC) FILETIME=[4906BE50:01CC887D] Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 01:21:38 -0000 Ben, Thanks for the discussion again.=20 Appreciate the effort you are making to dig down the problem space and making many good points. Thanks to Marshall too. Quite agree on focusing on the requirements, it is under work by several SP folks and others. Regarding the diagram, absolutely, give us some time, we are documenting. About the milestones, we initially had a shorter list, we had comments from AD to extend the milestones. May be we gone too far this time. I checked the milestones of many WGs, they vary a lot, from very short to very long, depending on the WG style and stage... In any case, we need to continue refine it with the team, thanks for the input from you and others. I think we are largely in agreement.=20 Luyuan > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Tuesday, October 11, 2011 8:03 PM > To: Luyuan Fang (lufang) > Cc: l3vpn@ietf.org > Subject: Re: VPN4DC at L3VPN in Taipei >=20 > Luyuan, >=20 > Thanks for your response. Let me say upfront that my interest in this > work at this stage is purely that Marshall and I are going to have to > chair your session in Taipei and so I'm just trying to understand a bit > better what it is and the context of any discussion I'm expected to > moderate. >=20 > More inline. >=20 > On 11 Oct 2011, at 23:17, Luyuan Fang (lufang) wrote: > >> Today a customer of a VPN service can advertise which IP addresses > are > >> in which sites attached to that VPN service using a routing protocol > >> over the CE-PE link (e.g. via OSPF) and that information is > reflected > >> to the relevant PEs in that VPN service using MP-BGP. > >> > >> It would be useful IMO if you could describe why that is not > > sufficient > >> for your needs and how the current capabilities of L3VPNs map (or do > >> not) to your needs. Is it just that the "CE" is no longer the access > >> router for a VPN site but now starts to be implemented within a > >> switch/router/hypervisor sat behind the access router? Is it that > the > >> CE (access router) still advertises routing to the PE as it would > > today > >> but you are proposing some additional mechanism for installing state > >> into switches/routers/hypervisors behind that CE and for how those > >> switches/routers/hypervisors advertise that state to the CE for > onward > >> advertisement (by existing L3VPN mechanisms) to the upstream PE for > >> that VPN site? Is it that the existing CE-PE advertisement > mechanisms > >> are unsuitable for some reason and a new CE-PE protocol is required? > >> etc. > > > > Today's BGP/MPLS VPNs work well in the regular enterprise VPN > scenarios. > > It has been more 12 years since we first working on it. It is one of > the > > great technology success stories over the last decade. > > > > This BOF took a different focus on where and how we want to apply > what > > VPN technologies. It is about data center, cloud services, where the > end > > system is most suited with light weight control protocols. >=20 > One of the things I'm trying to understand is when & how these new > light weight control protocols running on end systems in data centers > are expected to interact with the existing L3VPN control protocols. >=20 > > The > > provisioning process today is rather segmented as we learned from > > Service Providers, there is strong desire to have a standard, > scalable > > mechanism to solve the end-to-end/machine-to-machine connectivity > > issues. Ning is updating his requirements draft to shade more light > on > > this. >=20 > One thing that might help my understanding at least would be a diagram > or some prose that shows the components (hosts, gateways, CEs, PEs, > etc.) sitting between a pair of hosts within the same VPN and showing > what portion of that end to end flow is satisfied by existing > mechanisms versus what portions require new mechanisms. I guess it > might need to show two dimensions: (1) the existing/new portions > required to advertise the necessary forwarding between the different > components and (2) the new/existing portions required to provision > services/state that is separate to the forwarding state in the > different components. >=20 > Figures 1-3 in draft-so-vdcs-01 start to do that a little bit by > showing different physical/logical views with respect to what a PE sees > but aren't very specific in where new versus existing functionality is > used to achieve the end result. >=20 > >>> BOF Agenda for IETF 82 > >>> November, 2011, Taibei > >>> - Discuss and agree on charter definitions: problems space, scope, > >>> requirements, candidate solutions, general interests, encourage > >>> participation from DC groups and from SP groups > >>> - Present initial draft of problem statements > >>> - Present initial draft of requirements > >>> - Present initial draft of use cases > >>> - Present one or more initial draft(s) of protocol solution(s) > >> > >> While the topics above are valid topics to discuss I think it would > >> also be beneficial to include specific aims for what you think the > >> meeting should achieve beyond just presenting drafts and discussing > >> material. > >> > >> For example: > >> - Is the aim to discuss the work in general and receive feedback on > it > >> from the IETF community but nothing further at this stage? > >> - Is the aim to determine if there is consensus that the work is > work > >> that is required and should be taken on by IETF? > >> - Is the aim to determine if the work does/does not fit within the > >> scope of L3VPN? > >> - etc (including some combination of the above). > >> > > > > This proposed BOF had a goal to form a new WG to work on the topic, > > separately from L3VPN. > > > > AD suggested to use L3VPN meeting session to discuss this work in > > Taipei, so Chairs from L3VPN requested session for this purpose, > under > > the condition that we have mailing list discussion, and have at least > > one vpn4dc related draft posted, otherwise there would be no L3VPN > > meeting in Taipei as Marshall said in the earlier mail. > > > > We currently submitted two drafts, have at least two more coming > soon, > > and glad to see discussion picking up on the list. We also received > > off-line mails from several folks expressed interests to this work. > Our > > goal is to together a group of people who are interested and willing > to > > work on the requirements and solutions, produce useful work to the > end > > users (SPs, DCs, Enterprises, etc.) as soon as possible. > > > > Regarding charter, ADs/IESG will decide, I'd assume largely based on > the > > outcome of the meeting in Taipei, and the current mailing list > > discussion. >=20 > So part of my job is to chair/moderate that discussion and my questions > above were meant to dig a little into what it is you want to achieve > beyond just discussing some drafts, for example what sorts of questions > I might be expected to ask the room to help the ADs gauge if there is > consensus for whatever outcome you would ideally like to have. >=20 > If your goal is to form a WG then the most important things to present > and demonstrate IMO is that you have a well understood and clearly > scoped problem statement as well as a draft charter that folks agree > fairly reflects the work that needs to be undertaken to address the > problem statement and an initial set of milestones that are realistic > and that folks agree will achieve the cited aims. >=20 > We can then focus the discussion and the available time on ensuring > that folks reach a common understanding and (hopefully) consensus on > those things, rather than for example letting the discussion get bogged > down in the specifics of a particular solution proposal. >=20 > That is one of the reasons I suggested you significantly reduce the > number of milestones you're proposing to just the most important items > required to articulate the problem space, requirements & solutions > needed in order to do something meaningful as a first step because I'm > highly doubtful that it will be possible for us to have a focussed > discussion that results in consensus for a charter that contains 39 > milestones... >=20 > Ben From lufang@cisco.com Wed Oct 12 15:12:37 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5151C21F8C55 for ; Wed, 12 Oct 2011 15:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 H7yh25upyllQ for ; Wed, 12 Oct 2011 15:12:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3B17F21F8C5D for ; Wed, 12 Oct 2011 15:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=9560; q=dns/txt; s=iport; t=1318457556; x=1319667156; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GDhNXWNpZNteWVhAsXVGjTn1q4KFK/1cOscOexFb6Gk=; b=C2dV7vOKMHclEmEEMCnPleEYbweKW7ZrDNWWrbHrRzt6mx4M9tGOhyqI BdY2NW3VJF/3kQQjuWeMsrjnJR9p31hVV3MmTS3A1n+thKmNlDphBzpV7 EZqEyxllpbunZqFZBU2yOatIUd4pxQgpexqDBghKpdCqAgGQqBusTnGwF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIAAFoQlk6tJXG//2dsb2JhbABDmRmPIYEFgVMBAQEBAxIBHQo0BgUMBAIBCBEEAQEBCgYXAQYBRQkIAgQBEggMBweiIAGeR4Z3YQSHf5EnjEE X-IronPort-AV: E=Sophos;i="4.69,336,1315180800"; d="scan'208";a="27962261" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 12 Oct 2011 22:12:35 +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 p9CMCZPb014433; Wed, 12 Oct 2011 22:12:35 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, 12 Oct 2011 17:12:35 -0500 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 Subject: RE: VPN4DC at L3VPN in Taipei Date: Wed, 12 Oct 2011 17:12:28 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2507147AD0@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN4DC at L3VPN in Taipei Thread-Index: AcyCyGAvMy1n7PIQT3mJE3w1u7CcbQFFSu9AACFVawAACIwWAAADse0AAAK89AAAIywCIAAAC4wA References: <238542D917511A45B6B8AA806E875E250709B7CF@XMB-RCD-201.cisco.com><3B6CD5F5-9510-487E-AC30-575CE1B7427B@niven-jenkins.co.uk><238542D917511A45B6B8AA806E875E250709BB60@XMB-RCD-201.cisco.com><69D0559E-67A5-4111-9816-64E40F3847C4@niven-jenkins.co.uk> <238542D917511A45B6B8AA806E875E250709BC03@XMB-RCD-201.cisco.com> From: "Luyuan Fang (lufang)" To: "UTTARO, JAMES" , "Ben Niven-Jenkins" X-OriginalArrivalTime: 12 Oct 2011 22:12:35.0534 (UTC) FILETIME=[0BBC06E0:01CC892C] Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 22:12:37 -0000 Absolutely, Jim. It will an individual draft at first, then moving toward WG doc when consensus is built... Thanks, Luyuan > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Wednesday, October 12, 2011 6:09 PM > To: Luyuan Fang (lufang); Ben Niven-Jenkins > Cc: l3vpn@ietf.org > Subject: RE: VPN4DC at L3VPN in Taipei >=20 > Is the requirements intended as a WG document? I think it should be.. >=20 > Jim Uttaro >=20 > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Luyuan Fang (lufang) > Sent: Tuesday, October 11, 2011 9:22 PM > To: Ben Niven-Jenkins > Cc: l3vpn@ietf.org > Subject: RE: VPN4DC at L3VPN in Taipei >=20 > Ben, >=20 > Thanks for the discussion again. > Appreciate the effort you are making to dig down the problem space and > making many good points. Thanks to Marshall too. >=20 > Quite agree on focusing on the requirements, it is under work by > several > SP folks and others. >=20 > Regarding the diagram, absolutely, give us some time, we are > documenting. >=20 > About the milestones, we initially had a shorter list, we had comments > from AD to extend the milestones. May be we gone too far this time. I > checked the milestones of many WGs, they vary a lot, from very short to > very long, depending on the WG style and stage... In any case, we need > to continue refine it with the team, thanks for the input from you and > others. >=20 > I think we are largely in agreement. >=20 > Luyuan >=20 >=20 > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Tuesday, October 11, 2011 8:03 PM > > To: Luyuan Fang (lufang) > > Cc: l3vpn@ietf.org > > Subject: Re: VPN4DC at L3VPN in Taipei > > > > Luyuan, > > > > Thanks for your response. Let me say upfront that my interest in this > > work at this stage is purely that Marshall and I are going to have to > > chair your session in Taipei and so I'm just trying to understand a > bit > > better what it is and the context of any discussion I'm expected to > > moderate. > > > > More inline. > > > > On 11 Oct 2011, at 23:17, Luyuan Fang (lufang) wrote: > > >> Today a customer of a VPN service can advertise which IP addresses > > are > > >> in which sites attached to that VPN service using a routing > protocol > > >> over the CE-PE link (e.g. via OSPF) and that information is > > reflected > > >> to the relevant PEs in that VPN service using MP-BGP. > > >> > > >> It would be useful IMO if you could describe why that is not > > > sufficient > > >> for your needs and how the current capabilities of L3VPNs map (or > do > > >> not) to your needs. Is it just that the "CE" is no longer the > access > > >> router for a VPN site but now starts to be implemented within a > > >> switch/router/hypervisor sat behind the access router? Is it that > > the > > >> CE (access router) still advertises routing to the PE as it would > > > today > > >> but you are proposing some additional mechanism for installing > state > > >> into switches/routers/hypervisors behind that CE and for how those > > >> switches/routers/hypervisors advertise that state to the CE for > > onward > > >> advertisement (by existing L3VPN mechanisms) to the upstream PE > for > > >> that VPN site? Is it that the existing CE-PE advertisement > > mechanisms > > >> are unsuitable for some reason and a new CE-PE protocol is > required? > > >> etc. > > > > > > Today's BGP/MPLS VPNs work well in the regular enterprise VPN > > scenarios. > > > It has been more 12 years since we first working on it. It is one > of > > the > > > great technology success stories over the last decade. > > > > > > This BOF took a different focus on where and how we want to apply > > what > > > VPN technologies. It is about data center, cloud services, where > the > > end > > > system is most suited with light weight control protocols. > > > > One of the things I'm trying to understand is when & how these new > > light weight control protocols running on end systems in data centers > > are expected to interact with the existing L3VPN control protocols. > > > > > The > > > provisioning process today is rather segmented as we learned from > > > Service Providers, there is strong desire to have a standard, > > scalable > > > mechanism to solve the end-to-end/machine-to-machine connectivity > > > issues. Ning is updating his requirements draft to shade more light > > on > > > this. > > > > One thing that might help my understanding at least would be a > diagram > > or some prose that shows the components (hosts, gateways, CEs, PEs, > > etc.) sitting between a pair of hosts within the same VPN and showing > > what portion of that end to end flow is satisfied by existing > > mechanisms versus what portions require new mechanisms. I guess it > > might need to show two dimensions: (1) the existing/new portions > > required to advertise the necessary forwarding between the different > > components and (2) the new/existing portions required to provision > > services/state that is separate to the forwarding state in the > > different components. > > > > Figures 1-3 in draft-so-vdcs-01 start to do that a little bit by > > showing different physical/logical views with respect to what a PE > sees > > but aren't very specific in where new versus existing functionality > is > > used to achieve the end result. > > > > >>> BOF Agenda for IETF 82 > > >>> November, 2011, Taibei > > >>> - Discuss and agree on charter definitions: problems space, > scope, > > >>> requirements, candidate solutions, general interests, encourage > > >>> participation from DC groups and from SP groups > > >>> - Present initial draft of problem statements > > >>> - Present initial draft of requirements > > >>> - Present initial draft of use cases > > >>> - Present one or more initial draft(s) of protocol > solution(s) > > >> > > >> While the topics above are valid topics to discuss I think it > would > > >> also be beneficial to include specific aims for what you think the > > >> meeting should achieve beyond just presenting drafts and > discussing > > >> material. > > >> > > >> For example: > > >> - Is the aim to discuss the work in general and receive feedback > on > > it > > >> from the IETF community but nothing further at this stage? > > >> - Is the aim to determine if there is consensus that the work is > > work > > >> that is required and should be taken on by IETF? > > >> - Is the aim to determine if the work does/does not fit within the > > >> scope of L3VPN? > > >> - etc (including some combination of the above). > > >> > > > > > > This proposed BOF had a goal to form a new WG to work on the topic, > > > separately from L3VPN. > > > > > > AD suggested to use L3VPN meeting session to discuss this work in > > > Taipei, so Chairs from L3VPN requested session for this purpose, > > under > > > the condition that we have mailing list discussion, and have at > least > > > one vpn4dc related draft posted, otherwise there would be no L3VPN > > > meeting in Taipei as Marshall said in the earlier mail. > > > > > > We currently submitted two drafts, have at least two more coming > > soon, > > > and glad to see discussion picking up on the list. We also received > > > off-line mails from several folks expressed interests to this work. > > Our > > > goal is to together a group of people who are interested and > willing > > to > > > work on the requirements and solutions, produce useful work to the > > end > > > users (SPs, DCs, Enterprises, etc.) as soon as possible. > > > > > > Regarding charter, ADs/IESG will decide, I'd assume largely based > on > > the > > > outcome of the meeting in Taipei, and the current mailing list > > > discussion. > > > > So part of my job is to chair/moderate that discussion and my > questions > > above were meant to dig a little into what it is you want to achieve > > beyond just discussing some drafts, for example what sorts of > questions > > I might be expected to ask the room to help the ADs gauge if there is > > consensus for whatever outcome you would ideally like to have. > > > > If your goal is to form a WG then the most important things to > present > > and demonstrate IMO is that you have a well understood and clearly > > scoped problem statement as well as a draft charter that folks agree > > fairly reflects the work that needs to be undertaken to address the > > problem statement and an initial set of milestones that are realistic > > and that folks agree will achieve the cited aims. > > > > We can then focus the discussion and the available time on ensuring > > that folks reach a common understanding and (hopefully) consensus on > > those things, rather than for example letting the discussion get > bogged > > down in the specifics of a particular solution proposal. > > > > That is one of the reasons I suggested you significantly reduce the > > number of milestones you're proposing to just the most important > items > > required to articulate the problem space, requirements & solutions > > needed in order to do something meaningful as a first step because > I'm > > highly doubtful that it will be possible for us to have a focussed > > discussion that results in consensus for a charter that contains 39 > > milestones... > > > > Ben From lufang@cisco.com Wed Oct 12 15:54:16 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B982821F8AFF for ; Wed, 12 Oct 2011 15:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 mI+Px1JPiN88 for ; Wed, 12 Oct 2011 15:54:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 683FF21F8AFB for ; Wed, 12 Oct 2011 15:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=10666; q=dns/txt; s=iport; t=1318460055; x=1319669655; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=u4j2IoKkj1VajLoUERVGuaGkOzfl6XCOErHxM/GV2AE=; b=ThhvYkSS1zLgTh1JPOiev41FThpjm6b2EJA0ON+HGPyajDUWTxTSq5ln +SMqPNuONTlROpnXFrO+1Maej22vB4Qqmo+EoHR2AnVrmWMQEJd7Cfnt1 vu4PbLlP7zyx4TZbgDlaJSuOVbI6oNCya1BcQrjOGY3cSsjOB+Vu1Nc1g M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIAACQalk6tJV2Z/2dsb2JhbABDmSCPIYEFgVMBAQEBAxIBHQo0BgUMBAIBCBEEAQEBCgYXAQYBRQkIAgQBEggMBweiCQGeRYZ3YQSHf5EnjEE X-IronPort-AV: E=Sophos;i="4.69,337,1315180800"; d="scan'208";a="27987534" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 12 Oct 2011 22:54:14 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9CMsDOM017800; Wed, 12 Oct 2011 22:54:13 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); Wed, 12 Oct 2011 17:54:13 -0500 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 Subject: RE: VPN4DC at L3VPN in Taipei Date: Wed, 12 Oct 2011 17:54:08 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2507147AF9@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN4DC at L3VPN in Taipei Thread-Index: AcyCyGAvMy1n7PIQT3mJE3w1u7CcbQFFSu9AACFVawAACIwWAAADse0AAAK89AAAIywCIAAAC4wAAAFvlTAAABZ1oA== References: <238542D917511A45B6B8AA806E875E250709B7CF@XMB-RCD-201.cisco.com><3B6CD5F5-9510-487E-AC30-575CE1B7427B@niven-jenkins.co.uk><238542D917511A45B6B8AA806E875E250709BB60@XMB-RCD-201.cisco.com><69D0559E-67A5-4111-9816-64E40F3847C4@niven-jenkins.co.uk> <238542D917511A45B6B8AA806E875E250709BC03@XMB-RCD-201.cisco.com> <238542D917511A45B6B8AA806E875E2507147AD0@XMB-RCD-201.cisco.com> From: "Luyuan Fang (lufang)" To: "UTTARO, JAMES" , "Ben Niven-Jenkins" X-OriginalArrivalTime: 12 Oct 2011 22:54:13.0332 (UTC) FILETIME=[DC89C140:01CC8931] Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 22:54:16 -0000 Sure thing. Luyuan > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Wednesday, October 12, 2011 6:51 PM > To: Luyuan Fang (lufang); Ben Niven-Jenkins > Cc: l3vpn@ietf.org > Subject: RE: VPN4DC at L3VPN in Taipei >=20 > Pls include me in this effort.. >=20 > Jim Uttaro >=20 > -----Original Message----- > From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > Sent: Wednesday, October 12, 2011 6:12 PM > To: UTTARO, JAMES; Ben Niven-Jenkins > Cc: l3vpn@ietf.org > Subject: RE: VPN4DC at L3VPN in Taipei >=20 > Absolutely, Jim. > It will an individual draft at first, then moving toward WG doc when > consensus is built... > Thanks, > Luyuan >=20 > > -----Original Message----- > > From: UTTARO, JAMES [mailto:ju1738@att.com] > > Sent: Wednesday, October 12, 2011 6:09 PM > > To: Luyuan Fang (lufang); Ben Niven-Jenkins > > Cc: l3vpn@ietf.org > > Subject: RE: VPN4DC at L3VPN in Taipei > > > > Is the requirements intended as a WG document? I think it should be.. > > > > Jim Uttaro > > > > -----Original Message----- > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > Behalf > > Of Luyuan Fang (lufang) > > Sent: Tuesday, October 11, 2011 9:22 PM > > To: Ben Niven-Jenkins > > Cc: l3vpn@ietf.org > > Subject: RE: VPN4DC at L3VPN in Taipei > > > > Ben, > > > > Thanks for the discussion again. > > Appreciate the effort you are making to dig down the problem space > and > > making many good points. Thanks to Marshall too. > > > > Quite agree on focusing on the requirements, it is under work by > > several > > SP folks and others. > > > > Regarding the diagram, absolutely, give us some time, we are > > documenting. > > > > About the milestones, we initially had a shorter list, we had > comments > > from AD to extend the milestones. May be we gone too far this time. I > > checked the milestones of many WGs, they vary a lot, from very short > to > > very long, depending on the WG style and stage... In any case, we > need > > to continue refine it with the team, thanks for the input from you > and > > others. > > > > I think we are largely in agreement. > > > > Luyuan > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Tuesday, October 11, 2011 8:03 PM > > > To: Luyuan Fang (lufang) > > > Cc: l3vpn@ietf.org > > > Subject: Re: VPN4DC at L3VPN in Taipei > > > > > > Luyuan, > > > > > > Thanks for your response. Let me say upfront that my interest in > this > > > work at this stage is purely that Marshall and I are going to have > to > > > chair your session in Taipei and so I'm just trying to understand a > > bit > > > better what it is and the context of any discussion I'm expected to > > > moderate. > > > > > > More inline. > > > > > > On 11 Oct 2011, at 23:17, Luyuan Fang (lufang) wrote: > > > >> Today a customer of a VPN service can advertise which IP > addresses > > > are > > > >> in which sites attached to that VPN service using a routing > > protocol > > > >> over the CE-PE link (e.g. via OSPF) and that information is > > > reflected > > > >> to the relevant PEs in that VPN service using MP-BGP. > > > >> > > > >> It would be useful IMO if you could describe why that is not > > > > sufficient > > > >> for your needs and how the current capabilities of L3VPNs map > (or > > do > > > >> not) to your needs. Is it just that the "CE" is no longer the > > access > > > >> router for a VPN site but now starts to be implemented within a > > > >> switch/router/hypervisor sat behind the access router? Is it > that > > > the > > > >> CE (access router) still advertises routing to the PE as it > would > > > > today > > > >> but you are proposing some additional mechanism for installing > > state > > > >> into switches/routers/hypervisors behind that CE and for how > those > > > >> switches/routers/hypervisors advertise that state to the CE for > > > onward > > > >> advertisement (by existing L3VPN mechanisms) to the upstream PE > > for > > > >> that VPN site? Is it that the existing CE-PE advertisement > > > mechanisms > > > >> are unsuitable for some reason and a new CE-PE protocol is > > required? > > > >> etc. > > > > > > > > Today's BGP/MPLS VPNs work well in the regular enterprise VPN > > > scenarios. > > > > It has been more 12 years since we first working on it. It is one > > of > > > the > > > > great technology success stories over the last decade. > > > > > > > > This BOF took a different focus on where and how we want to apply > > > what > > > > VPN technologies. It is about data center, cloud services, where > > the > > > end > > > > system is most suited with light weight control protocols. > > > > > > One of the things I'm trying to understand is when & how these new > > > light weight control protocols running on end systems in data > centers > > > are expected to interact with the existing L3VPN control protocols. > > > > > > > The > > > > provisioning process today is rather segmented as we learned from > > > > Service Providers, there is strong desire to have a standard, > > > scalable > > > > mechanism to solve the end-to-end/machine-to-machine connectivity > > > > issues. Ning is updating his requirements draft to shade more > light > > > on > > > > this. > > > > > > One thing that might help my understanding at least would be a > > diagram > > > or some prose that shows the components (hosts, gateways, CEs, PEs, > > > etc.) sitting between a pair of hosts within the same VPN and > showing > > > what portion of that end to end flow is satisfied by existing > > > mechanisms versus what portions require new mechanisms. I guess it > > > might need to show two dimensions: (1) the existing/new portions > > > required to advertise the necessary forwarding between the > different > > > components and (2) the new/existing portions required to provision > > > services/state that is separate to the forwarding state in the > > > different components. > > > > > > Figures 1-3 in draft-so-vdcs-01 start to do that a little bit by > > > showing different physical/logical views with respect to what a PE > > sees > > > but aren't very specific in where new versus existing functionality > > is > > > used to achieve the end result. > > > > > > >>> BOF Agenda for IETF 82 > > > >>> November, 2011, Taibei > > > >>> - Discuss and agree on charter definitions: problems > space, > > scope, > > > >>> requirements, candidate solutions, general interests, encourage > > > >>> participation from DC groups and from SP groups > > > >>> - Present initial draft of problem statements > > > >>> - Present initial draft of requirements > > > >>> - Present initial draft of use cases > > > >>> - Present one or more initial draft(s) of protocol > > solution(s) > > > >> > > > >> While the topics above are valid topics to discuss I think it > > would > > > >> also be beneficial to include specific aims for what you think > the > > > >> meeting should achieve beyond just presenting drafts and > > discussing > > > >> material. > > > >> > > > >> For example: > > > >> - Is the aim to discuss the work in general and receive feedback > > on > > > it > > > >> from the IETF community but nothing further at this stage? > > > >> - Is the aim to determine if there is consensus that the work is > > > work > > > >> that is required and should be taken on by IETF? > > > >> - Is the aim to determine if the work does/does not fit within > the > > > >> scope of L3VPN? > > > >> - etc (including some combination of the above). > > > >> > > > > > > > > This proposed BOF had a goal to form a new WG to work on the > topic, > > > > separately from L3VPN. > > > > > > > > AD suggested to use L3VPN meeting session to discuss this work in > > > > Taipei, so Chairs from L3VPN requested session for this purpose, > > > under > > > > the condition that we have mailing list discussion, and have at > > least > > > > one vpn4dc related draft posted, otherwise there would be no > L3VPN > > > > meeting in Taipei as Marshall said in the earlier mail. > > > > > > > > We currently submitted two drafts, have at least two more coming > > > soon, > > > > and glad to see discussion picking up on the list. We also > received > > > > off-line mails from several folks expressed interests to this > work. > > > Our > > > > goal is to together a group of people who are interested and > > willing > > > to > > > > work on the requirements and solutions, produce useful work to > the > > > end > > > > users (SPs, DCs, Enterprises, etc.) as soon as possible. > > > > > > > > Regarding charter, ADs/IESG will decide, I'd assume largely based > > on > > > the > > > > outcome of the meeting in Taipei, and the current mailing list > > > > discussion. > > > > > > So part of my job is to chair/moderate that discussion and my > > questions > > > above were meant to dig a little into what it is you want to > achieve > > > beyond just discussing some drafts, for example what sorts of > > questions > > > I might be expected to ask the room to help the ADs gauge if there > is > > > consensus for whatever outcome you would ideally like to have. > > > > > > If your goal is to form a WG then the most important things to > > present > > > and demonstrate IMO is that you have a well understood and clearly > > > scoped problem statement as well as a draft charter that folks > agree > > > fairly reflects the work that needs to be undertaken to address the > > > problem statement and an initial set of milestones that are > realistic > > > and that folks agree will achieve the cited aims. > > > > > > We can then focus the discussion and the available time on ensuring > > > that folks reach a common understanding and (hopefully) consensus > on > > > those things, rather than for example letting the discussion get > > bogged > > > down in the specifics of a particular solution proposal. > > > > > > That is one of the reasons I suggested you significantly reduce the > > > number of milestones you're proposing to just the most important > > items > > > required to articulate the problem space, requirements & solutions > > > needed in order to do something meaningful as a first step because > > I'm > > > highly doubtful that it will be possible for us to have a focussed > > > discussion that results in consensus for a charter that contains 39 > > > milestones... > > > > > > Ben From tnadeau@lucidvision.com Thu Oct 13 14:33:43 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8337321F8B9B for ; Thu, 13 Oct 2011 14:33:43 -0700 (PDT) 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 W7DJ7JtmkkmE for ; Thu, 13 Oct 2011 14:33:43 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 52D3B21F8B29 for ; Thu, 13 Oct 2011 14:33:43 -0700 (PDT) Received: from [192.168.1.144] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id F04DF1EDF7BB for ; Thu, 13 Oct 2011 17:33:42 -0400 (EDT) From: Thomas Nadeau Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Software Defined Networks (SDN) BoF in Taipei Date: Thu, 13 Oct 2011 17:33:39 -0400 Message-Id: <34F7F013-997C-4B4D-B598-953D869E0A95@lucidvision.com> To: L3VPN WG mailing list Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:33:43 -0000 As an FYI, the initial schedule is out. The SDN BoF is planned = for Thursday afternoon from 1520-1720 in room 201 DEF. http://tools.ietf.org/agenda/82/ As usual, caveat emptor in that this is the initial schedule = which often changes. Please plan on being there M-F in case the = schedule changes. --Tom From xuxiaohu@huawei.com Thu Oct 13 19:48:03 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40A121F8C17; Thu, 13 Oct 2011 19:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 U3TmVv6o9+Iz; Thu, 13 Oct 2011 19:48:03 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A1DF521F8C10; Thu, 13 Oct 2011 19:48:02 -0700 (PDT) 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 <0LT1006SOBS0EY@szxga03-in.huawei.com>; Fri, 14 Oct 2011 10:48:00 +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 <0LT100I9YBS0K9@szxga03-in.huawei.com>; Fri, 14 Oct 2011 10:48:00 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEL25499; Fri, 14 Oct 2011 10:47:59 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 14 Oct 2011 10:47:54 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 10:47:51 +0800 Date: Fri, 14 Oct 2011 02:47:51 +0000 From: Xuxiaohu Subject: re: possible scope gap//re: [nvo3] L2VPN overlap? X-Originating-IP: [10.108.4.66] To: Murari Sridharan , Thomas Narten , "nvo3@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE738D15@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_C7RzNrZIxMCLrpglxS8Dyw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: possible scope gap//re: [nvo3] L2VPN overlap? Thread-index: AQHMgjl58MaBPbTLN0ykbFrwIKf11JVrFaoAgAgxL0CAB+3UAA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <201110040004.p94048u7009531@cichlid.raleigh.ibm.com> Cc: "l2vpn@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 02:48:04 -0000 --Boundary_(ID_C7RzNrZIxMCLrpglxS8Dyw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 VGhlcmUgaXMgYSBtaXN0YWtlIHRoYXQgSSBzaG91bGQgY29ycmVjdC4gVGhhdCBpcyBEYXRhIENl bnRlciBNb2JpbGl0eSAoaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yYWdn YXJ3YS1kYXRhLWNlbnRlci1tb2JpbGl0eSkgc3RpbGwgdXNlcyBMMiBvdmVybGF5IChpLmUuLCBN QUMtYmFzZWQgZm9yd2FyZGluZyApIHRvIGNvbm5lY3QgVk1zIHdoaWNoIGFyZSBiZWxvbmcgdG8g dGhlIHNhbWUgc3VibmV0LCBhbmQgaG9zdCByb3V0ZXMgYXJlIG9ubHkgdXNlZCBmb3IgaW50ZXIt c3VibmV0IGNvbW11bmljYXRpb24uDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQq3orz+yMs6 IFh1eGlhb2h1DQq3osvNyrG85DogMjAxMcTqMTDUwjnI1SAxMDo0NQ0KytW8/sjLOiAnTXVyYXJp IFNyaWRoYXJhbic7IFRob21hcyBOYXJ0ZW47IG52bzNAaWV0Zi5vcmcNCrOty806IGwydnBuQGll dGYub3JnOyAnbDN2cG5AaWV0Zi5vcmcnDQrW98ziOiBwb3NzaWJsZSBzY29wZSBnYXAvL3JlOiBb bnZvM10gTDJWUE4gb3ZlcmxhcD8NCg0KSXQgaXMgYSBnb29kIHF1ZXN0aW9uLg0KDQpJTUhPLCBJ dKGvcyBhYnNvbHV0ZWx5IHBvc3NpYmxlIHRvIHJlYWxpemUgbmV0d29yayB2aXJ0dWFsaXphdGlv biBpbiBhIGRhdGEgY2VudGVyIG9yIGFjcm9zcyBtdWx0aXBsZSBkYXRhIGNlbnRlcnMgYnkgdXNp bmcgTDMgb3ZlcmxheSwgZXNwZWNpYWxseSBob3N0IHJvdXRlIGJhc2VkIElQLW9ubHkgTDJWUE4g c2VydmljZS4gSG9zdCByb3V0ZSBiYXNlZCBJUC1vbmx5IEwyVlBOIHNlcnZpY2UgY291bGQgYWxz byBhbGxvdyB0aGUgaG9zdHMgd2l0aGluIGEgZ2l2ZSBWUE4gaW5zdGFuY2UgdG8gYWN0IGFzIGlm IHRoZXkgd2VyZSBsb2NhdGVkIHdpdGhpbiBhIHN1Ym5ldC9MQU4gZXhjZXB0IHRoYXQgb25seSBJ UCB0cmFmZmljIGlzIHN1cHBvcnRlZC4gQ29tcGFyZWQgdG8gdGhvc2UgTUFDIGZvcndhcmRpbmcg YmFzZWQgTDJWUE4gc2VydmljZXMgKGkuZS4sIEwyIG92ZXJsYXkpIHN1Y2ggYXMgVlBMUywgIGhv c3Qgcm91dGUgYmFzZWQgSVAtb25seSBMMlZQTiBzZXJ2aWNlIGRvZXMgc2VlbSBhIGJpdCByZXN0 cmljdGl2ZSBzaW5jZSB0aG9zZSBsZWdhY3kgbm9uLUlQIGFwcGxpY2F0aW9ucyAoZS5nLiwgbGlu ay1sb2NhbCBtdWx0aWNhc3QsIG5vbi1JUCB1bmljYXN0KSB3b3VsZCBub3QgYmUgc3VwcG9ydGVk LiBIb3dldmVyLCBob3N0IGJhc2VkIElQLW9ubHkgTDJWUE4gc2VydmljZSBoYXMgbWFueSB1bmlx dWUgYW5kIGNoYXJtaW5nIGFkdmFudGFnZXMgaW4gYWRkcmVzc2luZyB0aGUgc2NhbGluZyBpc3N1 ZXMgdGhhdCB0b2RheaGvcyBjbG91ZCBkYXRhIGNlbnRlcnMgYXJlIGZhY2luZywgc3VjaCBhcyBB UlAgYnJvYWRjYXN0IHN0b3JtIHJlZHVjdGlvbiwgdW5rbm93biB1bmljYXN0IGZsb29kaW5nIGF2 b2lkYW5jZSwgTUFDIHRhYmxlIHJlZHVjdGlvbiBvbiBDRSBzd2l0Y2hlcywgYWN0aXZlLWFjdGl2 ZSBEQyBleGl0IGFuZCBBUlAgdGFibGUgcmVkdWN0aW9uIG9uIERDIGV4aXQgcm91dGVycy4uLg0K DQpFeGFtcGxlcyBvZiBzdWNoIGFwcHJvYWNoIGFyZToNClZpcnR1YWwgU3VibmV0IChodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS12aXJ0dWFsLXN1Ym5ldC0wNikNCkRhdGEgQ2Vu dGVyIE1vYmlsaXR5IChodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhZ2dh cndhLWRhdGEtY2VudGVyLW1vYmlsaXR5KQ0KVkwyKGh0dHA6Ly9yZXNlYXJjaC5taWNyb3NvZnQu Y29tL2FwcHMvcHVicy9kZWZhdWx0LmFzcHg/aWQ9ODA2OTMpDQoNCkJlc3QgcmVnYXJkcywNClhp YW9odQ0KDQq3orz+yMs6IG52bzMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm52bzMtYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBNdXJhcmkgU3JpZGhhcmFuDQq3osvNyrG85DogMjAxMcTqMTDUwjTI 1SAxMjo0Mw0KytW8/sjLOiBUaG9tYXMgTmFydGVuOyBudm8zQGlldGYub3JnDQrW98ziOiBSZTog W252bzNdIEwyVlBOIG92ZXJsYXA/DQoNCldoeSBhcmUgd2UgcmVzdHJpY3RpbmcgdGhlIGRpc2N1 c3Npb24gdG8ganVzdCBMMiBvdmVybGF5cz8gVGhlIHZpcnR1YWwgdG9wb2xvZ3kgY2FuIGJlIEwz IGFzIHdlbGwuDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRnJvbTogVGhvbWFzIE5hcnRlbg0KU2VudDogMTAvMy8yMDExIDc6 MDQgUE0NClRvOiBudm8zQGlldGYub3JnDQpTdWJqZWN0OiBbbnZvM10gTDJWUE4gb3ZlcmxhcD8N CkZZSSwgYSBkaXNjdXNzaW9uIG9mIHNvcnRzIHN0YXJ0ZWQgb24gdGhlIEwyVlBOIGxpc3QgYXMg dG8gd2hldGhlciBMMg0Kb3ZlcmxheXMgYXMgcHJvcG9zZWQgZm9yIHRoaXMgbGlzdCBhcmUgYWxy ZWFkeSBpbi1zY29wZSBmb3IgdGhlIEwyVlBODQpXRy4NCg0KSS5lLiwgc2VlIGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sMnZwbi9jdXJyZW50L21zZzAyODc0Lmh0bWwNCg0K VGhvbWFzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bnZvMyBtYWlsaW5nIGxpc3QNCm52bzNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnZvMw0K --Boundary_(ID_C7RzNrZIxMCLrpglxS8Dyw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

There is a= mistake that I should correct. That is Data Center Mobility (http://datatracker.iet= f.org/doc/draft-raggarwa-data-center-mobility) still uses L2 overlay (i.e., MAC-based forwarding ) to connect VMs which a= re belong to the same subnet, and host routes are only used for inter-subne= t communication.

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: Xuxiaoh= u
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C29=C8=D5 10:45
=CA=D5=BC=FE=C8=CB: 'Murari Sridharan'; Thomas Narten; nvo3@ietf.org
=B3=AD=CB=CD: l2vpn@ietf.org; 'l3vpn@ietf.org'
=D6=F7=CC=E2: possible scope gap//re: [nvo3] L2VPN overlap?

 

It is a go= od question.  

 = ;

IMHO, It= =A1=AFs absolutely possible to realize network virtualization in a data cen= ter or across multiple data centers by using L3 overlay, especially host route based IP-only L2VPN service. Host route based IP-only L2VPN ser= vice could also allow the hosts within a give VPN instance to act as if the= y were located within a subnet/LAN except that only IP traffic is supported= . Compared to those MAC forwarding based L2VPN services (i.e., L2 overlay) such as VPLS,  host route bas= ed IP-only L2VPN service does seem a bit restrictive since those legacy non= -IP applications (e.g., link-local multicast, non-IP unicast) would not be = supported. However, host based IP-only L2VPN service has many unique and charming advantages in addressing the sc= aling issues that today=A1=AFs cloud data centers are facing, such as ARP b= roadcast storm reduction, unknown unicast flooding avoidance, MAC table red= uction on CE switches, active-active DC exit and ARP table reduction on DC exit routers...

 = ;

Examples o= f such approach are:

Virtual Su= bnet (http://tools.ietf.org/html/= draft-xu-virtual-subnet-06)

Data Cente= r Mobility (http:/= /datatracker.ietf.org/doc/draft-raggarwa-data-center-mobility)

VL2(http:/= /research.microsoft.com/apps/pubs/default.aspx?id=3D80693)

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: nvo3-bo= unces@ietf.org [mailto:nvo3-bounces@ietf.org] =B4=FA= =B1=ED Murari Sridharan
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C24=C8=D5 12:43
=CA=D5=BC=FE=C8=CB: Thomas Narten; nvo3@ietf.org
=D6=F7=CC=E2: Re: [nvo3] L2VPN overlap?

 

Why are we restricting t= he discussion to just L2 overlays? The virtual topology can be L3 as well.<= br>
Sent from my Windows Phone

From: Thomas Narten
Sent: 10/3/2011 7:04 PM
To: nvo3@ietf.org
Subject: [nvo3] L2VPN overlap?

FYI, a discussion of sorts started on the L2VPN = list as to whether L2
overlays as proposed for this list are already in-scope for the L2VPN
WG.

I.e., see http://www.ietf.org/mail-archive/web/l2vpn/current/msg02874.html

Thomas
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org= /mailman/listinfo/nvo3

--Boundary_(ID_C7RzNrZIxMCLrpglxS8Dyw)-- From nabil.n.bitar@verizon.com Fri Oct 14 05:08:29 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD2121F8B74; Fri, 14 Oct 2011 05:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-aRowxTMfa0; Fri, 14 Oct 2011 05:08:28 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id A856421F8B6F; Fri, 14 Oct 2011 05:08:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 14 Oct 2011 12:08:15 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.69,346,1315180800"; d="scan'208,217";a="159093923" Received: from fldp1lumxc7hb05.verizon.com (HELO FLDP1LUMXC7HB05.us.one.verizon.com) ([166.68.75.87]) by fldsmtpi03.verizon.com with ESMTP; 14 Oct 2011 12:08:15 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.168]) by FLDP1LUMXC7HB05.us.one.verizon.com ([166.68.75.87]) with mapi; Fri, 14 Oct 2011 08:08:15 -0400 To: "l2vpn@ietf.org" Date: Fri, 14 Oct 2011 08:08:14 -0400 Subject: [l2vpn] L2vpn WG sessions at IETF 82 in Taipei, Taiwan - meeting dates/times Thread-Topic: [l2vpn] L2vpn WG sessions at IETF 82 in Taipei, Taiwan - meeting dates/times Thread-Index: AcyKafOK4GiaZ7l7Tqi/QjN8Y1v3MQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CABD97091FA4Enabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 12:08:29 -0000 --_000_CABD97091FA4Enabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The meeting sessions for the l2vpn working group at IETF 82 in Taipei have = been set. They are at the following dates and times: l2vpn Session 1 (2.5 hours) Monday, Afternoon Session I 1300-1500 Room Name: 201 ABC l2vpn Session 2 (2 hours) Thursday, Morning Session I 0900-1130 Room Name: 3F Banquet The second session on Thursday will be mainly focused on discussing and def= ining the problem that new drafts related to providing a layer2 service in = a Data center environment are trying to address. For some, it may be known = as NV03 work, and there was email exchange on the l2vpn working group email= list related to that. It was decided that this work will be presented and = discussed in the l2vpn working group with a main focus on defining the prob= lem and using the solutions in the drafts posted as examples of solution bu= t not to debate the solutions for now. We are trying to give the l2vpner's = headsup on that, but there will be more communication on this session withi= n the upcoming 2 weeks. The l3vpn WG is also cc'd as some may have interest= . Thanks, Giles & Nabil --_000_CABD97091FA4Enabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

    l2vpn= Session 1 (2.5 hours)
    Monday, Afte= rnoon Session I 1300-1500
    Room Name= : 201 ABC
  
   &n= bsp;l2vpn Session 2 (2 hours)
    Thurs= day, Morning Session I 0900-1130
    Ro= om Name: 3F Banquet

The second s= ession on Thursday will be mainly focused on discussing and defining the pr= oblem that new drafts related to providing a layer2 service in a Data cente= r environment are trying to address. For some, it may be known as NV03 work= , and there was email exchange on the l2vpn working group email list relate= d to that. It was decided that this work will be presented and discussed in= the l2vpn working group with a main focus on defining the problem and usin= g the solutions in the drafts posted as examples of solution but not to deb= ate the solutions for now. We are trying to give the l2vpner's headsup on t= hat, but there will be more communication on this session within the upcomi= ng 2 weeks. The l3vpn WG is also cc'd as some may have interest.

Thanks,
Gil= es & Nabil
--_000_CABD97091FA4Enabilnbitarverizoncom_-- From Michael@huaweisymantec.com Fri Oct 14 11:38:04 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428E221F8CA6 for ; Fri, 14 Oct 2011 11:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 TgfQtVQKm7qT for ; Fri, 14 Oct 2011 11:38:03 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by ietfa.amsl.com (Postfix) with ESMTP id 60B1A21F8C8B for ; Fri, 14 Oct 2011 11:38:03 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ZiCg3+E2W7cEs/qAdKpGRQ)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LT200FWGJRADH80@hstga01-in.huaweisymantec.com> for l3vpn@ietf.org; Sat, 15 Oct 2011 02:37:58 +0800 (CST) Received: from m90003900a ([10.47.140.11]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LT200JSDJQZAO00@hstml01-in.huaweisymantec.com> for l3vpn@ietf.org; Sat, 15 Oct 2011 02:37:58 +0800 (CST) Message-id: <9B2C6950889542C1B55655C3DA175119@china.huawei.com> From: Michael Ko To: l3vpn@ietf.org Subject: Problem statement draft for dynamic secure interconnect Date: Fri, 14 Oct 2011 11:37:47 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 18:38:04 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ZiCg3+E2W7cEs/qAdKpGRQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT I have submitted a draft stating the problems and challenges associated with the process of establishing secure interconnections between authorized network nodes. The network nodes can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT. Establishing a secure interconnection in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, connection parameters determination, etc. I believe the process of establishing secure interconnections between network nodes fits within the scope of VPN4DC and would like to request time at the L3VPN meeting to discuss the issues enumerated in the draft. Mike ----- Original Message ----- From: internet-drafts@ietf.org To: Michael@huaweisymantec.com Cc: Michael@huaweisymantec.com ; wangyc@huaweisymantec.com Sent: Friday, October 14, 2011 11:07 AM Subject: New Version Notification for draft-ko-dsi-problem-statement-00.txt A new version of I-D, draft-ko-dsi-problem-statement-00.txt has been successfully submitted by Michael Ko and posted to the IETF repository. Filename: draft-ko-dsi-problem-statement Revision: 00 Title: Problem Statement for Dynamic Secure Interconnect Creation date: 2011-10-14 WG ID: Individual Submission Number of pages: 12 Abstract: This document examines the problems and challenges associated with the process of setting up secure interconnections between authorized network nodes. The network nodes can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT [NAT]. Setting up a secure interconnection in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, and connection parameters determination. The IETF Secretariat --Boundary_(ID_ZiCg3+E2W7cEs/qAdKpGRQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
I have submitted a draft stating the problems and = challenges=20 associated with the process of establishing secure interconnections = between=20 authorized network nodes.  The network nodes can be located = anywhere in a=20 private or public network, directly connected or behind one or more = levels of=20 NAT.  Establishing a secure interconnection in this environment = entails the=20 resolution of various issues such as authentication, peer discovery, = virtual=20 network address management, connection parameters determination,=20 etc.    
 
I believe the process of establishing secure = interconnections=20 between network nodes fits within the scope of VPN4DC and would = like to=20 request time at the L3VPN meeting to discuss the issues enumerated = in the=20 draft.
 
Mike
----- Original Message -----=20
From: internet-drafts@ietf.org =
Cc: Michael@huaweisymantec.com= ; wangyc@huaweisymantec.com =
Sent: Friday, October 14, 2011 11:07 AM
Subject: New Version Notification for=20 draft-ko-dsi-problem-statement-00.txt

A new version of I-D, = draft-ko-dsi-problem-statement-00.txt has=20 been successfully submitted by Michael Ko and posted to the IETF=20 repository.

Filename: draft-ko-dsi-problem-statement
Revision: = 00
Title: Problem Statement for Dynamic Secure = Interconnect
Creation date:=20 2011-10-14
WG ID: Individual Submission
Number of pages:=20 12

Abstract:
   This document examines the problems = and=20 challenges associated with
   the process of setting up = secure=20 interconnections between authorized
   network nodes.  = The=20 network nodes can be located anywhere in a
   private or = public=20 network, directly connected or behind one or more
   levels = of NAT=20 [NAT].  Setting up a secure interconnection in this
   = environment entails the resolution of various issues such = as
  =20 authentication, peer discovery, virtual network address=20 management,
   and connection parameters=20 determination.

        &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           =20


The IETF Secretariat
--Boundary_(ID_ZiCg3+E2W7cEs/qAdKpGRQ)-- From lufang@cisco.com Fri Oct 14 15:15:34 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6B521F8CA0; Fri, 14 Oct 2011 15:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=2.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VALCoPNFcgfL; Fri, 14 Oct 2011 15:15:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEF821F8A91; Fri, 14 Oct 2011 15:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=5157; q=dns/txt; s=iport; t=1318630533; x=1319840133; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=jv7bhpkOwu/kPb4Xssrts3KqsvtaE9YKY03zpnyK/T0=; b=c4aY+Kfrvw1gtm2oFm9PsONSj26Vevm7tnE4b7bm2a2u2KAX7m1EEx1L nv0pEQCXIv1tHWfTaqX4cl/BHnUEoO+zTUa+PR/bVRPWCBSNzLs2ERamB zu3V2k1htsOE74FaDwZIuqUkoUH6+sN98VEKipctdSK8kOHdSsZ5+dfhr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFANWzmE6tJV2b/2dsb2JhbABDgk2eXgGHO4EFgW8BAQEDEgEJEQNZAgEqBhgGAVYBAQQBGhqhDgGeQ4cYYQSIAZEnjEI X-IronPort-AV: E=Sophos;i="4.69,348,1315180800"; d="scan'208,217";a="28589451" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 14 Oct 2011 22:15:33 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9EMFZQ5008721; Fri, 14 Oct 2011 22:15:35 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, 14 Oct 2011 17:15:32 -0500 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_01CC8ABE.C9D50F73" Subject: L3 VPN4DC discussion in L3vpn WG session, and Bar BOF in Taipei, Date: Fri, 14 Oct 2011 17:15:30 -0500 Message-ID: <238542D917511A45B6B8AA806E875E250714832A@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L3 VPN4DC discussion in L3vpn WG session, and Bar BOF in Taipei, Thread-Index: AcyKafOK4GiaZ7l7Tqi/QjN8Y1v3MQAR+q7Q References: From: "Luyuan Fang (lufang)" To: , , X-OriginalArrivalTime: 14 Oct 2011 22:15:32.0814 (UTC) FILETIME=[CA3A4EE0:01CC8ABE] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 22:15:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8ABE.C9D50F73 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Heads-up for those who are interested in vpn4dc discussion in Taipei. =20 Per IETF schedule http://tools.ietf.org/agenda/82/ L3VPN session has one hour on Wed. Nov. 16, 15:10 - 16:10PM. (Note that the schedule may change, as usual.) =20 L3VPN WG chairs will set the meeting agenda; we will work with the chairs to best use that 1 hour. =20 For those who are interested in vpn4dc Bar BOF, please ping me off-line. We will find a Bar, a corner in the lobby, or go dinner to work together. =20 Thanks, Luyuan ------_=_NextPart_001_01CC8ABE.C9D50F73 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Heads-up for those who are interested in vpn4dc discussion in = Taipei.

 

Per IETF schedule http://tools.ietf.org/agenda/82= /

L3VPN session has one hour on Wed. Nov. 16, 15:10 – = 16:10PM.

(Note that the schedule may change, as usual.)

 

L3VPN WG chairs will set the meeting agenda; we will work with the chairs to = best use that 1 hour.

 

For those who are interested in vpn4dc Bar BOF, please ping me off-line. We = will find a Bar, a corner in the lobby, or go dinner to work = together.

 

Thanks,<= /o:p>

Luyuan

------_=_NextPart_001_01CC8ABE.C9D50F73-- From Michael@huaweisymantec.com Wed Oct 19 10:45:03 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378D321F8BAA for ; Wed, 19 Oct 2011 10:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 paiiA+-iRyUm for ; Wed, 19 Oct 2011 10:45:02 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by ietfa.amsl.com (Postfix) with ESMTP id 576FE21F8C3C for ; Wed, 19 Oct 2011 10:45:02 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TLF7XnfEZb3IRGwQ5QlsnQ)" Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LTB00540QMZ4000@hstga01-in.huaweisymantec.com> for l3vpn@ietf.org; Thu, 20 Oct 2011 01:44:59 +0800 (CST) Received: from m90003900a ([10.212.245.61]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LTB00AFEQMQSW00@hstml02-in.huaweisymantec.com> for l3vpn@ietf.org; Thu, 20 Oct 2011 01:44:59 +0800 (CST) Message-id: From: Michael Ko To: l3vpn@ietf.org References: <9B2C6950889542C1B55655C3DA175119@china.huawei.com> Subject: Re: Problem statement draft for dynamic secure interconnect Date: Wed, 19 Oct 2011 10:44:50 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:45:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TLF7XnfEZb3IRGwQ5QlsnQ) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Here is the link to the document: http://www.ietf.org/id/draft-ko-dsi-problem-statement-00.txt Mike ----- Original Message ----- From: Michael Ko To: l3vpn@ietf.org Sent: Friday, October 14, 2011 11:37 AM Subject: Problem statement draft for dynamic secure interconnect I have submitted a draft stating the problems and challenges associated with the process of establishing secure interconnections between authorized network nodes. The network nodes can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT. Establishing a secure interconnection in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, connection parameters determination, etc. I believe the process of establishing secure interconnections between network nodes fits within the scope of VPN4DC and would like to request time at the L3VPN meeting to discuss the issues enumerated in the draft. Mike ----- Original Message ----- From: internet-drafts@ietf.org To: Michael@huaweisymantec.com Cc: Michael@huaweisymantec.com ; wangyc@huaweisymantec.com Sent: Friday, October 14, 2011 11:07 AM Subject: New Version Notification for draft-ko-dsi-problem-statement-00.txt A new version of I-D, draft-ko-dsi-problem-statement-00.txt has been successfully submitted by Michael Ko and posted to the IETF repository. Filename: draft-ko-dsi-problem-statement Revision: 00 Title: Problem Statement for Dynamic Secure Interconnect Creation date: 2011-10-14 WG ID: Individual Submission Number of pages: 12 Abstract: This document examines the problems and challenges associated with the process of setting up secure interconnections between authorized network nodes. The network nodes can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT [NAT]. Setting up a secure interconnection in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, and connection parameters determination. The IETF Secretariat --Boundary_(ID_TLF7XnfEZb3IRGwQ5QlsnQ) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
Here is the link to the document: htt= p://www.ietf.org/id/draft-ko-dsi-problem-statement-00.txt
 
Mike
----- Original Message -----=20
From: Michael Ko
Sent: Friday, October 14, 2011 11:37 AM
Subject: Problem statement draft for dynamic secure=20 interconnect

I have submitted a draft stating the problems and = challenges=20 associated with the process of establishing secure interconnections = between=20 authorized network nodes.  The network nodes can be located = anywhere in a=20 private or public network, directly connected or behind one or more = levels of=20 NAT.  Establishing a secure interconnection in this environment = entails the=20 resolution of various issues such as authentication, peer discovery, = virtual=20 network address management, connection parameters determination,=20 etc.    
 
I believe the process of establishing secure = interconnections=20 between network nodes fits within the scope of VPN4DC and would = like to=20 request time at the L3VPN meeting to discuss the issues enumerated = in the=20 draft.
 
Mike
----- Original Message -----=20
From: internet-drafts@ietf.org =
Cc: Michael@huaweisymantec.com= ; wangyc@huaweisymantec.com =
Sent: Friday, October 14, 2011 11:07 AM
Subject: New Version Notification for=20 draft-ko-dsi-problem-statement-00.txt

A new version of I-D, = draft-ko-dsi-problem-statement-00.txt has=20 been successfully submitted by Michael Ko and posted to the IETF=20 repository.

Filename: draft-ko-dsi-problem-statement
Revision: = 00
Title: Problem Statement for Dynamic Secure = Interconnect
Creation date:=20 2011-10-14
WG ID: Individual Submission
Number of pages:=20 12

Abstract:
   This document examines the problems = and=20 challenges associated with
   the process of setting up = secure=20 interconnections between authorized
   network nodes.  = The=20 network nodes can be located anywhere in a
   private or = public=20 network, directly connected or behind one or more
   levels = of NAT=20 [NAT].  Setting up a secure interconnection in this
   = environment entails the resolution of various issues such = as
  =20 authentication, peer discovery, virtual network address=20 management,
   and connection parameters=20 determination.

        &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           =20


The IETF Secretariat
--Boundary_(ID_TLF7XnfEZb3IRGwQ5QlsnQ)-- From lucy.yong@huawei.com Mon Oct 24 05:29:43 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECBC21F8C71 for ; Mon, 24 Oct 2011 05:29:43 -0700 (PDT) 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.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 N-DlKeiiqMJA for ; Mon, 24 Oct 2011 05:29:43 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 181DA21F8C52 for ; Mon, 24 Oct 2011 05:29:43 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTK004RELDH1D@usaga02-in.huawei.com> for l3vpn@ietf.org; Mon, 24 Oct 2011 07:29:42 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LTK00IETLDHU2@usaga02-in.huawei.com> for l3vpn@ietf.org; Mon, 24 Oct 2011 07:29:41 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Oct 2011 05:29:39 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Mon, 24 Oct 2011 05:29:31 -0700 Date: Mon, 24 Oct 2011 12:29:24 +0000 From: Lucy yong Subject: L3VPN Gap Analysis for VPN4DC X-Originating-IP: [10.195.69.147] To: "l3vpn@ietf.org" Message-id: <2691CE0099834E4A9C5044EEC662BB9D118D0A6F@dfweml505-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_WUcHGMnwsu6Q6/itXR6Wvg)" Content-language: en-US Accept-Language: en-US Thread-topic: L3VPN Gap Analysis for VPN4DC Thread-index: AcySSJIjJwJHmVhATwKJ6P3ctiHA7w== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 12:29:43 -0000 --Boundary_(ID_WUcHGMnwsu6Q6/itXR6Wvg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT FYI A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : L3VPN Protocol Gap Analysis for Data Centers Author(s) : Lucy Yong Susan Hares Filename : draft-yong-vpn4dc-protocol-gap-analysis-00.txt Pages : 8 Date : 2011-10-24 An enterprise may need to connect their applications hosted in offsite provider data centers to their own premises via their dedicated L3VPN. The draft reviews L3VPN protocols for this application and discusses the protocol gaps to meet the requirements of VPN4DC. [VPN4DC] Look forward to discussing this in Taipei. Lucy --Boundary_(ID_WUcHGMnwsu6Q6/itXR6Wvg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

FYI

 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 

        Title           : L3VPN Protocol Gap Analysis for Data Centers

        Author(s)       : Lucy Yong

                          Susan Hares

        Filename        : draft-yong-vpn4dc-protocol-gap-analysis-00.txt

        Pages           : 8

        Date            : 2011-10-24

 

   An enterprise may need to connect their applications hosted in

   offsite provider data centers to their own premises via their

   dedicated L3VPN. The draft reviews L3VPN protocols for this

   application and discusses the protocol gaps to meet the requirements

   of VPN4DC. [VPN4DC]

 

Look forward to discussing this in Taipei.

 

Lucy

--Boundary_(ID_WUcHGMnwsu6Q6/itXR6Wvg)-- From wesley.george@twcable.com Mon Oct 24 14:41:15 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936D511E813B; Mon, 24 Oct 2011 14:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=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 q--3pmVRiaRt; Mon, 24 Oct 2011 14:41:15 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DCCFE11E80AE; Mon, 24 Oct 2011 14:41:14 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,399,1315195200"; d="scan'208";a="289063610" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Oct 2011 17:37:25 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 24 Oct 2011 17:41:13 -0400 From: "George, Wes" To: "l3vpn@ietf.org" , "grow@ietf.org" Date: Mon, 24 Oct 2011 17:41:16 -0400 Subject: FW: New Version Notification for draft-gs-vpn-scaling-00.txt Thread-Topic: New Version Notification for draft-gs-vpn-scaling-00.txt Thread-Index: AcySkr43m50IR3XdTz+JCMViALls4AAAbWGw Message-ID: 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 Cc: Rob Shakir X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:41:15 -0000 SGktDQoNClJvYiBTaGFraXIgYW5kIEkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gYSBkcmFmdCB0aGF0 IGRpc2N1c3NlcyBzb21lIHNjYWxpbmcgY29uc2lkZXJhdGlvbnMgZm9yIEwzVlBOIG5ldHdvcmtz LiBXZSBwb3N0ZWQgdGhpcyB0b2RheSBpbiBvcmRlciB0byBtZWV0IHRoZSAwMCBkZWFkbGluZSwg YnV0IGl0J3Mgc3RpbGwgbW9zdCBkZWZpbml0ZWx5IGEgd29yayBpbiBwcm9ncmVzcywgYW5kIHdl IGFyZSBub3QgbmVjZXNzYXJpbHkgbG9va2luZyB0byBwcmVzZW50IGl0IGF0IFRhaXBlaSB1bmxl c3MgdGhlcmUgaXMgZGVmaW5pdGUgaW50ZXJlc3QgZnJvbSB0aGUgZ3JvdXAgaW4gaGF2aW5nIGF0 IGxlYXN0IGFuIGluaXRpYWwgRjJGIGRpc2N1c3Npb24uDQpXZSB3ZXJlIG1haW5seSBqdXN0IGxv b2tpbmcgZm9yIHNvbWUgaW5pdGlhbCBmZWVkYmFjayBvbiB3aGV0aGVyIHRoaXMgaXMgd29yayB0 aGUgZ3JvdXAgdGhpbmtzIHdvdWxkIGJlIHVzZWZ1bCwgc2luY2Ugd2Ugd2VyZW4ndCBjZXJ0YWlu IGV4YWN0bHkgd2hlcmUgc29tZXRoaW5nIGxpa2UgdGhpcyBmaXRzLiBMM1ZQTiBzZWVtcyBsb2dp Y2FsIGdpdmVuIHRoZSBzdWJqZWN0IG1hdHRlciwgYnV0IG9mdGVuIHNjYWxpbmcgY29uc2lkZXJh dGlvbnMgd2l0aCBhbiBvcGVyYXRpb25hbCBmb2N1cyBsaWtlIHRoaXMgZW5kIHVwIGluIEdST1cu IEJ1dCwgR1JPVyBmb2N1c2VzIG9uIGludGVybmV0IHJvdXRpbmcgYW5kIHRoZXJlZm9yZSBtaWdo dCBub3QgYmUgYSBnb29kIGZpdCBvdGhlciB0aGFuIGJlaW5nIGEgcGxhY2Ugd2hlcmUgZm9sa3Mg d2l0aCBpZGVhcyB0aGF0IG1pZ2h0IGJlIGhlbHBmdWwgdG8gdGhpcyBkcmFmdCB0ZW5kIHRvIGhh bmcgb3V0LCBoZW5jZSB0aGUgY3Jvc3MtcG9zdC4NCg0KV2UncmUgYWxzbyBsb29raW5nIGZvciBm b2xrcyB3aWxsaW5nIHRvIGhlbHAgdXMgZmxlc2ggb3V0IHNvbWUgb2YgdGhlIHNlY3Rpb25zIHRo YXQgYXJlIHN0aWxsIG1pc3NpbmcgaW5mbywgZXNwZWNpYWxseSBhcyBmYXIgYXMgbXVsdGljYXN0 IGlzIGNvbmNlcm5lZCwgZ2l2ZSB1cyBvdGhlciBzdWdnZXN0aW9ucy4gUGxlYXNlIGhhdmUgYSBs b29rLg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ncy12cG4tc2NhbGluZy0w MA0KDQpUaGFua3MsDQoNCldlcyBHZW9yZ2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNCwgMjAxMSA1OjIwIFBNDQpUbzogR2Vv cmdlLCBXZXMNCkNjOiByanNAY3cubmV0OyBHZW9yZ2UsIFdlcw0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ncy12cG4tc2NhbGluZy0wMC50eHQNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdzLXZwbi1zY2FsaW5nLTAwLnR4dCBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlc2xleSBHZW9yZ2UgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgIGRyYWZ0LWdzLXZwbi1zY2FsaW5nDQpS ZXZpc2lvbjogICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgIElQIFZQTiBTY2FsaW5nIENvbnNp ZGVyYXRpb25zDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTEtMTAtMjQNCldHIElEOiAgICAgICAgICAg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIwDQoNCkFic3RyYWN0Og0K ICAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgc2NhbGluZyBjb25zaWRlcmF0aW9ucyB1bmlxdWUg dG8NCiAgIGltcGxlbWVudGF0aW9uIG9mIExheWVyIDMgKElQKSBWaXJ0dWFsIFByaXZhdGUgTmV0 d29ya3MsIGRpc2N1c3NlcyBhDQogICBmZXcgYmVzdCBwcmFjdGljZXMsIGFuZCBpZGVudGlmaWVz IGdhcHMgaW4gdGhlIGN1cnJlbnQgdG9vbHMgYW5kDQogICB0ZWNobmlxdWVzIHdoaWNoIGFyZSBt YWtpbmcgaXQgbW9yZSBkaWZmaWN1bHQgZm9yIG9wZXJhdG9ycyB0byBjb3N0LQ0KICAgZWZmZWN0 aXZlbHkgc2NhbGUgYW5kIG1hbmFnZSB0aGVpciBMM1ZQTiBkZXBsb3ltZW50cy4NCg0KDQoNCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5 cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo aWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2Vt aW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRp b24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9m IHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From vumip1@gmail.com Mon Oct 24 15:51:41 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF76421F8B47; Mon, 24 Oct 2011 15:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 Tyg0IIDAs-e2; Mon, 24 Oct 2011 15:51:40 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4F421F8B46; Mon, 24 Oct 2011 15:51:38 -0700 (PDT) Received: by gyh20 with SMTP id 20so7545127gyh.31 for ; Mon, 24 Oct 2011 15:51:38 -0700 (PDT) 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=0SCoGwv8JROI9x+nhOVkuvRFAw3W01fTvjLN/C+Su5k=; b=OqbYQydvtRgc9InejVqmmLqJjeon6BIdUJ9M/kOBVPNLh4fsZZ6fTelu2boqQT3kcu 7P4hB+HX/uwIvgAtadJ39UVZ92+m+jS1SA9Lca3RadkUwAOu2NYJgvFQEDfq4fpnhg6G kZIEvaDARiCQNrSaWTdtmH9lABXSkgt68oXWI= MIME-Version: 1.0 Received: by 10.182.13.1 with SMTP id d1mr3768025obc.74.1319496698001; Mon, 24 Oct 2011 15:51:38 -0700 (PDT) Received: by 10.182.37.69 with HTTP; Mon, 24 Oct 2011 15:51:37 -0700 (PDT) Date: Mon, 24 Oct 2011 18:51:37 -0400 Message-ID: Subject: Fwd: L3VPN automatical interconnection for VPN4DC From: Bhumip Khasnabish To: opsawg@ietf.org, l3vpn@ietf.org Content-Type: multipart/alternative; boundary=f46d044402f0f777ad04b0134311 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 22:51:41 -0000 --f46d044402f0f777ad04b0134311 Content-Type: text/plain; charset=ISO-8859-1 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : L3VPN automatical interconnection for VPN4DC Author(s) : Lizhong Jin Ning So Bhumip Khasnabish Bo Wu Filename : draft-jin-l3vpn-vpn4dc-interconnect-00.txt Pages : 7 Date : 2011-10-24 VPN4DC provides VPN oriented datacenter service to customer through L3VPN which is consisted of (private) L3VPN in datacenter and network provider's L3VPN over wide geographical area. If we considering the two L3VPN in two different AS, [RFC4364] providers three options to achieve L3VPN inter-AS connection. Both option A and B could be used to connect L3VPN in VPN4DC. This draft discusses a novel method for implementing option A, to automatically configure the VRF interface in order to interconnect the two segments of the end-to-end L3VPN. This L3VPN interconnection automation mechanism is expected to significantly reduce the VPN oriented inter-connection/service provisioning time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt --f46d044402f0f777ad04b0134311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : L3VPN automatical interco= nnection for VPN4DC
Author(s)=A0=A0=A0=A0=A0=A0 : Lizhong Jin
=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 Ning = So
=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= Bhumip Khasnabish
=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 Bo Wu
Filename=A0=A0=A0=A0=A0=A0=A0 : draft-jin= -l3vpn-vpn4dc-interconnect-00.txt
Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : = 7
Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-10-24

=A0=A0 VPN4D= C provides VPN oriented datacenter service to customer through
=A0=A0 L3VPN which is consisted of (private) L3VPN in datacenter and networ= k
=A0=A0 provider&#39;s L3VPN over wide geographical area.=A0 If we = considering the
=A0=A0 two L3VPN in two different AS, [RFC4364] provider= s three options to
=A0=A0 achieve L3VPN inter-AS connection.=A0 Both option A and B could be u= sed
=A0=A0 to connect L3VPN in VPN4DC.=A0 This draft discusses a novel m= ethod for
=A0=A0 implementing option A, to automatically configure the V= RF interface
=A0=A0 in order to interconnect the two segments of the end-to-end L3VPN.=A0=A0 This L3VPN interconnection automation mechanism is expected to
= =A0=A0 significantly reduce the VPN oriented inter-connection/service
= =A0=A0 provisioning time.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-= 00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/int= ernet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-jin-l3vp= n-vpn4dc-interconnect-00.txt

--f46d044402f0f777ad04b0134311-- From ben@niven-jenkins.co.uk Mon Oct 24 16:35:16 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F7311E80A4 for ; Mon, 24 Oct 2011 16:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, 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 aAzbbN3pxgJW for ; Mon, 24 Oct 2011 16:35:16 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 41E9B11E81E2 for ; Mon, 24 Oct 2011 16:35:16 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RIU31-0007mP-1U for l3vpn@ietf.org; Tue, 25 Oct 2011 00:35:15 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Discussion of VPN4DC drafts Date: Tue, 25 Oct 2011 00:35:14 +0100 Message-Id: To: L3VPN WG mailing list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 23:35:17 -0000 Colleagues, A number of drafts related to the VPN4DC topic are now available in the = Internet-Draft repository. The ones I could fine are listed below. When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was = conditional on the basis that: 1) There needed to be viable -00 drafts before the cutoff. 2) The problem needed to be discussed prior to Taipei on the L3VPN list. To date there has not been much discussion of VPN4DC on the L3VPN list, = possibly because folks were waiting for -00 drafts to be published. Now that a number of drafts have been published I would encourage those = folks interested in the VPN4DC topic to discuss the various drafts on = the L3VPN list otherwise you risk having the VPN4DC/L3VPN session in = Taipei cancelled. The VPN4DC related drafts that I could find (there may be others that = I've missed) are: VPN4DC Problem Statement http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 VPN4DC Problem Statement http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 L3VPN automatical interconnection for VPN4DC http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 Requirements of Layer 3 Virtual Private Network for Data Centers http://tools.ietf.org/html/draft-so-vpn4dc-00 L3VPN Protocol Gap Analysis for Data Centers http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 Experiment of Example Solution for VPN4DC http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 End-system support for BGP-signaled IP/VPNs. http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Problem Statement for Dynamic Secure Interconnect http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 Ben From ccie15672@yahoo.com Mon Oct 24 17:12:46 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C535F11E80D3 for ; Mon, 24 Oct 2011 17:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 SU-LGyQkQd8J for ; Mon, 24 Oct 2011 17:12:45 -0700 (PDT) Received: from nm40-vm6.bullet.mail.bf1.yahoo.com (nm40-vm6.bullet.mail.bf1.yahoo.com [72.30.239.214]) by ietfa.amsl.com (Postfix) with SMTP id CC59011E80CC for ; Mon, 24 Oct 2011 17:12:43 -0700 (PDT) Received: from [98.139.212.148] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 25 Oct 2011 00:12:39 -0000 Received: from [98.139.212.222] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 25 Oct 2011 00:12:39 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 25 Oct 2011 00:12:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 940484.73806.bm@omp1031.mail.bf1.yahoo.com Received: (qmail 89118 invoked by uid 60001); 25 Oct 2011 00:12:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1319501559; bh=EzhzI1vHJGZuEZclm4v8r3sVkX7FAxegIbbeMS3pOPE=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IxqrR4mYcwXElszZ/2TQIrd9RuTqtjBI1q73NgEbRIOhDLBCm5WDUSoci7feJTHlHeqDU0wqNzCsppat245vjXqlJCeS0dNFbcnCgX+rtDB/NazsuGosF8r0+uYgVsQ8bwnXvzpNrEZBPLBMjaK0/KNO8m7TMxZr1wrXbAezo/E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=t0Qe8xa3G0LLPTwv9RYv0ov3lWFHaBx4QuSwN1OHpGQpLUHHxjqgBMblEeIrysXHi+6p1wJwbkhvDexOvVUv6N6Ya1IHlJGSyXmapefx3P+6XqQvGL1fXqUJT6qEPp9TUX2vWoGWUVFvmxz30ZPHzH+LFNFokrooeSZM3UhcP7E=; X-YMail-OSG: Jp66AY0VM1kxL23iKazuOQ3ZeTw9dWqsc6ZE_hc5sqIm2F2 fxdA9tti1Bfi12Qp0D5Gnj13zlft85kRSRHnw0qFltUimN4X3NdDLofhqBXJ tUaFdp35Scb9gJIeg877pckXM99e3SEYFufjXs7vdU0_gfhubz7zF4_kVDx0 wOGWb2mSHd4WPQZyzZBIy9rdUequBL1H3CkSWx54G11XnS7Pa0Yr4N6xpMuU lmyaft7W7R_DZFj.xB2HBTyILNHAJGWlSaxefQluzrWNMJlu5YliEIbvBAAU vevzqcMCA0Ha7kGIFF1gssUvkMauT601uSnUKUoJxJiyBnnbQqrJ5UM5umZI IGdBX3YJMD3zDMe2C5A.OqN4UE8KG.HFMXSgkETXzlx143WfiiZIz2Tqwcu3 zsN1J90aqLcCYG8umZWrqqU5gO9nDb3Gp3nZwVkThxmMVue4Ru9ReWOy2Co6 K Received: from [76.194.43.66] by web161802.mail.bf1.yahoo.com via HTTP; Mon, 24 Oct 2011 17:12:39 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: Message-ID: <1319501559.87264.YahooMailNeo@web161802.mail.bf1.yahoo.com> Date: Mon, 24 Oct 2011 17:12:39 -0700 (PDT) From: Derick Winkworth Subject: Re: Discussion of VPN4DC drafts To: Ben Niven-Jenkins , L3VPN WG mailing list In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2096837515-1044803524-1319501559=:87264" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Derick Winkworth List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 00:12:46 -0000 ---2096837515-1044803524-1319501559=:87264 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All:=0A=0AI think the drafts constitute a great start to addressing this ga= p. =A0=0A=0AMy first, perhaps superficial, observation is that much of the = language is geared towards "Service-Provider." =A0I think in the context of= VPNs for Data Centers, these drafts apply equally to multi-security zone D= ata Centers in non-SP networks that have multiple logically isolated networ= k segments. =A0For instance, multiple DMZs, server farms, storage networks,= corporate LANs, guest LANs, etc. =A0These could very well all be L3VPNs in= an MPLS infrastructure that interconnects and extends into the various dat= a centers of an enterprise network. =A0The kind of security and transparenc= y that the infrastructure provides is adequate for the purpose of passing a= udits (where the alternative must be physical separation of network resourc= es). =A0There is certainly more enterprise adoption of MPLS happening in th= e field today for this purpose.=0A=0AAnother applicable type of environment= are "-service-providers" that provide various IP enabled applicatio= ns and services to the private networks of external customers. =A0These env= ironments are not classic service-providers because they do not own transpo= rt networks. =A0They connect to multiple carriers to have reachability to a= s many potential customers' private networks as possible. In this case they= are extending customer's private networks into their data centers in a sec= ure/transparent way, similar to the description in some of the drafts for V= PN4DC.=0A=0AI think it might be possible to generalize VPN4DC so that its i= nclusive of these situations. To be clear, these scenarios involve companie= s who are not classic "service-providers" but are running their own MPLS ne= twork with P and PE nodes and not just buying L3VPN sevices from an externa= l provider. =A0Rather than framing everything in a "service-provider" or "e= nterprise" context, we could just frame it in general networking terms. =A0= =0A=0AI think there is a sort of Hegelian synthesis happening in the indust= ry between service-provider and enterprise, and VPN4DC is a clear bridge be= tween them.=0A=0AThanks.=0A=0ADerick=0A=0A=0A______________________________= __=0AFrom: Ben Niven-Jenkins =0ATo: L3VPN WG maili= ng list =0ASent: Monday, October 24, 2011 6:35 PM=0ASubject= : Discussion of VPN4DC drafts =0A=0AColleagues,=0A=0AA number of drafts rel= ated to the VPN4DC topic are now available in the Internet-Draft repository= . The ones I could fine are listed below.=0A=0AWhen the L3VPN session in Ta= ipei was scheduled to discuss VPN4DC it was conditional on the basis that:= =0A=0A1) There needed to be viable -00 drafts before the cutoff.=0A2) The p= roblem needed to be discussed prior to Taipei on the L3VPN list.=0A=0ATo da= te there has not been much discussion of VPN4DC on the L3VPN list, possibly= because folks were waiting for -00 drafts to be published.=0A=0ANow that a= number of drafts have been published I would encourage those folks interes= ted in the VPN4DC topic to discuss the various drafts on the L3VPN list oth= erwise you risk having the VPN4DC/L3VPN session in Taipei cancelled.=0A=0AT= he VPN4DC related drafts that I could find (there may be others that I've m= issed) are:=0A=0AVPN4DC Problem Statement=0Ahttp://tools.ietf.org/html/draf= t-dunbar-vpn4dc-problem-statement-00=0A=0AVPN4DC Problem Statement=0Ahttp:/= /tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00=0A=0AL3VPN auto= matical interconnection for VPN4DC=0Ahttp://tools.ietf.org/html/draft-jin-l= 3vpn-vpn4dc-interconnect-00=0A=0ARequirements of Layer 3 Virtual Private Ne= twork for Data Centers=0Ahttp://tools.ietf.org/html/draft-so-vpn4dc-00=0A= =0AL3VPN Protocol Gap Analysis for Data Centers=0Ahttp://tools.ietf.org/htm= l/draft-yong-vpn4dc-protocol-gap-analysis-00=0A=0AExperiment of Example Sol= ution for VPN4DC=0Ahttp://tools.ietf.org/html/draft-zeng-vpn4dc-example-sol= ution-00=0A=0AEnd-system support for BGP-signaled IP/VPNs.=0Ahttp://tools.i= etf.org/html/draft-marques-l3vpn-end-system-02=0A=0AProblem Statement for D= ynamic Secure Interconnect=0Ahttp://tools.ietf.org/html/draft-ko-dsi-proble= m-statement-00=0A=0ABen ---2096837515-1044803524-1319501559=:87264 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All:

I think the draft= s constitute a great start to addressing this gap.  
=
My first, perhaps superficial, observatio= n is that much of the language is geared towards "Service-Provider."  = I think in the context of VPNs for Data Centers, these drafts apply equally= to multi-security zone Data Centers in non-SP networks that have multiple = logically isolated network segments.  For instance, multiple DMZs, ser= ver farms, storage networks, corporate LANs, guest LANs, etc.  These c= ould very well all be L3VPNs in an MPLS infrastructure that interconnects a= nd extends into the various data centers of an enterprise network.  Th= e kind of security and transparency that the infrastructure provides is adequate for the purpose of passing audits (where the alternative must = be physical separation of network resources).  There is certainly more= enterprise adoption of MPLS happening in the field today for this purpose.=

Another applicable type of en= vironment are "<blank>-service-providers" that provide various IP ena= bled applications and services to the private networks of external customer= s.  These environments are not classic service-providers because they = do not own transport networks.  They connect to multiple carriers to h= ave reachability to as many potential customers' private networks as possib= le. In this case they are extending customer's private networks into their = data centers in a secure/transparent way, similar to the description in som= e of the drafts for VPN4DC.

I t= hink it might be possible to generalize VPN4DC so that its inclusive of these situations. To be clear, these scenarios involve companies who ar= e not classic "service-providers" but are running their own MPLS network wi= th P and PE nodes and not just buying L3VPN sevices from an external provid= er.  Rather than framing everything in a "service-provider" or "enterp= rise" context, we could just frame it in general networking terms.  

I think there is a sort of Hege= lian synthesis happening in the industry between service-provider and enter= prise, and VPN4DC is a clear bridge between them.

Thanks.

Derick

From: Ben Niven-Jenkins <ben@niv= en-jenkins.co.uk>
To: L3VPN WG mailing list <l3vpn@ietf.org>
Sent: Monday, October 24, 2011 6:35 PM
Subject: Discussion of VPN4DC draft= s

=0AColleagues,

A number of drafts related to the VP= N4DC topic are now available in the Internet-Draft repository. The ones I c= ould fine are listed below.

When the L3VPN session in Taipei was sch= eduled to discuss VPN4DC it was conditional on the basis that:

1) Th= ere needed to be viable -00 drafts before the cutoff.
2) The problem nee= ded to be discussed prior to Taipei on the L3VPN list.

To date there= has not been much discussion of VPN4DC on the L3VPN list, possibly because= folks were waiting for -00 drafts to be published.

Now that a numbe= r of drafts have been published I would encourage those folks interested in= the VPN4DC topic to discuss the various drafts on the L3VPN list otherwise= you risk having the VPN4DC/L3VPN session in Taipei cancelled.

The V= PN4DC related drafts that I could find (there may be others that I've misse= d) are:

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statem= ent-00

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-= fang-vpn4dc-problem-statement-00

L3VPN automatical interconnection f= or VPN4DC
http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect= -00

Requirements of Layer 3 Virtual Private Network for Data Centers=
http://tools.ietf.org/html/draft-so-vpn4dc-00

L3VPN Protocol Gap= Analysis for Data Centers
http://tools.ietf.org/html/draft-yong-vpn4dc-= protocol-gap-analysis-00

Experiment of Example Solution for VPN4DChttp://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00

E= nd-system support for BGP-signaled IP/VPNs.
http://tools.ietf.org/html/d= raft-marques-l3vpn-end-system-02

Problem Statement for Dynamic Secur= e Interconnect
http://tools.ietf.org/html/draft-ko-dsi-problem-statement= -00

Ben



---2096837515-1044803524-1319501559=:87264-- From robert@raszuk.net Mon Oct 24 19:07:13 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646DE21F8BDE for ; Mon, 24 Oct 2011 19:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 GmcfphsrEFQ4 for ; Mon, 24 Oct 2011 19:07:12 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 31FB121F8BEC for ; Mon, 24 Oct 2011 19:07:12 -0700 (PDT) Received: (qmail 1000 invoked by uid 399); 25 Oct 2011 02:07:11 -0000 Received: from unknown (HELO ?216.69.69.199?) (216.69.69.199) by mail37.opentransfer.com with SMTP; 25 Oct 2011 02:07:11 -0000 Message-ID: <4EA619CE.80408@raszuk.net> Date: Tue, 25 Oct 2011 04:07:10 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "George, Wes" Subject: Comment reg draft-gs-vpn-scaling-00.txt References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Rob Shakir , "grow@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 02:07:13 -0000 Hi Wes, What a perfect timing ... I very much agree with the scaling aspects of L3VPN service model you have described in the draft. Clearly more hardware is not the answer .. well at least for the operator side - considering that such hardware is not a commodity one especially when our customers continue to expect more for less. The lack of scaling of L3VPNs has been the topic of discussions for some time now among many operation teams of service providers. There are two main concerns that arise - route scaling and platform scaling. My observation is that there are two main issues which are major contributors to the problem: - the aspect of directly attaching a VPN site's CE to service provider PE - the aspect of converting all customer routes to one common VPNv4/v6 container which becomes too heavy to carry around Originally I was personally investigating the idea of at least eliminating the latter by converting the L3VPN model to be more of CSC type (even for regular CE sites which would not run MPLS). However that type of approach still carries the inflexibility issue of directly attachment of sites which while for some sites are just fine, but for others are usually beyond the local reach of the L3VPN SP provider. From that point I and few other colleagues of mine have started to think about completely new way to accomplish L2 or L3VPN services ranging from mobile smartphone as CE to large site as CE. Moreover such VPN service can be provided not essentially by locally present network operator. The name I invented for it is VaaS (VPN-as-a-Service) which especially now could be easily offered as a new type of cloud application. In a nut shell the fundamental problems are solved by removing the requirement to attach customer to any PE box - VaaS control plane server can be accessed by any means of user internet connection. It also completely removes the need to combine VPN site's routing information .. you keep routes of each VPN sites in a separate routing slice - also residing on the control plane server or VM. With dynamic allocation of compute and storage which is becoming a commodity in any modern data center one could easily observe that scaling aspects of such a service model becomes very much shifted from vendor devices to commodity computing and storage managed by intelligent and very dynamic data centers' job distribution tools. Also while this is still very much work in progress I would encourage anyone concerned with today's L3VPN scale to read and provide comments and opinions on the below document. http://www.ietf.org/internet-drafts/draft-ko-vaas-problem-statement-00.txt As a matter of fact I am still adding some framework text reg routing information exchange to this draft this week so perhaps next week (if I manage to find enough time) there would be a -01 version posted. By bringing this to the IETF we are presenting the idea for open contribution by anyone interested both in the architecture space as well as possible open source implementations. Best regards, R. > Hi- > > Rob Shakir and I have been working on a draft that discusses some > scaling considerations for L3VPN networks. We posted this today in > order to meet the 00 deadline, but it's still most definitely a work > in progress, and we are not necessarily looking to present it at > Taipei unless there is definite interest from the group in having at > least an initial F2F discussion. We were mainly just looking for some > initial feedback on whether this is work the group thinks would be > useful, since we weren't certain exactly where something like this > fits. L3VPN seems logical given the subject matter, but often scaling > considerations with an operational focus like this end up in GROW. > But, GROW focuses on internet routing and therefore might not be a > good fit other than being a place where folks with ideas that might > be helpful to this draft tend to hang out, hence the cross-post. > > We're also looking for folks willing to help us flesh out some of the > sections that are still missing info, especially as far as multicast > is concerned, give us other suggestions. Please have a look. > > http://tools.ietf.org/html/draft-gs-vpn-scaling-00 > > Thanks, > > Wes George > > -----Original Message----- From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org] Sent: Monday, October 24, 2011 5:20 > PM To: George, Wes Cc: rjs@cw.net; George, Wes Subject: New Version > Notification for draft-gs-vpn-scaling-00.txt > > A new version of I-D, draft-gs-vpn-scaling-00.txt has been > successfully submitted by Wesley George and posted to the IETF > repository. > > Filename: draft-gs-vpn-scaling Revision: 00 Title: > IP VPN Scaling Considerations Creation date: 2011-10-24 WG ID: > Individual Submission Number of pages: 20 > > Abstract: This document discusses scaling considerations unique to > implementation of Layer 3 (IP) Virtual Private Networks, discusses a > few best practices, and identifies gaps in the current tools and > techniques which are making it more difficult for operators to cost- > effectively scale and manage their L3VPN deployments. > > The IETF Secretariat > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or > subject to copyright belonging to Time Warner Cable. This E-mail is > intended solely for the use of the individual or entity to which it > is addressed. If you are not the intended recipient of this E-mail, > you are hereby notified that any dissemination, distribution, > copying, or action taken in relation to the contents of and > attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. From ning.so@verizon.com Mon Oct 24 20:26:03 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA5221F8A64 for ; Mon, 24 Oct 2011 20:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 p9BSqqpYS+bK for ; Mon, 24 Oct 2011 20:26:02 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9C04721F8A66 for ; Mon, 24 Oct 2011 20:26:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 25 Oct 2011 03:25:59 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.69,402,1315180800"; d="scan'208";a="165824965" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 25 Oct 2011 03:25:59 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.133]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Mon, 24 Oct 2011 23:25:59 -0400 To: "l3vpn@ietf.org" Date: Mon, 24 Oct 2011 23:25:58 -0400 Subject: RE: Discussion of VPN4DC drafts Thread-Topic: Discussion of VPN4DC drafts Thread-Index: AcySxcQSxR2YoRpjTn6NOravyH7yeg== Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08F71ED49@FHDP1LUMXC7V41.us.one.verizon.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-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 03:26:03 -0000 Ben, Thanks putting together the list of drafts. As you can see from the work p= roduced in this area, a lot of people have been working hard to meet the de= adline. I know at least one more draft that is also related to VPN4DC ( h= ttps://datatracker.ietf.org/doc/draft-mcdysan-sdnp-cloudbursting-usecase/).= Dave asked for presentation slot for SDN BoF. He has also talked with Lu= yuan and myself about discussing it in VPN4DC barBoF, as well as L3VPN if t= ime permits. I am also in the process of updating -02 version of Requirem= ent for VPN-oriented Data Center Services with additional input collected r= ecently. That is the original draft that started VPN4DC work. =20 There has been some very good discussions on the scope of VPN4DC. The cur= rent scope is limited to host-to-host connectivity through L3VPN network. = This scope clearly fits the IETF way of doing things. It is very small, ta= ngible, and achievable. However, there are a whole new set of protocol wor= k needs to be done in order to allow services to be built on top of the hos= t-to-host connection. We might want to have some time during the meeting t= o discuss the going forward scope of work. =20 =20 =A0 Best regards, =A0 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =A0 Date: Tue, 25 Oct 2011 00:35:14 +0100 From: Ben Niven-Jenkins To: L3VPN WG mailing list Subject: Discussion of VPN4DC drafts Message-ID: Content-Type: text/plain; charset=3Dus-ascii Colleagues, A number of drafts related to the VPN4DC topic are now available in the Int= ernet-Draft repository. The ones I could fine are listed below. When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was con= ditional on the basis that: 1) There needed to be viable -00 drafts before the cutoff. 2) The problem needed to be discussed prior to Taipei on the L3VPN list. To date there has not been much discussion of VPN4DC on the L3VPN list, pos= sibly because folks were waiting for -00 drafts to be published. Now that a number of drafts have been published I would encourage those fol= ks interested in the VPN4DC topic to discuss the various drafts on the L3VP= N list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancell= ed. The VPN4DC related drafts that I could find (there may be others that I've = missed) are: VPN4DC Problem Statement http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 VPN4DC Problem Statement http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 L3VPN automatical interconnection for VPN4DC http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 Requirements of Layer 3 Virtual Private Network for Data Centers http://tools.ietf.org/html/draft-so-vpn4dc-00 L3VPN Protocol Gap Analysis for Data Centers http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 Experiment of Example Solution for VPN4DC http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 End-system support for BGP-signaled IP/VPNs. http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Problem Statement for Dynamic Secure Interconnect http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 Ben From ning.so@verizon.com Mon Oct 24 20:50:44 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74FB11E80E7 for ; Mon, 24 Oct 2011 20:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 lpU8NNaQDLn1 for ; Mon, 24 Oct 2011 20:50:44 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4D24811E80D5 for ; Mon, 24 Oct 2011 20:50:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe03.verizon.com with ESMTP; 25 Oct 2011 03:50:42 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.69,402,1315180800"; d="scan'208";a="165848904" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 25 Oct 2011 03:50:41 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.133]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Mon, 24 Oct 2011 23:50:41 -0400 To: "l3vpn@ietf.org" Date: Mon, 24 Oct 2011 23:50:40 -0400 Subject: RE: Re: Discussion of VPN4DC drafts Thread-Topic: Re: Discussion of VPN4DC drafts Thread-Index: AcySyGboZf66CAXiSBqVt90pgpM+mg== Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08F71ED4F@FHDP1LUMXC7V41.us.one.verizon.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-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 03:50:44 -0000 Derick, Please see my comments in-line. =A0 Best regards, =A0 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =A0 Date: Mon, 24 Oct 2011 17:12:39 -0700 (PDT) From: Derick Winkworth To: Ben Niven-Jenkins , L3VPN WG mailing list Subject: Re: Discussion of VPN4DC drafts Message-ID: <1319501559.87264.YahooMailNeo@web161802.mail.bf1.yahoo.com> Content-Type: text/plain; charset=3D"iso-8859-1" All: I think the drafts constitute a great start to addressing this gap. ? My first, perhaps superficial, observation is that much of the language is = geared towards "Service-Provider." ?I think in the context of VPNs for Data= Centers, these drafts apply equally to multi-security zone Data Centers in= non-SP networks that have multiple logically isolated network segments. ?F= or instance, multiple DMZs, server farms, storage networks, corporate LANs,= guest LANs, etc. ?These could very well all be L3VPNs in an MPLS infrastru= cture that interconnects and extends into the various data centers of an en= terprise network. ?The kind of security and transparency that the infrastru= cture provides is adequate for the purpose of passing audits (where the alt= ernative must be physical separation of network resources). ?There is certa= inly more enterprise adoption of MPLS happening in the field today for this= purpose. [Ning] Agree. Another applicable type of environment are "-service-providers" that= provide various IP enabled applications and services to the private networ= ks of external customers. ?These environments are not classic service-provi= ders because they do not own transport networks. ?They connect to multiple = carriers to have reachability to as many potential customers' private netwo= rks as possible. In this case they are extending customer's private network= s into their data centers in a secure/transparent way, similar to the descr= iption in some of the drafts for VPN4DC. [Ning] Can you gave an example to help me understand it better? I think it might be possible to generalize VPN4DC so that its inclusive of = these situations. To be clear, these scenarios involve companies who are no= t classic "service-providers" but are running their own MPLS network with P= and PE nodes and not just buying L3VPN sevices from an external provider. = ?Rather than framing everything in a "service-provider" or "enterprise" con= text, we could just frame it in general networking terms. ? [Ning] Service provider and Enterprise are meant to be generic terms, and I= agree with you that they are not good terms to fit the situation you are d= escribing. I can certainly go back to make the term more generalized (or a= t least clearly defined in definition section).=20 I think there is a sort of Hegelian synthesis happening in the industry bet= ween service-provider and enterprise, and VPN4DC is a clear bridge between = them. [Ning] Agree. =20 Thanks. Derick ________________________________ From: Ben Niven-Jenkins To: L3VPN WG mailing list Sent: Monday, October 24, 2011 6:35 PM Subject: Discussion of VPN4DC drafts=20 Colleagues, A number of drafts related to the VPN4DC topic are now available in the Int= ernet-Draft repository. The ones I could fine are listed below. When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was con= ditional on the basis that: 1) There needed to be viable -00 drafts before the cutoff. 2) The problem needed to be discussed prior to Taipei on the L3VPN list. To date there has not been much discussion of VPN4DC on the L3VPN list, pos= sibly because folks were waiting for -00 drafts to be published. Now that a number of drafts have been published I would encourage those fol= ks interested in the VPN4DC topic to discuss the various drafts on the L3VP= N list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancell= ed. The VPN4DC related drafts that I could find (there may be others that I've = missed) are: VPN4DC Problem Statement http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 VPN4DC Problem Statement http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 L3VPN automatical interconnection for VPN4DC http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 Requirements of Layer 3 Virtual Private Network for Data Centers http://tools.ietf.org/html/draft-so-vpn4dc-00 L3VPN Protocol Gap Analysis for Data Centers http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 Experiment of Example Solution for VPN4DC http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 End-system support for BGP-signaled IP/VPNs. http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Problem Statement for Dynamic Secure Interconnect http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael@huaweisymantec.com Mon Oct 24 21:28:45 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E06D11E80BC for ; Mon, 24 Oct 2011 21:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 eHd7dmn9SL2n for ; Mon, 24 Oct 2011 21:28:44 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2C34711E8097 for ; Mon, 24 Oct 2011 21:28:44 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_o8NFgQSSV6JKz/iiNCOsVA)" Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LTL00GH9TRQAGA0@hstga01-in.huaweisymantec.com> for l3vpn@ietf.org; Tue, 25 Oct 2011 12:28:38 +0800 (CST) Received: from m90003900a ([10.47.137.175]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LTL000YMTRIYF20@hstml02-in.huaweisymantec.com> for l3vpn@ietf.org; Tue, 25 Oct 2011 12:28:38 +0800 (CST) Message-id: <69A10181857544B88BF33AB1F5262DF2@china.huawei.com> From: Michael Ko To: Ben Niven-Jenkins , L3VPN WG mailing list References: Subject: Re: Discussion of VPN4DC drafts Date: Mon, 24 Oct 2011 21:28:30 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 04:28:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_o8NFgQSSV6JKz/iiNCOsVA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT I haver renamed "Dynamic Secure Interconnect" to "VPN As A Service" to better define its scope and have resubmitted the draft as "Problem Statement for VPN As A Service". Here is a link to the draft: http://www.ietf.org/internet-drafts/draft-ko-vaas-problem-statement-00.txt Mike ----- Original Message ----- From: Ben Niven-Jenkins To: L3VPN WG mailing list Sent: Monday, October 24, 2011 4:35 PM Subject: Discussion of VPN4DC drafts Colleagues, A number of drafts related to the VPN4DC topic are now available in the Internet-Draft repository. The ones I could fine are listed below. When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was conditional on the basis that: 1) There needed to be viable -00 drafts before the cutoff. 2) The problem needed to be discussed prior to Taipei on the L3VPN list. To date there has not been much discussion of VPN4DC on the L3VPN list, possibly because folks were waiting for -00 drafts to be published. Now that a number of drafts have been published I would encourage those folks interested in the VPN4DC topic to discuss the various drafts on the L3VPN list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancelled. The VPN4DC related drafts that I could find (there may be others that I've missed) are: VPN4DC Problem Statement http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 VPN4DC Problem Statement http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 L3VPN automatical interconnection for VPN4DC http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 Requirements of Layer 3 Virtual Private Network for Data Centers http://tools.ietf.org/html/draft-so-vpn4dc-00 L3VPN Protocol Gap Analysis for Data Centers http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 Experiment of Example Solution for VPN4DC http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 End-system support for BGP-signaled IP/VPNs. http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Problem Statement for Dynamic Secure Interconnect http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 Ben --Boundary_(ID_o8NFgQSSV6JKz/iiNCOsVA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
I haver renamed "Dynamic Secure Interconnect" to "VPN As A Service" to better define its scope and have resubmitted the draft as "Problem Statement for VPN As A Service".  Here is a link to the draft: http://www.ietf.org/internet-drafts/draft-ko-vaas-problem-statement-00.txt
 
Mike
----- Original Message -----
Sent: Monday, October 24, 2011 4:35 PM
Subject: Discussion of VPN4DC drafts

Colleagues,

A number of drafts related to the VPN4DC topic are now available in the Internet-Draft repository. The ones I could fine are listed below.

When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was conditional on the basis that:

1) There needed to be viable -00 drafts before the cutoff.
2) The problem needed to be discussed prior to Taipei on the L3VPN list.

To date there has not been much discussion of VPN4DC on the L3VPN list, possibly because folks were waiting for -00 drafts to be published.

Now that a number of drafts have been published I would encourage those folks interested in the VPN4DC topic to discuss the various drafts on the L3VPN list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancelled.

The VPN4DC related drafts that I could find (there may be others that I've missed) are:

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00

L3VPN automatical interconnection for VPN4DC
http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00

Requirements of Layer 3 Virtual Private Network for Data Centers
http://tools.ietf.org/html/draft-so-vpn4dc-00

L3VPN Protocol Gap Analysis for Data Centers
http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00

Experiment of Example Solution for VPN4DC
http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00

End-system support for BGP-signaled IP/VPNs.
http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02

Problem Statement for Dynamic Secure Interconnect
http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00

Ben

--Boundary_(ID_o8NFgQSSV6JKz/iiNCOsVA)-- From ccie15672@yahoo.com Mon Oct 24 21:45:54 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE76521F8783 for ; Mon, 24 Oct 2011 21:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 EvACCbCHQfFt for ; Mon, 24 Oct 2011 21:45:52 -0700 (PDT) Received: from nm31-vm6.bullet.mail.bf1.yahoo.com (nm31-vm6.bullet.mail.bf1.yahoo.com [72.30.239.14]) by ietfa.amsl.com (Postfix) with SMTP id 844F821F8B2F for ; Mon, 24 Oct 2011 21:45:51 -0700 (PDT) Received: from [98.139.215.140] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 25 Oct 2011 04:45:45 -0000 Received: from [98.139.212.249] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 25 Oct 2011 04:45:45 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 25 Oct 2011 04:45:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 770737.67958.bm@omp1058.mail.bf1.yahoo.com Received: (qmail 99951 invoked by uid 60001); 25 Oct 2011 04:45:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1319517945; bh=S9yvbG9iGQefCWR5afZvgTqUj71rT1MzLnvT3+i3fqE=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=3SuxWKInLsFFIqjekToqDm5nZlIZT1eTNp58NPqSxMUz07s8M/pRUIsjOtLGvOS6UBWZO6ybn95s6UhI8QUr6szfM5exM8l+HlBvsF6HdcQ6DVKFPyFcrMSZQell+ug4LTHg9PwwqppTbdrMMDi8qpxUy8elCdvh8q3LnEFRQOE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Qrg19gfZHZFUZ6JPJ/aGz9/Cst4yp8CWwIhF53mupXFX+hrtQazxzA42IdCnq1ddrT99CIqYZep1+0C1Lu0hZU0DOErzuWZTDddtxMhJZXTm1AAsBm6ygex0r/jIZtGWIKLpUvU+Ak6R3XrTxTL7WyRn/ZdEDHytjvZPdtppU8E=; X-YMail-OSG: J.TJLN0VM1nOg6bsC_PRTIsbRdqitGUzfOjktcSm4Nnq5xB e0qBwpGhiOrWVkCn0X6jz587ePQ9eqrHBoctDhYtrzDsdMjlwWU4LRxelMw7 VGqpwl_6J2wpk.S1R8x8OiEvjaxZthPpCwvx0R6xPtqjrUBWPz1SzJHP4bqq Wn4umYc_99euFjFqYJNldXKcrENPzmFVFUctyFKdRtIj.jgA.r7i1nu01imq E.2VcuvAK44uyn1KLLi3uMTVj7zA9OiPhkELPBaPNLkpomDUbh3QicsxPljM EXpA8IikZ_FfLsURNzoKWyU88h6GM3ord1L8VfbTUikIUgxV98g.pEY3G3jS o8sKvcyvLKx1J0oV48EnNmgF39Ksl_gw9xmGHtKStRJMoljHi_WeSHaHdPGM dsGjMTiHGJVaTbeidiXFBZmWHPpTnS7NAlbv6o4xyrO.tSQLc3EKPkSxlO64 KlSvY5lqBjeCfCWcS6Sc6k6ARK1.RYFHpa891_dZnzkcI86wkh4iWuSsBZFi la4MDrfLqUd8N_Xt4CQYsdmrbwK1E_i.UofY9WVlOGl.ZlYpheqT_8mkOKN8 1LFLKvOKrDDCCWBFNIksHqA-- Received: from [76.194.43.66] by web161805.mail.bf1.yahoo.com via HTTP; Mon, 24 Oct 2011 21:45:45 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <6665BC1FEA04AB47B1F75FA641C43BC08F71ED4F@FHDP1LUMXC7V41.us.one.verizon.com> Message-ID: <1319517945.99929.YahooMailNeo@web161805.mail.bf1.yahoo.com> Date: Mon, 24 Oct 2011 21:45:45 -0700 (PDT) From: Derick Winkworth Subject: Re: Re: Discussion of VPN4DC drafts To: "l3vpn@ietf.org" In-Reply-To: <6665BC1FEA04AB47B1F75FA641C43BC08F71ED4F@FHDP1LUMXC7V41.us.one.verizon.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-337026386-1841433737-1319517945=:99929" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Derick Winkworth List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 04:45:54 -0000 ---337026386-1841433737-1319517945=:99929 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ning:=0A=0A-----=0AAnother applicable type of environment are "-serv= ice-providers"...=0A=0A[Ning] Can you gave an example to help me understand= it better?=0A=0A-----=0A=0A=0AFor instance, there are SIP/VoIP providers w= ho do not own a regional or nation-wide MPLS transport network used primari= ly as revenue-generating L3VPN services network (such as Verizon, ATT, etc = have). =A0I have seen in a number of networks where these type of providers= would purchase a DS3 or ethernet circuit from Verizon or ATT and channeliz= e it with PVCs or VLANs. =A0Each PVC or VLAN would correspond to =A0a diffe= rent L3VPN network (i.e., customer) on Verizon or ATT's MPLS network. =A0Th= e SIP/VoIP provider would then use Inter-AS Option A to connect these L3VPN= networks to L3VPN networks they have built for their external customers in= their data center. =A0They are effectively extending these L3VPNs into the= ir datacenter to attach (and customize) services to them. =A0In some cases = customer owned appliances are put "in the path" of the customer's traffic i= n the provider's data center. =A0=0A=0AThere are SIP, Storage, and E-mail p= roviders (all fairly obvious) that I am aware of doing this. =A0Less obviou= s are more specialized services like financial services and applications an= d medical applications and services. =A0Locally here I have run into at lea= st one company delivering video and audio in this fashion for businesses th= at want streaming advertisements on media displays. =A0=0A=0AOf course, in = order to maximize their potential customer base they connect to multiple ca= rriers in this way. =A0=0A=0AThe point though is that this is an example of= a non-transport service-provider attaching VMs and other hosts/appliances/= services ultimately to customer L3VPNs internal to the provider's datacente= r. =A0There is a =A0need for automating the turn up of VPNs (as one of the = VPN4DC drafts describe) on the PEs facing the external transport providers = with which they are running Inter-AS option A, as well as on the PEs facing= the VM hosts or virtualized appliances. =A0Also there is a need for =A0aut= omatically building a VM or a virtual-appliance on the fly for service to t= hat VPN. =A0=0A=0ASorry if this is too verbose or not clear enough. =A0Here= is a partial diagram:=A0http://packetpushers.net/extending-private-network= s-into-your-datacenter/. =A0Now just imagine a PE in the data center with V= Ms attached to it for each of the four VRFs.=0A=0ADerick=0A=0A=0A=0A=0A=0A= =0A=0AFrom: "So, Ning" =0ATo: "l3vpn@ietf.org" =0ASent: Monday, October 24, 2011 10:50 PM=0ASubject: RE: Re: Disc= ussion of VPN4DC drafts=0A=0ADerick,=0A=0APlease see my comments in-line.= =0A=0A=A0=0ABest regards,=0A=A0=0ANing So=0AVerizon Corporate Technology=0A= (office) 972-729-7905=0A(Cell) 972-955-0914=0A=A0=0ADate: Mon, 24 Oct 2011 = 17:12:39 -0700 (PDT)=0AFrom: Derick Winkworth =0ATo: B= en Niven-Jenkins ,=A0=A0=A0 L3VPN WG mailing list= =0A=A0=A0=A0 =0ASubject: Re: Discussion of VPN4DC drafts=0A= Message-ID:=0A=A0=A0=A0 <1319501559.87264.YahooMailNeo@web161802.mail.bf1.y= ahoo.com>=0AContent-Type: text/plain; charset=3D"iso-8859-1"=0A=0AAll:=0A= =0AI think the drafts constitute a great start to addressing this gap. ?=0A= =0AMy first, perhaps superficial, observation is that much of the language = is geared towards "Service-Provider." ?I think in the context of VPNs for D= ata Centers, these drafts apply equally to multi-security zone Data Centers= in non-SP networks that have multiple logically isolated network segments.= ?For instance, multiple DMZs, server farms, storage networks, corporate LA= Ns, guest LANs, etc. ?These could very well all be L3VPNs in an MPLS infras= tructure that interconnects and extends into the various data centers of an= enterprise network. ?The kind of security and transparency that the infras= tructure provides is adequate for the purpose of passing audits (where the = alternative must be physical separation of network resources). ?There is ce= rtainly more enterprise adoption of MPLS happening in the field today for t= his purpose.=0A=0A[Ning] Agree.=0A=0AAnother applicable type of environment= are "-service-providers" that provide various IP enabled applicatio= ns and services to the private networks of external customers. ?These envir= onments are not classic service-providers because they do not own transport= networks. ?They connect to multiple carriers to have reachability to as ma= ny potential customers' private networks as possible. In this case they are= extending customer's private networks into their data centers in a secure/= transparent way, similar to the description in some of the drafts for VPN4D= C.=0A=0A[Ning] Can you gave an example to help me understand it better?=0A= =0AI think it might be possible to generalize VPN4DC so that its inclusive = of these situations. To be clear, these scenarios involve companies who are= not classic "service-providers" but are running their own MPLS network wit= h P and PE nodes and not just buying L3VPN sevices from an external provide= r. ?Rather than framing everything in a "service-provider" or "enterprise" = context, we could just frame it in general networking terms. ?=0A=0A[Ning] = Service provider and Enterprise are meant to be generic terms, and I agree = with you that they are not good terms to fit the situation you are describi= ng.=A0 I can certainly go back to make the term more generalized (or at lea= st clearly defined in definition section). =0A=0AI think there is a sort of= Hegelian synthesis happening in the industry between service-provider and = enterprise, and VPN4DC is a clear bridge between them.=0A=0A[Ning] Agree.= =A0 =0A=0AThanks.=0A=0ADerick=0A=0A=0A________________________________=0AFr= om: Ben Niven-Jenkins =0ATo: L3VPN WG mailing list= =0ASent: Monday, October 24, 2011 6:35 PM=0ASubject: Discu= ssion of VPN4DC drafts =0A=0AColleagues,=0A=0AA number of drafts related to= the VPN4DC topic are now available in the Internet-Draft repository. The o= nes I could fine are listed below.=0A=0AWhen the L3VPN session in Taipei wa= s scheduled to discuss VPN4DC it was conditional on the basis that:=0A=0A1)= There needed to be viable -00 drafts before the cutoff.=0A2) The problem n= eeded to be discussed prior to Taipei on the L3VPN list.=0A=0ATo date there= has not been much discussion of VPN4DC on the L3VPN list, possibly because= folks were waiting for -00 drafts to be published.=0A=0ANow that a number = of drafts have been published I would encourage those folks interested in t= he VPN4DC topic to discuss the various drafts on the L3VPN list otherwise y= ou risk having the VPN4DC/L3VPN session in Taipei cancelled.=0A=0AThe VPN4D= C related drafts that I could find (there may be others that I've missed) a= re:=0A=0AVPN4DC Problem Statement=0Ahttp://tools.ietf.org/html/draft-dunbar= -vpn4dc-problem-statement-00=0A=0AVPN4DC Problem Statement=0Ahttp://tools.i= etf.org/html/draft-fang-vpn4dc-problem-statement-00=0A=0AL3VPN automatical = interconnection for VPN4DC=0Ahttp://tools.ietf.org/html/draft-jin-l3vpn-vpn= 4dc-interconnect-00=0A=0ARequirements of Layer 3 Virtual Private Network fo= r Data Centers=0Ahttp://tools.ietf.org/html/draft-so-vpn4dc-00=0A=0AL3VPN P= rotocol Gap Analysis for Data Centers=0Ahttp://tools.ietf.org/html/draft-yo= ng-vpn4dc-protocol-gap-analysis-00=0A=0AExperiment of Example Solution for = VPN4DC=0Ahttp://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00= =0A=0AEnd-system support for BGP-signaled IP/VPNs.=0Ahttp://tools.ietf.org/= html/draft-marques-l3vpn-end-system-02=0A=0AProblem Statement for Dynamic S= ecure Interconnect=0Ahttp://tools.ietf.org/html/draft-ko-dsi-problem-statem= ent-00=0A=0ABen=0A-------------- next part --------------=0AAn HTML attachm= ent was scrubbed...=0AURL: ---337026386-1841433737-1319517945=:99929 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Ning:

-----
Another appli= cable type of environment are "<blank>-service-providers"...

[= Ning] Can you gave an example to help me understand it better?
-----

For instance, there are SIP/= VoIP providers who do not own a regional or nation-wide MPLS transport netw= ork used primarily as revenue-generating L3VPN services network (such as Ve= rizon, ATT, etc have).  I have seen in a number of networks where thes= e type of providers would purchase a DS3 or ethernet circuit from Verizon o= r ATT and channelize it with PVCs or VLANs.  Each PVC or VLAN would co= rrespond to  a different L3VPN network (i.e., customer) on Verizon or = ATT's MPLS network.  The SIP/VoIP provider would then use Inter-AS Opt= ion A to connect these L3VPN networks to L3VPN networks they have built for= their external customers in their data center.  They are effectively = extending these L3VPNs into their datacenter to attach (and customize) services to t= hem.  In some cases customer owned appliances are put "in the path" of= the customer's traffic in the provider's data center.  
<= div class=3D"yui_3_2_0_16_131951353975457">
There are SIP, Storage, and E-= mail providers (all fairly obvious) that I am aware of doing this.  Le= ss obvious are more specialized services like financial services and applic= ations and medical applications and services.  Locally here I have run= into at least one company delivering video and audio in this fashion for b= usinesses that want streaming advertisements on media displays.  

Of course, in order to maximiz= e their potential customer base they connect to multiple carriers in this w= ay.  
<= br>
The poin= t though is that this is an example of a non-transport service-provider att= aching VMs and other hosts/appliances/services ultimately to customer L3VPN= s internal to the provider's datacenter.  There is a  need for au= tomating the turn up of VPNs (as one of the VPN4DC drafts describe) on the = PEs facing the external transport providers with which they are running Int= er-AS option A, as well as on the PEs facing the VM hosts or virtualized appliances.  Also th= ere is a need for  automatically building a VM or a virtual-appliance = on the fly for service to that VPN.  

Sorry if this is t= oo verbose or not clear enough.  Here is a partial diagram: http://packetpushers.net/extending-private-networks-into-your-= datacenter/.  Now just imagine a PE in the data center with VMs at= tached to it for each of the four VRFs.

Derick


=

=

<= div class=3D"yui_3_2_0_16_131951353975457">
<= div class=3D"yui_3_2_0_16_131951353975457">

From: "So, Ning" <ning.so@verizon.co= m>
To: "l3vpn@ietf.o= rg" <l3vpn@ietf.org>
Sent: Monday, October 24, 2011 10:50 PM
Subject: RE: Re: Discussion of VPN4DC drafts

=0ADerick,

Please see my comments in-line.

 
Bes= t regards,
 
Ning So
Verizon Corporate Technology
(office)= 972-729-7905
(Cell) 972-955-0914
 
Date: Mon, 24 Oct 2011 17= :12:39 -0700 (PDT)
From: Derick Winkworth <ccie15672@yahoo.com= >
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>= ;,    L3VPN WG mailing list
    <l3vpn@ietf.or= g>
Subject: Re: Discussion of VPN4DC drafts
Message-ID:
&nb= sp;   <1319501559.87264.YahooMailNeo@web161802.mail.bf1.yahoo.com>
Cont= ent-Type: text/plain; charset=3D"iso-8859-1"

All:

I think the= drafts constitute a great start to addressing this gap. ?

My first,= perhaps superficial, observation is that much of the language is geared to= wards "Service-Provider." ?I think in the context of VPNs for Data Centers,= these drafts apply equally to multi-security zone Data Centers in non-SP n= etworks that have multiple logically isolated network segments. ?For instan= ce, multiple DMZs, server farms, storage networks, corporate LANs, guest LA= Ns, etc. ?These could very well all be L3VPNs in an MPLS infrastructure tha= t interconnects and extends into the various data centers of an enterprise = network. ?The kind of security and transparency that the infrastructure pro= vides is adequate for the purpose of passing audits (where the alternative must be physical separation of network resources). ?There is c= ertainly more enterprise adoption of MPLS happening in the field today for = this purpose.

[Ning] Agree.

Another applicable type of enviro= nment are "<blank>-service-providers" that provide various IP enabled= applications and services to the private networks of external customers. ?= These environments are not classic service-providers because they do not ow= n transport networks. ?They connect to multiple carriers to have reachabili= ty to as many potential customers' private networks as possible. In this ca= se they are extending customer's private networks into their data centers i= n a secure/transparent way, similar to the description in some of the draft= s for VPN4DC.

[Ning] Can you gave an example to help me understand i= t better?

I think it might be possible to generalize VPN4DC so that = its inclusive of these situations. To be clear, these scenarios involve companies who are not classic "service-providers" but are running = their own MPLS network with P and PE nodes and not just buying L3VPN sevice= s from an external provider. ?Rather than framing everything in a "service-= provider" or "enterprise" context, we could just frame it in general networ= king terms. ?

[Ning] Service provider and Enterprise are meant to be= generic terms, and I agree with you that they are not good terms to fit th= e situation you are describing.  I can certainly go back to make the t= erm more generalized (or at least clearly defined in definition section). <= br>
I think there is a sort of Hegelian synthesis happening in the indus= try between service-provider and enterprise, and VPN4DC is a clear bridge b= etween them.

[Ning] Agree. 

Thanks.

Derick

________________________________
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>To: L3VPN WG mailing list <l3vpn@ietf.org>
Sent: Monday, October 24,= 2011 6:35 PM
Subject: Discussion of VPN4DC drafts

Colleagues,
A number of drafts related to the VPN4DC topic are now available in t= he Internet-Draft repository. The ones I could fine are listed below.
When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was c= onditional on the basis that:

1) There needed to be viable -00 draft= s before the cutoff.
2) The problem needed to be discussed prior to Taip= ei on the L3VPN list.

To date there has not been much discussion of = VPN4DC on the L3VPN list, possibly because folks were waiting for -00 draft= s to be published.

Now that a number of drafts have been published I= would encourage those folks interested in the VPN4DC topic to discuss the various drafts on the L3VPN list otherwise you risk having the VPN4DC/L3VP= N session in Taipei cancelled.

The VPN4DC related drafts that I coul= d find (there may be others that I've missed) are:

VPN4DC Problem St= atement
http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement= -00

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-fan= g-vpn4dc-problem-statement-00

L3VPN automatical interconnection for = VPN4DC
http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00=

Requirements of Layer 3 Virtual Private Network for Data Centershttp://tools.ietf.org/html/draft-so-vpn4dc-00

L3VPN Protocol Gap An= alysis for Data Centers
http://tools.ietf.org/html/draft-yong-vpn4dc-pro= tocol-gap-analysis-00

Experiment of Example Solution for VPN4DC
h= ttp://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00

End-= system support for BGP-signaled IP/VPNs.
http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02
Problem Statement for Dynamic Secure Interconnect
http://tools.iet= f.org/html/draft-ko-dsi-problem-statement-00

Ben
-------------- n= ext part --------------
An HTML attachment was scrubbed...
URL: <h= ttp://www.ietf.org/mail-archive/web/l3vpn/attachments/20111024/38f215cb/att= achment.htm>


---337026386-1841433737-1319517945=:99929-- From lucy.yong@huawei.com Tue Oct 25 00:20:42 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2DA11E8083 for ; Tue, 25 Oct 2011 00:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.578 X-Spam-Level: X-Spam-Status: No, score=-5.578 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 21x3yzCyS7-v for ; Tue, 25 Oct 2011 00:20:38 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4638E21F8A69 for ; Tue, 25 Oct 2011 00:20:38 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTM007DV1QCTD@usaga02-in.huawei.com> for l3vpn@ietf.org; Tue, 25 Oct 2011 02:20:37 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LTM00I471QCJ0@usaga02-in.huawei.com> for l3vpn@ietf.org; Tue, 25 Oct 2011 02:20:36 -0500 (CDT) 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.270.1; Tue, 25 Oct 2011 00:20:33 -0700 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; Tue, 25 Oct 2011 00:20:29 -0700 Date: Tue, 25 Oct 2011 07:20:28 +0000 From: Lucy yong Subject: RE: Discussion of VPN4DC drafts In-reply-to: <1319501559.87264.YahooMailNeo@web161802.mail.bf1.yahoo.com> X-Originating-IP: [10.195.69.90] To: Derick Winkworth , Ben Niven-Jenkins , L3VPN WG mailing list Message-id: <2691CE0099834E4A9C5044EEC662BB9D118D3654@dfweml505-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cv0GBXKiWjmj5Nq01r3DDw)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Discussion of VPN4DC drafts Thread-index: AQHMkqrehGAw/SU5qUqE7WE7i3yCIZWMeEaQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1319501559.87264.YahooMailNeo@web161802.mail.bf1.yahoo.com> X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 07:20:42 -0000 --Boundary_(ID_cv0GBXKiWjmj5Nq01r3DDw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Derick, Thank very much for the good comments. You are right. The first version of the gap analysis just aims on the L3VPN in WAN. We restricted our first draft to the topic for a clear picture of the L3VPN WAN in VPN4DC. We did study some DC architectures and had written up a combined draft. However, earlier reviewers felt the draft should be split into two parts - DC L3VPN and WAN L3VPN for DC. We published the L3VPN WAN first. Would you like to review our work on the DC area? We'd love to work with you. We'd be glad to sponsor a call or meet you at IETF. Best Regards, Lucy From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Derick Winkworth Sent: Monday, October 24, 2011 7:13 PM To: Ben Niven-Jenkins; L3VPN WG mailing list Subject: Re: Discussion of VPN4DC drafts All: I think the drafts constitute a great start to addressing this gap. My first, perhaps superficial, observation is that much of the language is geared towards "Service-Provider." I think in the context of VPNs for Data Centers, these drafts apply equally to multi-security zone Data Centers in non-SP networks that have multiple logically isolated network segments. For instance, multiple DMZs, server farms, storage networks, corporate LANs, guest LANs, etc. These could very well all be L3VPNs in an MPLS infrastructure that interconnects and extends into the various data centers of an enterprise network. The kind of security and transparency that the infrastructure provides is adequate for the purpose of passing audits (where the alternative must be physical separation of network resources). There is certainly more enterprise adoption of MPLS happening in the field today for this purpose. Another applicable type of environment are "-service-providers" that provide various IP enabled applications and services to the private networks of external customers. These environments are not classic service-providers because they do not own transport networks. They connect to multiple carriers to have reachability to as many potential customers' private networks as possible. In this case they are extending customer's private networks into their data centers in a secure/transparent way, similar to the description in some of the drafts for VPN4DC. I think it might be possible to generalize VPN4DC so that its inclusive of these situations. To be clear, these scenarios involve companies who are not classic "service-providers" but are running their own MPLS network with P and PE nodes and not just buying L3VPN sevices from an external provider. Rather than framing everything in a "service-provider" or "enterprise" context, we could just frame it in general networking terms. I think there is a sort of Hegelian synthesis happening in the industry between service-provider and enterprise, and VPN4DC is a clear bridge between them. Thanks. Derick ________________________________ From: Ben Niven-Jenkins To: L3VPN WG mailing list Sent: Monday, October 24, 2011 6:35 PM Subject: Discussion of VPN4DC drafts Colleagues, A number of drafts related to the VPN4DC topic are now available in the Internet-Draft repository. The ones I could fine are listed below. When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was conditional on the basis that: 1) There needed to be viable -00 drafts before the cutoff. 2) The problem needed to be discussed prior to Taipei on the L3VPN list. To date there has not been much discussion of VPN4DC on the L3VPN list, possibly because folks were waiting for -00 drafts to be published. Now that a number of drafts have been published I would encourage those folks interested in the VPN4DC topic to discuss the various drafts on the L3VPN list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancelled. The VPN4DC related drafts that I could find (there may be others that I've missed) are: VPN4DC Problem Statement http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 VPN4DC Problem Statement http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 L3VPN automatical interconnection for VPN4DC http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 Requirements of Layer 3 Virtual Private Network for Data Centers http://tools.ietf.org/html/draft-so-vpn4dc-00 L3VPN Protocol Gap Analysis for Data Centers http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 Experiment of Example Solution for VPN4DC http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 End-system support for BGP-signaled IP/VPNs. http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Problem Statement for Dynamic Secure Interconnect http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 Ben --Boundary_(ID_cv0GBXKiWjmj5Nq01r3DDw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Derick,

 <= /p>

Thank very much for the g= ood comments. You are right. The first version of the  gap analysis ju= st aims on the L3VPN in WAN.   We restricted our first draft to the topic for a clear picture of the L3VPN WAN in VPN4DC.

 <= /p>

We did study some DC arch= itectures and had written up a combined draft.  However, earlier revie= wers felt the draft should be split into two parts – DC L3VPN and WAN L3VPN for DC.    We published the L3VPN WAN first. =

 <= /p>

Would you like to review = our work on the DC area?  We’d love to work with you.  We&#= 8217;d be glad to sponsor a call  or meet you at IETF.

 <= /p>

Best Regards,<= /span>

Lucy

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: l3vpn-bo= unces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Derick Winkworth
Sent: Monday, October 24, 2011 7:13 PM
To: Ben Niven-Jenkins; L3VPN WG mailing list
Subject: Re: Discussion of VPN4DC drafts

 

All:

 

I think the drafts = constitute a great start to addressing this gap.  

 

My first, perhaps s= uperficial, observation is that much of the language is geared towards &quo= t;Service-Provider."  I think in the context of VPNs for Data Centers, these drafts apply equally to multi-security zone Data C= enters in non-SP networks that have multiple logically isolated network seg= ments.  For instance, multiple DMZs, server farms, storage networks, c= orporate LANs, guest LANs, etc.  These could very well all be L3VPNs in an MPLS infrastructure that interconnects= and extends into the various data centers of an enterprise network.  = The kind of security and transparency that the infrastructure provides is a= dequate for the purpose of passing audits (where the alternative must be physical separation of network resources). =  There is certainly more enterprise adoption of MPLS happening in the = field today for this purpose.

 

Another applicable = type of environment are "<blank>-service-providers" that pr= ovide various IP enabled applications and services to the private networks of external customers.  These environments are not classic s= ervice-providers because they do not own transport networks.  They con= nect to multiple carriers to have reachability to as many potential custome= rs' private networks as possible. In this case they are extending customer's private networks into their data center= s in a secure/transparent way, similar to the description in some of the dr= afts for VPN4DC.

 

I think it might be= possible to generalize VPN4DC so that its inclusive of these situations. T= o be clear, these scenarios involve companies who are not classic "service-providers" but are running their own MP= LS network with P and PE nodes and not just buying L3VPN sevices from an ex= ternal provider.  Rather than framing everything in a "service-pr= ovider" or "enterprise" context, we could just frame it in general networking terms.  

 

I think there is a = sort of Hegelian synthesis happening in the industry between service-provid= er and enterprise, and VPN4DC is a clear bridge between them.

 

Thanks.<= /span>

 

Derick

 

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: Ben Niven-Jen= kins <ben@niven-jenkins.co.uk>
To: L3VPN WG mailing list <l3vpn@ietf.org>
Sent: Monday, October 24, 2011 6:35 PM
Subject: Discussion of VPN4DC drafts

Colleagues,

A number of drafts related to the VPN4DC topic are now available in the Int= ernet-Draft repository. The ones I could fine are listed below.

When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was con= ditional on the basis that:

1) There needed to be viable -00 drafts before the cutoff.
2) The problem needed to be discussed prior to Taipei on the L3VPN list.
To date there has not been much discussion of VPN4DC on the L3VPN list, pos= sibly because folks were waiting for -00 drafts to be published.

Now that a number of drafts have been published I would encourage those fol= ks interested in the VPN4DC topic to discuss the various drafts on the L3VP= N list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancell= ed.

The VPN4DC related drafts that I could find (there may be others that I've = missed) are:

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00

L3VPN automatical interconnection for VPN4DC
http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00

Requirements of Layer 3 Virtual Private Network for Data Centers
http://tools.ietf.org/html/draft-so-vpn4dc-00

L3VPN Protocol Gap Analysis for Data Centers
http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00

Experiment of Example Solution for VPN4DC
http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00

End-system support for BGP-signaled IP/VPNs.
http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02

Problem Statement for Dynamic Secure Interconnect
http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00

Ben


--Boundary_(ID_cv0GBXKiWjmj5Nq01r3DDw)-- From lufang@cisco.com Tue Oct 25 00:33:27 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B186B21F84FC for ; Tue, 25 Oct 2011 00:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=1.938, 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 95xnKp6Yu580 for ; Tue, 25 Oct 2011 00:33:26 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 920EA21F849A for ; Tue, 25 Oct 2011 00:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=5146; q=dns/txt; s=iport; t=1319528006; x=1320737606; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=9nFzgviuwvR1xKBbi2IqhqOgQtXPfcDFlJGgbua9qT4=; b=WAlguRGXfBKCbIP1rcLOjq4XYLn+SRfRbdWLeGVheaBm3NzR6rnFu+ho m8G3mako4vitQqVPyqeBlUsN3TEm8KeffywnaK8U3g08kpFXz/Z3xAsCM 6L9voe6Hyj4DQD1sF4Z1Sl2BlGlQUHCYBvr1SMzHs2eY2FS33so7wUD6/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAGdlpk6tJXHA/2dsb2JhbABAA5lXj0KBBYFuAQEBAQIBEgEdCjQQBwICAgEIEQMBAQELBhcBBgEVMAkIAQEEARIIEweHXgiVawGeWQKFLII0YQSIBpE4jEY X-IronPort-AV: E=Sophos;i="4.69,403,1315180800"; d="scan'208";a="30746837" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 25 Oct 2011 07:33:26 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9P7XQa2025925; Tue, 25 Oct 2011 07:33:26 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 02:33:25 -0500 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 Subject: RE: Discussion of VPN4DC drafts Date: Tue, 25 Oct 2011 02:33:23 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25072809F6@XMB-RCD-201.cisco.com> In-Reply-To: <6665BC1FEA04AB47B1F75FA641C43BC08F71ED49@FHDP1LUMXC7V41.us.one.verizon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion of VPN4DC drafts Thread-Index: AcySxcQSxR2YoRpjTn6NOravyH7yegAGtpWw References: <6665BC1FEA04AB47B1F75FA641C43BC08F71ED49@FHDP1LUMXC7V41.us.one.verizon.com> From: "Luyuan Fang (lufang)" To: "So, Ning" , X-OriginalArrivalTime: 25 Oct 2011 07:33:25.0956 (UTC) FILETIME=[61E7F040:01CC92E8] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 07:33:27 -0000 Ben, Thanks a lot!=20 And thanks to all participants - those who contribute the drafts and those discussed the topic on-line and off-line. In addition to Dave's and Ning's drafts, there are also a couple of more drafts related to the topic.=20 The following can be add to the list: Cloud Bursting Use Case http://tools.ietf.org/html/draft-mcdysan-sdnp-cloudbursting-usecase-00 Requirement and Framework for VPN-Oriented Data Center Services http://tools.ietf.org/html/draft-so-vdcs-00 Cloud Networking: Framework and VPN Applicability http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-00 Traffic classification, filtering and redirection for end-system IP VPNs http://tools.ietf.org/html/draft-marques-sdnp-flow-spec-00 The two framework docs are covering both L2 and L3, they need to be discussed in L3VPN and L2VPN. The other two drafts need to be discussed in L3VPN and SDNP BOF. > To date there has not been much discussion of VPN4DC on the L3VPN list,=20 There are actually quite a number of folks discussed off-line after the VPN4DC topic was brought up, and after draft-marques-l3vpn-end-system was posted. Folks, we really encourage you to bring the off-line discussions on-line, as much as possible. Heads-up, we are targeting Tuesday for BarBOF, will send the info on the time and location to meet later. Thanks, Luyuan > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of So, Ning > Sent: Monday, October 24, 2011 11:26 PM > To: l3vpn@ietf.org > Subject: RE: Discussion of VPN4DC drafts >=20 > Ben, >=20 > Thanks putting together the list of drafts. As you can see from the > work produced in this area, a lot of people have been working hard to > meet the deadline. I know at least one more draft that is also related > to VPN4DC ( https://datatracker.ietf.org/doc/draft-mcdysan-sdnp- > cloudbursting-usecase/). Dave asked for presentation slot for SDN BoF. > He has also talked with Luyuan and myself about discussing it in VPN4DC > barBoF, as well as L3VPN if time permits. I am also in the process of > updating -02 version of Requirement for VPN-oriented Data Center > Services with additional input collected recently. That is the > original draft that started VPN4DC work. >=20 > There has been some very good discussions on the scope of VPN4DC. The > current scope is limited to host-to-host connectivity through L3VPN > network. This scope clearly fits the IETF way of doing things. It is > very small, tangible, and achievable. However, there are a whole new > set of protocol work needs to be done in order to allow services to be > built on top of the host-to-host connection. We might want to have > some time during the meeting to discuss the going forward scope of > work. >=20 >=20 >=20 > Best regards, >=20 > Ning So > Verizon Corporate Technology > (office) 972-729-7905 > (Cell) 972-955-0914 >=20 >=20 > Date: Tue, 25 Oct 2011 00:35:14 +0100 > From: Ben Niven-Jenkins > To: L3VPN WG mailing list > Subject: Discussion of VPN4DC drafts > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii >=20 > Colleagues, >=20 > A number of drafts related to the VPN4DC topic are now available in the > Internet-Draft repository. The ones I could fine are listed below. >=20 > When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was > conditional on the basis that: >=20 > 1) There needed to be viable -00 drafts before the cutoff. > 2) The problem needed to be discussed prior to Taipei on the L3VPN > list. >=20 > To date there has not been much discussion of VPN4DC on the L3VPN list, c >=20 > Now that a number of drafts have been published I would encourage those > folks interested in the VPN4DC topic to discuss the various drafts on > the L3VPN list otherwise you risk having the VPN4DC/L3VPN session in > Taipei cancelled. >=20 > The VPN4DC related drafts that I could find (there may be others that > I've missed) are: >=20 > VPN4DC Problem Statement > http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 >=20 > VPN4DC Problem Statement > http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 >=20 > L3VPN automatical interconnection for VPN4DC > http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 >=20 > Requirements of Layer 3 Virtual Private Network for Data Centers > http://tools.ietf.org/html/draft-so-vpn4dc-00 >=20 > L3VPN Protocol Gap Analysis for Data Centers > http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 >=20 > Experiment of Example Solution for VPN4DC > http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 >=20 > End-system support for BGP-signaled IP/VPNs. > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >=20 > Problem Statement for Dynamic Secure Interconnect > http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 >=20 > Ben >=20 From lufang@cisco.com Tue Oct 25 00:45:56 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAA021F8669 for ; Tue, 25 Oct 2011 00:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=1.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 jPueFk3NuWat for ; Tue, 25 Oct 2011 00:45:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 35B0821F84B9 for ; Tue, 25 Oct 2011 00:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=29108; q=dns/txt; s=iport; t=1319528754; x=1320738354; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=zMYj2OfTEhDfP73XFPpx0Lg5OBTXMM3qL/HLwaoMMCI=; b=JkGF9QayZTq2lvbGjEkBzmld6ynhLdyFo3DJkfAJt2u+cdvAX5UBh17d KNQVwxTbUolc0AVL7NclGlD0VK+7qopuJCs+JilVf+Ve79/AsR46hUUXi ALPVZCv9SsXQPeclDQ9brk10p4faoV0KPGITxz8ris/oK+vpk656yE7nG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoBAL1opk6tJXG+/2dsb2JhbABAA4JNlwoPjzOBBYFuAQEBAQMSAQkRAzcHGQICAQgOAwMBAQELBhAHAQYBFS8BCQgBAQQBEggBEgeHZpVxAZ5ZAoUsgjRhBIgGkTiEf4dH X-IronPort-AV: E=Sophos;i="4.69,403,1315180800"; d="scan'208,217";a="30747937" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 25 Oct 2011 07:45:53 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9P7jrEI013404; Tue, 25 Oct 2011 07:45:53 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); Tue, 25 Oct 2011 02:45:53 -0500 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_01CC92EA.1F11E038" Subject: RE: Re: Discussion of VPN4DC drafts Date: Tue, 25 Oct 2011 02:45:51 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25072809F7@XMB-RCD-201.cisco.com> In-Reply-To: <1319517945.99929.YahooMailNeo@web161805.mail.bf1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Discussion of VPN4DC drafts Thread-Index: AcyS0P3xxKfzNc4fQt2zu0BMwUIjCgAF5c2g References: <6665BC1FEA04AB47B1F75FA641C43BC08F71ED4F@FHDP1LUMXC7V41.us.one.verizon.com> <1319517945.99929.YahooMailNeo@web161805.mail.bf1.yahoo.com> From: "Luyuan Fang (lufang)" To: "Derick Winkworth" , X-OriginalArrivalTime: 25 Oct 2011 07:45:53.0312 (UTC) FILETIME=[1F5D6A00:01CC92EA] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 07:45:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC92EA.1F11E038 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Derick, =20 I think you are right about a lot of focus on service provider in many cases, and indeed we have many SP contributors. J But our intention, at least from my end, was to cover the DC/Cloud VPN in general, including network service providers, content providers, and Enterprises. E.g. draft-fang-vpn4dc-problem-statement-00.txt is general in scope. =20 You brought up a lot of good points and very useful examples. Would you mind to turn these use cases into a Use Case draft?=20 It does not need to be comprehensive covering all cases. We could have separate documents each covering different type of cases. We could also consolidate them together later. The format is less important than the content. =20 Thanks, Luyuan =20 From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Derick Winkworth Sent: Tuesday, October 25, 2011 12:46 AM To: l3vpn@ietf.org Subject: Re: Re: Discussion of VPN4DC drafts =20 Ning: =20 ----- Another applicable type of environment are "-service-providers"... [Ning] Can you gave an example to help me understand it better? ----- =20 For instance, there are SIP/VoIP providers who do not own a regional or nation-wide MPLS transport network used primarily as revenue-generating L3VPN services network (such as Verizon, ATT, etc have). I have seen in a number of networks where these type of providers would purchase a DS3 or ethernet circuit from Verizon or ATT and channelize it with PVCs or VLANs. Each PVC or VLAN would correspond to a different L3VPN network (i.e., customer) on Verizon or ATT's MPLS network. The SIP/VoIP provider would then use Inter-AS Option A to connect these L3VPN networks to L3VPN networks they have built for their external customers in their data center. They are effectively extending these L3VPNs into their datacenter to attach (and customize) services to them. In some cases customer owned appliances are put "in the path" of the customer's traffic in the provider's data center. =20 =20 There are SIP, Storage, and E-mail providers (all fairly obvious) that I am aware of doing this. Less obvious are more specialized services like financial services and applications and medical applications and services. Locally here I have run into at least one company delivering video and audio in this fashion for businesses that want streaming advertisements on media displays. =20 =20 Of course, in order to maximize their potential customer base they connect to multiple carriers in this way. =20 =20 The point though is that this is an example of a non-transport service-provider attaching VMs and other hosts/appliances/services ultimately to customer L3VPNs internal to the provider's datacenter. There is a need for automating the turn up of VPNs (as one of the VPN4DC drafts describe) on the PEs facing the external transport providers with which they are running Inter-AS option A, as well as on the PEs facing the VM hosts or virtualized appliances. Also there is a need for automatically building a VM or a virtual-appliance on the fly for service to that VPN. =20 =20 Sorry if this is too verbose or not clear enough. Here is a partial diagram: http://packetpushers.net/extending-private-networks-into-your-datacenter /. Now just imagine a PE in the data center with VMs attached to it for each of the four VRFs. =20 Derick =20 =20 =20 =20 =20 =20 =20 From: "So, Ning" To: "l3vpn@ietf.org" Sent: Monday, October 24, 2011 10:50 PM Subject: RE: Re: Discussion of VPN4DC drafts Derick, Please see my comments in-line. =20 Best regards, =20 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =20 Date: Mon, 24 Oct 2011 17:12:39 -0700 (PDT) From: Derick Winkworth To: Ben Niven-Jenkins , L3VPN WG mailing list Subject: Re: Discussion of VPN4DC drafts Message-ID: <1319501559.87264.YahooMailNeo@web161802.mail.bf1.yahoo.com> Content-Type: text/plain; charset=3D"iso-8859-1" All: I think the drafts constitute a great start to addressing this gap. ? My first, perhaps superficial, observation is that much of the language is geared towards "Service-Provider." ?I think in the context of VPNs for Data Centers, these drafts apply equally to multi-security zone Data Centers in non-SP networks that have multiple logically isolated network segments. ?For instance, multiple DMZs, server farms, storage networks, corporate LANs, guest LANs, etc. ?These could very well all be L3VPNs in an MPLS infrastructure that interconnects and extends into the various data centers of an enterprise network. ?The kind of security and transparency that the infrastructure provides is adequate for the purpose of passing audits (where the alternative must be physical separation of network resources). ?There is certainly more enterprise adoption of MPLS happening in the field today for this purpose. [Ning] Agree. Another applicable type of environment are "-service-providers" that provide various IP enabled applications and services to the private networks of external customers. ?These environments are not classic service-providers because they do not own transport networks. ?They connect to multiple carriers to have reachability to as many potential customers' private networks as possible. In this case they are extending customer's private networks into their data centers in a secure/transparent way, similar to the description in some of the drafts for VPN4DC. [Ning] Can you gave an example to help me understand it better? I think it might be possible to generalize VPN4DC so that its inclusive of these situations. To be clear, these scenarios involve companies who are not classic "service-providers" but are running their own MPLS network with P and PE nodes and not just buying L3VPN sevices from an external provider. ?Rather than framing everything in a "service-provider" or "enterprise" context, we could just frame it in general networking terms. ? [Ning] Service provider and Enterprise are meant to be generic terms, and I agree with you that they are not good terms to fit the situation you are describing. I can certainly go back to make the term more generalized (or at least clearly defined in definition section).=20 I think there is a sort of Hegelian synthesis happening in the industry between service-provider and enterprise, and VPN4DC is a clear bridge between them. [Ning] Agree. =20 Thanks. Derick ________________________________ From: Ben Niven-Jenkins To: L3VPN WG mailing list Sent: Monday, October 24, 2011 6:35 PM Subject: Discussion of VPN4DC drafts=20 Colleagues, A number of drafts related to the VPN4DC topic are now available in the Internet-Draft repository. The ones I could fine are listed below. When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was conditional on the basis that: 1) There needed to be viable -00 drafts before the cutoff. 2) The problem needed to be discussed prior to Taipei on the L3VPN list. To date there has not been much discussion of VPN4DC on the L3VPN list, possibly because folks were waiting for -00 drafts to be published. Now that a number of drafts have been published I would encourage those folks interested in the VPN4DC topic to discuss the various drafts on the L3VPN list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancelled. The VPN4DC related drafts that I could find (there may be others that I've missed) are: VPN4DC Problem Statement http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 VPN4DC Problem Statement http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 L3VPN automatical interconnection for VPN4DC http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 Requirements of Layer 3 Virtual Private Network for Data Centers http://tools.ietf.org/html/draft-so-vpn4dc-00 L3VPN Protocol Gap Analysis for Data Centers http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 Experiment of Example Solution for VPN4DC http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 End-system support for BGP-signaled IP/VPNs. http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Problem Statement for Dynamic Secure Interconnect http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: ------_=_NextPart_001_01CC92EA.1F11E038 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Derick,

 

I think you are right about a lot of = focus on service provider in many cases, and indeed we have many SP contributors. = J

But our intention, at least from my = end, was to cover the DC/Cloud VPN in general, including network service = providers, content providers, and Enterprises. E.g. = draft-fang-vpn4dc-problem-statement-00.txt is general in scope.

 

You brought up a lot of good points = and very useful examples. Would you mind to turn these use cases into a Use Case = draft?

It does not need to be comprehensive = covering all cases. We could have separate documents each covering different type = of cases. We could also consolidate them together later. The format is less important than the content.

 

Thanks,

Luyuan

 

From:= l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of = Derick Winkworth
Sent: Tuesday, October 25, 2011 12:46 AM
To: l3vpn@ietf.org
Subject: Re: Re: Discussion of VPN4DC = drafts

 

Ning:

 

-----

Another applicable type of environment are "<blank>-service-providers"...

[Ning] Can you gave an example to help me understand it = better?

-----

 

For instance, there are = SIP/VoIP providers who do not own a regional or nation-wide MPLS transport = network used primarily as revenue-generating L3VPN services network (such as Verizon, = ATT, etc have).  I have seen in a number of networks where these type of providers would purchase a DS3 or ethernet circuit from Verizon or ATT = and channelize it with PVCs or VLANs.  Each PVC or VLAN would = correspond to  a different L3VPN network (i.e., customer) on Verizon or ATT's = MPLS network.  The SIP/VoIP provider would then use Inter-AS Option A to connect these L3VPN networks to L3VPN networks they have built for their external customers in their data center.  They are effectively = extending these L3VPNs into their datacenter to attach (and customize) services to = them.  In some cases customer owned appliances are put "in the = path" of the customer's traffic in the provider's data center. =  

 

There are SIP, Storage, = and E-mail providers (all fairly obvious) that I am aware of doing this. =  Less obvious are more specialized services like financial services and = applications and medical applications and services.  Locally here I have run = into at least one company delivering video and audio in this fashion for businesses = that want streaming advertisements on media displays.  

 

Of course, in order to = maximize their potential customer base they connect to multiple carriers in this = way.  

 

The point though is that = this is an example of a non-transport service-provider attaching VMs and other hosts/appliances/services ultimately to customer L3VPNs internal to the provider's datacenter.  There is a  need for automating the = turn up of VPNs (as one of the VPN4DC drafts describe) on the PEs facing the = external transport providers with which they are running Inter-AS option A, as = well as on the PEs facing the VM hosts or virtualized appliances.  Also = there is a need for  automatically building a VM or a virtual-appliance on the = fly for service to that VPN.  

 

Sorry if this is too = verbose or not clear enough.  Here is a partial diagram: http://packetpushers.net/extending-private-networks-into-your-d= atacenter/.  Now just imagine a PE in the data center with VMs attached to it = for each of the four VRFs.

 

Derick

 

 

 

 

 

 

 

F= rom: "So, Ning" <ning.so@verizon.com>
To: "l3vpn@ietf.org" <l3vpn@ietf.org>
Sent: Monday, October 24, 2011 10:50 PM
Subject: RE: Re: Discussion of VPN4DC drafts

Derick,

Please see my comments in-line.

 
Best regards,
 
Ning So
Verizon Corporate Technology
(office) 972-729-7905
(Cell) 972-955-0914
 
Date: Mon, 24 Oct 2011 17:12:39 -0700 (PDT)
From: Derick Winkworth <ccie15672@yahoo.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>,&= nbsp;   L3VPN WG mailing list
    <l3vpn@ietf.org>
Subject: Re: Discussion of VPN4DC drafts
Message-ID:
    <1319501559.87264.YahooMailNeo@web161802.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

All:

I think the drafts constitute a great start to addressing this gap. = ?

My first, perhaps superficial, observation is that much of the language = is geared towards "Service-Provider." ?I think in the context of = VPNs for Data Centers, these drafts apply equally to multi-security zone Data Centers in non-SP networks that have multiple logically isolated network segments. ?For instance, multiple DMZs, server farms, storage networks, corporate LANs, guest LANs, etc. ?These could very well all be L3VPNs in = an MPLS infrastructure that interconnects and extends into the various data centers of an enterprise network. ?The kind of security and transparency = that the infrastructure provides is adequate for the purpose of passing = audits (where the alternative must be physical separation of network = resources). ?There is certainly more enterprise adoption of MPLS happening in the = field today for this purpose.

[Ning] Agree.

Another applicable type of environment are = "<blank>-service-providers" that provide various IP enabled applications and services to the private networks of external customers. ?These environments are not classic service-providers because they do not own transport networks. ?They = connect to multiple carriers to have reachability to as many potential customers' = private networks as possible. In this case they are extending customer's private networks into their data centers in a secure/transparent way, similar to = the description in some of the drafts for VPN4DC.

[Ning] Can you gave an example to help me understand it better?

I think it might be possible to generalize VPN4DC so that its inclusive = of these situations. To be clear, these scenarios involve companies who are = not classic "service-providers" but are running their own MPLS = network with P and PE nodes and not just buying L3VPN sevices from an external provider. ?Rather than framing everything in a = "service-provider" or "enterprise" context, we could just frame it in general = networking terms. ?

[Ning] Service provider and Enterprise are meant to be generic terms, = and I agree with you that they are not good terms to fit the situation you are describing.  I can certainly go back to make the term more = generalized (or at least clearly defined in definition section).

I think there is a sort of Hegelian synthesis happening in the industry = between service-provider and enterprise, and VPN4DC is a clear bridge between = them.

[Ning] Agree. 

Thanks.

Derick


________________________________
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk> To: L3VPN WG mailing list <l3vpn@ietf.org>
Sent: Monday, October 24, 2011 6:35 PM
Subject: Discussion of VPN4DC drafts

Colleagues,

A number of drafts related to the VPN4DC topic are now available in the Internet-Draft repository. The ones I could fine are listed below.

When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was conditional on the basis that:

1) There needed to be viable -00 drafts before the cutoff.
2) The problem needed to be discussed prior to Taipei on the L3VPN = list.

To date there has not been much discussion of VPN4DC on the L3VPN list, possibly because folks were waiting for -00 drafts to be published.

Now that a number of drafts have been published I would encourage those = folks interested in the VPN4DC topic to discuss the various drafts on the = L3VPN list otherwise you risk having the VPN4DC/L3VPN session in Taipei = cancelled.

The VPN4DC related drafts that I could find (there may be others that = I've missed) are:

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00

L3VPN automatical interconnection for VPN4DC
http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00

Requirements of Layer 3 Virtual Private Network for Data Centers
http://tools.ietf.org/html/draft-so-vpn4dc-00

L3VPN Protocol Gap Analysis for Data Centers
http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00
=
Experiment of Example Solution for VPN4DC
http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00

End-system support for BGP-signaled IP/VPNs.
http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02

Problem Statement for Dynamic Secure Interconnect
http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: = <http://www.ietf.org/mail-archive/web/l3vpn/attachments/20111024/38f21= 5cb/attachment.htm>

------_=_NextPart_001_01CC92EA.1F11E038-- From wesley.george@twcable.com Tue Oct 25 07:57:34 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DC221F8AF4; Tue, 25 Oct 2011 07:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 6bhfsOn9IvH6; Tue, 25 Oct 2011 07:57:33 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5A87B21F8AF6; Tue, 25 Oct 2011 07:57:33 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,403,1315195200"; d="scan'208";a="289331584" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Oct 2011 10:53:43 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 25 Oct 2011 10:57:32 -0400 From: "George, Wes" To: "robert@raszuk.net" Date: Tue, 25 Oct 2011 10:57:35 -0400 Subject: RE: Comment reg draft-gs-vpn-scaling-00.txt Thread-Topic: Comment reg draft-gs-vpn-scaling-00.txt Thread-Index: AcySus946TmyRpWZQaqQKi6GeDuXhgAaljbw Message-ID: References: <4EA619CE.80408@raszuk.net> In-Reply-To: <4EA619CE.80408@raszuk.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Rob Shakir , "grow@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 14:57:34 -0000 Um9iZXJ0IC0gdGhhbmtzLiBJbmRlZWQgUm9iIGFuZCBteSBob3BlIGluIHBvc3RpbmcgdGhpcyBk cmFmdCB3YXMgdG8gaGF2ZSBhIGdvb2Qgc29saWQgZGlzY3Vzc2lvbiBhYm91dCBwcm9ibGVtcyBh bmQgZ2FwcyBzbyB0aGF0IHdlIHdlcmUgY2xlYXJseSBhcnRpY3VsYXRpbmcgc29tZSBvZiB0aGUg aXNzdWVzIHdlJ3JlIGZhY2luZywgd2l0aCB0aGUgZ29hbCB0aGF0IGZvbGtzIHdpdGhpbiB0aGUg SUVURiBjb3VsZCBjb21lIHVwIHdpdGggc29tZSBjcmVhdGl2ZSBzb2x1dGlvbnMgdG8gaGVscCBv dXQsIGV2ZW4gcG9zc2libHkgYWRhcHRpbmcgc29tZSBvZiB0aGUgdGhpbmdzIHRoYXQgYXJlIGJl aW5nIHByb3Bvc2VkIHdpdGhpbiBHUk9XIHRvIGhlbHAgd2l0aCBJbnRlcm5ldCBSb3V0ZSBzY2Fs aW5nIGluIG9yZGVyIGZvciB0aGVtIHRvIGhlbHAgd2l0aCBWUE4gcm91dGUgc2NhbGluZy4NCkkn bSBvZiB0aGUgbWluZCB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIGxpbWl0IHRoZSBzY29wZSBvZiB0 aGUgY3VycmVudCBkb2N1bWVudCB0byBkaXNjdXNzaW5nIHByb2JsZW1zL2dhcHMgYW5kIGJlc3Qg cHJhY3RpY2VzLiBUaGVuLCBlaXRoZXIgdGhlIHNvbHV0aW9ucyBkcmFmdHMgY2FuIHVzZSB0aGF0 IGFzIGEgZnJhbWV3b3JrIHRvIGNpdGUgc3BlY2lmaWMgaXRlbXMgdGhhdCB0aGV5IGFyZSB3b3Jr aW5nIHRvIHJlc29sdmUsIG9yIHBlcmhhcHMgdGhlcmUgaXMgYSBmb2xsb3ctb24gZHJhZnQgdGhh dCBjYXRhbG9ncy9zdXJ2ZXlzIHNvbWUgcG90ZW50aWFsIHNvbHV0aW9ucywgcHJvcy9jb25zLCBl dGMuDQoNCk1lYW50aW1lLCBzaW5jZSB5b3UndmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGlzIHBy b2JsZW0gYXMgd2VsbCwgd2UnZCB3ZWxjb21lIGZlZWRiYWNrIHRvIGltcHJvdmUgdGhlIHRleHQg b2YgdGhlIGRyYWZ0ISA6LSkNCg0KV2VzIEdlb3JnZQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogUm9iZXJ0IFJhc3p1ayBbbWFpbHRvOnJvYmVydEByYXN6dWsubmV0 XQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMjQsIDIwMTEgMTA6MDcgUE0NCj4gVG86IEdlb3Jn ZSwgV2VzDQo+IENjOiBsM3ZwbkBpZXRmLm9yZzsgZ3Jvd0BpZXRmLm9yZzsgUm9iIFNoYWtpcjsg TWljaGFlbCBLbw0KPiBTdWJqZWN0OiBDb21tZW50IHJlZyBkcmFmdC1ncy12cG4tc2NhbGluZy0w MC50eHQNCj4NCj4gSGkgV2VzLA0KPg0KPiBXaGF0IGEgcGVyZmVjdCB0aW1pbmcgLi4uDQo+DQo+ IEkgdmVyeSBtdWNoIGFncmVlIHdpdGggdGhlIHNjYWxpbmcgYXNwZWN0cyBvZiBMM1ZQTiBzZXJ2 aWNlIG1vZGVsIHlvdQ0KPiBoYXZlIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQuIENsZWFybHkgbW9y ZSBoYXJkd2FyZSBpcyBub3QgdGhlIGFuc3dlciAuLg0KPiB3ZWxsIGF0IGxlYXN0IGZvciB0aGUg b3BlcmF0b3Igc2lkZSAtIGNvbnNpZGVyaW5nIHRoYXQgc3VjaCBoYXJkd2FyZSBpcw0KPiBub3Qg YSBjb21tb2RpdHkgb25lIGVzcGVjaWFsbHkgd2hlbiBvdXIgY3VzdG9tZXJzIGNvbnRpbnVlIHRv IGV4cGVjdA0KPiBtb3JlIGZvciBsZXNzLg0KPg0KPiBUaGUgbGFjayBvZiBzY2FsaW5nIG9mIEwz VlBOcyBoYXMgYmVlbiB0aGUgdG9waWMgb2YgZGlzY3Vzc2lvbnMgZm9yDQo+IHNvbWUNCj4gdGlt ZSBub3cgYW1vbmcgbWFueSBvcGVyYXRpb24gdGVhbXMgb2Ygc2VydmljZSBwcm92aWRlcnMuDQo+ DQo+IFRoZXJlIGFyZSB0d28gbWFpbiBjb25jZXJucyB0aGF0IGFyaXNlIC0gcm91dGUgc2NhbGlu ZyBhbmQgcGxhdGZvcm0NCj4gc2NhbGluZy4NCj4NCj4gTXkgb2JzZXJ2YXRpb24gaXMgdGhhdCB0 aGVyZSBhcmUgdHdvIG1haW4gaXNzdWVzIHdoaWNoIGFyZSBtYWpvcg0KPiBjb250cmlidXRvcnMg dG8gdGhlIHByb2JsZW06DQo+DQo+IC0gdGhlIGFzcGVjdCBvZiBkaXJlY3RseSBhdHRhY2hpbmcg YSBWUE4gc2l0ZSdzIENFIHRvIHNlcnZpY2UgcHJvdmlkZXINCj4gICAgUEUNCj4NCj4gLSB0aGUg YXNwZWN0IG9mIGNvbnZlcnRpbmcgYWxsIGN1c3RvbWVyIHJvdXRlcyB0byBvbmUgY29tbW9uIFZQ TnY0L3Y2DQo+ICAgIGNvbnRhaW5lciB3aGljaCBiZWNvbWVzIHRvbyBoZWF2eSB0byBjYXJyeSBh cm91bmQNCj4NCj4gT3JpZ2luYWxseSBJIHdhcyBwZXJzb25hbGx5IGludmVzdGlnYXRpbmcgdGhl IGlkZWEgb2YgYXQgbGVhc3QNCj4gZWxpbWluYXRpbmcgdGhlIGxhdHRlciBieSBjb252ZXJ0aW5n IHRoZSBMM1ZQTiBtb2RlbCB0byBiZSBtb3JlIG9mIENTQw0KPiB0eXBlIChldmVuIGZvciByZWd1 bGFyIENFIHNpdGVzIHdoaWNoIHdvdWxkIG5vdCBydW4gTVBMUykuIEhvd2V2ZXIgdGhhdA0KPiB0 eXBlIG9mIGFwcHJvYWNoIHN0aWxsIGNhcnJpZXMgdGhlIGluZmxleGliaWxpdHkgaXNzdWUgb2Yg ZGlyZWN0bHkNCj4gYXR0YWNobWVudCBvZiBzaXRlcyB3aGljaCB3aGlsZSBmb3Igc29tZSBzaXRl cyBhcmUganVzdCBmaW5lLCBidXQgZm9yDQo+IG90aGVycyBhcmUgdXN1YWxseSBiZXlvbmQgdGhl IGxvY2FsIHJlYWNoIG9mIHRoZSBMM1ZQTiBTUCBwcm92aWRlci4NCj4NCj4gIEZyb20gdGhhdCBw b2ludCBJIGFuZCBmZXcgb3RoZXIgY29sbGVhZ3VlcyBvZiBtaW5lIGhhdmUgc3RhcnRlZCB0bw0K PiB0aGluaw0KPiBhYm91dCBjb21wbGV0ZWx5IG5ldyB3YXkgdG8gYWNjb21wbGlzaCBMMiBvciBM M1ZQTiBzZXJ2aWNlcyByYW5naW5nDQo+IGZyb20NCj4gbW9iaWxlIHNtYXJ0cGhvbmUgYXMgQ0Ug dG8gbGFyZ2Ugc2l0ZSBhcyBDRS4gTW9yZW92ZXIgc3VjaCBWUE4gc2VydmljZQ0KPiBjYW4gYmUg cHJvdmlkZWQgbm90IGVzc2VudGlhbGx5IGJ5IGxvY2FsbHkgcHJlc2VudCBuZXR3b3JrIG9wZXJh dG9yLg0KPg0KPiBUaGUgbmFtZSBJIGludmVudGVkIGZvciBpdCBpcyBWYWFTIChWUE4tYXMtYS1T ZXJ2aWNlKSB3aGljaCBlc3BlY2lhbGx5DQo+IG5vdyBjb3VsZCBiZSBlYXNpbHkgb2ZmZXJlZCBh cyBhIG5ldyB0eXBlIG9mIGNsb3VkIGFwcGxpY2F0aW9uLg0KPg0KPiBJbiBhIG51dCBzaGVsbCB0 aGUgZnVuZGFtZW50YWwgcHJvYmxlbXMgYXJlIHNvbHZlZCBieSByZW1vdmluZyB0aGUNCj4gcmVx dWlyZW1lbnQgdG8gYXR0YWNoIGN1c3RvbWVyIHRvIGFueSBQRSBib3ggLSBWYWFTIGNvbnRyb2wg cGxhbmUNCj4gc2VydmVyDQo+IGNhbiBiZSBhY2Nlc3NlZCBieSBhbnkgbWVhbnMgb2YgdXNlciBp bnRlcm5ldCBjb25uZWN0aW9uLg0KPg0KPiBJdCBhbHNvIGNvbXBsZXRlbHkgcmVtb3ZlcyB0aGUg bmVlZCB0byBjb21iaW5lIFZQTiBzaXRlJ3Mgcm91dGluZw0KPiBpbmZvcm1hdGlvbiAuLiB5b3Ug a2VlcCByb3V0ZXMgb2YgZWFjaCBWUE4gc2l0ZXMgaW4gYSBzZXBhcmF0ZSByb3V0aW5nDQo+IHNs aWNlIC0gYWxzbyByZXNpZGluZyBvbiB0aGUgY29udHJvbCBwbGFuZSBzZXJ2ZXIgb3IgVk0uIFdp dGggZHluYW1pYw0KPiBhbGxvY2F0aW9uIG9mIGNvbXB1dGUgYW5kIHN0b3JhZ2Ugd2hpY2ggaXMg YmVjb21pbmcgYSBjb21tb2RpdHkgaW4gYW55DQo+IG1vZGVybiBkYXRhIGNlbnRlciBvbmUgY291 bGQgZWFzaWx5IG9ic2VydmUgdGhhdCBzY2FsaW5nIGFzcGVjdHMgb2YNCj4gc3VjaA0KPiBhIHNl cnZpY2UgbW9kZWwgYmVjb21lcyB2ZXJ5IG11Y2ggc2hpZnRlZCBmcm9tIHZlbmRvciBkZXZpY2Vz IHRvDQo+IGNvbW1vZGl0eSBjb21wdXRpbmcgYW5kIHN0b3JhZ2UgbWFuYWdlZCBieSBpbnRlbGxp Z2VudCBhbmQgdmVyeSBkeW5hbWljDQo+IGRhdGEgY2VudGVycycgam9iIGRpc3RyaWJ1dGlvbiB0 b29scy4NCj4NCj4gQWxzbyB3aGlsZSB0aGlzIGlzIHN0aWxsIHZlcnkgbXVjaCB3b3JrIGluIHBy b2dyZXNzIEkgd291bGQgZW5jb3VyYWdlDQo+IGFueW9uZSBjb25jZXJuZWQgd2l0aCB0b2RheSdz IEwzVlBOIHNjYWxlIHRvIHJlYWQgYW5kIHByb3ZpZGUgY29tbWVudHMNCj4gYW5kIG9waW5pb25z IG9uIHRoZSBiZWxvdyBkb2N1bWVudC4NCj4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQta28tdmFhcy1wcm9ibGVtLXN0YXRlbWVudC0NCj4gMDAudHh0DQo+DQo+ IEFzIGEgbWF0dGVyIG9mIGZhY3QgSSBhbSBzdGlsbCBhZGRpbmcgc29tZSBmcmFtZXdvcmsgdGV4 dCByZWcgcm91dGluZw0KPiBpbmZvcm1hdGlvbiBleGNoYW5nZSB0byB0aGlzIGRyYWZ0IHRoaXMg d2VlayBzbyBwZXJoYXBzIG5leHQgd2VlayAoaWYgSQ0KPiBtYW5hZ2UgdG8gZmluZCBlbm91Z2gg dGltZSkgdGhlcmUgd291bGQgYmUgYSAtMDEgdmVyc2lvbiBwb3N0ZWQuDQo+DQo+IEJ5IGJyaW5n aW5nIHRoaXMgdG8gdGhlIElFVEYgd2UgYXJlIHByZXNlbnRpbmcgdGhlIGlkZWEgZm9yIG9wZW4N Cj4gY29udHJpYnV0aW9uIGJ5IGFueW9uZSBpbnRlcmVzdGVkIGJvdGggaW4gdGhlIGFyY2hpdGVj dHVyZSBzcGFjZSBhcw0KPiB3ZWxsDQo+IGFzIHBvc3NpYmxlIG9wZW4gc291cmNlIGltcGxlbWVu dGF0aW9ucy4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBSLg0KPg0KPg0KPiA+IEhpLQ0KPiA+DQo+ ID4gUm9iIFNoYWtpciBhbmQgSSBoYXZlIGJlZW4gd29ya2luZyBvbiBhIGRyYWZ0IHRoYXQgZGlz Y3Vzc2VzIHNvbWUNCj4gPiBzY2FsaW5nIGNvbnNpZGVyYXRpb25zIGZvciBMM1ZQTiBuZXR3b3Jr cy4gV2UgcG9zdGVkIHRoaXMgdG9kYXkgaW4NCj4gPiBvcmRlciB0byBtZWV0IHRoZSAwMCBkZWFk bGluZSwgYnV0IGl0J3Mgc3RpbGwgbW9zdCBkZWZpbml0ZWx5IGEgd29yaw0KPiA+IGluIHByb2dy ZXNzLCBhbmQgd2UgYXJlIG5vdCBuZWNlc3NhcmlseSBsb29raW5nIHRvIHByZXNlbnQgaXQgYXQN Cj4gPiBUYWlwZWkgdW5sZXNzIHRoZXJlIGlzIGRlZmluaXRlIGludGVyZXN0IGZyb20gdGhlIGdy b3VwIGluIGhhdmluZyBhdA0KPiA+IGxlYXN0IGFuIGluaXRpYWwgRjJGIGRpc2N1c3Npb24uIFdl IHdlcmUgbWFpbmx5IGp1c3QgbG9va2luZyBmb3Igc29tZQ0KPiA+IGluaXRpYWwgZmVlZGJhY2sg b24gd2hldGhlciB0aGlzIGlzIHdvcmsgdGhlIGdyb3VwIHRoaW5rcyB3b3VsZCBiZQ0KPiA+IHVz ZWZ1bCwgc2luY2Ugd2Ugd2VyZW4ndCBjZXJ0YWluIGV4YWN0bHkgd2hlcmUgc29tZXRoaW5nIGxp a2UgdGhpcw0KPiA+IGZpdHMuIEwzVlBOIHNlZW1zIGxvZ2ljYWwgZ2l2ZW4gdGhlIHN1YmplY3Qg bWF0dGVyLCBidXQgb2Z0ZW4gc2NhbGluZw0KPiA+IGNvbnNpZGVyYXRpb25zIHdpdGggYW4gb3Bl cmF0aW9uYWwgZm9jdXMgbGlrZSB0aGlzIGVuZCB1cCBpbiBHUk9XLg0KPiA+IEJ1dCwgR1JPVyBm b2N1c2VzIG9uIGludGVybmV0IHJvdXRpbmcgYW5kIHRoZXJlZm9yZSBtaWdodCBub3QgYmUgYQ0K PiA+IGdvb2QgZml0IG90aGVyIHRoYW4gYmVpbmcgYSBwbGFjZSB3aGVyZSBmb2xrcyB3aXRoIGlk ZWFzIHRoYXQgbWlnaHQNCj4gPiBiZSBoZWxwZnVsIHRvIHRoaXMgZHJhZnQgdGVuZCB0byBoYW5n IG91dCwgaGVuY2UgdGhlIGNyb3NzLXBvc3QuDQo+ID4NCj4gPiBXZSdyZSBhbHNvIGxvb2tpbmcg Zm9yIGZvbGtzIHdpbGxpbmcgdG8gaGVscCB1cyBmbGVzaCBvdXQgc29tZSBvZiB0aGUNCj4gPiBz ZWN0aW9ucyB0aGF0IGFyZSBzdGlsbCBtaXNzaW5nIGluZm8sIGVzcGVjaWFsbHkgYXMgZmFyIGFz IG11bHRpY2FzdA0KPiA+IGlzIGNvbmNlcm5lZCwgZ2l2ZSB1cyBvdGhlciBzdWdnZXN0aW9ucy4g UGxlYXNlIGhhdmUgYSBsb29rLg0KPiA+DQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZ3MtdnBuLXNjYWxpbmctMDANCj4gPg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+IFdlcyBH ZW9yZ2UNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZw0KPiA+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSBT ZW50OiBNb25kYXksIE9jdG9iZXIgMjQsIDIwMTEgNToyMA0KPiA+IFBNIFRvOiBHZW9yZ2UsIFdl cyBDYzogcmpzQGN3Lm5ldDsgR2VvcmdlLCBXZXMgU3ViamVjdDogTmV3IFZlcnNpb24NCj4gPiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWdzLXZwbi1zY2FsaW5nLTAwLnR4dA0KPiA+DQo+ID4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdzLXZwbi1zY2FsaW5nLTAwLnR4dCBoYXMgYmVlbg0K PiA+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VzbGV5IEdlb3JnZSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGDQo+ID4gcmVwb3NpdG9yeS4NCj4gPg0KPiA+IEZpbGVuYW1lOiAgICAgICAgZHJh ZnQtZ3MtdnBuLXNjYWxpbmcgUmV2aXNpb246ICAgICAgICAwMCBUaXRsZToNCj4gPiBJUCBWUE4g U2NhbGluZyBDb25zaWRlcmF0aW9ucyBDcmVhdGlvbiBkYXRlOiAgIDIwMTEtMTAtMjQgV0cgSUQ6 DQo+ID4gSW5kaXZpZHVhbCBTdWJtaXNzaW9uIE51bWJlciBvZiBwYWdlczogMjANCj4gPg0KPiA+ IEFic3RyYWN0OiBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBzY2FsaW5nIGNvbnNpZGVyYXRpb25z IHVuaXF1ZSB0bw0KPiA+IGltcGxlbWVudGF0aW9uIG9mIExheWVyIDMgKElQKSBWaXJ0dWFsIFBy aXZhdGUgTmV0d29ya3MsIGRpc2N1c3NlcyBhDQo+ID4gZmV3IGJlc3QgcHJhY3RpY2VzLCBhbmQg aWRlbnRpZmllcyBnYXBzIGluIHRoZSBjdXJyZW50IHRvb2xzIGFuZA0KPiA+IHRlY2huaXF1ZXMg d2hpY2ggYXJlIG1ha2luZyBpdCBtb3JlIGRpZmZpY3VsdCBmb3Igb3BlcmF0b3JzIHRvIGNvc3Qt DQo+ID4gZWZmZWN0aXZlbHkgc2NhbGUgYW5kIG1hbmFnZSB0aGVpciBMM1ZQTiBkZXBsb3ltZW50 cy4NCj4gPg0KPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4NCj4gPiBUaGlzIEUtbWFpbCBh bmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZQ0K PiA+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRl bnRpYWwsIG9yDQo+ID4gc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2Fy bmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcw0KPiA+IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQNCj4gPiBpcyBhZGRyZXNz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWws DQo+ID4geW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlz dHJpYnV0aW9uLA0KPiA+IGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0 aGUgY29udGVudHMgb2YgYW5kDQo+ID4gYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlDQo+ID4gdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5DQo+ID4gdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55 DQo+ID4gY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KDQoNClRoaXMgRS1t YWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENh YmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRl bnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBD YWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5 IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywg b3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNo bWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhl IG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From ning.so@verizon.com Wed Oct 26 07:47:19 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C36B21F8B44 for ; Wed, 26 Oct 2011 07:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.951, 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 hztAWCT38Ls9 for ; Wed, 26 Oct 2011 07:47:19 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5F021F8B3F for ; Wed, 26 Oct 2011 07:47:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 26 Oct 2011 14:47:18 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.69,409,1315180800"; d="scan'208";a="167121755" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 26 Oct 2011 14:47:18 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.133]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Wed, 26 Oct 2011 10:47:17 -0400 To: "l3vpn@ietf.org" Date: Wed, 26 Oct 2011 10:47:16 -0400 Subject: FW: New Version Notification for draft-so-vdcs-02.txt Thread-Topic: New Version Notification for draft-so-vdcs-02.txt Thread-Index: AcyT7dpa0AA5MhyARzuJbJ627IJe/wAACyMg Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08F7F19A2@FHDP1LUMXC7V41.us.one.verizon.com> References: <20111026144454.22513.30261.idtracker@ietfa.amsl.com> In-Reply-To: <20111026144454.22513.30261.idtracker@ietfa.amsl.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-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 14:47:19 -0000 DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc28tdmRjcy0wMi50eHQgaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOaW5nIFNvIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1zby12ZGNzDQpSZXZpc2lvbjoJIDAyDQpUaXRs ZToJCSBSZXF1aXJlbWVudHMgZm9yIFZQTi1PcmllbnRlZCBEYXRhIENlbnRlciBTZXJ2aWNlcw0K Q3JlYXRpb24gZGF0ZToJIDIwMTEtMTAtMjYNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KTnVtYmVyIG9mIHBhZ2VzOiAxMA0KDQpBYnN0cmFjdDoNClRoaXMgY29udHJpYnV0aW9uIGFk ZHJlc3NlcyB0aGUgc2VydmljZSBwcm92aWRlcnMmIzM5OyByZXF1aXJlbWVudHMgdG8gc3VwcG9y dCBWUE4tT3JpZW50ZWQgZGF0YSBjZW50ZXIgc2VydmljZXMuIEl0IGRlc2NyaWJlcyB0aGUgY2hh cmFjdGVyaXN0aWNzIGFuZCB0aGUgZnJhbWV3b3JrIG9mIFZQTi1vcmllbnRlZCBkYXRhIGNlbnRl ciBzZXJ2aWNlcyBhbmQgc3BlY2lmaWVzIHRoZSByZXF1aXJlbWVudHMgb24gaG93IHRvIG1haW50 YWluIGFuZCBtYW5hZ2UgdGhlIHZpcnR1YWwgcmVzb3VyY2VzIHdpdGhpbiBkYXRhIGNlbnRlciBy ZXNvdXJjZXMgYW5kIHRoZSBzdXBwb3J0aW5nIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmVzIGZvciB0 aG9zZSBzZXJ2aWNlcy4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0K From lizhong.jin@zte.com.cn Fri Oct 28 00:16:48 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDD021F84D4; Fri, 28 Oct 2011 00:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.638 X-Spam-Level: X-Spam-Status: No, score=-100.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, 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 xbLtDqjhMnZq; Fri, 28 Oct 2011 00:16:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1960221F89BA; Fri, 28 Oct 2011 00:16:46 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466212260588612; Fri, 28 Oct 2011 15:08:00 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 60802.3864543671; Fri, 28 Oct 2011 15:16:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9S7GUh5084576; Fri, 28 Oct 2011 15:16:30 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: l3vpn@ietf.org, opsawg@ietf.org Subject: Re: Fwd: L3VPN automatic interconnection for VPN4DC MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Fri, 28 Oct 2011 15:15:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-28 15:16:32, Serialize complete at 2011-10-28 15:16:32 Content-Type: multipart/alternative; boundary="=_alternative 0027F6C148257937_=" X-MAIL: mse01.zte.com.cn p9S7GUh5084576 Cc: vumip1@gmail.com X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 07:16:48 -0000 This is a multipart message in MIME format. --=_alternative 0027F6C148257937_= Content-Type: text/plain; charset="US-ASCII" Hi All, This draft enables L3VPN VRF-to-VRF interconnection to be automatically provided by one PE, and is expect to reduce the VPN4DC provisioning time. Would appreciate if you could review. And any comments are welcome! Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Mon, 24 Oct 2011 18:51:37 -0400 > From: Bhumip Khasnabish > To: opsawg@ietf.org, l3vpn@ietf.org > Subject: Fwd: L3VPN automatical interconnection for VPN4DC > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : L3VPN automatical interconnection for VPN4DC > Author(s) : Lizhong Jin > Ning So > Bhumip Khasnabish > Bo Wu > Filename : draft-jin-l3vpn-vpn4dc-interconnect-00.txt > Pages : 7 > Date : 2011-10-24 > > VPN4DC provides VPN oriented datacenter service to customer through > L3VPN which is consisted of (private) L3VPN in datacenter and network > provider's L3VPN over wide geographical area. If we considering the > two L3VPN in two different AS, [RFC4364] providers three options to > achieve L3VPN inter-AS connection. Both option A and B could be used > to connect L3VPN in VPN4DC. This draft discusses a novel method for > implementing option A, to automatically configure the VRF interface > in order to interconnect the two segments of the end-to-end L3VPN. > This L3VPN interconnection automation mechanism is expected to > significantly reduce the VPN oriented inter-connection/service > provisioning time. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/l3vpn/attachments/20111024/e2f1cb0d/attachment.htm> > > ------------------------------ > -------------------------------------------------------- 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 0027F6C148257937_= Content-Type: text/html; charset="US-ASCII"
Hi All,
This draft enables L3VPN VRF-to-VRF interconnection to be automatically provided by one PE, and is expect to reduce the VPN4DC provisioning time. Would appreciate if you could review. And any comments are welcome!

Thanks
Lizhong


> ------------------------------
>
> Message: 2
> Date: Mon, 24 Oct 2011 18:51:37 -0400
> From: Bhumip Khasnabish <vumip1@gmail.com>
> To: opsawg@ietf.org, l3vpn@ietf.org
> Subject: Fwd: L3VPN automatical interconnection for VPN4DC
> Message-ID:
>    <CANtnpwgH9y3QZ2e1N84H62QpnHB3GcXhsTJEqVvU9JzmQjhy+w@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title           : L3VPN automatical interconnection for VPN4DC
> Author(s)       : Lizhong Jin
>                           Ning So
>                           Bhumip Khasnabish
>                           Bo Wu
> Filename        : draft-jin-l3vpn-vpn4dc-interconnect-00.txt
> Pages           : 7
> Date            : 2011-10-24
>
>    VPN4DC provides VPN oriented datacenter service to customer through
>    L3VPN which is consisted of (private) L3VPN in datacenter and network
>    provider&#39;s L3VPN over wide geographical area.  If we considering the
>    two L3VPN in two different AS, [RFC4364] providers three options to
>    achieve L3VPN inter-AS connection.  Both option A and B could be used
>    to connect L3VPN in VPN4DC.  This draft discusses a novel method for
>    implementing option A, to automatically configure the VRF interface
>    in order to interconnect the two segments of the end-to-end L3VPN.
>    This L3VPN interconnection automation mechanism is expected to
>    significantly reduce the VPN oriented inter-connection/service
>    provisioning time.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/l3vpn/attachments/20111024/e2f1cb0d/attachment.htm>
>
> ------------------------------
> 
--------------------------------------------------------
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 0027F6C148257937_=-- From Michael@huaweisymantec.com Fri Oct 28 11:39:50 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175AF21F84CB for ; Fri, 28 Oct 2011 11:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 cWnYGkW3g2Sk for ; Fri, 28 Oct 2011 11:39:49 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1D68B21F84CC for ; Fri, 28 Oct 2011 11:39:49 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_DwsfLEYFI5hov43+iOZ02A)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LTS00GAGH6AL7B0@hstga02-in.huaweisymantec.com> for l3vpn@ietf.org; Sat, 29 Oct 2011 02:39:47 +0800 (CST) Received: from m90003900a ([69.199.248.19]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LTS002QJH663400@hstml01-in.huaweisymantec.com> for l3vpn@ietf.org; Sat, 29 Oct 2011 02:39:46 +0800 (CST) Message-id: <26255032C8C1498E8975694322EA87CB@china.huawei.com> From: Michael Ko To: L3VPN WG mailing list References: <69A10181857544B88BF33AB1F5262DF2@china.huawei.com> Subject: Re: Discussion of VPN4DC drafts Date: Fri, 28 Oct 2011 11:39:41 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 18:39:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_DwsfLEYFI5hov43+iOZ02A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT I have uploaded a revised version of the draft. You can download it at http://tools.ietf.org/html/draft-ko-vaas-problem-statement-01 This is a replacement for the "Problem Statement for Dynamic Secure Interconnect" draft mentioned in Ben's note. VPN as a Service (VaaS) is envisioned as a way to either transition or complement existing ways of establishing VPN service between a set of sites or clients. There are some fundamental differences between VaaS and the various forms of VPN today. This draft examines the problems and challenges associated with the process of setting up secure connections between authorized network nodes which can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT. Setting up a secure connection in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, routing information exchange and connection parameters determination. I believe this draft is within the scope of VPN4DC and your feedback and comments are most welcome. Mike ----- Original Message ----- From: Ben Niven-Jenkins To: L3VPN WG mailing list Sent: Monday, October 24, 2011 4:35 PM Subject: Discussion of VPN4DC drafts Colleagues, A number of drafts related to the VPN4DC topic are now available in the Internet-Draft repository. The ones I could fine are listed below. When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was conditional on the basis that: 1) There needed to be viable -00 drafts before the cutoff. 2) The problem needed to be discussed prior to Taipei on the L3VPN list. To date there has not been much discussion of VPN4DC on the L3VPN list, possibly because folks were waiting for -00 drafts to be published. Now that a number of drafts have been published I would encourage those folks interested in the VPN4DC topic to discuss the various drafts on the L3VPN list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancelled. The VPN4DC related drafts that I could find (there may be others that I've missed) are: VPN4DC Problem Statement http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 VPN4DC Problem Statement http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 L3VPN automatical interconnection for VPN4DC http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 Requirements of Layer 3 Virtual Private Network for Data Centers http://tools.ietf.org/html/draft-so-vpn4dc-00 L3VPN Protocol Gap Analysis for Data Centers http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 Experiment of Example Solution for VPN4DC http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 End-system support for BGP-signaled IP/VPNs. http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Problem Statement for Dynamic Secure Interconnect http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 Ben --Boundary_(ID_DwsfLEYFI5hov43+iOZ02A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
I have uploaded a revised version of the draft.  You can download it at http://tools.ietf.org/html/draft-ko-vaas-problem-statement-01  This is a replacement for the "Problem Statement for Dynamic Secure Interconnect" draft mentioned in Ben's note. 
 
VPN as a Service (VaaS) is envisioned as a way to either transition or complement existing ways of establishing VPN service between a set of sites or clients.  There are some fundamental differences between VaaS and the various forms of VPN today.  This draft examines the problems and challenges associated with the process of setting up secure connections between authorized network nodes which can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT.  Setting up a secure connection in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, routing information exchange and connection parameters determination.
 
I believe this draft is within the scope of VPN4DC and your feedback and comments are most welcome.
 
Mike
----- Original Message -----
Sent: Monday, October 24, 2011 4:35 PM
Subject: Discussion of VPN4DC drafts

Colleagues,

A number of drafts related to the VPN4DC topic are now available in the Internet-Draft repository. The ones I could fine are listed below.

When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was conditional on the basis that:

1) There needed to be viable -00 drafts before the cutoff.
2) The problem needed to be discussed prior to Taipei on the L3VPN list.

To date there has not been much discussion of VPN4DC on the L3VPN list, possibly because folks were waiting for -00 drafts to be published.

Now that a number of drafts have been published I would encourage those folks interested in the VPN4DC topic to discuss the various drafts on the L3VPN list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancelled.

The VPN4DC related drafts that I could find (there may be others that I've missed) are:

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00

VPN4DC Problem Statement
http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00

L3VPN automatical interconnection for VPN4DC
http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00

Requirements of Layer 3 Virtual Private Network for Data Centers
http://tools.ietf.org/html/draft-so-vpn4dc-00

L3VPN Protocol Gap Analysis for Data Centers
http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00

Experiment of Example Solution for VPN4DC
http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00

End-system support for BGP-signaled IP/VPNs.
http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02

Problem Statement for Dynamic Secure Interconnect
http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00

Ben

--Boundary_(ID_DwsfLEYFI5hov43+iOZ02A)-- From ning.so@verizon.com Fri Oct 28 13:06:15 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2857E11E8081 for ; Fri, 28 Oct 2011 13:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 m7tgAaeMvASc for ; Fri, 28 Oct 2011 13:06:14 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id E9DB511E807F for ; Fri, 28 Oct 2011 13:06:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 28 Oct 2011 20:06:11 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.69,420,1315180800"; d="scan'208";a="168871023" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 28 Oct 2011 20:06:05 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.133]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Fri, 28 Oct 2011 16:06:04 -0400 To: "l3vpn@ietf.org" Date: Fri, 28 Oct 2011 16:06:03 -0400 Subject: Re: Re: Discussion of VPN4DC drafts Thread-Topic: Re: Discussion of VPN4DC drafts Thread-Index: AcyVqw9RHeWdBu2bQWeBgIdQbDnsIQ== Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08F88FC45@FHDP1LUMXC7V41.us.one.verizon.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-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:06:15 -0000 Derick, Thank you for clarifying it for me. Yes, I have seen network built like wh= at you described. It is indeed a valid use case. However, things gets rea= lly complicated when you throw Inter-AS into the mix. IETF works on baby s= teps with clearly and precisely defined problems. We have been given a dir= ective to define and reach consensus on a base set of problem statement. I= am afraid that the situation you are describing may be out-of-the-scope fo= r this stage, IMHO. However, it can certainly be something of interest for= the next stage. =20 Currently there are three separate problem statement drafts in VPN4DC, and = many other drafts also described some problems in detail. We would like to= summarize the problems into a common set to help define our working charte= r and scope. Luyuan will send something out next week to kick start this e= ffort. Please feel free to comment and/or voice your opinion agree or disa= gree. =20 =A0 Best regards, =A0 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =A0 Subject:=20 Message-ID: <1319517945.99929.YahooMailNeo@web161805.mail.bf1.yahoo.com> Content-Type: text/plain; charset=3D"iso-8859-1" Ning: ----- Another applicable type of environment are "-service-providers"... [Ning] Can you gave an example to help me understand it better? ----- For instance, there are SIP/VoIP providers who do not own a regional or nat= ion-wide MPLS transport network used primarily as revenue-generating L3VPN = services network (such as Verizon, ATT, etc have). ?I have seen in a number= of networks where these type of providers would purchase a DS3 or ethernet= circuit from Verizon or ATT and channelize it with PVCs or VLANs. ?Each PV= C or VLAN would correspond to ?a different L3VPN network (i.e., customer) o= n Verizon or ATT's MPLS network. ?The SIP/VoIP provider would then use Inte= r-AS Option A to connect these L3VPN networks to L3VPN networks they have b= uilt for their external customers in their data center. ?They are effective= ly extending these L3VPNs into their datacenter to attach (and customize) s= ervices to them. ?In some cases customer owned appliances are put "in the p= ath" of the customer's traffic in the provider's data center. ? There are SIP, Storage, and E-mail providers (all fairly obvious) that I am= aware of doing this. ?Less obvious are more specialized services like fina= ncial services and applications and medical applications and services. ?Loc= ally here I have run into at least one company delivering video and audio i= n this fashion for businesses that want streaming advertisements on media d= isplays. ? Of course, in order to maximize their potential customer base they connect = to multiple carriers in this way. ? The point though is that this is an example of a non-transport service-prov= ider attaching VMs and other hosts/appliances/services ultimately to custom= er L3VPNs internal to the provider's datacenter. ?There is a ?need for auto= mating the turn up of VPNs (as one of the VPN4DC drafts describe) on the PE= s facing the external transport providers with which they are running Inter= -AS option A, as well as on the PEs facing the VM hosts or virtualized appl= iances. ?Also there is a need for ?automatically building a VM or a virtual= -appliance on the fly for service to that VPN. ? Sorry if this is too verbose or not clear enough. ?Here is a partial diagra= m:?http://packetpushers.net/extending-private-networks-into-your-datacenter= /. ?Now just imagine a PE in the data center with VMs attached to it for ea= ch of the four VRFs. Derick From: "So, Ning" To: "l3vpn@ietf.org" Sent: Monday, October 24, 2011 10:50 PM Subject: RE: Re: Discussion of VPN4DC drafts Derick, Please see my comments in-line. ? Best regards, ? Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 ? Date: Mon, 24 Oct 2011 17:12:39 -0700 (PDT) From: Derick Winkworth To: Ben Niven-Jenkins ,??? L3VPN WG mailing list ??? Subject: Re: Discussion of VPN4DC drafts Message-ID: ??? <1319501559.87264.YahooMailNeo@web161802.mail.bf1.yahoo.com> Content-Type: text/plain; charset=3D"iso-8859-1" All: I think the drafts constitute a great start to addressing this gap. ? My first, perhaps superficial, observation is that much of the language is = geared towards "Service-Provider." ?I think in the context of VPNs for Data= Centers, these drafts apply equally to multi-security zone Data Centers in= non-SP networks that have multiple logically isolated network segments. ?F= or instance, multiple DMZs, server farms, storage networks, corporate LANs,= guest LANs, etc. ?These could very well all be L3VPNs in an MPLS infrastru= cture that interconnects and extends into the various data centers of an en= terprise network. ?The kind of security and transparency that the infrastru= cture provides is adequate for the purpose of passing audits (where the alt= ernative must be physical separation of network resources). ?There is certa= inly more enterprise adoption of MPLS happening in the field today for this= purpose. [Ning] Agree. Another applicable type of environment are "-service-providers" that= provide various IP enabled applications and services to the private networ= ks of external customers. ?These environments are not classic service-provi= ders because they do not own transport networks. ?They connect to multiple = carriers to have reachability to as many potential customers' private netwo= rks as possible. In this case they are extending customer's private network= s into their data centers in a secure/transparent way, similar to the descr= iption in some of the drafts for VPN4DC. [Ning] Can you gave an example to help me understand it better? I think it might be possible to generalize VPN4DC so that its inclusive of = these situations. To be clear, these scenarios involve companies who are no= t classic "service-providers" but are running their own MPLS network with P= and PE nodes and not just buying L3VPN sevices from an external provider. = ?Rather than framing everything in a "service-provider" or "enterprise" con= text, we could just frame it in general networking terms. ? [Ning] Service provider and Enterprise are meant to be generic terms, and I= agree with you that they are not good terms to fit the situation you are d= escribing.? I can certainly go back to make the term more generalized (or a= t least clearly defined in definition section).=20 I think there is a sort of Hegelian synthesis happening in the industry bet= ween service-provider and enterprise, and VPN4DC is a clear bridge between = them. [Ning] Agree.?=20 Thanks. Derick ________________________________ From: Ben Niven-Jenkins To: L3VPN WG mailing list Sent: Monday, October 24, 2011 6:35 PM Subject: Discussion of VPN4DC drafts=20 Colleagues, A number of drafts related to the VPN4DC topic are now available in the Int= ernet-Draft repository. The ones I could fine are listed below. When the L3VPN session in Taipei was scheduled to discuss VPN4DC it was con= ditional on the basis that: 1) There needed to be viable -00 drafts before the cutoff. 2) The problem needed to be discussed prior to Taipei on the L3VPN list. To date there has not been much discussion of VPN4DC on the L3VPN list, pos= sibly because folks were waiting for -00 drafts to be published. Now that a number of drafts have been published I would encourage those fol= ks interested in the VPN4DC topic to discuss the various drafts on the L3VP= N list otherwise you risk having the VPN4DC/L3VPN session in Taipei cancell= ed. The VPN4DC related drafts that I could find (there may be others that I've = missed) are: VPN4DC Problem Statement http://tools.ietf.org/html/draft-dunbar-vpn4dc-problem-statement-00 VPN4DC Problem Statement http://tools.ietf.org/html/draft-fang-vpn4dc-problem-statement-00 L3VPN automatical interconnection for VPN4DC http://tools.ietf.org/html/draft-jin-l3vpn-vpn4dc-interconnect-00 Requirements of Layer 3 Virtual Private Network for Data Centers http://tools.ietf.org/html/draft-so-vpn4dc-00 L3VPN Protocol Gap Analysis for Data Centers http://tools.ietf.org/html/draft-yong-vpn4dc-protocol-gap-analysis-00 Experiment of Example Solution for VPN4DC http://tools.ietf.org/html/draft-zeng-vpn4dc-example-solution-00 End-system support for BGP-signaled IP/VPNs. http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 Problem Statement for Dynamic Secure Interconnect http://tools.ietf.org/html/draft-ko-dsi-problem-statement-00 Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ L3VPN mailing list L3VPN@ietf.org https://www.ietf.org/mailman/listinfo/l3vpn End of L3VPN Digest, Vol 88, Issue 18 ************************************* From marshall.eubanks@gmail.com Mon Oct 31 16:56:11 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370A511E8410 for ; Mon, 31 Oct 2011 16:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.115 X-Spam-Level: X-Spam-Status: No, score=-103.115 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, 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 PSevzOP6PFcU for ; Mon, 31 Oct 2011 16:56:09 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13CAE11E83E8 for ; Mon, 31 Oct 2011 16:56:08 -0700 (PDT) Received: by qyk34 with SMTP id 34so4220241qyk.10 for ; Mon, 31 Oct 2011 16:56:08 -0700 (PDT) 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 :content-type; bh=ejLYtGtJ685Fg/fZSpIQH3puB2bRI2k59jQ/wvMsVQo=; b=fcDTtd+bvlcWhDQAQ97etdVUSRMeBm1OaZ3zLaJi5JXLpTYODHmdGUknf2VMza8PF1 Zr8scwyokM3hIIzxntJd5kOeC8xCq7/fphRdpH7djloq6NVgAiCIJJhxyNrnCue3M9/q Chr4k6hIRSsu9rGL2aukkrqXExoYJiq75aYZE= MIME-Version: 1.0 Received: by 10.182.2.164 with SMTP id 4mr3329704obv.49.1320105368499; Mon, 31 Oct 2011 16:56:08 -0700 (PDT) Received: by 10.182.14.65 with HTTP; Mon, 31 Oct 2011 16:56:08 -0700 (PDT) In-Reply-To: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> Date: Mon, 31 Oct 2011 19:56:08 -0400 Message-ID: Subject: Fwd: [vpn4dc] Question on the problem From: Marshall Eubanks To: L3VPN , Fred Baker Content-Type: multipart/alternative; boundary=f46d044519e18e349004b0a0fb9f X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:56:11 -0000 --f46d044519e18e349004b0a0fb9f Content-Type: text/plain; charset=ISO-8859-1 Forwarding for Fred Baker. ---------- Forwarded message ---------- From: Fred Baker Date: Mon, Oct 31, 2011 at 8:58 AM Subject: [vpn4dc] Question on the problem To: vpn4dc@ietf.org I have started reading the vpn4dc drafts, and especially the problem statements, and find myself scratching my head. Starting with the title "VPN for Data Center", I really wonder if the topic is starting from a proposed solution before settling on a problem. Let me ramble a bit, and then tell me I'm wrong. It seems to me that your primary issue is that you have a set of hosts that want to communicate with each other securely. These hosts might be physical or virtual, and might be in the same data center or in different data centers. The important thing is that they be able to authenticate communications with each other, and then do things that they are authorized to do based on those communications. The things that they do might differ. Within one community, the hosts might all be peers accomplishing the job of the cloud, whatever that is - order processing, content delivery, take your pick. Within another community, the issue might be the management of virtual machines, and you might have a relatively small number of control systems that talk with a large number of client machines. The term "VPN" implies to me that you have chosen a solution. It might be an MPLS VPN, which is to say that you have transport but depend on higher layer services for encryption, authentication, and authorization. In IPsec, "VPN" the term "VPN" generally refers to the tunnel mode, and is a way of overlaying one network on another. In the case, that doesn't make a lot of sense to me in this context - You don't appear to be overlaying networks per se, merely making sure that messages you receive and process are from trusted peers. If the primary issue is one of trust, we could discuss TLS, https (if the only application protocol is a web protocol), or IPsec's transport mode. In any of those, the issue is largely one of key distribution, and the use of those keys for encryption and authentication to manage communications among a set of communicating entities. What am I missing? What makes this specifically a Virtual Private Network? Why is this not a key distribution problem based on existing technologies? _______________________________________________ vpn4dc mailing list vpn4dc@ietf.org https://www.ietf.org/mailman/listinfo/vpn4dc --f46d044519e18e349004b0a0fb9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Forwarding for Fred Baker.

---------- For= warded message ----------
From: Fred Baker= <fred@cisco.com= >
Date: Mon, Oct 31, 2011 at 8:58 AM
Subject: [vpn4dc] Question on the pro= blem
To: vpn4dc@ietf.org

<= br>I have started reading the vpn4dc drafts, and especially the problem sta= tements, and find myself scratching my head. Starting with the title "= VPN for Data Center", I really wonder if the topic is starting from a = proposed solution before settling on a problem.

Let me ramble a bit, and then tell me I'm wrong.

It seems to me that your primary issue is that you have a set of hosts that= want to communicate with each other securely. These hosts might be physica= l or virtual, and might be in the same data center or in different data cen= ters. The important thing is that they be able to authenticate communicatio= ns with each other, and then do things that they are authorized to do based= on those communications. The things that they do might differ. Within one = community, the hosts might all be peers accomplishing the job of the cloud,= whatever that is - order processing, content delivery, take your pick. Wit= hin another community, the issue might be the management of virtual machine= s, and you might have a relatively small number of control systems that tal= k with a large number of client machines.

The term "VPN" implies to me that you have chosen a solution. It = might be an MPLS VPN, which is to say that you have transport but depend on= higher layer services for encryption, authentication, and authorization. I= n IPsec, "VPN" the term "VPN" generally refers to the t= unnel mode, and is a way of overlaying one network on another. In the case,= that doesn't make a lot of sense to me in this context - You don't= appear to be overlaying networks per se, merely making sure that messages = you receive and process are from trusted peers.

If the primary issue is one of trust, we could discuss TLS, https (if the o= nly application protocol is a web protocol), or IPsec's transport mode.= In any of those, the issue is largely one of key distribution, and the use= of those keys for encryption and authentication to manage communications a= mong a set of communicating entities.

What am I missing? What makes this specifically a Virtual Private Network? = Why is this not a key distribution problem based on existing technologies?<= br> _______________________________________________
vpn4dc mailing list
vpn4dc@ietf.org
= https://www.ietf.org/mailman/listinfo/vpn4dc

--f46d044519e18e349004b0a0fb9f-- From lufang@cisco.com Mon Oct 31 21:54:25 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D5921F8C29 for ; Mon, 31 Oct 2011 21:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.118 X-Spam-Level: X-Spam-Status: No, score=-4.118 tagged_above=-999 required=5 tests=[AWL=1.880, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LsrPh7LbpPEj for ; Mon, 31 Oct 2011 21:54:22 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8EF1F0C3C for ; Mon, 31 Oct 2011 21:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=17474; q=dns/txt; s=iport; t=1320123262; x=1321332862; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Tq0Ju1IXIrqe27RWUSCchItjMC2rZ3NrKiFvOshq7FU=; b=K6CQD4/yc93GMfu8GJ7/W1P+PME7tjWlLY+AW/zpRTn/dyEYj0JqLdwy mOgL9jR/bBvaW3nUyDh//cr3KS+wYjLJTtaChW33lZs3ULFBrnrSOaatS YtcRtPtqtZbQV7HdsajWaBjBo/W1zuRVrd79QwYsb8IQThxB40HTXLl2Z 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0AANx6r06tJXG+/2dsb2JhbABDgk2XFo9UgQWBcgEBAQEDAQEBDwEJEQM+GwIBCBEDAQEBCwYXAQYBJh8JCAEBBAESCAwHB4dolgMBnj0EiCFhBIgGkT+MRw X-IronPort-AV: E=Sophos;i="4.69,436,1315180800"; d="scan'208,217";a="32383819" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 01 Nov 2011 04:54:21 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA14sL5F021539; Tue, 1 Nov 2011 04:54:21 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); Mon, 31 Oct 2011 23:54:20 -0500 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_01CC9852.513A9458" Subject: RE: [vpn4dc] Question on the problem Date: Mon, 31 Oct 2011 23:54:17 -0500 Message-ID: <238542D917511A45B6B8AA806E875E250732068F@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [vpn4dc] Question on the problem Thread-Index: AcyYKLWVq2EvAiTXRXmySAHaz7vjKAAH60uw References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> From: "Luyuan Fang (lufang)" To: "Marshall Eubanks" , "L3VPN" , "Fred Baker (fred)" X-OriginalArrivalTime: 01 Nov 2011 04:54:20.0711 (UTC) FILETIME=[51636370:01CC9852] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 04:54:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9852.513A9458 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fred, =20 Thanks a lot for the discussion. =20 You are right about the DC host to host communication. Now we need to get clear on the 'securely' thing.=20 =20 Here is background of the vpn4dc initiative: SPs already have large VPN deployment, they are moving fast on providing scalable cloud services. The MPLS VPN typically ends at PEs, not reaching to hosts/end systems. The provisioning is segmented (SP network segment, SP DC segment, Enterprise segment, content provider segment), and today they are often facing long service turning up time. - this is the practical problems Ning first presented to us.=20 =20 After a couple of months study, we decided we would not be able to solve everything for the end-to-end provisioning in one effort, but we could possibly solve the host-to-host layer 3 - ip or mpls, vpn connectivity problems in one initiative - vpn4dc. Why vpn? because they are existing services, one of the most widely deployed features over the last 12 years. Enterprise customers are asking SPs to extend the vpns to the end systems. =20 We know that MPLS/BGP VPN or other IP tunneling mechanisms provide routing isolation, not encryption. Many folks consider the routing isolation provides certain degree of security, good enough for them, while others think security means encryption. We are not going to enter that debate here. =20 Our intention is to focus on the vpn connectivity issues, not cryptography techniques, nor key distribution/key management, we will leave these to the Security Area. =20 =20 Let me send next mail to get more feedbacks from all. =20 Thanks, Luyuan =20 From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Marshall Eubanks Sent: Monday, October 31, 2011 7:56 PM To: L3VPN; Fred Baker (fred) Subject: Fwd: [vpn4dc] Question on the problem =20 Forwarding for Fred Baker. ---------- Forwarded message ---------- From: Fred Baker Date: Mon, Oct 31, 2011 at 8:58 AM Subject: [vpn4dc] Question on the problem To: vpn4dc@ietf.org I have started reading the vpn4dc drafts, and especially the problem statements, and find myself scratching my head. Starting with the title "VPN for Data Center", I really wonder if the topic is starting from a proposed solution before settling on a problem. Let me ramble a bit, and then tell me I'm wrong. It seems to me that your primary issue is that you have a set of hosts that want to communicate with each other securely. These hosts might be physical or virtual, and might be in the same data center or in different data centers. The important thing is that they be able to authenticate communications with each other, and then do things that they are authorized to do based on those communications. The things that they do might differ. Within one community, the hosts might all be peers accomplishing the job of the cloud, whatever that is - order processing, content delivery, take your pick. Within another community, the issue might be the management of virtual machines, and you might have a relatively small number of control systems that talk with a large number of client machines. The term "VPN" implies to me that you have chosen a solution. It might be an MPLS VPN, which is to say that you have transport but depend on higher layer services for encryption, authentication, and authorization. In IPsec, "VPN" the term "VPN" generally refers to the tunnel mode, and is a way of overlaying one network on another. In the case, that doesn't make a lot of sense to me in this context - You don't appear to be overlaying networks per se, merely making sure that messages you receive and process are from trusted peers. If the primary issue is one of trust, we could discuss TLS, https (if the only application protocol is a web protocol), or IPsec's transport mode. In any of those, the issue is largely one of key distribution, and the use of those keys for encryption and authentication to manage communications among a set of communicating entities. What am I missing? What makes this specifically a Virtual Private Network? Why is this not a key distribution problem based on existing technologies? _______________________________________________ vpn4dc mailing list vpn4dc@ietf.org https://www.ietf.org/mailman/listinfo/vpn4dc =20 ------_=_NextPart_001_01CC9852.513A9458 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Fred,

 

Thanks a lot for the discussion.

 

You are right about the DC host to host communication. = Now we need to get clear on the ‘securely’ thing. =

 

Here is background of the vpn4dc initiative:  SPs = already have large VPN deployment, they are moving fast on providing scalable = cloud services. The MPLS VPN typically ends at PEs, not reaching to hosts/end systems. The provisioning is segmented (SP network segment, SP DC = segment, Enterprise segment, content provider segment), and today they are often = facing long service turning up time. – this is the practical problems Ning = first presented to us.

 

After a couple of months study, we decided we would not = be able to solve everything for the end-to-end provisioning in one effort, but = we could possibly solve the  host-to-host layer 3 - ip or mpls, vpn = connectivity problems in one initiative – vpn4dc. Why vpn? because they are existing = services, one of the most widely deployed features over the last 12 years. Enterprise = customers are asking SPs to extend the vpns to the end = systems.

 

We know that MPLS/BGP VPN or other IP tunneling = mechanisms provide routing isolation, not encryption. Many folks consider the routing = isolation provides certain degree of security, good enough for them, while others = think security means  encryption. We are not going to enter that debate = here.

 

Our intention is to focus on the vpn connectivity issues, = not cryptography techniques, nor key distribution/key management, we will = leave these to the Security Area.  

 

Let me send next mail to get more feedbacks from = all.

 

Thanks,

Luyuan

 

From:= l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of = Marshall Eubanks
Sent: Monday, October 31, 2011 7:56 PM
To: L3VPN; Fred Baker (fred)
Subject: Fwd: [vpn4dc] Question on the = problem

 

Forwarding for Fred = Baker.

---------- Forwarded message ----------
From: Fred Baker <fred@cisco.com>
Date: Mon, Oct 31, 2011 at 8:58 AM
Subject: [vpn4dc] Question on the problem
To: vpn4dc@ietf.org


I have started reading the vpn4dc drafts, and especially the problem statements, and find myself scratching my head. Starting with the title "VPN for Data Center", I really wonder if the topic is = starting from a proposed solution before settling on a problem.

Let me ramble a bit, and then tell me I'm wrong.

It seems to me that your primary issue is that you have a set of hosts = that want to communicate with each other securely. These hosts might be = physical or virtual, and might be in the same data center or in different data = centers. The important thing is that they be able to authenticate communications with = each other, and then do things that they are authorized to do based on those communications. The things that they do might differ. Within one = community, the hosts might all be peers accomplishing the job of the cloud, whatever = that is - order processing, content delivery, take your pick. Within another = community, the issue might be the management of virtual machines, and you might = have a relatively small number of control systems that talk with a large number = of client machines.

The term "VPN" implies to me that you have chosen a solution. = It might be an MPLS VPN, which is to say that you have transport but depend = on higher layer services for encryption, authentication, and authorization. = In IPsec, "VPN" the term "VPN" generally refers to the = tunnel mode, and is a way of overlaying one network on another. In the case, = that doesn't make a lot of sense to me in this context - You don't appear to = be overlaying networks per se, merely making sure that messages you receive = and process are from trusted peers.

If the primary issue is one of trust, we could discuss TLS, https (if = the only application protocol is a web protocol), or IPsec's transport mode. In = any of those, the issue is largely one of key distribution, and the use of = those keys for encryption and authentication to manage communications among a set = of communicating entities.

What am I missing? What makes this specifically a Virtual Private = Network? Why is this not a key distribution problem based on existing = technologies?
_______________________________________________
vpn4dc mailing list
vpn4dc@ietf.org
https://www.ietf.org/mailman/listinfo/vpn4dc

 

------_=_NextPart_001_01CC9852.513A9458-- From lufang@cisco.com Mon Oct 31 22:06:10 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26951F0C60 for ; Mon, 31 Oct 2011 22:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 tagged_above=-999 required=5 tests=[AWL=1.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wXFNxMoVhtJp for ; Mon, 31 Oct 2011 22:06:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 502B61F0C5F for ; Mon, 31 Oct 2011 22:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=8475; q=dns/txt; s=iport; t=1320123969; x=1321333569; h=mime-version:subject:date:message-id:from:to; bh=n3+eh+FuFaCPI6PnrVDQcCc0nyrNqyjKsp16Hvm7ZYQ=; b=brWSxG5WUxz9drVhjNm0Qw/g1Wo8zHrxjjpyzvPy2CKzuLNK5ujHjfNf sTbOKkat6RhVNTLMdori6DbKssziXTmMsxri3sjQ1DAkR2osI0eveIq4q gYr17dlhMAR6mvkZDwNnR7hJ/jTkDUqTkz5LeoFi8LVr6eY6PfR8tDPIO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEJ9r06tJV2Z/2dsb2JhbABDgk2maoEFgXQBAQMSAQkRA1sBKgYYB1cBBBsMDpxDgSYBnkKIIWEEiAaRP4xH X-IronPort-AV: E=Sophos;i="4.69,436,1315180800"; d="scan'208,217";a="32395940" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 01 Nov 2011 05:05:51 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA155pEH021877 for ; Tue, 1 Nov 2011 05:05:51 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); Tue, 1 Nov 2011 00:05:50 -0500 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_01CC9853.ECB8689C" Subject: vpn4dc Q&A Date: Tue, 1 Nov 2011 00:05:49 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: vpn4dc Q&A Thread-Index: AcyYU+vgQoLx0mxOTaeB3XO3f4OVpg== From: "Luyuan Fang (lufang)" To: "L3VPN" X-OriginalArrivalTime: 01 Nov 2011 05:05:50.0902 (UTC) FILETIME=[ECC62D60:01CC9853] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 05:06:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9853.ECB8689C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 There are a few things around vpn4dc I'd like to kick off the discussion. I put my simple answers to each question, very much like to hear yours. =20 1 What are we trying to achieve in vpn4dc?=20 - DC Host-to-host connectivity through layer 3 signaling protocols. These hosts can be in SP DC, Enterprise DC, content provider's DC, any DC... The connection can be in the same DC, or different DCs within any admin domains. =20 2. What cannot be achieved through L3VPN today? - We don't have a stds way for host-to-host vpn connectivity through protocols signaling which easily work in DC.=20 - BGP/MPLS VPN is extremely successful in network environment. But it is normally not accepted in the computing community. I had discussion with folks working on DC directly or indirectly, including Google, Yahoo, Facebook, VZ, AT&T, CenturyLink, T-Systems, ... many folks think layer 3 is a scalable approach, but no BGP/MPLS VPN inside DC, into host... so we need to bridge the gap. - And this is no long SP provisioned vpns, it has wider scope. =20 3. What is missing? The missing piece is the segment in DC and inter-connection/auto-mapping of the DC segment to the network segment. =20 4. Is this IETF problem? - Yes. It is about IP protocols for establish connectivity. =20 5. Who wants this?=20 Please speak out if you do. =20 6. What are not in scope for this initiative/charter? - L2VPN for DC connectivity - that goes to L2VPN WG - Encryption, key management, new authentication protocols - these go to Security Area. - Multicast - the mcast use in DC need to be further studied. We like to start without mcast to make things simpler, be able to move. =20 Looking forward seeing your comments to any of the questions. =20 Thanks, Luyuan =20 =20 ------_=_NextPart_001_01CC9853.ECB8689C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

There are a few things around vpn4dc I’d like = to kick off the discussion.

I put my simple answers to each question, very much = like to hear yours.

 

1 What are we trying to achieve in vpn4dc? =

-          DC Host-to-host connectivity through layer 3 = signaling protocols.

       These hosts = can be in SP DC, Enterprise DC, content provider’s DC, any DC… The = connection can be in the same DC, or different DCs within any admin = domains.

 

2. What cannot be achieved through L3VPN = today?

        - We = don’t have a stds way for host-to-host vpn connectivity through protocols signaling = which easily work in DC.

       - BGP/MPLS VPN = is extremely successful in network environment. But it is normally not = accepted in the computing community. I had discussion with folks working on DC = directly or indirectly, including  Google, Yahoo, Facebook, VZ, AT&T, CenturyLink, = T-Systems, … many folks think layer 3 is a scalable approach, but no BGP/MPLS VPN = inside DC, into host… so we need to bridge the gap.

      - And this is no = long SP provisioned vpns, it has wider scope.

 

3. What is missing?

     The missing piece is the = segment in DC and inter-connection/auto-mapping of the DC segment to the network = segment.

 

4. Is this IETF problem?

- Yes. It is about IP protocols for establish = connectivity.

 

5. Who wants this?

    Please speak out if you = do.

 

6. What are not in scope for this = initiative/charter?

- L2VPN for DC connectivity – that goes to = L2VPN WG

- Encryption, key management, new authentication = protocols – these go to Security Area.

- Multicast – the mcast use in DC need to be = further studied. We like to start without mcast to make things simpler, be able = to move.

 

Looking forward seeing  your comments to any = of the questions.

 

Thanks,

Luyuan

 

 

------_=_NextPart_001_01CC9853.ECB8689C--