From lizhong.jin@zte.com.cn Tue Nov 1 01:15: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 C366921F8FFF for ; Tue, 1 Nov 2011 01:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 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_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 7BrwxdM2TTdH for ; Tue, 1 Nov 2011 01:15:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 973F321F9000 for ; Tue, 1 Nov 2011 01:15:34 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 41713870512105; Tue, 1 Nov 2011 16:11:37 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 20387.2043576882; Tue, 1 Nov 2011 16:15:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pA18F03H058640; Tue, 1 Nov 2011 16:15:00 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: lufang@cisco.com Subject: Re: vpn4dc Q&A MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: lizhong.jin@zte.com.cn Date: Tue, 1 Nov 2011 16:14:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-01 16:15:02, Serialize complete at 2011-11-01 16:15:02 Content-Type: multipart/alternative; boundary="=_alternative 002D51984825793B_=" X-MAIL: mse01.zte.com.cn pA18F03H058640 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, 01 Nov 2011 08:15:39 -0000 This is a multipart message in MIME format. --=_alternative 002D51984825793B_= Content-Type: text/plain; charset="US-ASCII" Hi Luyuan, Thanks for initiating this discussion. Please see my comments in line. Regards Lizhong > ------------------------------ > > Message: 3 > Date: Tue, 1 Nov 2011 00:05:49 -0500 > From: "Luyuan Fang (lufang)" > To: "L3VPN" > Subject: vpn4dc Q&A > Message-ID: > <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> > Content-Type: text/plain; charset="us-ascii" > > 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. > [Lizhong] I try to suggest to change "host-to-host connectivity" to "host connectivity". Host-to-host is a bit easy to misunderstand with point-to-point or end-to-end, while L3VPN will provide multipoint-to-multipoint IP connection for hosts. > > > 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. [Lizhong] agree, and I think VPN4DC does not intend to achieve host connectivity only by L3VPN, and L3VPN is only deployed in some network segment, e.g, provider's network, part of DC network. L3VPN is not always BGP/MPLS VPN based, VRF-lite can also be deployed in DC network. > > > > 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. [Lizhong] I am not clear with the missing piece of segment in DC. I think VPN segment in DC is mixed with L2&L3 VPN. And I agree inter-connection/auto-mapping is the missing piece. > > > > 4. Is this IETF problem? > > - Yes. It is about IP protocols for establish connectivity. [Lizhong] agree. > > > > 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 > > > > -------------------------------------------------------- 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 002D51984825793B_= Content-Type: text/html; charset="US-ASCII"
Hi Luyuan,
Thanks for initiating this discussion. Please see my comments in line.

Regards
Lizhong



> ------------------------------
>
> Message: 3
> Date: Tue, 1 Nov 2011 00:05:49 -0500
> From: "Luyuan Fang (lufang)" <lufang@cisco.com>
> To: "L3VPN" <l3vpn@ietf.org>
> Subject: vpn4dc Q&A
> Message-ID:
>    <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com>
> Content-Type: text/plain; charset="us-ascii"
>
> 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.
>
[Lizhong] I try to suggest to change "host-to-host connectivity" to "host connectivity". Host-to-host is a bit easy to misunderstand with point-to-point or end-to-end, while L3VPN will provide multipoint-to-multipoint IP connection for hosts.

>  
>
> 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.
[Lizhong] agree, and I think VPN4DC does not intend to achieve host connectivity only by L3VPN, and L3VPN is only deployed in some network segment, e.g, provider's network, part of DC network. L3VPN is not always BGP/MPLS VPN based, VRF-lite can also be deployed in DC network.

>
>  
>
> 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.
[Lizhong] I am not clear with the missing piece of segment in DC. I think VPN segment in DC is mixed with L2&L3 VPN. And I agree inter-connection/auto-mapping is the missing piece.

>
>  
>
> 4. Is this IETF problem?
>
> - Yes. It is about IP protocols for establish connectivity.
[Lizhong] agree.

>
>  
>
> 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
>
>  
>
>  
--------------------------------------------------------
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 002D51984825793B_=-- From robert@raszuk.net Tue Nov 1 05:03: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 BA31821F907B for ; Tue, 1 Nov 2011 05:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 HIkMkUKb2CMF for ; Tue, 1 Nov 2011 05:03:22 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id B765A21F9007 for ; Tue, 1 Nov 2011 05:03:21 -0700 (PDT) Received: (qmail 7987 invoked by uid 399); 1 Nov 2011 12:03:20 -0000 Received: from unknown (HELO ?216.69.73.165?) (216.69.73.165) by mail37.opentransfer.com with SMTP; 1 Nov 2011 12:03:20 -0000 Message-ID: <4EAFE005.7080702@raszuk.net> Date: Tue, 01 Nov 2011 13:03:17 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Fred Baker Subject: Re: Fwd: [vpn4dc] Question on the problem References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN , vpn4dc@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, 01 Nov 2011 12:03:23 -0000 Hi Fred, In the light of your below message it would be very interesting to hear your point of view on IPSec like "VPN as a Service" approach with provider's neutral auto-discovery service ? It seems that it can address L2VPN, L3VPN as well as VPN4DC set of requirements in a much more general way. Problem statement has been described in: http://tools.ietf.org/html/draft-ko-vaas-problem-statement-01 Thx, R. > 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 > From robert@raszuk.net Tue Nov 1 05:16: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 3B5F811E8143 for ; Tue, 1 Nov 2011 05:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsJ+AO6dc9XC for ; Tue, 1 Nov 2011 05:16:35 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 40B0611E810E for ; Tue, 1 Nov 2011 05:16:35 -0700 (PDT) Received: (qmail 13476 invoked by uid 399); 1 Nov 2011 12:16:34 -0000 Received: from unknown (HELO ?216.69.73.165?) (216.69.73.165) by mail37.opentransfer.com with SMTP; 1 Nov 2011 12:16:34 -0000 Message-ID: <4EAFE320.2040603@raszuk.net> Date: Tue, 01 Nov 2011 13:16:32 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Luyuan Fang (lufang)" Subject: Re: [vpn4dc] Question on the problem References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <238542D917511A45B6B8AA806E875E250732068F@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E250732068F@XMB-RCD-201.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN , "Fred Baker \(fred\)" 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, 01 Nov 2011 12:16:36 -0000 Hi Luyuan, I think the time has come to allow customers freedom to choose how they are going to interconnect their DC sites without relaying and being locked to the same service provider they have used for the last 12 years to deliver their VPN connectivity. By such decoupling they are free to choose arbitrary data center physical or virtual location without worrying that their SP does not have a presence in the DC proximity. In particular if I am interested to secure my on demand public cloud resources I would hardly be able to accomplish that by current VPN static connectivity model. It really needs to be local provider independent, on demand dynamic secure discovery service. Thx, R. > 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 > 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 > > > > From robert@raszuk.net Tue Nov 1 05:30: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 6C3BB11E84F1 for ; Tue, 1 Nov 2011 05:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=-0.525, 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 J+FQQoKFVQcT for ; Tue, 1 Nov 2011 05:30:38 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id D9DB111E8212 for ; Tue, 1 Nov 2011 05:30:35 -0700 (PDT) Received: (qmail 18893 invoked by uid 399); 1 Nov 2011 12:30:34 -0000 Received: from unknown (HELO ?216.69.73.165?) (216.69.73.165) by mail37.opentransfer.com with SMTP; 1 Nov 2011 12:30:34 -0000 Message-ID: <4EAFE66A.90004@raszuk.net> Date: Tue, 01 Nov 2011 13:30:34 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Luyuan Fang (lufang)" Subject: Re: vpn4dc Q&A References: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN 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, 01 Nov 2011 12:30:39 -0000 Hi Luyuan, > 1 What are we trying to achieve in vpn4dc? > > - DC Host-to-host connectivity through layer 3 signaling > protocols. I think before we start talking about signalling we need to seriously discuss auto-discovery. Static model of manual provisioning of VPN sites will not address DC host to host connectivity requirements. > 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. L3VPNs were indeed successful to interconnect static VPN sites. L3VPNs however hardly fit the model of interconnection of hosts or mobile devices like smartphones to be part of same VPN. The reason is that site discovery does not exits in L3VPN. The L3VPN discovery is limited to SP network among SP provisioned sites. That is not sufficient to the set of requirements at hand. > 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. One could argue if that is at all required. It is only required to add DC to traditional L3VPNs or statically build VPNs between VMs residing on hosts owned by given customer. I do not think that this accurately reflects the customers flexible computing requirements of today. > 4. Is this IETF problem? > > - Yes. It is about IP protocols for establish connectivity. Agreed. > 5. Who wants this? > > Please speak out if you do. I think we need more that this. I want to be able to access VPN resources on demand both in the sites of my company as well as in their both private and public data centers. And this is all from android or iphone regardless if I am at home or in the plane. I also need to be able to dynamically shop of computing resources among public clouds when I encounter increased processing demands. > 6. What are not in scope for this initiative/charter? > > - L2VPN for DC connectivity - that goes to L2VPN WG I do not think we need to have different solutions to different types of VPNs. If you think about the problem space it should be one button to switch from L3VPN to L2VPN and not a different IETF WG. > - Encryption, key management, new authentication protocols - these go to > Security Area. Disagree. > - 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. I agree. Thx, R. From ccie15672@yahoo.com Tue Nov 1 07:42:51 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 859E511E8137 for ; Tue, 1 Nov 2011 07:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_40=-0.185, 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 8KVRWzNISXur for ; Tue, 1 Nov 2011 07:42:50 -0700 (PDT) Received: from nm22-vm0.bullet.mail.bf1.yahoo.com (nm22-vm0.bullet.mail.bf1.yahoo.com [98.139.212.126]) by ietfa.amsl.com (Postfix) with SMTP id 1144511E812E for ; Tue, 1 Nov 2011 07:42:49 -0700 (PDT) Received: from [98.139.212.146] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2011 14:42:40 -0000 Received: from [98.139.212.232] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2011 14:42:40 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 01 Nov 2011 14:42:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 939125.23232.bm@omp1041.mail.bf1.yahoo.com Received: (qmail 93364 invoked by uid 60001); 1 Nov 2011 14:42:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1320158560; bh=29xWtr6y228VEpR0KgLyT+RcVLAFpMVbT3dOIUo0MA4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ojDHsqAkIRnflwHyxxwOctwI9Fu2zgvMe6mDaNHpgr/m6KfpckRTG2wY39pKwIs6xj9l2Z4EYlR8l6QbH7RUC1bhtOLy8+VUL0AxH0Nw7lW1U8oJ6cUssI+/Cg4/l8kNpa4KwmfKr1X9MF2MgbWE/awHlw5uO9gsrjtGlOgUcKc= 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=S0c2NOPNBY88cKR2gKZmI4HoEXEVCLI05KXu0KSY0CJ0BUGp2X8xQ9+GL7YQEihHeVCIVCI7Nuke0/4mMHkQqQWql8y+DOCCHBDKH9Ko4dgdrqUxVcwcIKKgTQvk7AQ9ptytz66Pks4z/xBTzNeq3DhvXajKV1zI1dxkpRGPgSA=; X-YMail-OSG: Is2AZsEVM1nLUPq6zAhqcdEj0eCphySQ2sh3hl45G0HzqDL lHDpSIldXwmv20JiVT6pv43xQUlLtAUGoNoKpTMIgzzPl28iRH7drjFSDxGt mTNd3KtcF35T314NyBj6JwCmTvergANNO45cSrC.yhaJYwxqCAAPC1PJa9ED 4DZAwkio0QzriVc3BRXobb0a2P56p6p3rouMS3OlBzovSTXHdpnqSCjFzMwn KmqqfWv4LuQA5eCQjOJ5C5f5C6cnCyjuq8UFdVgVrqKpQwxebL0QGPznP4xf 07bLfjgB9LfxWGPPb8DXWtN9K76ns8zoCpN.ca3T56kbTNE0r4ubxSX.1gAN uQ0Cx7nh4iOMsNj0z_1fpm6NLctVu0SYQJoWw4QCrE5bhBWGna0e_0Lbz3pd rzPQfcUxPrYpzKnOYWNR10M2dlOM6ig4O7IR77dYLXFU6ShAcH_JG5k2Weva lcqiVCg-- Received: from [76.194.43.66] by web161801.mail.bf1.yahoo.com via HTTP; Tue, 01 Nov 2011 07:42:40 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <238542D917511A45B6B8AA806E875E250732068F@XMB-RCD-201.cisco.com> Message-ID: <1320158560.90199.YahooMailNeo@web161801.mail.bf1.yahoo.com> Date: Tue, 1 Nov 2011 07:42:40 -0700 (PDT) From: Derick Winkworth Subject: Re: [vpn4dc] Question on the problem To: "Luyuan Fang \(lufang\)" , Marshall Eubanks , L3VPN , "Fred Baker \(fred\)" In-Reply-To: <238542D917511A45B6B8AA806E875E250732068F@XMB-RCD-201.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1882999342-136880922-1320158560=:90199" 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, 01 Nov 2011 14:42:51 -0000 --1882999342-136880922-1320158560=:90199 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All:=0A=0AI, too, agree that the "host-to-host" term is confusing. =C2=A0It= s not about host-to-host. =C2=A0Its about putting VMs (or other hosts) "int= o" an existing L3VPN natively. =C2=A0They could have IP addresses chosen by= the L3VPN customer, for instance. =C2=A0We should be able to turn up a VM = and drop it into an L3VPN without installing software or performing configu= ration on the VM itself.=0A=0AIf the L3VPN does not already exist in the da= ta center where the VM host resides, how can we automate the provisioning o= f the VRFs, and then automate the attachment of the VM to that VRF? =C2=A0M= anually configuring all of that can be extremely tedious. =C2=A0Orchestrati= on tools that interface with disparate APIs aren't doing the job well.=0A= =0ADerick=0A=0A________________________________=0AFrom: Luyuan Fang (lufang= ) =0ATo: Marshall Eubanks ; L= 3VPN ; Fred Baker (fred) =0ASent: Monday, O= ctober 31, 2011 11:54 PM=0ASubject: RE: [vpn4dc] Question on the problem=0A= =0A=0A =0AHi Fred,=0A=C2=A0=0AThanks a lot for the discussion.=0A=C2=A0=0AY= ou are right about the DC host to host communication. Now we=0Aneed to get = clear on the =E2=80=98securely=E2=80=99 thing. =0A=C2=A0=0AHere is backgrou= nd of the vpn4dc initiative: =C2=A0SPs already=0Ahave large VPN deployment,= they are moving fast on providing scalable cloud=0Aservices. The MPLS VPN = typically ends at PEs, not reaching to hosts/end=0Asystems. The provisionin= g is segmented (SP network segment, SP DC segment,=0AEnterprise segment, co= ntent provider segment), and today they are often facing long=0Aservice tur= ning up time. =E2=80=93 this is the practical problems Ning first=0Apresent= ed to us. =0A=C2=A0=0AAfter a couple of months study, we decided we would n= ot be able=0Ato solve everything for the end-to-end provisioning in one eff= ort, but we could=0Apossibly solve the =C2=A0host-to-host layer 3 - ip or m= pls, vpn connectivity problems=0Ain one initiative =E2=80=93 vpn4dc. Why vp= n? because they are existing services, one=0Aof the most widely deployed fe= atures over the last 12 years. Enterprise customers=0Aare asking SPs to ext= end the vpns to the end systems.=0A=C2=A0=0AWe know that MPLS/BGP VPN or ot= her IP tunneling mechanisms provide=0Arouting isolation, not encryption. Ma= ny folks consider the routing isolation=0Aprovides certain degree of securi= ty, good enough for them, while others think security=0Ameans =C2=A0encrypt= ion. We are not going to enter that debate here.=0A=C2=A0=0AOur intention i= s to focus on the vpn connectivity issues, not=0Acryptography techniques, n= or key distribution/key management, we will leave=0Athese to the Security A= rea. =C2=A0=0A=C2=A0=0ALet me send next mail to get more feedbacks from all= .=0A=C2=A0=0AThanks,=0ALuyuan=0A=C2=A0=0AFrom:l3vpn-bounces@ietf.org [mailt= o:l3vpn-bounces@ietf.org] On Behalf Of Marshall=0AEubanks=0ASent: Monday, O= ctober 31, 2011 7:56 PM=0ATo: L3VPN; Fred Baker (fred)=0ASubject: Fwd: [vpn= 4dc] Question on the problem=0A=C2=A0=0AForwarding for Fred Baker.=0A------= ---- Forwarded message ----------=0AFrom: Fred Baker =0ADat= e: Mon, Oct 31, 2011 at 8:58 AM=0ASubject: [vpn4dc] Question on the problem= =0ATo: vpn4dc@ietf.org=0A=0A=0AI have started reading the vpn4dc drafts, an= d especially the problem=0Astatements, and find myself scratching my head. = Starting with the title=0A"VPN for Data Center", I really wonder if the top= ic is starting from=0Aa proposed solution before settling on a problem.=0A= =0ALet me ramble a bit, and then tell me I'm wrong.=0A=0AIt seems to me tha= t your primary issue is that you have a set of hosts that=0Awant to communi= cate with each other securely. These hosts might be physical or=0Avirtual, = and might be in the same data center or in different data centers. The=0Aim= portant thing is that they be able to authenticate communications with each= =0Aother, and then do things that they are authorized to do based on those= =0Acommunications. The things that they do might differ. Within one communi= ty, the=0Ahosts might all be peers accomplishing the job of the cloud, what= ever that is -=0Aorder processing, content delivery, take your pick. Within= another community,=0Athe issue might be the management of virtual machines= , and you might have a=0Arelatively small number of control systems that ta= lk with a large number of=0Aclient machines.=0A=0AThe term "VPN" implies to= me that you have chosen a solution. It=0Amight be an MPLS VPN, which is to= say that you have transport but depend on=0Ahigher layer services for encr= yption, authentication, and authorization. In=0AIPsec, "VPN" the term "VPN"= generally refers to the tunnel=0Amode, and is a way of overlaying one netw= ork on another. In the case, that=0Adoesn't make a lot of sense to me in th= is context - You don't appear to be=0Aoverlaying networks per se, merely ma= king sure that messages you receive and=0Aprocess are from trusted peers.= =0A=0AIf the primary issue is one of trust, we could discuss TLS, https (if= the only=0Aapplication protocol is a web protocol), or IPsec's transport m= ode. In any of=0Athose, the issue is largely one of key distribution, and t= he use of those keys=0Afor encryption and authentication to manage communic= ations among a set of=0Acommunicating entities.=0A=0AWhat am I missing? Wha= t makes this specifically a Virtual Private Network? Why=0Ais this not a ke= y distribution problem based on existing technologies?=0A__________________= _____________________________=0Avpn4dc mailing list=0Avpn4dc@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/vpn4dc --1882999342-136880922-1320158560=:90199 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
All:

I, too, agree that the "host-to-host" term is confusing.  Its not a= bout host-to-host.  Its about putting VMs (or other hosts) "into" an e= xisting L3VPN natively.  They could have IP addresses chosen by the L3= VPN customer, for instance.  We should be able to turn up a VM and dro= p it into an L3VPN without installing software or performing configuration = on the VM itself.

If the L3VPN does not already ex= ist in the data center where the VM host resides, how can we automate the p= rovisioning of the VRFs, and then automate the attachment of the VM to that= VRF?  Manually configuring all of that can be extremely tedious. &nbs= p;Orchestration tools that interface with disparate APIs aren't doing the j= ob well.

Derick
From: Luyuan Fang (lufang) <lufang@cisco.com>
To: Marshall Eubanks <marshall= .eubanks@gmail.com>; L3VPN <l3vpn@ietf.org>; Fred Baker (fred) <= ;fred@cisco.com>
Sent: Monday, October 31, 2011 11:54 PM
Subject: RE: [vpn4dc] Question on the problem

= =0A
=0A=0A=0A =0A =0A=0A=0A=0A=0A =0A=0A
=0A=0A
Hi Fred,<= /div> =0A=0A
  =0A=0A
Thanks a lot for = the discussion.
=0A=0A
 
=0A=0A
You are right about the DC host to host communication. Now we=0Aneed = to get clear on the =E2=80=98securely=E2=80=99 thing.
=0A=0A<= div class=3D"yiv1252974310MsoNormal">  
=0A=0AHere is background of the vpn4= dc initiative:  SPs already=0Ahave large VPN deployment, they are movi= ng fast on providing scalable cloud=0Aservices. The MPLS VPN typically ends= at PEs, not reaching to hosts/end=0Asystems. The provisioning is segmented= (SP network segment, SP DC segment,=0AEnterprise segment, content provider= segment), and today they are often facing long=0Aservice turning up time. = =E2=80=93 this is the practical problems Ning first=0Apresented to us.
=0A=0A
 
=0A=0A
After a coupl= e of months study, we decided we would not be able=0Ato solve everything fo= r the end-to-end provisioning in one effort, but we could=0Apossibly solve = the  host-to-host layer 3 - ip or mpls, vpn connectivity problems=0Ain= one initiative =E2=80=93 vpn4dc. Why vpn? because they are existing servic= es, one=0Aof the most widely deployed features over the last 12 years. Ente= rprise customers=0Aare asking SPs to extend the vpns to the end systems.
=0A=0A
 
=0A=0A
We know that= MPLS/BGP VPN or other IP tunneling mechanisms provide=0Arouting isolation,= not encryption. Many folks consider the routing isolation=0Aprovides certa= in degree of security, good enough for them, while others think security=0A= means  encryption. We are not going to enter that debate here.<= /div> =0A=0A
  =0A=0A
Our intention is = to focus on the vpn connectivity issues, not=0Acryptography techniques, nor= key distribution/key management, we will leave=0Athese to the Security Are= a.  
=0A=0A
 
=0A=0A
= Let me send next mail to get more feedbacks from all.
=0A=0A  
=0A=0AThanks,
=0A=0ALuyuan
=0A=0A
 
=0A=0A
=0A=0A
=0A=0A
=0A=0A
= From:= =0Al3vpn-bounces= @ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Marshall=0AEu= banks
=0ASent: Monday, October 31, 2011 7:56 PM
=0ATo: = L3VPN; Fred Baker (fred)
=0ASubject: Fwd: [vpn4dc] Question on th= e problem
=0A=0A
=0A=0A
=0A=0A
 
=0A=0A
Forwarding for Fred Baker.
=0A=0A
= =0A=0A
---------- Forwarded message --= --------
=0AFrom: Fred Baker <fred= @cisco.com>
=0ADate: Mon, Oct 31, 2011 at 8:58 AM
=0ASubject: = [vpn4dc] Question on the problem
=0ATo: vp= n4dc@ietf.org
=0A
=0A
=0AI have started reading the vpn4dc dra= fts, and especially the problem=0Astatements, and find myself scratching my= head. Starting with the title=0A"VPN for Data Center", I really wonder if = the topic is starting from=0Aa proposed solution before settling on a probl= em.
=0A
=0ALet me ramble a bit, and then tell me I'm wrong.
=0A=0AIt seems to me that your primary issue is that you have a set of hosts = that=0Awant to communicate with each other securely. These hosts might be p= hysical or=0Avirtual, and might be in the same data center or in different = data centers. The=0Aimportant thing is that they be able to authenticate co= mmunications with each=0Aother, and then do things that they are authorized= to do based on those=0Acommunications. The things that they do might diffe= r. Within one community, the=0Ahosts might all be peers accomplishing the j= ob of the cloud, whatever that is -=0Aorder processing, content delivery, t= ake your pick. Within another community,=0Athe issue might be the managemen= t of virtual machines, and you might have a=0Arelatively small number of co= ntrol systems that talk with a large number of=0Aclient machines.
=0A=0AThe term "VPN" implies to me that you have chosen a solution. It=0Amigh= t be an MPLS VPN, which is to say that you have transport but depend on=0Ah= igher layer services for encryption, authentication, and authorization. In= =0AIPsec, "VPN" the term "VPN" generally refers to the tunnel=0Amode, and i= s a way of overlaying one network on another. In the case, that=0Adoesn't m= ake a lot of sense to me in this context - You don't appear to be=0Aoverlay= ing networks per se, merely making sure that messages you receive and=0Apro= cess are from trusted peers.
=0A
=0AIf the primary issue is one of tr= ust, we could discuss TLS, https (if the only=0Aapplication protocol is a w= eb protocol), or IPsec's transport mode. In any of=0Athose, the issue is la= rgely one of key distribution, and the use of those keys=0Afor encryption a= nd authentication to manage communications among a set of=0Acommunicating e= ntities.
=0A
=0AWhat am I missing? What makes this specifically a Vir= tual Private Network? Why=0Ais this not a key distribution problem based on= existing technologies?
=0A_____________________________________________= __
=0Avpn4dc mailing list
=0Avpn4dc@iet= f.org
=0Ahttps://www.ietf.org/mailman/listinfo/vpn4= dc
=0A=0A
=0A=0A
 
=0A=0A
=0A=0A
=0A= =0A =0A=0A=0A


--1882999342-136880922-1320158560=:90199-- From lucy.yong@huawei.com Tue Nov 1 08:31: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 2C5EE21F91D0 for ; Tue, 1 Nov 2011 08:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 nsZAypI4T4qg for ; Tue, 1 Nov 2011 08:31:17 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2E21F8EE8 for ; Tue, 1 Nov 2011 08:31:17 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTZ008H8N3YL7@usaga04-in.huawei.com> for l3vpn@ietf.org; Tue, 01 Nov 2011 10:31:11 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTZ000X6N3YAO@usaga04-in.huawei.com> for l3vpn@ietf.org; Tue, 01 Nov 2011 10:31:10 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 08:31:06 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 08:31:00 -0700 Date: Tue, 01 Nov 2011 15:30:59 +0000 From: Lucy yong Subject: RE: vpn4dc Q&A In-reply-to: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> X-Originating-IP: [10.192.11.76] To: "Luyuan Fang (lufang)" , L3VPN Message-id: <2691CE0099834E4A9C5044EEC662BB9D118D60B8@dfweml505-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_E1sKTvpTwoaoG/M2AVdv7A)" Content-language: en-US Accept-Language: en-US Thread-topic: vpn4dc Q&A Thread-index: AcyYU+vgQoLx0mxOTaeB3XO3f4OVpgAU2/JA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.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, 01 Nov 2011 15:31:19 -0000 --Boundary_(ID_E1sKTvpTwoaoG/M2AVdv7A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Please see my comments below. Lucy From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Luyuan Fang (lufang) Sent: Tuesday, November 01, 2011 12:06 AM To: L3VPN Subject: vpn4dc Q&A 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. [[LY]] Agree. There are many ways to form a hosts' private virtual network: via L3VPN, L2VPN, overlay VPN, or hybrid of them. My understanding is VPN4DC aiming on L3VPN solution because SPs have business cases on it, and it makes the work scope very clear. 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. [[LY]] Today L3VPN provides the connectivity among the connected sites, or say DC sites but it does not have the control on the hosts at the sites. VPN4DC requires the admission control on host joining/leaving via in-band signaling. 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. [[LY]] VPN4DC does not have any assumption in DC now. Thus, it addresses some use case, but not all. It makes the problem clear in this way. 4. Is this IETF problem? - Yes. It is about IP protocols for establish connectivity. [[LY]] agree. 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 --Boundary_(ID_E1sKTvpTwoaoG/M2AVdv7A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Please see my comments= below.

Lucy=

 

From: l3vpn-bo= unces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Luyuan Fang (lufang)
Sent: Tuesday, November 01, 2011 12:06 AM
To: L3VPN
Subject: vpn4dc Q&A

 

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?

-     &= nbsp;    DC Host-to-host connectivity through layer 3 signal= ing 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 domain= s.

[[LY]] Agree. Th= ere are many ways to form a hosts’ private virtual network: via L3VPN= , L2VPN, overlay VPN, or hybrid of them. My understanding is VPN4DC aiming = on L3VPN solution because SPs have business cases on it, and it makes the work scope very clear.

 

2. What cannot be achieved through L3VPN today?=

        - We don&= #8217;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 acce= pted 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 sc= alable 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.

[[LY]] Today L3V= PN provides the connectivity among the connected sites, or say DC sites but= it does not have the control on the hosts at the sites. VPN4DC requires th= e admission control on host joining/leaving via in-band signaling. <= /o:p>

 

3. What is missing?

     The missing piece is the se= gment in DC and inter-connection/auto-mapping of the DC segment to the netw= ork segment.

[[LY]] VPN4DC do= es not have any assumption in DC now. Thus, it addresses some use case, but= not all. It makes the problem clear in this way.

 

4. Is this IETF problem?

- Yes. It is about IP protocols for establish connec= tivity.

[[LY]] agree.

 

5. Who wants this?

    Please speak out if you do.<= /o:p>

 

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

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

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

- Multicast – the mcast use in DC need to be f= urther studied. We like to start without mcast to make things simpler, be a= ble to move.

 

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

 

Thanks,

Luyuan

 

 

--Boundary_(ID_E1sKTvpTwoaoG/M2AVdv7A)-- From lucy.yong@huawei.com Tue Nov 1 08:35:32 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 CFE4A1F0C40 for ; Tue, 1 Nov 2011 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 p4C5aOUxC1zb for ; Tue, 1 Nov 2011 08:35:31 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 90D161F0C3D for ; Tue, 1 Nov 2011 08:35:31 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTZ008D2NB6L7@usaga04-in.huawei.com> for l3vpn@ietf.org; Tue, 01 Nov 2011 10:35:30 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTZ000KVNATAO@usaga04-in.huawei.com> for l3vpn@ietf.org; Tue, 01 Nov 2011 10:35:30 -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; Tue, 01 Nov 2011 08:35:18 -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; Tue, 01 Nov 2011 08:35:12 -0700 Date: Tue, 01 Nov 2011 15:35:12 +0000 From: Lucy yong Subject: RE: [vpn4dc] Question on the problem In-reply-to: <1320158560.90199.YahooMailNeo@web161801.mail.bf1.yahoo.com> X-Originating-IP: [10.192.11.76] To: Derick Winkworth , "Luyuan Fang (lufang)" , Marshall Eubanks , L3VPN , "Fred Baker (fred)" Message-id: <2691CE0099834E4A9C5044EEC662BB9D118D60C6@dfweml505-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_XnVATJgbCMJXMpWyM+OcJw)" Content-language: en-US Accept-Language: en-US Thread-topic: [vpn4dc] Question on the problem Thread-index: AQHMmCjvzeXzAwYHcUWsWnPF/T1vrJWX6aWAgACkZAD//5i00A== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <238542D917511A45B6B8AA806E875E250732068F@XMB-RCD-201.cisco.com> <1320158560.90199.YahooMailNeo@web161801.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, 01 Nov 2011 15:35:32 -0000 --Boundary_(ID_XnVATJgbCMJXMpWyM+OcJw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 QWxsLA0KDQpJdCBpcyBtb3JlIGFib3V0IGhvc3Rz4oCZIHZpcnR1YWwgcHJpdmF0ZSBuZXR3b3Jr LiAgVlBONERDIGlzIGFpbWluZyBvbiBMM1ZQTiBhcyB0aGUgc29sdXRpb24gZm9yIGhvc3Rz4oCZ IHZpcnR1YWwgcHJpdmF0ZSBuZXR3b3JrLg0KDQpMdWN5DQoNCkZyb206IGwzdnBuLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGVy aWNrIFdpbmt3b3J0aA0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMDEsIDIwMTEgOTo0MyBBTQ0K VG86IEx1eXVhbiBGYW5nIChsdWZhbmcpOyBNYXJzaGFsbCBFdWJhbmtzOyBMM1ZQTjsgRnJlZCBC YWtlciAoZnJlZCkNClN1YmplY3Q6IFJlOiBbdnBuNGRjXSBRdWVzdGlvbiBvbiB0aGUgcHJvYmxl bQ0KDQpBbGw6DQoNCkksIHRvbywgYWdyZWUgdGhhdCB0aGUgImhvc3QtdG8taG9zdCIgdGVybSBp cyBjb25mdXNpbmcuICBJdHMgbm90IGFib3V0IGhvc3QtdG8taG9zdC4gIEl0cyBhYm91dCBwdXR0 aW5nIFZNcyAob3Igb3RoZXIgaG9zdHMpICJpbnRvIiBhbiBleGlzdGluZyBMM1ZQTiBuYXRpdmVs eS4gIFRoZXkgY291bGQgaGF2ZSBJUCBhZGRyZXNzZXMgY2hvc2VuIGJ5IHRoZSBMM1ZQTiBjdXN0 b21lciwgZm9yIGluc3RhbmNlLiAgV2Ugc2hvdWxkIGJlIGFibGUgdG8gdHVybiB1cCBhIFZNIGFu ZCBkcm9wIGl0IGludG8gYW4gTDNWUE4gd2l0aG91dCBpbnN0YWxsaW5nIHNvZnR3YXJlIG9yIHBl cmZvcm1pbmcgY29uZmlndXJhdGlvbiBvbiB0aGUgVk0gaXRzZWxmLg0KDQpJZiB0aGUgTDNWUE4g ZG9lcyBub3QgYWxyZWFkeSBleGlzdCBpbiB0aGUgZGF0YSBjZW50ZXIgd2hlcmUgdGhlIFZNIGhv c3QgcmVzaWRlcywgaG93IGNhbiB3ZSBhdXRvbWF0ZSB0aGUgcHJvdmlzaW9uaW5nIG9mIHRoZSBW UkZzLCBhbmQgdGhlbiBhdXRvbWF0ZSB0aGUgYXR0YWNobWVudCBvZiB0aGUgVk0gdG8gdGhhdCBW UkY/ICBNYW51YWxseSBjb25maWd1cmluZyBhbGwgb2YgdGhhdCBjYW4gYmUgZXh0cmVtZWx5IHRl ZGlvdXMuICBPcmNoZXN0cmF0aW9uIHRvb2xzIHRoYXQgaW50ZXJmYWNlIHdpdGggZGlzcGFyYXRl IEFQSXMgYXJlbid0IGRvaW5nIHRoZSBqb2Igd2VsbC4NCg0KRGVyaWNrDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogTHV5dWFuIEZhbmcgKGx1ZmFuZykgPGx1ZmFuZ0Bj aXNjby5jb20+DQpUbzogTWFyc2hhbGwgRXViYW5rcyA8bWFyc2hhbGwuZXViYW5rc0BnbWFpbC5j b20+OyBMM1ZQTiA8bDN2cG5AaWV0Zi5vcmc+OyBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNj by5jb20+DQpTZW50OiBNb25kYXksIE9jdG9iZXIgMzEsIDIwMTEgMTE6NTQgUE0NClN1YmplY3Q6 IFJFOiBbdnBuNGRjXSBRdWVzdGlvbiBvbiB0aGUgcHJvYmxlbQ0KSGkgRnJlZCwNCg0KVGhhbmtz IGEgbG90IGZvciB0aGUgZGlzY3Vzc2lvbi4NCg0KWW91IGFyZSByaWdodCBhYm91dCB0aGUgREMg aG9zdCB0byBob3N0IGNvbW11bmljYXRpb24uIE5vdyB3ZSBuZWVkIHRvIGdldCBjbGVhciBvbiB0 aGUg4oCYc2VjdXJlbHnigJkgdGhpbmcuDQoNCkhlcmUgaXMgYmFja2dyb3VuZCBvZiB0aGUgdnBu NGRjIGluaXRpYXRpdmU6ICBTUHMgYWxyZWFkeSBoYXZlIGxhcmdlIFZQTiBkZXBsb3ltZW50LCB0 aGV5IGFyZSBtb3ZpbmcgZmFzdCBvbiBwcm92aWRpbmcgc2NhbGFibGUgY2xvdWQgc2VydmljZXMu IFRoZSBNUExTIFZQTiB0eXBpY2FsbHkgZW5kcyBhdCBQRXMsIG5vdCByZWFjaGluZyB0byBob3N0 cy9lbmQgc3lzdGVtcy4gVGhlIHByb3Zpc2lvbmluZyBpcyBzZWdtZW50ZWQgKFNQIG5ldHdvcmsg c2VnbWVudCwgU1AgREMgc2VnbWVudCwgRW50ZXJwcmlzZSBzZWdtZW50LCBjb250ZW50IHByb3Zp ZGVyIHNlZ21lbnQpLCBhbmQgdG9kYXkgdGhleSBhcmUgb2Z0ZW4gZmFjaW5nIGxvbmcgc2Vydmlj ZSB0dXJuaW5nIHVwIHRpbWUuIOKAkyB0aGlzIGlzIHRoZSBwcmFjdGljYWwgcHJvYmxlbXMgTmlu ZyBmaXJzdCBwcmVzZW50ZWQgdG8gdXMuDQoNCkFmdGVyIGEgY291cGxlIG9mIG1vbnRocyBzdHVk eSwgd2UgZGVjaWRlZCB3ZSB3b3VsZCBub3QgYmUgYWJsZSB0byBzb2x2ZSBldmVyeXRoaW5nIGZv ciB0aGUgZW5kLXRvLWVuZCBwcm92aXNpb25pbmcgaW4gb25lIGVmZm9ydCwgYnV0IHdlIGNvdWxk IHBvc3NpYmx5IHNvbHZlIHRoZSAgaG9zdC10by1ob3N0IGxheWVyIDMgLSBpcCBvciBtcGxzLCB2 cG4gY29ubmVjdGl2aXR5IHByb2JsZW1zIGluIG9uZSBpbml0aWF0aXZlIOKAkyB2cG40ZGMuIFdo eSB2cG4/IGJlY2F1c2UgdGhleSBhcmUgZXhpc3Rpbmcgc2VydmljZXMsIG9uZSBvZiB0aGUgbW9z dCB3aWRlbHkgZGVwbG95ZWQgZmVhdHVyZXMgb3ZlciB0aGUgbGFzdCAxMiB5ZWFycy4gRW50ZXJw cmlzZSBjdXN0b21lcnMgYXJlIGFza2luZyBTUHMgdG8gZXh0ZW5kIHRoZSB2cG5zIHRvIHRoZSBl bmQgc3lzdGVtcy4NCg0KV2Uga25vdyB0aGF0IE1QTFMvQkdQIFZQTiBvciBvdGhlciBJUCB0dW5u ZWxpbmcgbWVjaGFuaXNtcyBwcm92aWRlIHJvdXRpbmcgaXNvbGF0aW9uLCBub3QgZW5jcnlwdGlv bi4gTWFueSBmb2xrcyBjb25zaWRlciB0aGUgcm91dGluZyBpc29sYXRpb24gcHJvdmlkZXMgY2Vy dGFpbiBkZWdyZWUgb2Ygc2VjdXJpdHksIGdvb2QgZW5vdWdoIGZvciB0aGVtLCB3aGlsZSBvdGhl cnMgdGhpbmsgc2VjdXJpdHkgbWVhbnMgIGVuY3J5cHRpb24uIFdlIGFyZSBub3QgZ29pbmcgdG8g ZW50ZXIgdGhhdCBkZWJhdGUgaGVyZS4NCg0KT3VyIGludGVudGlvbiBpcyB0byBmb2N1cyBvbiB0 aGUgdnBuIGNvbm5lY3Rpdml0eSBpc3N1ZXMsIG5vdCBjcnlwdG9ncmFwaHkgdGVjaG5pcXVlcywg bm9yIGtleSBkaXN0cmlidXRpb24va2V5IG1hbmFnZW1lbnQsIHdlIHdpbGwgbGVhdmUgdGhlc2Ug dG8gdGhlIFNlY3VyaXR5IEFyZWEuDQoNCkxldCBtZSBzZW5kIG5leHQgbWFpbCB0byBnZXQgbW9y ZSBmZWVkYmFja3MgZnJvbSBhbGwuDQoNClRoYW5rcywNCkx1eXVhbg0KDQpGcm9tOiBsM3Zwbi1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE1hcnNoYWxsIEV1YmFua3MNClNlbnQ6IE1vbmRheSwgT2N0b2JlciAzMSwgMjAxMSA3OjU2 IFBNDQpUbzogTDNWUE47IEZyZWQgQmFrZXIgKGZyZWQpDQpTdWJqZWN0OiBGd2Q6IFt2cG40ZGNd IFF1ZXN0aW9uIG9uIHRoZSBwcm9ibGVtDQoNCkZvcndhcmRpbmcgZm9yIEZyZWQgQmFrZXIuDQot LS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IEZyZWQgQmFrZXIg PGZyZWRAY2lzY28uY29tPG1haWx0bzpmcmVkQGNpc2NvLmNvbT4+DQpEYXRlOiBNb24sIE9jdCAz MSwgMjAxMSBhdCA4OjU4IEFNDQpTdWJqZWN0OiBbdnBuNGRjXSBRdWVzdGlvbiBvbiB0aGUgcHJv YmxlbQ0KVG86IHZwbjRkY0BpZXRmLm9yZzxtYWlsdG86dnBuNGRjQGlldGYub3JnPg0KDQoNCkkg aGF2ZSBzdGFydGVkIHJlYWRpbmcgdGhlIHZwbjRkYyBkcmFmdHMsIGFuZCBlc3BlY2lhbGx5IHRo ZSBwcm9ibGVtIHN0YXRlbWVudHMsIGFuZCBmaW5kIG15c2VsZiBzY3JhdGNoaW5nIG15IGhlYWQu IFN0YXJ0aW5nIHdpdGggdGhlIHRpdGxlICJWUE4gZm9yIERhdGEgQ2VudGVyIiwgSSByZWFsbHkg d29uZGVyIGlmIHRoZSB0b3BpYyBpcyBzdGFydGluZyBmcm9tIGEgcHJvcG9zZWQgc29sdXRpb24g YmVmb3JlIHNldHRsaW5nIG9uIGEgcHJvYmxlbS4NCg0KTGV0IG1lIHJhbWJsZSBhIGJpdCwgYW5k IHRoZW4gdGVsbCBtZSBJJ20gd3JvbmcuDQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgeW91ciBwcmlt YXJ5IGlzc3VlIGlzIHRoYXQgeW91IGhhdmUgYSBzZXQgb2YgaG9zdHMgdGhhdCB3YW50IHRvIGNv bW11bmljYXRlIHdpdGggZWFjaCBvdGhlciBzZWN1cmVseS4gVGhlc2UgaG9zdHMgbWlnaHQgYmUg cGh5c2ljYWwgb3IgdmlydHVhbCwgYW5kIG1pZ2h0IGJlIGluIHRoZSBzYW1lIGRhdGEgY2VudGVy IG9yIGluIGRpZmZlcmVudCBkYXRhIGNlbnRlcnMuIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhh dCB0aGV5IGJlIGFibGUgdG8gYXV0aGVudGljYXRlIGNvbW11bmljYXRpb25zIHdpdGggZWFjaCBv dGhlciwgYW5kIHRoZW4gZG8gdGhpbmdzIHRoYXQgdGhleSBhcmUgYXV0aG9yaXplZCB0byBkbyBi YXNlZCBvbiB0aG9zZSBjb21tdW5pY2F0aW9ucy4gVGhlIHRoaW5ncyB0aGF0IHRoZXkgZG8gbWln aHQgZGlmZmVyLiBXaXRoaW4gb25lIGNvbW11bml0eSwgdGhlIGhvc3RzIG1pZ2h0IGFsbCBiZSBw ZWVycyBhY2NvbXBsaXNoaW5nIHRoZSBqb2Igb2YgdGhlIGNsb3VkLCB3aGF0ZXZlciB0aGF0IGlz IC0gb3JkZXIgcHJvY2Vzc2luZywgY29udGVudCBkZWxpdmVyeSwgdGFrZSB5b3VyIHBpY2suIFdp dGhpbiBhbm90aGVyIGNvbW11bml0eSwgdGhlIGlzc3VlIG1pZ2h0IGJlIHRoZSBtYW5hZ2VtZW50 IG9mIHZpcnR1YWwgbWFjaGluZXMsIGFuZCB5b3UgbWlnaHQgaGF2ZSBhIHJlbGF0aXZlbHkgc21h bGwgbnVtYmVyIG9mIGNvbnRyb2wgc3lzdGVtcyB0aGF0IHRhbGsgd2l0aCBhIGxhcmdlIG51bWJl ciBvZiBjbGllbnQgbWFjaGluZXMuDQoNClRoZSB0ZXJtICJWUE4iIGltcGxpZXMgdG8gbWUgdGhh dCB5b3UgaGF2ZSBjaG9zZW4gYSBzb2x1dGlvbi4gSXQgbWlnaHQgYmUgYW4gTVBMUyBWUE4sIHdo aWNoIGlzIHRvIHNheSB0aGF0IHlvdSBoYXZlIHRyYW5zcG9ydCBidXQgZGVwZW5kIG9uIGhpZ2hl ciBsYXllciBzZXJ2aWNlcyBmb3IgZW5jcnlwdGlvbiwgYXV0aGVudGljYXRpb24sIGFuZCBhdXRo b3JpemF0aW9uLiBJbiBJUHNlYywgIlZQTiIgdGhlIHRlcm0gIlZQTiIgZ2VuZXJhbGx5IHJlZmVy cyB0byB0aGUgdHVubmVsIG1vZGUsIGFuZCBpcyBhIHdheSBvZiBvdmVybGF5aW5nIG9uZSBuZXR3 b3JrIG9uIGFub3RoZXIuIEluIHRoZSBjYXNlLCB0aGF0IGRvZXNuJ3QgbWFrZSBhIGxvdCBvZiBz ZW5zZSB0byBtZSBpbiB0aGlzIGNvbnRleHQgLSBZb3UgZG9uJ3QgYXBwZWFyIHRvIGJlIG92ZXJs YXlpbmcgbmV0d29ya3MgcGVyIHNlLCBtZXJlbHkgbWFraW5nIHN1cmUgdGhhdCBtZXNzYWdlcyB5 b3UgcmVjZWl2ZSBhbmQgcHJvY2VzcyBhcmUgZnJvbSB0cnVzdGVkIHBlZXJzLg0KDQpJZiB0aGUg cHJpbWFyeSBpc3N1ZSBpcyBvbmUgb2YgdHJ1c3QsIHdlIGNvdWxkIGRpc2N1c3MgVExTLCBodHRw cyAoaWYgdGhlIG9ubHkgYXBwbGljYXRpb24gcHJvdG9jb2wgaXMgYSB3ZWIgcHJvdG9jb2wpLCBv ciBJUHNlYydzIHRyYW5zcG9ydCBtb2RlLiBJbiBhbnkgb2YgdGhvc2UsIHRoZSBpc3N1ZSBpcyBs YXJnZWx5IG9uZSBvZiBrZXkgZGlzdHJpYnV0aW9uLCBhbmQgdGhlIHVzZSBvZiB0aG9zZSBrZXlz IGZvciBlbmNyeXB0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiB0byBtYW5hZ2UgY29tbXVuaWNhdGlv bnMgYW1vbmcgYSBzZXQgb2YgY29tbXVuaWNhdGluZyBlbnRpdGllcy4NCg0KV2hhdCBhbSBJIG1p c3Npbmc/IFdoYXQgbWFrZXMgdGhpcyBzcGVjaWZpY2FsbHkgYSBWaXJ0dWFsIFByaXZhdGUgTmV0 d29yaz8gV2h5IGlzIHRoaXMgbm90IGEga2V5IGRpc3RyaWJ1dGlvbiBwcm9ibGVtIGJhc2VkIG9u IGV4aXN0aW5nIHRlY2hub2xvZ2llcz8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQp2cG40ZGMgbWFpbGluZyBsaXN0DQp2cG40ZGNAaWV0Zi5vcmc8bWFp bHRvOnZwbjRkY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdnBuNGRjDQoNCg0K --Boundary_(ID_XnVATJgbCMJXMpWyM+OcJw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9 DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwv c3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEg MSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5v c2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC55aXYxMjUyOTc0 MzEwbXNvbm9ybWFsLCBsaS55aXYxMjUyOTc0MzEwbXNvbm9ybWFsLCBkaXYueWl2MTI1Mjk3NDMx MG1zb25vcm1hbA0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjUyOTc0MzEwbXNvbm9ybWFsOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjEyNTI5NzQz MTBtc29oeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTI1Mjk3NDMxMG1zb2h5cGVybGlu azt9DQpzcGFuLnlpdjEyNTI5NzQzMTBtc29oeXBlcmxpbmtmb2xsb3dlZA0KCXttc28tc3R5bGUt bmFtZTp5aXYxMjUyOTc0MzEwbXNvaHlwZXJsaW5rZm9sbG93ZWQ7fQ0Kc3Bhbi55aXYxMjUyOTc0 MzEwZW1haWxzdHlsZTE3DQoJe21zby1zdHlsZS1uYW1lOnlpdjEyNTI5NzQzMTBlbWFpbHN0eWxl MTc7fQ0KcC55aXYxMjUyOTc0MzEwbXNvbm9ybWFsMSwgbGkueWl2MTI1Mjk3NDMxMG1zb25vcm1h bDEsIGRpdi55aXYxMjUyOTc0MzEwbXNvbm9ybWFsMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjUy OTc0MzEwbXNvbm9ybWFsMTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0Kc3Bhbi55aXYxMjUyOTc0MzEwbXNvaHlwZXJsaW5rMQ0KCXttc28tc3R5bGUtbmFtZTp5 aXYxMjUyOTc0MzEwbXNvaHlwZXJsaW5rMTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXYxMjUyOTc0MzEwbXNvaHlwZXJsaW5rZm9sbG93ZWQxDQoJ e21zby1zdHlsZS1uYW1lOnlpdjEyNTI5NzQzMTBtc29oeXBlcmxpbmtmb2xsb3dlZDE7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXYxMjUyOTc0 MzEwZW1haWxzdHlsZTE3MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjUyOTc0MzEwZW1haWxzdHls ZTE3MTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsbCw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkl0IGlzIG1vcmUgYWJvdXQgaG9zdHPigJkgdmlydHVhbCBwcml2YXRlIG5ldHdv cmsuICZuYnNwO1ZQTjREQyBpcyBhaW1pbmcgb24gTDNWUE4gYXMgdGhlIHNvbHV0aW9uIGZvciBo b3N0c+KAmSB2aXJ0dWFsIHByaXZhdGUgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkx1Y3k8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGVyaWNrIFdpbmt3b3J0aDxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAwMSwgMjAxMSA5OjQzIEFNPGJyPg0KPGI+VG86PC9i PiBMdXl1YW4gRmFuZyAobHVmYW5nKTsgTWFyc2hhbGwgRXViYW5rczsgTDNWUE47IEZyZWQgQmFr ZXIgKGZyZWQpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdnBuNGRjXSBRdWVzdGlvbiBvbiB0 aGUgcHJvYmxlbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkFsbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkksIHRv bywgYWdyZWUgdGhhdCB0aGUgJnF1b3Q7aG9zdC10by1ob3N0JnF1b3Q7IHRlcm0gaXMgY29uZnVz aW5nLiAmbmJzcDtJdHMgbm90IGFib3V0IGhvc3QtdG8taG9zdC4gJm5ic3A7SXRzIGFib3V0IHB1 dHRpbmcgVk1zIChvciBvdGhlciBob3N0cykgJnF1b3Q7aW50byZxdW90OyBhbg0KIGV4aXN0aW5n IEwzVlBOIG5hdGl2ZWx5LiAmbmJzcDtUaGV5IGNvdWxkIGhhdmUgSVAgYWRkcmVzc2VzIGNob3Nl biBieSB0aGUgTDNWUE4gY3VzdG9tZXIsIGZvciBpbnN0YW5jZS4gJm5ic3A7V2Ugc2hvdWxkIGJl IGFibGUgdG8gdHVybiB1cCBhIFZNIGFuZCBkcm9wIGl0IGludG8gYW4gTDNWUE4gd2l0aG91dCBp bnN0YWxsaW5nIHNvZnR3YXJlIG9yIHBlcmZvcm1pbmcgY29uZmlndXJhdGlvbiBvbiB0aGUgVk0g aXRzZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SWYgdGhlIEwzVlBOIGRvZXMgbm90IGFs cmVhZHkgZXhpc3QgaW4gdGhlIGRhdGEgY2VudGVyIHdoZXJlIHRoZSBWTSBob3N0IHJlc2lkZXMs IGhvdyBjYW4gd2UgYXV0b21hdGUgdGhlIHByb3Zpc2lvbmluZyBvZiB0aGUgVlJGcywgYW5kDQog dGhlbiBhdXRvbWF0ZSB0aGUgYXR0YWNobWVudCBvZiB0aGUgVk0gdG8gdGhhdCBWUkY/ICZuYnNw O01hbnVhbGx5IGNvbmZpZ3VyaW5nIGFsbCBvZiB0aGF0IGNhbiBiZSBleHRyZW1lbHkgdGVkaW91 cy4gJm5ic3A7T3JjaGVzdHJhdGlvbiB0b29scyB0aGF0IGludGVyZmFjZSB3aXRoIGRpc3BhcmF0 ZSBBUElzIGFyZW4ndCBkb2luZyB0aGUgam9iIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5EZXJpY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp diBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+ PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7 YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PiBMdXl1YW4gRmFuZyAobHVmYW5nKQ0KICZsdDtsdWZhbmdAY2lzY28uY29tJmd0Ozxicj4NCjxi PlRvOjwvYj4gTWFyc2hhbGwgRXViYW5rcyAmbHQ7bWFyc2hhbGwuZXViYW5rc0BnbWFpbC5jb20m Z3Q7OyBMM1ZQTiAmbHQ7bDN2cG5AaWV0Zi5vcmcmZ3Q7OyBGcmVkIEJha2VyIChmcmVkKSAmbHQ7 ZnJlZEBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAzMSwg MjAxMSAxMTo1NCBQTTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3ZwbjRkY10gUXVlc3Rpb24g b24gdGhlIHByb2JsZW08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5aXYxMjUyOTc0MzEwIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRnJlZCw8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgYSBsb3QgZm9yIHRoZSBkaXNjdXNzaW9uLjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBhcmUgcmlnaHQgYWJvdXQgdGhlIERD IGhvc3QgdG8gaG9zdCBjb21tdW5pY2F0aW9uLiBOb3cgd2UgbmVlZCB0byBnZXQgY2xlYXIgb24g dGhlIOKAmHNlY3VyZWx54oCZIHRoaW5nLg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SGVyZSBpcyBiYWNrZ3JvdW5kIG9mIHRoZSB2cG40ZGMgaW5pdGlhdGl2ZTogJm5i c3A7U1BzIGFscmVhZHkgaGF2ZSBsYXJnZSBWUE4gZGVwbG95bWVudCwgdGhleSBhcmUgbW92aW5n IGZhc3Qgb24gcHJvdmlkaW5nIHNjYWxhYmxlIGNsb3VkDQogc2VydmljZXMuIFRoZSBNUExTIFZQ TiB0eXBpY2FsbHkgZW5kcyBhdCBQRXMsIG5vdCByZWFjaGluZyB0byBob3N0cy9lbmQgc3lzdGVt cy4gVGhlIHByb3Zpc2lvbmluZyBpcyBzZWdtZW50ZWQgKFNQIG5ldHdvcmsgc2VnbWVudCwgU1Ag REMgc2VnbWVudCwgRW50ZXJwcmlzZSBzZWdtZW50LCBjb250ZW50IHByb3ZpZGVyIHNlZ21lbnQp LCBhbmQgdG9kYXkgdGhleSBhcmUgb2Z0ZW4gZmFjaW5nIGxvbmcgc2VydmljZSB0dXJuaW5nIHVw IHRpbWUuDQog4oCTIHRoaXMgaXMgdGhlIHByYWN0aWNhbCBwcm9ibGVtcyBOaW5nIGZpcnN0IHBy ZXNlbnRlZCB0byB1cy4gPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWZ0 ZXIgYSBjb3VwbGUgb2YgbW9udGhzIHN0dWR5LCB3ZSBkZWNpZGVkIHdlIHdvdWxkIG5vdCBiZSBh YmxlIHRvIHNvbHZlIGV2ZXJ5dGhpbmcgZm9yIHRoZSBlbmQtdG8tZW5kIHByb3Zpc2lvbmluZyBp biBvbmUgZWZmb3J0LCBidXQNCiB3ZSBjb3VsZCBwb3NzaWJseSBzb2x2ZSB0aGUgJm5ic3A7aG9z dC10by1ob3N0IGxheWVyIDMgLSBpcCBvciBtcGxzLCB2cG4gY29ubmVjdGl2aXR5IHByb2JsZW1z IGluIG9uZSBpbml0aWF0aXZlIOKAkyB2cG40ZGMuIFdoeSB2cG4/IGJlY2F1c2UgdGhleSBhcmUg ZXhpc3Rpbmcgc2VydmljZXMsIG9uZSBvZiB0aGUgbW9zdCB3aWRlbHkgZGVwbG95ZWQgZmVhdHVy ZXMgb3ZlciB0aGUgbGFzdCAxMiB5ZWFycy4gRW50ZXJwcmlzZSBjdXN0b21lcnMgYXJlIGFza2lu Zw0KIFNQcyB0byBleHRlbmQgdGhlIHZwbnMgdG8gdGhlIGVuZCBzeXN0ZW1zLjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGtub3cgdGhhdCBNUExTL0JHUCBWUE4gb3Ig b3RoZXIgSVAgdHVubmVsaW5nIG1lY2hhbmlzbXMgcHJvdmlkZSByb3V0aW5nIGlzb2xhdGlvbiwg bm90IGVuY3J5cHRpb24uIE1hbnkgZm9sa3MgY29uc2lkZXIgdGhlIHJvdXRpbmcNCiBpc29sYXRp b24gcHJvdmlkZXMgY2VydGFpbiBkZWdyZWUgb2Ygc2VjdXJpdHksIGdvb2QgZW5vdWdoIGZvciB0 aGVtLCB3aGlsZSBvdGhlcnMgdGhpbmsgc2VjdXJpdHkgbWVhbnMgJm5ic3A7ZW5jcnlwdGlvbi4g V2UgYXJlIG5vdCBnb2luZyB0byBlbnRlciB0aGF0IGRlYmF0ZSBoZXJlLjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk91ciBpbnRlbnRpb24gaXMgdG8gZm9jdXMgb24gdGhl IHZwbiBjb25uZWN0aXZpdHkgaXNzdWVzLCBub3QgY3J5cHRvZ3JhcGh5IHRlY2huaXF1ZXMsIG5v ciBrZXkgZGlzdHJpYnV0aW9uL2tleSBtYW5hZ2VtZW50LCB3ZSB3aWxsIGxlYXZlDQogdGhlc2Ug dG8gdGhlIFNlY3VyaXR5IEFyZWEuICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkxldCBtZSBzZW5kIG5leHQgbWFpbCB0byBnZXQgbW9yZSBmZWVkYmFja3MgZnJv bSBhbGwuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkx1eXVhbjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcnNoYWxs IEV1YmFua3M8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDMxLCAyMDExIDc6NTYg UE08YnI+DQo8Yj5Ubzo8L2I+IEwzVlBOOyBGcmVkIEJha2VyIChmcmVkKTxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBGd2Q6IFt2cG40ZGNdIFF1ZXN0aW9uIG9uIHRoZSBwcm9ibGVtPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Rm9yd2FyZGluZyBmb3IgRnJlZCBCYWtlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LS0tLS0tLS0tLSBGb3J3YXJk ZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogPGI+RnJlZCBCYWtlcjwvYj4gJmx0Ozxh IGhyZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZyZWRAY2lzY28u Y29tPC9hPiZndDs8YnI+DQpEYXRlOiBNb24sIE9jdCAzMSwgMjAxMSBhdCA4OjU4IEFNPGJyPg0K U3ViamVjdDogW3ZwbjRkY10gUXVlc3Rpb24gb24gdGhlIHByb2JsZW08YnI+DQpUbzogPGEgaHJl Zj0ibWFpbHRvOnZwbjRkY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZwbjRkY0BpZXRmLm9y ZzwvYT48YnI+DQo8YnI+DQo8YnI+DQpJIGhhdmUgc3RhcnRlZCByZWFkaW5nIHRoZSB2cG40ZGMg ZHJhZnRzLCBhbmQgZXNwZWNpYWxseSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnRzLCBhbmQgZmluZCBt eXNlbGYgc2NyYXRjaGluZyBteSBoZWFkLiBTdGFydGluZyB3aXRoIHRoZSB0aXRsZSAmcXVvdDtW UE4gZm9yIERhdGEgQ2VudGVyJnF1b3Q7LCBJIHJlYWxseSB3b25kZXIgaWYgdGhlIHRvcGljIGlz IHN0YXJ0aW5nIGZyb20gYSBwcm9wb3NlZCBzb2x1dGlvbiBiZWZvcmUgc2V0dGxpbmcgb24gYSBw cm9ibGVtLjxicj4NCjxicj4NCkxldCBtZSByYW1ibGUgYSBiaXQsIGFuZCB0aGVuIHRlbGwgbWUg SSdtIHdyb25nLjxicj4NCjxicj4NCkl0IHNlZW1zIHRvIG1lIHRoYXQgeW91ciBwcmltYXJ5IGlz c3VlIGlzIHRoYXQgeW91IGhhdmUgYSBzZXQgb2YgaG9zdHMgdGhhdCB3YW50IHRvIGNvbW11bmlj YXRlIHdpdGggZWFjaCBvdGhlciBzZWN1cmVseS4gVGhlc2UgaG9zdHMgbWlnaHQgYmUgcGh5c2lj YWwgb3IgdmlydHVhbCwgYW5kIG1pZ2h0IGJlIGluIHRoZSBzYW1lIGRhdGEgY2VudGVyIG9yIGlu IGRpZmZlcmVudCBkYXRhIGNlbnRlcnMuIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdA0KIHRo ZXkgYmUgYWJsZSB0byBhdXRoZW50aWNhdGUgY29tbXVuaWNhdGlvbnMgd2l0aCBlYWNoIG90aGVy LCBhbmQgdGhlbiBkbyB0aGluZ3MgdGhhdCB0aGV5IGFyZSBhdXRob3JpemVkIHRvIGRvIGJhc2Vk IG9uIHRob3NlIGNvbW11bmljYXRpb25zLiBUaGUgdGhpbmdzIHRoYXQgdGhleSBkbyBtaWdodCBk aWZmZXIuIFdpdGhpbiBvbmUgY29tbXVuaXR5LCB0aGUgaG9zdHMgbWlnaHQgYWxsIGJlIHBlZXJz IGFjY29tcGxpc2hpbmcgdGhlIGpvYiBvZg0KIHRoZSBjbG91ZCwgd2hhdGV2ZXIgdGhhdCBpcyAt IG9yZGVyIHByb2Nlc3NpbmcsIGNvbnRlbnQgZGVsaXZlcnksIHRha2UgeW91ciBwaWNrLiBXaXRo aW4gYW5vdGhlciBjb21tdW5pdHksIHRoZSBpc3N1ZSBtaWdodCBiZSB0aGUgbWFuYWdlbWVudCBv ZiB2aXJ0dWFsIG1hY2hpbmVzLCBhbmQgeW91IG1pZ2h0IGhhdmUgYSByZWxhdGl2ZWx5IHNtYWxs IG51bWJlciBvZiBjb250cm9sIHN5c3RlbXMgdGhhdCB0YWxrIHdpdGggYSBsYXJnZSBudW1iZXIN CiBvZiBjbGllbnQgbWFjaGluZXMuPGJyPg0KPGJyPg0KVGhlIHRlcm0gJnF1b3Q7VlBOJnF1b3Q7 IGltcGxpZXMgdG8gbWUgdGhhdCB5b3UgaGF2ZSBjaG9zZW4gYSBzb2x1dGlvbi4gSXQgbWlnaHQg YmUgYW4gTVBMUyBWUE4sIHdoaWNoIGlzIHRvIHNheSB0aGF0IHlvdSBoYXZlIHRyYW5zcG9ydCBi dXQgZGVwZW5kIG9uIGhpZ2hlciBsYXllciBzZXJ2aWNlcyBmb3IgZW5jcnlwdGlvbiwgYXV0aGVu dGljYXRpb24sIGFuZCBhdXRob3JpemF0aW9uLiBJbiBJUHNlYywgJnF1b3Q7VlBOJnF1b3Q7IHRo ZSB0ZXJtICZxdW90O1ZQTiZxdW90OyBnZW5lcmFsbHkgcmVmZXJzDQogdG8gdGhlIHR1bm5lbCBt b2RlLCBhbmQgaXMgYSB3YXkgb2Ygb3ZlcmxheWluZyBvbmUgbmV0d29yayBvbiBhbm90aGVyLiBJ biB0aGUgY2FzZSwgdGhhdCBkb2Vzbid0IG1ha2UgYSBsb3Qgb2Ygc2Vuc2UgdG8gbWUgaW4gdGhp cyBjb250ZXh0IC0gWW91IGRvbid0IGFwcGVhciB0byBiZSBvdmVybGF5aW5nIG5ldHdvcmtzIHBl ciBzZSwgbWVyZWx5IG1ha2luZyBzdXJlIHRoYXQgbWVzc2FnZXMgeW91IHJlY2VpdmUgYW5kIHBy b2Nlc3MgYXJlIGZyb20NCiB0cnVzdGVkIHBlZXJzLjxicj4NCjxicj4NCklmIHRoZSBwcmltYXJ5 IGlzc3VlIGlzIG9uZSBvZiB0cnVzdCwgd2UgY291bGQgZGlzY3VzcyBUTFMsIGh0dHBzIChpZiB0 aGUgb25seSBhcHBsaWNhdGlvbiBwcm90b2NvbCBpcyBhIHdlYiBwcm90b2NvbCksIG9yIElQc2Vj J3MgdHJhbnNwb3J0IG1vZGUuIEluIGFueSBvZiB0aG9zZSwgdGhlIGlzc3VlIGlzIGxhcmdlbHkg b25lIG9mIGtleSBkaXN0cmlidXRpb24sIGFuZCB0aGUgdXNlIG9mIHRob3NlIGtleXMgZm9yIGVu Y3J5cHRpb24gYW5kIGF1dGhlbnRpY2F0aW9uDQogdG8gbWFuYWdlIGNvbW11bmljYXRpb25zIGFt b25nIGEgc2V0IG9mIGNvbW11bmljYXRpbmcgZW50aXRpZXMuPGJyPg0KPGJyPg0KV2hhdCBhbSBJ IG1pc3Npbmc/IFdoYXQgbWFrZXMgdGhpcyBzcGVjaWZpY2FsbHkgYSBWaXJ0dWFsIFByaXZhdGUg TmV0d29yaz8gV2h5IGlzIHRoaXMgbm90IGEga2V5IGRpc3RyaWJ1dGlvbiBwcm9ibGVtIGJhc2Vk IG9uIGV4aXN0aW5nIHRlY2hub2xvZ2llcz88YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnZwbjRkYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86dnBuNGRjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dnBuNGRjQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdnBuNGRjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92cG40ZGM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --Boundary_(ID_XnVATJgbCMJXMpWyM+OcJw)-- From pedro.r.marques@gmail.com Tue Nov 1 10:39:09 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 4455521F9A33 for ; Tue, 1 Nov 2011 10:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlKYlu3+5h-e for ; Tue, 1 Nov 2011 10:39:08 -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 8FF2921F99CE for ; Tue, 1 Nov 2011 10:39:08 -0700 (PDT) Received: by ywt2 with SMTP id 2so8678065ywt.31 for ; Tue, 01 Nov 2011 10:35:52 -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=xt8tnAp3QWVzVSRBdli79QdTVdTw+f30ZUsJ9ZMrxzw=; b=VIn+1eUKmhfbiIRg/5Bc7/cGxvhH5iTM7PIaP8aGtEqey1YrRymta+8nKH1yi8UUFT TyxHg6ZNlx1nII3gQVVAxxjsFLX/IsaG6LgzKU6xC65B9GnA5QKMIW6bTVr49vLycUv9 ULD7/CD/NLw4e9UVk8YZI7QOpcsNx7/phB47M= MIME-Version: 1.0 Received: by 10.50.104.137 with SMTP id ge9mr438038igb.38.1320168951236; Tue, 01 Nov 2011 10:35:51 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Tue, 1 Nov 2011 10:35:51 -0700 (PDT) In-Reply-To: References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> Date: Tue, 1 Nov 2011 10:35:51 -0700 Message-ID: Subject: Re: [vpn4dc] Question on the problem From: Pedro Marques To: Marshall Eubanks Content-Type: text/plain; charset=ISO-8859-1 Cc: L3VPN , Fred Baker 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 17:39:09 -0000 Fred, Authentication and private networks are orthogonal topics; both are necessary. In a shared facility it is necessary to control the IP network access of machines (virtual or otherwise) of a given admin-domain. For instances such networks are often closed to the outside world. This does not replace the need to authenticate at the application level. As with any other application security is applied in layers. VPNs are needed in this space by the same reason they are needed in another other space. I'm sure you are not going to advocate that we should just get rid of firewalls and private enterprise networks. It is well understood that end-to-end IP unfettered access is unrealistic for security and administrative reasons. The term VPN states a requirement. I believe it is preferable than to use the term "VLAN" which is more common in this space, where the implication is that the VLAN is not connected to the outside world other than through an appliance. Application level security within a VPN is still required. But that doesn't not replace the need for a private network. I don't believe it is productive to argue otherwise. It is simply not acceptable for the VMs of user A to be able to send arbitrary IP packets to the VMs of user B. Pedro. On Mon, Oct 31, 2011 at 4:56 PM, Marshall Eubanks wrote: > 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 > > From robert@raszuk.net Tue Nov 1 11:03: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 D76301F0CA1 for ; Tue, 1 Nov 2011 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Ups5wFxNfUi9 for ; Tue, 1 Nov 2011 11:03:45 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id BDD261F0C4D for ; Tue, 1 Nov 2011 11:03:44 -0700 (PDT) Received: (qmail 12533 invoked by uid 399); 1 Nov 2011 18:02:23 -0000 Received: from unknown (HELO ?216.69.73.167?) (216.69.73.167) by mail37.opentransfer.com with SMTP; 1 Nov 2011 18:02:23 -0000 Message-ID: <4EB0342E.1080909@raszuk.net> Date: Tue, 01 Nov 2011 19:02:22 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Pedro Marques Subject: Re: [vpn4dc] Question on the problem References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN , Fred Baker 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, 01 Nov 2011 18:03:46 -0000 Pedro, > In a shared facility it is necessary to control the IP > network access of machines (virtual or otherwise) of a given > admin-domain. + > Application level security within a VPN is still required. But that > doesn't not replace the need for a private network. I don't believe it > is productive to argue otherwise. It is simply not acceptable for the > VMs of user A to be able to send arbitrary IP packets to the VMs of > user B. Do you think that it is acceptable of arbitrary host in the internet to send IP packet to any other host ? If not then how are you protecting considering draft-marques-l3vpn-end-system the datacenter host from being reachable by anyone ? Correct me if I have misread the proposal but it seems you are protecting VMs running over those host by terminating IP GRE tunnels in the hosts and allowing only selected IP reachability to reach particular set of VMs. I do not see how is this any more secure as interconnecting VMs over IPsec and filtering (be it on the host level) any other IP traffic between same admin-domain groups such VMs are provisioned to be part of. Thx, R. From ycai@cisco.com Tue Nov 1 11:18: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 0A44F21F8EB6 for ; Tue, 1 Nov 2011 11:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.332 X-Spam-Level: X-Spam-Status: No, score=-7.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 0AX-CLaZgR+X for ; Tue, 1 Nov 2011 11:18:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C979A21F8E92 for ; Tue, 1 Nov 2011 11:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=1198; q=dns/txt; s=iport; t=1320171489; x=1321381089; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=tH/Y9wtI2uT31g5kzcA9LH5+6i8yQ9j88l0IZTWhyqI=; b=Bu0RPLseXrokRk8R7odja23MzjwxkM/FV2IZnkzaFoc8Pl8OiWpJV3pi p8myD36mh/+4xit6ENdLWlbP6MARQwz5Jz0G7SnUn6dCgb/B7/rBW+jkd aYAnIIiqs8fVhdop0CvCH7bBiHqI44sdp9ClA+Uo2mqjGjY+t5fCSjgIP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokGABM3sE6Q/khR/2dsb2JhbABDiT+gBAKBBYFyAQEBAwESAScCAU4BCIEdAQEELgeHYJVrgSYBi0aSZYkHBIgGjAmFNogbhC4 X-IronPort-AV: E=Sophos;i="4.69,439,1315180800"; d="scan'208";a="120539922" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2011 18:17:29 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA1IHNnS009891 for ; Tue, 1 Nov 2011 18:17:29 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 11:17:28 -0700 Received: from 128.107.161.220 ([128.107.161.220]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Nov 2011 18:17:27 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 01 Nov 2011 11:17:29 -0700 Subject: Re: vpn4dc Q&A From: Yiqun Cai To: L3VPN Message-ID: Thread-Topic: vpn4dc Q&A Thread-Index: AcyYU+vgQoLx0mxOTaeB3XO3f4OVpgAbpf7s In-Reply-To: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Nov 2011 18:17:28.0172 (UTC) FILETIME=[835A6AC0:01CC98C2] 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 18:18:11 -0000 > > 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. > If we expect this work to be successful, and if past history is any indication of what might happen in the future, the moment the solution gets deployed people will ask for multicast. Excluding multicast would be a costly mistake for everyone. When multicast was forgot, or declared out of scope, we ended up spending more time to "fix" it. I am sure all of us still have fresh memory of what l3vpn has been doing since 2004. And in case you are not aware, there is a brand new BOF dedicated to solving v4/v6 transition for multicast. When multicast was considered from the beginning, (e.g., trill and l2vpn) the work is still there but there is less drama. Given the nature of the proposed work and its applicable space, I just don't see how you can avoid multicast down the road. -- Yiqun From pedro.r.marques@gmail.com Tue Nov 1 11:19: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 07F7621F8F17 for ; Tue, 1 Nov 2011 11:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 VmzAH688s97V for ; Tue, 1 Nov 2011 11:19:43 -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 AC49A21F8EC2 for ; Tue, 1 Nov 2011 11:19:25 -0700 (PDT) Received: by iaeo4 with SMTP id o4so1103588iae.31 for ; Tue, 01 Nov 2011 11:18:57 -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=+yt84ZjGA8RKu8VVqYSza83mS+6EaXN+wNkG1/KxPPs=; b=OtwYCmdae5tSXJ+IP50ESDGV0gxk68hXmGycro/83niaFMmDJjgtY4snjyH4SZkToU SjcxpnYS2C8in4S0i6HiX3oxId+WKxtaiesoeMjpawO9ECG4DAk1ll/lMgP+NAog40HH /N146MTqF4uBBZHDoDNO8rFJP88G9lJgPQcN4= MIME-Version: 1.0 Received: by 10.231.63.212 with SMTP id c20mr127991ibi.52.1320171537743; Tue, 01 Nov 2011 11:18:57 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Tue, 1 Nov 2011 11:18:57 -0700 (PDT) In-Reply-To: <4EB0342E.1080909@raszuk.net> References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> Date: Tue, 1 Nov 2011 11:18:57 -0700 Message-ID: Subject: Re: [vpn4dc] Question on the problem From: Pedro Marques To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: L3VPN , Fred Baker 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 18:19:44 -0000 On Tue, Nov 1, 2011 at 11:02 AM, Robert Raszuk wrote: > > Do you think that it is acceptable of arbitrary host in the internet to send > IP packet to any other host ? That is a very imprecise question. The "internet" is generally the set of consumer devices plus the web front-ends that provide content. That set of devices gets to exchange traffic. > If not then how are you protecting considering > draft-marques-l3vpn-end-system the datacenter host from being reachable by > anyone ? Data center networks are private networks. Front-end devices talk to both the external network and the private network to fetch data. For most data-centers it would very likely be illegal for the data center machines to be reachable through the internet. There are laws in most countries protecting confidentially of data and having direct access to the internet would most like constitute negligence. It should. Certainly as a consumer i would feel unacceptable if my private data was kept on a system with internet access. By the same token "company-A" VMs should not be able to communicate directly with VMs from "company-B". > > I do not see how is this any more secure as interconnecting VMs over IPsec > and filtering (be it on the host level) any other IP traffic between same > admin-domain groups such VMs are provisioned to be part of. > IPsec is also used to implement private networks. The term VPN also covers IPsec VPNs. Fred's email questions the requirement for VPNs between different admin-domains. Application level authentication is simply not a replacement for a virtual private network. Pedro. From lufang@cisco.com Tue Nov 1 11:28: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 32ABA1F0C8D for ; Tue, 1 Nov 2011 11:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.107 X-Spam-Level: X-Spam-Status: No, score=-4.107 tagged_above=-999 required=5 tests=[AWL=1.292, 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 UZSFi1okLprP for ; Tue, 1 Nov 2011 11:27:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 98B6A21F9467 for ; Tue, 1 Nov 2011 11:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1832; q=dns/txt; s=iport; t=1320172079; x=1321381679; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=HE1l4tiSgzUiPceTuZmL3x8BMecwgKvAa0hPKYGTFeY=; b=aItg75W5UOKpDwo85sJd/aAVDWT3/NA5HbRKiTPRy9tAaZIR2l0mZOBh J3DOVxLTGDgao2t/HHGtTumBZ4AfeUbZdbVCTD9LMm00HziLrsWqj1T8m mTg6Ftt/4qgtzWtiHb7IskrSIEBkiQC90RS1mCmEvmnRYxpNyRVBPZYEu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAAOY4sE6tJXHA/2dsb2JhbABDmWmPXIEFgXIBAQEEEgEdCksEAgEIEQQBAQsGFwEGAUUJCAEBBAESCBMHnncBi0aSZYgmYQSIBpE/jEc X-IronPort-AV: E=Sophos;i="4.69,439,1315180800"; d="scan'208";a="32583622" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 01 Nov 2011 18:26:46 +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 pA1IQkw7007172 for ; Tue, 1 Nov 2011 18:26:46 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, 1 Nov 2011 13:26:46 -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 Q&A Date: Tue, 1 Nov 2011 13:26:43 -0500 Message-ID: <238542D917511A45B6B8AA806E875E250732090C@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: vpn4dc Q&A Thread-Index: AcyYU+vgQoLx0mxOTaeB3XO3f4OVpgAbpf7sAAARyoA= References: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> From: "Luyuan Fang (lufang)" To: "Yiqun Cai (ycai)" , "L3VPN" X-OriginalArrivalTime: 01 Nov 2011 18:26:46.0299 (UTC) FILETIME=[D005D6B0:01CC98C3] 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 18:28:00 -0000 Yiqun, My fear (and a few others' interested in this work) is that if we start it with mcast, we might just end with not going anywhere by looking the history of past many years with mvpn.=20 On the other hand, I'm open to the folks who operate DC to say they must have mcast.=20 Luyuan > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Yiqun Cai (ycai) > Sent: Tuesday, November 01, 2011 2:17 PM > To: L3VPN > Subject: Re: vpn4dc Q&A >=20 >=20 >=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 > If we expect this work to be successful, and if past history is any > indication of what might happen in the future, the moment the solution > gets > deployed people will ask for multicast. Excluding multicast would be a > costly mistake for everyone. >=20 > When multicast was forgot, or declared out of scope, we ended up > spending > more time to "fix" it. I am sure all of us still have fresh memory of > what > l3vpn has been doing since 2004. And in case you are not aware, there > is a > brand new BOF dedicated to solving v4/v6 transition for multicast. >=20 > When multicast was considered from the beginning, (e.g., trill and > l2vpn) > the work is still there but there is less drama. >=20 > Given the nature of the proposed work and its applicable space, I just > don't see how you can avoid multicast down the road. >=20 >=20 >=20 >=20 >=20 > -- > Yiqun From marshall.eubanks@gmail.com Tue Nov 1 11:33: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 6402011E80FD for ; Tue, 1 Nov 2011 11:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.81 X-Spam-Level: X-Spam-Status: No, score=-102.81 tagged_above=-999 required=5 tests=[AWL=-0.411, 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 cWV5VBx39OrX for ; Tue, 1 Nov 2011 11:33:03 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE8AE11E80F6 for ; Tue, 1 Nov 2011 11:33:02 -0700 (PDT) Received: by vws5 with SMTP id 5so7202887vws.31 for ; Tue, 01 Nov 2011 11:30:47 -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=krngDg/ziHM3kRxTPn83SMmsunGfchC5xLYJgNEN7LE=; b=WsGEHl+3AvImMpyBlbSmTZgcWLPUB6Y5JANfefbQ5ng39dkWUYREmEeYXdAcczRrb+ Klmpxh6WS7+qnQ/5Fn8ZWSf/ew+tNGC+cqT20rYXgax3ZEw2OUbhI40JBIP5D4p3i6Vo O4lB9uR4hMij3mB2n22CXxxOGFmSaDZN/IAJg= MIME-Version: 1.0 Received: by 10.182.111.33 with SMTP id if1mr155300obb.29.1320172247421; Tue, 01 Nov 2011 11:30:47 -0700 (PDT) Received: by 10.182.14.65 with HTTP; Tue, 1 Nov 2011 11:30:47 -0700 (PDT) In-Reply-To: <238542D917511A45B6B8AA806E875E250732090C@XMB-RCD-201.cisco.com> References: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> <238542D917511A45B6B8AA806E875E250732090C@XMB-RCD-201.cisco.com> Date: Tue, 1 Nov 2011 14:30:47 -0400 Message-ID: Subject: Re: vpn4dc Q&A From: Marshall Eubanks To: "Luyuan Fang (lufang)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Yiqun Cai \(ycai\)" , L3VPN 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 18:33:03 -0000 On Tue, Nov 1, 2011 at 2:26 PM, Luyuan Fang (lufang) wro= te: > Yiqun, > > My fear (and a few others' interested in this work) is that if we start > it with mcast, we might just end with not going anywhere by looking the > history of past many years with mvpn. > > On the other hand, I'm open to the folks who operate DC to say they must > have mcast. > Are there any drafts now extant that cover multicast for VPN4DC ? Regards Marshall > Luyuan > > >> -----Original Message----- >> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf >> Of Yiqun Cai (ycai) >> Sent: Tuesday, November 01, 2011 2:17 PM >> To: L3VPN >> Subject: Re: vpn4dc Q&A >> >> >> >> > >> > 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. >> > >> >> If we expect this work to be successful, and if past history is any >> indication of what might happen in the future, the moment the solution >> gets >> deployed people will ask for multicast. =A0Excluding multicast would be > a >> costly mistake for everyone. >> >> When multicast was forgot, or declared out of scope, we ended up >> spending >> more time to "fix" it. =A0I am sure all of us still have fresh memory of >> what >> l3vpn has been doing since 2004. =A0And in case you are not aware, there >> is a >> brand new BOF dedicated to solving v4/v6 transition for multicast. >> >> When multicast was considered from the beginning, (e.g., trill and >> l2vpn) >> the work is still there but there is less drama. >> >> Given the nature of the proposed work and its applicable space, =A0I > just >> don't see how you can avoid multicast down the road. >> >> >> >> >> >> -- >> Yiqun > > From pedro.r.marques@gmail.com Tue Nov 1 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 55FF911E813F for ; Tue, 1 Nov 2011 11:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=-0.360, 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 WQJdFr20OmSl for ; Tue, 1 Nov 2011 11:39:49 -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 9938811E80F6 for ; Tue, 1 Nov 2011 11:39:37 -0700 (PDT) Received: by ywt2 with SMTP id 2so8742131ywt.31 for ; Tue, 01 Nov 2011 11:39:37 -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=wKcT1nv8Ypk2wJ1vvIq+Wt61DLZKljsrr9yKlPWx4ZY=; b=eVg2ggalbeOTenyOVFi4dUnvSBuP9YC5Cx1gsI7HXrnZOSP4AA14sl+Pd/SqU60LXW 1L54WUJBuWJaaa60u60F/scbYZDlexyhGeF8VymOs3/rF5XCadT6P3VDnGZtV+BWdEEv ORAJgotNfrGsPmp/oA1o3/e3StVR1Xc8+xL6c= MIME-Version: 1.0 Received: by 10.50.6.202 with SMTP id d10mr534461iga.31.1320172777062; Tue, 01 Nov 2011 11:39:37 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Tue, 1 Nov 2011 11:39:36 -0700 (PDT) In-Reply-To: References: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> Date: Tue, 1 Nov 2011 11:39:36 -0700 Message-ID: Subject: Re: vpn4dc Q&A From: Pedro Marques To: Yiqun Cai Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: L3VPN 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 18:39:50 -0000 Yiqun, There are two different aspects to "multicast". - The service: allowing IP applications to send packets to a group of addresses. - Network state: having IP group state in network devices in the middle of the network. The first (application service) is not commonly offered, in public data-centers. Applications do not rely on it and use different strategy for discovery and content distribution. The second has very significant scaling and operational challenges at large scale. Specially if you consider the topology of a DC network. One can offer a "multicast" service via ingress replication or by using replication servers in a tree. The latter approach (tree of replicators) can be implemented on top of a unicast service for those apps that are looking for a discovery service. But there are simpler / more effective ways to provide discovery. regards, Pedro. On Tue, Nov 1, 2011 at 11:17 AM, Yiqun Cai wrote: > If we expect this work to be successful, and if past history is any > indication of what might happen in the future, the moment the solution ge= ts > deployed people will ask for multicast. =A0Excluding multicast would be a > costly mistake for everyone. > > When multicast was forgot, or declared out of scope, we ended up spending > more time to "fix" it. =A0I am sure all of us still have fresh memory of = what > l3vpn has been doing since 2004. =A0And in case you are not aware, there = is a > brand new BOF dedicated to solving v4/v6 transition for multicast. > > When multicast was considered from the beginning, (e.g., trill and l2vpn) > the work is still there but there is less drama. > > Given the nature of the proposed work and its applicable space, =A0I just > don't see how you can avoid multicast down the road. > > > > > > -- > Yiqun > > From robert@raszuk.net Tue Nov 1 11:52: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 09CE411E815C for ; Tue, 1 Nov 2011 11:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.223, 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 TYbZ0yICoMlQ for ; Tue, 1 Nov 2011 11:52:43 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 641A711E814E for ; Tue, 1 Nov 2011 11:52:43 -0700 (PDT) Received: (qmail 866 invoked by uid 399); 1 Nov 2011 18:49:51 -0000 Received: from unknown (HELO ?216.69.73.167?) (216.69.73.167) by mail37.opentransfer.com with SMTP; 1 Nov 2011 18:49:51 -0000 Message-ID: <4EB03F4E.1030804@raszuk.net> Date: Tue, 01 Nov 2011 19:49:50 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Yiqun Cai Subject: Re: vpn4dc Q&A References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN 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, 01 Nov 2011 18:52:44 -0000 Hi Yiqun, I think the priority given to support multicast really depends on the planned scope of given VM to VM data exchange models. I could easily see large use cases for non-multicast enabled secured inter-VM or VM to end user connectivity. Especially in cases where VM to VM connectivity is not locked to particular service provider support of real multicast may as Pedro just observed performed by ingress replication. Alternatively other ways to efficiently distribute content could be utilized in the application space. Best, R. >> 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. >> > > If we expect this work to be successful, and if past history is any > indication of what might happen in the future, the moment the solution gets > deployed people will ask for multicast. Excluding multicast would be a > costly mistake for everyone. > > When multicast was forgot, or declared out of scope, we ended up spending > more time to "fix" it. I am sure all of us still have fresh memory of what > l3vpn has been doing since 2004. And in case you are not aware, there is a > brand new BOF dedicated to solving v4/v6 transition for multicast. > > When multicast was considered from the beginning, (e.g., trill and l2vpn) > the work is still there but there is less drama. > > Given the nature of the proposed work and its applicable space, I just > don't see how you can avoid multicast down the road. From robert@raszuk.net Tue Nov 1 12:16:35 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 D604C11E80BA for ; Tue, 1 Nov 2011 12:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.396, 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 MClGFCXw6t7R for ; Tue, 1 Nov 2011 12:16:35 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 2AF0A11E80B8 for ; Tue, 1 Nov 2011 12:16:35 -0700 (PDT) Received: (qmail 12307 invoked by uid 399); 1 Nov 2011 19:16:07 -0000 Received: from unknown (HELO ?216.69.73.167?) (216.69.73.167) by mail37.opentransfer.com with SMTP; 1 Nov 2011 19:16:07 -0000 Message-ID: <4EB04576.1010905@raszuk.net> Date: Tue, 01 Nov 2011 20:16:06 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Pedro Marques Subject: Re: [vpn4dc] Question on the problem References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN , Fred Baker 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, 01 Nov 2011 19:16:35 -0000 Hi Pedro, > Data center networks are private networks. Front-end devices talk to > both the external network and the private network to fetch data. > > For most data-centers it would very likely be illegal for the data > center machines to be reachable through the internet. There are laws > in most countries protecting confidentially of data and having direct > access to the internet would most like constitute negligence. It > should. Certainly as a consumer i would feel unacceptable if my > private data was kept on a system with internet access. How would you envision practically to open holes in the current data center security model for GRE tunnels to reach data center hosts ? Would it be automated or manual operation ? Perhaps considering this discussion it could be great to update any set of proposals with such details. Considering model proposed in your draft I do not think this is out of scope. However if VMs would be able to initiate a VPN it may be just VPN membership discovery server allocating required VPN credentials which would seemed required. I am of the opinion that host OS given VMs are build over should not be involved in VM to VM secure inter-connectivity. > By the same token "company-A" VMs should not be able to > communicate directly with VMs from "company-B". That is in fact another reason why such VPN isolation should rather not require configuration of number of other elements then VMs itself. > Fred's email questions the requirement for VPNs between different > admin-domains. Application level authentication is simply not a > replacement for a virtual private network. The way I read Fred's message is not that. I think he just questions why only MPLS-VPN model should be used as VM to VM VPN solution. Thx, R. From marshall.eubanks@gmail.com Tue Nov 1 12:35: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 99C261F0CB0 for ; Tue, 1 Nov 2011 12:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.803 X-Spam-Level: X-Spam-Status: No, score=-102.803 tagged_above=-999 required=5 tests=[AWL=-0.404, 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 uILEZahbzzz2 for ; Tue, 1 Nov 2011 12:35:42 -0700 (PDT) Received: from mail-dy0-f44.google.com (mail-dy0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 689391F0CAE for ; Tue, 1 Nov 2011 12:35:42 -0700 (PDT) Received: by dyl37 with SMTP id 37so35161dyl.31 for ; Tue, 01 Nov 2011 12:34:00 -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=ZDnoEpM2UkG67CkhTh3/bvpgWvUYasKUrDmWWKbGOcY=; b=BuHk9mY2QajA8T00sr9O8Y9Np/J2ewcc64BwS0cBdfzic+XWIyEkKe72r777NiocEG SGu9xxt22GWOHDlpveKMg7MyD5FXOFGaiC/LbiDxA4rxHiplGSWGb4RZijPy8BwoWZLW P+VWmr5y3NnhqxMdR8REsD3LNzVGokd2ZRo5s= MIME-Version: 1.0 Received: by 10.182.77.164 with SMTP id t4mr221702obw.9.1320176039608; Tue, 01 Nov 2011 12:33:59 -0700 (PDT) Received: by 10.182.14.65 with HTTP; Tue, 1 Nov 2011 12:33:59 -0700 (PDT) In-Reply-To: References: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> Date: Tue, 1 Nov 2011 15:33:59 -0400 Message-ID: Subject: Re: vpn4dc Q&A From: Marshall Eubanks To: Pedro Marques Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Yiqun Cai , L3VPN 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 19:35:43 -0000 On Tue, Nov 1, 2011 at 2:39 PM, Pedro Marques w= rote: > Yiqun, > There are two different aspects to "multicast". > =A0- The service: allowing IP applications to send packets to a group > of addresses. > =A0- Network state: having IP group state in network devices in the > middle of the network. > > The first (application service) is not commonly offered, in public > data-centers. Applications do not rely on it and use different > strategy for discovery and content distribution. > > The second has very significant scaling and operational challenges at > large scale. Specially if you consider the topology of a DC network. > > One can offer a "multicast" service via ingress replication or by > using replication servers in a tree. The latter approach (tree of > replicators) can be implemented on top of a unicast service for those > apps that are looking for a discovery service. But there are simpler / > more effective ways to provide discovery. If there is any significant video transport, and in particular if IPTV services are being offered, multicast is going to become an issue. I believe that is what drove the Multicast VPN work at L3VPN originally. Regards Marshall > > regards, > =A0Pedro. > > On Tue, Nov 1, 2011 at 11:17 AM, Yiqun Cai wrote: > >> If we expect this work to be successful, and if past history is any >> indication of what might happen in the future, the moment the solution g= ets >> deployed people will ask for multicast. =A0Excluding multicast would be = a >> costly mistake for everyone. >> >> When multicast was forgot, or declared out of scope, we ended up spendin= g >> more time to "fix" it. =A0I am sure all of us still have fresh memory of= what >> l3vpn has been doing since 2004. =A0And in case you are not aware, there= is a >> brand new BOF dedicated to solving v4/v6 transition for multicast. >> >> When multicast was considered from the beginning, (e.g., trill and l2vpn= ) >> the work is still there but there is less drama. >> >> Given the nature of the proposed work and its applicable space, =A0I jus= t >> don't see how you can avoid multicast down the road. >> >> >> >> >> >> -- >> Yiqun >> >> > From ben@niven-jenkins.co.uk Tue Nov 1 12:53: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 E282221F8EAB for ; Tue, 1 Nov 2011 12:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.839 X-Spam-Level: X-Spam-Status: No, score=-102.839 tagged_above=-999 required=5 tests=[AWL=-0.440, 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 oqSnC9E54k4F for ; Tue, 1 Nov 2011 12:53:36 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id B7DB221F8D1D for ; Tue, 1 Nov 2011 12:53:35 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-125-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RLK0o-0002E8-5x for l3vpn@ietf.org; Tue, 01 Nov 2011 19:28:42 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: L3VPN WG status Date: Tue, 1 Nov 2011 19:28:41 +0000 Message-Id: <8576CEA8-CB29-4D84-9425-38C99E3D1A84@niven-jenkins.co.uk> 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: Tue, 01 Nov 2011 19:53:37 -0000 Colleagues, Although we currently have a face to face session in Taipei to discuss = VPN4DC I wasn't planning on using any of that time to provide a more = general L3VPN update so please find below a status update on the current = status of work within L3VPN (ahead of IETF for once). Ben 1. DRAFTS PUBLISHED RFC 6368 (draft-ietf-l3vpn-ibgp). 2. DRAFTS IN THE RFC EDITOR QUEUE A. draft-ietf-l3vpn-2547bis-mcast The referenced drafts that were holding this up in the RFC Editor queue = have now been approved for publication and it is just awaiting = processing & publication. B. draft-ietf-l3vpn-2547bis-mcast-bgp As this was held up by a reference to draft-ietf-l3vpn-2547bis-mcast it = is now just awaiting processing and publishing. C. draft-ietf-l3vpn-mvpn-considerations As this was held up by references to draft-ietf-l3vpn-2547bis-mcast & = draft-ietf-l3vpn-2547bis-mcast-bgp it is now just awaiting processing = and publishing. D. draft-ietf-l3vpn-mvpn-spmsi-joins As this was held up by a reference to draft-ietf-l3vpn-2547bis-mcast it = is now just awaiting processing and publishing. E. draft-ietf-l3vpn-mvpn-infra-addrs As this was held up by references to draft-ietf-l3vpn-2547bis-mcast & = draft-ietf-l3vpn-2547bis-mcast-bgp it is now just awaiting processing = and publishing. F. draft-ietf-l3vpn-ospfv3-pece Publication has been requested for this draft and it is awaiting IESG = approval. 3. DRAFT IN OR PAST WG LAST CALL None. 4. ACTIVE WG DRAFTS A. draft-ietf-l3vpn-acceptown-community No change since IETF79. The authors believe the draft is complete but = would prefer to wait for an implementation to be produced before = proceeding to WG LC. B. draft-ietf-l3vpn-mvpn-bidir This was accepted as a WG draft on 5th August 2011. C. draft-ietf-l3vpn-mvpn-wildcards This was accepted as a WG draft on 17th September 2011. 5. EXPIRED DRAFTS None. 6. OTHER WG WORK / ISSUES / ETC. draft-rosen-l3vpn-mvpn-extranet & = draft-raggarwa-l3vpn-bgp-mvpn-extranet No change since IETF81. The authors are still working to merge these two = drafts into a single combined draft and following the merge we will poll = the WG to judge consensus to adopt the merged draft as a WG draft. From pedro.r.marques@gmail.com Tue Nov 1 12:55: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 A7A0F1F0CE1 for ; Tue, 1 Nov 2011 12:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 vL3yD6ggCn1I for ; Tue, 1 Nov 2011 12:55:46 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03AF71F0CD5 for ; Tue, 1 Nov 2011 12:55:45 -0700 (PDT) Received: by qadc10 with SMTP id c10so7824245qad.31 for ; Tue, 01 Nov 2011 12:55:03 -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=37II5YV924mBkNDaqzDNMB6sUMJzjeoV0XFj/ziBRag=; b=DHbOoP/Y6NtSvOKBqw4qSbjUaNF/vCnSN6ac3t65Mn49O9FZMLPUDkjsJdeDJQjt18 86r2/PxdsYfuhvCFIYRjnziJB56scPfkZGiD47ofd4+iPSwwPqiwYET/XM8aMMa5RJZw QunO+KB0B+zmgFQ/KI6rkUiNd2DY9xTZWp/9M= MIME-Version: 1.0 Received: by 10.50.158.227 with SMTP id wx3mr646770igb.52.1320177302541; Tue, 01 Nov 2011 12:55:02 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Tue, 1 Nov 2011 12:55:02 -0700 (PDT) In-Reply-To: <4EB04576.1010905@raszuk.net> References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> <4EB04576.1010905@raszuk.net> Date: Tue, 1 Nov 2011 12:55:02 -0700 Message-ID: Subject: Re: [vpn4dc] Question on the problem From: Pedro Marques To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: L3VPN , Fred Baker 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 19:55:46 -0000 Robert, On Tue, Nov 1, 2011 at 12:16 PM, Robert Raszuk wrote: > Hi Pedro, > > How would you envision practically to open holes in the current data center > security model for GRE tunnels to reach data center hosts ? Several of the problem statement documents envision data-center gateways that interconnect the private VM networks to private enterprise networks. The typical assumption tends to be that the enterprise private network is being transported over MPLS, with a carrier providing the enterprise VPN. You have references to both "option B" interconnects between the DC network and SP networks and also attempts to revive the "option D" approach from years back (per VPN forwarding state with aggregate option B style ebgp session). The same interconnection model would be applicable to a VPN carried over GRE instead of MPLS, i believe. In a similar vain the the interconnect can be a simple IPsec tunnel from the enterprise side plus a web app configuring its respective IP prefixes. This is the model in use today in the most common public services. > > Would it be automated or manual operation ? Perhaps considering this > discussion it could be great to update any set of proposals with such > details. Considering model proposed in your draft I do not think this is out > of scope. This is certainly within the scope of the problem statement drafts and more than one touch on the issue, although not in enough detail in order to describe a solution (which makes sense since they are problem statements). > > However if VMs would be able to initiate a VPN it may be just VPN membership > discovery server allocating required VPN credentials which would seemed > required. The requirement here is the inverse. The VM is imposed a private network topology. > > I am of the opinion that host OS given VMs are build over should not be > involved in VM to VM secure inter-connectivity. The host OS is already involved. The host OS must ensure containment between VMs and must ensure that a VM cannot spill over to other VM in the same host and in anyway read its memory influence it. > The way I read Fred's message is not that. I think he just questions why > only MPLS-VPN model should be used as VM to VM VPN solution. There are many technologies capable of delivering VPNs and it is reasonable to discuss the pros and cons of each. Pedro. From pedro.r.marques@gmail.com Tue Nov 1 13:03: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 BE90611E8191 for ; Tue, 1 Nov 2011 13:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.343, 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 w+1SGlT0e-vr for ; Tue, 1 Nov 2011 13:03:28 -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 52B9011E8185 for ; Tue, 1 Nov 2011 13:03:28 -0700 (PDT) Received: by iaeo4 with SMTP id o4so1213544iae.31 for ; Tue, 01 Nov 2011 13:02:23 -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=AARQ0vaoc1PuuKVsfdbngU+3CNPO0QcMTlADznrCfvI=; b=hPsxdTyxAb781ICheQmNe9aYIVaAFWXMsxd9cMDYb5FzA8uSIA86CzHgMcCIhYJO7U 6jLKpI4Xd90BayuN55ykm7b6ZWuhcpKZjoSIDzvPljiUv+ro6K1iS8Tf7ej8/HedLbQI R10R/h+9jM9JJ4d5kftx8B8Am4rNl9D+W7miI= MIME-Version: 1.0 Received: by 10.231.28.209 with SMTP id n17mr177388ibc.89.1320177743584; Tue, 01 Nov 2011 13:02:23 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Tue, 1 Nov 2011 13:02:23 -0700 (PDT) In-Reply-To: References: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> Date: Tue, 1 Nov 2011 13:02:23 -0700 Message-ID: Subject: Re: vpn4dc Q&A From: Pedro Marques To: Marshall Eubanks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Yiqun Cai , L3VPN 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 20:03:28 -0000 Marshall, Content delivery networks are a very interesting topic but i believe orthogonal to the "DC" conversation. My understanding (probably an urban myth) is that the main driver behind l3vpn multicast support was "stock ticker" style applications. i.e. non-guaranteed delivery of repeated information in which the sender explicitly doesn't want to control the order of the receivers. That functionality can be supported via a tree of replication servers. The most important characteristic is probably that the sender doesn't control order. Pedro. > > If there is any significant video transport, and in particular if IPTV > services are being offered, multicast is going to become an issue. > I believe that is what drove =A0the Multicast VPN work at L3VPN originall= y. > From lufang@cisco.com Tue Nov 1 15:20: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 56DBB1F0C53 for ; Tue, 1 Nov 2011 15:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[AWL=1.192, 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 SbDVX0r0NEg1 for ; Tue, 1 Nov 2011 15:19:59 -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 19F921F0C4E for ; Tue, 1 Nov 2011 15:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=17094; q=dns/txt; s=iport; t=1320185999; x=1321395599; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=vrzET2iAYxKm8mxXee/7iEzfRUObY8dFA0tWp6b6p7I=; b=lEmbqsq4SfCZ04DTaXXEjwp/OjCyCrRjJYqNOwyB80cAqt6S2ZW95ALk auT9rNyWhNHHxXvmtGEqbnCjAZ9ooUg5JkMiFcWHJ4Ugg6op7p425yhY7 hHEOtVBhPn35LbdQTSvXmVnJCVF8DvXWFrZjVjeonwcaMjqRnjax/T0Mv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAAE1vsE6tJV2a/2dsb2JhbABDgk2XH49dgQWBcgEBAQMBEgEJEQNJEAIBCBEDAQEBCwYXAQYBRQkIAQEEEwgMDodglygBniSIJmEEiAaRP4xH X-IronPort-AV: E=Sophos;i="4.69,440,1315180800"; d="scan'208,217";a="32640023" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 01 Nov 2011 22:19:58 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA1MJwl6012328; Tue, 1 Nov 2011 22:19:58 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, 1 Nov 2011 17:19:58 -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_01CC98E4.63B6776C" Subject: RE: vpn4dc Q&A Date: Tue, 1 Nov 2011 17:19:55 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2507320A56@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: vpn4dc Q&A Thread-Index: AcyYbmnM2owfBPs7Sm2OTKENbFzocwAUjhjQ References: From: "Luyuan Fang (lufang)" To: X-OriginalArrivalTime: 01 Nov 2011 22:19:58.0300 (UTC) FILETIME=[63E7C1C0:01CC98E4] 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, 01 Nov 2011 22:20:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC98E4.63B6776C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lizhong, =20 Thanks for your comments. See in-line. Luyuan =20 From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn]=20 Sent: Tuesday, November 01, 2011 4:15 AM To: Luyuan Fang (lufang) Cc: l3vpn@ietf.org Subject: Re: vpn4dc Q&A =20 Hi Luyuan,=20 Thanks for initiating this discussion. Please see my comments in line.=20 Regards=20 Lizhong=20 > ------------------------------ >=20 > Message: 3 > Date: Tue, 1 Nov 2011 00:05:49 -0500 > From: "Luyuan Fang (lufang)" > To: "L3VPN" > Subject: vpn4dc Q&A > Message-ID: > <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi all, >=20 > =20 >=20 > There are a few things around vpn4dc I'd like to kick off the > discussion. >=20 > I put my simple answers to each question, very much like to hear yours. >=20 > =20 >=20 > 1 What are we trying to achieve in vpn4dc?=20 >=20 > - DC Host-to-host connectivity through layer 3 signaling > protocols. >=20 > 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 [Lizhong] I try to suggest to change "host-to-host connectivity" to "host connectivity". Host-to-host is a bit easy to misunderstand with point-to-point or end-to-end, while L3VPN will provide multipoint-to-multipoint IP connection for hosts.=20 [Luyuan] I really meant any-to-any VPN connections. P2P, partial mesh would be degenerated cases of any-to-any. May be I should change the wording later. > =20 >=20 > 2. What cannot be achieved through L3VPN today? >=20 > - We don't have a stds way for host-to-host vpn connectivity > through protocols signaling which easily work in DC.=20 >=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. >=20 > - And this is no long SP provisioned vpns, it has wider scope.=20 [Lizhong] agree, and I think VPN4DC does not intend to achieve host connectivity only by L3VPN, and L3VPN is only deployed in some network segment, e.g, provider's network, part of DC network. L3VPN is not always BGP/MPLS VPN based, VRF-lite can also be deployed in DC network.=20 >=20 > =20 >=20 > 3. What is missing? >=20 > The missing piece is the segment in DC and > inter-connection/auto-mapping of the DC segment to the network segment.=20 [Lizhong] I am not clear with the missing piece of segment in DC. I think VPN segment in DC is mixed with L2&L3 VPN. And I agree inter-connection/auto-mapping is the missing piece.=20 [Luyuan] points taken.=20 >=20 > =20 >=20 > 4. Is this IETF problem? >=20 > - Yes. It is about IP protocols for establish connectivity.=20 [Lizhong] agree.=20 >=20 > =20 >=20 > 5. Who wants this?=20 >=20 > Please speak out if you do. >=20 > =20 >=20 > 6. What are not in scope for this initiative/charter? >=20 > - L2VPN for DC connectivity - that goes to L2VPN WG >=20 > - Encryption, key management, new authentication protocols - these go to > Security Area. >=20 > - 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 > =20 >=20 > Looking forward seeing your comments to any of the questions. >=20 > =20 >=20 > Thanks, >=20 > Luyuan >=20 > =20 >=20 > =20 =20 -------------------------------------------------------- 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. ------_=_NextPart_001_01CC98E4.63B6776C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lizhong,

 

Thanks for your comments. See = in-line.

Luyuan

 

From:= lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn]
Sent: Tuesday, November 01, 2011 4:15 AM
To: Luyuan Fang (lufang)
Cc: l3vpn@ietf.org
Subject: Re: vpn4dc Q&A

 


Hi = Luyuan,
Thanks = for initiating this discussion. Please see my comments in line.

Regards
Lizhong



> ------------------------------
>
> Message: 3
> Date: Tue, 1 Nov 2011 00:05:49 -0500
> From: "Luyuan Fang (lufang)" = <lufang@cisco.com>
> To: "L3VPN" <l3vpn@ietf.org>
> Subject: vpn4dc Q&A
> Message-ID:
>   =  <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com&= gt;
> Content-Type: text/plain; = charset=3D"us-ascii"
>
> 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.
>
[Lizhong] I try to suggest to = change "host-to-host connectivity" to "host connectivity". Host-to-host is a bit easy to misunderstand with point-to-point or = end-to-end, while L3VPN will provide multipoint-to-multipoint IP connection for = hosts.

[Luyuan] I really = meant any-to-any VPN connections. P2P, partial mesh would be degenerated cases = of any-to-any. May be I should change the wording later.

> =  


>
> 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.
[Lizhong] agree, and I think VPN4DC = does not intend to achieve host connectivity only by L3VPN, and L3VPN is only = deployed in some network segment, e.g, provider's network, part of DC network. = L3VPN is not always BGP/MPLS VPN based, VRF-lite can also be deployed in DC = network.

>
>  
>
> 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.
[Lizhong] I am not clear with the = missing piece of segment in DC. I think VPN segment in DC is mixed with = L2&L3 VPN. And I agree inter-connection/auto-mapping is the missing = piece.


[Luyuan] points taken. =

> =
>  
>
> 4. Is this IETF problem?
>
> - Yes. It is about IP protocols for establish = connectivity.
[Lizhong] agree.

>
>  
>
> 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
>
>  
>
>  

 
----------------------------------------=
----------------
ZTE Information Security&=
nbsp;Notice: The information contained in this&n=
bsp;mail is solely property of the sender's=
 organization. This mail communication is c=
onfidential. Recipients named above are obligate=
d to maintain secrecy and are not perm=
itted to disclose the contents of this =
;communication to others.
This email&=
nbsp;and any files transmitted with it are&=
nbsp;confidential and intended solely for the&nb=
sp;use of the individual or entity to =
whom they are addressed. If you have r=
eceived this email in error please notify&n=
bsp;the originator of the message. Any view=
s expressed in this message are those =
of the individual sender.
This m=
essage has been scanned for viruses and&nbs=
p;Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01CC98E4.63B6776C-- From lufang@cisco.com Tue Nov 1 15:40: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 0C02E21F9CBE for ; Tue, 1 Nov 2011 15:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.992 X-Spam-Level: X-Spam-Status: No, score=-3.992 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, 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 g5aPzoR8rY3C for ; Tue, 1 Nov 2011 15:40:57 -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 2003821F9CBD for ; Tue, 1 Nov 2011 15:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=4267; q=dns/txt; s=iport; t=1320187257; x=1321396857; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1i/OaHLQ+FYepHv3cCUe6r1HLSHiYx6VEpiIysjveUU=; b=XMedxZJ5M7wcKDKruLi8WgFGssCr2Vk6G/49dpwvgNpVEx0nZKi79WP4 B4DNrQw7k5mIescL0BfcftJwwR9quZ7mlYmidYxhzsMYGNLlfVxGCna2E M7V9y+buBI/2yFDXBt0mFBHdUCMDVPanqgoWsJVKMfx+zU48xIjEC3wQX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAAMR0sE6tJV2b/2dsb2JhbABDmWyPXYEFgXIBAQEDARIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEEwgMBweHYJcuAZ4kiCZhBIgGkT+MRw X-IronPort-AV: E=Sophos;i="4.69,440,1315180800"; d="scan'208";a="32623455" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 01 Nov 2011 22:40:56 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA1Mf5L5031784; Tue, 1 Nov 2011 22:41:05 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 17:40:56 -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 Q&A Date: Tue, 1 Nov 2011 17:40:53 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2507320A5A@XMB-RCD-201.cisco.com> In-Reply-To: <4EAFE66A.90004@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: vpn4dc Q&A Thread-Index: AcyYkg5MOGK7YWppRziUPTyEc/F/egAUo8Ng References: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> <4EAFE66A.90004@raszuk.net> From: "Luyuan Fang (lufang)" To: X-OriginalArrivalTime: 01 Nov 2011 22:40:56.0365 (UTC) FILETIME=[51C53DD0:01CC98E7] Cc: L3VPN 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 22:40:58 -0000 Rob, Thanks for your comments, see in-line. > -----Original Message----- > From: Robert Raszuk [mailto:robert@raszuk.net] > Sent: Tuesday, November 01, 2011 8:31 AM > To: Luyuan Fang (lufang) > Cc: L3VPN > Subject: Re: vpn4dc Q&A >=20 > Hi Luyuan, >=20 > > 1 What are we trying to achieve in vpn4dc? > > > > - DC Host-to-host connectivity through layer 3 signaling > > protocols. >=20 > I think before we start talking about signalling we need to seriously > discuss auto-discovery. Static model of manual provisioning of VPN > sites > will not address DC host to host connectivity requirements. >=20 Good point. > > 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. >=20 > L3VPNs were indeed successful to interconnect static VPN sites. L3VPNs > however hardly fit the model of interconnection of hosts or mobile > devices like smartphones to be part of same VPN. The reason is that > site > discovery does not exits in L3VPN. The L3VPN discovery is limited to SP > network among SP provisioned sites. That is not sufficient to the set > of > requirements at hand. >=20 We are in agreement here.=20 When we said to bridge the gap, it did not mean to push BGP/MPLS VPN all the way to the host, VMs. > > 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 > One could argue if that is at all required. It is only required to add > DC to traditional L3VPNs or statically build VPNs between VMs residing > on hosts owned by given customer. I do not think that this accurately > reflects the customers flexible computing requirements of today. >=20 > > 4. Is this IETF problem? > > > > - Yes. It is about IP protocols for establish connectivity. >=20 > Agreed. Thx. >=20 > > 5. Who wants this? > > > > Please speak out if you do. >=20 > I think we need more that this. I want to be able to access VPN > resources on demand both in the sites of my company as well as in their > both private and public data centers. And this is all from android or > iphone regardless if I am at home or in the plane. >=20 > I also need to be able to dynamically shop of computing resources among > public clouds when I encounter increased processing demands. >=20 > > 6. What are not in scope for this initiative/charter? > > > > - L2VPN for DC connectivity - that goes to L2VPN WG >=20 > I do not think we need to have different solutions to different types > of > VPNs. If you think about the problem space it should be one button to > switch from L3VPN to L2VPN and not a different IETF WG. >=20 I agree with the points you are making. But I don't think it works for the charter scope to cover all, especially L2VPN recently explicitly added DC solution in the charter, NOV3 also going L2VPN to discuss. There also different set of focus in dealing with IEEE bridges, ARP scaling, etc. in l2. which may not apply in l3.=20 I prefer to keep this charter as l3 only. More manageable to progress the work, and avoid overlapping. It is a good point you made on "one button to switch from L3VPN to L2VPN", I am sure there are many places we need to align effort between l3, l2, and sdn too.=20 > > - Encryption, key management, new authentication protocols - these go > to > > Security Area. >=20 > Disagree. >=20 > > - 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 > I agree. Thx. >=20 > Thx, > R. Luyuan From lufang@cisco.com Tue Nov 1 15:46:02 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 15B861F0C6C for ; Tue, 1 Nov 2011 15:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.345 X-Spam-Level: X-Spam-Status: No, score=-4.345 tagged_above=-999 required=5 tests=[AWL=1.053, 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 D8K5AfhqHIMz for ; Tue, 1 Nov 2011 15:46:00 -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 A37351F0C36 for ; Tue, 1 Nov 2011 15:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=16823; q=dns/txt; s=iport; t=1320187559; x=1321397159; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=kclCnECTDV8Bcq1j/dyqB12Ba/pZO0Vj3LinzlBpdN4=; b=lHDZVhguHMO10sj0rzu2gFS/DeauxiHc/ljfVzuLN871GTTJZrG87V82 c9eSi3pdo3PTaT1RCAJTO6v3vHkMu8V7wdePu/M5WW0Jg3QK5LpACbQF7 LmO/mGO2/TNLv5BOh3eJoO1g+SNMj0mwSkK/idoLiTf+9exd8HACFhQRC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAALV1sE6tJXHB/2dsb2JhbABDgk2XH49dgQWBcgEBAQQSAQkRA1kCAQgRBAEBCwYXAQYBRQkIAQEEARIIDAcHnxQBniSIJmEEiAaRP4xH X-IronPort-AV: E=Sophos;i="4.69,440,1315180800"; d="scan'208,217";a="32633917" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 01 Nov 2011 22:45:59 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pA1MjxkE000953; Tue, 1 Nov 2011 22:45:59 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, 1 Nov 2011 17:45:58 -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_01CC98E8.05CC9CC4" Subject: RE: vpn4dc Q&A Date: Tue, 1 Nov 2011 17:45:52 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2507320A5E@XMB-RCD-201.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D118D60B8@dfweml505-mbx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: vpn4dc Q&A Thread-Index: AcyYU+vgQoLx0mxOTaeB3XO3f4OVpgAU2/JAABAFkrA= References: <238542D917511A45B6B8AA806E875E2507320690@XMB-RCD-201.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D118D60B8@dfweml505-mbx> From: "Luyuan Fang (lufang)" To: "Lucy yong" , "L3VPN" X-OriginalArrivalTime: 01 Nov 2011 22:45:58.0835 (UTC) FILETIME=[060E8030:01CC98E8] 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 22:46:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC98E8.05CC9CC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lucy, =20 Thanks for commenting, I'm good with your points. Luyuan =20 From: Lucy yong [mailto:lucy.yong@huawei.com]=20 Sent: Tuesday, November 01, 2011 11:31 AM To: Luyuan Fang (lufang); L3VPN Subject: RE: vpn4dc Q&A =20 Please see my comments below. Lucy =20 From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Luyuan Fang (lufang) Sent: Tuesday, November 01, 2011 12:06 AM To: L3VPN Subject: vpn4dc Q&A =20 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. [[LY]] Agree. There are many ways to form a hosts' private virtual network: via L3VPN, L2VPN, overlay VPN, or hybrid of them. My understanding is VPN4DC aiming on L3VPN solution because SPs have business cases on it, and it makes the work scope very clear.=20 =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. [[LY]] Today L3VPN provides the connectivity among the connected sites, or say DC sites but it does not have the control on the hosts at the sites. VPN4DC requires the admission control on host joining/leaving via in-band signaling.=20 =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. [[LY]] VPN4DC does not have any assumption in DC now. Thus, it addresses some use case, but not all. It makes the problem clear in this way. =20 4. Is this IETF problem? - Yes. It is about IP protocols for establish connectivity. [[LY]] agree. =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_01CC98E8.05CC9CC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lucy,

 

Thanks for = commenting, I’m good with your points.

Luyuan

 

From:= Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, November 01, 2011 11:31 AM
To: Luyuan Fang (lufang); L3VPN
Subject: RE: vpn4dc Q&A

 

Please see my = comments below.

Lucy

 

From:= l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of = Luyuan Fang (lufang)
Sent: Tuesday, November 01, 2011 12:06 AM
To: L3VPN
Subject: vpn4dc Q&A

 

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.

[[LY]] Agree. = There are many ways to form a hosts’ private virtual network: via L3VPN, = L2VPN, overlay VPN, or hybrid of them. My understanding is VPN4DC aiming on = L3VPN solution because SPs have business cases on it, and it makes the work = scope very clear.

 

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.

[[LY]] Today = L3VPN provides the connectivity among the connected sites, or say DC sites but = it does not have the control on the hosts at the sites. VPN4DC requires the admission control on host joining/leaving via in-band signaling. =

 

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.

[[LY]] VPN4DC = does not have any assumption in DC now. Thus, it addresses some use case, but not = all. It makes the problem clear in this way.

 

4. Is this IETF problem?

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

[[LY]] = agree.

 

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_01CC98E8.05CC9CC4-- From ycai@cisco.com Tue Nov 1 16:06:32 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 4B38221F9E1C for ; Tue, 1 Nov 2011 16:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 dwQWPTr5djxB for ; Tue, 1 Nov 2011 16:06:31 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B9B0321F9E19 for ; Tue, 1 Nov 2011 16:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=2366; q=dns/txt; s=iport; t=1320188791; x=1321398391; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=HBTj5Xy4YxFc/ThYIhnzOIqS3+qMiYqXilwuCZXkZ14=; b=NYDdF2bsOLvEAIQ5WaiSjejOoKDUBnC87PjlEzxJhlTwvxHZEQ2uzBou zKvbMRFWcHpIMnR/3wDhCTh2sKSs3yBqjN3wxw5rG+6VUdNEv99x8HfIF tH3ufNpSPAKNRdcOezTQ/1X6AzqjIHFvUI3kP5DLbIjXiywp1XRGRpDOx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooGANV6sE6rRDoH/2dsb2JhbAA7CIk/oAgCgQWBcgEBAQMBEgEnAgE8BQ0BCIEdAQEEDgUbB4dglyYBi0aSYIVbgywEiAaMCYU2iBuELg X-IronPort-AV: E=Sophos;i="4.69,440,1315180800"; d="scan'208";a="11744145" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 01 Nov 2011 23:06:31 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA1N6VUx024886; Tue, 1 Nov 2011 23:06:31 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 16:06:31 -0700 Received: from 128.107.161.220 ([128.107.161.220]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Nov 2011 23:06:30 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 01 Nov 2011 16:06:29 -0700 Subject: Re: vpn4dc Q&A From: Yiqun Cai To: Robert Raszuk Message-ID: Thread-Topic: vpn4dc Q&A Thread-Index: AcyY6uNKr+XV/tqClkGBOJpDaKw+Gw== In-Reply-To: <4EB03F4E.1030804@raszuk.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Nov 2011 23:06:31.0288 (UTC) FILETIME=[E4A7E780:01CC98EA] Cc: L3VPN 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 23:06:32 -0000 Luyang, Pedro, Robert, If I understand your replies correctly, what you are saying is not that "multicast is out of scope". Rather, it is that if there is the need to do multicast, whether at application or IP layer, and whether from within the data center or inside the networks that connect the data centers, it will be addressed by unicast replication. If that is the point, then we should say it explicitly. Thanks. On 11/1/11 11:49 AM, "Robert Raszuk" wrote: > Hi Yiqun, > > I think the priority given to support multicast really depends on the > planned scope of given VM to VM data exchange models. > > I could easily see large use cases for non-multicast enabled secured > inter-VM or VM to end user connectivity. > > Especially in cases where VM to VM connectivity is not locked to > particular service provider support of real multicast may as Pedro just > observed performed by ingress replication. > > Alternatively other ways to efficiently distribute content could be > utilized in the application space. > > Best, > R. > > >>> 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. >>> >> >> If we expect this work to be successful, and if past history is any >> indication of what might happen in the future, the moment the solution gets >> deployed people will ask for multicast. Excluding multicast would be a >> costly mistake for everyone. >> >> When multicast was forgot, or declared out of scope, we ended up spending >> more time to "fix" it. I am sure all of us still have fresh memory of what >> l3vpn has been doing since 2004. And in case you are not aware, there is a >> brand new BOF dedicated to solving v4/v6 transition for multicast. >> >> When multicast was considered from the beginning, (e.g., trill and l2vpn) >> the work is still there but there is less drama. >> >> Given the nature of the proposed work and its applicable space, I just >> don't see how you can avoid multicast down the road. > > -- Yiqun From ccie15672@yahoo.com Tue Nov 1 16:27: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 498C721F9F52 for ; Tue, 1 Nov 2011 16:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 CvKmNAvKpBxw for ; Tue, 1 Nov 2011 16:27:15 -0700 (PDT) Received: from nm4-vm0.bullet.mail.bf1.yahoo.com (nm4-vm0.bullet.mail.bf1.yahoo.com [98.139.213.129]) by ietfa.amsl.com (Postfix) with SMTP id 6761B21F9F51 for ; Tue, 1 Nov 2011 16:27:15 -0700 (PDT) Received: from [98.139.215.142] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2011 23:27:12 -0000 Received: from [98.139.212.251] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2011 23:27:12 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 01 Nov 2011 23:27:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 295574.57752.bm@omp1060.mail.bf1.yahoo.com Received: (qmail 2774 invoked by uid 60001); 1 Nov 2011 23:27:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1320190032; bh=mJ8AszusHvvtAA0lg1PNAa/WYxz9vaeUCEJj1rADBz8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PnZ7L9Jh21Kpthfnb/ez1F+wv1c/MJTl2NU/jclb52UpBsogEBPrGcaHqUQzggldOjvZbGpTInKZuO0PX5YGOznH+FN1EpQlqszY+YS4qgZj7zCBvosZS6/gBOEqn6/8imOFqHdtSXzntkuGGu0cIIqq9ajH8QY8o9929aK9OUw= 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:Cc:In-Reply-To:MIME-Version:Content-Type; b=5wB6MZ73SNQUNg0fRnNUauk7b8xybfwG05A+H2sf42HBZXzyLDaUpV3Hw8jJr5ERaWpkgMk9Jgwi5cwNIG7VjstCxf2PDmfdpK5IEQMjbhVZYvi9q/IkKPyva5bs6EsnuC8go4AgQKjaT+mutaksXjAXo8mrFK1anKKWalIWY9w=; X-YMail-OSG: 5rd9lR4VM1kjLdhAecENagenXAnIR5aM12CdnecRXp5E7sw QPdv7x5x_FYPMCdKdrdx4xEK3WV8rsA95wC6weV_N9HZUKv4EBXhkRLt2Y5A k1PeYlzVzMbdwVcrQ9SejQLQBHWPUxxQ4ZOQgXIPKgb.FXd7LAyD.ZrbJcug Yy7fddgZvtqvxUzIpB6.0iiGn7fLRJWHbE1pc7nJyNf1nD5rI_.LbOhJ7k8i XgHXgS7J1Ybsd_Q5tB9gGl6cgzTfeHZCvkwKjIE13h35yDWWXEodJhNpocF7 D982gM4e.nQh.I0KCO.LyeGphtXGP1AX_hc3b2Z3rP3wds0wCTg7bm.IXbWX Wa1q4HxVr1fKKzbltvwYycEPFt7xkM56YKUngWyLiWDineobkjJuscg9jVho cC5RxkdmQXRchLVpt.ecGG8OkHatsyA6FSYmkwGRdvbC440kY4Rc3N9zdVaa 4EWhV9g-- Received: from [76.194.43.66] by web161801.mail.bf1.yahoo.com via HTTP; Tue, 01 Nov 2011 16:27:11 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> <4EB04576.1010905@raszuk.net> Message-ID: <1320190031.96972.YahooMailNeo@web161801.mail.bf1.yahoo.com> Date: Tue, 1 Nov 2011 16:27:11 -0700 (PDT) From: Derick Winkworth Subject: Re: [vpn4dc] Question on the problem To: "robert@raszuk.net" , Pedro Marques In-Reply-To: <4EB04576.1010905@raszuk.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1882999342-1591591403-1320190031=:96972" Cc: L3VPN , Fred Baker 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, 01 Nov 2011 23:27:16 -0000 --1882999342-1591591403-1320190031=:96972 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Robert:=0A=0A##########=0AThat is in fact another reason why such VPN isola= tion should rather not require configuration of number of other elements th= en VMs itself.=0A=0A#########=0A=0ACan you elaborate on this statement? =A0= On the face of it, I could not disagree more. =A0We absolutely want to cont= ainerize VMs in the network and not have any dependencies at all on configu= ration within the VM itself..=0A=0ADerick=0A=0A=0A_________________________= _______=0AFrom: Robert Raszuk =0ATo: Pedro Marques =0ACc: L3VPN ; Fred Baker =0ASent: Tuesday, November 1, 2011 2:16 PM=0ASubject: Re: [vpn4dc] Que= stion on the problem=0A=0AHi Pedro,=0A=0A> Data center networks are private= networks. Front-end devices talk to=0A> both the external network and the = private network to fetch data.=0A> =0A> For most data-centers it would very= likely be illegal for the data=0A> center machines to be reachable through= the internet. There are laws=0A> in most countries protecting confidential= ly of data and having direct=0A> access to the internet would most like con= stitute negligence. It=0A> should. Certainly as a consumer i would feel una= cceptable if my=0A> private data was kept on a system with internet access.= =0A=0AHow would you envision practically to open holes in the current data = center security model for GRE tunnels to reach data center hosts ?=0A=0AWou= ld it be automated or manual operation ? Perhaps considering this discussio= n it could be great to update any set of proposals with such details. Consi= dering model proposed in your draft I do not think this is out of scope.=0A= =0AHowever if VMs would be able to initiate a VPN it may be just VPN member= ship discovery server allocating required VPN credentials which would seeme= d required.=0A=0AI am of the opinion that host OS given VMs are build over = should not be involved in VM to VM secure inter-connectivity.=0A=0A> By the= same token "company-A" VMs should not be able to=0A> communicate directly = with VMs from "company-B".=0A=0AThat is in fact another reason why such VPN= isolation should rather not require configuration of number of other eleme= nts then VMs itself.=0A=0A> Fred's email questions the requirement for VPNs= between different=0A> admin-domains. Application level authentication is s= imply not a=0A> replacement for a virtual private network.=0A=0AThe way I r= ead Fred's message is not that. I think he just questions why only MPLS-VPN= model should be used as VM to VM VPN solution.=0A=0AThx,=0AR. --1882999342-1591591403-1320190031=:96972 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Robert:

=
##########
That is= in fact another reason why such VPN isolation should rather not require co= nfiguration of number of other elements then VMs itself.
#########

Can you elaborate on this statement?  On the face of it, I= could not disagree more.  We absolutely want to containerize VMs in t= he network and not have any dependencies at all on configuration within the= VM itself..

= Derick

From: Ro= bert Raszuk <robert@raszuk.net>
To: Pedro Marques <pedro.r.marques@gmail.com>
Cc: L3VPN <l3vpn@ietf.org>; Fred B= aker <fred@cisco.com>
Sent:<= /span> Tuesday, November 1, 2011 2:16 PM
Subject: Re: [vpn4dc] Question on the problem

=0AHi Pedro,

> Data center networks are private networks. = Front-end devices talk to
> both the external network and the private= network to fetch data.
>
> For most data-centers it would ver= y likely be illegal for the data
> center machines to be reachable th= rough the internet. There are laws
> in most countries protecting con= fidentially of data and having direct
> access to the internet would = most like constitute negligence. It
> should. Certainly as a consumer= i would feel unacceptable if my
> private data was kept on a system = with internet access.

How would you envision practically to open hol= es in the current data center security model for GRE tunnels to reach data = center hosts ?

Would it be automated or manual operation ? Perhaps c= onsidering this discussion it could be great to update any set of proposals= with such details. Considering model proposed in your draft I do not think this is out of scope.

However if VMs would be able to initiate a VP= N it may be just VPN membership discovery server allocating required VPN cr= edentials which would seemed required.

I am of the opinion that host= OS given VMs are build over should not be involved in VM to VM secure inte= r-connectivity.

> By the same token "company-A" VMs should not be= able to
> communicate directly with VMs from "company-B".

Tha= t is in fact another reason why such VPN isolation should rather not requir= e configuration of number of other elements then VMs itself.

> Fr= ed's email questions the requirement for VPNs between different
> adm= in-domains. Application level authentication is simply not a
> replac= ement for a virtual private network.

The way I read Fred's message i= s not that. I think he just questions why only MPLS-VPN model should be use= d as VM to VM VPN solution.

Thx,
R.


--1882999342-1591591403-1320190031=:96972-- From pedro.r.marques@gmail.com Tue Nov 1 16:38: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 DC5231F0C82 for ; Tue, 1 Nov 2011 16:38:27 -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.300, 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 Tu3OqNrS1a74 for ; Tue, 1 Nov 2011 16:38:27 -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 461901F0C79 for ; Tue, 1 Nov 2011 16:38:27 -0700 (PDT) Received: by iaeo4 with SMTP id o4so1413562iae.31 for ; Tue, 01 Nov 2011 16:38:26 -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=jfj6CKIl19OOPQWjTA2VkpRl+UoblECVa8thPLKCPZc=; b=T85yhlncGU0tnCGo4ZRRaPx+nZhKOo0if70uOEWGfSVRECKWrRJ7b2cwBsb13CPCVr knJVSLeS1qJM1SmuMAEF4V8C2NL31aoK7mYrQ3il3D2vtAvh70gnHRhNLniTCswpzJ9H K5OUrY4IWnUAX1HfuvwPh1bo2VZTuw0FRveH8= MIME-Version: 1.0 Received: by 10.231.21.217 with SMTP id k25mr303506ibb.63.1320190706783; Tue, 01 Nov 2011 16:38:26 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Tue, 1 Nov 2011 16:38:26 -0700 (PDT) In-Reply-To: References: <4EB03F4E.1030804@raszuk.net> Date: Tue, 1 Nov 2011 16:38:26 -0700 Message-ID: Subject: Re: vpn4dc Q&A From: Pedro Marques To: Yiqun Cai Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: L3VPN , Robert Raszuk 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 23:38:28 -0000 Yiqun, My opinion is that: - It is unclear if an IP multicast service to applications is a requirement. As i mentioned both discovery and reliable content distribution tend to be done today without IP multicast service to applications. - Storing IP multicast state in the middle of the network is very likely problematic at the scale required for this class of solutions. A solution for network virtualization must be able to work without storing multicast state in routers and switches. - If it becomes desirable to offer an IP multicast service, for instance because the order of delivery is now no longer controllable by the application, that can be offered as an overlay on top an unicast service. Thus i disagree with your assement that multicast needs to be part of the DC solution from the start. On the other hand, the people interested in discussing multicast solutions should have have a forum in the l3vpn WG since it is already covered in the charter. Pedro. On Tue, Nov 1, 2011 at 4:06 PM, Yiqun Cai wrote: > Luyang, Pedro, Robert, > > If I understand your replies correctly, =A0what you are saying is not tha= t > "multicast is out of scope". =A0Rather, =A0it is that if there is the nee= d to do > multicast, whether at application or IP layer, and whether from within th= e > data center or inside the networks that connect the data centers, it will= be > addressed by unicast replication. > > If that is the point, then we should say it explicitly. > > Thanks. > > On 11/1/11 11:49 AM, "Robert Raszuk" wrote: > >> Hi Yiqun, >> >> I think the priority given to support multicast really depends on the >> planned scope of given VM to VM data exchange models. >> >> I could easily see large use cases for non-multicast enabled secured >> inter-VM or VM to end user connectivity. >> >> Especially in cases where VM to VM connectivity is not locked to >> particular service provider support of real multicast may as Pedro just >> observed performed by ingress replication. >> >> Alternatively other ways to efficiently distribute content could be >> utilized in the application space. >> >> Best, >> R. >> >> >>>> 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. >>>> >>> >>> If we expect this work to be successful, and if past history is any >>> indication of what might happen in the future, the moment the solution = gets >>> deployed people will ask for multicast. =A0Excluding multicast would be= a >>> costly mistake for everyone. >>> >>> When multicast was forgot, or declared out of scope, we ended up spendi= ng >>> more time to "fix" it. =A0I am sure all of us still have fresh memory o= f what >>> l3vpn has been doing since 2004. =A0And in case you are not aware, ther= e is a >>> brand new BOF dedicated to solving v4/v6 transition for multicast. >>> >>> When multicast was considered from the beginning, (e.g., trill and l2vp= n) >>> the work is still there but there is less drama. >>> >>> Given the nature of the proposed work and its applicable space, =A0I ju= st >>> don't see how you can avoid multicast down the road. >> >> > > > -- > Yiqun > > From robert@raszuk.net Tue Nov 1 16: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 74CE01F0C8D for ; Tue, 1 Nov 2011 16:47:00 -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 TSpvt37tFaUK for ; Tue, 1 Nov 2011 16:47:00 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id A01A31F0C89 for ; Tue, 1 Nov 2011 16:46:59 -0700 (PDT) Received: (qmail 31613 invoked by uid 399); 1 Nov 2011 23:46:58 -0000 Received: from unknown (HELO ?192.168.1.57?) (83.24.200.54) by mail37.opentransfer.com with SMTP; 1 Nov 2011 23:46:58 -0000 Message-ID: <4EB084F2.8030702@raszuk.net> Date: Wed, 02 Nov 2011 00:46:58 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Derick Winkworth Subject: Re: [vpn4dc] Question on the problem References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> <4EB04576.1010905@raszuk.net> <1320190031.96972.YahooMailNeo@web161801.mail.bf1.yahoo.com> In-Reply-To: <1320190031.96972.YahooMailNeo@web161801.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN , Fred Baker 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, 01 Nov 2011 23:47:00 -0000 Hi Derick, Very glad you have asked. When I establish a VPN from any of my hosts, from my CE router(s) or from my smartphones I do not tell my providers that I need my device to securely participate in the VPN. I fail to see why adding VM to any VPN would need to be any harder or any different than the examples provided above. Note that VMs can be short lived and placed in arbitrary data center locations on the network. Who do you tell that you need to join a VPN ? In other words if I would like to buy a VM resources from any cloud providers (for example: Amazon, Google ...) all I should need is to log in to such VPN and establish a VPN connection to the rest of my enterprise network - smartphones included. Thx, R. > Robert: > > ########## That is in fact another reason why such VPN isolation > should rather not require configuration of number of other elements > then VMs itself. > > ######### > > Can you elaborate on this statement? On the face of it, I could not > disagree more. We absolutely want to containerize VMs in the network > and not have any dependencies at all on configuration within the VM > itself.. > > Derick From ycai@cisco.com Tue Nov 1 17:47: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 AE55B1F0C38 for ; Tue, 1 Nov 2011 17:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=-1.698, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 BiAcDW6LrPk8 for ; Tue, 1 Nov 2011 17:47:54 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id EC4AB1F0C47 for ; Tue, 1 Nov 2011 17:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=4790; q=dns/txt; s=iport; t=1320194875; x=1321404475; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=9EDJQTWcKj1VW7g8IFt4Y+DFETDZSvHSS0PvhPP5ZII=; b=I6R1z520ksyyyznLr2i1wxW4H45cBfvnp6lREA0fb6Yh4loU1b65k55e SZtSPgf2KWZPPJMgPfTQQu2LKExVh5CxPi9j0ax5YJ/77whpVuF4FWph5 0o13iGtTb01oRCvFzl9xGBLkma5e2CU3mn1kbpFrRkC9RbozdMzBE836U Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEIAEaSsE6rRDoI/2dsb2JhbAA8CIk/nxV7AoEFgXIBAQEDARIBKQE8BQ0BCBhPNgEBBA4FGweHYJcdAYtGklyFXIMsBIdWMIwLhTeFAIMchC4 X-IronPort-AV: E=Sophos;i="4.69,441,1315180800"; d="scan'208";a="11763340" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 02 Nov 2011 00:47:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA20lr5m032122; Wed, 2 Nov 2011 00:47:53 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 17:47:53 -0700 Received: from 128.107.161.220 ([128.107.161.220]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Nov 2011 00:47:53 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 01 Nov 2011 17:47:51 -0700 Subject: Re: vpn4dc Q&A From: Yiqun Cai To: Pedro Marques Message-ID: Thread-Topic: vpn4dc Q&A Thread-Index: AcyY+QxyfxYIOXDUWkOiLyuivaPFtw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 02 Nov 2011 00:47:53.0730 (UTC) FILETIME=[0E12E620:01CC98F9] Cc: L3VPN , Robert Raszuk 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, 02 Nov 2011 00:47:55 -0000 On 11/1/11 4:38 PM, "Pedro Marques" wrote: > Yiqun, >=20 > My opinion is that: > - It is unclear if an IP multicast service to applications is a > requirement. As i mentioned both discovery and reliable content > distribution tend to be done today without IP multicast service to > applications. Pedro, There are applications that are built on multicast. IPTV is one. Market dat= a (including what you referred to as "stock ticker" earlier) is another, both and others are what drive multicast in l3vpn. When IP multicast connectivity is not available but abundant bandwidth is, one might choose to use unicast to support these applications. But that is a different story. We can argue on the percentage of multicast traffic v.s., unicast in any particular network. But in quite a few networks, the percentage number is not zero. > - Storing IP multicast state in the middle of the network is very > likely problematic at the scale required for this class of solutions. I'm not sure I agree. But that is ok. > A solution for network virtualization must be able to work without > storing multicast state in routers and switches. In fact I'm quite fine with the above statement (even though I don't necessarily agree with how you get there). Requirement and solution -wise, unicast replication can indeed be a common denominator. However, merely declaring that multicast is "out of scape" will likely get us into trouble down the road. That was my point. > - If it becomes desirable to offer an IP multicast service, for > instance because the order of delivery is now no longer controllable > by the application, that can be offered as an overlay on top an > unicast service. >=20 > Thus i disagree with your assement that multicast needs to be part of > the DC solution from the start. On the other hand, the people > interested in discussing multicast solutions should have have a forum > in the l3vpn WG since it is already covered in the charter. >=20 > Pedro. >=20 > On Tue, Nov 1, 2011 at 4:06 PM, Yiqun Cai wrote: >> Luyang, Pedro, Robert, >>=20 >> If I understand your replies correctly, =A0what you are saying is not that >> "multicast is out of scope". =A0Rather, =A0it is that if there is the need t= o do >> multicast, whether at application or IP layer, and whether from within t= he >> data center or inside the networks that connect the data centers, it wil= l be >> addressed by unicast replication. >>=20 >> If that is the point, then we should say it explicitly. >>=20 >> Thanks. >>=20 >> On 11/1/11 11:49 AM, "Robert Raszuk" wrote: >>=20 >>> Hi Yiqun, >>>=20 >>> I think the priority given to support multicast really depends on the >>> planned scope of given VM to VM data exchange models. >>>=20 >>> I could easily see large use cases for non-multicast enabled secured >>> inter-VM or VM to end user connectivity. >>>=20 >>> Especially in cases where VM to VM connectivity is not locked to >>> particular service provider support of real multicast may as Pedro just >>> observed performed by ingress replication. >>>=20 >>> Alternatively other ways to efficiently distribute content could be >>> utilized in the application space. >>>=20 >>> Best, >>> R. >>>=20 >>>=20 >>>>> 6. What are not in scope for this initiative/charter? >>>>>=20 >>>>> - L2VPN for DC connectivity - that goes to L2VPN WG >>>>>=20 >>>>> - Encryption, key management, new authentication protocols - these go= to >>>>> Security Area. >>>>>=20 >>>>> - 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 >>>>=20 >>>> If we expect this work to be successful, and if past history is any >>>> indication of what might happen in the future, the moment the solution= gets >>>> deployed people will ask for multicast. =A0Excluding multicast would be = a >>>> costly mistake for everyone. >>>>=20 >>>> When multicast was forgot, or declared out of scope, we ended up spend= ing >>>> more time to "fix" it. =A0I am sure all of us still have fresh memory of= what >>>> l3vpn has been doing since 2004. =A0And in case you are not aware, there= is a >>>> brand new BOF dedicated to solving v4/v6 transition for multicast. >>>>=20 >>>> When multicast was considered from the beginning, (e.g., trill and l2v= pn) >>>> the work is still there but there is less drama. >>>>=20 >>>> Given the nature of the proposed work and its applicable space, =A0I jus= t >>>> don't see how you can avoid multicast down the road. >>>=20 >>>=20 >>=20 >>=20 >> -- >> Yiqun >>=20 >>=20 --=20 Yiqun From ccie15672@yahoo.com Tue Nov 1 18:10: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 4E3891F0C38 for ; Tue, 1 Nov 2011 18:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.714 X-Spam-Level: X-Spam-Status: No, score=0.714 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_50=0.001, 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 dzDkWxDDBU6k for ; Tue, 1 Nov 2011 18:10:43 -0700 (PDT) Received: from nm29.bullet.mail.bf1.yahoo.com (nm29.bullet.mail.bf1.yahoo.com [98.139.212.188]) by ietfa.amsl.com (Postfix) with SMTP id 8C30621F9EAD for ; Tue, 1 Nov 2011 18:10:43 -0700 (PDT) Received: from [98.139.212.145] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2011 01:10:37 -0000 Received: from [98.139.212.197] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 02 Nov 2011 01:10:37 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 02 Nov 2011 01:10:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 960931.76343.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 97529 invoked by uid 60001); 2 Nov 2011 01:10:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1320196237; bh=hs+IOEbcGU9IJD/awwi70/83ZQVCKaAQL2LWYA3IqyU=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tv4jgig2+QQeiGg890bwDJDHZdc9CQNpGig5WyXHFOl78YpvHuZj1Tr87kTfQvGpmdqtimrYrjKt/bfJ6pK3tZykNa7Tva8hPibvCJ6bRFw+t0sHVhH5MSrgtWO71iO3UdujYeNO2Ip0Wqy+PAVVHyJROzFX231aGW15li2vY1o= 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:Cc:In-Reply-To:MIME-Version:Content-Type; b=316pO4gXTzugmBJe0us38Wn+hHt62mA4mqEGB2a56kezfEzGtiQw4c6GzpPg6IjxBAGtd20ErV5nFZDKqvnn/UAQTAb2wJD3RwthEt6yEyoDUHuGa7YCVpE5qqw8aXNYrxoShiY0GBJMUhCFVxQWT3GiB3dD53EHYaIEVePDCsY=; X-YMail-OSG: VRYrKTMVM1nKkovszi7VukkdLiT5EaiPKXq9YEm0RKv42ID n4FerEg1rpCsBhhOznPBXysMll3adk3mUtkytw80l4dBZWC6M9c9IwbZ9aH8 c.MZeDlamVOMjJk0RofpYDSq0cw61MmAoUKXGtwJGAuReSItm_2HteJicjhR HUq6tPSELPnrztjkhD2iLbLQpUKjSBZ9E.tE5rH.xx9QL88YvwpgDFqqLs_k tD8hZIZmwqvpXjqH2PrEUwQeTSuoK_rzx2CCRB5jHG5CIWoxfc3GkvWZTIMn 5FNs9qnk1nUOUy8uDldocmQfLO_25aY_YKFqOLatBElq0ZmO_kshGMvkzWEx PRmu6eHcgNa66F3vhiSq9xPLkJV5c2H41CvFNuyXv7jb613pBeuE1QnZyXxh HhgtJZvSZRZY93B9e20TfTprGgfNv7XPD2xCL_Iq1ulNDertoAoRyuC.8GeK iBH8TTA-- Received: from [76.194.43.66] by web161803.mail.bf1.yahoo.com via HTTP; Tue, 01 Nov 2011 18:10:37 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> <4EB04576.1010905@raszuk.net> <1320190031.96972.YahooMailNeo@web161801.mail.bf1.yahoo.com> <4EB084F2.8030702@raszuk.net> Message-ID: <1320196237.96003.YahooMailNeo@web161803.mail.bf1.yahoo.com> Date: Tue, 1 Nov 2011 18:10:37 -0700 (PDT) From: Derick Winkworth Subject: Re: [vpn4dc] Question on the problem To: "robert@raszuk.net" In-Reply-To: <4EB084F2.8030702@raszuk.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2037608182-1403053287-1320196237=:96003" Cc: L3VPN , Fred Baker 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: Wed, 02 Nov 2011 01:10:50 -0000 ---2037608182-1403053287-1320196237=:96003 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Answers in-line.=0A=0A=0A________________________________=0AFrom: Robert Ra= szuk =0ATo: Derick Winkworth =0ACc:= Pedro Marques ; L3VPN ; Fred Ba= ker =0ASent: Tuesday, November 1, 2011 6:46 PM=0ASubject: R= e: [vpn4dc] Question on the problem=0A=0AHi Derick,=0A=0AVery glad you have= asked.=0A=0A----------=0AWhen I establish a VPN from any of my hosts, from= my CE router(s) or from my smartphones I do not tell my providers that I n= eed my device to securely participate in the VPN.=0A----------=0A=0AYour VP= N is implied. =A0Your VMs are not able to directly communicate with the VMs= of another of Google's customers by default. =A0I wonder how Google achiev= es this separation...=A0=0A=0A-----=0AI fail to see why adding VM to any VP= N would need to be any harder or any different than the examples provided a= bove.=0A----=0A=0AThe complexity is hidden from you in the case of Google o= r Amazon. =A0It would be hidden from the tenant in the case of VPN4DC. =A0t= he difference is that, as a MPLS network operator, the tenant's private net= works already exist at the edge of my data center in the form of virtual-ro= uters. =A0My customers would like the VMs I provision for them to appear na= tive to their L3VPN network. =A0Think virtual-datacenter for private networ= ks.=0A=0A=0A----------=0ANote that VMs can be short lived and placed in arb= itrary data center locations on the network. Who do you tell that you need = to join a VPN ?=0A----------=0A=0AThe tenant tells noone. =A0 I, on the oth= er hand, would like to automate turning up a VM and attaching it to a custo= mers L3VPN so it appears native to their private network and provide the sa= me illusion of simplicity to my tenant as Google or Amazon provides to cust= omers who find internet-based cloud services acceptable.=0A=0A-------=0AIn = other words if I would like to buy a VM resources from any cloud providers = (for example: Amazon, Google ...) all I should need is to log in to such VP= N and establish a VPN connection to the rest of my enterprise network - sma= rtphones included.=0A----------=0A=0AYou realize there is more going on und= er the hood in your example than you have indicated?=0A=0A=0A=0AThx,=0AR.= =0A=0A> Robert:=0A> =0A> ########## That is in fact another reason why such= VPN isolation=0A> should rather not require configuration of number of oth= er elements=0A> then VMs itself.=0A> =0A> #########=0A> =0A> Can you elabor= ate on this statement?=A0 On the face of it, I could not=0A> disagree more.= =A0 We absolutely want to containerize VMs in the network=0A> and not have = any dependencies at all on configuration within the VM=0A> itself..=0A> =0A= > Derick ---2037608182-1403053287-1320196237=:96003 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Answers in-line.

From: Robert Ra= szuk <robert@raszuk.net>
To:= Derick Winkworth <ccie15672@yahoo.com>
Cc: Pedro Marques <pedro.r.marques@gm= ail.com>; L3VPN <l3vpn@ietf.org>; Fred Baker <fred@cisco.com>= ;
Sent: Tuesday, Novemb= er 1, 2011 6:46 PM
Subject:= Re: [vpn4dc] Question on the problem

=0AHi Derick,
Very glad you have asked.

----------
When I establish a VPN fro= m any of my hosts, from my CE router(s) or from my smartphones I do not tel= l my providers that I need my device to securely participate in the VPN.
----------

Your VPN is implied.  Your VMs are not ab= le to directly communicate with the VMs of another of Google's customers by= default.  I wonder how Google achieves this separation... 
=

-----
I fail to see why ad= ding VM to any VPN would need to be any harder or any different than the ex= amples provided above.
----

The complexity is hidden fr= om you in the case of Google or Amazon.  It would be hidden from the t= enant in the case of VPN4DC.  the difference is that, as a MPLS networ= k operator, the tenant's private networks already exist at the edge of my d= ata center in the form of virtual-routers.  My customers would like th= e VMs I provision for them to appear native to their L3VPN network.  Think vi= rtual-datacenter for private networks.


----------
Note that VMs can be short lived and placed in arbitr= ary data center locations on the network. Who do you tell that you need to = join a VPN ?
-------= ---

The tenant tells noone.   = I, on the other hand, would like to automate turning up a VM and attaching it to a c= ustomers L3VPN so it appears native to their private network and provide th= e same illusion of simplicity to my tenant as Google or Amazon provides to = customers who find internet-based cloud services acceptable.

-------
In other words if I= would like to buy a VM resources from any cloud providers (for example: Am= azon, Google ...) all I should need is to log in to such VPN and establish = a VPN connection to the rest of my enterprise network - smartphones include= d.
----------
You realize there = is more going on under the hood in your example than you have indicated?



Thx,
R.

> Robert:
>
> ##= ######## That is in fact another reason why such VPN isolation
> shou= ld rather not require configuration of number of other elements
> the= n VMs itself.
>
> #########
>
> Can you elaborate= on this statement?  On the face of it, I could not
> disagree m= ore.  We absolutely want to containerize VMs in the network
> an= d not have any dependencies at all on configuration within the VM
> itself..
>
> Derick



<= /html> ---2037608182-1403053287-1320196237=:96003-- From lufang@cisco.com Tue Nov 1 19:22: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 DE4F01F0C54 for ; Tue, 1 Nov 2011 19:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.411 X-Spam-Level: X-Spam-Status: No, score=-4.411 tagged_above=-999 required=5 tests=[AWL=0.988, 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 dpauvrgd2Jre for ; Tue, 1 Nov 2011 19:22:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 017631F0C41 for ; Tue, 1 Nov 2011 19:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=6259; q=dns/txt; s=iport; t=1320200548; x=1321410148; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nXyqbJKg64XIo70UkcVJ2vCmkMUuVC+eANG1lIctzWs=; b=jULf7wU4UbL4y7sWFyGUdD6UbrKH5xVMqy4YFya7kf3pYHqgl2CjY6eI dMdiWWIFvou9YwWM8/uQCzlqCY2TgeP2cBCUScKSJHSbIXu5jZU2ugboq Vk7pGxRZREUVE9GHycn0moGk6snUUTzGS+iz8t6OGH+7S6C0/yHyq/hn8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUAADWosE6tJV2c/2dsb2JhbAA7CJltj2SBBYFyAQEBBBIBHUkMBAIBCBEEAQEBCgYXAQYBICUJCAEBBAESCBMHnnIBi0aSYoVcgkthBIdWMJFChQCHSA X-IronPort-AV: E=Sophos;i="4.69,441,1315180800"; d="scan'208";a="32674618" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 02 Nov 2011 02:22:27 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pA22MR4U008411; Wed, 2 Nov 2011 02:22:27 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, 1 Nov 2011 21:22:27 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: DojI GEFd K+Xc MEcW M3xX PMCK P30J P8jF RJ3E RKgw T6SZ VA6A VLTW Vhsm eKh+ fgB5; 3; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAcABlAGQAcgBvAC4AcgAuAG0AYQByAHEAdQBlAHMAQABnAG0AYQBpAGwALgBjAG8AbQA7AHIAbwBiAGUAcgB0AEAAcgBhAHMAegB1AGsALgBuAGUAdAA=; Sosha1_v1; 7; {BA3EFF8C-12F3-4C79-81B8-877ED0B69686}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Wed, 02 Nov 2011 02:22:18 GMT; UgBFADoAIAB2AHAAbgA0AGQAYwAgAFEAJgBBAA== MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {BA3EFF8C-12F3-4C79-81B8-877ED0B69686} Content-class: urn:content-classes:message Subject: RE: vpn4dc Q&A Date: Tue, 1 Nov 2011 21:22:17 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2507320AD8@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: vpn4dc Q&A Thread-Index: AcyY+QxyfxYIOXDUWkOiLyuivaPFtwAByM6A References: From: "Luyuan Fang (lufang)" To: "Yiqun Cai (ycai)" , "Pedro Marques" X-OriginalArrivalTime: 02 Nov 2011 02:22:27.0353 (UTC) FILETIME=[43D11090:01CC9906] Cc: L3VPN , Robert Raszuk 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, 02 Nov 2011 02:22:29 -0000 Yiqun, My thinking is that we leave mcast out for the initial phase of the = project unless we see strong DC demand for it. This is not a typical SP network environment we are looking at. E.g., we = know that often DC folks choose to use N*end systems to protect against = failure rather than using multi-homing redundancy protocols already = exist in the network world - they try to avoid complexity.=20 I would not say no one needs multicast in DC, I'm sure the questions = would be raised again and again. The trade off in design consideration is optimal design vs. simplicity. = DC folks are often prefer the later. The trade off in deciding the charter scope between being complete, but = may not get there in 3 years vs. not perfect, not covering 100% of the = cases, but something useful can come out relatively quickly to serve = large number of end users who are in need. I prefer the later. Thanks, Luyuan > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Yiqun Cai (ycai) > Sent: Tuesday, November 01, 2011 8:48 PM > To: Pedro Marques > Cc: L3VPN; Robert Raszuk > Subject: Re: vpn4dc Q&A >=20 >=20 >=20 >=20 > On 11/1/11 4:38 PM, "Pedro Marques" wrote: >=20 > > Yiqun, > > > > My opinion is that: > > - It is unclear if an IP multicast service to applications is a > > requirement. As i mentioned both discovery and reliable content > > distribution tend to be done today without IP multicast service to > > applications. >=20 > Pedro, >=20 > There are applications that are built on multicast. IPTV is one. = Market > data > (including what you referred to as "stock ticker" earlier) is another, > both > and others are what drive multicast in l3vpn. >=20 > When IP multicast connectivity is not available but abundant bandwidth > is, > one might choose to use unicast to support these applications. But > that is > a different story. >=20 > We can argue on the percentage of multicast traffic v.s., unicast in > any > particular network. But in quite a few networks, the percentage = number > is > not zero. >=20 > > - Storing IP multicast state in the middle of the network is very > > likely problematic at the scale required for this class of = solutions. >=20 > I'm not sure I agree. But that is ok. >=20 > > A solution for network virtualization must be able to work without > > storing multicast state in routers and switches. >=20 > In fact I'm quite fine with the above statement (even though I don't > necessarily agree with how you get there). Requirement and solution - > wise, > unicast replication can indeed be a common denominator. However, > merely > declaring that multicast is "out of scape" will likely get us into > trouble > down the road. That was my point. >=20 > > - If it becomes desirable to offer an IP multicast service, for > > instance because the order of delivery is now no longer controllable > > by the application, that can be offered as an overlay on top an > > unicast service. > > > > Thus i disagree with your assement that multicast needs to be part = of > > the DC solution from the start. On the other hand, the people > > interested in discussing multicast solutions should have have a = forum > > in the l3vpn WG since it is already covered in the charter. > > > > Pedro. > > > > On Tue, Nov 1, 2011 at 4:06 PM, Yiqun Cai wrote: > >> Luyang, Pedro, Robert, > >> > >> If I understand your replies correctly, =A0what you are saying is = not > that > >> "multicast is out of scope". =A0Rather, =A0it is that if there is = the > need to do > >> multicast, whether at application or IP layer, and whether from > within the > >> data center or inside the networks that connect the data centers, = it > will be > >> addressed by unicast replication. > >> > >> If that is the point, then we should say it explicitly. > >> > >> Thanks. > >> > >> On 11/1/11 11:49 AM, "Robert Raszuk" wrote: > >> > >>> Hi Yiqun, > >>> > >>> I think the priority given to support multicast really depends on > the > >>> planned scope of given VM to VM data exchange models. > >>> > >>> I could easily see large use cases for non-multicast enabled > secured > >>> inter-VM or VM to end user connectivity. > >>> > >>> Especially in cases where VM to VM connectivity is not locked to > >>> particular service provider support of real multicast may as Pedro > just > >>> observed performed by ingress replication. > >>> > >>> Alternatively other ways to efficiently distribute content could = be > >>> utilized in the application space. > >>> > >>> Best, > >>> R. > >>> > >>> > >>>>> 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. > >>>>> > >>>> > >>>> If we expect this work to be successful, and if past history is > any > >>>> indication of what might happen in the future, the moment the > solution gets > >>>> deployed people will ask for multicast. =A0Excluding multicast = would > be a > >>>> costly mistake for everyone. > >>>> > >>>> When multicast was forgot, or declared out of scope, we ended up > spending > >>>> more time to "fix" it. =A0I am sure all of us still have fresh > memory of what > >>>> l3vpn has been doing since 2004. =A0And in case you are not = aware, > there is a > >>>> brand new BOF dedicated to solving v4/v6 transition for = multicast. > >>>> > >>>> When multicast was considered from the beginning, (e.g., trill = and > l2vpn) > >>>> the work is still there but there is less drama. > >>>> > >>>> Given the nature of the proposed work and its applicable space, = =A0I > just > >>>> don't see how you can avoid multicast down the road. > >>> > >>> > >> > >> > >> -- > >> Yiqun > >> > >> >=20 >=20 > -- > Yiqun From lufang@cisco.com Tue Nov 1 19:34:02 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 C213121F9DF1 for ; Tue, 1 Nov 2011 19:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.469 X-Spam-Level: X-Spam-Status: No, score=-4.469 tagged_above=-999 required=5 tests=[AWL=0.929, 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 TSWc4TsNVb0e for ; Tue, 1 Nov 2011 19:34:01 -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 2828D21F9DED for ; Tue, 1 Nov 2011 19:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=33262; q=dns/txt; s=iport; t=1320201241; x=1321410841; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=55H71S6IOSp74MBrCA7ttgCoYeC/ZCh4i7tMQcN802k=; b=lp3V66mXvqpahKifQ9fSE+mMhxM9pn15d9u+DBs9vVcSKuAtWPvd6Z1o /rvVOTrM4qYPn+PjZZXLdtKHHTKRlasG/HW6jKpOp4oxo5soRcs3n1dm3 omjLUM/VUJ/8YARcYYIFole0k9ec8XZKHFNVC3cPpcw2ac3gGMEa+TAy9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQBAGirsE6tJV2Z/2dsb2JhbABDgk2CKpR2D4x/gSslgQaBBYFyAQEBBAEBAQ8BCQcKAz4bAgEIDgMDAQEBCwYQBwECAgIBAR8GHgEJCAEBBAESCAwHB4dolwABjEuRVwSHdDNhBIgGkUKFAIdI X-IronPort-AV: E=Sophos;i="4.69,441,1315180800"; d="scan'208,217";a="32647005" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 02 Nov 2011 02:34:00 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA22Y0x6006616; Wed, 2 Nov 2011 02:34:00 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, 1 Nov 2011 21:34:00 -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_01CC9907.E0C81DE0" Subject: RE: [vpn4dc] Question on the problem Date: Tue, 1 Nov 2011 21:33:56 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2507320AD9@XMB-RCD-201.cisco.com> In-Reply-To: <1320158560.90199.YahooMailNeo@web161801.mail.bf1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [vpn4dc] Question on the problem Thread-Index: AcyYpIKkcHlhyGctS7CV+jtvIBo2YgAYiimg References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <238542D917511A45B6B8AA806E875E250732068F@XMB-RCD-201.cisco.com> <1320158560.90199.YahooMailNeo@web161801.mail.bf1.yahoo.com> From: "Luyuan Fang (lufang)" To: "Derick Winkworth" , "Marshall Eubanks" , "L3VPN" , "Fred Baker (fred)" X-OriginalArrivalTime: 02 Nov 2011 02:34:00.0578 (UTC) FILETIME=[E102CE20:01CC9907] 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, 02 Nov 2011 02:34:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9907.E0C81DE0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRGVyaWNrLA0KDQogDQoNClNvcnJ5IGFib3V0IHRoZSBjb25mdXNpb24gb24gdGhlIOKAmGhv c3QtdG8taG9zdOKAnSwgYWdyZWVkIHRvIHJld29yZCwgYXMgc2V2ZXJhbCBvdGhlcnMgcmFpc2Vk IHRoZSBzYW1lIHF1ZXN0aW9uLg0KDQogDQoNCkkgbGlrZSB5b3VyIGRlc2NyaXB0aW9ucywgdGhh dCB3YXMgZXhhY3RseSB3aGF0IG1vdGl2YXRlZCBtYW55IG9mIHVzIHRvIHN0YXJ0IHRoaXMgaW5p dGlhdGl2ZS4gDQoNCkF1dG9tYXRlIHRoZSBwcm92aXNpb25pbmcgZm9yIFZNIHRvIGpvaW4gdGhl IGNvcnJlY3QgVlBOcyB0aHJvdWdoIGNvbnRyb2wgcHJvdG9jb2xzIGlzIG9uZSBvZiB0aGUga2V5 IHByb2JsZW1zIHdlIGFpbSB0byBzb2x2ZS4NCg0KIA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVu dHMuDQoNCkx1eXVhbg0KDQogDQoNCkZyb206IERlcmljayBXaW5rd29ydGggW21haWx0bzpjY2ll MTU2NzJAeWFob28uY29tXSANClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDAxLCAyMDExIDEwOjQz IEFNDQpUbzogTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IE1hcnNoYWxsIEV1YmFua3M7IEwzVlBOOyBG cmVkIEJha2VyIChmcmVkKQ0KU3ViamVjdDogUmU6IFt2cG40ZGNdIFF1ZXN0aW9uIG9uIHRoZSBw cm9ibGVtDQoNCiANCg0KQWxsOg0KDQogDQoNCkksIHRvbywgYWdyZWUgdGhhdCB0aGUgImhvc3Qt dG8taG9zdCIgdGVybSBpcyBjb25mdXNpbmcuICBJdHMgbm90IGFib3V0IGhvc3QtdG8taG9zdC4g IEl0cyBhYm91dCBwdXR0aW5nIFZNcyAob3Igb3RoZXIgaG9zdHMpICJpbnRvIiBhbiBleGlzdGlu ZyBMM1ZQTiBuYXRpdmVseS4gIFRoZXkgY291bGQgaGF2ZSBJUCBhZGRyZXNzZXMgY2hvc2VuIGJ5 IHRoZSBMM1ZQTiBjdXN0b21lciwgZm9yIGluc3RhbmNlLiAgV2Ugc2hvdWxkIGJlIGFibGUgdG8g dHVybiB1cCBhIFZNIGFuZCBkcm9wIGl0IGludG8gYW4gTDNWUE4gd2l0aG91dCBpbnN0YWxsaW5n IHNvZnR3YXJlIG9yIHBlcmZvcm1pbmcgY29uZmlndXJhdGlvbiBvbiB0aGUgVk0gaXRzZWxmLg0K DQogDQoNCklmIHRoZSBMM1ZQTiBkb2VzIG5vdCBhbHJlYWR5IGV4aXN0IGluIHRoZSBkYXRhIGNl bnRlciB3aGVyZSB0aGUgVk0gaG9zdCByZXNpZGVzLCBob3cgY2FuIHdlIGF1dG9tYXRlIHRoZSBw cm92aXNpb25pbmcgb2YgdGhlIFZSRnMsIGFuZCB0aGVuIGF1dG9tYXRlIHRoZSBhdHRhY2htZW50 IG9mIHRoZSBWTSB0byB0aGF0IFZSRj8gIE1hbnVhbGx5IGNvbmZpZ3VyaW5nIGFsbCBvZiB0aGF0 IGNhbiBiZSBleHRyZW1lbHkgdGVkaW91cy4gIE9yY2hlc3RyYXRpb24gdG9vbHMgdGhhdCBpbnRl cmZhY2Ugd2l0aCBkaXNwYXJhdGUgQVBJcyBhcmVuJ3QgZG9pbmcgdGhlIGpvYiB3ZWxsLg0KDQog DQoNCkRlcmljaw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpGcm9tOiBM dXl1YW4gRmFuZyAobHVmYW5nKSA8bHVmYW5nQGNpc2NvLmNvbT4NClRvOiBNYXJzaGFsbCBFdWJh bmtzIDxtYXJzaGFsbC5ldWJhbmtzQGdtYWlsLmNvbT47IEwzVlBOIDxsM3ZwbkBpZXRmLm9yZz47 IEZyZWQgQmFrZXIgKGZyZWQpIDxmcmVkQGNpc2NvLmNvbT4NClNlbnQ6IE1vbmRheSwgT2N0b2Jl ciAzMSwgMjAxMSAxMTo1NCBQTQ0KU3ViamVjdDogUkU6IFt2cG40ZGNdIFF1ZXN0aW9uIG9uIHRo ZSBwcm9ibGVtDQoNCkhpIEZyZWQsDQoNCiANCg0KVGhhbmtzIGEgbG90IGZvciB0aGUgZGlzY3Vz c2lvbi4NCg0KIA0KDQpZb3UgYXJlIHJpZ2h0IGFib3V0IHRoZSBEQyBob3N0IHRvIGhvc3QgY29t bXVuaWNhdGlvbi4gTm93IHdlIG5lZWQgdG8gZ2V0IGNsZWFyIG9uIHRoZSDigJhzZWN1cmVseeKA mSB0aGluZy4gDQoNCiANCg0KSGVyZSBpcyBiYWNrZ3JvdW5kIG9mIHRoZSB2cG40ZGMgaW5pdGlh dGl2ZTogIFNQcyBhbHJlYWR5IGhhdmUgbGFyZ2UgVlBOIGRlcGxveW1lbnQsIHRoZXkgYXJlIG1v dmluZyBmYXN0IG9uIHByb3ZpZGluZyBzY2FsYWJsZSBjbG91ZCBzZXJ2aWNlcy4gVGhlIE1QTFMg VlBOIHR5cGljYWxseSBlbmRzIGF0IFBFcywgbm90IHJlYWNoaW5nIHRvIGhvc3RzL2VuZCBzeXN0 ZW1zLiBUaGUgcHJvdmlzaW9uaW5nIGlzIHNlZ21lbnRlZCAoU1AgbmV0d29yayBzZWdtZW50LCBT UCBEQyBzZWdtZW50LCBFbnRlcnByaXNlIHNlZ21lbnQsIGNvbnRlbnQgcHJvdmlkZXIgc2VnbWVu dCksIGFuZCB0b2RheSB0aGV5IGFyZSBvZnRlbiBmYWNpbmcgbG9uZyBzZXJ2aWNlIHR1cm5pbmcg dXAgdGltZS4g4oCTIHRoaXMgaXMgdGhlIHByYWN0aWNhbCBwcm9ibGVtcyBOaW5nIGZpcnN0IHBy ZXNlbnRlZCB0byB1cy4gDQoNCiANCg0KQWZ0ZXIgYSBjb3VwbGUgb2YgbW9udGhzIHN0dWR5LCB3 ZSBkZWNpZGVkIHdlIHdvdWxkIG5vdCBiZSBhYmxlIHRvIHNvbHZlIGV2ZXJ5dGhpbmcgZm9yIHRo ZSBlbmQtdG8tZW5kIHByb3Zpc2lvbmluZyBpbiBvbmUgZWZmb3J0LCBidXQgd2UgY291bGQgcG9z c2libHkgc29sdmUgdGhlICBob3N0LXRvLWhvc3QgbGF5ZXIgMyAtIGlwIG9yIG1wbHMsIHZwbiBj b25uZWN0aXZpdHkgcHJvYmxlbXMgaW4gb25lIGluaXRpYXRpdmUg4oCTIHZwbjRkYy4gV2h5IHZw bj8gYmVjYXVzZSB0aGV5IGFyZSBleGlzdGluZyBzZXJ2aWNlcywgb25lIG9mIHRoZSBtb3N0IHdp ZGVseSBkZXBsb3llZCBmZWF0dXJlcyBvdmVyIHRoZSBsYXN0IDEyIHllYXJzLiBFbnRlcnByaXNl IGN1c3RvbWVycyBhcmUgYXNraW5nIFNQcyB0byBleHRlbmQgdGhlIHZwbnMgdG8gdGhlIGVuZCBz eXN0ZW1zLg0KDQogDQoNCldlIGtub3cgdGhhdCBNUExTL0JHUCBWUE4gb3Igb3RoZXIgSVAgdHVu bmVsaW5nIG1lY2hhbmlzbXMgcHJvdmlkZSByb3V0aW5nIGlzb2xhdGlvbiwgbm90IGVuY3J5cHRp b24uIE1hbnkgZm9sa3MgY29uc2lkZXIgdGhlIHJvdXRpbmcgaXNvbGF0aW9uIHByb3ZpZGVzIGNl cnRhaW4gZGVncmVlIG9mIHNlY3VyaXR5LCBnb29kIGVub3VnaCBmb3IgdGhlbSwgd2hpbGUgb3Ro ZXJzIHRoaW5rIHNlY3VyaXR5IG1lYW5zICBlbmNyeXB0aW9uLiBXZSBhcmUgbm90IGdvaW5nIHRv IGVudGVyIHRoYXQgZGViYXRlIGhlcmUuDQoNCiANCg0KT3VyIGludGVudGlvbiBpcyB0byBmb2N1 cyBvbiB0aGUgdnBuIGNvbm5lY3Rpdml0eSBpc3N1ZXMsIG5vdCBjcnlwdG9ncmFwaHkgdGVjaG5p cXVlcywgbm9yIGtleSBkaXN0cmlidXRpb24va2V5IG1hbmFnZW1lbnQsIHdlIHdpbGwgbGVhdmUg dGhlc2UgdG8gdGhlIFNlY3VyaXR5IEFyZWEuICANCg0KIA0KDQpMZXQgbWUgc2VuZCBuZXh0IG1h aWwgdG8gZ2V0IG1vcmUgZmVlZGJhY2tzIGZyb20gYWxsLg0KDQogDQoNClRoYW5rcywNCg0KTHV5 dWFuDQoNCiANCg0KRnJvbTogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJzaGFsbCBFdWJhbmtzDQpTZW50OiBNb25k YXksIE9jdG9iZXIgMzEsIDIwMTEgNzo1NiBQTQ0KVG86IEwzVlBOOyBGcmVkIEJha2VyIChmcmVk KQ0KU3ViamVjdDogRndkOiBbdnBuNGRjXSBRdWVzdGlvbiBvbiB0aGUgcHJvYmxlbQ0KDQogDQoN CkZvcndhcmRpbmcgZm9yIEZyZWQgQmFrZXIuDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3Nh Z2UgLS0tLS0tLS0tLQ0KRnJvbTogRnJlZCBCYWtlciA8ZnJlZEBjaXNjby5jb20+DQpEYXRlOiBN b24sIE9jdCAzMSwgMjAxMSBhdCA4OjU4IEFNDQpTdWJqZWN0OiBbdnBuNGRjXSBRdWVzdGlvbiBv biB0aGUgcHJvYmxlbQ0KVG86IHZwbjRkY0BpZXRmLm9yZw0KDQoNCkkgaGF2ZSBzdGFydGVkIHJl YWRpbmcgdGhlIHZwbjRkYyBkcmFmdHMsIGFuZCBlc3BlY2lhbGx5IHRoZSBwcm9ibGVtIHN0YXRl bWVudHMsIGFuZCBmaW5kIG15c2VsZiBzY3JhdGNoaW5nIG15IGhlYWQuIFN0YXJ0aW5nIHdpdGgg dGhlIHRpdGxlICJWUE4gZm9yIERhdGEgQ2VudGVyIiwgSSByZWFsbHkgd29uZGVyIGlmIHRoZSB0 b3BpYyBpcyBzdGFydGluZyBmcm9tIGEgcHJvcG9zZWQgc29sdXRpb24gYmVmb3JlIHNldHRsaW5n IG9uIGEgcHJvYmxlbS4NCg0KTGV0IG1lIHJhbWJsZSBhIGJpdCwgYW5kIHRoZW4gdGVsbCBtZSBJ J20gd3JvbmcuDQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgeW91ciBwcmltYXJ5IGlzc3VlIGlzIHRo YXQgeW91IGhhdmUgYSBzZXQgb2YgaG9zdHMgdGhhdCB3YW50IHRvIGNvbW11bmljYXRlIHdpdGgg ZWFjaCBvdGhlciBzZWN1cmVseS4gVGhlc2UgaG9zdHMgbWlnaHQgYmUgcGh5c2ljYWwgb3Igdmly dHVhbCwgYW5kIG1pZ2h0IGJlIGluIHRoZSBzYW1lIGRhdGEgY2VudGVyIG9yIGluIGRpZmZlcmVu dCBkYXRhIGNlbnRlcnMuIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB0aGV5IGJlIGFibGUg dG8gYXV0aGVudGljYXRlIGNvbW11bmljYXRpb25zIHdpdGggZWFjaCBvdGhlciwgYW5kIHRoZW4g ZG8gdGhpbmdzIHRoYXQgdGhleSBhcmUgYXV0aG9yaXplZCB0byBkbyBiYXNlZCBvbiB0aG9zZSBj b21tdW5pY2F0aW9ucy4gVGhlIHRoaW5ncyB0aGF0IHRoZXkgZG8gbWlnaHQgZGlmZmVyLiBXaXRo aW4gb25lIGNvbW11bml0eSwgdGhlIGhvc3RzIG1pZ2h0IGFsbCBiZSBwZWVycyBhY2NvbXBsaXNo aW5nIHRoZSBqb2Igb2YgdGhlIGNsb3VkLCB3aGF0ZXZlciB0aGF0IGlzIC0gb3JkZXIgcHJvY2Vz c2luZywgY29udGVudCBkZWxpdmVyeSwgdGFrZSB5b3VyIHBpY2suIFdpdGhpbiBhbm90aGVyIGNv bW11bml0eSwgdGhlIGlzc3VlIG1pZ2h0IGJlIHRoZSBtYW5hZ2VtZW50IG9mIHZpcnR1YWwgbWFj aGluZXMsIGFuZCB5b3UgbWlnaHQgaGF2ZSBhIHJlbGF0aXZlbHkgc21hbGwgbnVtYmVyIG9mIGNv bnRyb2wgc3lzdGVtcyB0aGF0IHRhbGsgd2l0aCBhIGxhcmdlIG51bWJlciBvZiBjbGllbnQgbWFj aGluZXMuDQoNClRoZSB0ZXJtICJWUE4iIGltcGxpZXMgdG8gbWUgdGhhdCB5b3UgaGF2ZSBjaG9z ZW4gYSBzb2x1dGlvbi4gSXQgbWlnaHQgYmUgYW4gTVBMUyBWUE4sIHdoaWNoIGlzIHRvIHNheSB0 aGF0IHlvdSBoYXZlIHRyYW5zcG9ydCBidXQgZGVwZW5kIG9uIGhpZ2hlciBsYXllciBzZXJ2aWNl cyBmb3IgZW5jcnlwdGlvbiwgYXV0aGVudGljYXRpb24sIGFuZCBhdXRob3JpemF0aW9uLiBJbiBJ UHNlYywgIlZQTiIgdGhlIHRlcm0gIlZQTiIgZ2VuZXJhbGx5IHJlZmVycyB0byB0aGUgdHVubmVs IG1vZGUsIGFuZCBpcyBhIHdheSBvZiBvdmVybGF5aW5nIG9uZSBuZXR3b3JrIG9uIGFub3RoZXIu IEluIHRoZSBjYXNlLCB0aGF0IGRvZXNuJ3QgbWFrZSBhIGxvdCBvZiBzZW5zZSB0byBtZSBpbiB0 aGlzIGNvbnRleHQgLSBZb3UgZG9uJ3QgYXBwZWFyIHRvIGJlIG92ZXJsYXlpbmcgbmV0d29ya3Mg cGVyIHNlLCBtZXJlbHkgbWFraW5nIHN1cmUgdGhhdCBtZXNzYWdlcyB5b3UgcmVjZWl2ZSBhbmQg cHJvY2VzcyBhcmUgZnJvbSB0cnVzdGVkIHBlZXJzLg0KDQpJZiB0aGUgcHJpbWFyeSBpc3N1ZSBp cyBvbmUgb2YgdHJ1c3QsIHdlIGNvdWxkIGRpc2N1c3MgVExTLCBodHRwcyAoaWYgdGhlIG9ubHkg YXBwbGljYXRpb24gcHJvdG9jb2wgaXMgYSB3ZWIgcHJvdG9jb2wpLCBvciBJUHNlYydzIHRyYW5z cG9ydCBtb2RlLiBJbiBhbnkgb2YgdGhvc2UsIHRoZSBpc3N1ZSBpcyBsYXJnZWx5IG9uZSBvZiBr ZXkgZGlzdHJpYnV0aW9uLCBhbmQgdGhlIHVzZSBvZiB0aG9zZSBrZXlzIGZvciBlbmNyeXB0aW9u IGFuZCBhdXRoZW50aWNhdGlvbiB0byBtYW5hZ2UgY29tbXVuaWNhdGlvbnMgYW1vbmcgYSBzZXQg b2YgY29tbXVuaWNhdGluZyBlbnRpdGllcy4NCg0KV2hhdCBhbSBJIG1pc3Npbmc/IFdoYXQgbWFr ZXMgdGhpcyBzcGVjaWZpY2FsbHkgYSBWaXJ0dWFsIFByaXZhdGUgTmV0d29yaz8gV2h5IGlzIHRo aXMgbm90IGEga2V5IGRpc3RyaWJ1dGlvbiBwcm9ibGVtIGJhc2VkIG9uIGV4aXN0aW5nIHRlY2hu b2xvZ2llcz8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQp2cG40ZGMgbWFpbGluZyBsaXN0DQp2cG40ZGNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdnBuNGRjDQoNCiANCg0KIA0KDQo= ------_=_NextPart_001_01CC9907.E0C81DE0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYg IW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+ DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQog QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLnlpdjEyNTI5NzQzMTBtc29ub3JtYWwsIGxpLnlpdjEy NTI5NzQzMTBtc29ub3JtYWwsIGRpdi55aXYxMjUyOTc0MzEwbXNvbm9ybWFsDQoJe21zby1zdHls ZS1uYW1lOnlpdjEyNTI5NzQzMTBtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2MTI1Mjk3NDMxMG1zb2h5cGVybGluaw0KCXttc28t c3R5bGUtbmFtZTp5aXYxMjUyOTc0MzEwbXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2MTI1Mjk3NDMx MG1zb2h5cGVybGlua2ZvbGxvd2VkDQoJe21zby1zdHlsZS1uYW1lOnlpdjEyNTI5NzQzMTBtc29o eXBlcmxpbmtmb2xsb3dlZDt9DQpzcGFuLnlpdjEyNTI5NzQzMTBlbWFpbHN0eWxlMTcNCgl7bXNv LXN0eWxlLW5hbWU6eWl2MTI1Mjk3NDMxMGVtYWlsc3R5bGUxNzt9DQpwLnlpdjEyNTI5NzQzMTBt c29ub3JtYWwxLCBsaS55aXYxMjUyOTc0MzEwbXNvbm9ybWFsMSwgZGl2LnlpdjEyNTI5NzQzMTBt c29ub3JtYWwxDQoJe21zby1zdHlsZS1uYW1lOnlpdjEyNTI5NzQzMTBtc29ub3JtYWwxOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjEyNTI5NzQz MTBtc29oeXBlcmxpbmsxDQoJe21zby1zdHlsZS1uYW1lOnlpdjEyNTI5NzQzMTBtc29oeXBlcmxp bmsxOw0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnlp djEyNTI5NzQzMTBtc29oeXBlcmxpbmtmb2xsb3dlZDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTI1 Mjk3NDMxMG1zb2h5cGVybGlua2ZvbGxvd2VkMTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnlpdjEyNTI5NzQzMTBlbWFpbHN0eWxlMTcxDQoJe21z by1zdHlsZS1uYW1lOnlpdjEyNTI5NzQzMTBlbWFpbHN0eWxlMTcxOw0KCWZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNz PVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0Qn PkhpIERlcmljayw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlNvcnJ5IGFib3V0IHRo ZSBjb25mdXNpb24gb24gdGhlIOKAmGhvc3QtdG8taG9zdOKAnSwgYWdyZWVkIHRvIHJld29yZCwN CmFzIHNldmVyYWwgb3RoZXJzIHJhaXNlZCB0aGUgc2FtZSBxdWVzdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPkkgbGlrZSB5b3VyIGRlc2NyaXB0aW9ucywgdGhhdCB3YXMgZXhh Y3RseSB3aGF0IG1vdGl2YXRlZCBtYW55DQpvZiB1cyB0byBzdGFydCB0aGlzIGluaXRpYXRpdmUu IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz5BdXRvbWF0ZSB0aGUgcHJvdmlzaW9uaW5nIGZvciBWTSB0byBqb2luIHRo ZSBjb3JyZWN0IFZQTnMgdGhyb3VnaA0KY29udHJvbCBwcm90b2NvbHMgaXMgb25lIG9mIHRoZSBr ZXkgcHJvYmxlbXMgd2UgYWltIHRvIHNvbHZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5MdXl1YW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQn Pg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gRGVyaWNrIFdpbmt3b3J0 aA0KW21haWx0bzpjY2llMTU2NzJAeWFob28uY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh eSwgTm92ZW1iZXIgMDEsIDIwMTEgMTA6NDMgQU08YnI+DQo8Yj5Ubzo8L2I+IEx1eXVhbiBGYW5n IChsdWZhbmcpOyBNYXJzaGFsbCBFdWJhbmtzOyBMM1ZQTjsgRnJlZCBCYWtlciAoZnJlZCk8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2cG40ZGNdIFF1ZXN0aW9uIG9uIHRoZSBwcm9ibGVtPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5B bGw6PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PkksIHRvbywgYWdyZWUgdGhhdCB0aGUNCiZxdW90O2hvc3QtdG8taG9zdCZxdW90OyB0ZXJtIGlz IGNvbmZ1c2luZy4gJm5ic3A7SXRzIG5vdCBhYm91dCBob3N0LXRvLWhvc3QuDQombmJzcDtJdHMg YWJvdXQgcHV0dGluZyBWTXMgKG9yIG90aGVyIGhvc3RzKSAmcXVvdDtpbnRvJnF1b3Q7IGFuIGV4 aXN0aW5nIEwzVlBODQpuYXRpdmVseS4gJm5ic3A7VGhleSBjb3VsZCBoYXZlIElQIGFkZHJlc3Nl cyBjaG9zZW4gYnkgdGhlIEwzVlBOIGN1c3RvbWVyLCBmb3INCmluc3RhbmNlLiAmbmJzcDtXZSBz aG91bGQgYmUgYWJsZSB0byB0dXJuIHVwIGEgVk0gYW5kIGRyb3AgaXQgaW50byBhbiBMM1ZQTg0K d2l0aG91dCBpbnN0YWxsaW5nIHNvZnR3YXJlIG9yIHBlcmZvcm1pbmcgY29uZmlndXJhdGlvbiBv biB0aGUgVk0gaXRzZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrJz5JZiB0aGUgTDNWUE4gZG9lcyBub3QgYWxyZWFkeQ0KZXhpc3QgaW4gdGhl IGRhdGEgY2VudGVyIHdoZXJlIHRoZSBWTSBob3N0IHJlc2lkZXMsIGhvdyBjYW4gd2UgYXV0b21h dGUgdGhlDQpwcm92aXNpb25pbmcgb2YgdGhlIFZSRnMsIGFuZCB0aGVuIGF1dG9tYXRlIHRoZSBh dHRhY2htZW50IG9mIHRoZSBWTSB0byB0aGF0DQpWUkY/ICZuYnNwO01hbnVhbGx5IGNvbmZpZ3Vy aW5nIGFsbCBvZiB0aGF0IGNhbiBiZSBleHRyZW1lbHkgdGVkaW91cy4NCiZuYnNwO09yY2hlc3Ry YXRpb24gdG9vbHMgdGhhdCBpbnRlcmZhY2Ugd2l0aCBkaXNwYXJhdGUgQVBJcyBhcmVuJ3QgZG9p bmcgdGhlDQpqb2Igd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibGFjayc+RGVyaWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxl PSd0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlJz48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn Pg0KDQo8aHIgc2l6ZT0xIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+DQoNCjwvc3Bhbj48L2Rp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNr Z3JvdW5kOndoaXRlJz48Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3Bh bg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPiBMdXl1YW4NCkZhbmcgKGx1ZmFuZykgJmx0O2x1ZmFuZ0BjaXNjby5j b20mZ3Q7PGJyPg0KPGI+VG86PC9iPiBNYXJzaGFsbCBFdWJhbmtzICZsdDttYXJzaGFsbC5ldWJh bmtzQGdtYWlsLmNvbSZndDs7IEwzVlBODQombHQ7bDN2cG5AaWV0Zi5vcmcmZ3Q7OyBGcmVkIEJh a2VyIChmcmVkKSAmbHQ7ZnJlZEBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgT2N0b2JlciAzMSwgMjAxMSAxMTo1NCBQTTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3Zw bjRkY10gUXVlc3Rpb24gb24gdGhlIHByb2JsZW08L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IGlkPXlpdjEyNTI5NzQzMTA+DQoN CjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IaSBGcmVkLDwvc3Bhbj48c3Bhbg0Kc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFua3Mg YSBsb3QgZm9yIHRoZQ0KZGlzY3Vzc2lvbi48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ Jm5ic3A7PC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Zb3UgYXJlIHJpZ2h0IGFib3V0 IHRoZSBEQyBob3N0DQp0byBob3N0IGNvbW11bmljYXRpb24uIE5vdyB3ZSBuZWVkIHRvIGdldCBj bGVhciBvbiB0aGUg4oCYc2VjdXJlbHnigJkgdGhpbmcuIDwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IZXJlIGlzIGJh Y2tncm91bmQgb2YgdGhlDQp2cG40ZGMgaW5pdGlhdGl2ZTogJm5ic3A7U1BzIGFscmVhZHkgaGF2 ZSBsYXJnZSBWUE4gZGVwbG95bWVudCwgdGhleSBhcmUgbW92aW5nDQpmYXN0IG9uIHByb3ZpZGlu ZyBzY2FsYWJsZSBjbG91ZCBzZXJ2aWNlcy4gVGhlIE1QTFMgVlBOIHR5cGljYWxseSBlbmRzIGF0 IFBFcywNCm5vdCByZWFjaGluZyB0byBob3N0cy9lbmQgc3lzdGVtcy4gVGhlIHByb3Zpc2lvbmlu ZyBpcyBzZWdtZW50ZWQgKFNQIG5ldHdvcmsNCnNlZ21lbnQsIFNQIERDIHNlZ21lbnQsIEVudGVy cHJpc2Ugc2VnbWVudCwgY29udGVudCBwcm92aWRlciBzZWdtZW50KSwgYW5kDQp0b2RheSB0aGV5 IGFyZSBvZnRlbiBmYWNpbmcgbG9uZyBzZXJ2aWNlIHR1cm5pbmcgdXAgdGltZS4g4oCTIHRoaXMg aXMgdGhlDQpwcmFjdGljYWwgcHJvYmxlbXMgTmluZyBmaXJzdCBwcmVzZW50ZWQgdG8gdXMuIDwv c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4NCnN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkFmdGVyIGEgY291cGxlIG9mIG1vbnRocyBzdHVkeSwNCndlIGRlY2lkZWQgd2Ug d291bGQgbm90IGJlIGFibGUgdG8gc29sdmUgZXZlcnl0aGluZyBmb3IgdGhlIGVuZC10by1lbmQN CnByb3Zpc2lvbmluZyBpbiBvbmUgZWZmb3J0LCBidXQgd2UgY291bGQgcG9zc2libHkgc29sdmUg dGhlICZuYnNwO2hvc3QtdG8taG9zdA0KbGF5ZXIgMyAtIGlwIG9yIG1wbHMsIHZwbiBjb25uZWN0 aXZpdHkgcHJvYmxlbXMgaW4gb25lIGluaXRpYXRpdmUg4oCTIHZwbjRkYy4gV2h5DQp2cG4/IGJl Y2F1c2UgdGhleSBhcmUgZXhpc3Rpbmcgc2VydmljZXMsIG9uZSBvZiB0aGUgbW9zdCB3aWRlbHkg ZGVwbG95ZWQNCmZlYXR1cmVzIG92ZXIgdGhlIGxhc3QgMTIgeWVhcnMuIEVudGVycHJpc2UgY3Vz dG9tZXJzIGFyZSBhc2tpbmcgU1BzIHRvIGV4dGVuZA0KdGhlIHZwbnMgdG8gdGhlIGVuZCBzeXN0 ZW1zLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dy b3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4NCnN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPldlIGtub3cgdGhhdCBNUExTL0JHUCBWUE4gb3INCm90aGVyIElQIHR1 bm5lbGluZyBtZWNoYW5pc21zIHByb3ZpZGUgcm91dGluZyBpc29sYXRpb24sIG5vdCBlbmNyeXB0 aW9uLiBNYW55DQpmb2xrcyBjb25zaWRlciB0aGUgcm91dGluZyBpc29sYXRpb24gcHJvdmlkZXMg Y2VydGFpbiBkZWdyZWUgb2Ygc2VjdXJpdHksIGdvb2QNCmVub3VnaCBmb3IgdGhlbSwgd2hpbGUg b3RoZXJzIHRoaW5rIHNlY3VyaXR5IG1lYW5zICZuYnNwO2VuY3J5cHRpb24uIFdlIGFyZSBub3QN CmdvaW5nIHRvIGVudGVyIHRoYXQgZGViYXRlIGhlcmUuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+T3VyIGludGVudGlv biBpcyB0byBmb2N1cyBvbg0KdGhlIHZwbiBjb25uZWN0aXZpdHkgaXNzdWVzLCBub3QgY3J5cHRv Z3JhcGh5IHRlY2huaXF1ZXMsIG5vciBrZXkNCmRpc3RyaWJ1dGlvbi9rZXkgbWFuYWdlbWVudCwg d2Ugd2lsbCBsZWF2ZSB0aGVzZSB0byB0aGUgU2VjdXJpdHkgQXJlYS4gJm5ic3A7PC9zcGFuPjxz cGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkxldCBtZSBzZW5kIG5leHQgbWFpbCB0byBnZXQNCm1vcmUgZmVlZGJhY2tzIGZyb20gYWxs Ljwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4NCnN0eWxl PSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPlRoYW5rcyw8L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkx1eXVh bjwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuDQpzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz4gbDN2cG4tYm91bmNlc0BpZXRmLm9yZw0KW21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3Jn XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcnNoYWxsIEV1YmFua3M8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBPY3RvYmVyIDMxLCAyMDExIDc6NTYgUE08YnI+DQo8Yj5Ubzo8L2I+IEwzVlBOOyBG cmVkIEJha2VyIChmcmVkKTxicj4NCjxiPlN1YmplY3Q6PC9iPiBGd2Q6IFt2cG40ZGNdIFF1ZXN0 aW9uIG9uIHRoZSBwcm9ibGVtPC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXYgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkZvcndh cmRpbmcNCmZvciBGcmVkIEJha2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4tLS0tLS0tLS0tDQpGb3J3YXJkZWQgbWVz c2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogPGI+RnJlZCBCYWtlcjwvYj4gJmx0OzxhIGhyZWY9 Im1haWx0bzpmcmVkQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZyZWRAY2lzY28uY29tPC9h PiZndDs8YnI+DQpEYXRlOiBNb24sIE9jdCAzMSwgMjAxMSBhdCA4OjU4IEFNPGJyPg0KU3ViamVj dDogW3ZwbjRkY10gUXVlc3Rpb24gb24gdGhlIHByb2JsZW08YnI+DQpUbzogPGEgaHJlZj0ibWFp bHRvOnZwbjRkY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZwbjRkY0BpZXRmLm9yZzwvYT48 YnI+DQo8YnI+DQo8YnI+DQpJIGhhdmUgc3RhcnRlZCByZWFkaW5nIHRoZSB2cG40ZGMgZHJhZnRz LCBhbmQgZXNwZWNpYWxseSB0aGUgcHJvYmxlbQ0Kc3RhdGVtZW50cywgYW5kIGZpbmQgbXlzZWxm IHNjcmF0Y2hpbmcgbXkgaGVhZC4gU3RhcnRpbmcgd2l0aCB0aGUgdGl0bGUNCiZxdW90O1ZQTiBm b3IgRGF0YSBDZW50ZXImcXVvdDssIEkgcmVhbGx5IHdvbmRlciBpZiB0aGUgdG9waWMgaXMgc3Rh cnRpbmcgZnJvbQ0KYSBwcm9wb3NlZCBzb2x1dGlvbiBiZWZvcmUgc2V0dGxpbmcgb24gYSBwcm9i bGVtLjxicj4NCjxicj4NCkxldCBtZSByYW1ibGUgYSBiaXQsIGFuZCB0aGVuIHRlbGwgbWUgSSdt IHdyb25nLjxicj4NCjxicj4NCkl0IHNlZW1zIHRvIG1lIHRoYXQgeW91ciBwcmltYXJ5IGlzc3Vl IGlzIHRoYXQgeW91IGhhdmUgYSBzZXQgb2YgaG9zdHMgdGhhdA0Kd2FudCB0byBjb21tdW5pY2F0 ZSB3aXRoIGVhY2ggb3RoZXIgc2VjdXJlbHkuIFRoZXNlIGhvc3RzIG1pZ2h0IGJlIHBoeXNpY2Fs IG9yDQp2aXJ0dWFsLCBhbmQgbWlnaHQgYmUgaW4gdGhlIHNhbWUgZGF0YSBjZW50ZXIgb3IgaW4g ZGlmZmVyZW50IGRhdGEgY2VudGVycy4gVGhlDQppbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB0aGV5 IGJlIGFibGUgdG8gYXV0aGVudGljYXRlIGNvbW11bmljYXRpb25zIHdpdGggZWFjaA0Kb3RoZXIs IGFuZCB0aGVuIGRvIHRoaW5ncyB0aGF0IHRoZXkgYXJlIGF1dGhvcml6ZWQgdG8gZG8gYmFzZWQg b24gdGhvc2UNCmNvbW11bmljYXRpb25zLiBUaGUgdGhpbmdzIHRoYXQgdGhleSBkbyBtaWdodCBk aWZmZXIuIFdpdGhpbiBvbmUgY29tbXVuaXR5LCB0aGUNCmhvc3RzIG1pZ2h0IGFsbCBiZSBwZWVy cyBhY2NvbXBsaXNoaW5nIHRoZSBqb2Igb2YgdGhlIGNsb3VkLCB3aGF0ZXZlciB0aGF0IGlzIC0N Cm9yZGVyIHByb2Nlc3NpbmcsIGNvbnRlbnQgZGVsaXZlcnksIHRha2UgeW91ciBwaWNrLiBXaXRo aW4gYW5vdGhlciBjb21tdW5pdHksDQp0aGUgaXNzdWUgbWlnaHQgYmUgdGhlIG1hbmFnZW1lbnQg b2YgdmlydHVhbCBtYWNoaW5lcywgYW5kIHlvdSBtaWdodCBoYXZlIGENCnJlbGF0aXZlbHkgc21h bGwgbnVtYmVyIG9mIGNvbnRyb2wgc3lzdGVtcyB0aGF0IHRhbGsgd2l0aCBhIGxhcmdlIG51bWJl ciBvZg0KY2xpZW50IG1hY2hpbmVzLjxicj4NCjxicj4NClRoZSB0ZXJtICZxdW90O1ZQTiZxdW90 OyBpbXBsaWVzIHRvIG1lIHRoYXQgeW91IGhhdmUgY2hvc2VuIGEgc29sdXRpb24uIEl0DQptaWdo dCBiZSBhbiBNUExTIFZQTiwgd2hpY2ggaXMgdG8gc2F5IHRoYXQgeW91IGhhdmUgdHJhbnNwb3J0 IGJ1dCBkZXBlbmQgb24NCmhpZ2hlciBsYXllciBzZXJ2aWNlcyBmb3IgZW5jcnlwdGlvbiwgYXV0 aGVudGljYXRpb24sIGFuZCBhdXRob3JpemF0aW9uLiBJbg0KSVBzZWMsICZxdW90O1ZQTiZxdW90 OyB0aGUgdGVybSAmcXVvdDtWUE4mcXVvdDsgZ2VuZXJhbGx5IHJlZmVycyB0byB0aGUgdHVubmVs DQptb2RlLCBhbmQgaXMgYSB3YXkgb2Ygb3ZlcmxheWluZyBvbmUgbmV0d29yayBvbiBhbm90aGVy LiBJbiB0aGUgY2FzZSwgdGhhdA0KZG9lc24ndCBtYWtlIGEgbG90IG9mIHNlbnNlIHRvIG1lIGlu IHRoaXMgY29udGV4dCAtIFlvdSBkb24ndCBhcHBlYXIgdG8gYmUNCm92ZXJsYXlpbmcgbmV0d29y a3MgcGVyIHNlLCBtZXJlbHkgbWFraW5nIHN1cmUgdGhhdCBtZXNzYWdlcyB5b3UgcmVjZWl2ZSBh bmQNCnByb2Nlc3MgYXJlIGZyb20gdHJ1c3RlZCBwZWVycy48YnI+DQo8YnI+DQpJZiB0aGUgcHJp bWFyeSBpc3N1ZSBpcyBvbmUgb2YgdHJ1c3QsIHdlIGNvdWxkIGRpc2N1c3MgVExTLCBodHRwcyAo aWYgdGhlIG9ubHkNCmFwcGxpY2F0aW9uIHByb3RvY29sIGlzIGEgd2ViIHByb3RvY29sKSwgb3Ig SVBzZWMncyB0cmFuc3BvcnQgbW9kZS4gSW4gYW55IG9mDQp0aG9zZSwgdGhlIGlzc3VlIGlzIGxh cmdlbHkgb25lIG9mIGtleSBkaXN0cmlidXRpb24sIGFuZCB0aGUgdXNlIG9mIHRob3NlIGtleXMN CmZvciBlbmNyeXB0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiB0byBtYW5hZ2UgY29tbXVuaWNhdGlv bnMgYW1vbmcgYSBzZXQgb2YNCmNvbW11bmljYXRpbmcgZW50aXRpZXMuPGJyPg0KPGJyPg0KV2hh dCBhbSBJIG1pc3Npbmc/IFdoYXQgbWFrZXMgdGhpcyBzcGVjaWZpY2FsbHkgYSBWaXJ0dWFsIFBy aXZhdGUgTmV0d29yaz8gV2h5DQppcyB0aGlzIG5vdCBhIGtleSBkaXN0cmlidXRpb24gcHJvYmxl bSBiYXNlZCBvbiBleGlzdGluZyB0ZWNobm9sb2dpZXM/PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2cG40ZGMgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOnZwbjRkY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZwbjRk Y0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3ZwbjRkYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdnBuNGRjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRl Jz48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9i b2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01CC9907.E0C81DE0-- From marshall.eubanks@gmail.com Tue Nov 1 19:34: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 EFFEE1F0C54 for ; Tue, 1 Nov 2011 19:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.796 X-Spam-Level: X-Spam-Status: No, score=-102.796 tagged_above=-999 required=5 tests=[AWL=-0.397, 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 k35XkhUV6b70 for ; Tue, 1 Nov 2011 19:34:58 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9391F0C41 for ; Tue, 1 Nov 2011 19:34:58 -0700 (PDT) Received: by qadc10 with SMTP id c10so8133421qad.31 for ; Tue, 01 Nov 2011 19:34:57 -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=DBgqGC3jV1ovvNF7SoY33CPy7Vwf0g6jhWMXFYHvnJs=; b=FX68tJ0zC9rUie8zATlvsy2hk0Pa4W96jGtybPI5SACAmHLoJhb1nikdYY8E9r22J5 k6cl3DbqDVc/H316J9cJ+bOHF/SjY7V/4iZE1PR2LCOZWVUjW1A1HDsIY5KLhI+aKXKn Nc4DMhB/te2WskB2f+aNSXsIGccWM6Xe3S99s= MIME-Version: 1.0 Received: by 10.182.77.164 with SMTP id t4mr506265obw.9.1320201297667; Tue, 01 Nov 2011 19:34:57 -0700 (PDT) Received: by 10.182.14.65 with HTTP; Tue, 1 Nov 2011 19:34:57 -0700 (PDT) In-Reply-To: References: <4EB03F4E.1030804@raszuk.net> Date: Tue, 1 Nov 2011 22:34:57 -0400 Message-ID: Subject: Re: vpn4dc Q&A From: Marshall Eubanks To: Pedro Marques Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Yiqun Cai , L3VPN , Robert Raszuk 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, 02 Nov 2011 02:34:59 -0000 Dear Pedro; On Tue, Nov 1, 2011 at 7:38 PM, Pedro Marques w= rote: > Yiqun, > > My opinion is that: > =A0- It is unclear if an IP multicast service to applications is a > requirement. As i mentioned both discovery and reliable content > distribution tend to be done today without IP multicast service to > applications. > =A0- Storing IP multicast state in the middle of the network is very > likely problematic at the scale required for this class of solutions. > A solution for network virtualization must be able to work without > storing multicast state in routers and switches. > =A0- If it becomes desirable to offer an IP multicast service, for > instance because the order of delivery is now no longer controllable > by the application, that can be offered as an overlay on top an > unicast service. > > Thus i disagree with your assement that multicast needs to be part of > the DC solution from the start. On the other hand, the people > interested in discussing multicast solutions should have have a forum > in the l3vpn WG since it is already covered in the charter. > Yes, they do. As it happens, this is it. Regards Marshall > =A0Pedro. > > On Tue, Nov 1, 2011 at 4:06 PM, Yiqun Cai wrote: >> Luyang, Pedro, Robert, >> >> If I understand your replies correctly, =A0what you are saying is not th= at >> "multicast is out of scope". =A0Rather, =A0it is that if there is the ne= ed to do >> multicast, whether at application or IP layer, and whether from within t= he >> data center or inside the networks that connect the data centers, it wil= l be >> addressed by unicast replication. >> >> If that is the point, then we should say it explicitly. >> >> Thanks. >> >> On 11/1/11 11:49 AM, "Robert Raszuk" wrote: >> >>> Hi Yiqun, >>> >>> I think the priority given to support multicast really depends on the >>> planned scope of given VM to VM data exchange models. >>> >>> I could easily see large use cases for non-multicast enabled secured >>> inter-VM or VM to end user connectivity. >>> >>> Especially in cases where VM to VM connectivity is not locked to >>> particular service provider support of real multicast may as Pedro just >>> observed performed by ingress replication. >>> >>> Alternatively other ways to efficiently distribute content could be >>> utilized in the application space. >>> >>> Best, >>> R. >>> >>> >>>>> 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. >>>>> >>>> >>>> If we expect this work to be successful, and if past history is any >>>> indication of what might happen in the future, the moment the solution= gets >>>> deployed people will ask for multicast. =A0Excluding multicast would b= e a >>>> costly mistake for everyone. >>>> >>>> When multicast was forgot, or declared out of scope, we ended up spend= ing >>>> more time to "fix" it. =A0I am sure all of us still have fresh memory = of what >>>> l3vpn has been doing since 2004. =A0And in case you are not aware, the= re is a >>>> brand new BOF dedicated to solving v4/v6 transition for multicast. >>>> >>>> When multicast was considered from the beginning, (e.g., trill and l2v= pn) >>>> the work is still there but there is less drama. >>>> >>>> Given the nature of the proposed work and its applicable space, =A0I j= ust >>>> don't see how you can avoid multicast down the road. >>> >>> >> >> >> -- >> Yiqun >> >> > From marshall.eubanks@gmail.com Tue Nov 1 19:38:20 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 70A6A11E8080 for ; Tue, 1 Nov 2011 19:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.09 X-Spam-Level: X-Spam-Status: No, score=-103.09 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, J_CHICKENPOX_13=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 VfaxBCZWB64s for ; Tue, 1 Nov 2011 19:38:20 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD3DB11E80BA for ; Tue, 1 Nov 2011 19:38:19 -0700 (PDT) Received: by qadc10 with SMTP id c10so8134869qad.31 for ; Tue, 01 Nov 2011 19:38: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 :content-type:content-transfer-encoding; bh=uqz8dom7CTVikyw930hKHuFDeKUT9TMuuAeuIAcZPbM=; b=UJkmYVSMn7MddJSU02xf4ZYH3q7Mvox3O9nbaDa83xy6Z8uVbbLtG7PqqqTIEYML61 /V1gCoxzRJrh9j8JGavrcvgIswd4U+eg6nvziurlka2iv+TruOX64LmoVhZYHkpagz4S 40frQ2fvOaM6GpIgQ0sKbMIOr0LiVPFuHl/N4= MIME-Version: 1.0 Received: by 10.182.2.164 with SMTP id 4mr479704obv.49.1320201489593; Tue, 01 Nov 2011 19:38:09 -0700 (PDT) Received: by 10.182.14.65 with HTTP; Tue, 1 Nov 2011 19:38:09 -0700 (PDT) In-Reply-To: <2314E193-4C5A-4CD8-8576-F5F8DAEFCC55@cisco.com> References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> <2314E193-4C5A-4CD8-8576-F5F8DAEFCC55@cisco.com> Date: Tue, 1 Nov 2011 22:38:09 -0400 Message-ID: Subject: Fwd: [vpn4dc] Question on the problem From: Marshall Eubanks To: L3VPN , Robert Raszuk , Pedro Marques , Fred Baker Content-Type: text/plain; charset=windows-1252 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: Wed, 02 Nov 2011 02:38:20 -0000 ---------- Forwarded message ---------- From: Fred Baker Date: Tue, Nov 1, 2011 at 3:48 PM Subject: Re: [vpn4dc] Question on the problem To: robert@raszuk.net Cc: Pedro Marques , Marshall Eubanks , L3VPN On Nov 2, 2011, at 2:02 AM, Robert Raszuk wrote: > Do you think that it is acceptable of arbitrary host in the internet to s= end IP packet to any other host ? I think NIST has this right in their 2009 description of the Smart Grid project. Note that in the electrical grid, there are a lot of parties that for very good reasons should not be able to directly communicate - you don't want script kiddies DDOSing electrical generators or switching systems, which have timing requirements on the order of 1/4 Hz (4 ms) and kill people when that is disrupted, for example. But the statement of direction states that "...the Network should enable an application in a particular domain to communicate with an application in any other domain in the information network, with proper management control over who and where applications can be interconnected.=94 In other words, it should be *capable* of connecting any two systems, and should have appropriate controls to prevent unauthorized connectivity, both in the network and at the host itself. From robert@raszuk.net Wed Nov 2 00:38:49 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 0741C11E809A for ; Wed, 2 Nov 2011 00:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=-0.235, 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 qdM8hAzJh4CN for ; Wed, 2 Nov 2011 00:38:48 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 4AD8D11E8097 for ; Wed, 2 Nov 2011 00:38:48 -0700 (PDT) Received: (qmail 19951 invoked by uid 399); 2 Nov 2011 07:38:47 -0000 Received: from unknown (HELO ?216.69.73.169?) (216.69.73.169) by mail37.opentransfer.com with SMTP; 2 Nov 2011 07:38:47 -0000 Message-ID: <4EB0F385.9090402@raszuk.net> Date: Wed, 02 Nov 2011 08:38:45 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Derick Winkworth Subject: Re: [vpn4dc] Question on the problem References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> <4EB04576.1010905@raszuk.net> <1320190031.96972.YahooMailNeo@web161801.mail.bf1.yahoo.com> <4EB084F2.8030702@raszuk.net> <1320196237.96003.YahooMailNeo@web161803.mail.bf1.yahoo.com> In-Reply-To: <1320196237.96003.YahooMailNeo@web161803.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN , Fred Baker 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: Wed, 02 Nov 2011 07:38:49 -0000 Hi Derick, > Your VMs are not able to directly communicate > with the VMs of another of Google's customers by default. I wonder > how Google achieves this separation... I can buy VM from my or any hosting provider in the Internet in few seconds and this VM will have full access to the Internet ON by default and for that matter to any other VM running in public space. In some cases I can either upload which image such VM should be booted with. My hosting provider does not have any link to you as the SP. So even if I am your L3VPN customer how are you going to attach such VM to be part of my VPN ? How long such attachment will take you ? How are you going to convince my hosting provider to enable host level separation per some solutions proposed already. -- The other topic is when you as the L3VPN SP own data center/cloud and would like to enhance your current MPLS-VPN service offering to offer to your customers an additional VM resources. If this is the model you are describing that I am completely fine with it. However while this is a valid model this is only a subset of VPN models for secure data center inter-connectivity requirements. Best regards, R. > ----- I fail to see why adding VM to any VPN would need to be any > harder or any different than the examples provided above. ---- > > The complexity is hidden from you in the case of Google or Amazon. > It would be hidden from the tenant in the case of VPN4DC. the > difference is that, as a MPLS network operator, the tenant's private > networks already exist at the edge of my data center in the form of > virtual-routers. My customers would like the VMs I provision for > them to appear native to their L3VPN network. Think > virtual-datacenter for private networks. > > > ---------- Note that VMs can be short lived and placed in arbitrary > data center locations on the network. Who do you tell that you need > to join a VPN ? ---------- > > The tenant tells noone. I, on the other hand, would like to > automate turning up a VM and attaching it to a customers L3VPN so it > appears native to their private network and provide the same illusion > of simplicity to my tenant as Google or Amazon provides to customers > who find internet-based cloud services acceptable. > > ------- In other words if I would like to buy a VM resources from any > cloud providers (for example: Amazon, Google ...) all I should need > is to log in to such VPN and establish a VPN connection to the rest > of my enterprise network - smartphones included. ---------- > > You realize there is more going on under the hood in your example > than you have indicated? > > > > Thx, R. > >> Robert: >> >> ########## That is in fact another reason why such VPN isolation >> should rather not require configuration of number of other >> elements then VMs itself. >> >> ######### >> >> Can you elaborate on this statement? On the face of it, I could >> not disagree more. We absolutely want to containerize VMs in the >> network and not have any dependencies at all on configuration >> within the VM itself.. >> >> Derick From neil.2.harrison@bt.com Wed Nov 2 06:01: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 8A31D21F90EA for ; Wed, 2 Nov 2011 06:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 03Qy+Dv+Cfdt for ; Wed, 2 Nov 2011 06:01:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8721F901F for ; Wed, 2 Nov 2011 06:01:40 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 2 Nov 2011 13:01:39 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.68]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 2 Nov 2011 13:01:39 +0000 From: To: , Date: Wed, 2 Nov 2011 13:01:22 +0000 Subject: RE: [vpn4dc] Question on the problem Thread-Topic: [vpn4dc] Question on the problem Thread-Index: AcyZMnf+3fEwphIzRCmZg7RN2eTo1AALCfuQ Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4406730299B@EMV62-UKRD.domain1.systemhost.net> References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> <4EB04576.1010905@raszuk.net> <1320190031.96972.YahooMailNeo@web161801.mail.bf1.yahoo.com> <4EB084F2.8030702@raszuk.net> <1320196237.96003.YahooMailNeo@web161803.mail.bf1.yahoo.com> <4EB0F385.9090402@raszuk.net> In-Reply-To: <4EB0F385.9090402@raszuk.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: l3vpn@ietf.org, fred@cisco.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: Wed, 02 Nov 2011 13:01:41 -0000 Hi Robert, You wrote 02 November 2011 07:39 > To: Derick Winkworth > Cc: L3VPN; Fred Baker > Subject: Re: [vpn4dc] Question on the problem >=20 > Hi Derick, >=20 > > Your VMs are not able to directly communicate > > with the VMs of another of Google's customers by default. I wonder > > how Google achieves this separation... >=20 > I can buy VM from my or any hosting provider in the Internet in few > seconds and this VM will have full access to the Internet ON by default > and for that matter to any other VM running in public space. In some > cases I can either upload which image such VM should be booted with. >=20 > My hosting provider does not have any link to you as the SP. So even if > I am your L3VPN customer how are you going to attach such VM to be part > of my VPN ? How long such attachment will take you ? How are you going > to convince my hosting provider to enable host level separation per > some > solutions proposed already. You (and Fred before you) make some excellent points Robert. I hope folks = are listening to these. The whole notion of 'L3' vs 'L2' is seriously flaw= ed as we all should know by now. There are many layer networks operating a= t L3 in all 3 network modes of co-cs, co-ps and cl-ps...the network mode is= a function of how one carves up space/freq/time resource dimensions and la= bels them for different client instances. Indeed if this were not true the= n IETF would not be working on GMPLS (co-cs) or MPLS-TP (co-ps) to augment = IP (cl-ps). Note - The notion of a single instance of routing running IP t= o Optics is flawed for many reasons and at the heart of many of the problem= s here. The so-called 'L3 VPNs' have no need to use MPLS...we can use any server te= chnology here to create the client/server separation of a client IP layer n= etwork from whatever mode of technology lies under it....though having pukk= a single source connections for the server layer network technology is a ke= y requirement if one wants strong control of resource allocation/separation= to each client.=20 The primary reason IP is so important is not the flawed OSI L3 RM nonsense,= but the simple fact that it contains adaptation functions that allows the = interfacing with external (to the network) message/file/stream application = types. Indeed, the whole purpose of *any* networking case is to allow thes= e external message/file/stream applications to communicate over a large geo= graphic distance. Network technologies that have these message/file/stream application adapta= tion functions are what I have called a TOS (Top-of-Stack) layer network. = And it is only here that both public network services and peering at E-NNIs= between different operating parties are required, eg Internet or PSTN say.= ..the PSTN is a 64kbit/s co-cs layer network primarily oriented towards int= erfacing only with stream (voice) applications=20 For all 'VPN' cases what we need is some form of client/server layer networ= k relationship. It is trivially easy to prove that any non-TOS layer netwo= rk does not require peering E-NNIs....that is the route of folks who either= don't understand the technical nature of the problem or simply want to gen= erate unnecessary work/problems/costs. =20 The key client/server 'VPN' requirement relates to transparency and this me= ans strong functional separation of the DP/CP/MP of each client layer netwo= rk instance from each other. This is achieved one way in rfc4364 but it is= not the only way...indeed operators have been doing client/server VPNs a l= ong time before rfc4364 arrived on the scene (the PDH and SDH hierarchies f= or example are exactly this in a very simple form). The clever bits in rfc= 4364 relate to how BGP4 is used by the SP to broker client IP layer CP/rout= ing separation.....this client layer CP/routing aspect can be decoupled fro= m the need for client/server DP separation, and the server layer network he= re has no need to be MPLS. regards, Neil=20 >=20 > -- >=20 > The other topic is when you as the L3VPN SP own data center/cloud and > would like to enhance your current MPLS-VPN service offering to offer > to > your customers an additional VM resources. If this is the model you are > describing that I am completely fine with it. However while this is a > valid model this is only a subset of VPN models for secure data center > inter-connectivity requirements. >=20 > Best regards, > R. >=20 >=20 > > ----- I fail to see why adding VM to any VPN would need to be any > > harder or any different than the examples provided above. ---- > > > > The complexity is hidden from you in the case of Google or Amazon. > > It would be hidden from the tenant in the case of VPN4DC. the > > difference is that, as a MPLS network operator, the tenant's private > > networks already exist at the edge of my data center in the form of > > virtual-routers. My customers would like the VMs I provision for > > them to appear native to their L3VPN network. Think > > virtual-datacenter for private networks. > > > > > > ---------- Note that VMs can be short lived and placed in arbitrary > > data center locations on the network. Who do you tell that you need > > to join a VPN ? ---------- > > > > The tenant tells noone. I, on the other hand, would like to > > automate turning up a VM and attaching it to a customers L3VPN so it > > appears native to their private network and provide the same illusion > > of simplicity to my tenant as Google or Amazon provides to customers > > who find internet-based cloud services acceptable. > > > > ------- In other words if I would like to buy a VM resources from any > > cloud providers (for example: Amazon, Google ...) all I should need > > is to log in to such VPN and establish a VPN connection to the rest > > of my enterprise network - smartphones included. ---------- > > > > You realize there is more going on under the hood in your example > > than you have indicated? > > > > > > > > Thx, R. > > > >> Robert: > >> > >> ########## That is in fact another reason why such VPN isolation > >> should rather not require configuration of number of other > >> elements then VMs itself. > >> > >> ######### > >> > >> Can you elaborate on this statement? On the face of it, I could > >> not disagree more. We absolutely want to containerize VMs in the > >> network and not have any dependencies at all on configuration > >> within the VM itself.. > >> > >> Derick From ben@niven-jenkins.co.uk Wed Nov 2 11:01: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 461B91F0C4B for ; Wed, 2 Nov 2011 11:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.122 X-Spam-Level: X-Spam-Status: No, score=-103.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, 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 S3imUPFHAdIM for ; Wed, 2 Nov 2011 11:01:24 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id C02F11F0C35 for ; Wed, 2 Nov 2011 11:01:24 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-125-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RLf7r-0003pJ-Ce for l3vpn@ietf.org; Wed, 02 Nov 2011 18:01:23 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 Date: Wed, 2 Nov 2011 18:01:21 +0000 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: Wed, 02 Nov 2011 18:01:25 -0000 Colleagues, Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda for IETF 82 = in Taipei. You can find it here: http://www.ietf.org/proceedings/82/agenda/l3vpn.txt At the moment the agenda is a little vague because we are still working = with the VPN4DC proponents on who will lead each slot. We have purposely not put time on the agenda to present/discuss specific = solution drafts as we would like the discussion to be focussed on the = problem/requirements posed by VPN4DC and its applicability to IETF = (including L3VPN). Discussion of specific solution proposals can happen = at future meetings if the VPN4DC work is adopted. Ben From lucy.yong@huawei.com Wed Nov 2 11:54: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 DD9D71F0C59 for ; Wed, 2 Nov 2011 11:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=-0.330, 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 31GPDubHcHlg for ; Wed, 2 Nov 2011 11:54:54 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 68B071F0C44 for ; Wed, 2 Nov 2011 11:54:54 -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 <0LU100DP8R20EU@usaga02-in.huawei.com> for l3vpn@ietf.org; Wed, 02 Nov 2011 13:51:36 -0500 (CDT) Received: from dfweml202-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 <0LU100EIFR20ON@usaga02-in.huawei.com> for l3vpn@ietf.org; Wed, 02 Nov 2011 13:51:36 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 02 Nov 2011 11:51:37 -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; Wed, 02 Nov 2011 11:51:27 -0700 Date: Wed, 02 Nov 2011 18:51:27 +0000 From: Lucy yong Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: X-Originating-IP: [10.192.11.76] To: Ben Niven-Jenkins , L3VPN WG mailing list Message-id: <2691CE0099834E4A9C5044EEC662BB9D118D6A0D@dfweml505-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmYl5ZBhekuJZ20GHKuq0eUCi7ZWZ7C8g X-MS-Has-Attach: X-MS-TNEF-Correlator: References: 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, 02 Nov 2011 18:54:55 -0000 Ben, It is good to present the l3vpn protocol gap analysis as well, which helps the group to understand the protocol weakness in supporting VPN4DC requirements. Regards, Lucy -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 Colleagues, Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda for IETF 82 in Taipei. You can find it here: http://www.ietf.org/proceedings/82/agenda/l3vpn.txt At the moment the agenda is a little vague because we are still working with the VPN4DC proponents on who will lead each slot. We have purposely not put time on the agenda to present/discuss specific solution drafts as we would like the discussion to be focussed on the problem/requirements posed by VPN4DC and its applicability to IETF (including L3VPN). Discussion of specific solution proposals can happen at future meetings if the VPN4DC work is adopted. Ben From pedro.r.marques@gmail.com Wed Nov 2 16:25: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 B971411E8094 for ; Wed, 2 Nov 2011 16:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 gvUERYSCH1-G for ; Wed, 2 Nov 2011 16:25:10 -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 6B1CB11E8091 for ; Wed, 2 Nov 2011 16:25:10 -0700 (PDT) Received: by iaeo4 with SMTP id o4so825700iae.31 for ; Wed, 02 Nov 2011 16:25:09 -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=ZZ384/Q84eYCQ0+KmbiHoua2rf+FD7adPp7mXOErfyY=; b=qzoZQjTa3sXQKgjaFm9DdUdZF0DZWGZyuEcFYlEbDTY8Vgp5S9RntOUKr++XKLCgra MdyjR10LSGhQEa97u+fc2CQsB1oXkn2xvZmcGOy78Ayl/flu4kF5nezulwIsCo826hoe xVfT6sajkSWxEa/DjrXDAYOR1tiAtApTnG5lM= MIME-Version: 1.0 Received: by 10.231.28.209 with SMTP id n17mr1140340ibc.89.1320276308138; Wed, 02 Nov 2011 16:25:08 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Wed, 2 Nov 2011 16:25:08 -0700 (PDT) Date: Wed, 2 Nov 2011 16:25:08 -0700 Message-ID: Subject: SDN charter and work items From: Pedro Marques To: sdnp@lucidvision.com, l3vpn@ietf.org Content-Type: multipart/mixed; boundary=0015177413885a19ed04b0c8c890 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, 02 Nov 2011 23:25:11 -0000 --0015177413885a19ed04b0c8c890 Content-Type: text/plain; charset=ISO-8859-1 Dear colleagues, It has become a common methodology within the IETF to start with a top level discussion on problem statement and architectural frameworks and them move discuss solutions. In the specific case of the SDN work that is being proposed, it is my opinion that the IETF should initially focus on building a small number of solutions such that they yield at least two interoperable implementations, before generalizing into architectural frameworks. The field of programmable interfaces to network information is new, and so is the data-center network virtualization area. Without testing concrete solutions and learning from experience, it is rather unlikely that there would be no way to resolve between different opinions of what the abstract architecture should be and should include. The overall experience in these topics in the whole industry and the IETF in particular is shallow. There is a very considerable interest at the moment in DC centric solutions for network virtualization. For reasons of development agility a large number of parties in this space have gravitated towards proprietary solutions. There is a small window of opportunity for those that believe in building open and interoperable ecosystems to attempt to work with these more nimbler players, as long as that is achieved in reasonable timescales. Does standardization mean an interminable bureaucratic process or does it actually lead to creating an eco-system in which many players can trive ? In the spirit of "running code and rough consensus" i believe the SDN effort should focus on building a small number of "test" solutions and then iterate from there. While i will proceed to "peddle" one proposal that i've been working on by no means i want to suggest that it is sufficient to explore that specific proposal in order to be able to determine what the "D" in SDN really means. But i would like to suggest that the way to go about it is by experimentation. As one possible vision of what SDN could mean i would like to submit: - A proposal for DC VPNs: http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 - The document in attachement which proposes a possible interface between an orchestration system and a routing infrastructure such as the one above. Both these documents follow a very incremental approach and attempt to deliver the desired functionality without reinventing components which are known to work correctly today. The underlying protocols that are being reused are fully documented and standardized and multiple implementations exist from which is possible to quickly build the proposed extensions. It is at least a data point. My humble suggestion is that the IETF collects several distinct data points before it attempts to engage in a broader top-down architectural approach. thank you for your attention, Pedro. --0015177413885a19ed04b0c8c890 Content-Type: text/plain; charset=US-ASCII; name="sdnp-l3vpn-schema.txt" Content-Disposition: attachment; filename="sdnp-l3vpn-schema.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_guiyehk91 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBQLiBNYXJxdWVzDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTENCkludGVuZGVkIHN0YXR1czog U3RhbmRhcmRzIFRyYWNrDQpFeHBpcmVzOiBNYXkgMTQsIDIwMTINCg0KICAgICAgICAgICAgICAg ICAgICAgICBJRi1NQVAgc2NoZW1hIGZvciBJUCBWUE5zLg0KICAgICAgICAgICAgICAgICAgIGRy YWZ0LW1hcnF1ZXMtc25kcC1sM3Zwbi1zY2hlbWEtMDANCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIHRoZSBtZXRhZGF0YSBzY2hlbWEgdXNlZCB0byBkZWZpbmUgdGhlIHJv dXRlDQogICBleGNoYW5nZSBwb2xpY2llcyBvZiBhbiBJUCBWUE4gbmV0d29yay4gIEluZm9ybWF0 aW9uIGVsZW1lbnRzDQogICBjb25mb3JtaW5nIHRvIHRoaXMgc2NoZW1hIGNhbiBiZSBkaXN0cmli dXRlZCB1c2luZyB0aGUgSUYtTUFQIFtpZi0NCiAgIG1hcF0gc3BlY2lmaWNhdGlvbi4gIFRoZSBz Y2hlbWEgaXMgYXBwbGljYWJsZSBib3RoIHRvIHRoZSBzdGFuZGFyZA0KICAgQkdQIElQIFZQTiBb UkZDNDM2NF0gZGVwbG95bWVudHMgd2l0aGluIHNlcnZpY2UgcHJvdmlkZXIgZW52aXJvbm1lbnRz DQogICBhcyB3ZWxsIGFzIGVuZC1zeXN0ZW0gW0ktRC5tYXJxdWVzLWwzdnBuLWVuZC1zeXN0ZW1d IGJhc2VkDQogICBkZXBsb3ltZW50cy4NCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBUaGlz IEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhl DQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFm dHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAg VGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWJ1dGUNCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0 IG9mIGN1cnJlbnQgSW50ZXJuZXQtDQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0 IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0 cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGly ZSBvbiBNYXkgMTQsIDIwMTIuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChj KSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQogICBk b2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVu dCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KICAgUHJv dmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cyAoaHR0cDovL3RydXN0ZWUuaWV0Zi5v cmcvDQogICBsaWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZiBwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50Lg0KICAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2Fy ZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzDQogICBhbmQgcmVzdHJpY3Rpb25z IHdpdGggcmVzcGVjdCB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzDQogICBleHRy YWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNl bnNlIHRleHQNCiAgIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZiB0aGUgVHJ1c3QgTGVn YWwgUHJvdmlzaW9ucyBhbmQgYXJlDQogICBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzIGRl c2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4NCg0KVGFibGUgb2YgQ29udGVu dHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAyDQoNCk1hcnF1ZXMgICAgICAgICAgICAgICAgICAgICAgICAg ICBzdGQgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgbDN2cG4gc2NoZW1hICAgICAgICAgICAgICAgICBOb3ZlbWJlciAy MDExDQoNCiAgIDIuICBEYXRhIE1vZGVsIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgICAyLjEuICBJZGVudGlmaWVycyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgICAgMi4xLjEuICBj dXN0b21lci1hdHRhY2hlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQN CiAgICAgICAyLjEuMi4gIHJvdXRpbmctdGFibGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNA0KICAgICAgIDIuMS4zLiAgcm91dGUtdGFyZ2V0IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgICAgMi4xLjQuICBwcm92aWRl ci1lZGdlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgICAg Mi4yLiAgTWV0YWRhdGEgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNQ0KICAgICAgIDIuMi4xLiAgYXR0YWNoZW1lbnQtc3RhdGUgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICAgICAgMi4yLjIuICBiaW5kaW5nICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgICAyLjIu My4gIEltcG9ydCBhbmQgZXhwb3J0IHRhcmdldHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNg0KICAgMy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICA0LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgIEF1dGhvcidzIEFkZHJl c3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0K DQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBzY2hlbWEgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50IGFsbG93cyBhIG1hbmFnZW1lbnQgY29uc29sZSBvcg0KICAgb3JjaGVzdHJhdGlvbiBzeXN0 ZW0gdG8gZGVmaW5lIElQIFZQTnMgYW5kIHRoZWlyIGFjY2VzcyBwb2xpY2llcyBhbmQNCiAgIGRp c3RyaWJ1dGUgdGhhdCBpbmZvcm1hdGlvbiB0byBhbGwgUHJvdmlkZXIgRWRnZSAoUEUpIGRldmlj ZXMuICBJdA0KICAgYWxzbyBhbGxvd3MgdGhlIFBFIGRldmljZXMgdG8gcHVibGlzaCB0aGUgaW5m b3JtYXRpb24gb2Ygd2hpY2gNCiAgIGN1c3RvbWVyIGF0dGFjaGVtZW50IHBvaW50cyBhcmUgbG9j YWxseSBhc3NvY2lhdGVkIHdpdGggZWFjaCBWUE4NCiAgIHJvdXRpbmctdGFibGUsIHByb3ZpZGlu ZyBhIG1lY2hhbmlzbSBieSB3aGljaCBhIG1hbmFnZW1lbnQgZW50aXR5LA0KICAgcG90ZW50aWFs bHkgZGlmZmVyZW50IGZyb20gdGhlIG9uZSBlc3RhYmxpc2hpbmcgYWNjZXNzIHBvbGljaWVzLCBj YW4NCiAgIHZlcmlmeSB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgb2YgdGhlIG5ldHdvcmsuDQoNCiAg IEluIG9yZGVyIHRvIGRlZmluZSBhbiBJUCBWUE4sIGEgbWFuYWdlbWVudCBzeXN0ZW0sIG11c3Qg c2VsZWN0IGEgVlBODQogICBpZGVudGlmaWVyIGFuZCBhc3NvY2lhdGUgaXQgd2l0aCBhIHJvdXRl LXRhcmdldCB2YWx1ZS4gIFRoYXQNCiAgIG9wZXJhdGlvbiBpcyBhY2hpZXZlZCBieSBzZW5kaW5n IHRoZSBmb2xsb3dpbmcgWE1MIGRvY3VtZW50IHRvIGFuIElGLQ0KICAgTUFQIHNlcnZlci4NCg0K ICAgPD94bWwgdmVyc2lvbj0iMS4wIj8+DQogICA8aWZtYXA6cHVibGlzaCBzZXNzaW9uLWlkPSIx Ig0KICAgICAgIHhtbG5zOmlmbWFwPSJodHRwOi8vaWV0Zi5vcmcvSS1ELm1hcnF1ZXMtbDN2cG4t c2NoZW1hIj4NCiAgICAgPHVwZGF0ZT4NCiAgICAgICA8cm91dGluZy10YWJsZSBuYW1lPSJTaW1w bGVWUE4iPg0KICAgICAgIDxtZXRhZGF0YT4NCiAgICAgICAgIDxpbXBvcnQtdGFyZ2V0Pg0KICAg ICAgICAgICA8cm91dGUtdGFyZ2V0PjE6MC4wLjAuMTwvcm91dGUtdGFyZ2V0Pg0KICAgICAgICAg PC9pbXBvcnQtdGFyZ2V0Pg0KICAgICAgICAgPGV4cG9ydC10YXJnZXQ+DQogICAgICAgICAgIDxy b3V0ZS10YXJnZXQ+MTowLjAuMC4xPC9yb3V0ZS10YXJnZXQ+DQogICAgICAgICA8L2V4cG9ydC10 YXJnZXQ+DQogICAgICAgPC9tZXRhZGF0YT4NCiAgICAgPC91cGRhdGU+DQogICA8L2lmbWFwOnB1 Ymxpc2g+DQoNCiAgIEluIHRoZSBWUE4gZGVmaW5pdGlvbiBhYm92ZSwgdGhlIGltcG9ydCBhbnQg ZXhwb3J0IHJvdXRlLXRhcmdldCBsaXN0DQogICBpcyB0aGUgc2FtZSwgY3JlYXRpbmcgYSBjbG9z ZWQgZ3JvdXAgVlBOIGluIHdoaWNoIGFueSBjdXN0b21lcg0KICAgYXR0YWNoZW1lbnQgY2FuIG9u bHkgY29tbXVuaWNhdGUgd2l0aCBvdGhlciBtZW1iZXJzIG9mIHRoZSBzYW1lIFZQTi4NCiAgIFRo aXMgZGVmaW5pdGlvbiBpcyBwdWJsaXNoZWQgaW4gdGhlIE1BUCBzZXJ2ZXIgYW5kIGF2YWlsYWJs ZSB0byBhbGwNCiAgIFBFIGRldmljZXMgd2hpY2ggbWF5IGVpdGhlciBzdWJzY3JpYmUgdG8gbm90 aWZpY2F0aW9uIG9yIHBvbGwgdGhlDQogICBpbmZvcm1hdGlvbiBvbi1kZW1hbmQuDQoNCg0KDQoN Cg0KTWFycXVlcyAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0ZCAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsM3Zw biBzY2hlbWEgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTENCg0KICAgVGhlIFhNTCBlbGVt ZW50ICJyb3V0aW5nLXRhYmxlIiBhYm92ZSByZWZlcnMgbm90IHRvIGEgcGFydGljdWxhcg0KICAg aW5zdGFudGlhdGlvbiBvZiBhIFZSRiB0YWJsZSBvbiBhIFBFIGRldmljZSBidXQgYSBjb25maWd1 cmF0aW9uDQogICB0ZW1wbGF0ZSB0aGF0IGlzIHVzZWQgdG8gaW5zdGFudGlhdGUgdGhlIHNwZWNp ZmljIHJvdXRpbmcgdGFibGVzLg0KDQogICBUaGUgc2NoZW1hIGFsbG93cyBmb3IgbXVsdGlwbGUg aW1wb3J0IGFuZCBleHBvcnQgdGFyZ2V0cyB0byBiZQ0KICAgY29uZmlndXJlZCBvbiBhIHBhcnRp Y3VsYXIgInJvdXRpbmctdGFibGUiIGluIG9yZGVyIHRvIGFsbG93IGZvcg0KICAgc2NlbmFyaW9z IHdoZXJlIHRoZXJlIGlzIGRpcmVjdCB0cmFmZmljIGV4Y2hhbmdlIGJldHdlZW4gZGlmZmVyZW50 DQogICBWUE5zLiAgRm9yIGV4YW1wbGUsIGEgY29tbW9uIHNlcnZpY2Ugc3VjaCBhcyBzdG9yYWdl IG1heSBoYXZlIGENCiAgICJzdG9yYWdlLWZyb250ZW5kIiBWUE4gd2hpY2ggaW1wb3J0cyB0aGUg cm91dGUtdGFyZ2V0cyBvZiBhbGwgaXRzDQogICBjdXN0b21lciBWUE5zLiAgVGhlIGN1c3RvbWVy IFZQTnMgd291bGQgYWxzbyBpbXBvcnQgdGhlIHJvdXRlLXRhcmdldA0KICAgYXNzb2NpYXRlZCB3 aXRoIHRoZSAic3RvcmFnZS1mcm9udGVuZCIgc2VydmljZS4NCg0KICAgSW4gb3JkZXIgdG8gYXNz b2NpYXRlIGEgZ2l2ZW4gImF0dGFjaGVtZW50IGNpcmN1aXQiIHRvIGEgcm91dGluZy0NCiAgIHRh YmxlIGEgUEUgZGV2aWNlIG1heSBlaXRoZXIgY29uc3VsdCB0aGUgTUFQIHNlcnZlciBvciByZWx5 IG9uIGENCiAgIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJvdmlkZWQgYnkgdGhlIGN1c3RvbWVyIGRl dmljZSB2aWEgYSBQRS1DRQ0KICAgY29tbXVuaWNhdGlvbiBwcm90b2NvbC4gIEluIHRoZSBzZWNv bmQgY2FzZSBpdCBpcyBpbXBvcnRhbnQgZm9yIHRoZQ0KICAgUEUgdG8gYmUgYWJsZSB0byBwdWJs aXNoIHRoYXQgbWFwcGluZyB0byB0aGUgTUFQIHNlcnZlciBpbiBvcmRlciB0bw0KICAgcHJvdmlk ZSB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgb2YgdGhlIG5ldHdvcmsuDQoNCiAgIFJlZ2FyZGxlc3Mg b2Ygd2hldGhlciB0aGUgYXNzb2NpYXRpb24gaXMgY2VudHJhbGx5IGRldGVybWluZWQgYnkgYQ0K ICAgcHJvdmlzaW9uaW5nIHN5c3RlbSBvciBieSB0aGUgUEUgaXQgY2FuIGJlIGFkZGVkIHRvIHRo ZSBNQVAgc2VydmVyDQogICB2aWEgdGhlIGZvbGxvd2luZyBtZXNzYWdlOg0KDQogICA8P3htbCB2 ZXJzaW9uPSIxLjAiPz4NCiAgIDxpZm1hcDpwdWJsaXNoIHNlc3Npb24taWQ9IjEiDQogICAgICAg eG1sbnM6aWZtYXA9Imh0dHA6Ly9pZXRmLm9yZy9JLUQubWFycXVlcy1sM3Zwbi1zY2hlbWEiPg0K ICAgICA8dXBkYXRlPg0KICAgICAgIDxjdXN0b21lci1hdHRhY2hlbWVudCBpZD0idm06MDA6MDA6 MDA6MDE6MDI6MDMiLz4NCiAgICAgICA8bWV0YWRhdGE+DQogICAgICAgICA8YmluZGluZyBpZm1h cC1jYXJkaW5hbGl0eT0ic2luZ2xlVmFsdWUiPg0KICAgICAgICAgICAgPHRhYmxlLW5hbWU+U2lt cGxlVlBOPC90YWJsZS1uYW1lPg0KICAgICAgICAgPC9iaW5kaW5nPg0KICAgICAgICAgPGF0dGFj aGVtZW50LXN0YXRlIGlmbWFwLWNhcmRpbmFsaXR5PSJtdWx0aVZhbHVlIj4NCiAgICAgICAgPHBy b3ZpZGVyLWVkZ2U+MTkyLjE2OC4wLjE8L3Byb3ZpZGVyLWVkZ2U+DQogICAgICAgIDxzdGF0ZT5V cDwvc3RhdGU+DQogICAgICAgICA8L2F0dGFjaGVtZW50LXN0YXRlPg0KICAgICAgIDwvbWV0YWRh dGE+DQogICAgIDwvdXBkYXRlPg0KICAgPC9pZm1hcDpwdWJsaXNoPg0KDQogICBUaGUgbWV0YWRh dGEgaW5mb3JtYXRpb24gaW4gdGhpcyB1cGRhdGUgbWVzc2FnZSBjb250YWlucyBib3RoIHRoZQ0K ICAgaW5mb3JtYXRpb24gb2Ygd2hpY2ggcm91dGluZyB0YWJsZSBpcyB0aGUgY2lyY3VpdCBib3Vu ZCB0byBhcyB3ZWxsIGFzDQogICBpdHMgb3BlcmF0aW9uYWwgc3RhdGUuDQoNCiAgIEJ5IHN0b3Jp bmcgdGhpcyBpbmZvcm1hdGlvbiBvbiBhIE1BUCBzZXJ2ZXIgdGhlIHByb3Zpc2lvbmluZyBhbmQN CiAgIG9wZXJhdGlvbmFsIHN0YXRlIG9mIGFsbCBJUCBWUE5zIGluIGEgZG9tYWluIGNhbiBiZSBr bm93bi4gIE5vdGUgdGhhdA0KICAgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gY29ycmVzcG9uZGlu ZyB0byB3aGljaCBJUCBwcmVmaXhlcyBhcmUNCiAgIGN1cnJlbnRseSByZWFjaGFibGUgYW5kIHRo ZSBzZWxlY3Rpb24gb2YgdGhlIHByZWZlcnJlZCBwYXRoIGZvciBhDQogICBnaXZlbiBJUCBwYWNr ZXQgYXJlIHN0aWxsIGRvbmUgdXNpbmcgQkdQIElQIFZQTi4NCg0KICAgUm91dGluZyBpbmZvcm1h dGlvbiBpcyBib3RoIHZlcnkgZHluYW1pYyBhcyB3ZWxsIGFzIHBvdGVudGlhbGx5DQogICBkaWZm ZXJlbnQgYXQgZWFjaCBzcGVjaWZpYyBWUkYgdGFibGUsIHNpbmNlIHRoZSBuZXR3b3JrIGxvY2F0 aW9uDQogICBpbmZsdWVuY2VzIHBhdGggc2VsZWN0aW9uLiAgSW5mb3JtYXRpb24gc3RvcmVkIGlu IHRoZSBNQVAgc2VydmVyIGlzLA0KICAgdHlwaWNhbGx5LCBtb3JlIGdsb2JhbCBpbiBuYXR1cmUu DQoNCjIuICBEYXRhIE1vZGVsDQoNCk1hcnF1ZXMgICAgICAgICAgICAgICAgICAgICAgICAgICBz dGQgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgbDN2cG4gc2NoZW1hICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEx DQoNCg0KICAgVGhlIGZpZ3VyZSBiZWxsb3cgY29udGFpbnMgdGhlIGRhdGEtbW9kZWwgdXNlZCB0 byByZXByZXNlbnQgdGhlDQogICBwcm92aXNpb25pbmcgaW5mb3JtYXRpb24gbmVjZXNzYXJ5IHRv IGF0dGFjaCBhIGdpdmVuIGN1c3RvbWVyIGNpcmN1aXQNCiAgIHRvIGFuIElQIFZQTi4gIEluIGl0 IGlkZW50aWZpZXJzIGFyZSByZXByZXNlbnRlZCBieSBib3hlcyB3aGlsZQ0KICAgbWV0YWRhdGEg aXMgcmVwcmVzZW50ZWQgYnkgZWxlbWVudHMgaW4gc3F1YXJlIGJyYWNrZXRzLg0KDQogICArLS0t LS0tLS0tLS0tLSsNCiAgIHwgIGN1c3RvbWVyICAgfCAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0rDQogICB8IGF0dGFjaGVtZW50IHwtLSBbIGJpbmRpbmcgXSAtLSB8IHJvdXRpbmct dGFibGUgfA0KICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLSsNCiAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8gICAgXA0K ICAgW2F0dGFjaGVtZW50LXN0YXRlXSAgICAgWyBpbXBvcnQtdGFyZ2V0IF0gIFsgZXhwb3J0LXRh cmdldCBdDQogICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8 DQogICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rDQog ICB8IHByb3ZpZGVyLWVkZ2UgfCAgICAgICAgICAgICAgICB8IHJvdXRlLXRhcmdldCB8DQogICAr LS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rDQoNCjIuMS4g IElkZW50aWZpZXJzDQoNCiAgIFRoZSBmb2xsb3dpbmcgSWRlbnRpZmllcnMgYXJlIGRlZmluZWQg Zm9yIHRoaXMgc2NoZW1hOg0KDQoyLjEuMS4gIGN1c3RvbWVyLWF0dGFjaGVtZW50DQoNCiAgIFRo ZSAiY3VzdG9tZXIgYXR0YWNoZW1lbnQiIGlkZW50aWZpZXIgcmVwcmVzZW50cyBhIGNpcmN1aXQg Y29ubmVjdGluZw0KICAgdG8gYSBjdXN0b21lciBlZGdlIGRldmljZSBpbiB0aGUgc3RhbmRhcmQg QkdQIElQIFZQTiBhcHBsaWNhdGlvbi4NCiAgIFdoZW4gdGhlIG5ldHdvcmsgaW4gcXVlc3Rpb24g aXMgdXNpbmcgYW4gZW5kLXN5c3RlbSBbSS1ELm1hcnF1ZXMtDQogICBsM3Zwbi1lbmQtc3lzdGVt XSBiYXNlZCBpbXBsZW1lbnRhdGlvbiwgdGhlICJjdXN0b21lciBhdHRhY2hlbWVudCINCiAgIHJl cHJlc2VudHMgdGhlIFhNUFAgY2xpZW50IHNlc3Npb24gYmV0d2VlbiB0aGUgZW5kLXN5c3RlbSBh bmQNCiAgIHNpZ25hbGluZyBnYXRld2F5Lg0KDQogICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9IkN1 c3RvbWVyQXR0YWNoZW1lbnRUeXBlIj4NCiAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iaWQiIHR5 cGU9InhzZDpzdHJpbmciIHVzZT0icmVxdWlyZWQiPg0KICAgPC94c2Q6Y29tcGxleFR5cGU+DQoN CjIuMS4yLiAgcm91dGluZy10YWJsZQ0KDQogICBUaGUgInJvdXRpbmcgdGFibGUiIGVsZW1lbnQg cmVwcmVzZW50cyBhIGNvbmZpZ3VyYXRpb24gdGVtcGxhdGUgdXNlZA0KICAgdG8gcHJvdmlzaW9u IGEgVlJGIHRhYmxlIG9uIGEgUEUgb3IgYSByb3V0aW5nIHRhYmxlIG9uIGEgQkdQL1hNUFANCiAg IHNpZ25hbGluZyBnYXRld2F5Lg0KDQogICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9IlJvdXRpbmdU YWJsZVR5cGUiPg0KICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJuYW1lIiB0eXBlPSJ4c2Q6c3Ry aW5nIiB1c2U9InJlcXVpcmVkIj4NCiAgIDwveHNkOmNvbXBsZXhUeXBlPg0KDQoyLjEuMy4gIHJv dXRlLXRhcmdldA0KDQogICBJbiBCR1AgSVAgVlBOcywgcm91dGUgdGFyZ2V0cyBhcmUgYXNzb2Np YXRlZCB3aXRoIFZQTiByb3V0aW5nDQogICBpbmZvcm1hdGlvbiBhbmQgdXNlZCB0byBleHByZXNz IHJvdXRpbmcgdGFibGUgaW1wb3J0IGFuZCBleHBvcnQNCiAgIHBvbGljaWVzLg0KDQogICA8eHNk OmNvbXBsZXhUeXBlIG5hbWU9IlJvdXRlVGFyZ2V0VHlwZSI+DQogICAgIDx4c2Q6YXR0cmlidXRl IG5hbWU9InZhbHVlIiB0eXBlPSJ4c2Q6c3RyaW5nIiB1c2U9InJlcXVpcmVkIj4NCiAgIDwveHNk OmNvbXBsZXhUeXBlPg0KDQoyLjEuNC4gIHByb3ZpZGVyLWVkZ2UNCg0KDQpNYXJxdWVzICAgICAg ICAgICAgICAgICAgICAgICAgICAgc3RkICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug NF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIGwzdnBuIHNjaGVtYSAgICAgICAg ICAgICAgICAgTm92ZW1iZXIgMjAxMQ0KDQoNCiAgIEEgInByb3ZpZGVyLWVkZ2UiIGVsZW1lbnQg aWRlbnRpZmllcyBhIHNwZWNpZmljIFBFIGRldmljZS4NCg0KICAgPHhzZDpjb21wbGV4VHlwZSBu YW1lPSJQcm92aWRlckVkZ2VUeXBlIj4NCiAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iaWQiIHR5 cGU9InNtaTpJcEFkZHJlc3MiIHVzZT0icmVxdWlyZWQiPg0KICAgPC94c2Q6Y29tcGxleFR5cGU+ DQoNCiAgIEluIHRoZSBkZWZpbml0aW9uIGFib3ZlIHRoZSAic21pIiBuYW1lc3BhY2UgaXMgcmVm ZXJzIHRvIHRoZSBTTk1QIFNNSQ0KICAgWE1MIHNjaGVtYSBbUkZDNTkzNV0uDQoNCjIuMi4gIE1l dGFkYXRhDQoNCiAgIEluIHRoZSBJRi1NQVAgc3BlY2lmaWNhdGlvbiBbaWYtbWFwXSBtZXRhZGF0 YSBkZXRlcm1pbmVzIHRoZSBzdGF0ZSBvZg0KICAgdGhlIE1BUCBkYXRhYmFzZS4gIElkZW50aWZp ZXJzIGFyZSBpbW11dGFibGUgY29uc3RhbnRzLiAgTWV0YWRhdGENCiAgIHVwZGF0ZSBhbmQgZGVs ZXRlIHJlcXVlc3RzIHJlcHJlc2VudCBzdGF0ZSBhbmQgbGVhZCB0byB1cGRhdGVzIGJlaW5nDQog ICBzZW50IHRvIHN1YnNjcmliZXJzLg0KDQoyLjIuMS4gIGF0dGFjaGVtZW50LXN0YXRlDQoNCiAg IFRoZSBhdHRhY2hlbWVudC1zdGF0ZSBtZXRhZGF0YSBlbGVtZW50IGlzIHVzZWQgdG8gYXNzb2Np YXRlIGENCiAgICJjdXN0b21lci1hdHRhY2hlbWVudCIgd2l0aCBhIFBFIGRldmljZS4gIEl0IGNh biBhbHNvIGNvbnZleSBpdHMNCiAgIG9wZXJhdGlvbmFsIHN0YXRlLg0KDQogICBUaGUgY29udGFp bmVkICJsb2NhbC1yb3V0ZXMiIGVsZW1lbnQsIHdoZW4gcHJlc2VudCwgY29udGFpbnMgdGhlDQog ICBudW1iZXIgb2Ygcm91dGVzIHRoYXQgaGF2ZSBiZWVuIGFkdmVyaXNlZCBieSBhIGdpdmVuIGN1 c3RvbWVyDQogICBhdHRhY2hlbWVudCB0byB0aGUgbG9jYWwgUEUgZGV2aWNlLg0KDQogICA8eHNk OmVsZW1lbnQgbmFtZT0iYXR0YWNoZW1lbnQtc3RhdGUiPg0KICAgICA8eHNkOmNvbXBsZXhUeXBl Pg0KICAgICAgIDx4c2Q6c2VxdWVuY2U+DQogICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0icHJv dmlkZXItZWRnZSIgdHlwZT0ic21pOklwQWRkcmVzcyINCiAgICAgICAgICAgICBtaW5PY2N1cnM9 IjEiIG1heE9jY3Vycz0iMSI+DQogICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ic3RhdGUiIG1p bk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIj4NCiAgICAgICAgICAgPHhzZDpzaW1wbGVUeXBlPg0K ICAgICAgICAgPHhzZDpyZXN0cmljdGlvbiBiYXNlPSJ4c2Q6c3RyaW5nIj4NCiAgICAgICAgICAg PHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0iVXAiLz4NCiAgICAgICAgICAgPHhzZDplbnVtZXJhdGlv biB2YWx1ZT0iRG93biIvPg0KICAgICAgICAgICA8eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJBZG1p bkRvd24iLz4NCiAgICAgICAgIDwveHNkOnJlc3RyaWN0aW9uPg0KICAgICAgIDwveHNkOnNpbXBs ZVR5cGU+DQogICAgICAgICA8L3hzZDplbGVtZW50Pg0KICAgICAgICAgPHhzZDplbGVtZW50IG5h bWU9ImxvY2FsLXJvdXRlcyIgdHlwZT0ieHNkOmludGVnZXIiIG1pbk9jY3Vycz0iMCINCiAgICAg ICAgICAgICBtYXhPY2N1cnM9IjEiLz4NCiAgICAgICA8L3hzZDpzZXF1ZW5jZT4NCiAgICAgICA8 eHNkOmF0dHJpYnV0ZUdyb3VwIHJlZj0iaWZtYXA6c2luZ2xlVmFsdWVNZXRhZGF0YUF0dHJpYnV0 ZXMiLz4NCiAgICAgPC94c2Q6Y29tcGxleFR5cGU+DQogICA8L3hzZDplbGVtZW50Pg0KDQoyLjIu Mi4gIGJpbmRpbmcNCg0KICAgVGhlIGJpbmRpbmcgbWV0YWRhdGEgZWxlbWVudCBhc3NvY2lhdGVz IGEgY3VzdG9tZXIgYXR0YWNoZW1lbnQgd2l0aCBhDQogICBzcGVjaWZpYyBWUE4uIEl0IGNvbnRh aW5zIG5vIG9wZXJhdGlvbmFsIHN0YXRlIGFuZCBtYXliZSBpbnNlcnRlZCBieQ0KICAgZWl0aGVy IGEgUEUgZGV2aWNlIG9yIGEgcHJvdmlzaW9uaW5nIHN5c3RlbS4NCg0KDQoNCg0KTWFycXVlcyAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN0ZCAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsM3ZwbiBzY2hlbWEgICAg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTENCg0KDQogICA8eHNkOmVsZW1lbnQgbmFtZT0iYmlu ZGluZyI+DQogICAgIDx4c2Q6Y29tcGxleFR5cGU+DQogICAgICAgPHhzZDpzZXF1ZW5jZT4NCiAg ICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJ0YWJsZS1uYW1lIiB0eXBlPSJ4c2Q6c3RyaW5nIiBt aW5PY2N1cnM9IjEiDQogICAgICAgICAgICAgbWF4T2NjdXJzPSIxIj4NCiAgICAgICA8L3hzZDpz ZXF1ZW5jZT4NCiAgICAgICA8eHNkOmF0dHJpYnV0ZUdyb3VwIHJlZj0iaWZtYXA6c2luZ2xlVmFs dWVNZXRhZGF0YUF0dHJpYnV0ZXMiLz4NCiAgICAgPC94c2Q6Y29tcGxleFR5cGU+DQogICA8L3hz ZDplbGVtZW50Pg0KDQoyLjIuMy4gIEltcG9ydCBhbmQgZXhwb3J0IHRhcmdldHMNCg0KICAgVGhl IGltcG9ydCBhbmQgZXhwb3J0IHRhcmdldCBlbGVtZW50cyBzcGVjaWZpYyB0aGUgbGlzdCBvZiBy b3V0ZS0NCiAgIHRhcmdldHMgdGhhdCBzcGVjaWZ5IGEgcm91dGluZy10YWJsZSBpbXBvcnQgYW5k IGV4cG9ydCBwb2xpY2llcywNCiAgIHJlc3BlY3RpdmVseS4gIEltcG9ydCB0YXJnZXRzIHNlbGVj dCByb3V0ZXMgd2hpY2ggaGF2ZSBiZWVuDQogICBhc3NvY2lhdGVkIHdpdGggYW55IG9mIHRoZXNl IHRhcmdldHMgdG8gYmUgYWRkZWQgdG8gdGhlIHNwZWNpZmljDQogICByb3V0aW5nIHRhYmxlLiAg RXhwb3J0IHRhcmdldHMgaW5zdHJ1Y3QgdGhlIHJvdXRpbmcgdGFibGUgdG8gdGFnIGENCiAgIHJv dXRlIHdpdGggdGhhdCBzcGVjaWZpYyBsaXN0IG9mIHRhcmdldHMgd2hlbiBhZHZlcnRpc2luZyBh IHJvdXRlIHRvDQogICBvdGhlciBQRSBkZXZpY2VzLiAgUEUgZGV2aWNlcyBtdXN0IGFsc28gaW1w b3J0L2V4cG9ydCByb3V0ZXMgYmV0d2Vlbg0KICAgbG9jYWwgVlJGcyB3aGljaCBjb250YWluIGlu dGVyc2VjdGluZyByb3V0ZSB0YXJnZXQgbGlzdHMuDQoNCiAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJp bXBvcnQtdGFyZ2V0Ij4NCiAgICAgPHhzZDpjb21wbGV4VHlwZT4NCiAgICAgICA8eHNkOnNlcXVl bmNlPg0KICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9InJvdXRlLXRhcmdldCIgdHlwZT0ieHNk OnN0cmluZyIgbWluT2NjdXJzPSIxIg0KICAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVk Ij4NCiAgICAgICA8L3hzZDpzZXF1ZW5jZT4NCiAgICAgICA8eHNkOmF0dHJpYnV0ZUdyb3VwIHJl Zj0iaWZtYXA6c2luZ2xlVmFsdWVNZXRhZGF0YUF0dHJpYnV0ZXMiLz4NCiAgICAgPC94c2Q6Y29t cGxleFR5cGU+DQogICA8L3hzZDplbGVtZW50Pg0KDQozLiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMNCg0KICAgV2hlbiB1c2luZyB0aGlzIGFwcHJvYWNoLCB0aGUgTUFQIGRhdGFiYXNlLCByYXRo ZXIgdGhhbiB0aGUNCiAgIGluZGl2aWR1YWwgY29uZmlndXJhdGlvbnMgb24gUEUgZGV2aWNlcywg YmVjb21lcyB0aGUgInNvdXJjZSBvZg0KICAgdHJ1dGgiIGFib3V0IHRoZSBWUE4gbWVtYmVyc2hp cC4gIEl0IGlzIGltcG9ydGFudCB0byByZXN0cmljdCB0aGUNCiAgIHdyaXRlIGFjY2VzcyB0byB0 aGUgTUFQIGRhdGFiYXNlIHRvIHN5c3RlbXMgdGhhdCBzaG91bGQgYmUgYWxsb3dlZCB0bw0KICAg bW9kaWZpZWQgaXQuDQoNCiAgIEEgTUFQIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgc3Vw cG9ydCBhY2Nlc3MgY29udHJvbHMgb24gYSBwZXINCiAgIG1ldGFkYXRhIGVsZW1lbnQgYmFzaXMg c3VjaCB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIHJlc3RyaWN0IHdyaXRlDQogICBhY2Nlc3MgdG8g YSBzZXQgb2YgbWV0YWRhdGEgZWxlbWVudHMgdG8gYSBzcGVjaWZpYyBsaXN0IG9mDQogICBjZXJ0 aWZpY2F0ZXMuDQoNCjQuICBSZWZlcmVuY2VzDQoNCiAgIFtJLUQubWFycXVlcy1sM3Zwbi1lbmQt c3lzdGVtXQ0KICAgICAgICAgICAgICBNYXJxdWVzLCBQLCBGYW5nLCBMLCBQYW4sIFAgYW5kIEEg U2h1a2xhLCAiRW5kLXN5c3RlbQ0KICAgICAgICAgICAgICBzdXBwb3J0IGZvciBCR1Atc2lnbmFs ZWQgSVAvVlBOcy4iLCBJbnRlcm5ldC1EcmFmdCBkcmFmdC0NCiAgICAgICAgICAgICAgbWFycXVl cy1sM3Zwbi1lbmQtc3lzdGVtLTAyLCBPY3RvYmVyIDIwMTEuDQoNCiAgIFtSRkM0MzY0XSAgUm9z ZW4sIEUuIGFuZCBZLiBSZWtodGVyLCAiQkdQL01QTFMgSVAgVmlydHVhbCBQcml2YXRlDQogICAg ICAgICAgICAgIE5ldHdvcmtzIChWUE5zKSIsIFJGQyA0MzY0LCBGZWJydWFyeSAyMDA2Lg0KDQoN Cg0KTWFycXVlcyAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0ZCAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBsM3Zw biBzY2hlbWEgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTENCg0KDQogICBbUkZDNTkzNV0g IEVsbGlzb24sIE0uIGFuZCBCLiBOYXRhbGUsICJFeHByZXNzaW5nIFNOTVAgU01JIERhdGF0eXBl cw0KICAgICAgICAgICAgICBpbiBYTUwgU2NoZW1hIERlZmluaXRpb24gTGFuZ3VhZ2UiLCBSRkMg NTkzNSwgQXVndXN0IDIwMTAuDQoNCiAgIFtpZi1tYXBdICAgIklGLU1BUCBCaW5kaW5nIGZvciBT T0FQIFNwZWNpZmljYXRpb24gVmVyc2lvbiAyLjAiLCBKdWx5DQogICAgICAgICAgICAgIDIwMTAu DQoNCkF1dGhvcidzIEFkZHJlc3MNCg0KICAgUGVkcm8gTWFycXVlcw0KICAgDQogICBFbWFpbDog cGVkcm8uci5tYXJxdWVzQGdtYWlsLmNvbQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KTWFycXVlcyAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0ZCAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDddDQo= --0015177413885a19ed04b0c8c890-- From linda.dunbar@huawei.com Wed Nov 2 19:56:02 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 9CFD61F0C47 for ; Wed, 2 Nov 2011 19:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=-0.572, 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 LYrWVKcw35ed for ; Wed, 2 Nov 2011 19:56:02 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5801F0C38 for ; Wed, 2 Nov 2011 19:56:02 -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 <0LU2006A6DH7AD@usaga02-in.huawei.com> for l3vpn@ietf.org; Wed, 02 Nov 2011 21:55:55 -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 <0LU2004YQDH6DA@usaga02-in.huawei.com> for l3vpn@ietf.org; Wed, 02 Nov 2011 21:55:55 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 02 Nov 2011 19:55:49 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Wed, 02 Nov 2011 19:55:46 -0700 Date: Thu, 03 Nov 2011 02:55:45 +0000 From: Linda Dunbar Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: X-Originating-IP: [10.47.141.7] To: Ben Niven-Jenkins , L3VPN WG mailing list Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEsw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: 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, 03 Nov 2011 02:56:02 -0000 Who will lead the talk for each topic? Linda > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: Wednesday, November 02, 2011 1:01 PM > To: L3VPN WG mailing list > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > Colleagues, > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda for IETF > 82 in Taipei. You can find it here: > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > At the moment the agenda is a little vague because we are still working > with the VPN4DC proponents on who will lead each slot. > > We have purposely not put time on the agenda to present/discuss > specific solution drafts as we would like the discussion to be focussed > on the problem/requirements posed by VPN4DC and its applicability to > IETF (including L3VPN). Discussion of specific solution proposals can > happen at future meetings if the VPN4DC work is adopted. > > Ben > From lufang@cisco.com Wed Nov 2 21:41: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 84BED11E8115 for ; Wed, 2 Nov 2011 21:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.521 X-Spam-Level: X-Spam-Status: No, score=-4.521 tagged_above=-999 required=5 tests=[AWL=0.878, 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 dAqUpO4orlVN for ; Wed, 2 Nov 2011 21:41:37 -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 8EA8611E8112 for ; Wed, 2 Nov 2011 21:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=2204; q=dns/txt; s=iport; t=1320295297; x=1321504897; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=HBDFxAXY72B9wxeCmJmgyb0rFQElccq4jtul+XJ/uwE=; b=QXL5M57qBtGnFDW6Nq2cd9GRSmy08oqudRITmU8ugbKeclw/YOOiQ+Nw V7E0KA1oFETwwelX3cua5efv9/mqTRm9sfXqj2hzK+eKQkO2ewGhiNd2K xWMe1t99LUyN4e2K1kJPUrljim9Jz/C6cd2EFQu1Yyvs2rmsWl2ZqMZiM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAAEcbsk6tJXHA/2dsb2JhbABEmX2OW4EfgQWBcgEBAQQSAR0KNBcEAgEIEQQBAQsGFwEGAUUJCAIEARIIARIHh2iWFQGeeIg9YQSICJFIjEk X-IronPort-AV: E=Sophos;i="4.69,447,1315180800"; d="scan'208";a="32995909" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 03 Nov 2011 04:41:24 +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 pA34fO37013253; Thu, 3 Nov 2011 04:41:24 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); Wed, 2 Nov 2011 23:41:24 -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: Preliminary L3VPN/VPN4DC agenda @ IETF82 Date: Wed, 2 Nov 2011 23:41:21 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEswgAAFNTA= References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> From: "Luyuan Fang (lufang)" To: "Linda Dunbar" , "Ben Niven-Jenkins" , "L3VPN WG mailing list" X-OriginalArrivalTime: 03 Nov 2011 04:41:24.0082 (UTC) FILETIME=[D74EB520:01CC99E2] 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, 03 Nov 2011 04:41:38 -0000 Linda, Ben suggested that Ning and myself to work with co-authors of other problem statement drafts to come up with a combined view to be presented in Taipei meeting. The requirements drafts would be treated in the similar fashion. I plan to put gap analysis together with pb statement drafts.=20 Though there would be no individual vpn4dc drafts presentations as in normal WG meetings, we welcome input on all three subjects from authors of vpn4dc related drafts, and everyone on the list. In fact, the intent of vpn4dc Q&A I sent a couple of days ago was to gather feedback/input from the list, as the first step of meeting prep.=20 Will get together with the authors of the relevant drafts to discuss soon, prefer we meet when Ning is back to office in a couple of days.=20 Ping me if you cannot wait.=20 Thanks, Luyuan > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Linda Dunbar > Sent: Wednesday, November 02, 2011 10:56 PM > To: Ben Niven-Jenkins; L3VPN WG mailing list > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >=20 > Who will lead the talk for each topic? >=20 > Linda >=20 > > -----Original Message----- > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > Behalf > > Of Ben Niven-Jenkins > > Sent: Wednesday, November 02, 2011 1:01 PM > > To: L3VPN WG mailing list > > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > Colleagues, > > > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda for IETF > > 82 in Taipei. You can find it here: > > > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > > > At the moment the agenda is a little vague because we are still > working > > with the VPN4DC proponents on who will lead each slot. > > > > We have purposely not put time on the agenda to present/discuss > > specific solution drafts as we would like the discussion to be > focussed > > on the problem/requirements posed by VPN4DC and its applicability to > > IETF (including L3VPN). Discussion of specific solution proposals can > > happen at future meetings if the VPN4DC work is adopted. > > > > Ben > > From robert@raszuk.net Thu Nov 3 00:36:09 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 5696C11E80B1 for ; Thu, 3 Nov 2011 00:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, 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 nS0D1s31T-Po for ; Thu, 3 Nov 2011 00:36:08 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 9C82011E809F for ; Thu, 3 Nov 2011 00:36:08 -0700 (PDT) Received: (qmail 5363 invoked by uid 399); 3 Nov 2011 07:36:07 -0000 Received: from unknown (HELO ?216.69.73.171?) (216.69.73.171) by mail37.opentransfer.com with SMTP; 3 Nov 2011 07:36:07 -0000 Message-ID: <4EB24466.6020904@raszuk.net> Date: Thu, 03 Nov 2011 08:36:06 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Pedro Marques Subject: Re: [Sdnp] SDN charter and work items References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sdnp@lucidvision.com, 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: Thu, 03 Nov 2011 07:36:09 -0000 Hi Pedro, > The field of programmable interfaces to network information is new, > and so is the data-center network virtualization area. Without testing > concrete solutions and learning from experience, it is rather unlikely > that there would be no way to resolve between different opinions of > what the abstract architecture should be and should include. The > overall experience in these topics in the whole industry and the IETF > in particular is shallow. + > really means. But i would like to suggest that the way to go about it > is by experimentation. I must say that I very much agree with the above approach ie to get experience in learning what SDN really is by experimentation with sample set of applications of it. > IF-MAP schema for IP VPNs. > draft-marques-sndp-l3vpn-schema-00 Few questions on this one ... - How are you define choice of PE-CE routing protocol used to exchange reachability information ? - How do you envision scale of MAP server ? How about communication between MAP servers especially in case of distributed ones ? - How about discussion of MAP server failure cases ? - How one would go about negotiating with given VPN instance various per VPN security parameters (vrf-route-limit, prefix-limit etc ...) - Do you expect MAP server to be used to manage just single administrative domain leaving any form of inter-as or inter-provider out of scope (manual provisioning) ? > A MAP server implementation SHOULD support access controls on a per > metadata element basis such that it is possible to restrict write > access to a set of metadata elements to a specific list of > certificates. This perhaps leaves a door a bit open to allow customer management of their VPN instance. That is great. However how do you envision possible extranets provisioning when applicable ? Thx, R. From linda.dunbar@huawei.com Thu Nov 3 09:32:18 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 8807611E809D for ; Thu, 3 Nov 2011 09:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.923 X-Spam-Level: X-Spam-Status: No, score=-5.923 tagged_above=-999 required=5 tests=[AWL=-0.525, 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 l6l7McWk-mzE for ; Thu, 3 Nov 2011 09:32:17 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9F18B11E8099 for ; Thu, 3 Nov 2011 09:32:17 -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 <0LU300KLYF81TP@usaga02-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 11:31:14 -0500 (CDT) Received: from dfweml202-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 <0LU30030DF5ZVY@usaga02-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 11:31:11 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 03 Nov 2011 09:30:28 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 03 Nov 2011 09:30:19 -0700 Date: Thu, 03 Nov 2011 16:30:16 +0000 From: Linda Dunbar Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> X-Originating-IP: [10.192.11.155] To: "Luyuan Fang (lufang)" , Ben Niven-Jenkins , L3VPN WG mailing list Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TAPBDzsfDHKoNL11AUV/RQ)" Content-language: en-US Accept-Language: en-US Thread-topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEswgAAFNTCAANe5YA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.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: Thu, 03 Nov 2011 16:32:18 -0000 --Boundary_(ID_TAPBDzsfDHKoNL11AUV/RQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Here is the fundamental question for the goal of VPN4DC: 1. Is VPN4DC to create mechanisms which make it possible to connect hosts in any public data centers (e.g. Amazon' EC2) to hosts' corresponding VPNs? Or 2. Is VPN4DC to create a solution which allows VPN service provider to extend their VPN with computing service? In this model, customers (i.e. VPN clients) see their computing resources being offloaded to their VPN. Customers don't deal with data centers directly. Personally I don't think that we need to waste our time on Model #1 for the following reasons: - VPN service providers may not even have PEs in close proximity to "the public data centers" which clients choose. If a VPN client has leased some computing resource from a data center, the easiest way to connect them securely is by IPSec tunnel. - Today Amazon already allows any hosts to be connected to their chosen sites by IPSec (Amazon's VPC service). Model #2 gives VPN service providers an unique advantage of binding valuable VPN services with virtual computing services, making it more difficult for data centers who don't own network infrastructure to compete. Do people agree? Linda > -----Original Message----- > From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > Sent: Wednesday, November 02, 2011 11:41 PM > To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > Linda, > > Ben suggested that Ning and myself to work with co-authors of other > problem statement drafts to come up with a combined view to be > presented > in Taipei meeting. The requirements drafts would be treated in the > similar fashion. I plan to put gap analysis together with pb statement > drafts. > > Though there would be no individual vpn4dc drafts presentations as in > normal WG meetings, we welcome input on all three subjects from authors > of vpn4dc related drafts, and everyone on the list. > > In fact, the intent of vpn4dc Q&A I sent a couple of days ago was to > gather feedback/input from the list, as the first step of meeting prep. > > Will get together with the authors of the relevant drafts to discuss > soon, prefer we meet when Ning is back to office in a couple of days. > Ping me if you cannot wait. > > Thanks, > Luyuan > > > > -----Original Message----- > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > Behalf > > Of Linda Dunbar > > Sent: Wednesday, November 02, 2011 10:56 PM > > To: Ben Niven-Jenkins; L3VPN WG mailing list > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > Who will lead the talk for each topic? > > > > Linda > > > > > -----Original Message----- > > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > > Behalf > > > Of Ben Niven-Jenkins > > > Sent: Wednesday, November 02, 2011 1:01 PM > > > To: L3VPN WG mailing list > > > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > Colleagues, > > > > > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda for > IETF > > > 82 in Taipei. You can find it here: > > > > > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > > > > > At the moment the agenda is a little vague because we are still > > working > > > with the VPN4DC proponents on who will lead each slot. > > > > > > We have purposely not put time on the agenda to present/discuss > > > specific solution drafts as we would like the discussion to be > > focussed > > > on the problem/requirements posed by VPN4DC and its applicability > to > > > IETF (including L3VPN). Discussion of specific solution proposals > can > > > happen at future meetings if the VPN4DC work is adopted. > > > > > > Ben > > > --Boundary_(ID_TAPBDzsfDHKoNL11AUV/RQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Here is the fundamental question for the goal of VPN4DC:
 
1. Is VPN4DC to create mechanisms which make it possible to connect hosts in any public data centers (e.g. Amazon' EC2) to hosts' corresponding VPNs? Or
 
2. Is VPN4DC to create a solution which allows VPN service provider to extend their VPN with computing service? In this model, customers (i.e. VPN clients) see their computing resources being offloaded to their VPN. Customers don't deal with data centers directly.
 
 
Personally I don't think that we need to waste our time on Model #1 for the following reasons:
  • VPN service providers may not even have PEs in close proximity to "the public data centers" which clients choose. If a VPN client has leased some computing resource from a data center, the easiest way to connect them securely is by IPSec tunnel.
 
  • Today Amazon already allows any hosts to be connected to their chosen sites by IPSec (Amazon's VPC service).
 
Model #2 gives VPN service providers an unique advantage of binding valuable VPN services with virtual computing services, making it more difficult for data centers who don't own network infrastructure to compete.
 
Do people agree?
 
Linda
 
> -----Original Message-----
> From: Luyuan Fang (lufang) [mailto:lufang@cisco.com]
> Sent: Wednesday, November 02, 2011 11:41 PM
> To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list
> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82
>
> Linda,
>
> Ben suggested that Ning and myself to work with co-authors of other
> problem statement drafts to come up with a combined view to be
> presented
> in Taipei meeting. The requirements drafts would be treated in the
> similar fashion. I plan to put gap analysis together with pb statement
> drafts.
>
> Though there would be no individual vpn4dc drafts presentations as in
> normal WG meetings, we welcome input on all three subjects from authors
> of vpn4dc related drafts, and everyone on the list.
>
> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was to
> gather feedback/input from the list, as the first step of meeting prep.
>
> Will get together with the authors of the relevant drafts to discuss
> soon, prefer we meet when Ning is back to office in a couple of days.
> Ping me if you cannot wait.
>
> Thanks,
> Luyuan
>
>
> > -----Original Message-----
> > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On
> Behalf
> > Of Linda Dunbar
> > Sent: Wednesday, November 02, 2011 10:56 PM
> > To: Ben Niven-Jenkins; L3VPN WG mailing list
> > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82
> >
> > Who will lead the talk for each topic?
> >
> > Linda
> >
> > > -----Original Message-----
> > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On
> > Behalf
> > > Of Ben Niven-Jenkins
> > > Sent: Wednesday, November 02, 2011 1:01 PM
> > > To: L3VPN WG mailing list
> > > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82
> > >
> > > Colleagues,
> > >
> > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda for
> IETF
> > > 82 in Taipei. You can find it here:
> > >
> > >
> > > At the moment the agenda is a little vague because we are still
> > working
> > > with the VPN4DC proponents on who will lead each slot.
> > >
> > > We have purposely not put time on the agenda to present/discuss
> > > specific solution drafts as we would like the discussion to be
> > focussed
> > > on the problem/requirements posed by VPN4DC and its applicability
> to
> > > IETF (including L3VPN). Discussion of specific solution proposals
> can
> > > happen at future meetings if the VPN4DC work is adopted.
> > >
> > > Ben
> > >
 
 
 --Boundary_(ID_TAPBDzsfDHKoNL11AUV/RQ)-- From pedro.r.marques@gmail.com Thu Nov 3 09:58: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 B47AF11E8148 for ; Thu, 3 Nov 2011 09:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.861 X-Spam-Level: X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, 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 66pNb5tInaUo for ; Thu, 3 Nov 2011 09:58:37 -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 2673111E80C5 for ; Thu, 3 Nov 2011 09:58:37 -0700 (PDT) Received: by iaeo4 with SMTP id o4so1981177iae.31 for ; Thu, 03 Nov 2011 09:58:36 -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:cc:content-type :content-transfer-encoding; bh=i+Ew9+xLDAUsVh3WnhNTXRYggpMtmdIKZTKvZbh3j4g=; b=o/ug4iTyAFaE7RK9JpiZaqX90UOFDfZILnJjZWBIyQw01zVVgmJnsQi722Sncvfbrn Tr5n39yr1rMdT6asGGs7G8kFhWRNKz5x/oSllvVWS3oBgME+6z/0PgU36iyQ0VmxBVDD eLgp/dpX2kHH1oKkERTNxW08IhsaFp+q3QqF8= MIME-Version: 1.0 Received: by 10.231.63.212 with SMTP id c20mr2160866ibi.52.1320339516481; Thu, 03 Nov 2011 09:58:36 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Thu, 3 Nov 2011 09:58:36 -0700 (PDT) Date: Thu, 3 Nov 2011 09:58:36 -0700 Message-ID: Subject: if-map schema for l3vpn From: Pedro Marques To: robert@raszuk.net 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: Thu, 03 Nov 2011 16:58:37 -0000 Robert, Thank you for your questions. On Thu, Nov 3, 2011 at 12:36 AM, Robert Raszuk wrote: >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IF-MAP schema for IP VPNs. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-marques-sndp-l3vpn-schema-00 > > Few questions on this one ... > > - How are you define choice of PE-CE routing protocol used to exchange > reachability information ? I apologize in advance if i'm not answering the right question. I understanding this question as: in the traditional SP-centric l3vpn application, how does a provisioning system configure parameters such as the PE-CE protocol. The answer to that would be by defining extra elements in the "binding" metadata element. > > - How do you envision scale of MAP server ? How about communication betwe= en > MAP servers especially in case of distributed ones ? For reasons of resiliency and scale MAP servers should be distributed. It is desirable to have the server-to-server protocol(s) be publicly documented. There are multiple possible implementation strategies for a distributed MAP server implementation. It would be reasonable to have more than one publicly documented server-to-server protocol, exporting the same API to clients. > > - How about discussion of MAP server failure cases ? >From a client's perspective the MAP server is assumed to be resilient / persistent. > > - How one would go about negotiating with given VPN instance various per = VPN > security parameters (vrf-route-limit, prefix-limit etc ...) These would be optional elements in the metadata elements. > > - Do you expect MAP server to be used to manage just single administrativ= e > domain leaving any form of inter-as or inter-provider out of scope (manua= l > provisioning) ? inter-as inter-provider is likely to have very different requirements. It would be possible to use a similar approach for communicating operational data (e.g. customer name to route-target mappings) but for requests that modify state the current web based API approach seems to be better suited. > >> =A0 A MAP server implementation SHOULD support access controls on a per >> =A0 metadata element basis such that it is possible to restrict write >> =A0 access to a set of metadata elements to a specific list of >> =A0 certificates. > > This perhaps leaves a door a bit open to allow customer management of the= ir > VPN instance. That is great. However how do you envision possible extrane= ts > provisioning when applicable ? > The focus is on provider provisioned VPNs, specially when it comes to controlling the membership of the VPN. This is not an API that is appropriate for the end-user application to interact with the network. For the later i'd recommend looking at the work of the ALTO working group. Pedro. From pedro.r.marques@gmail.com Thu Nov 3 10:22: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 2F3601F0C85 for ; Thu, 3 Nov 2011 10:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 QYJ1o32xLR-T for ; Thu, 3 Nov 2011 10:22:53 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF211F0C81 for ; Thu, 3 Nov 2011 10:22:53 -0700 (PDT) Received: by qadc10 with SMTP id c10so1710288qad.31 for ; Thu, 03 Nov 2011 10:22:52 -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=7aPgSaUtrWxW2eTCnVp2T8IkrHKREOYI2aLXciZ99RE=; b=dY2CIxhddayJVeKVas8SK6VUtIlVJlleIgeEj+lxTQ2AKI5CZC/9Me6rwOiITLoHjd Vyqb5o4dwfVAwJLES5AXGz+6ThuRJBtXCRf43Hjp75XhZchyF1yyeAdxveuwn9n8wIMW LKLtmOiYhWvVAKzq0BAakhcMDQjm/0ikCRF44= MIME-Version: 1.0 Received: by 10.50.158.227 with SMTP id wx3mr5474344igb.52.1320340972172; Thu, 03 Nov 2011 10:22:52 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Thu, 3 Nov 2011 10:22:52 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> Date: Thu, 3 Nov 2011 10:22:52 -0700 Message-ID: Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 From: Pedro Marques To: Linda Dunbar Content-Type: text/plain; charset=ISO-8859-1 Cc: L3VPN WG mailing list 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, 03 Nov 2011 17:22:54 -0000 It appears to me that you are discussing business models rather than the underlying technology. At least from my view point, when it comes to technology both of your examples are the same: a private enterprise network interconnects with a public data-center. Irrespective of the question of economic ownership, the data center network is different from the WAN network and is managed differently. The issue only becomes relevant to the l3vpn working group if one assumes that there are multiple enterprise VPN networks connecting to a particular datacenter and there is a VPN technology in the datacenter. Otherwise we are talking of a CE attachment circuit and it really don't matter what service sits behind that circuit. regards, Pedro. On Thu, Nov 3, 2011 at 9:30 AM, Linda Dunbar wrote: > Here is the fundamental question for the goal of VPN4DC: > > 1. Is VPN4DC to create mechanisms which make it possible to connect hosts in > any public data centers (e.g. Amazon' EC2) to hosts' corresponding VPNs? Or > > 2. Is VPN4DC to create a solution which allows VPN service provider to > extend their VPN with computing service? In this model, customers (i.e. VPN > clients) see their computing resources being offloaded to their VPN. > Customers don't deal with data centers directly. > > > Personally I don't think that we need to waste our time on Model #1 for the > following reasons: > > VPN service providers may not even have PEs in close proximity to "the > public data centers" which clients choose. If a VPN client has leased some > computing resource from a data center, the easiest way to connect them > securely is by IPSec tunnel. > > > > Today Amazon already allows any hosts to be connected to their chosen sites > by IPSec (Amazon's VPC service). > > > Model #2 gives VPN service providers an unique advantage of binding valuable > VPN services with virtual computing services, making it more difficult for > data centers who don't own network infrastructure to compete. > > Do people agree? > > Linda > >> -----Original Message----- >> From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] >> Sent: Wednesday, November 02, 2011 11:41 PM >> To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list >> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >> >> Linda, >> >> Ben suggested that Ning and myself to work with co-authors of other >> problem statement drafts to come up with a combined view to be >> presented >> in Taipei meeting. The requirements drafts would be treated in the >> similar fashion. I plan to put gap analysis together with pb statement >> drafts. >> >> Though there would be no individual vpn4dc drafts presentations as in >> normal WG meetings, we welcome input on all three subjects from authors >> of vpn4dc related drafts, and everyone on the list. >> >> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was to >> gather feedback/input from the list, as the first step of meeting prep. >> >> Will get together with the authors of the relevant drafts to discuss >> soon, prefer we meet when Ning is back to office in a couple of days. >> Ping me if you cannot wait. >> >> Thanks, >> Luyuan >> >> >> > -----Original Message----- >> > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On >> Behalf >> > Of Linda Dunbar >> > Sent: Wednesday, November 02, 2011 10:56 PM >> > To: Ben Niven-Jenkins; L3VPN WG mailing list >> > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >> > >> > Who will lead the talk for each topic? >> > >> > Linda >> > >> > > -----Original Message----- >> > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On >> > Behalf >> > > Of Ben Niven-Jenkins >> > > Sent: Wednesday, November 02, 2011 1:01 PM >> > > To: L3VPN WG mailing list >> > > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 >> > > >> > > Colleagues, >> > > >> > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda for >> IETF >> > > 82 in Taipei. You can find it here: >> > > >> > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt >> > > >> > > At the moment the agenda is a little vague because we are still >> > working >> > > with the VPN4DC proponents on who will lead each slot. >> > > >> > > We have purposely not put time on the agenda to present/discuss >> > > specific solution drafts as we would like the discussion to be >> > focussed >> > > on the problem/requirements posed by VPN4DC and its applicability >> to >> > > IETF (including L3VPN). Discussion of specific solution proposals >> can >> > > happen at future meetings if the VPN4DC work is adopted. >> > > >> > > Ben >> > > > > From robert@raszuk.net Thu Nov 3 10:42: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 3B1BF1F0CB6 for ; Thu, 3 Nov 2011 10:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[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 AXePctaitTJM for ; Thu, 3 Nov 2011 10:42:54 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 5FE261F0C7C for ; Thu, 3 Nov 2011 10:42:54 -0700 (PDT) Received: (qmail 16330 invoked by uid 399); 3 Nov 2011 17:42:53 -0000 Received: from unknown (HELO ?192.168.1.57?) (83.28.177.170) by mail37.opentransfer.com with SMTP; 3 Nov 2011 17:42:53 -0000 Message-ID: <4EB2D29D.8000701@raszuk.net> Date: Thu, 03 Nov 2011 18:42:53 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Linda Dunbar Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN WG mailing list 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: Thu, 03 Nov 2011 17:42:55 -0000 Linda, > Personally I don't think that we need to waste our time on Model #1 > for the following reasons: Personally I don't think we need to waste our time on solving Model #2 for one main reason - #2 is a subset of #1. If we solve #1 then #2 get's solved automatically. Please note that IPSec access to provider's L3VPNs has been a commercialized and deployed feature years ago. -- I really think that if we have any desire to constructively move forward in this space time spend on finding the flexible and universal auto-discovery tool for customer's network islands (be it VMs alone or L3VPNs sites/set of sides or even specific mobile users) is a prerequisite for any further work. Then we could worry about what tool to use to interconnect those islands. Even if those islands (more and more dynamic in nature) would all belong under one SP .. such SP would also largely benefit from ability to auto-discovery in real time needs to join or leave a VPN. Then the toolkit of choice could be triggered to add/delete a site, a user or a VM to/from given VPN via the orchestration system of his choice. To the best of my knowledge such dynamic VPN discovery tool has not been invented yet. Best rgds, R. > Here is the fundamental question for the goal of VPN4DC: > > 1. Is VPN4DC to create mechanisms which make it possible to connect > hosts in any public data centers (e.g. Amazon' EC2) to hosts' > corresponding VPNs? Or > > 2. Is VPN4DC to create a solution which allows VPN service provider > to extend their VPN with computing service? In this model, customers > (i.e. VPN clients) see their computing resources being offloaded to > their VPN. Customers don't deal with data centers directly. > > > Personally I don't think that we need to waste our time on Model #1 > for the following reasons: - VPN service providers may not even > have PEs in close proximity to "the public data centers" which > clients choose. If a VPN client has leased some computing resource > from a data center, the easiest way to connect them securely is by > IPSec tunnel. > > - Today Amazon already allows any hosts to be connected to > their chosen sites by IPSec (Amazon's VPC service). > > Model #2 gives VPN service providers an unique advantage of binding > valuable VPN services with virtual computing services, making it > more difficult for data centers who don't own network infrastructure > to compete. > > Do people agree? > > Linda > >> -----Original Message----- From: Luyuan Fang (lufang) >> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41 >> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list >> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >> >> Linda, >> >> Ben suggested that Ning and myself to work with co-authors of >> other problem statement drafts to come up with a combined view to >> be presented in Taipei meeting. The requirements drafts would be >> treated in the similar fashion. I plan to put gap analysis together >> with pb statement drafts. >> >> Though there would be no individual vpn4dc drafts presentations as >> in normal WG meetings, we welcome input on all three subjects from >> authors of vpn4dc related drafts, and everyone on the list. >> >> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was >> to gather feedback/input from the list, as the first step of >> meeting prep. >> >> Will get together with the authors of the relevant drafts to >> discuss soon, prefer we meet when Ning is back to office in a >> couple of days. Ping me if you cannot wait. >> >> Thanks, Luyuan >> >> >>> -----Original Message----- From: l3vpn-bounces@ietf.org >>> [mailto:l3vpn-bounces@ietf.org] On >> Behalf >>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To: >>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary >>> L3VPN/VPN4DC agenda @ IETF82 >>> >>> Who will lead the talk for each topic? >>> >>> Linda >>> >>>> -----Original Message----- From: l3vpn-bounces@ietf.org >>>> [mailto:l3vpn-bounces@ietf.org] On >>> Behalf >>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 >>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC >>>> agenda @ IETF82 >>>> >>>> Colleagues, >>>> >>>> Marshall& I have uploaded a preliminary L3VPN/VPN4DC agenda >>>> for >> IETF >>>> 82 in Taipei. You can find it here: >>>> >>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt >>>> >>>> At the moment the agenda is a little vague because we are >>>> still >>> working >>>> with the VPN4DC proponents on who will lead each slot. >>>> >>>> We have purposely not put time on the agenda to >>>> present/discuss specific solution drafts as we would like the >>>> discussion to be >>> focussed >>>> on the problem/requirements posed by VPN4DC and its >>>> applicability >> to >>>> IETF (including L3VPN). Discussion of specific solution >>>> proposals >> can >>>> happen at future meetings if the VPN4DC work is adopted. >>>> >>>> Ben >>>> > > > From linda.dunbar@huawei.com Thu Nov 3 12:18: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 363211F0CC2 for ; Thu, 3 Nov 2011 12:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.592 X-Spam-Level: X-Spam-Status: No, score=-5.592 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_00=-2.599, 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 P7t+Fn2AIw4i for ; Thu, 3 Nov 2011 12:18:03 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 466E31F0CAF for ; Thu, 3 Nov 2011 12:18:03 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU300HZIMXVIZ@usaga04-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 14:17:55 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU300MQ2MXTKC@usaga04-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 14:17:55 -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; Thu, 03 Nov 2011 12:17:47 -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; Thu, 03 Nov 2011 12:17:44 -0700 Date: Thu, 03 Nov 2011 19:17:40 +0000 From: Linda Dunbar Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: <4EB2D29D.8000701@raszuk.net> X-Originating-IP: [10.192.11.155] To: "robert@raszuk.net" Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120B20AE@dfweml505-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEswgAAFNTCAANe5YIAAkROA//+fD5A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4EB2D29D.8000701@raszuk.net> Cc: L3VPN WG mailing list 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, 03 Nov 2011 19:18:04 -0000 Robert, You are absolutely correct that "IPSec has been used for many years to interconnect hosts to L3VPN". That is why we don't need to invest energy on Model #1. I also agree with you that it will be very useful to find the flexible and universal auto-discovery tool for customer's network islands". I interpret it as defining a mechanism for VPN PEs to "discover" customer's network segments (i.e. subnets) from their adjacent networks (e.g. data center network). Linda > -----Original Message----- > From: Robert Raszuk [mailto:robert@raszuk.net] > Sent: Thursday, November 03, 2011 12:43 PM > To: Linda Dunbar > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing list > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > Linda, > > > Personally I don't think that we need to waste our time on Model #1 > > for the following reasons: > > Personally I don't think we need to waste our time on solving Model #2 > for one main reason - #2 is a subset of #1. If we solve #1 then #2 > get's > solved automatically. > > Please note that IPSec access to provider's L3VPNs has been a > commercialized and deployed feature years ago. > > -- > > I really think that if we have any desire to constructively move > forward > in this space time spend on finding the flexible and universal > auto-discovery tool for customer's network islands (be it VMs alone or > L3VPNs sites/set of sides or even specific mobile users) is a > prerequisite for any further work. > > Then we could worry about what tool to use to interconnect those > islands. > > Even if those islands (more and more dynamic in nature) would all > belong > under one SP .. such SP would also largely benefit from ability to > auto-discovery in real time needs to join or leave a VPN. Then the > toolkit of choice could be triggered to add/delete a site, a user or a > VM to/from given VPN via the orchestration system of his choice. > > To the best of my knowledge such dynamic VPN discovery tool has not > been > invented yet. > > Best rgds, > R. > > > > > Here is the fundamental question for the goal of VPN4DC: > > > > 1. Is VPN4DC to create mechanisms which make it possible to connect > > hosts in any public data centers (e.g. Amazon' EC2) to hosts' > > corresponding VPNs? Or > > > > 2. Is VPN4DC to create a solution which allows VPN service provider > > to extend their VPN with computing service? In this model, customers > > (i.e. VPN clients) see their computing resources being offloaded to > > their VPN. Customers don't deal with data centers directly. > > > > > > Personally I don't think that we need to waste our time on Model #1 > > for the following reasons: - VPN service providers may not even > > have PEs in close proximity to "the public data centers" which > > clients choose. If a VPN client has leased some computing resource > > from a data center, the easiest way to connect them securely is by > > IPSec tunnel. > > > > - Today Amazon already allows any hosts to be connected to > > their chosen sites by IPSec (Amazon's VPC service). > > > > Model #2 gives VPN service providers an unique advantage of binding > > valuable VPN services with virtual computing services, making it > > more difficult for data centers who don't own network infrastructure > > to compete. > > > > Do people agree? > > > > Linda > > > >> -----Original Message----- From: Luyuan Fang (lufang) > >> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41 > >> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > >> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > >> > >> Linda, > >> > >> Ben suggested that Ning and myself to work with co-authors of > >> other problem statement drafts to come up with a combined view to > >> be presented in Taipei meeting. The requirements drafts would be > >> treated in the similar fashion. I plan to put gap analysis together > >> with pb statement drafts. > >> > >> Though there would be no individual vpn4dc drafts presentations as > >> in normal WG meetings, we welcome input on all three subjects from > >> authors of vpn4dc related drafts, and everyone on the list. > >> > >> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was > >> to gather feedback/input from the list, as the first step of > >> meeting prep. > >> > >> Will get together with the authors of the relevant drafts to > >> discuss soon, prefer we meet when Ning is back to office in a > >> couple of days. Ping me if you cannot wait. > >> > >> Thanks, Luyuan > >> > >> > >>> -----Original Message----- From: l3vpn-bounces@ietf.org > >>> [mailto:l3vpn-bounces@ietf.org] On > >> Behalf > >>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To: > >>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary > >>> L3VPN/VPN4DC agenda @ IETF82 > >>> > >>> Who will lead the talk for each topic? > >>> > >>> Linda > >>> > >>>> -----Original Message----- From: l3vpn-bounces@ietf.org > >>>> [mailto:l3vpn-bounces@ietf.org] On > >>> Behalf > >>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 > >>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC > >>>> agenda @ IETF82 > >>>> > >>>> Colleagues, > >>>> > >>>> Marshall& I have uploaded a preliminary L3VPN/VPN4DC agenda > >>>> for > >> IETF > >>>> 82 in Taipei. You can find it here: > >>>> > >>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > >>>> > >>>> At the moment the agenda is a little vague because we are > >>>> still > >>> working > >>>> with the VPN4DC proponents on who will lead each slot. > >>>> > >>>> We have purposely not put time on the agenda to > >>>> present/discuss specific solution drafts as we would like the > >>>> discussion to be > >>> focussed > >>>> on the problem/requirements posed by VPN4DC and its > >>>> applicability > >> to > >>>> IETF (including L3VPN). Discussion of specific solution > >>>> proposals > >> can > >>>> happen at future meetings if the VPN4DC work is adopted. > >>>> > >>>> Ben > >>>> > > > > > > From linda.dunbar@huawei.com Thu Nov 3 12:19: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 4990C1F0CAF for ; Thu, 3 Nov 2011 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=-0.440, 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 r5jyx30weLcN for ; Thu, 3 Nov 2011 12:19:47 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9D61F0CAB for ; Thu, 3 Nov 2011 12:19:47 -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 <0LU300FA3MCO5G@usaga02-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 14:05:28 -0500 (CDT) Received: from dfweml202-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 <0LU3000N1MCOCM@usaga02-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 14:05:12 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 03 Nov 2011 12:05:13 -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; Thu, 03 Nov 2011 12:05:01 -0700 Date: Thu, 03 Nov 2011 19:04:58 +0000 From: Linda Dunbar Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: X-Originating-IP: [10.192.11.155] To: Pedro Marques Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEswgAAFNTCAANe5YIAAi3sA//+kw6A= X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Agn/ CXY2 DVat HTmi IEK8 Mo0l NVZd Rg5N SyWG Tj4n WwxS eFn6 eYcu fdaE izrH nU1P; 4; YgBlAG4AQABuAGkAdgBlAG4ALQBqAGUAbgBrAGkAbgBzAC4AYwBvAC4AdQBrADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA7AHAAZQBkAHIAbwAuAHIALgBtAGEAcgBxAHUAZQBzAEAAZwBtAGEAaQBsAC4AYwBvAG0A; Sosha1_v1; 7; {2AA1F882-D976-4ADB-84D7-C5E5B27CEFAB}; bABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 03 Nov 2011 19:04:53 GMT; UgBFADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== x-cr-puzzleid: {2AA1F882-D976-4ADB-84D7-C5E5B27CEFAB} References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> Cc: L3VPN WG mailing list 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, 03 Nov 2011 19:19:48 -0000 I am only trying to get the boundary of this VPN4DC to make the discussion more focused. As for "talking about CE attachment circuit" or "interconnecting hosts in a data center whose network is L3VPN based", I think we should invest energy in the first. I've seen many data centers with Layer 2 or Layer 3 interconnecting servers among all the server racks. Does anyone know of any data centers which use L3VPN to interconnect servers within a data center? Linda > -----Original Message----- > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > Sent: Thursday, November 03, 2011 12:23 PM > To: Linda Dunbar > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing list > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > It appears to me that you are discussing business models rather than > the underlying technology. At least from my view point, when it comes > to technology both of your examples are the same: a private enterprise > network interconnects with a public data-center. Irrespective of the > question of economic ownership, the data center network is different > from the WAN network and is managed differently. > > The issue only becomes relevant to the l3vpn working group if one > assumes that there are multiple enterprise VPN networks connecting to > a particular datacenter and there is a VPN technology in the > datacenter. Otherwise we are talking of a CE attachment circuit and it > really don't matter what service sits behind that circuit. > > regards, > Pedro. > > On Thu, Nov 3, 2011 at 9:30 AM, Linda Dunbar > wrote: > > Here is the fundamental question for the goal of VPN4DC: > > > > 1. Is VPN4DC to create mechanisms which make it possible to connect > hosts in > > any public data centers (e.g. Amazon' EC2) to hosts' corresponding > VPNs? Or > > > > 2. Is VPN4DC to create a solution which allows VPN service provider > to > > extend their VPN with computing service? In this model, customers > (i.e. VPN > > clients) see their computing resources being offloaded to their VPN. > > Customers don't deal with data centers directly. > > > > > > Personally I don't think that we need to waste our time on Model #1 > for the > > following reasons: > > > > VPN service providers may not even have PEs in close proximity to > "the > > public data centers" which clients choose. If a VPN client has leased > some > > computing resource from a data center, the easiest way to connect > them > > securely is by IPSec tunnel. > > > > > > > > Today Amazon already allows any hosts to be connected to their chosen > sites > > by IPSec (Amazon's VPC service). > > > > > > Model #2 gives VPN service providers an unique advantage of binding > valuable > > VPN services with virtual computing services, making it more > difficult for > > data centers who don't own network infrastructure to compete. > > > > Do people agree? > > > > Linda > > > >> -----Original Message----- > >> From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > >> Sent: Wednesday, November 02, 2011 11:41 PM > >> To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > >> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > >> > >> Linda, > >> > >> Ben suggested that Ning and myself to work with co-authors of other > >> problem statement drafts to come up with a combined view to be > >> presented > >> in Taipei meeting. The requirements drafts would be treated in the > >> similar fashion. I plan to put gap analysis together with pb > statement > >> drafts. > >> > >> Though there would be no individual vpn4dc drafts presentations as > in > >> normal WG meetings, we welcome input on all three subjects from > authors > >> of vpn4dc related drafts, and everyone on the list. > >> > >> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was to > >> gather feedback/input from the list, as the first step of meeting > prep. > >> > >> Will get together with the authors of the relevant drafts to discuss > >> soon, prefer we meet when Ning is back to office in a couple of days. > >> Ping me if you cannot wait. > >> > >> Thanks, > >> Luyuan > >> > >> > >> > -----Original Message----- > >> > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > >> Behalf > >> > Of Linda Dunbar > >> > Sent: Wednesday, November 02, 2011 10:56 PM > >> > To: Ben Niven-Jenkins; L3VPN WG mailing list > >> > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > >> > > >> > Who will lead the talk for each topic? > >> > > >> > Linda > >> > > >> > > -----Original Message----- > >> > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > >> > Behalf > >> > > Of Ben Niven-Jenkins > >> > > Sent: Wednesday, November 02, 2011 1:01 PM > >> > > To: L3VPN WG mailing list > >> > > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 > >> > > > >> > > Colleagues, > >> > > > >> > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda for > >> IETF > >> > > 82 in Taipei. You can find it here: > >> > > > >> > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > >> > > > >> > > At the moment the agenda is a little vague because we are still > >> > working > >> > > with the VPN4DC proponents on who will lead each slot. > >> > > > >> > > We have purposely not put time on the agenda to present/discuss > >> > > specific solution drafts as we would like the discussion to be > >> > focussed > >> > > on the problem/requirements posed by VPN4DC and its > applicability > >> to > >> > > IETF (including L3VPN). Discussion of specific solution > proposals > >> can > >> > > happen at future meetings if the VPN4DC work is adopted. > >> > > > >> > > Ben > >> > > > > > > From robert@raszuk.net Thu Nov 3 12:22: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 37DC41F0CB6 for ; Thu, 3 Nov 2011 12:22:21 -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.900, 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 h-747uBZkj4l for ; Thu, 3 Nov 2011 12:22:20 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 698AA1F0CAF for ; Thu, 3 Nov 2011 12:22:20 -0700 (PDT) Received: (qmail 30561 invoked by uid 399); 3 Nov 2011 19:22:17 -0000 Received: from unknown (HELO ?192.168.1.57?) (83.28.177.170) by mail37.opentransfer.com with SMTP; 3 Nov 2011 19:22:17 -0000 Message-ID: <4EB2E9E9.7010705@raszuk.net> Date: Thu, 03 Nov 2011 20:22:17 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Linda Dunbar Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4EB2D29D.8000701@raszuk.net> <4A95BA014132FF49AE685FAB4B9F17F6120B20AE@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120B20AE@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN WG mailing list 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: Thu, 03 Nov 2011 19:22:21 -0000 > islands". I interpret it as defining a mechanism for VPN PEs to > "discover" customer's network segments (i.e. subnets) from their > adjacent networks (e.g. data center network). And I interpret it mainly as getting rid of PEs all together. Best regards, R. > Robert, > > You are absolutely correct that "IPSec has been used for many years > to interconnect hosts to L3VPN". That is why we don't need to invest > energy on Model #1. > > I also agree with you that it will be very useful to find the > flexible and universal auto-discovery tool for customer's network > islands". I interpret it as defining a mechanism for VPN PEs to > "discover" customer's network segments (i.e. subnets) from their > adjacent networks (e.g. data center network). > > Linda From lufang@cisco.com Thu Nov 3 12:25: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 03DA71F0CAD for ; Thu, 3 Nov 2011 12:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.639 X-Spam-Level: X-Spam-Status: No, score=-4.639 tagged_above=-999 required=5 tests=[AWL=0.760, 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 g2e12m+C3DAr for ; Thu, 3 Nov 2011 12:25:47 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 10BCC1F0CAB for ; Thu, 3 Nov 2011 12:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=6628; q=dns/txt; s=iport; t=1320348347; x=1321557947; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Uv7M+m7X0laKDlyL4ZLCqQfeZHt74+qlVHfFqZgYgFw=; b=BTObKxEycDS1UUhaKsO6GZe+0gJMZpCG4Zhyq6cn7/A8gAZLXr46sVmX wMqkNqZJ3nwEitCN90OaNImIFKTSdSDz1jdKFJaIFqFMtSQCbjVdFbTcQ NrFV3305sM+BQrf8zlu53brDizcby3x4j5aJIYXBPPiUXE9ITbKqg0iWh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAG7qsk6rRDoI/2dsb2JhbABEmgeOW4EhgQWBcgEBAQQSAR0KNAsMBAIBCBEEAQEBCgYXAQYBICUJCAIEARIIARIHh2iWBgGedIg9YgSICJFKhQGHSA X-IronPort-AV: E=Sophos;i="4.69,451,1315180800"; d="scan'208";a="12177687" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 03 Nov 2011 19:25:47 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA3JPk2s012289; Thu, 3 Nov 2011 19:25:46 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); Thu, 3 Nov 2011 14:25:46 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AxrC EzV0 FbhI K0z6 M8Rz NL9X Oq5j PPuD QBGY QHUw S5oL V5f5 WYpN XBHZ fDHH mHNh; 4; YgBlAG4AQABuAGkAdgBlAG4ALQBqAGUAbgBrAGkAbgBzAC4AYwBvAC4AdQBrADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtADsAcABlAGQAcgBvAC4AcgAuAG0AYQByAHEAdQBlAHMAQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {D76F3D14-B712-406A-B37A-A4ABEABF6CCF}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Thu, 03 Nov 2011 19:25:17 GMT; UgBFADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {D76F3D14-B712-406A-B37A-A4ABEABF6CCF} Content-class: urn:content-classes:message Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 Date: Thu, 3 Nov 2011 14:25:17 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CA5DC@XMB-RCD-201.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEswgAAFNTCAANe5YIAAi3sA//+kw6CAAAcCIA== References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> From: "Luyuan Fang (lufang)" To: "Linda Dunbar" , "Pedro Marques" X-OriginalArrivalTime: 03 Nov 2011 19:25:46.0399 (UTC) FILETIME=[62E9BAF0:01CC9A5E] Cc: L3VPN WG mailing list 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, 03 Nov 2011 19:25:48 -0000 Your definition of L3VPN here? - BGP/MPLS VPN (RFC 4364)? - The current L3VPN WG scope? - any ip (layer 3) VPN technologies? Luyuan > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Thursday, November 03, 2011 3:05 PM > To: Pedro Marques > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing list > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >=20 > I am only trying to get the boundary of this VPN4DC to make the > discussion more focused. >=20 > As for "talking about CE attachment circuit" or "interconnecting hosts > in a data center whose network is L3VPN based", I think we should > invest energy in the first. >=20 > I've seen many data centers with Layer 2 or Layer 3 interconnecting > servers among all the server racks. > Does anyone know of any data centers which use L3VPN to interconnect > servers within a data center? >=20 > Linda >=20 > > -----Original Message----- > > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > > Sent: Thursday, November 03, 2011 12:23 PM > > To: Linda Dunbar > > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing list > > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > It appears to me that you are discussing business models rather than > > the underlying technology. At least from my view point, when it comes > > to technology both of your examples are the same: a private > enterprise > > network interconnects with a public data-center. Irrespective of the > > question of economic ownership, the data center network is different > > from the WAN network and is managed differently. > > > > The issue only becomes relevant to the l3vpn working group if one > > assumes that there are multiple enterprise VPN networks connecting to > > a particular datacenter and there is a VPN technology in the > > datacenter. Otherwise we are talking of a CE attachment circuit and > it > > really don't matter what service sits behind that circuit. > > > > regards, > > Pedro. > > > > On Thu, Nov 3, 2011 at 9:30 AM, Linda Dunbar > > > wrote: > > > Here is the fundamental question for the goal of VPN4DC: > > > > > > 1. Is VPN4DC to create mechanisms which make it possible to connect > > hosts in > > > any public data centers (e.g. Amazon' EC2) to hosts' corresponding > > VPNs? Or > > > > > > 2. Is VPN4DC to create a solution which allows VPN service provider > > to > > > extend their VPN with computing service? In this model, customers > > (i.e. VPN > > > clients) see their computing resources being offloaded to their > VPN. > > > Customers don't deal with data centers directly. > > > > > > > > > Personally I don't think that we need to waste our time on Model #1 > > for the > > > following reasons: > > > > > > VPN service providers may not even have PEs in close proximity to > > "the > > > public data centers" which clients choose. If a VPN client has > leased > > some > > > computing resource from a data center, the easiest way to connect > > them > > > securely is by IPSec tunnel. > > > > > > > > > > > > Today Amazon already allows any hosts to be connected to their > chosen > > sites > > > by IPSec (Amazon's VPC service). > > > > > > > > > Model #2 gives VPN service providers an unique advantage of binding > > valuable > > > VPN services with virtual computing services, making it more > > difficult for > > > data centers who don't own network infrastructure to compete. > > > > > > Do people agree? > > > > > > Linda > > > > > >> -----Original Message----- > > >> From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > > >> Sent: Wednesday, November 02, 2011 11:41 PM > > >> To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > > >> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > >> > > >> Linda, > > >> > > >> Ben suggested that Ning and myself to work with co-authors of > other > > >> problem statement drafts to come up with a combined view to be > > >> presented > > >> in Taipei meeting. The requirements drafts would be treated in the > > >> similar fashion. I plan to put gap analysis together with pb > > statement > > >> drafts. > > >> > > >> Though there would be no individual vpn4dc drafts presentations as > > in > > >> normal WG meetings, we welcome input on all three subjects from > > authors > > >> of vpn4dc related drafts, and everyone on the list. > > >> > > >> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was > to > > >> gather feedback/input from the list, as the first step of meeting > > prep. > > >> > > >> Will get together with the authors of the relevant drafts to > discuss > > >> soon, prefer we meet when Ning is back to office in a couple of > days. > > >> Ping me if you cannot wait. > > >> > > >> Thanks, > > >> Luyuan > > >> > > >> > > >> > -----Original Message----- > > >> > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > > >> Behalf > > >> > Of Linda Dunbar > > >> > Sent: Wednesday, November 02, 2011 10:56 PM > > >> > To: Ben Niven-Jenkins; L3VPN WG mailing list > > >> > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > >> > > > >> > Who will lead the talk for each topic? > > >> > > > >> > Linda > > >> > > > >> > > -----Original Message----- > > >> > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] > On > > >> > Behalf > > >> > > Of Ben Niven-Jenkins > > >> > > Sent: Wednesday, November 02, 2011 1:01 PM > > >> > > To: L3VPN WG mailing list > > >> > > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > >> > > > > >> > > Colleagues, > > >> > > > > >> > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda > for > > >> IETF > > >> > > 82 in Taipei. You can find it here: > > >> > > > > >> > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > >> > > > > >> > > At the moment the agenda is a little vague because we are > still > > >> > working > > >> > > with the VPN4DC proponents on who will lead each slot. > > >> > > > > >> > > We have purposely not put time on the agenda to > present/discuss > > >> > > specific solution drafts as we would like the discussion to be > > >> > focussed > > >> > > on the problem/requirements posed by VPN4DC and its > > applicability > > >> to > > >> > > IETF (including L3VPN). Discussion of specific solution > > proposals > > >> can > > >> > > happen at future meetings if the VPN4DC work is adopted. > > >> > > > > >> > > Ben > > >> > > > > > > > > From pedro.r.marques@gmail.com Thu Nov 3 13:13: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 B9A1821F8D24 for ; Thu, 3 Nov 2011 13:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 7PlLiCMf9bd5 for ; Thu, 3 Nov 2011 13:13:01 -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 35AA121F8D23 for ; Thu, 3 Nov 2011 13:13:01 -0700 (PDT) Received: by qyl16 with SMTP id 16so133717qyl.10 for ; Thu, 03 Nov 2011 13:13:00 -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=lQofboEzkx/l1ZhJP0wEljEyj93qhxHBklQ7wGy83uo=; b=fbCe2sUGimakkIq1P72XHfrZMqHH3oPc4LkQp1LGuMQhmNaCg5hB9x8YvvvdGnGjRr t9wb/tTJ/ztaComp8M31qxQNFXuaGNcq3fNUyiwTUes8C2pFO6lKuu18wssBPsTE5E4Z ThQuhbccVJa1pRp4W214t3N+80YjrKOjZ5yko= MIME-Version: 1.0 Received: by 10.50.104.137 with SMTP id ge9mr6454905igb.38.1320351180543; Thu, 03 Nov 2011 13:13:00 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Thu, 3 Nov 2011 13:13:00 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> Date: Thu, 3 Nov 2011 13:13:00 -0700 Message-ID: Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 From: Pedro Marques To: Linda Dunbar Content-Type: text/plain; charset=ISO-8859-1 Cc: L3VPN WG mailing list 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, 03 Nov 2011 20:13:01 -0000 Linda, On Thu, Nov 3, 2011 at 12:04 PM, Linda Dunbar wrote: > I am only trying to get the boundary of this VPN4DC to make the discussion more focused. > > As for "talking about CE attachment circuit" or "interconnecting hosts in a data center whose network is L3VPN based", I think we should invest energy in the first. It seems to me that you are making the case that there is no problem to be solved. Clearly with existing technology one can interconnect an enterprise VPN with a data-center. In today's use case enterprise branch offices are essentially exchanging traffic with private enterprise data-centers. And clearly a CE interface can be itself a tunnel, IPSec or otherwise. > > I've seen many data centers with Layer 2 or Layer 3 interconnecting servers among all the server racks. > Does anyone know of any data centers which use L3VPN to interconnect servers within a data center? > Public data-centers do use VPNs for the compute resources associated with a specific user. Some use VLANs as a VPN technology, others use L3 based solutions, using proprietary control planes. It is not clear whether those that use L3 based solutions are sold on the benefits of using standards based signaling protocols. As carriers try to enter this space, it is possible that they will be more interested in interoperability and in openly documented protocols than what has happened so far. There is a second reason why the data-center network topology is virtualized which is the need to support VM moves. This implies that the IP addresses used for communication between applications may be anywhere across the data-center. Using a virtual topology is an attractive way to solve this problem. Lots of people are trying to solve this problem with data-center wide VLANs. Using data-center wide broadcast domains on top of IP multicast and data-driven learning. I personally believe that using BGP-based signaling is a more cost effective and scalable approach to solve this problem. It is at least the only technology that has proven to scale to the number of routes that are needed in such an application. Pedro. From linda.dunbar@huawei.com Thu Nov 3 13:30: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 7587811E80DA for ; Thu, 3 Nov 2011 13:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=-0.423, 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 6+JnWdjGbKnc for ; Thu, 3 Nov 2011 13:30:42 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 753D911E80AE for ; Thu, 3 Nov 2011 13:30:42 -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 <0LU300FLTQ7J5G@usaga02-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 15:28:32 -0500 (CDT) Received: from dfweml202-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 <0LU300MDVQ7JBI@usaga02-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 15:28:31 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 03 Nov 2011 13:28: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; Thu, 03 Nov 2011 13:28:22 -0700 Date: Thu, 03 Nov 2011 20:28:18 +0000 From: Linda Dunbar Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: <238542D917511A45B6B8AA806E875E25073CA5DC@XMB-RCD-201.cisco.com> X-Originating-IP: [10.192.11.155] To: "Luyuan Fang (lufang)" , Pedro Marques Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120B21DF@dfweml505-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEswgAAFNTCAANe5YIAAi3sA//+kw6CAAAcCIIAAEieQ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BQ6i BgHu JLE/ Jghs PJR9 Q6Ty Rm+K U4mg WD+e YM6R fPss jLwp lN1o n+XV vcg+ xhK8; 4; YgBlAG4AQABuAGkAdgBlAG4ALQBqAGUAbgBrAGkAbgBzAC4AYwBvAC4AdQBrADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA7AHAAZQBkAHIAbwAuAHIALgBtAGEAcgBxAHUAZQBzAEAAZwBtAGEAaQBsAC4AYwBvAG0A; Sosha1_v1; 7; {F744F83A-5BD0-4740-BFB8-B254B12E6890}; bABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 03 Nov 2011 20:28:11 GMT; UgBFADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== x-cr-puzzleid: {F744F83A-5BD0-4740-BFB8-B254B12E6890} References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA5DC@XMB-RCD-201.cisco.com> Cc: L3VPN WG mailing list 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, 03 Nov 2011 20:30:43 -0000 I mean RFC4364 based L3VPN. For VLAN based VPN, I would categorize it to L2 based solution. Linda > -----Original Message----- > From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > Sent: Thursday, November 03, 2011 2:25 PM > To: Linda Dunbar; Pedro Marques > Cc: Ben Niven-Jenkins; L3VPN WG mailing list > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > Your definition of L3VPN here? > > - BGP/MPLS VPN (RFC 4364)? > - The current L3VPN WG scope? > - any ip (layer 3) VPN technologies? > > Luyuan > > > -----Original Message----- > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > Sent: Thursday, November 03, 2011 3:05 PM > > To: Pedro Marques > > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing list > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > I am only trying to get the boundary of this VPN4DC to make the > > discussion more focused. > > > > As for "talking about CE attachment circuit" or "interconnecting > hosts > > in a data center whose network is L3VPN based", I think we should > > invest energy in the first. > > > > I've seen many data centers with Layer 2 or Layer 3 interconnecting > > servers among all the server racks. > > Does anyone know of any data centers which use L3VPN to interconnect > > servers within a data center? > > > > Linda > > > > > -----Original Message----- > > > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > > > Sent: Thursday, November 03, 2011 12:23 PM > > > To: Linda Dunbar > > > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing list > > > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > It appears to me that you are discussing business models rather > than > > > the underlying technology. At least from my view point, when it > comes > > > to technology both of your examples are the same: a private > > enterprise > > > network interconnects with a public data-center. Irrespective of > the > > > question of economic ownership, the data center network is > different > > > from the WAN network and is managed differently. > > > > > > The issue only becomes relevant to the l3vpn working group if one > > > assumes that there are multiple enterprise VPN networks connecting > to > > > a particular datacenter and there is a VPN technology in the > > > datacenter. Otherwise we are talking of a CE attachment circuit and > > it > > > really don't matter what service sits behind that circuit. > > > > > > regards, > > > Pedro. > > > > > > On Thu, Nov 3, 2011 at 9:30 AM, Linda Dunbar > > > > > wrote: > > > > Here is the fundamental question for the goal of VPN4DC: > > > > > > > > 1. Is VPN4DC to create mechanisms which make it possible to > connect > > > hosts in > > > > any public data centers (e.g. Amazon' EC2) to hosts' > corresponding > > > VPNs? Or > > > > > > > > 2. Is VPN4DC to create a solution which allows VPN service > provider > > > to > > > > extend their VPN with computing service? In this model, customers > > > (i.e. VPN > > > > clients) see their computing resources being offloaded to their > > VPN. > > > > Customers don't deal with data centers directly. > > > > > > > > > > > > Personally I don't think that we need to waste our time on Model > #1 > > > for the > > > > following reasons: > > > > > > > > VPN service providers may not even have PEs in close proximity to > > > "the > > > > public data centers" which clients choose. If a VPN client has > > leased > > > some > > > > computing resource from a data center, the easiest way to connect > > > them > > > > securely is by IPSec tunnel. > > > > > > > > > > > > > > > > Today Amazon already allows any hosts to be connected to their > > chosen > > > sites > > > > by IPSec (Amazon's VPC service). > > > > > > > > > > > > Model #2 gives VPN service providers an unique advantage of > binding > > > valuable > > > > VPN services with virtual computing services, making it more > > > difficult for > > > > data centers who don't own network infrastructure to compete. > > > > > > > > Do people agree? > > > > > > > > Linda > > > > > > > >> -----Original Message----- > > > >> From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > > > >> Sent: Wednesday, November 02, 2011 11:41 PM > > > >> To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > > > >> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > >> > > > >> Linda, > > > >> > > > >> Ben suggested that Ning and myself to work with co-authors of > > other > > > >> problem statement drafts to come up with a combined view to be > > > >> presented > > > >> in Taipei meeting. The requirements drafts would be treated in > the > > > >> similar fashion. I plan to put gap analysis together with pb > > > statement > > > >> drafts. > > > >> > > > >> Though there would be no individual vpn4dc drafts presentations > as > > > in > > > >> normal WG meetings, we welcome input on all three subjects from > > > authors > > > >> of vpn4dc related drafts, and everyone on the list. > > > >> > > > >> In fact, the intent of vpn4dc Q&A I sent a couple of days ago > was > > to > > > >> gather feedback/input from the list, as the first step of > meeting > > > prep. > > > >> > > > >> Will get together with the authors of the relevant drafts to > > discuss > > > >> soon, prefer we meet when Ning is back to office in a couple of > > days. > > > >> Ping me if you cannot wait. > > > >> > > > >> Thanks, > > > >> Luyuan > > > >> > > > >> > > > >> > -----Original Message----- > > > >> > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] > On > > > >> Behalf > > > >> > Of Linda Dunbar > > > >> > Sent: Wednesday, November 02, 2011 10:56 PM > > > >> > To: Ben Niven-Jenkins; L3VPN WG mailing list > > > >> > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > >> > > > > >> > Who will lead the talk for each topic? > > > >> > > > > >> > Linda > > > >> > > > > >> > > -----Original Message----- > > > >> > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] > > On > > > >> > Behalf > > > >> > > Of Ben Niven-Jenkins > > > >> > > Sent: Wednesday, November 02, 2011 1:01 PM > > > >> > > To: L3VPN WG mailing list > > > >> > > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > >> > > > > > >> > > Colleagues, > > > >> > > > > > >> > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda > > for > > > >> IETF > > > >> > > 82 in Taipei. You can find it here: > > > >> > > > > > >> > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > > >> > > > > > >> > > At the moment the agenda is a little vague because we are > > still > > > >> > working > > > >> > > with the VPN4DC proponents on who will lead each slot. > > > >> > > > > > >> > > We have purposely not put time on the agenda to > > present/discuss > > > >> > > specific solution drafts as we would like the discussion to > be > > > >> > focussed > > > >> > > on the problem/requirements posed by VPN4DC and its > > > applicability > > > >> to > > > >> > > IETF (including L3VPN). Discussion of specific solution > > > proposals > > > >> can > > > >> > > happen at future meetings if the VPN4DC work is adopted. > > > >> > > > > > >> > > Ben > > > >> > > > > > > > > > > From linda.dunbar@huawei.com Thu Nov 3 14:26:07 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 7F5451F0CD5 for ; Thu, 3 Nov 2011 14:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyuS0BgFvZU3 for ; Thu, 3 Nov 2011 14:26:07 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC171F0CD4 for ; Thu, 3 Nov 2011 14:26:07 -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 <0LU3005RTSEDJT@usaga02-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 16:15:50 -0500 (CDT) Received: from dfweml202-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 <0LU300MW3SEDBI@usaga02-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 16:15:49 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 03 Nov 2011 14:15:51 -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; Thu, 03 Nov 2011 14:15:43 -0700 Date: Thu, 03 Nov 2011 21:15:39 +0000 From: Linda Dunbar Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: <4EB2E9E9.7010705@raszuk.net> X-Originating-IP: [10.192.11.155] To: "robert@raszuk.net" Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120B2253@dfweml505-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEswgAAFNTCAANe5YIAAkROA//+fD5CAAHy2gP//pqFQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4EB2D29D.8000701@raszuk.net> <4A95BA014132FF49AE685FAB4B9F17F6120B20AE@dfweml505-mbx> <4EB2E9E9.7010705@raszuk.net> Cc: L3VPN WG mailing list 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, 03 Nov 2011 21:26:07 -0000 What do you mean by getting rid of PEs? PE represents the ownership, e.g. VPN provider owns the PE device. Linda > -----Original Message----- > From: Robert Raszuk [mailto:robert@raszuk.net] > Sent: Thursday, November 03, 2011 2:22 PM > To: Linda Dunbar > Cc: L3VPN WG mailing list > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > islands". I interpret it as defining a mechanism for VPN PEs to > > "discover" customer's network segments (i.e. subnets) from their > > adjacent networks (e.g. data center network). > > And I interpret it mainly as getting rid of PEs all together. > > Best regards, > R. > > > Robert, > > > > You are absolutely correct that "IPSec has been used for many years > > to interconnect hosts to L3VPN". That is why we don't need to invest > > energy on Model #1. > > > > I also agree with you that it will be very useful to find the > > flexible and universal auto-discovery tool for customer's network > > islands". I interpret it as defining a mechanism for VPN PEs to > > "discover" customer's network segments (i.e. subnets) from their > > adjacent networks (e.g. data center network). > > > > Linda > From robert@raszuk.net Thu Nov 3 15:18:06 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 615461F0CA4 for ; Thu, 3 Nov 2011 15:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, 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 WikHO+8aNY7F for ; Thu, 3 Nov 2011 15:18:05 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id A73F61F0C9F for ; Thu, 3 Nov 2011 15:18:05 -0700 (PDT) Received: (qmail 1981 invoked by uid 399); 3 Nov 2011 22:18:04 -0000 Received: from unknown (HELO ?192.168.1.57?) (83.28.177.170) by mail37.opentransfer.com with SMTP; 3 Nov 2011 22:18:04 -0000 Message-ID: <4EB3131D.5050702@raszuk.net> Date: Thu, 03 Nov 2011 23:18:05 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Pedro Marques Subject: Re: if-map schema for l3vpn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sdnp@lucidvision.com, 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: Thu, 03 Nov 2011 22:18:06 -0000 Hi Pedro, > I apologize in advance if i'm not answering the right question. Actually you have answered precisely the questions .. except one .. where those missing pieces of metadata elements are going to be defined? In other words don't you think that l3vpn schema should define them apriori ? Best regards, R. > Robert, > Thank you for your questions. > > On Thu, Nov 3, 2011 at 12:36 AM, Robert Raszuk wrote: > >>> IF-MAP schema for IP VPNs. >>> draft-marques-sndp-l3vpn-schema-00 >> >> Few questions on this one ... >> >> - How are you define choice of PE-CE routing protocol used to exchange >> reachability information ? > > I apologize in advance if i'm not answering the right question. I > understanding this question as: in the traditional SP-centric l3vpn > application, how does a provisioning system configure parameters such > as the PE-CE protocol. The answer to that would be by defining extra > elements in the "binding" metadata element. > >> >> - How do you envision scale of MAP server ? How about communication between >> MAP servers especially in case of distributed ones ? > > For reasons of resiliency and scale MAP servers should be distributed. > It is desirable to have the server-to-server protocol(s) be publicly > documented. There are multiple possible implementation strategies for > a distributed MAP server implementation. It would be reasonable to > have more than one publicly documented server-to-server protocol, > exporting the same API to clients. > >> >> - How about discussion of MAP server failure cases ? > >> From a client's perspective the MAP server is assumed to be resilient > / persistent. > >> >> - How one would go about negotiating with given VPN instance various per VPN >> security parameters (vrf-route-limit, prefix-limit etc ...) > > These would be optional elements in the metadata elements. > >> >> - Do you expect MAP server to be used to manage just single administrative >> domain leaving any form of inter-as or inter-provider out of scope (manual >> provisioning) ? > > inter-as inter-provider is likely to have very different requirements. > It would be possible to use a similar approach for communicating > operational data (e.g. customer name to route-target mappings) but for > requests that modify state the current web based API approach seems to > be better suited. > >> >>> A MAP server implementation SHOULD support access controls on a per >>> metadata element basis such that it is possible to restrict write >>> access to a set of metadata elements to a specific list of >>> certificates. >> >> This perhaps leaves a door a bit open to allow customer management of their >> VPN instance. That is great. However how do you envision possible extranets >> provisioning when applicable ? >> > > The focus is on provider provisioned VPNs, specially when it comes to > controlling the membership of the VPN. This is not an API that is > appropriate for the end-user application to interact with the network. > For the later i'd recommend looking at the work of the ALTO working > group. > > Pedro. > > From robert@raszuk.net Thu Nov 3 15:20:08 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 A96D51F0CC2 for ; Thu, 3 Nov 2011 15:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 BB9AZbiweF1y for ; Thu, 3 Nov 2011 15:20:08 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 0381F1F0C9F for ; Thu, 3 Nov 2011 15:20:07 -0700 (PDT) Received: (qmail 2762 invoked by uid 399); 3 Nov 2011 22:20:07 -0000 Received: from unknown (HELO ?192.168.1.57?) (83.28.177.170) by mail37.opentransfer.com with SMTP; 3 Nov 2011 22:20:07 -0000 Message-ID: <4EB31397.6090905@raszuk.net> Date: Thu, 03 Nov 2011 23:20:07 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Linda Dunbar Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4EB2D29D.8000701@raszuk.net> <4A95BA014132FF49AE685FAB4B9F17F6120B20AE@dfweml505-mbx> <4EB2E9E9.7010705@raszuk.net> <4A95BA014132FF49AE685FAB4B9F17F6120B2253@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120B2253@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN WG mailing list 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: Thu, 03 Nov 2011 22:20:08 -0000 Hi Linda, That is precisely the point. Getting rid of data plane ownership is something which would enable much more flexible individual and enterprise VPNs as compared with today's practices. For more details you are welcome to read draft-ko-vaas-problem-statement-01 Thx, R. > What do you mean by getting rid of PEs? PE represents the ownership, > e.g. VPN provider owns the PE device. > > Linda From lufang@cisco.com Thu Nov 3 15:21: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 0BABB1F0CC7 for ; Thu, 3 Nov 2011 15:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.09 X-Spam-Level: X-Spam-Status: No, score=-5.09 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eUZxNVO1kOt for ; Thu, 3 Nov 2011 15:21:10 -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 224A11F0C9F for ; Thu, 3 Nov 2011 15:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=3825; q=dns/txt; s=iport; t=1320358870; x=1321568470; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=puv1rUxc98PH3A2j7/wDuzjxb/pIZ5XwL01Rs6R2jfs=; b=ddcRLbgreR4OcUcplgCrhy+BobJTqKNEPKX29jdLiotgzS/Zgdz25Mgk YXfmNZAUc421mhnxCSol1cBRfl+kxzy3fcnN56NhMPJGCrLOBjcQnJIWF 1y6MUwhT86bYz/9geITzohvgqbKQyHu/z79phjeO8WGGnGWakRyTLOphU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskAAKgSs06tJV2c/2dsb2JhbABDmgiPfIEFgXIBAQEEEgEdCj8MBAIBCBEEAQEBCgYXAQYBRQkIAQEEARIIGp1mAZ5wiD1iBIgIkUqMSQ X-IronPort-AV: E=Sophos;i="4.69,452,1315180800"; d="scan'208";a="33251837" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 03 Nov 2011 22:21:09 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pA3ML9bY003710; Thu, 3 Nov 2011 22:21:09 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); Thu, 3 Nov 2011 17:21:09 -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: if-map schema for l3vpn Date: Thu, 3 Nov 2011 17:21:06 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CA6AE@XMB-RCD-201.cisco.com> In-Reply-To: <4EB3131D.5050702@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: if-map schema for l3vpn Thread-Index: Acyadng7oIBWgbYQTCCaLbrP1h4xHgAAC43w References: <4EB3131D.5050702@raszuk.net> From: "Luyuan Fang (lufang)" To: , "Pedro Marques" X-OriginalArrivalTime: 03 Nov 2011 22:21:09.0409 (UTC) FILETIME=[E31DA110:01CC9A76] 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: Thu, 03 Nov 2011 22:21:11 -0000 Would that be the reason this is on sdnp list as well? Luyuan > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Robert Raszuk > Sent: Thursday, November 03, 2011 6:18 PM > To: Pedro Marques > Cc: sdnp@lucidvision.com; l3vpn@ietf.org > Subject: Re: if-map schema for l3vpn >=20 > Hi Pedro, >=20 > > I apologize in advance if i'm not answering the right question. >=20 > Actually you have answered precisely the questions .. except one .. > where those missing pieces of metadata elements are going to be > defined? > In other words don't you think that l3vpn schema should define them > apriori ? >=20 > Best regards, > R. >=20 >=20 > > Robert, > > Thank you for your questions. > > > > On Thu, Nov 3, 2011 at 12:36 AM, Robert Raszuk > wrote: > > > >>> IF-MAP schema for IP VPNs. > >>> draft-marques-sndp-l3vpn-schema-00 > >> > >> Few questions on this one ... > >> > >> - How are you define choice of PE-CE routing protocol used to > exchange > >> reachability information ? > > > > I apologize in advance if i'm not answering the right question. I > > understanding this question as: in the traditional SP-centric l3vpn > > application, how does a provisioning system configure parameters such > > as the PE-CE protocol. The answer to that would be by defining extra > > elements in the "binding" metadata element. > > > >> > >> - How do you envision scale of MAP server ? How about communication > between > >> MAP servers especially in case of distributed ones ? > > > > For reasons of resiliency and scale MAP servers should be > distributed. > > It is desirable to have the server-to-server protocol(s) be publicly > > documented. There are multiple possible implementation strategies for > > a distributed MAP server implementation. It would be reasonable to > > have more than one publicly documented server-to-server protocol, > > exporting the same API to clients. > > > >> > >> - How about discussion of MAP server failure cases ? > > > >> From a client's perspective the MAP server is assumed to be > resilient > > / persistent. > > > >> > >> - How one would go about negotiating with given VPN instance various > per VPN > >> security parameters (vrf-route-limit, prefix-limit etc ...) > > > > These would be optional elements in the metadata elements. > > > >> > >> - Do you expect MAP server to be used to manage just single > administrative > >> domain leaving any form of inter-as or inter-provider out of scope > (manual > >> provisioning) ? > > > > inter-as inter-provider is likely to have very different > requirements. > > It would be possible to use a similar approach for communicating > > operational data (e.g. customer name to route-target mappings) but > for > > requests that modify state the current web based API approach seems > to > > be better suited. > > > >> > >>> A MAP server implementation SHOULD support access controls on a > per > >>> metadata element basis such that it is possible to restrict > write > >>> access to a set of metadata elements to a specific list of > >>> certificates. > >> > >> This perhaps leaves a door a bit open to allow customer management > of their > >> VPN instance. That is great. However how do you envision possible > extranets > >> provisioning when applicable ? > >> > > > > The focus is on provider provisioned VPNs, specially when it comes to > > controlling the membership of the VPN. This is not an API that is > > appropriate for the end-user application to interact with the > network. > > For the later i'd recommend looking at the work of the ALTO working > > group. > > > > Pedro. > > > > From lufang@cisco.com Thu Nov 3 15:32:47 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 E9F761F0C63 for ; Thu, 3 Nov 2011 15:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.828 X-Spam-Level: X-Spam-Status: No, score=-4.828 tagged_above=-999 required=5 tests=[AWL=0.571, 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 ilp9MY5SlDR4 for ; Thu, 3 Nov 2011 15:32:46 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9FC1F0C59 for ; Thu, 3 Nov 2011 15:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=8798; q=dns/txt; s=iport; t=1320359566; x=1321569166; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9qLG22qWHeXvN1f/gxexLx5qok+pQ8tAIEHtq7/e5rQ=; b=d4tWCov9vv8ukm7it43S45dLa+Foo4k3OoPfBoxzEmHlQnnUyOsRfV+v lwT0cy+cGV0PPFfe8cqVcPgFH8H3UTw0IayVq6/Aec83cmq1TiaS+eT84 JpJW7MdOJl1pLFLaFF1MShu1uD7vArNjCmPxCoeU0zvtPao8Z00ngNc3E o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAG8Vs06tJXG//2dsb2JhbABDmgmOW4EhgQWBcgEBAQMBEgEdCjQLDAQCAQgRBAEBAQoGFwEGASAlCQgCBAESCAESB4dgCJV8AZ5wiD1iBIgIkUqFAYdI X-IronPort-AV: E=Sophos;i="4.69,452,1315180800"; d="scan'208";a="33263752" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 03 Nov 2011 22:32:45 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA3MWj99022711; Thu, 3 Nov 2011 22:32:45 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); Thu, 3 Nov 2011 17:32:45 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: NcQ= B9Oo B9ok EKCv FhA0 Lv1j L3UF QEcs QQFl Qyl3 Ujxh Ztad afNw eU2h rCTX x4+R; 4; YgBlAG4AQABuAGkAdgBlAG4ALQBqAGUAbgBrAGkAbgBzAC4AYwBvAC4AdQBrADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtADsAcABlAGQAcgBvAC4AcgAuAG0AYQByAHEAdQBlAHMAQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {CFCFB4CA-18AF-4798-8B2F-1BAD951D7D2E}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Thu, 03 Nov 2011 22:32:26 GMT; UgBFADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {CFCFB4CA-18AF-4798-8B2F-1BAD951D7D2E} Content-class: urn:content-classes:message Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 Date: Thu, 3 Nov 2011 17:32:26 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CA6B8@XMB-RCD-201.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120B21DF@dfweml505-mbx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEswgAAFNTCAANe5YIAAi3sA//+kw6CAAAcCIIAAEieQgAAC2jA= References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA5DC@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B21DF@dfweml505-mbx> From: "Luyuan Fang (lufang)" To: "Linda Dunbar" , "Pedro Marques" X-OriginalArrivalTime: 03 Nov 2011 22:32:45.0480 (UTC) FILETIME=[8201A280:01CC9A78] Cc: L3VPN WG mailing list 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, 03 Nov 2011 22:32:48 -0000 VLAN based was not in this conversation. When you said - > > > I've seen many data centers with Layer 2 or Layer 3 interconnecting > > > servers among all the server racks. > > > Does anyone know of any data centers which use L3VPN to > interconnect > > > servers within a data center? Is your point we need to extend the use of RFC4364 VPN as it is to interconnect servers within a data center, or we need to extend the VPNs with other l3 technologies to allow end systems join the VPNs easily?=20 Just try to understand your point. I'd assume it is the later. Luyuan > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Thursday, November 03, 2011 4:28 PM > To: Luyuan Fang (lufang); Pedro Marques > Cc: Ben Niven-Jenkins; L3VPN WG mailing list > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >=20 > I mean RFC4364 based L3VPN. >=20 > For VLAN based VPN, I would categorize it to L2 based solution. >=20 > Linda >=20 > > -----Original Message----- > > From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > > Sent: Thursday, November 03, 2011 2:25 PM > > To: Linda Dunbar; Pedro Marques > > Cc: Ben Niven-Jenkins; L3VPN WG mailing list > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > Your definition of L3VPN here? > > > > - BGP/MPLS VPN (RFC 4364)? > > - The current L3VPN WG scope? > > - any ip (layer 3) VPN technologies? > > > > Luyuan > > > > > -----Original Message----- > > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > > Sent: Thursday, November 03, 2011 3:05 PM > > > To: Pedro Marques > > > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing list > > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > I am only trying to get the boundary of this VPN4DC to make the > > > discussion more focused. > > > > > > As for "talking about CE attachment circuit" or "interconnecting > > hosts > > > in a data center whose network is L3VPN based", I think we should > > > invest energy in the first. > > > > > > I've seen many data centers with Layer 2 or Layer 3 interconnecting > > > servers among all the server racks. > > > Does anyone know of any data centers which use L3VPN to > interconnect > > > servers within a data center? > > > > > > Linda > > > > > > > -----Original Message----- > > > > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > > > > Sent: Thursday, November 03, 2011 12:23 PM > > > > To: Linda Dunbar > > > > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing > list > > > > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > > > It appears to me that you are discussing business models rather > > than > > > > the underlying technology. At least from my view point, when it > > comes > > > > to technology both of your examples are the same: a private > > > enterprise > > > > network interconnects with a public data-center. Irrespective of > > the > > > > question of economic ownership, the data center network is > > different > > > > from the WAN network and is managed differently. > > > > > > > > The issue only becomes relevant to the l3vpn working group if one > > > > assumes that there are multiple enterprise VPN networks > connecting > > to > > > > a particular datacenter and there is a VPN technology in the > > > > datacenter. Otherwise we are talking of a CE attachment circuit > and > > > it > > > > really don't matter what service sits behind that circuit. > > > > > > > > regards, > > > > Pedro. > > > > > > > > On Thu, Nov 3, 2011 at 9:30 AM, Linda Dunbar > > > > > > > wrote: > > > > > Here is the fundamental question for the goal of VPN4DC: > > > > > > > > > > 1. Is VPN4DC to create mechanisms which make it possible to > > connect > > > > hosts in > > > > > any public data centers (e.g. Amazon' EC2) to hosts' > > corresponding > > > > VPNs? Or > > > > > > > > > > 2. Is VPN4DC to create a solution which allows VPN service > > provider > > > > to > > > > > extend their VPN with computing service? In this model, > customers > > > > (i.e. VPN > > > > > clients) see their computing resources being offloaded to their > > > VPN. > > > > > Customers don't deal with data centers directly. > > > > > > > > > > > > > > > Personally I don't think that we need to waste our time on > Model > > #1 > > > > for the > > > > > following reasons: > > > > > > > > > > VPN service providers may not even have PEs in close proximity > to > > > > "the > > > > > public data centers" which clients choose. If a VPN client has > > > leased > > > > some > > > > > computing resource from a data center, the easiest way to > connect > > > > them > > > > > securely is by IPSec tunnel. > > > > > > > > > > > > > > > > > > > > Today Amazon already allows any hosts to be connected to their > > > chosen > > > > sites > > > > > by IPSec (Amazon's VPC service). > > > > > > > > > > > > > > > Model #2 gives VPN service providers an unique advantage of > > binding > > > > valuable > > > > > VPN services with virtual computing services, making it more > > > > difficult for > > > > > data centers who don't own network infrastructure to compete. > > > > > > > > > > Do people agree? > > > > > > > > > > Linda > > > > > > > > > >> -----Original Message----- > > > > >> From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > > > > >> Sent: Wednesday, November 02, 2011 11:41 PM > > > > >> To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > > > > >> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > >> > > > > >> Linda, > > > > >> > > > > >> Ben suggested that Ning and myself to work with co-authors of > > > other > > > > >> problem statement drafts to come up with a combined view to be > > > > >> presented > > > > >> in Taipei meeting. The requirements drafts would be treated in > > the > > > > >> similar fashion. I plan to put gap analysis together with pb > > > > statement > > > > >> drafts. > > > > >> > > > > >> Though there would be no individual vpn4dc drafts > presentations > > as > > > > in > > > > >> normal WG meetings, we welcome input on all three subjects > from > > > > authors > > > > >> of vpn4dc related drafts, and everyone on the list. > > > > >> > > > > >> In fact, the intent of vpn4dc Q&A I sent a couple of days ago > > was > > > to > > > > >> gather feedback/input from the list, as the first step of > > meeting > > > > prep. > > > > >> > > > > >> Will get together with the authors of the relevant drafts to > > > discuss > > > > >> soon, prefer we meet when Ning is back to office in a couple > of > > > days. > > > > >> Ping me if you cannot wait. > > > > >> > > > > >> Thanks, > > > > >> Luyuan > > > > >> > > > > >> > > > > >> > -----Original Message----- > > > > >> > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] > > On > > > > >> Behalf > > > > >> > Of Linda Dunbar > > > > >> > Sent: Wednesday, November 02, 2011 10:56 PM > > > > >> > To: Ben Niven-Jenkins; L3VPN WG mailing list > > > > >> > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > >> > > > > > >> > Who will lead the talk for each topic? > > > > >> > > > > > >> > Linda > > > > >> > > > > > >> > > -----Original Message----- > > > > >> > > From: l3vpn-bounces@ietf.org [mailto:l3vpn- > bounces@ietf.org] > > > On > > > > >> > Behalf > > > > >> > > Of Ben Niven-Jenkins > > > > >> > > Sent: Wednesday, November 02, 2011 1:01 PM > > > > >> > > To: L3VPN WG mailing list > > > > >> > > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > >> > > > > > > >> > > Colleagues, > > > > >> > > > > > > >> > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC > agenda > > > for > > > > >> IETF > > > > >> > > 82 in Taipei. You can find it here: > > > > >> > > > > > > >> > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > > > >> > > > > > > >> > > At the moment the agenda is a little vague because we are > > > still > > > > >> > working > > > > >> > > with the VPN4DC proponents on who will lead each slot. > > > > >> > > > > > > >> > > We have purposely not put time on the agenda to > > > present/discuss > > > > >> > > specific solution drafts as we would like the discussion > to > > be > > > > >> > focussed > > > > >> > > on the problem/requirements posed by VPN4DC and its > > > > applicability > > > > >> to > > > > >> > > IETF (including L3VPN). Discussion of specific solution > > > > proposals > > > > >> can > > > > >> > > happen at future meetings if the VPN4DC work is adopted. > > > > >> > > > > > > >> > > Ben > > > > >> > > > > > > > > > > > > From linda.dunbar@huawei.com Thu Nov 3 15:50:49 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 9942B1F0CD7 for ; Thu, 3 Nov 2011 15:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.794 X-Spam-Level: X-Spam-Status: No, score=-5.794 tagged_above=-999 required=5 tests=[AWL=-0.395, 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 cysVthNwazQW for ; Thu, 3 Nov 2011 15:50:48 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9251F0C59 for ; Thu, 3 Nov 2011 15:50:48 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU30047SWSI50@usaga04-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 17:50:43 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU3007KSWSHZY@usaga04-in.huawei.com> for l3vpn@ietf.org; Thu, 03 Nov 2011 17:50:42 -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; Thu, 03 Nov 2011 15:50:35 -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; Thu, 03 Nov 2011 15:50:31 -0700 Date: Thu, 03 Nov 2011 22:50:26 +0000 From: Linda Dunbar Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: <238542D917511A45B6B8AA806E875E25073CA6B8@XMB-RCD-201.cisco.com> X-Originating-IP: [10.192.11.155] To: "Luyuan Fang (lufang)" , Pedro Marques Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120B22E8@dfweml505-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEswgAAFNTCAANe5YIAAi3sA//+kw6CAAAcCIIAAEieQgAAC2jCAACMdsA== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: A13w JwCS KyM4 K/K7 M9Oj TSWJ VIyw Vwfu WopR Xe5G YgWA aneF dxTi jf2F nkMj pVDG; 4; YgBlAG4AQABuAGkAdgBlAG4ALQBqAGUAbgBrAGkAbgBzAC4AYwBvAC4AdQBrADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA7AHAAZQBkAHIAbwAuAHIALgBtAGEAcgBxAHUAZQBzAEAAZwBtAGEAaQBsAC4AYwBvAG0A; Sosha1_v1; 7; {4890F0C5-06BE-48A8-92C7-8395F634C07C}; bABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 03 Nov 2011 22:50:22 GMT; UgBFADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== x-cr-puzzleid: {4890F0C5-06BE-48A8-92C7-8395F634C07C} References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA5DC@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B21DF@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA6B8@XMB-RCD-201.cisco.com> Cc: L3VPN WG mailing list 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, 03 Nov 2011 22:50:50 -0000 Since the title is VPN4DC, I prefer your first interpretation: i.e. let group of hosts (servers or VMs) in a data center to join an external L3VPN. The network within the data center can be anything (L2 based, IP based, etc). For your second interpretation, i.e. "extend the VPNs with other l3 technologies to allow end systems join the VPNs easily", "VPN-Interconnect" would be a more accurate name. In this interpretation, "DC" shouldn't be in the title because its major application probably is not Data Center. Linda > -----Original Message----- > From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > Sent: Thursday, November 03, 2011 5:32 PM > To: Linda Dunbar; Pedro Marques > Cc: Ben Niven-Jenkins; L3VPN WG mailing list > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > VLAN based was not in this conversation. > > When you said - > > > > I've seen many data centers with Layer 2 or Layer 3 > interconnecting > > > > servers among all the server racks. > > > > Does anyone know of any data centers which use L3VPN to > > interconnect > > > > servers within a data center? > > Is your point we need to extend the use of RFC4364 VPN as it is to > interconnect servers within a data center, or we need to extend the > VPNs > with other l3 technologies to allow end systems join the VPNs easily? > > Just try to understand your point. I'd assume it is the later. > > Luyuan > > > > -----Original Message----- > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > Sent: Thursday, November 03, 2011 4:28 PM > > To: Luyuan Fang (lufang); Pedro Marques > > Cc: Ben Niven-Jenkins; L3VPN WG mailing list > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > I mean RFC4364 based L3VPN. > > > > For VLAN based VPN, I would categorize it to L2 based solution. > > > > Linda > > > > > -----Original Message----- > > > From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > > > Sent: Thursday, November 03, 2011 2:25 PM > > > To: Linda Dunbar; Pedro Marques > > > Cc: Ben Niven-Jenkins; L3VPN WG mailing list > > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > Your definition of L3VPN here? > > > > > > - BGP/MPLS VPN (RFC 4364)? > > > - The current L3VPN WG scope? > > > - any ip (layer 3) VPN technologies? > > > > > > Luyuan > > > > > > > -----Original Message----- > > > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > > > Sent: Thursday, November 03, 2011 3:05 PM > > > > To: Pedro Marques > > > > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing > list > > > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > > > I am only trying to get the boundary of this VPN4DC to make the > > > > discussion more focused. > > > > > > > > As for "talking about CE attachment circuit" or "interconnecting > > > hosts > > > > in a data center whose network is L3VPN based", I think we should > > > > invest energy in the first. > > > > > > > > I've seen many data centers with Layer 2 or Layer 3 > interconnecting > > > > servers among all the server racks. > > > > Does anyone know of any data centers which use L3VPN to > > interconnect > > > > servers within a data center? > > > > > > > > Linda > > > > > > > > > -----Original Message----- > > > > > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > > > > > Sent: Thursday, November 03, 2011 12:23 PM > > > > > To: Linda Dunbar > > > > > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing > > list > > > > > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > > > > > It appears to me that you are discussing business models rather > > > than > > > > > the underlying technology. At least from my view point, when it > > > comes > > > > > to technology both of your examples are the same: a private > > > > enterprise > > > > > network interconnects with a public data-center. Irrespective > of > > > the > > > > > question of economic ownership, the data center network is > > > different > > > > > from the WAN network and is managed differently. > > > > > > > > > > The issue only becomes relevant to the l3vpn working group if > one > > > > > assumes that there are multiple enterprise VPN networks > > connecting > > > to > > > > > a particular datacenter and there is a VPN technology in the > > > > > datacenter. Otherwise we are talking of a CE attachment circuit > > and > > > > it > > > > > really don't matter what service sits behind that circuit. > > > > > > > > > > regards, > > > > > Pedro. > > > > > > > > > > On Thu, Nov 3, 2011 at 9:30 AM, Linda Dunbar > > > > > > > > > wrote: > > > > > > Here is the fundamental question for the goal of VPN4DC: > > > > > > > > > > > > 1. Is VPN4DC to create mechanisms which make it possible to > > > connect > > > > > hosts in > > > > > > any public data centers (e.g. Amazon' EC2) to hosts' > > > corresponding > > > > > VPNs? Or > > > > > > > > > > > > 2. Is VPN4DC to create a solution which allows VPN service > > > provider > > > > > to > > > > > > extend their VPN with computing service? In this model, > > customers > > > > > (i.e. VPN > > > > > > clients) see their computing resources being offloaded to > their > > > > VPN. > > > > > > Customers don't deal with data centers directly. > > > > > > > > > > > > > > > > > > Personally I don't think that we need to waste our time on > > Model > > > #1 > > > > > for the > > > > > > following reasons: > > > > > > > > > > > > VPN service providers may not even have PEs in close > proximity > > to > > > > > "the > > > > > > public data centers" which clients choose. If a VPN client > has > > > > leased > > > > > some > > > > > > computing resource from a data center, the easiest way to > > connect > > > > > them > > > > > > securely is by IPSec tunnel. > > > > > > > > > > > > > > > > > > > > > > > > Today Amazon already allows any hosts to be connected to > their > > > > chosen > > > > > sites > > > > > > by IPSec (Amazon's VPC service). > > > > > > > > > > > > > > > > > > Model #2 gives VPN service providers an unique advantage of > > > binding > > > > > valuable > > > > > > VPN services with virtual computing services, making it more > > > > > difficult for > > > > > > data centers who don't own network infrastructure to compete. > > > > > > > > > > > > Do people agree? > > > > > > > > > > > > Linda > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > > > > > >> Sent: Wednesday, November 02, 2011 11:41 PM > > > > > >> To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > > > > > >> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > >> > > > > > >> Linda, > > > > > >> > > > > > >> Ben suggested that Ning and myself to work with co-authors > of > > > > other > > > > > >> problem statement drafts to come up with a combined view to > be > > > > > >> presented > > > > > >> in Taipei meeting. The requirements drafts would be treated > in > > > the > > > > > >> similar fashion. I plan to put gap analysis together with pb > > > > > statement > > > > > >> drafts. > > > > > >> > > > > > >> Though there would be no individual vpn4dc drafts > > presentations > > > as > > > > > in > > > > > >> normal WG meetings, we welcome input on all three subjects > > from > > > > > authors > > > > > >> of vpn4dc related drafts, and everyone on the list. > > > > > >> > > > > > >> In fact, the intent of vpn4dc Q&A I sent a couple of days > ago > > > was > > > > to > > > > > >> gather feedback/input from the list, as the first step of > > > meeting > > > > > prep. > > > > > >> > > > > > >> Will get together with the authors of the relevant drafts to > > > > discuss > > > > > >> soon, prefer we meet when Ning is back to office in a couple > > of > > > > days. > > > > > >> Ping me if you cannot wait. > > > > > >> > > > > > >> Thanks, > > > > > >> Luyuan > > > > > >> > > > > > >> > > > > > >> > -----Original Message----- > > > > > >> > From: l3vpn-bounces@ietf.org > [mailto:l3vpn-bounces@ietf.org] > > > On > > > > > >> Behalf > > > > > >> > Of Linda Dunbar > > > > > >> > Sent: Wednesday, November 02, 2011 10:56 PM > > > > > >> > To: Ben Niven-Jenkins; L3VPN WG mailing list > > > > > >> > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > >> > > > > > > >> > Who will lead the talk for each topic? > > > > > >> > > > > > > >> > Linda > > > > > >> > > > > > > >> > > -----Original Message----- > > > > > >> > > From: l3vpn-bounces@ietf.org [mailto:l3vpn- > > bounces@ietf.org] > > > > On > > > > > >> > Behalf > > > > > >> > > Of Ben Niven-Jenkins > > > > > >> > > Sent: Wednesday, November 02, 2011 1:01 PM > > > > > >> > > To: L3VPN WG mailing list > > > > > >> > > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > >> > > > > > > > >> > > Colleagues, > > > > > >> > > > > > > > >> > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC > > agenda > > > > for > > > > > >> IETF > > > > > >> > > 82 in Taipei. You can find it here: > > > > > >> > > > > > > > >> > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > > > > >> > > > > > > > >> > > At the moment the agenda is a little vague because we > are > > > > still > > > > > >> > working > > > > > >> > > with the VPN4DC proponents on who will lead each slot. > > > > > >> > > > > > > > >> > > We have purposely not put time on the agenda to > > > > present/discuss > > > > > >> > > specific solution drafts as we would like the discussion > > to > > > be > > > > > >> > focussed > > > > > >> > > on the problem/requirements posed by VPN4DC and its > > > > > applicability > > > > > >> to > > > > > >> > > IETF (including L3VPN). Discussion of specific solution > > > > > proposals > > > > > >> can > > > > > >> > > happen at future meetings if the VPN4DC work is adopted. > > > > > >> > > > > > > > >> > > Ben > > > > > >> > > > > > > > > > > > > > > From lufang@cisco.com Thu Nov 3 16:08: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 8208D1F0C59 for ; Thu, 3 Nov 2011 16:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[AWL=0.548, 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 qF+VKHMZ0V90 for ; Thu, 3 Nov 2011 16:08:26 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0091F0C3D for ; Thu, 3 Nov 2011 16:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=11626; q=dns/txt; s=iport; t=1320361701; x=1321571301; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BY9o2OcSskcykzSDwG2usvGNKVsdYOKbJePmoDaYmHI=; b=N3wZh6BaO8ouFHrNF+RFLDO38qWRx6zRa1A5JoeTN3Ul3Lov1sXL+2Tg apwlKHg6FELHZ3GRtGrBRuXABN0gUeChTTkXxO6C2AHcCstftyquyUONt C+zc8fnIemEYrnoDhOJVQ7KM7zdRtQc9Wx+CXrtOUChCgDSY3qqNrWxVr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAF4es06rRDoI/2dsb2JhbABDmgmOW4EhgQWBcgEBAQMBEgEdCjQLBQcEAgEIEQQBAQEKBhcBBgEgJQkIAgQBEggBEgeHYAiVdgGedIg9YgSICJFKhQGHSA X-IronPort-AV: E=Sophos;i="4.69,453,1315180800"; d="scan'208";a="10833896" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 03 Nov 2011 23:08:20 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA3N8Kqm009684; Thu, 3 Nov 2011 23:08:20 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); Thu, 3 Nov 2011 18:08:20 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: CNgT Ccdn DGVK EzSf FIxC O/Ka RaVC TZTL Tc5y UWxT appZ dbJF h7PT jfI2 qjFE qvKG; 4; YgBlAG4AQABuAGkAdgBlAG4ALQBqAGUAbgBrAGkAbgBzAC4AYwBvAC4AdQBrADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtADsAcABlAGQAcgBvAC4AcgAuAG0AYQByAHEAdQBlAHMAQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {F0E4A52D-2223-4D47-B155-D6264B085CCC}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Thu, 03 Nov 2011 23:07:49 GMT; UgBFADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {F0E4A52D-2223-4D47-B155-D6264B085CCC} Content-class: urn:content-classes:message Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 Date: Thu, 3 Nov 2011 18:07:49 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CA6CC@XMB-RCD-201.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120B22E8@dfweml505-mbx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Index: AQHMmYl6E4TYRDW10UGqTgml5BhLpZWadEswgAAFNTCAANe5YIAAi3sA//+kw6CAAAcCIIAAEieQgAAC2jCAACMdsIAAAvdw References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA5DC@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B21DF@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA6B8@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B22E8@dfweml505-mbx> From: "Luyuan Fang (lufang)" To: "Linda Dunbar" , "Pedro Marques" X-OriginalArrivalTime: 03 Nov 2011 23:08:20.0524 (UTC) FILETIME=[7A977EC0:01CC9A7D] Cc: L3VPN WG mailing list 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, 03 Nov 2011 23:08:27 -0000 I think we are crossing each other. The 1st option is to use "RFC4364 VPN as it is" in DC, the technology is there, not sure what you meant we need to do. The 2nd option, may be my wording was not so clean, meant to say extend with other IP tech - still VPN - but may not be 4364 end-to-end (in any to any environment). We may not have much disagreement. In any case, better talk face to face or on the phone than keep miss-interpreting each other.=20 I'll stop this mail for now. Luyuan > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Thursday, November 03, 2011 6:50 PM > To: Luyuan Fang (lufang); Pedro Marques > Cc: Ben Niven-Jenkins; L3VPN WG mailing list > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >=20 > Since the title is VPN4DC, I prefer your first interpretation: i.e. let > group of hosts (servers or VMs) in a data center to join an external > L3VPN. The network within the data center can be anything (L2 based, IP > based, etc). >=20 >=20 > For your second interpretation, i.e. "extend the VPNs with other l3 > technologies to allow end systems join the VPNs easily", "VPN- > Interconnect" would be a more accurate name. In this interpretation, > "DC" shouldn't be in the title because its major application probably > is not Data Center. >=20 > Linda >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > > Sent: Thursday, November 03, 2011 5:32 PM > > To: Linda Dunbar; Pedro Marques > > Cc: Ben Niven-Jenkins; L3VPN WG mailing list > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > VLAN based was not in this conversation. > > > > When you said - > > > > > I've seen many data centers with Layer 2 or Layer 3 > > interconnecting > > > > > servers among all the server racks. > > > > > Does anyone know of any data centers which use L3VPN to > > > interconnect > > > > > servers within a data center? > > > > Is your point we need to extend the use of RFC4364 VPN as it is to > > interconnect servers within a data center, or we need to extend the > > VPNs > > with other l3 technologies to allow end systems join the VPNs easily? > > > > Just try to understand your point. I'd assume it is the later. > > > > Luyuan > > > > > > > -----Original Message----- > > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > > Sent: Thursday, November 03, 2011 4:28 PM > > > To: Luyuan Fang (lufang); Pedro Marques > > > Cc: Ben Niven-Jenkins; L3VPN WG mailing list > > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > I mean RFC4364 based L3VPN. > > > > > > For VLAN based VPN, I would categorize it to L2 based solution. > > > > > > Linda > > > > > > > -----Original Message----- > > > > From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > > > > Sent: Thursday, November 03, 2011 2:25 PM > > > > To: Linda Dunbar; Pedro Marques > > > > Cc: Ben Niven-Jenkins; L3VPN WG mailing list > > > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > > > Your definition of L3VPN here? > > > > > > > > - BGP/MPLS VPN (RFC 4364)? > > > > - The current L3VPN WG scope? > > > > - any ip (layer 3) VPN technologies? > > > > > > > > Luyuan > > > > > > > > > -----Original Message----- > > > > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > > > > Sent: Thursday, November 03, 2011 3:05 PM > > > > > To: Pedro Marques > > > > > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing > > list > > > > > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > > > > > I am only trying to get the boundary of this VPN4DC to make the > > > > > discussion more focused. > > > > > > > > > > As for "talking about CE attachment circuit" or > "interconnecting > > > > hosts > > > > > in a data center whose network is L3VPN based", I think we > should > > > > > invest energy in the first. > > > > > > > > > > I've seen many data centers with Layer 2 or Layer 3 > > interconnecting > > > > > servers among all the server racks. > > > > > Does anyone know of any data centers which use L3VPN to > > > interconnect > > > > > servers within a data center? > > > > > > > > > > Linda > > > > > > > > > > > -----Original Message----- > > > > > > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > > > > > > Sent: Thursday, November 03, 2011 12:23 PM > > > > > > To: Linda Dunbar > > > > > > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG mailing > > > list > > > > > > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > > > > > > > It appears to me that you are discussing business models > rather > > > > than > > > > > > the underlying technology. At least from my view point, when > it > > > > comes > > > > > > to technology both of your examples are the same: a private > > > > > enterprise > > > > > > network interconnects with a public data-center. Irrespective > > of > > > > the > > > > > > question of economic ownership, the data center network is > > > > different > > > > > > from the WAN network and is managed differently. > > > > > > > > > > > > The issue only becomes relevant to the l3vpn working group if > > one > > > > > > assumes that there are multiple enterprise VPN networks > > > connecting > > > > to > > > > > > a particular datacenter and there is a VPN technology in the > > > > > > datacenter. Otherwise we are talking of a CE attachment > circuit > > > and > > > > > it > > > > > > really don't matter what service sits behind that circuit. > > > > > > > > > > > > regards, > > > > > > Pedro. > > > > > > > > > > > > On Thu, Nov 3, 2011 at 9:30 AM, Linda Dunbar > > > > > > > > > > > wrote: > > > > > > > Here is the fundamental question for the goal of VPN4DC: > > > > > > > > > > > > > > 1. Is VPN4DC to create mechanisms which make it possible to > > > > connect > > > > > > hosts in > > > > > > > any public data centers (e.g. Amazon' EC2) to hosts' > > > > corresponding > > > > > > VPNs? Or > > > > > > > > > > > > > > 2. Is VPN4DC to create a solution which allows VPN service > > > > provider > > > > > > to > > > > > > > extend their VPN with computing service? In this model, > > > customers > > > > > > (i.e. VPN > > > > > > > clients) see their computing resources being offloaded to > > their > > > > > VPN. > > > > > > > Customers don't deal with data centers directly. > > > > > > > > > > > > > > > > > > > > > Personally I don't think that we need to waste our time on > > > Model > > > > #1 > > > > > > for the > > > > > > > following reasons: > > > > > > > > > > > > > > VPN service providers may not even have PEs in close > > proximity > > > to > > > > > > "the > > > > > > > public data centers" which clients choose. If a VPN client > > has > > > > > leased > > > > > > some > > > > > > > computing resource from a data center, the easiest way to > > > connect > > > > > > them > > > > > > > securely is by IPSec tunnel. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Today Amazon already allows any hosts to be connected to > > their > > > > > chosen > > > > > > sites > > > > > > > by IPSec (Amazon's VPC service). > > > > > > > > > > > > > > > > > > > > > Model #2 gives VPN service providers an unique advantage of > > > > binding > > > > > > valuable > > > > > > > VPN services with virtual computing services, making it > more > > > > > > difficult for > > > > > > > data centers who don't own network infrastructure to > compete. > > > > > > > > > > > > > > Do people agree? > > > > > > > > > > > > > > Linda > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > > > > > > >> Sent: Wednesday, November 02, 2011 11:41 PM > > > > > > >> To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > > > > > > >> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > >> > > > > > > >> Linda, > > > > > > >> > > > > > > >> Ben suggested that Ning and myself to work with co-authors > > of > > > > > other > > > > > > >> problem statement drafts to come up with a combined view > to > > be > > > > > > >> presented > > > > > > >> in Taipei meeting. The requirements drafts would be > treated > > in > > > > the > > > > > > >> similar fashion. I plan to put gap analysis together with > pb > > > > > > statement > > > > > > >> drafts. > > > > > > >> > > > > > > >> Though there would be no individual vpn4dc drafts > > > presentations > > > > as > > > > > > in > > > > > > >> normal WG meetings, we welcome input on all three subjects > > > from > > > > > > authors > > > > > > >> of vpn4dc related drafts, and everyone on the list. > > > > > > >> > > > > > > >> In fact, the intent of vpn4dc Q&A I sent a couple of days > > ago > > > > was > > > > > to > > > > > > >> gather feedback/input from the list, as the first step of > > > > meeting > > > > > > prep. > > > > > > >> > > > > > > >> Will get together with the authors of the relevant drafts > to > > > > > discuss > > > > > > >> soon, prefer we meet when Ning is back to office in a > couple > > > of > > > > > days. > > > > > > >> Ping me if you cannot wait. > > > > > > >> > > > > > > >> Thanks, > > > > > > >> Luyuan > > > > > > >> > > > > > > >> > > > > > > >> > -----Original Message----- > > > > > > >> > From: l3vpn-bounces@ietf.org > > [mailto:l3vpn-bounces@ietf.org] > > > > On > > > > > > >> Behalf > > > > > > >> > Of Linda Dunbar > > > > > > >> > Sent: Wednesday, November 02, 2011 10:56 PM > > > > > > >> > To: Ben Niven-Jenkins; L3VPN WG mailing list > > > > > > >> > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > >> > > > > > > > >> > Who will lead the talk for each topic? > > > > > > >> > > > > > > > >> > Linda > > > > > > >> > > > > > > > >> > > -----Original Message----- > > > > > > >> > > From: l3vpn-bounces@ietf.org [mailto:l3vpn- > > > bounces@ietf.org] > > > > > On > > > > > > >> > Behalf > > > > > > >> > > Of Ben Niven-Jenkins > > > > > > >> > > Sent: Wednesday, November 02, 2011 1:01 PM > > > > > > >> > > To: L3VPN WG mailing list > > > > > > >> > > Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > > > >> > > > > > > > > >> > > Colleagues, > > > > > > >> > > > > > > > > >> > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC > > > agenda > > > > > for > > > > > > >> IETF > > > > > > >> > > 82 in Taipei. You can find it here: > > > > > > >> > > > > > > > > >> > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > > > > > >> > > > > > > > > >> > > At the moment the agenda is a little vague because we > > are > > > > > still > > > > > > >> > working > > > > > > >> > > with the VPN4DC proponents on who will lead each slot. > > > > > > >> > > > > > > > > >> > > We have purposely not put time on the agenda to > > > > > present/discuss > > > > > > >> > > specific solution drafts as we would like the > discussion > > > to > > > > be > > > > > > >> > focussed > > > > > > >> > > on the problem/requirements posed by VPN4DC and its > > > > > > applicability > > > > > > >> to > > > > > > >> > > IETF (including L3VPN). Discussion of specific > solution > > > > > > proposals > > > > > > >> can > > > > > > >> > > happen at future meetings if the VPN4DC work is > adopted. > > > > > > >> > > > > > > > > >> > > Ben > > > > > > >> > > > > > > > > > > > > > > > > From pedro.r.marques@gmail.com Thu Nov 3 16:22: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 448641F0C59 for ; Thu, 3 Nov 2011 16:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, 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 4-zXnlTa3ZcD for ; Thu, 3 Nov 2011 16:22:40 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6891F0C3D for ; Thu, 3 Nov 2011 16:22:40 -0700 (PDT) Received: by qadc10 with SMTP id c10so2092794qad.31 for ; Thu, 03 Nov 2011 16:22:39 -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=CygKtwUHEQVsk8gBM7mkxgvKGpSiCHmqeJn/OTpy4Lk=; b=O273+ZNqLX6AiXeFGdb8GS8Hk/qnk+0lT3hOduDM35SmW2FWAaky1CfrY+ZFIQhW2W w8+TP6xtaVV8m60ZLj7zazi+ZAN4iZRoJPhpFU1n8bKOmfZzeQDmEuIRsKPy2fpgRBR5 gdrNJDJ1j8Ugi6q58vRjPVUcPMn0pRVHGUfdI= MIME-Version: 1.0 Received: by 10.50.6.202 with SMTP id d10mr7394650iga.31.1320362559517; Thu, 03 Nov 2011 16:22:39 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Thu, 3 Nov 2011 16:22:39 -0700 (PDT) In-Reply-To: <4EB3131D.5050702@raszuk.net> References: <4EB3131D.5050702@raszuk.net> Date: Thu, 3 Nov 2011 16:22:39 -0700 Message-ID: Subject: Re: if-map schema for l3vpn From: Pedro Marques To: robert@raszuk.net 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: Thu, 03 Nov 2011 23:22:43 -0000 Yes. I believe commonly used config elements should be documented in this document (or a document that supersedes it). This is just a draft pre-00 intended to explain the approach. Pedro. On Thu, Nov 3, 2011 at 3:18 PM, Robert Raszuk wrote: > Hi Pedro, > >> I apologize in advance if i'm not answering the right question. > > Actually you have answered precisely the questions .. except one .. where > those missing pieces of metadata elements are going to be defined? In oth= er > words don't you think that l3vpn schema should define them apriori ? > > Best regards, > R. > > >> Robert, >> Thank you for your questions. >> >> On Thu, Nov 3, 2011 at 12:36 AM, Robert Raszuk =A0wro= te: >> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IF-MAP schema for IP VPNs. >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-marques-sndp-l3vpn-schema-00 >>> >>> Few questions on this one ... >>> >>> - How are you define choice of PE-CE routing protocol used to exchange >>> reachability information ? >> >> I apologize in advance if i'm not answering the right question. I >> understanding this question as: in the traditional SP-centric l3vpn >> application, how does a provisioning system configure parameters such >> as the PE-CE protocol. The answer to that would be by defining extra >> elements in the "binding" metadata element. >> >>> >>> - How do you envision scale of MAP server ? How about communication >>> between >>> MAP servers especially in case of distributed ones ? >> >> For reasons of resiliency and scale MAP servers should be distributed. >> It is desirable to have the server-to-server protocol(s) be publicly >> documented. There are multiple possible implementation strategies for >> a distributed MAP server implementation. It would be reasonable to >> have more than one publicly documented server-to-server protocol, >> exporting the same API to clients. >> >>> >>> - How about discussion of MAP server failure cases ? >> >>> From a client's perspective the MAP server is assumed to be resilient >> >> / persistent. >> >>> >>> - How one would go about negotiating with given VPN instance various pe= r >>> VPN >>> security parameters (vrf-route-limit, prefix-limit etc ...) >> >> These would be optional elements in the metadata elements. >> >>> >>> - Do you expect MAP server to be used to manage just single >>> administrative >>> domain leaving any form of inter-as or inter-provider out of scope >>> (manual >>> provisioning) ? >> >> inter-as inter-provider is likely to have very different requirements. >> It would be possible to use a similar approach for communicating >> operational data (e.g. customer name to route-target mappings) but for >> requests that modify state the current web based API approach seems to >> be better suited. >> >>> >>>> =A0 A MAP server implementation SHOULD support access controls on a pe= r >>>> =A0 metadata element basis such that it is possible to restrict write >>>> =A0 access to a set of metadata elements to a specific list of >>>> =A0 certificates. >>> >>> This perhaps leaves a door a bit open to allow customer management of >>> their >>> VPN instance. That is great. However how do you envision possible >>> extranets >>> provisioning when applicable ? >>> >> >> The focus is on provider provisioned VPNs, specially when it comes to >> controlling the membership of the VPN. This is not an API that is >> appropriate for the end-user application to interact with the network. >> For the later i'd recommend looking at the work of the ALTO working >> group. >> >> =A0 Pedro. >> >> > > From xuxiaohu@huawei.com Thu Nov 3 20:54:51 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 525DE11E8147 for ; Thu, 3 Nov 2011 20:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.324 X-Spam-Level: X-Spam-Status: No, score=-4.324 tagged_above=-999 required=5 tests=[AWL=1.075, 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 IonudnoPNL9f for ; Thu, 3 Nov 2011 20:54:50 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 739BE11E8096 for ; Thu, 3 Nov 2011 20:54:50 -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 <0LU400AUCAUTZH@szxga03-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 11:54:30 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU400A09ASGRJ@szxga03-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 11:54:29 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AET32882; Fri, 04 Nov 2011 11:54:29 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 11:54:20 +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, 04 Nov 2011 11:54:19 +0800 Date: Fri, 04 Nov 2011 03:54:18 +0000 From: Xuxiaohu Subject: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: X-Originating-IP: [10.108.4.59] To: Pedro Marques , Linda Dunbar Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmYl45yL3eYnpiEidbEIR6K802JWZ7vqAgAAdgYCAAMYSAIAADrIAgAAchwCAABMCAIABAL2A X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AQNN Aw8E CPc1 DQth FzzV Gdo3 HKyF IfZD NdMg Ork+ Os0/ TheT UAtu UUL4 W0bb XlEx; 2; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAcABlAGQAcgBvAC4AcgAuAG0AYQByAHEAdQBlAHMAQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {A925EAEE-BFD3-4820-906C-1BF97A696EE2}; eAB1AHgAaQBhAG8AaAB1AEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 04 Nov 2011 04:08:12 GMT; QQBwAHAAbABpAGMAYQB0AGkAbwBuACAAbwBmACAATAAzAFYAUABOACAAZgBvAHIAIABEAEMASQAvAC8AcgBlADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== x-cr-puzzleid: {A925EAEE-BFD3-4820-906C-1BF97A696EE2} X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> Cc: L3VPN WG mailing list 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, 04 Nov 2011 03:54:51 -0000 > There is a second reason why the data-center network topology is > virtualized which is the need to support VM moves. This implies that > the IP addresses used for communication between applications may be > anywhere across the data-center. Using a virtual topology is an > attractive way to solve this problem. I guess VM mobility is not the object for VPN4DC. For VM mobility across data centers, subnet extension at least is required so as to allow the IP addresses used for communication between applications to be anywhere across the data-centers. > Lots of people are trying to solve this problem with data-center wide > VLANs. Using data-center wide broadcast domains on top of IP multicast > and data-driven learning. I personally believe that using BGP-based > signaling is a more cost effective and scalable approach to solve this > problem. It is at least the only technology that has proven to scale > to the number of routes that are needed in such an application. Indeed, there is a BGP/MPLS IP VPN based solution for subnet extension (http://tools.ietf.org/html/draft-xu-virtual-subnet-06) which uses the proven L3VPN and APR proxy technologies. Although the subnet is stretched across multiple data centers, the MAC learning domain, unknown unicast/ARP flood domain associated with that subnet however are confined to each data center location. As a result, the scalability problems associated with the large Layer2 domain are eliminated. Meanwhile, since this solution is host route (L3) based, it can provide many other attractive benefits, such as path optimization (for inter-subnet traffic) and active-active data center exit, that traditional L2VPN technologies (e.g., VPLS) alone could never provide. According to L3VPN co-chairs' suggestion, I would like to solicit comments in this mailing-list on such application of L3VPN technology for data center interconnection. Best regards, Xiaohu > Pedro. From pedro.r.marques@gmail.com Thu Nov 3 21:13: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 C818D11E8089 for ; Thu, 3 Nov 2011 21:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.159, 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 mlIshIkFwL4P for ; Thu, 3 Nov 2011 21:13:45 -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 43CEA11E8081 for ; Thu, 3 Nov 2011 21:13:45 -0700 (PDT) Received: by iaeo4 with SMTP id o4so2698160iae.31 for ; Thu, 03 Nov 2011 21:13:44 -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=78gwaaSU7e9WlqzBJyGmxIfEGcU1Ica5pLoPZHTsoow=; b=U8/fe/OzTTOI5+Fr/7IjWBZbUFc3kT0qopvqtGg8Zcs7ZOF2vT341fGcFVi9pjV1pv sn5q7Q9Ezw72lkMDBuKbqFDGUVDccS55C6DIjfTXO8AkDaW9bKv3A+5oNIUH28I7omFL RUOkVmXsa0fwW3CFr23Q6dsOhZj7ogbUA4g60= MIME-Version: 1.0 Received: by 10.50.158.227 with SMTP id wx3mr8573525igb.52.1320380024708; Thu, 03 Nov 2011 21:13:44 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Thu, 3 Nov 2011 21:13:44 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> Date: Thu, 3 Nov 2011 21:13:44 -0700 Message-ID: Subject: Re: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda @ IETF82 From: Pedro Marques To: Xuxiaohu Content-Type: text/plain; charset=ISO-8859-1 Cc: L3VPN WG mailing list 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, 04 Nov 2011 04:13:45 -0000 Xiaohu, On Thu, Nov 3, 2011 at 8:54 PM, Xuxiaohu wrote: >> There is a second reason why the data-center network topology is >> virtualized which is the need to support VM moves. This implies that >> the IP addresses used for communication between applications may be >> anywhere across the data-center. Using a virtual topology is an >> attractive way to solve this problem. > > I guess VM mobility is not the object for VPN4DC. For VM mobility across data centers, subnet extension at least is required so as to allow the IP addresses used for communication between applications to be anywhere across the data-centers. There is no reason to think in terms of subnets. Given that there is no locality the concept of subnet no longer makes any sense. Thus one has a collection of host routes spread randomly across a large area. It is trivial to make all VM to VM communication routed. If you look at the details in the l3vpn-end-system proposal, packets are routed from the VM to the host-os and by the host-os which encapsulates the packets. The latter has a collection of host routes. Thinking in terms of subnets is not helpful, the concept is just not applicable. Using ARP, proxy or otherwise, is simply self inflicted pain and suffering. There is no reason to care about the mac address of the remote system. regards, Pedro. From lufang@cisco.com Thu Nov 3 22:20:52 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 93D8011E8081 for ; Thu, 3 Nov 2011 22:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.914 X-Spam-Level: X-Spam-Status: No, score=-4.914 tagged_above=-999 required=5 tests=[AWL=0.485, 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 iMGEKNF9+BNX for ; Thu, 3 Nov 2011 22:20:51 -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 7ABDB11E8073 for ; Thu, 3 Nov 2011 22:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=2075; q=dns/txt; s=iport; t=1320384051; x=1321593651; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DoLicLBvmDAW8E3T1xU9AHihsziHZ5Tx7L5MFE3BAXg=; b=GVLlzFdOiYoHsEM6wAmY785myUVFPtEW8J3hThkF9+b4M8gHkztzGgLW FL1BUCPFtfA/ZMo4JdaClXczH2Ot1RafIqpLJXHBs8lD2uMRCsb8/sLcS kDx2VsUTaSqFc2fTUwrNdtCcp39VPVICgAPAqKHTHV4tmVkYql95lUy/w g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwAAFp1s06tJXG+/2dsb2JhbABDmgiPfIEFgXIBAQEEEgEdCjQLDAQCAQgRBAEBAQoGFwEGAUUJCAEBBAESCBMHnhUBnkyIPWIEiAiRSoxJ X-IronPort-AV: E=Sophos;i="4.69,454,1315180800"; d="scan'208";a="33309926" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 04 Nov 2011 05:20:51 +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 pA45KoNQ022349; Fri, 4 Nov 2011 05:20:50 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, 4 Nov 2011 00:20:50 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: BObO BPQO BoxV CpI+ C2O7 D7Vi IcKd KxSh LaDN M5xh VZ2a WxWu XUSA Xm+Z Zcgc d4Dj; 3; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAcABlAGQAcgBvAC4AcgAuAG0AYQByAHEAdQBlAHMAQABnAG0AYQBpAGwALgBjAG8AbQA7AHgAdQB4AGkAYQBvAGgAdQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Sosha1_v1; 7; {17F32221-1500-4CB6-AE79-EBA7F89EC4E8}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Fri, 04 Nov 2011 05:20:40 GMT; UgBFADoAIABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABvAGYAIABMADMAVgBQAE4AIABmAG8AcgAgAEQAQwBJAC8ALwByAGUAOgAgAFAAcgBlAGwAaQBtAGkAbgBhAHIAeQAgAEwAMwBWAFAATgAvAFYAUABOADQARABDACAAYQBnAGUAbgBkAGEAQAAgAEkARQBUAEYAOAAyAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {17F32221-1500-4CB6-AE79-EBA7F89EC4E8} Content-class: urn:content-classes:message Subject: RE: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda@ IETF82 Date: Fri, 4 Nov 2011 00:20:40 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CA754@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda@ IETF82 Thread-Index: AcyaqCduT6sx5zTRSUCSCewxwHw2LwAAdBPQ References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx><238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com><4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx><4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx><1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> From: "Luyuan Fang (lufang)" To: "Pedro Marques" , "Xuxiaohu" X-OriginalArrivalTime: 04 Nov 2011 05:20:50.0401 (UTC) FILETIME=[84281510:01CC9AB1] Cc: L3VPN WG mailing list 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, 04 Nov 2011 05:20:52 -0000 Xiaohu, VM mobility is certainly in scope for VPN4DC, it would not be much use otherwise. There are large modern data centers running l3 only today, VM mobility goes without say, it works. Assume your draft is with l2vpn WG, as you called out "IP only L2VPN solution". Thanks, Luyuan > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Pedro Marques > Sent: Friday, November 04, 2011 12:14 AM > To: Xuxiaohu > Cc: L3VPN WG mailing list > Subject: Re: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC > agenda@ IETF82 >=20 > Xiaohu, >=20 > On Thu, Nov 3, 2011 at 8:54 PM, Xuxiaohu wrote: > >> There is a second reason why the data-center network topology is > >> virtualized which is the need to support VM moves. This implies that > >> the IP addresses used for communication between applications may be > >> anywhere across the data-center. Using a virtual topology is an > >> attractive way to solve this problem. > > > > I guess VM mobility is not the object for VPN4DC. For VM mobility > across data centers, subnet extension at least is required so as to > allow the IP addresses used for communication between applications to > be anywhere across the data-centers. >=20 > There is no reason to think in terms of subnets. Given that there is > no locality the concept of subnet no longer makes any sense. Thus one > has a collection of host routes spread randomly across a large area. >=20 > It is trivial to make all VM to VM communication routed. If you look > at the details in the l3vpn-end-system proposal, packets are routed > from the VM to the host-os and by the host-os which encapsulates the > packets. The latter has a collection of host routes. Thinking in terms > of subnets is not helpful, the concept is just not applicable. >=20 > Using ARP, proxy or otherwise, is simply self inflicted pain and > suffering. There is no reason to care about the mac address of the > remote system. >=20 > regards, > Pedro. From xuxiaohu@huawei.com Thu Nov 3 23:01: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 E10E611E808D for ; Thu, 3 Nov 2011 23:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=-1.304, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIaN+xgcSnaL for ; Thu, 3 Nov 2011 23:01:42 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 50E1211E8073 for ; Thu, 3 Nov 2011 23:01:42 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU400AUUGQMPH@szxga04-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 14:01:34 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU4006JJGQLVO@szxga04-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 14:01:34 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW24634; Fri, 04 Nov 2011 14:00:53 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 14:00:47 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 04 Nov 2011 14:00:48 +0800 Date: Fri, 04 Nov 2011 06:00:47 +0000 From: Xuxiaohu Subject: re: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda@ IETF82 In-reply-to: <238542D917511A45B6B8AA806E875E25073CA754@XMB-RCD-201.cisco.com> X-Originating-IP: [10.108.4.59] To: "Luyuan Fang (lufang)" , Pedro Marques Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D053@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda@ IETF82 Thread-index: AQHMmrGOILXiFPzge0SLRu2L8lR6TpWcNUOw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> <238542D917511A45B6B8AA806E875E25073CA754@XMB-RCD-201.cisco.com> Cc: L3VPN WG mailing list 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, 04 Nov 2011 06:01:44 -0000 THV5dWFuLA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IEx1eXVhbiBGYW5nIChs dWZhbmcpIFttYWlsdG86bHVmYW5nQGNpc2NvLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTHE6jEx1MI0 yNUgMTM6MjENCj4gytW8/sjLOiBQZWRybyBNYXJxdWVzOyBYdXhpYW9odQ0KPiCzrcvNOiBMM1ZQ TiBXRyBtYWlsaW5nIGxpc3QNCj4g1vfM4jogUkU6IEFwcGxpY2F0aW9uIG9mIEwzVlBOIGZvciBE Q0kvL3JlOiBQcmVsaW1pbmFyeSBMM1ZQTi9WUE40REMNCj4gYWdlbmRhQCBJRVRGODINCj4gDQo+ IFhpYW9odSwNCj4gDQo+IFZNIG1vYmlsaXR5IGlzIGNlcnRhaW5seSBpbiBzY29wZSBmb3IgVlBO NERDLCBpdCB3b3VsZCBub3QgYmUgbXVjaCB1c2UNCj4gb3RoZXJ3aXNlLg0KPiBUaGVyZSBhcmUg bGFyZ2UgbW9kZXJuIGRhdGEgY2VudGVycyBydW5uaW5nIGwzIG9ubHkgdG9kYXksIFZNIG1vYmls aXR5DQo+IGdvZXMgd2l0aG91dCBzYXksIGl0IHdvcmtzLg0KDQpPaCwgc29ycnksIGl0J3MgbXkg bWlzdW5kZXJzdGFuZGluZzopDQoNCj4gQXNzdW1lIHlvdXIgZHJhZnQgaXMgd2l0aCBsMnZwbiBX RywgYXMgeW91IGNhbGxlZCBvdXQgIklQIG9ubHkgTDJWUE4NCj4gc29sdXRpb24iLg0KDQpWaXJ0 dWFsIFN1Ym5ldCBpcyBhbiBhcHByb2FjaCBmb3Igc3VibmV0IGV4dGVuc2lvbiBieSB0aGUgdXNl IG9mIEwzVlBOIG9yIEFSUCBwcm94eSB0ZWNobm9sb2dpZXMuIFRvIHNvbWUgZXh0ZW5zaW9uLCBz dWJuZXQgZXh0ZW5zaW9uIGNvdWxkIGJlIHVuZGVyc3Rvb2QgYXMgYW4gSVAtb25seSBMMlZQTiBz ZXJ2aWNlIGR1ZSB0byB0aGUgZm9sbG93aW5nIHR3byByZWFzb25zOjEpIGZyb20gdGhlIHBlcnNw ZWN0aXZlIG9mIENFIGhvc3RzLCBzdWJuZXQgZXh0ZW5zaW9uIG1ha2VzIHRoZW0gYWN0IGFzIGlm IHRoZXkgYXJlIGxvY2F0ZWQgd2l0aGluIHRoZSBzYW1lIEwyVlBOIGluc3RhbmNlOjIpIG9ubHkg SVAgdHJhZmZpYyBpcyBhbGxvd2VkIHRvIGJlIHRyYW5zcG9ydGVkIGluIFZpcnR1YWwgU3VibmV0 Lg0KIA0KU2luY2UgaXQncyBhbiBhcHBsaWNhdGlvbiBvZiBMM1ZQTiBwcm90b2NvbCBhcyBhIGRh dGEgY2VudGVyIGludGVyY29ubmVjdGlvbiBzb2x1dGlvbiwgSSB0aGluayBpdCBzaG91bGQgYmUg dGFsa2VkIGF0IEwzVlBOIFdHLiANCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1IA0KDQo+IFRoYW5r cywNCj4gTHV5dWFuDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJv bTogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPiA+IE9mIFBlZHJvIE1hcnF1ZXMNCj4gPiBTZW50OiBGcmlkYXksIE5vdmVt YmVyIDA0LCAyMDExIDEyOjE0IEFNDQo+ID4gVG86IFh1eGlhb2h1DQo+ID4gQ2M6IEwzVlBOIFdH IG1haWxpbmcgbGlzdA0KPiA+IFN1YmplY3Q6IFJlOiBBcHBsaWNhdGlvbiBvZiBMM1ZQTiBmb3Ig RENJLy9yZTogUHJlbGltaW5hcnkNCj4gTDNWUE4vVlBONERDDQo+ID4gYWdlbmRhQCBJRVRGODIN Cj4gPg0KPiA+IFhpYW9odSwNCj4gPg0KPiA+IE9uIFRodSwgTm92IDMsIDIwMTEgYXQgODo1NCBQ TSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ID4+IFRoZXJlIGlz IGEgc2Vjb25kIHJlYXNvbiB3aHkgdGhlIGRhdGEtY2VudGVyIG5ldHdvcmsgdG9wb2xvZ3kgaXMN Cj4gPiA+PiB2aXJ0dWFsaXplZCB3aGljaCBpcyB0aGUgbmVlZCB0byBzdXBwb3J0IFZNIG1vdmVz LiBUaGlzIGltcGxpZXMNCj4gdGhhdA0KPiA+ID4+IHRoZSBJUCBhZGRyZXNzZXMgdXNlZCBmb3Ig Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIGFwcGxpY2F0aW9ucyBtYXkgYmUNCj4gPiA+PiBhbnl3aGVy ZSBhY3Jvc3MgdGhlIGRhdGEtY2VudGVyLiBVc2luZyBhIHZpcnR1YWwgdG9wb2xvZ3kgaXMgYW4N Cj4gPiA+PiBhdHRyYWN0aXZlIHdheSB0byBzb2x2ZSB0aGlzIHByb2JsZW0uDQo+ID4gPg0KPiA+ ID4gSSBndWVzcyBWTSBtb2JpbGl0eSBpcyBub3QgdGhlIG9iamVjdCBmb3IgVlBONERDLiBGb3Ig Vk0gbW9iaWxpdHkNCj4gPiBhY3Jvc3MgZGF0YSBjZW50ZXJzLCBzdWJuZXQgZXh0ZW5zaW9uIGF0 IGxlYXN0IGlzIHJlcXVpcmVkIHNvIGFzIHRvDQo+ID4gYWxsb3cgdGhlIElQIGFkZHJlc3NlcyB1 c2VkIGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gYXBwbGljYXRpb25zIHRvDQo+ID4gYmUgYW55 d2hlcmUgYWNyb3NzIHRoZSBkYXRhLWNlbnRlcnMuDQo+ID4NCj4gPiBUaGVyZSBpcyBubyByZWFz b24gdG8gdGhpbmsgaW4gdGVybXMgb2Ygc3VibmV0cy4gR2l2ZW4gdGhhdCB0aGVyZSBpcw0KPiA+ IG5vIGxvY2FsaXR5IHRoZSBjb25jZXB0IG9mIHN1Ym5ldCBubyBsb25nZXIgbWFrZXMgYW55IHNl bnNlLiBUaHVzIG9uZQ0KPiA+IGhhcyBhIGNvbGxlY3Rpb24gb2YgaG9zdCByb3V0ZXMgc3ByZWFk IHJhbmRvbWx5IGFjcm9zcyBhIGxhcmdlIGFyZWEuDQo+ID4NCj4gPiBJdCBpcyB0cml2aWFsIHRv IG1ha2UgYWxsIFZNIHRvIFZNIGNvbW11bmljYXRpb24gcm91dGVkLiBJZiB5b3UgbG9vaw0KPiA+ IGF0IHRoZSBkZXRhaWxzIGluIHRoZSBsM3Zwbi1lbmQtc3lzdGVtIHByb3Bvc2FsLCBwYWNrZXRz IGFyZSByb3V0ZWQNCj4gPiBmcm9tIHRoZSBWTSB0byB0aGUgaG9zdC1vcyBhbmQgYnkgdGhlIGhv c3Qtb3Mgd2hpY2ggZW5jYXBzdWxhdGVzIHRoZQ0KPiA+IHBhY2tldHMuIFRoZSBsYXR0ZXIgaGFz IGEgY29sbGVjdGlvbiBvZiBob3N0IHJvdXRlcy4gVGhpbmtpbmcgaW4gdGVybXMNCj4gPiBvZiBz dWJuZXRzIGlzIG5vdCBoZWxwZnVsLCB0aGUgY29uY2VwdCBpcyBqdXN0IG5vdCBhcHBsaWNhYmxl Lg0KPiA+DQo+ID4gVXNpbmcgQVJQLCBwcm94eSBvciBvdGhlcndpc2UsIGlzIHNpbXBseSBzZWxm IGluZmxpY3RlZCBwYWluIGFuZA0KPiA+IHN1ZmZlcmluZy4gVGhlcmUgaXMgbm8gcmVhc29uIHRv IGNhcmUgYWJvdXQgdGhlIG1hYyBhZGRyZXNzIG9mIHRoZQ0KPiA+IHJlbW90ZSBzeXN0ZW0uDQo+ ID4NCj4gPiByZWdhcmRzLA0KPiA+ICAgUGVkcm8uDQo= From xuxiaohu@huawei.com Thu Nov 3 23:38: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 32D9311E80AA for ; Thu, 3 Nov 2011 23:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.38 X-Spam-Level: X-Spam-Status: No, score=0.38 tagged_above=-999 required=5 tests=[AWL=-3.608, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k6AEHkimf-j for ; Thu, 3 Nov 2011 23:38:40 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8E411E80A0 for ; Thu, 3 Nov 2011 23:38:39 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU400BM4IF4A3@szxga05-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 14:37:53 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU400BBIIEYQC@szxga05-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 14:37:52 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AET44688; Fri, 04 Nov 2011 14:37:51 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 14:37:44 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Fri, 04 Nov 2011 14:37:40 +0800 Date: Fri, 04 Nov 2011 06:37:39 +0000 From: Xuxiaohu Subject: =?gb2312?B?tPC4tDogQXBwbGljYXRpb24gb2YgTDNWUE4gZm9yIERDSS8vcmU6IFByZWxp?= =?gb2312?Q?minary_L3VPN/VPN4DC_agenda=09@_IETF82?= In-reply-to: X-Originating-IP: [10.108.4.59] To: Pedro Marques Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D080@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmqgsFXMckaoVPUS38HFoVfrwNZWcPOKw X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: PXw= A09S CiGC DGlL DpFu E8VA FanS Fx18 Go2c LFXY MkBf M3cN OedX PbAH Qqga Re+c; 2; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAcABlAGQAcgBvAC4AcgAuAG0AYQByAHEAdQBlAHMAQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {F6C0257D-5A6F-48BC-A9A5-13C28BF1E637}; eAB1AHgAaQBhAG8AaAB1AEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 04 Nov 2011 06:51:36 GMT; VHsNWToAIABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABvAGYAIABMADMAVgBQAE4AIABmAG8AcgAgAEQAQwBJAC8ALwByAGUAOgAgAFAAcgBlAGwAaQBtAGkAbgBhAHIAeQAgAEwAMwBWAFAATgAvAFYAUABOADQARABDACAAYQBnAGUAbgBkAGEACQBAACAASQBFAFQARgA4ADIA x-cr-puzzleid: {F6C0257D-5A6F-48BC-A9A5-13C28BF1E637} X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> Cc: L3VPN WG mailing list 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, 04 Nov 2011 06:38:41 -0000 SGkgUGVkcm8sDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbDN2cG4tYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUGVkcm8NCj4g TWFycXVlcw0KPiC3osvNyrG85DogMjAxMcTqMTHUwjTI1SAxMjoxNA0KPiDK1bz+yMs6IFh1eGlh b2h1DQo+ILOty806IEwzVlBOIFdHIG1haWxpbmcgbGlzdA0KPiDW98ziOiBSZTogQXBwbGljYXRp b24gb2YgTDNWUE4gZm9yIERDSS8vcmU6IFByZWxpbWluYXJ5IEwzVlBOL1ZQTjREQyBhZ2VuZGEN Cj4gQCBJRVRGODINCj4gDQo+IFhpYW9odSwNCj4gDQo+IE9uIFRodSwgTm92IDMsIDIwMTEgYXQg ODo1NCBQTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+PiBUaGVy ZSBpcyBhIHNlY29uZCByZWFzb24gd2h5IHRoZSBkYXRhLWNlbnRlciBuZXR3b3JrIHRvcG9sb2d5 IGlzDQo+ID4+IHZpcnR1YWxpemVkIHdoaWNoIGlzIHRoZSBuZWVkIHRvIHN1cHBvcnQgVk0gbW92 ZXMuIFRoaXMgaW1wbGllcyB0aGF0DQo+ID4+IHRoZSBJUCBhZGRyZXNzZXMgdXNlZCBmb3IgY29t bXVuaWNhdGlvbiBiZXR3ZWVuIGFwcGxpY2F0aW9ucyBtYXkgYmUNCj4gPj4gYW55d2hlcmUgYWNy b3NzIHRoZSBkYXRhLWNlbnRlci4gVXNpbmcgYSB2aXJ0dWFsIHRvcG9sb2d5IGlzIGFuDQo+ID4+ IGF0dHJhY3RpdmUgd2F5IHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4NCj4gPg0KPiA+IEkgZ3Vlc3Mg Vk0gbW9iaWxpdHkgaXMgbm90IHRoZSBvYmplY3QgZm9yIFZQTjREQy4gRm9yIFZNIG1vYmlsaXR5 IGFjcm9zcw0KPiBkYXRhIGNlbnRlcnMsIHN1Ym5ldCBleHRlbnNpb24gYXQgbGVhc3QgaXMgcmVx dWlyZWQgc28gYXMgdG8gYWxsb3cgdGhlIElQDQo+IGFkZHJlc3NlcyB1c2VkIGZvciBjb21tdW5p Y2F0aW9uIGJldHdlZW4gYXBwbGljYXRpb25zIHRvIGJlIGFueXdoZXJlDQo+IGFjcm9zcyB0aGUg ZGF0YS1jZW50ZXJzLg0KPiANCj4gVGhlcmUgaXMgbm8gcmVhc29uIHRvIHRoaW5rIGluIHRlcm1z IG9mIHN1Ym5ldHMuIEdpdmVuIHRoYXQgdGhlcmUgaXMNCj4gbm8gbG9jYWxpdHkgdGhlIGNvbmNl cHQgb2Ygc3VibmV0IG5vIGxvbmdlciBtYWtlcyBhbnkgc2Vuc2UuIFRodXMgb25lDQo+IGhhcyBh IGNvbGxlY3Rpb24gb2YgaG9zdCByb3V0ZXMgc3ByZWFkIHJhbmRvbWx5IGFjcm9zcyBhIGxhcmdl IGFyZWEuDQoNCkl0J3MgcmVhbGx5IGEgc3VibmV0IHdoaWNoIGlzIGV4dGVuZGVkIGFjcm9zcyBk YXRhIGNlbnRlcnMgZnJvbSB0aGUgaG9zdHMnIHBvaW50cyBvZiB2aWV3LiBWaXJ0dWFsIFN1Ym5l dCBpcyBhbiBEQ0kgYXBwcm9hY2ggd2hpY2ggaXMgYmFzZWQgb24gdGhlIHByZS1yZXF1aXJlbWVu dCB0aGF0IGl0IHNob3VsZCBiZSB0cmFuc3BhcmVudCB0byB0aGUgaG9zdHMoaS5lLiwgc2VydmVy cy9WTXMpIGFuZCB0aGUgZGF0YSBjZW50ZXIgbmV0d29yaywgaW4gb3RoZXIgd29yZHMsIGl0IGRv ZXNuJ3QgcmVxdWlyZSBhbnkgY2hhbmdlIHRvIHRoZXNlIGRhdGEgY2VudGVyIGludGVybmFsIGVs ZW1lbnRzLCBlc3BlY2lhbGx5IGhvc3RzLiBPZiBjb3Vyc2UsIGlmIHlvdSB3YW50IHRvIGV4dGVu ZCB0aGUgTDNWUE4gUEUgZnVuY3Rpb25zIHRvIHRoZSBob3N0cyB3aXRoaW4gdGhlIGNsb3VkIGRh dGEgY2VudGVycywgaXQncyBhbm90aGVyIHRoaW5nLg0KDQo+IEl0IGlzIHRyaXZpYWwgdG8gbWFr ZSBhbGwgVk0gdG8gVk0gY29tbXVuaWNhdGlvbiByb3V0ZWQuIElmIHlvdSBsb29rDQo+IGF0IHRo ZSBkZXRhaWxzIGluIHRoZSBsM3Zwbi1lbmQtc3lzdGVtIHByb3Bvc2FsLCBwYWNrZXRzIGFyZSBy b3V0ZWQNCj4gZnJvbSB0aGUgVk0gdG8gdGhlIGhvc3Qtb3MgYW5kIGJ5IHRoZSBob3N0LW9zIHdo aWNoIGVuY2Fwc3VsYXRlcyB0aGUNCj4gcGFja2V0cy4gVGhlIGxhdHRlciBoYXMgYSBjb2xsZWN0 aW9uIG9mIGhvc3Qgcm91dGVzLiBUaGlua2luZyBpbiB0ZXJtcw0KPiBvZiBzdWJuZXRzIGlzIG5v dCBoZWxwZnVsLCB0aGUgY29uY2VwdCBpcyBqdXN0IG5vdCBhcHBsaWNhYmxlLg0KDQpJIHRoaW5r IHlvdXIgYXBwcm9hY2ggd29ya3MuIEhvd2V2ZXIsIGVhY2ggYXBwcm9hY2ggZWl0aGVyIGhvc3Qt YmFzZWQgb3IgbmV0d29yay1iYXNlZCBoYXMgaXRzIG93biBwcm9zIGFuZCBjb25zLiANCg0KPiBV c2luZyBBUlAsIHByb3h5IG9yIG90aGVyd2lzZSwgaXMgc2ltcGx5IHNlbGYgaW5mbGljdGVkIHBh aW4gYW5kDQo+IHN1ZmZlcmluZy4gVGhlcmUgaXMgbm8gcmVhc29uIHRvIGNhcmUgYWJvdXQgdGhl IG1hYyBhZGRyZXNzIG9mIHRoZQ0KPiByZW1vdGUgc3lzdGVtLg0KDQpJbiBmYWN0LCBpbiB0aGUg VmlydHVhbCBTdWJuZXQsIFZNcyBpbiBvbmUgZGF0YSBjZW50ZXIgZG9uJ3QgY2FyZSBhYm91dCB0 aGUgcmVhbCBNQUMgYWRkcmVzc2VzIG9mIHRoZSByZW1vdGUgVk1zIGluIG90aGVyIGRhdGEgY2Vu dGVyIGR1ZSB0byB0aGUgdXNhZ2Ugb2YgQVJQIHByb3h5OikgDQoNCkJlc3QgcmVnYXJkcywNClhp YW9odQ0KDQo+IHJlZ2FyZHMsDQo+ICAgUGVkcm8uDQo= From xuxiaohu@huawei.com Fri Nov 4 00:07: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 29B6011E80AA for ; Fri, 4 Nov 2011 00:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.681 X-Spam-Level: X-Spam-Status: No, score=0.681 tagged_above=-999 required=5 tests=[AWL=-3.307, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1jnwtdDbGwz for ; Fri, 4 Nov 2011 00:07:26 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 80C7811E80A0 for ; Fri, 4 Nov 2011 00:07:26 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU4002SKJRKOR@szxga05-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 15:06:56 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU400K5DJRJFG@szxga05-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 15:06:56 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW27106; Fri, 04 Nov 2011 15:06:16 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 15:06:09 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Fri, 04 Nov 2011 15:06:06 +0800 Date: Fri, 04 Nov 2011 07:06:06 +0000 From: Xuxiaohu Subject: =?gb2312?B?tPC4tDogQXBwbGljYXRpb24gb2YgTDNWUE4gZm9yIERDSS8vcmU6IFByZWxp?= =?gb2312?Q?minary_L3VPN/VPN4DC_agenda=09@_IETF82?= In-reply-to: X-Originating-IP: [10.108.4.59] To: Pedro Marques Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D09D@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmqgsFXMckaoVPUS38HFoVfrwNZWcSwXQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> Cc: L3VPN WG mailing list 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, 04 Nov 2011 07:07:27 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFBlZHJvDQo+IE1hcnF1ZXMNCj4g t6LLzcqxvOQ6IDIwMTHE6jEx1MI0yNUgMTI6MTQNCj4gytW8/sjLOiBYdXhpYW9odQ0KPiCzrcvN OiBMM1ZQTiBXRyBtYWlsaW5nIGxpc3QNCj4g1vfM4jogUmU6IEFwcGxpY2F0aW9uIG9mIEwzVlBO IGZvciBEQ0kvL3JlOiBQcmVsaW1pbmFyeSBMM1ZQTi9WUE40REMgYWdlbmRhDQo+IEAgSUVURjgy DQo+IA0KPiBYaWFvaHUsDQo+IA0KPiBPbiBUaHUsIE5vdiAzLCAyMDExIGF0IDg6NTQgUE0sIFh1 eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPj4gVGhlcmUgaXMgYSBzZWNv bmQgcmVhc29uIHdoeSB0aGUgZGF0YS1jZW50ZXIgbmV0d29yayB0b3BvbG9neSBpcw0KPiA+PiB2 aXJ0dWFsaXplZCB3aGljaCBpcyB0aGUgbmVlZCB0byBzdXBwb3J0IFZNIG1vdmVzLiBUaGlzIGlt cGxpZXMgdGhhdA0KPiA+PiB0aGUgSVAgYWRkcmVzc2VzIHVzZWQgZm9yIGNvbW11bmljYXRpb24g YmV0d2VlbiBhcHBsaWNhdGlvbnMgbWF5IGJlDQo+ID4+IGFueXdoZXJlIGFjcm9zcyB0aGUgZGF0 YS1jZW50ZXIuIFVzaW5nIGEgdmlydHVhbCB0b3BvbG9neSBpcyBhbg0KPiA+PiBhdHRyYWN0aXZl IHdheSB0byBzb2x2ZSB0aGlzIHByb2JsZW0uDQo+ID4NCj4gPiBJIGd1ZXNzIFZNIG1vYmlsaXR5 IGlzIG5vdCB0aGUgb2JqZWN0IGZvciBWUE40REMuIEZvciBWTSBtb2JpbGl0eSBhY3Jvc3MNCj4g ZGF0YSBjZW50ZXJzLCBzdWJuZXQgZXh0ZW5zaW9uIGF0IGxlYXN0IGlzIHJlcXVpcmVkIHNvIGFz IHRvIGFsbG93IHRoZSBJUA0KPiBhZGRyZXNzZXMgdXNlZCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3 ZWVuIGFwcGxpY2F0aW9ucyB0byBiZSBhbnl3aGVyZQ0KPiBhY3Jvc3MgdGhlIGRhdGEtY2VudGVy cy4NCj4gDQo+IFRoZXJlIGlzIG5vIHJlYXNvbiB0byB0aGluayBpbiB0ZXJtcyBvZiBzdWJuZXRz LiBHaXZlbiB0aGF0IHRoZXJlIGlzDQo+IG5vIGxvY2FsaXR5IHRoZSBjb25jZXB0IG9mIHN1Ym5l dCBubyBsb25nZXIgbWFrZXMgYW55IHNlbnNlLiBUaHVzIG9uZQ0KPiBoYXMgYSBjb2xsZWN0aW9u IG9mIGhvc3Qgcm91dGVzIHNwcmVhZCByYW5kb21seSBhY3Jvc3MgYSBsYXJnZSBhcmVhLg0KPiAN Cj4gSXQgaXMgdHJpdmlhbCB0byBtYWtlIGFsbCBWTSB0byBWTSBjb21tdW5pY2F0aW9uIHJvdXRl ZC4gSWYgeW91IGxvb2sNCj4gYXQgdGhlIGRldGFpbHMgaW4gdGhlIGwzdnBuLWVuZC1zeXN0ZW0g cHJvcG9zYWwsIHBhY2tldHMgYXJlIHJvdXRlZA0KDQpBZnRlciByZWFkaW5nIHlvdXIgbDN2cG4t ZW5kLXN5c3RlbSBwcm9wb3NhbCBhdCBhIGdsYW5jZSwgSSBmZWx0IHRoYXQgYm90aCBsM3Zwbi1l bmQtc3lzdGVtIHByb3Bvc2FsIGFuZCBWaXJ0dWFsIFN1Ym5ldCBwcm9wb3NhbCBhcmUgdXNpbmcg TDNWUE4gdG8gZXhjaGFuZ2UgaG9zdCByb3V0ZXMgd2hpbGUgdGhlIG1ham9yIGRpZmZlcmVuY2Ug aXMgdGhhdCB5b3VyIHByb3Bvc2FsIGV4cGVjdHMgdG8gZXh0ZW5kIHRoZSBQRSBmdW5jdGlvbnMg dG8gdGhlIGhvc3RzIGFuZCBteSBwcm9wb3NhbCBpbnRlbmRzIHRvIHJldGFpbiB0aGUgUEUgZnVu Y3Rpb25zIG9uIHRoZSByb3V0ZXJzLiBJdCdzIGludGVyZXN0aW5nOikNCg0KQmVzdCByZWdhcmRz LA0KWGlhb2h1DQoNCj4gZnJvbSB0aGUgVk0gdG8gdGhlIGhvc3Qtb3MgYW5kIGJ5IHRoZSBob3N0 LW9zIHdoaWNoIGVuY2Fwc3VsYXRlcyB0aGUNCj4gcGFja2V0cy4gVGhlIGxhdHRlciBoYXMgYSBj b2xsZWN0aW9uIG9mIGhvc3Qgcm91dGVzLiBUaGlua2luZyBpbiB0ZXJtcw0KPiBvZiBzdWJuZXRz IGlzIG5vdCBoZWxwZnVsLCB0aGUgY29uY2VwdCBpcyBqdXN0IG5vdCBhcHBsaWNhYmxlLg0KPiAN Cj4gVXNpbmcgQVJQLCBwcm94eSBvciBvdGhlcndpc2UsIGlzIHNpbXBseSBzZWxmIGluZmxpY3Rl ZCBwYWluIGFuZA0KPiBzdWZmZXJpbmcuIFRoZXJlIGlzIG5vIHJlYXNvbiB0byBjYXJlIGFib3V0 IHRoZSBtYWMgYWRkcmVzcyBvZiB0aGUNCj4gcmVtb3RlIHN5c3RlbS4NCj4gDQo+IHJlZ2FyZHMs DQo+ICAgUGVkcm8uDQo= From xuxiaohu@huawei.com Fri Nov 4 01:39: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 5AF5321F8A7B for ; Fri, 4 Nov 2011 01:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmH-uBH0aib6 for ; Fri, 4 Nov 2011 01:39:57 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 72B7221F8A7A for ; Fri, 4 Nov 2011 01:39:57 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU400EQHNY57R@szxga05-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 16:37:17 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU4008Q9NY4D0@szxga05-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 16:37:17 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AET59210; Fri, 04 Nov 2011 16:37:16 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 16:37:03 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 04 Nov 2011 16:37:08 +0800 Date: Fri, 04 Nov 2011 08:37:08 +0000 From: Xuxiaohu Subject: re: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D09D@szxeml525-mbs.china.huawei.com> X-Originating-IP: [10.108.4.59] To: Pedro Marques Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D0E6@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmqgsFXMckaoVPUS38HFoVfrwNZWcSwXQgAAbKlA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D09D@szxeml525-mbs.china.huawei.com> Cc: L3VPN WG mailing list 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, 04 Nov 2011 08:39:58 -0000 UGVkcm8sDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbDN2cG4tYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gWHV4aWFvaHUN Cj4gt6LLzcqxvOQ6IDIwMTHE6jEx1MI0yNUgMTU6MDYNCj4gytW8/sjLOiBQZWRybyBNYXJxdWVz DQo+ILOty806IEwzVlBOIFdHIG1haWxpbmcgbGlzdA0KPiDW98ziOiC08Li0OiBBcHBsaWNhdGlv biBvZiBMM1ZQTiBmb3IgRENJLy9yZTogUHJlbGltaW5hcnkgTDNWUE4vVlBONERDDQo+IGFnZW5k YSBAIElFVEY4Mg0KPiANCj4gDQo+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiBs M3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gtPqx 7Q0KPiBQZWRybw0KPiA+IE1hcnF1ZXMNCj4gPiC3osvNyrG85DogMjAxMcTqMTHUwjTI1SAxMjox NA0KPiA+IMrVvP7IyzogWHV4aWFvaHUNCj4gPiCzrcvNOiBMM1ZQTiBXRyBtYWlsaW5nIGxpc3QN Cj4gPiDW98ziOiBSZTogQXBwbGljYXRpb24gb2YgTDNWUE4gZm9yIERDSS8vcmU6IFByZWxpbWlu YXJ5IEwzVlBOL1ZQTjREQw0KPiBhZ2VuZGENCj4gPiBAIElFVEY4Mg0KPiA+DQo+ID4gWGlhb2h1 LA0KPiA+DQo+ID4gT24gVGh1LCBOb3YgMywgMjAxMSBhdCA4OjU0IFBNLCBYdXhpYW9odSA8eHV4 aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gPj4gVGhlcmUgaXMgYSBzZWNvbmQgcmVhc29u IHdoeSB0aGUgZGF0YS1jZW50ZXIgbmV0d29yayB0b3BvbG9neSBpcw0KPiA+ID4+IHZpcnR1YWxp emVkIHdoaWNoIGlzIHRoZSBuZWVkIHRvIHN1cHBvcnQgVk0gbW92ZXMuIFRoaXMgaW1wbGllcyB0 aGF0DQo+ID4gPj4gdGhlIElQIGFkZHJlc3NlcyB1c2VkIGZvciBjb21tdW5pY2F0aW9uIGJldHdl ZW4gYXBwbGljYXRpb25zIG1heSBiZQ0KPiA+ID4+IGFueXdoZXJlIGFjcm9zcyB0aGUgZGF0YS1j ZW50ZXIuIFVzaW5nIGEgdmlydHVhbCB0b3BvbG9neSBpcyBhbg0KPiA+ID4+IGF0dHJhY3RpdmUg d2F5IHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4NCj4gPiA+DQo+ID4gPiBJIGd1ZXNzIFZNIG1vYmls aXR5IGlzIG5vdCB0aGUgb2JqZWN0IGZvciBWUE40REMuIEZvciBWTSBtb2JpbGl0eSBhY3Jvc3MN Cj4gPiBkYXRhIGNlbnRlcnMsIHN1Ym5ldCBleHRlbnNpb24gYXQgbGVhc3QgaXMgcmVxdWlyZWQg c28gYXMgdG8gYWxsb3cgdGhlIElQDQo+ID4gYWRkcmVzc2VzIHVzZWQgZm9yIGNvbW11bmljYXRp b24gYmV0d2VlbiBhcHBsaWNhdGlvbnMgdG8gYmUgYW55d2hlcmUNCj4gPiBhY3Jvc3MgdGhlIGRh dGEtY2VudGVycy4NCj4gPg0KPiA+IFRoZXJlIGlzIG5vIHJlYXNvbiB0byB0aGluayBpbiB0ZXJt cyBvZiBzdWJuZXRzLiBHaXZlbiB0aGF0IHRoZXJlIGlzDQo+ID4gbm8gbG9jYWxpdHkgdGhlIGNv bmNlcHQgb2Ygc3VibmV0IG5vIGxvbmdlciBtYWtlcyBhbnkgc2Vuc2UuIFRodXMgb25lDQo+ID4g aGFzIGEgY29sbGVjdGlvbiBvZiBob3N0IHJvdXRlcyBzcHJlYWQgcmFuZG9tbHkgYWNyb3NzIGEg bGFyZ2UgYXJlYS4NCj4gPg0KPiA+IEl0IGlzIHRyaXZpYWwgdG8gbWFrZSBhbGwgVk0gdG8gVk0g Y29tbXVuaWNhdGlvbiByb3V0ZWQuIElmIHlvdSBsb29rDQo+ID4gYXQgdGhlIGRldGFpbHMgaW4g dGhlIGwzdnBuLWVuZC1zeXN0ZW0gcHJvcG9zYWwsIHBhY2tldHMgYXJlIHJvdXRlZA0KPiANCj4g QWZ0ZXIgcmVhZGluZyB5b3VyIGwzdnBuLWVuZC1zeXN0ZW0gcHJvcG9zYWwgYXQgYSBnbGFuY2Us IEkgZmVsdCB0aGF0IGJvdGgNCj4gbDN2cG4tZW5kLXN5c3RlbSBwcm9wb3NhbCBhbmQgVmlydHVh bCBTdWJuZXQgcHJvcG9zYWwgYXJlIHVzaW5nIEwzVlBOIHRvDQo+IGV4Y2hhbmdlIGhvc3Qgcm91 dGVzIHdoaWxlIHRoZSBtYWpvciBkaWZmZXJlbmNlIGlzIHRoYXQgeW91ciBwcm9wb3NhbCBleHBl Y3RzDQo+IHRvIGV4dGVuZCB0aGUgUEUgZnVuY3Rpb25zIHRvIHRoZSBob3N0cyBhbmQgbXkgcHJv cG9zYWwgaW50ZW5kcyB0byByZXRhaW4gdGhlDQo+IFBFIGZ1bmN0aW9ucyBvbiB0aGUgcm91dGVy cy4gSXQncyBpbnRlcmVzdGluZzopDQoNCkJ5IHRoZSB3YXksIGhhdmUgeW91IGNvbnNpZGVyZWQg dGhlIHNjZW5hcmlvIHdoZXJlIHNlcnZlcnMgaW4gb25lIGRhdGEgY2VudGVyIHNpdGUgYXJlIHVw Z3JhZGVkIHRvIHN1cHBvcnQgbDN2cG4tZW5kLXN5c3RlbSBwcm9wb3NhbCB3aGlsZSBzZXJ2ZXJz IGluIHRoZSBvdGhlciBkYXRhIGNlbnRlciBzaXRlIChlLmcuLCBMYXllcjIgZGF0YSBjZW50ZXIp IGFyZSBub3Q/IEhvdyB0byBzdXBwb3J0IFZNIG1vYmlsaXR5IGFjcm9zcyB0aGVzZSB0d28gZGF0 YSBjZW50ZXJzPw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCj4gDQo+ID4gZnJvbSB0aGUgVk0g dG8gdGhlIGhvc3Qtb3MgYW5kIGJ5IHRoZSBob3N0LW9zIHdoaWNoIGVuY2Fwc3VsYXRlcyB0aGUN Cj4gPiBwYWNrZXRzLiBUaGUgbGF0dGVyIGhhcyBhIGNvbGxlY3Rpb24gb2YgaG9zdCByb3V0ZXMu IFRoaW5raW5nIGluIHRlcm1zDQo+ID4gb2Ygc3VibmV0cyBpcyBub3QgaGVscGZ1bCwgdGhlIGNv bmNlcHQgaXMganVzdCBub3QgYXBwbGljYWJsZS4NCj4gPg0KPiA+IFVzaW5nIEFSUCwgcHJveHkg b3Igb3RoZXJ3aXNlLCBpcyBzaW1wbHkgc2VsZiBpbmZsaWN0ZWQgcGFpbiBhbmQNCj4gPiBzdWZm ZXJpbmcuIFRoZXJlIGlzIG5vIHJlYXNvbiB0byBjYXJlIGFib3V0IHRoZSBtYWMgYWRkcmVzcyBv ZiB0aGUNCj4gPiByZW1vdGUgc3lzdGVtLg0KPiA+DQo+ID4gcmVnYXJkcywNCj4gPiAgIFBlZHJv Lg0K From xuxiaohu@huawei.com Fri Nov 4 02:13: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 94A5321F8B7B for ; Fri, 4 Nov 2011 02:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.98 X-Spam-Level: X-Spam-Status: No, score=0.98 tagged_above=-999 required=5 tests=[AWL=-3.008, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNGd2x2pIFx6 for ; Fri, 4 Nov 2011 02:13:48 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C20B221F8ABE for ; Fri, 4 Nov 2011 02:13:47 -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 <0LU4005C9PKIEB@szxga03-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 17:12:18 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU400KU7PI74W@szxga03-in.huawei.com> for l3vpn@ietf.org; Fri, 04 Nov 2011 17:12:18 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AET63859; Fri, 04 Nov 2011 17:12:17 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 17:12:04 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Fri, 04 Nov 2011 17:12:05 +0800 Date: Fri, 04 Nov 2011 09:12:04 +0000 From: Xuxiaohu Subject: =?gb2312?B?tPC4tDogQXBwbGljYXRpb24gb2YgTDNWUE4gZm9yIERDSS8vcmU6IFByZWxp?= =?gb2312?Q?minary_L3VPN/VPN4DC_agenda=09@_IETF82?= X-Originating-IP: [10.108.4.59] To: Pedro Marques Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D107@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMmqgsFXMckaoVPUS38HFoVfrwNZWcSwXQgAAkkZA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> Cc: L3VPN WG mailing list 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, 04 Nov 2011 09:13:48 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IFh1eGlhb2h1DQo+ILeiy83KsbzkOiAy MDExxOoxMdTCNMjVIDE1OjIwDQo+IMrVvP7IyzogJ1BlZHJvIE1hcnF1ZXMnDQo+ILOty806IEwz VlBOIFdHIG1haWxpbmcgbGlzdA0KPiDW98ziOiC08Li0OiBBcHBsaWNhdGlvbiBvZiBMM1ZQTiBm b3IgRENJLy9yZTogUHJlbGltaW5hcnkgTDNWUE4vVlBONERDDQo+IGFnZW5kYSBAIElFVEY4Mg0K PiANCj4gDQo+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiBsM3Zwbi1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0KPiBQZWRybw0K PiA+IE1hcnF1ZXMNCj4gPiC3osvNyrG85DogMjAxMcTqMTHUwjTI1SAxMjoxNA0KPiA+IMrVvP7I yzogWHV4aWFvaHUNCj4gPiCzrcvNOiBMM1ZQTiBXRyBtYWlsaW5nIGxpc3QNCj4gPiDW98ziOiBS ZTogQXBwbGljYXRpb24gb2YgTDNWUE4gZm9yIERDSS8vcmU6IFByZWxpbWluYXJ5IEwzVlBOL1ZQ TjREQw0KPiBhZ2VuZGENCj4gPiBAIElFVEY4Mg0KPiA+DQo+ID4gWGlhb2h1LA0KPiA+DQo+ID4g T24gVGh1LCBOb3YgMywgMjAxMSBhdCA4OjU0IFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2Vp LmNvbT4gd3JvdGU6DQo+ID4gPj4gVGhlcmUgaXMgYSBzZWNvbmQgcmVhc29uIHdoeSB0aGUgZGF0 YS1jZW50ZXIgbmV0d29yayB0b3BvbG9neSBpcw0KPiA+ID4+IHZpcnR1YWxpemVkIHdoaWNoIGlz IHRoZSBuZWVkIHRvIHN1cHBvcnQgVk0gbW92ZXMuIFRoaXMgaW1wbGllcyB0aGF0DQo+ID4gPj4g dGhlIElQIGFkZHJlc3NlcyB1c2VkIGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gYXBwbGljYXRp b25zIG1heSBiZQ0KPiA+ID4+IGFueXdoZXJlIGFjcm9zcyB0aGUgZGF0YS1jZW50ZXIuIFVzaW5n IGEgdmlydHVhbCB0b3BvbG9neSBpcyBhbg0KPiA+ID4+IGF0dHJhY3RpdmUgd2F5IHRvIHNvbHZl IHRoaXMgcHJvYmxlbS4NCj4gPiA+DQo+ID4gPiBJIGd1ZXNzIFZNIG1vYmlsaXR5IGlzIG5vdCB0 aGUgb2JqZWN0IGZvciBWUE40REMuIEZvciBWTSBtb2JpbGl0eSBhY3Jvc3MNCj4gPiBkYXRhIGNl bnRlcnMsIHN1Ym5ldCBleHRlbnNpb24gYXQgbGVhc3QgaXMgcmVxdWlyZWQgc28gYXMgdG8gYWxs b3cgdGhlIElQDQo+ID4gYWRkcmVzc2VzIHVzZWQgZm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiBh cHBsaWNhdGlvbnMgdG8gYmUgYW55d2hlcmUNCj4gPiBhY3Jvc3MgdGhlIGRhdGEtY2VudGVycy4N Cj4gPg0KPiA+IFRoZXJlIGlzIG5vIHJlYXNvbiB0byB0aGluayBpbiB0ZXJtcyBvZiBzdWJuZXRz LiBHaXZlbiB0aGF0IHRoZXJlIGlzDQo+ID4gbm8gbG9jYWxpdHkgdGhlIGNvbmNlcHQgb2Ygc3Vi bmV0IG5vIGxvbmdlciBtYWtlcyBhbnkgc2Vuc2UuIFRodXMgb25lDQo+ID4gaGFzIGEgY29sbGVj dGlvbiBvZiBob3N0IHJvdXRlcyBzcHJlYWQgcmFuZG9tbHkgYWNyb3NzIGEgbGFyZ2UgYXJlYS4N Cj4gPg0KPiA+IEl0IGlzIHRyaXZpYWwgdG8gbWFrZSBhbGwgVk0gdG8gVk0gY29tbXVuaWNhdGlv biByb3V0ZWQuIElmIHlvdSBsb29rDQo+ID4gYXQgdGhlIGRldGFpbHMgaW4gdGhlIGwzdnBuLWVu ZC1zeXN0ZW0gcHJvcG9zYWwsIHBhY2tldHMgYXJlIHJvdXRlZA0KPiANCj4gQWZ0ZXIgcmVhZGlu ZyB5b3VyIGwzdnBuLWVuZC1zeXN0ZW0gcHJvcG9zYWwgYXQgYSBnbGFuY2UsIEkgZmVsdCB0aGF0 IGJvdGgNCj4gbDN2cG4tZW5kLXN5c3RlbSBwcm9wb3NhbCBhbmQgVmlydHVhbCBTdWJuZXQgcHJv cG9zYWwgYXJlIHVzaW5nIEwzVlBOIHRvDQo+IGV4Y2hhbmdlIGhvc3Qgcm91dGVzIHdoaWxlIHRo ZSBtYWpvciBkaWZmZXJlbmNlIGlzIHRoYXQgeW91ciBwcm9wb3NhbCBleHBlY3RzDQo+IHRvIGV4 dGVuZCB0aGUgUEUgZnVuY3Rpb25zIHRvIHRoZSBob3N0cyBhbmQgbXkgcHJvcG9zYWwgaW50ZW5k cyB0byByZXRhaW4gdGhlDQo+IFBFIGZ1bmN0aW9ucyBvbiB0aGUgcm91dGVycy4gSXQncyBpbnRl cmVzdGluZzopDQoNCkFoYSwgaWYgdGhlIGRhdGEgY2VudGVyIG9wZXJhdG9ycyB3b3VsZCBsaWtl IHRvIHBlcmZvcm0gdGhlIFBFIGZ1bmN0aW9ucyBvZiBWaXJ0dWFsIFN1Ym5ldCBhdCBUb1Igc3dp dGNoZXMsIGl0IHNlZW1zIGFsbW9zdCBubyBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgdHdvIHBy b3Bvc2FscyBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBlZmZlY3QuIA0KDQpCZXN0IHJlZ2FyZHMs DQpYaWFvaHUNCj4gDQo+ID4gZnJvbSB0aGUgVk0gdG8gdGhlIGhvc3Qtb3MgYW5kIGJ5IHRoZSBo b3N0LW9zIHdoaWNoIGVuY2Fwc3VsYXRlcyB0aGUNCj4gPiBwYWNrZXRzLiBUaGUgbGF0dGVyIGhh cyBhIGNvbGxlY3Rpb24gb2YgaG9zdCByb3V0ZXMuIFRoaW5raW5nIGluIHRlcm1zDQo+ID4gb2Yg c3VibmV0cyBpcyBub3QgaGVscGZ1bCwgdGhlIGNvbmNlcHQgaXMganVzdCBub3QgYXBwbGljYWJs ZS4NCj4gPg0KPiA+IFVzaW5nIEFSUCwgcHJveHkgb3Igb3RoZXJ3aXNlLCBpcyBzaW1wbHkgc2Vs ZiBpbmZsaWN0ZWQgcGFpbiBhbmQNCj4gPiBzdWZmZXJpbmcuIFRoZXJlIGlzIG5vIHJlYXNvbiB0 byBjYXJlIGFib3V0IHRoZSBtYWMgYWRkcmVzcyBvZiB0aGUNCj4gPiByZW1vdGUgc3lzdGVtLg0K PiA+DQo+ID4gcmVnYXJkcywNCj4gPiAgIFBlZHJvLg0K From pedro.r.marques@gmail.com Fri Nov 4 09:15: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 27D8D21F8CA9 for ; Fri, 4 Nov 2011 09:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.27 X-Spam-Level: * X-Spam-Status: No, score=1.27 tagged_above=-999 required=5 tests=[AWL=-3.965, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmB0rVZDBkZt for ; Fri, 4 Nov 2011 09:15:10 -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 8230E21F8BAB for ; Fri, 4 Nov 2011 09:15:10 -0700 (PDT) Received: by iaeo4 with SMTP id o4so3536812iae.31 for ; Fri, 04 Nov 2011 09:15:10 -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=McqkwSeghMxLCSD69yOvsjX2lkVKkUoGnFyRW1gybb8=; b=ilQ6IlvpxCLVTEds+zhiQqMg70hKUZ8SKkHbzxKrPcdR6XVIHIKex+jkTlhuhzQngY 30521+Rxh7+i+DiAcJYX/nUilMhNpMrkJR1gqDYTheyWlNAPEXCdtyowWo+Zyn8Bezuf qcbBqvzr/W7PNnB9GtYtMu0hx/AyE8K0CDByk= MIME-Version: 1.0 Received: by 10.231.28.209 with SMTP id n17mr3812961ibc.89.1320423310213; Fri, 04 Nov 2011 09:15:10 -0700 (PDT) Received: by 10.231.37.140 with HTTP; Fri, 4 Nov 2011 09:15:09 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D107@szxeml525-mbs.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D107@szxeml525-mbs.china.huawei.com> Date: Fri, 4 Nov 2011 09:15:09 -0700 Message-ID: Subject: =?GB2312?Q?Re=3A_=B4=F0=B8=B4=3A_Application_of_L3VPN_for_DCI=2F=2Fre=3A_Prelim?= =?GB2312?Q?inary_L3VPN=2FVPN4DC_agenda_=40_IETF82?= From: Pedro Marques To: Xuxiaohu Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: L3VPN WG mailing list 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, 04 Nov 2011 16:15:11 -0000 Xiaohu, You are correct, the difference between the l3vpn-end-system proposal and current l3vpn deployments is the fact that the forwarding information regarding the overlay network is entirely pushed to the edge. In that scenario the data center fabric has no knowledge of the overlay network. Whether the later is important depends on assumptions of scale and how scale impacts the economics of network devices. Pedro. 2011/11/4 Xuxiaohu : > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Xuxiaohu >> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C24=C8=D5 15:20 >> =CA=D5=BC=FE=C8=CB: 'Pedro Marques' >> =B3=AD=CB=CD: L3VPN WG mailing list >> =D6=F7=CC=E2: =B4=F0=B8=B4: Application of L3VPN for DCI//re: Preliminar= y L3VPN/VPN4DC >> agenda @ IETF82 >> >> >> > -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> > =B7=A2=BC=FE=C8=CB: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.= org] =B4=FA=B1=ED >> Pedro >> > Marques >> > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C24=C8=D5 12:14 >> > =CA=D5=BC=FE=C8=CB: Xuxiaohu >> > =B3=AD=CB=CD: L3VPN WG mailing list >> > =D6=F7=CC=E2: Re: Application of L3VPN for DCI//re: Preliminary L3VPN/= VPN4DC >> agenda >> > @ IETF82 >> > >> > Xiaohu, >> > >> > On Thu, Nov 3, 2011 at 8:54 PM, Xuxiaohu wrote: >> > >> There is a second reason why the data-center network topology is >> > >> virtualized which is the need to support VM moves. This implies tha= t >> > >> the IP addresses used for communication between applications may be >> > >> anywhere across the data-center. Using a virtual topology is an >> > >> attractive way to solve this problem. >> > > >> > > I guess VM mobility is not the object for VPN4DC. For VM mobility ac= ross >> > data centers, subnet extension at least is required so as to allow the= IP >> > addresses used for communication between applications to be anywhere >> > across the data-centers. >> > >> > There is no reason to think in terms of subnets. Given that there is >> > no locality the concept of subnet no longer makes any sense. Thus one >> > has a collection of host routes spread randomly across a large area. >> > >> > It is trivial to make all VM to VM communication routed. If you look >> > at the details in the l3vpn-end-system proposal, packets are routed >> >> After reading your l3vpn-end-system proposal at a glance, I felt that bo= th >> l3vpn-end-system proposal and Virtual Subnet proposal are using L3VPN to >> exchange host routes while the major difference is that your proposal ex= pects >> to extend the PE functions to the hosts and my proposal intends to retai= n the >> PE functions on the routers. It's interesting:) > > Aha, if the data center operators would like to perform the PE functions = of Virtual Subnet at ToR switches, it seems almost no difference between th= ese two proposals from the perspective of effect. > > Best regards, > Xiaohu >> >> > from the VM to the host-os and by the host-os which encapsulates the >> > packets. The latter has a collection of host routes. Thinking in terms >> > of subnets is not helpful, the concept is just not applicable. >> > >> > Using ARP, proxy or otherwise, is simply self inflicted pain and >> > suffering. There is no reason to care about the mac address of the >> > remote system. >> > >> > regards, >> > Pedro. > From nabil.n.bitar@verizon.com Fri Nov 4 11:16: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 0449611E807F for ; Fri, 4 Nov 2011 11:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=-0.762, 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 hE5L6iYGXaXt for ; Fri, 4 Nov 2011 11:16:28 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7705F11E8082 for ; Fri, 4 Nov 2011 11:16:27 -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 Nov 2011 18:16:26 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="173826910" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi01.verizon.com with ESMTP; 04 Nov 2011 18:16:26 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.102]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Fri, 4 Nov 2011 14:16:26 -0400 To: "robert@raszuk.net" , Linda Dunbar Date: Fri, 4 Nov 2011 14:16:19 -0400 Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Index: AcybHdz+seIH48DeTI+MFjyOvqTq7g== Message-ID: In-Reply-To: <4EB2D29D.8000701@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: L3VPN WG mailing list 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, 04 Nov 2011 18:16:29 -0000 Hi, I think what we need to be careful about assuming that the cloud service provider is the same as the VPN service provider, and in particular a BGP/MPLS service provider. That is not to say that they cannot be the same, but it is over-restrictive to assume that they are and if one makes that assumption the solution or attributes of a solution will not be necessarily the same. Model #2 seems to assume that this is the case in the way it is worded. There are a number of ways in which #1 can be achieved, and one of which can be overlapping with model#2 per suggested modification. I think it is fine to define a model that defines a type or types of DC tenant isolation (connectivity) that will be stitched to the tenant VPN WAN service provided by a service provider. The tenant VPN service can be focused on to be BGP/MPLS VPN provided by a service provider. The tenant connectivity within the data center can also be a BGP-MPLS VPN or an IPsec VPN or a layer2VPN, and one can focus on one, but I think we will find that that at the connection between the data center and the tenant WAN VPN provided by a service provider, the problem will be the same. That is, in terms of stitching the two VPN services. If the service provider VPN is integrated with that of data center, I think that will become a degenerate case. In addition, if there is no BGP/MPLS connectivity, and the customer is gaining access to the DC via an Ipsec tunnel starting from a customer CE and terminated in the data center, that will be transparent to the VPN service provider as a BGP MPLS service provider and I don't think in that case there is anything additional that should be done within the L3VPN WG. Thanks, Nabil On 11/3/11 1:42 PM, "Robert Raszuk" wrote: >Linda, > > > Personally I don't think that we need to waste our time on Model #1 > > for the following reasons: > >Personally I don't think we need to waste our time on solving Model #2 >for one main reason - #2 is a subset of #1. If we solve #1 then #2 get's >solved automatically. > >Please note that IPSec access to provider's L3VPNs has been a >commercialized and deployed feature years ago. > >-- > >I really think that if we have any desire to constructively move forward >in this space time spend on finding the flexible and universal >auto-discovery tool for customer's network islands (be it VMs alone or >L3VPNs sites/set of sides or even specific mobile users) is a >prerequisite for any further work. > >Then we could worry about what tool to use to interconnect those islands. > >Even if those islands (more and more dynamic in nature) would all belong >under one SP .. such SP would also largely benefit from ability to >auto-discovery in real time needs to join or leave a VPN. Then the >toolkit of choice could be triggered to add/delete a site, a user or a >VM to/from given VPN via the orchestration system of his choice. > >To the best of my knowledge such dynamic VPN discovery tool has not been >invented yet. > >Best rgds, >R. > > > >> Here is the fundamental question for the goal of VPN4DC: >> >> 1. Is VPN4DC to create mechanisms which make it possible to connect >> hosts in any public data centers (e.g. Amazon' EC2) to hosts' >> corresponding VPNs? Or >> >> 2. Is VPN4DC to create a solution which allows VPN service provider >> to extend their VPN with computing service? In this model, customers >> (i.e. VPN clients) see their computing resources being offloaded to >> their VPN. Customers don't deal with data centers directly. >> >> >> Personally I don't think that we need to waste our time on Model #1 >> for the following reasons: - VPN service providers may not even >> have PEs in close proximity to "the public data centers" which >> clients choose. If a VPN client has leased some computing resource >> from a data center, the easiest way to connect them securely is by >> IPSec tunnel. >> >> - Today Amazon already allows any hosts to be connected to >> their chosen sites by IPSec (Amazon's VPC service). >> >> Model #2 gives VPN service providers an unique advantage of binding >> valuable VPN services with virtual computing services, making it >> more difficult for data centers who don't own network infrastructure >> to compete. >> >> Do people agree? >> >> Linda >> >>> -----Original Message----- From: Luyuan Fang (lufang) >>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41 >>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list >>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >>> >>> Linda, >>> >>> Ben suggested that Ning and myself to work with co-authors of >>> other problem statement drafts to come up with a combined view to >>> be presented in Taipei meeting. The requirements drafts would be >>> treated in the similar fashion. I plan to put gap analysis together >>> with pb statement drafts. >>> >>> Though there would be no individual vpn4dc drafts presentations as >>> in normal WG meetings, we welcome input on all three subjects from >>> authors of vpn4dc related drafts, and everyone on the list. >>> >>> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was >>> to gather feedback/input from the list, as the first step of >>> meeting prep. >>> >>> Will get together with the authors of the relevant drafts to >>> discuss soon, prefer we meet when Ning is back to office in a >>> couple of days. Ping me if you cannot wait. >>> >>> Thanks, Luyuan >>> >>> >>>> -----Original Message----- From: l3vpn-bounces@ietf.org >>>> [mailto:l3vpn-bounces@ietf.org] On >>> Behalf >>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To: >>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary >>>> L3VPN/VPN4DC agenda @ IETF82 >>>> >>>> Who will lead the talk for each topic? >>>> >>>> Linda >>>> >>>>> -----Original Message----- From: l3vpn-bounces@ietf.org >>>>> [mailto:l3vpn-bounces@ietf.org] On >>>> Behalf >>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 >>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC >>>>> agenda @ IETF82 >>>>> >>>>> Colleagues, >>>>> >>>>> Marshall& I have uploaded a preliminary L3VPN/VPN4DC agenda >>>>> for >>> IETF >>>>> 82 in Taipei. You can find it here: >>>>> >>>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt >>>>> >>>>> At the moment the agenda is a little vague because we are >>>>> still >>>> working >>>>> with the VPN4DC proponents on who will lead each slot. >>>>> >>>>> We have purposely not put time on the agenda to >>>>> present/discuss specific solution drafts as we would like the >>>>> discussion to be >>>> focussed >>>>> on the problem/requirements posed by VPN4DC and its >>>>> applicability >>> to >>>>> IETF (including L3VPN). Discussion of specific solution >>>>> proposals >>> can >>>>> happen at future meetings if the VPN4DC work is adopted. >>>>> >>>>> Ben >>>>> >> >> >> From ccie15672@yahoo.com Fri Nov 4 19:08:09 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 D829711E80C5 for ; Fri, 4 Nov 2011 19:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[AWL=0.610, 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 7284gtwrHwuB for ; Fri, 4 Nov 2011 19:08:08 -0700 (PDT) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) by ietfa.amsl.com (Postfix) with SMTP id 456DF11E8087 for ; Fri, 4 Nov 2011 19:08:08 -0700 (PDT) Received: from [98.139.212.146] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2011 02:08:04 -0000 Received: from [98.139.212.233] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2011 02:08:04 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 05 Nov 2011 02:08:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 221749.89946.bm@omp1042.mail.bf1.yahoo.com Received: (qmail 88487 invoked by uid 60001); 5 Nov 2011 02:08:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1320458884; bh=7zwb0GBCrixDx4RSkUtDjcLTuaE/NzvuFBQ+h4a/YUs=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GrXgrb04epiq2ByozS84ZqBit7mNB6Ylgm1C3KTN3wNLgG+d1mlawuC4cHial6MdTG081FQ71cniWOF/emAMB/Uf9b78eIe5c4EOtdceBa2048sW7bJfPkFQJNFGi+kX+KIiXXDQMcnv+cqyHYvjf30reNRyf6OnvPlGv59v5zs= 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:Cc:In-Reply-To:MIME-Version:Content-Type; b=mhbMraV03rW5TY5m61drbgzUROj2WhyqG6NFPJWdvmnyea3kZECV518byXqxJgW7KPAYIjj+BKgi9wFnVewPoEKg9xTCn6bSc8zCaNKxlXk/igvJNgl7DVEQKncPoGTkusFslN1RtKO1zceo9sQLSb3OcrMDCHkdgudRmPtHqIc=; X-YMail-OSG: 17D0W38VM1kA_4r.oDpKZvuSakQi5EFiGAo4ttdLE7BOYSk 3RalZ27TI2gjjBzFJ10Yk2ZbXkZgMAMTL8DIVOmZjnGL86rJh_J3ChM4RsEv 1Y3LVpathRWOMcXrrDsP.zIxm7MZ.49m7I6Cf2npRfcyJSTKMRmwXBy9seUG K.6WUz_u1ubk7c6aBT.JX7UwlhO1nYVSVOnNJZ1ZvvzgpgVDRfwIrJRtnKt6 9Dj1w41aaJ248QtxQlihQrKm0vRl_J6g13Xz33SXRdyGycZFE7U9lMh.a6h8 LYSgRgRSqMro20uQr53ii3sGkQinNCbb1PDvHN.TpkV6DOWLqlTkurMOw_4v hW9cL.KXctJu81p6igrt2OHS7C.9OZ._p.q.4YENl8j95hIlinUm3LeMREmW H8rPqVu7CldPSS1n7b5yQzkdysGJpXvY_arESOcJmbWO2AaKXvxUWIFdyR9Y rPnF.bw-- Received: from [76.194.43.66] by web161801.mail.bf1.yahoo.com via HTTP; Fri, 04 Nov 2011 19:08:04 PDT X-Mailer: YahooMailWebService/0.8.114.317681 References: <4EB2D29D.8000701@raszuk.net> Message-ID: <1320458884.82254.YahooMailNeo@web161801.mail.bf1.yahoo.com> Date: Fri, 4 Nov 2011 19:08:04 -0700 (PDT) From: Derick Winkworth Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 To: "Bitar, Nabil N" , "robert@raszuk.net" , Linda Dunbar In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1882999342-322915630-1320458884=:82254" Cc: L3VPN WG mailing list 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: Sat, 05 Nov 2011 02:08:10 -0000 --1882999342-322915630-1320458884=:82254 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I have read the VaaS document several times and I'm not seeing how it is re= levant to VPN4DC. =A0=0A=0A(1) These VMs are not mobile users on the intern= et.=A0=0A(2) We are, in fact, creating network path isolation (with proper = separation) for the VMs in the data center to/from their respective VRF.=0A= (3) No matter how great the software is that you are using on your host to = establish the VPN... *my* customers, the reason I'm so interested in VPN4DC= , do not want their servers exposed to the internet at any level. =A0They w= ant their servers effectively "jailed" in their L3VPN. =A0there can be no d= ependency on software or configuration of the VM for its placement in their= network. =A0The vNIC is bound by path isolation to their private L3VPN. = =A0this is a not a unique or unusual requirement.=0A(4) You are advocating = VaaS as a replacement for MPLS (it would seem by your comments). =A0I'm not= interested in replacing MPLS. =A0=0A=0AFeel free to correct or clarify any= misunderstanding I may be suffering from...=0A=0A=0A=0A=0A=0A=0A__________= ______________________=0AFrom: "Bitar, Nabil N" = =0ATo: "robert@raszuk.net" ; Linda Dunbar =0ACc: L3VPN WG mailing list =0ASent: Friday, No= vember 4, 2011 1:16 PM=0ASubject: Re: Preliminary L3VPN/VPN4DC agenda @ IET= F82=0A=0AHi,=0AI think what we need to be careful about assuming that the c= loud service=0Aprovider is the same as the VPN service provider, and in par= ticular a=0ABGP/MPLS service provider. That is not to say that they cannot = be the=0Asame, but it is over-restrictive to assume that they are and if on= e makes=0Athat assumption the solution or attributes of a solution will not= be=0Anecessarily the same. Model #2 seems to assume that this is the case = in=0Athe way it is worded.=0A=0AThere are a number of ways in which #1 can = be achieved, and one of which=0Acan be overlapping with model#2 per suggest= ed modification. I think it is=0Afine to define a model that defines a type= or types=A0 of DC tenant=0Aisolation (connectivity)=A0 that will be stitch= ed to the tenant VPN WAN=0Aservice provided by a service provider. The tena= nt VPN service can be=0Afocused on to be BGP/MPLS VPN provided by a service= provider. The tenant=0Aconnectivity within the data center can also be a B= GP-MPLS VPN or an IPsec=0AVPN or a layer2VPN, and one can focus on one, but= I think we will find=0Athat that at the connection between the data center= and the tenant WAN VPN=0Aprovided by a service provider, the problem will = be the same. That is, in=0Aterms of stitching the two VPN services. If the = service provider VPN is=0Aintegrated with that of data center, I think that= will become a degenerate=0Acase. In addition, if there is no BGP/MPLS conn= ectivity, and the customer=0Ais gaining access to the DC via an Ipsec tunne= l starting from a customer=0ACE and terminated in the data center, that wil= l be transparent to the VPN=0Aservice provider as a BGP MPLS service provid= er and I don't think in that=0Acase there is anything additional that shoul= d be done within the L3VPN WG.=0A=0AThanks,=0ANabil=0A=0AOn 11/3/11 1:42 PM= , "Robert Raszuk" wrote:=0A=0A>Linda,=0A>=0A> > Persona= lly I don't think that we need to waste our time on Model #1=0A> > for the = following reasons:=0A>=0A>Personally I don't think we need to waste our tim= e on solving Model #2=0A>for one main reason - #2 is a subset of #1. If we = solve #1 then #2 get's=0A>solved automatically.=0A>=0A>Please note that IPS= ec access to provider's L3VPNs has been a=0A>commercialized and deployed fe= ature years ago.=0A>=0A>--=0A>=0A>I really think that if we have any desire= to constructively move forward=0A>in this space time spend on finding the = flexible and universal=0A>auto-discovery tool for customer's network island= s (be it VMs alone or=0A>L3VPNs sites/set of sides or even specific mobile = users) is a=0A>prerequisite for any further work.=0A>=0A>Then we could worr= y about what tool to use to interconnect those islands.=0A>=0A>Even if thos= e islands (more and more dynamic in nature) would all belong=0A>under one S= P .. such SP would also largely benefit from ability to=0A>auto-discovery i= n real time needs to join or leave a VPN. Then the=0A>toolkit of choice cou= ld be triggered to add/delete a site, a user or a=0A>VM to/from given VPN v= ia the orchestration system of his choice.=0A>=0A>To the best of my knowled= ge such dynamic VPN discovery tool has not been=0A>invented yet.=0A>=0A>Bes= t rgds,=0A>R.=0A>=0A>=0A>=0A>> Here is the fundamental question for the goa= l of VPN4DC:=0A>>=0A>> 1. Is VPN4DC to create mechanisms which make it poss= ible to connect=0A>> hosts in any public data centers (e.g. Amazon' EC2) to= hosts'=0A>> corresponding VPNs? Or=0A>>=0A>> 2. Is VPN4DC to create a solu= tion which allows VPN service provider=0A>> to extend their VPN with comput= ing service? In this model, customers=0A>> (i.e. VPN clients) see their com= puting resources being offloaded to=0A>> their VPN. Customers don't deal wi= th data centers directly.=0A>>=0A>>=0A>> Personally I don't think that we n= eed to waste our time on Model #1=0A>> for the following reasons: -=A0 =A0 = =A0 VPN service providers may not even=0A>> have PEs in close proximity to= "the public data centers" which=0A>> clients choose. If a VPN client has l= eased some computing resource=0A>> from a data center, the easiest way to c= onnect them securely is by=0A>> IPSec tunnel.=0A>>=0A>> -=A0 =A0 =A0 Today= Amazon already allows any hosts to be connected to=0A>> their chosen sites= by IPSec (Amazon's VPC service).=0A>>=0A>> Model #2 gives VPN service prov= iders an unique advantage of binding=0A>> valuable VPN services with virtua= l computing services,=A0 making it=0A>> more difficult for data centers who= don't own network infrastructure=0A>> to compete.=0A>>=0A>> Do people agre= e?=0A>>=0A>> Linda=0A>>=0A>>> -----Original Message----- From: Luyuan Fang = (lufang)=0A>>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011= 11:41=0A>>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list= =0A>>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82=0A>>>=0A>>> Li= nda,=0A>>>=0A>>> Ben suggested that Ning and myself to work with co-authors= of=0A>>> other problem statement drafts to come up with a combined view to= =0A>>> be presented in Taipei meeting. The requirements drafts would be=0A>= >> treated in the similar fashion. I plan to put gap analysis together=0A>>= > with pb statement drafts.=0A>>>=0A>>> Though there would be no individual= vpn4dc drafts presentations as=0A>>> in normal WG meetings, we welcome inp= ut on all three subjects from=0A>>> authors of vpn4dc related drafts, and e= veryone on the list.=0A>>>=0A>>> In fact, the intent of vpn4dc Q&A I sent a= couple of days ago was=0A>>> to gather feedback/input from the list, as th= e first step of=0A>>> meeting prep.=0A>>>=0A>>> Will get together with the = authors of the relevant drafts to=0A>>> discuss soon, prefer we meet when N= ing is back to office in a=0A>>> couple of days. Ping me if you cannot wait= .=0A>>>=0A>>> Thanks, Luyuan=0A>>>=0A>>>=0A>>>> -----Original Message----- = From: l3vpn-bounces@ietf.org=0A>>>> [mailto:l3vpn-bounces@ietf.org] On=0A>>= > Behalf=0A>>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM= To:=0A>>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Prelimina= ry=0A>>>> L3VPN/VPN4DC agenda @ IETF82=0A>>>>=0A>>>> Who will lead the talk= for each topic?=0A>>>>=0A>>>> Linda=0A>>>>=0A>>>>> -----Original Message--= --- From: l3vpn-bounces@ietf.org=0A>>>>> [mailto:l3vpn-bounces@ietf.org] On= =0A>>>> Behalf=0A>>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2= 011 1:01=0A>>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VP= N4DC=0A>>>>> agenda @ IETF82=0A>>>>>=0A>>>>> Colleagues,=0A>>>>>=0A>>>>> Ma= rshall&=A0 I have uploaded a preliminary L3VPN/VPN4DC agenda=0A>>>>> for=0A= >>> IETF=0A>>>>> 82 in Taipei. You can find it here:=0A>>>>>=0A>>>>> http:/= /www.ietf.org/proceedings/82/agenda/l3vpn.txt=0A>>>>>=0A>>>>> At the moment= the agenda is a little vague because we are=0A>>>>> still=0A>>>> working= =0A>>>>> with the VPN4DC proponents on who will lead each slot.=0A>>>>>=0A>= >>>> We have purposely not put time on the agenda to=0A>>>>> present/discus= s specific solution drafts as we would like the=0A>>>>> discussion to be=0A= >>>> focussed=0A>>>>> on the problem/requirements posed by VPN4DC and its= =0A>>>>> applicability=0A>>> to=0A>>>>> IETF (including L3VPN). Discussion = of specific solution=0A>>>>> proposals=0A>>> can=0A>>>>> happen at future m= eetings if the VPN4DC work is adopted.=0A>>>>>=0A>>>>> Ben=0A>>>>>=0A>>=0A>= >=0A>> --1882999342-322915630-1320458884=:82254 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I have read the VaaS = document several times and I'm not seeing how it is relevant to VPN4DC. &nb= sp;

(1) These VMs are no= t mobile users on the internet. 
(2) We are, in= fact, creating network path isolation (with proper separation) for the VMs= in the data center to/from their respective VRF.
(3= ) No matter how great the software is that you are using on your host to es= tablish the VPN... *my* customers, the reason I'm so interested in VPN4DC, = do not want their servers exposed to the internet at any level.  They = want their servers effectively "jailed" in their L3VPN.  there can be = no dependency on software or configuration of the VM for its placement in t= heir network.  The vNIC is bound by path isolation to their private L3VPN.  this is a not a unique or unusual requirement.=
(4) You are advocating VaaS as a replacement for MPLS (it = would seem by your comments).  I'm not interested in replacing MPLS. &= nbsp;

Feel free to corre= ct or clarify any misunderstanding I may be suffering from...
<= div>




From: "Bitar, Nabil N" <nabil.n.bitar@verizon.com>
To: "robert@raszuk.net" <robert@raszu= k.net>; Linda Dunbar <linda.dunbar@huawei.com>
Cc: L3VPN WG mailing list <l3vp= n@ietf.org>
Sent: Fr= iday, November 4, 2011 1:16 PM
Sub= ject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82
=0AHi,
I think what we need to be careful about assuming that the cloud= service
provider is the same as the VPN service provider, and in partic= ular a
BGP/MPLS service provider. That is not to say that they cannot be= the
same, but it is over-restrictive to assume that they are and if one= makes
that assumption the solution or attributes of a solution will not= be
necessarily the same. Model #2 seems to assume that this is the case= in
the way it is worded.

There are a number of ways in which #1 = can be achieved, and one of which
can be overlapping with model#2 per su= ggested modification. I think it is
fine to define a model that defines = a type or types  of DC tenant
isolation (connectivity)  that w= ill be stitched to the tenant VPN WAN
service provided by a service prov= ider. The tenant VPN service can be
focused on to be BGP/MPLS VPN provid= ed by a service provider. The tenant
connectivity within the data center can also be a BGP-MPLS VPN or an IPsec
VPN or a layer2VPN, and o= ne can focus on one, but I think we will find
that that at the connectio= n between the data center and the tenant WAN VPN
provided by a service p= rovider, the problem will be the same. That is, in
terms of stitching th= e two VPN services. If the service provider VPN is
integrated with that = of data center, I think that will become a degenerate
case. In addition,= if there is no BGP/MPLS connectivity, and the customer
is gaining acces= s to the DC via an Ipsec tunnel starting from a customer
CE and terminat= ed in the data center, that will be transparent to the VPN
service provi= der as a BGP MPLS service provider and I don't think in that
case there = is anything additional that should be done within the L3VPN WG.

Than= ks,
Nabil

On 11/3/11 1:42 PM, "Robert Raszuk" <robert@raszuk.net> wrote:

= >Linda,
>
> > Personally I don't think that we need to wa= ste our time on Model #1
> > for the following reasons:
>>Personally I don't think we need to waste our time on solving Model #2=
>for one main reason - #2 is a subset of #1. If we solve #1 then #2 = get's
>solved automatically.
>
>Please note that IPSec ac= cess to provider's L3VPNs has been a
>commercialized and deployed fea= ture years ago.
>
>--
>
>I really think that if we = have any desire to constructively move forward
>in this space time sp= end on finding the flexible and universal
>auto-discovery tool for cu= stomer's network islands (be it VMs alone or
>L3VPNs sites/set of sid= es or even specific mobile users) is a
>prerequisite for any further = work.
>
>Then we could worry about what tool to use to interconnect those islands.
>
>Even if those islands (more and= more dynamic in nature) would all belong
>under one SP .. such SP wo= uld also largely benefit from ability to
>auto-discovery in real time= needs to join or leave a VPN. Then the
>toolkit of choice could be t= riggered to add/delete a site, a user or a
>VM to/from given VPN via = the orchestration system of his choice.
>
>To the best of my kn= owledge such dynamic VPN discovery tool has not been
>invented yet.>
>Best rgds,
>R.
>
>
>
>> Here= is the fundamental question for the goal of VPN4DC:
>>
>>= ; 1. Is VPN4DC to create mechanisms which make it possible to connect
&g= t;> hosts in any public data centers (e.g. Amazon' EC2) to hosts'
>= ;> corresponding VPNs? Or
>>
>> 2. Is VPN4DC to create= a solution which allows VPN service provider
>> to extend their VPN with computing service? In this model, customers
>> (i.= e. VPN clients) see their computing resources being offloaded to
>>= ; their VPN. Customers don't deal with data centers directly.
>>>>
>> Personally I don't think that we need to waste our t= ime on Model #1
>> for the following reasons: -     = ; VPN service providers may not even
>> have PEs in close proximi= ty to "the public data centers" which
>> clients choose. If a VPN = client has leased some computing resource
>> from a data center, t= he easiest way to connect them securely is by
>> IPSec tunnel.
= >>
>> -      Today Amazon already allows any= hosts to be connected to
>> their chosen sites by IPSec (Amazon's= VPC service).
>>
>> Model #2 gives VPN service providers= an unique advantage of binding
>> valuable VPN services with virtual computing services,  making it
>> more difficul= t for data centers who don't own network infrastructure
>> to comp= ete.
>>
>> Do people agree?
>>
>> Linda=
>>
>>> -----Original Message----- From: Luyuan Fang (= lufang)
>>> [mailto:lufang@cisco.com] Sent: Wednesday, Novembe= r 02, 2011 11:41
>>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3= VPN WG mailing list
>>> Subject: RE: Preliminary L3VPN/VPN4DC a= genda @ IETF82
>>>
>>> Linda,
>>>
&g= t;>> Ben suggested that Ning and myself to work with co-authors of>>> other problem statement drafts to come up with a combined vie= w to
>>> be presented in Taipei meeting. The requirements draft= s would be
>>> treated in the similar fashion. I plan to put gap analysis together
>>> with pb statement drafts.
>>= ;>
>>> Though there would be no individual vpn4dc drafts pre= sentations as
>>> in normal WG meetings, we welcome input on al= l three subjects from
>>> authors of vpn4dc related drafts, and= everyone on the list.
>>>
>>> In fact, the intent = of vpn4dc Q&A I sent a couple of days ago was
>>> to gather= feedback/input from the list, as the first step of
>>> meeting= prep.
>>>
>>> Will get together with the authors o= f the relevant drafts to
>>> discuss soon, prefer we meet when = Ning is back to office in a
>>> couple of days. Ping me if you = cannot wait.
>>>
>>> Thanks, Luyuan
>>>=
>>>
>>>> -----Original Message----- From: l3vpn-bounces@ietf.org
>&= gt;>> [mailto:l3vpn-bounces@ietf.org] On
>>>= Behalf
>>>> Of Linda Dunbar Sent: Wednesday, November 02, 2= 011 10:56 PM To:
>>>> Ben Niven-Jenkins; L3VPN WG mailing li= st Subject: RE: Preliminary
>>>> L3VPN/VPN4DC agenda @ IETF8= 2
>>>>
>>>> Who will lead the talk for each t= opic?
>>>>
>>>> Linda
>>>>
= >>>>> -----Original Message----- From: l3vpn-bounce= s@ietf.org
>>>>> [mailto:l3vpn-bounces@ietf.= org] On
>>>> Behalf
>>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01
>>>>&= gt; PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC
>&= gt;>>> agenda @ IETF82
>>>>>
>>>>= > Colleagues,
>>>>>
>>>>> Marshall&a= mp;  I have uploaded a preliminary L3VPN/VPN4DC agenda
>>>= >> for
>>> IETF
>>>>> 82 in Taipei. You= can find it here:
>>>>>
>>>>> http://w= ww.ietf.org/proceedings/82/agenda/l3vpn.txt
>>>>>
>= >>>> At the moment the agenda is a little vague because we are<= br>>>>>> still
>>>> working
>>>&g= t;> with the VPN4DC proponents on who will lead each slot.
>>&g= t;>>
>>>>> We have purposely not put time on the ag= enda to
>>>>> present/discuss specific solution drafts as we would like the
>>>>> discussion to be
&g= t;>>> focussed
>>>>> on the problem/requirements= posed by VPN4DC and its
>>>>> applicability
>>&= gt; to
>>>>> IETF (including L3VPN). Discussion of specif= ic solution
>>>>> proposals
>>> can
>&g= t;>>> happen at future meetings if the VPN4DC work is adopted.
= >>>>>
>>>>> Ben
>>>>>>>
>>
>>



<= /html> --1882999342-322915630-1320458884=:82254-- From lizho.jin@gmail.com Fri Nov 4 20:03:52 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 9697D11E80E0 for ; Fri, 4 Nov 2011 20:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.652, 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_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 3Tp-A6jMGf02 for ; Fri, 4 Nov 2011 20:03:51 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1413C11E80DD for ; Fri, 4 Nov 2011 20:03:51 -0700 (PDT) Received: by qadc10 with SMTP id c10so3391775qad.31 for ; Fri, 04 Nov 2011 20:03:50 -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:cc:content-type; bh=hdN4cibgZIXjnmugx8k1SUCcD59tW2Pb5ceJOUM/jm8=; b=w0X6a2TJJnw52kd0hwubPH8aZnv+q/xpEe8rLku/ZI2zvamusI8DUa6nP7JpxO/w/r PyovDZPU/mQXuMqGarSOV7LMkV1uT+zniIRJnRRlHsC95XoTc+vV2oAk1+fnCCF/Gduo 2B2jup8dkvvEZOWb8awqMite7SjdxQqEp+DKg= MIME-Version: 1.0 Received: by 10.224.216.197 with SMTP id hj5mr8616677qab.15.1320462230608; Fri, 04 Nov 2011 20:03:50 -0700 (PDT) Received: by 10.224.54.147 with HTTP; Fri, 4 Nov 2011 20:03:50 -0700 (PDT) Date: Sat, 5 Nov 2011 11:03:50 +0800 Message-ID: Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 From: Lizhong Jin To: l3vpn@ietf.org Content-Type: multipart/alternative; boundary=20cf300fb3c731dc0f04b0f412ea Cc: robert@raszuk.net 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: Sat, 05 Nov 2011 03:03:52 -0000 --20cf300fb3c731dc0f04b0f412ea Content-Type: text/plain; charset=ISO-8859-1 I tend to hold the same view as Nabil. The problem we can see now is "stitching the two VPN services". There will be various ways to implement VPN in datacenter, e.g, VLAN, PBB, VRF and etc. And I am not sure the cloud provider need a new kind of L3VPN in their datacenter? Whether setting up VPN in datacenter by network manager is a more easy and cost efficient way? Could anyone from cloud provider give some information? Thanks Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 4 Nov 2011 14:16:19 -0400 > From: "Bitar, Nabil N" > To: "robert@raszuk.net" , Linda Dunbar > > Cc: L3VPN WG mailing list > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi, > I think what we need to be careful about assuming that the cloud service > provider is the same as the VPN service provider, and in particular a > BGP/MPLS service provider. That is not to say that they cannot be the > same, but it is over-restrictive to assume that they are and if one makes > that assumption the solution or attributes of a solution will not be > necessarily the same. Model #2 seems to assume that this is the case in > the way it is worded. > > There are a number of ways in which #1 can be achieved, and one of which > can be overlapping with model#2 per suggested modification. I think it is > fine to define a model that defines a type or types of DC tenant > isolation (connectivity) that will be stitched to the tenant VPN WAN > service provided by a service provider. The tenant VPN service can be > focused on to be BGP/MPLS VPN provided by a service provider. The tenant > connectivity within the data center can also be a BGP-MPLS VPN or an IPsec > VPN or a layer2VPN, and one can focus on one, but I think we will find > that that at the connection between the data center and the tenant WAN VPN > provided by a service provider, the problem will be the same. That is, in > terms of stitching the two VPN services. If the service provider VPN is > integrated with that of data center, I think that will become a degenerate > case. In addition, if there is no BGP/MPLS connectivity, and the customer > is gaining access to the DC via an Ipsec tunnel starting from a customer > CE and terminated in the data center, that will be transparent to the VPN > service provider as a BGP MPLS service provider and I don't think in that > case there is anything additional that should be done within the L3VPN WG. > > Thanks, > Nabil > > On 11/3/11 1:42 PM, "Robert Raszuk" wrote: > > >Linda, > > > > > Personally I don't think that we need to waste our time on Model #1 > > > for the following reasons: > > > >Personally I don't think we need to waste our time on solving Model #2 > >for one main reason - #2 is a subset of #1. If we solve #1 then #2 get's > >solved automatically. > > > >Please note that IPSec access to provider's L3VPNs has been a > >commercialized and deployed feature years ago. > > > >-- > > > >I really think that if we have any desire to constructively move forward > >in this space time spend on finding the flexible and universal > >auto-discovery tool for customer's network islands (be it VMs alone or > >L3VPNs sites/set of sides or even specific mobile users) is a > >prerequisite for any further work. > > > >Then we could worry about what tool to use to interconnect those islands. > > > >Even if those islands (more and more dynamic in nature) would all belong > >under one SP .. such SP would also largely benefit from ability to > >auto-discovery in real time needs to join or leave a VPN. Then the > >toolkit of choice could be triggered to add/delete a site, a user or a > >VM to/from given VPN via the orchestration system of his choice. > > > >To the best of my knowledge such dynamic VPN discovery tool has not been > >invented yet. > > > >Best rgds, > >R. > > > > > > > >> Here is the fundamental question for the goal of VPN4DC: > >> > >> 1. Is VPN4DC to create mechanisms which make it possible to connect > >> hosts in any public data centers (e.g. Amazon' EC2) to hosts' > >> corresponding VPNs? Or > >> > >> 2. Is VPN4DC to create a solution which allows VPN service provider > >> to extend their VPN with computing service? In this model, customers > >> (i.e. VPN clients) see their computing resources being offloaded to > >> their VPN. Customers don't deal with data centers directly. > >> > >> > >> Personally I don't think that we need to waste our time on Model #1 > >> for the following reasons: - VPN service providers may not even > >> have PEs in close proximity to "the public data centers" which > >> clients choose. If a VPN client has leased some computing resource > >> from a data center, the easiest way to connect them securely is by > >> IPSec tunnel. > >> > >> - Today Amazon already allows any hosts to be connected to > >> their chosen sites by IPSec (Amazon's VPC service). > >> > >> Model #2 gives VPN service providers an unique advantage of binding > >> valuable VPN services with virtual computing services, making it > >> more difficult for data centers who don't own network infrastructure > >> to compete. > >> > >> Do people agree? > >> > >> Linda > >> > >>> -----Original Message----- From: Luyuan Fang (lufang) > >>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41 > >>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > >>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > >>> > >>> Linda, > >>> > >>> Ben suggested that Ning and myself to work with co-authors of > >>> other problem statement drafts to come up with a combined view to > >>> be presented in Taipei meeting. The requirements drafts would be > >>> treated in the similar fashion. I plan to put gap analysis together > >>> with pb statement drafts. > >>> > >>> Though there would be no individual vpn4dc drafts presentations as > >>> in normal WG meetings, we welcome input on all three subjects from > >>> authors of vpn4dc related drafts, and everyone on the list. > >>> > >>> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was > >>> to gather feedback/input from the list, as the first step of > >>> meeting prep. > >>> > >>> Will get together with the authors of the relevant drafts to > >>> discuss soon, prefer we meet when Ning is back to office in a > >>> couple of days. Ping me if you cannot wait. > >>> > >>> Thanks, Luyuan > >>> > >>> > >>>> -----Original Message----- From: l3vpn-bounces@ietf.org > >>>> [mailto:l3vpn-bounces@ietf.org] On > >>> Behalf > >>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To: > >>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary > >>>> L3VPN/VPN4DC agenda @ IETF82 > >>>> > >>>> Who will lead the talk for each topic? > >>>> > >>>> Linda > >>>> > >>>>> -----Original Message----- From: l3vpn-bounces@ietf.org > >>>>> [mailto:l3vpn-bounces@ietf.org] On > >>>> Behalf > >>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 > >>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC > >>>>> agenda @ IETF82 > >>>>> > >>>>> Colleagues, > >>>>> > >>>>> Marshall& I have uploaded a preliminary L3VPN/VPN4DC agenda > >>>>> for > >>> IETF > >>>>> 82 in Taipei. You can find it here: > >>>>> > >>>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > >>>>> > >>>>> At the moment the agenda is a little vague because we are > >>>>> still > >>>> working > >>>>> with the VPN4DC proponents on who will lead each slot. > >>>>> > >>>>> We have purposely not put time on the agenda to > >>>>> present/discuss specific solution drafts as we would like the > >>>>> discussion to be > >>>> focussed > >>>>> on the problem/requirements posed by VPN4DC and its > >>>>> applicability > >>> to > >>>>> IETF (including L3VPN). Discussion of specific solution > >>>>> proposals > >>> can > >>>>> happen at future meetings if the VPN4DC work is adopted. > >>>>> > >>>>> Ben > >>>>> > >> > >> > >> > > > > ------------------------------ > > _______________________________________________ > L3VPN mailing list > L3VPN@ietf.org > https://www.ietf.org/mailman/listinfo/l3vpn > > > End of L3VPN Digest, Vol 89, Issue 17 > ************************************* > --20cf300fb3c731dc0f04b0f412ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I tend to hold the same view as Nabil. The problem we can see now is &= quot;stitching the two VPN services". There will be various ways to im= plement VPN in datacenter, e.g, VLAN, PBB, VRF and etc. And I am not sure= =A0the cloud provider need a new kind of L3VPN in their datacenter? Whether= setting up VPN in datacenter by network manager is a more easy and cost ef= ficient way? Could anyone from cloud provider give some information?
=A0
Thanks
Lizhong
=A0
=A0
--------------------------------= --------------------------------------

Message: 1
Date: Fri, 4 No= v 2011 14:16:19 -0400
From: "Bitar, Nabil N" <nabil.n.bitar@verizon.com>
To: "robert@raszuk.net" <robert@raszuk.net>, Linda Dunbar
=A0 =A0 =A0 =A0<linda.dunbar@= huawei.com>
Cc: L3VPN WG mailing list <l3vpn@ietf.org>
Subject: Re: Preliminary L3VPN/VPN4DC = agenda @ IETF82
Message-ID: <CAD957A1.2C4B8%nabil.n.bitar@verizon.com>
Content-Type: text/p= lain; charset=3D"us-ascii"

Hi,
I think what we need to = be careful about assuming that the cloud service
provider is the same as the VPN service provider, and in particular a
BG= P/MPLS service provider. That is not to say that they cannot be the
same= , but it is over-restrictive to assume that they are and if one makes
that assumption the solution or attributes of a solution will not be
nec= essarily the same. Model #2 seems to assume that this is the case in
the= way it is worded.

There are a number of ways in which #1 can be ach= ieved, and one of which
can be overlapping with model#2 per suggested modification. I think it isfine to define a model that defines a type or types =A0of DC tenant
is= olation (connectivity) =A0that will be stitched to the tenant VPN WAN
se= rvice provided by a service provider. The tenant VPN service can be
focused on to be BGP/MPLS VPN provided by a service provider. The tenantconnectivity within the data center can also be a BGP-MPLS VPN or an IPsec=
VPN or a layer2VPN, and one can focus on one, but I think we will find<= br> that that at the connection between the data center and the tenant WAN VPN<= br>provided by a service provider, the problem will be the same. That is, i= n
terms of stitching the two VPN services. If the service provider VPN i= s
integrated with that of data center, I think that will become a degenerate<= br>case. In addition, if there is no BGP/MPLS connectivity, and the custome= r
is gaining access to the DC via an Ipsec tunnel starting from a custom= er
CE and terminated in the data center, that will be transparent to the VPNservice provider as a BGP MPLS service provider and I don't think in = that
case there is anything additional that should be done within the L3= VPN WG.

Thanks,
Nabil

On 11/3/11 1:42 PM, "Robert Raszuk" &= lt;robert@raszuk.net> wrote:
>Linda,
>
> > Personally I don't think that we n= eed to waste our time on Model #1
> > for the following reasons:
>
>Personally I don't = think we need to waste our time on solving Model #2
>for one main rea= son - #2 is a subset of #1. If we solve #1 then #2 get's
>solved = automatically.
>
>Please note that IPSec access to provider's L3VPNs has been= a
>commercialized and deployed feature years ago.
>
>--<= br>>
>I really think that if we have any desire to constructively = move forward
>in this space time spend on finding the flexible and universal
>a= uto-discovery tool for customer's network islands (be it VMs alone or>L3VPNs sites/set of sides or even specific mobile users) is a
>prerequisite for any further work.
>
>Then we could worry a= bout what tool to use to interconnect those islands.
>
>Even if= those islands (more and more dynamic in nature) would all belong
>un= der one SP .. such SP would also largely benefit from ability to
>auto-discovery in real time needs to join or leave a VPN. Then the
&= gt;toolkit of choice could be triggered to add/delete a site, a user or a>VM to/from given VPN via the orchestration system of his choice.
>
>To the best of my knowledge such dynamic VPN discovery tool has= not been
>invented yet.
>
>Best rgds,
>R.
><= br>>
>
>> Here is the fundamental question for the goal o= f VPN4DC:
>>
>> 1. Is VPN4DC to create mechanisms which make it possib= le to connect
>> hosts in any public data centers (e.g. Amazon'= ; EC2) to hosts'
>> corresponding VPNs? Or
>>
>> 2. Is VPN4DC to create a solution which allows VPN service provide= r
>> to extend their VPN with computing service? In this model, cu= stomers
>> (i.e. VPN clients) see their computing resources being = offloaded to
>> their VPN. Customers don't deal with data centers directly.>>
>>
>> Personally I don't think that we need= to waste our time on Model #1
>> for the following reasons: - =A0= =A0 =A0 VPN service providers may not even
>> have PEs in close proximity to "the public data centers"= which
>> clients choose. If a VPN client has leased some computin= g resource
>> from a data center, the easiest way to connect them = securely is by
>> IPSec tunnel.
>>
>> - =A0 =A0 =A0 Today Amazon a= lready allows any hosts to be connected to
>> their chosen sites b= y IPSec (Amazon's VPC service).
>>
>> Model #2 gives = VPN service providers an unique advantage of binding
>> valuable VPN services with virtual computing services, =A0making i= t
>> more difficult for data centers who don't own network inf= rastructure
>> to compete.
>>
>> Do people agree= ?
>>
>> Linda
>>
>>> -----Original Messag= e----- From: Luyuan Fang (lufang)
>>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011= 11:41
>>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list<= br>>>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82
&g= t;>>
>>> Linda,
>>>
>>> Ben sugge= sted that Ning and myself to work with co-authors of
>>> other problem statement drafts to come up with a combined view= to
>>> be presented in Taipei meeting. The requirements drafts= would be
>>> treated in the similar fashion. I plan to put gap= analysis together
>>> with pb statement drafts.
>>>
>>> Thou= gh there would be no individual vpn4dc drafts presentations as
>>&= gt; in normal WG meetings, we welcome input on all three subjects from
>>> authors of vpn4dc related drafts, and everyone on the list.>>>
>>> In fact, the intent of vpn4dc Q&A I sent = a couple of days ago was
>>> to gather feedback/input from the = list, as the first step of
>>> meeting prep.
>>>
>>> Will get togethe= r with the authors of the relevant drafts to
>>> discuss soon, = prefer we meet when Ning is back to office in a
>>> couple of d= ays. Ping me if you cannot wait.
>>>
>>> Thanks, Luyuan
>>>
>>>=
>>>> -----Original Message----- From: l3vpn-bounces@ietf.org
>>>> [mailto= :l3vpn-bounces@ietf.org] On >>> Behalf
>>>> Of Linda Dunbar Sent: Wednesday, No= vember 02, 2011 10:56 PM To:
>>>> Ben Niven-Jenkins; L3VPN W= G mailing list Subject: RE: Preliminary
>>>> L3VPN/VPN4DC ag= enda @ IETF82
>>>>
>>>> Who will lead the talk for each topic?=
>>>>
>>>> Linda
>>>>
>&= gt;>>> -----Original Message----- From: l3vpn-bounces@ietf.org
>>>>> [mailto:l3vp= n-bounces@ietf.org] On
>>>> Behalf
>>>>&g= t; Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01
>>= >>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC=
>>>>> agenda @ IETF82
>>>>>
>>>= ;>> Colleagues,
>>>>>
>>>>> Marsh= all& =A0I have uploaded a preliminary L3VPN/VPN4DC agenda
>>&g= t;>> for
>>> IETF
>>>>> 82 in Taipei. You can find it her= e:
>>>>>
>>>>> http://www.ietf.o= rg/proceedings/82/agenda/l3vpn.txt
>>>>>
>>>>> At the moment the agenda is a = little vague because we are
>>>>> still
>>>&g= t; working
>>>>> with the VPN4DC proponents on who will l= ead each slot.
>>>>>
>>>>> We have purposely not put time= on the agenda to
>>>>> present/discuss specific solution= drafts as we would like the
>>>>> discussion to be
>>>> focussed
>>>>> on the problem/requiremen= ts posed by VPN4DC and its
>>>>> applicability
>>= ;> to
>>>>> IETF (including L3VPN). Discussion of spec= ific solution
>>>>> proposals
>>> can
>>>>> = happen at future meetings if the VPN4DC work is adopted.
>>>>= ;>
>>>>> Ben
>>>>>
>>
>>
>>



------------------------------

_= ______________________________________________
L3VPN mailing list
L3VPN@ietf.org
https://www.ietf.org/ma= ilman/listinfo/l3vpn


End of L3VPN Digest, Vol 89, Issue 17
**************************= ***********

--20cf300fb3c731dc0f04b0f412ea-- From lufang@cisco.com Fri Nov 4 22:34: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 8B31021F8B52 for ; Fri, 4 Nov 2011 22:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.631 X-Spam-Level: X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=1.168, BAYES_00=-2.599, GB_I_LETTER=-2, 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 BTt1MdHlh-pv for ; Fri, 4 Nov 2011 22:34:28 -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 56BCC21F8B51 for ; Fri, 4 Nov 2011 22:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=8625; q=dns/txt; s=iport; t=1320471268; x=1321680868; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=u9lvGl6Oo6tu1uB2249IozRgcYbqAumN3RgC07RSYFo=; b=Ojeta43ol15886py226lGkKOeCZkrd9r3LNVd1KnBviBkqpuuN3wRMCL d9CzB/tPpWhCpNehaz2uw+9+8f6od7VydMwz7+/XicTbyep+nj5TINaSO p7owAUQxRmta1mCVCS0YJytk5HPDQJG7kOgDg/vai1JJfLrkVsHyhgKI0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMAAP7JtE6tJXG8/2dsb2JhbABDmhSOVIEggQWBcgEBAQMBEgEdCjICCwwEAgEIEQQBAQEKBhcBBgFFCQgBAQQBEggBEgeHYAiYNQGeFYhIYwSIC5FNjE8 X-IronPort-AV: E=Sophos;i="4.69,459,1315180800"; d="scan'208";a="33578337" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 05 Nov 2011 05:34:27 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA55YRpH023015; Sat, 5 Nov 2011 05:34:27 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 5 Nov 2011 00:34:27 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Anhm BVEb Gjgb HS80 Iw3E LZwc Np1j S53z TC8w UAlI X6Fa diBh mKkI mlzi nQfZ sQ9L; 4; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtADsAbgBhAGIAaQBsAC4AbgAuAGIAaQB0AGEAcgBAAHYAZQByAGkAegBvAG4ALgBjAG8AbQA7AHIAbwBiAGUAcgB0AEAAcgBhAHMAegB1AGsALgBuAGUAdAA=; Sosha1_v1; 7; {B769E912-91EF-46B4-9F75-7C3E28EF5C1C}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sat, 05 Nov 2011 05:34:10 GMT; UgBFADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {B769E912-91EF-46B4-9F75-7C3E28EF5C1C} Content-class: urn:content-classes:message Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 Date: Sat, 5 Nov 2011 00:34:10 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CAAEE@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Index: AcybHdz+seIH48DeTI+MFjyOvqTq7gAKe6+Q References: <4EB2D29D.8000701@raszuk.net> From: "Luyuan Fang (lufang)" To: "Bitar, Nabil N" , , "Linda Dunbar" X-OriginalArrivalTime: 05 Nov 2011 05:34:27.0164 (UTC) FILETIME=[9565F9C0:01CC9B7C] Cc: L3VPN WG mailing list 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: Sat, 05 Nov 2011 05:34:29 -0000 Babil, Thanks for your comments, make sense. Similar as Pedro commented to Linda before, we were not dealing with one or two biz models, we are focusing on defining the underlying technologies. In this vpn4dc discussion, the underlying technology is L3VPN. It is L3VPN4DC to be precise, we tried to save letters when named it. :-) Appreciate your points on the general view. Here is what we see: We have networks, and data centers. The network may belong to a service provider, a content provider, or an enterprise. Same applies to the data centers.=20 The connectivity between networks and DC can be any combination of the above in terms of admin domain. Some combinations may be more common than the others. The technologies we are working on should support all scenarios. Thanks, Luyuan > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Bitar, Nabil N > Sent: Friday, November 04, 2011 2:16 PM > To: robert@raszuk.net; Linda Dunbar > Cc: L3VPN WG mailing list > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 >=20 > Hi, > I think what we need to be careful about assuming that the cloud > service > provider is the same as the VPN service provider, and in particular a > BGP/MPLS service provider. That is not to say that they cannot be the > same, but it is over-restrictive to assume that they are and if one > makes > that assumption the solution or attributes of a solution will not be > necessarily the same. Model #2 seems to assume that this is the case in > the way it is worded. >=20 > There are a number of ways in which #1 can be achieved, and one of > which > can be overlapping with model#2 per suggested modification. I think it > is > fine to define a model that defines a type or types of DC tenant > isolation (connectivity) that will be stitched to the tenant VPN WAN > service provided by a service provider. The tenant VPN service can be > focused on to be BGP/MPLS VPN provided by a service provider. The > tenant > connectivity within the data center can also be a BGP-MPLS VPN or an > IPsec > VPN or a layer2VPN, and one can focus on one, but I think we will find > that that at the connection between the data center and the tenant WAN > VPN > provided by a service provider, the problem will be the same. That is, > in > terms of stitching the two VPN services. If the service provider VPN is > integrated with that of data center, I think that will become a > degenerate > case. In addition, if there is no BGP/MPLS connectivity, and the > customer > is gaining access to the DC via an Ipsec tunnel starting from a > customer > CE and terminated in the data center, that will be transparent to the > VPN > service provider as a BGP MPLS service provider and I don't think in > that > case there is anything additional that should be done within the L3VPN > WG. >=20 > Thanks, > Nabil >=20 > On 11/3/11 1:42 PM, "Robert Raszuk" wrote: >=20 > >Linda, > > > > > Personally I don't think that we need to waste our time on Model #1 > > > for the following reasons: > > > >Personally I don't think we need to waste our time on solving Model #2 > >for one main reason - #2 is a subset of #1. If we solve #1 then #2 > get's > >solved automatically. > > > >Please note that IPSec access to provider's L3VPNs has been a > >commercialized and deployed feature years ago. > > > >-- > > > >I really think that if we have any desire to constructively move > forward > >in this space time spend on finding the flexible and universal > >auto-discovery tool for customer's network islands (be it VMs alone or > >L3VPNs sites/set of sides or even specific mobile users) is a > >prerequisite for any further work. > > > >Then we could worry about what tool to use to interconnect those > islands. > > > >Even if those islands (more and more dynamic in nature) would all > belong > >under one SP .. such SP would also largely benefit from ability to > >auto-discovery in real time needs to join or leave a VPN. Then the > >toolkit of choice could be triggered to add/delete a site, a user or a > >VM to/from given VPN via the orchestration system of his choice. > > > >To the best of my knowledge such dynamic VPN discovery tool has not > been > >invented yet. > > > >Best rgds, > >R. > > > > > > > >> Here is the fundamental question for the goal of VPN4DC: > >> > >> 1. Is VPN4DC to create mechanisms which make it possible to connect > >> hosts in any public data centers (e.g. Amazon' EC2) to hosts' > >> corresponding VPNs? Or > >> > >> 2. Is VPN4DC to create a solution which allows VPN service provider > >> to extend their VPN with computing service? In this model, customers > >> (i.e. VPN clients) see their computing resources being offloaded to > >> their VPN. Customers don't deal with data centers directly. > >> > >> > >> Personally I don't think that we need to waste our time on Model #1 > >> for the following reasons: - VPN service providers may not > even > >> have PEs in close proximity to "the public data centers" which > >> clients choose. If a VPN client has leased some computing resource > >> from a data center, the easiest way to connect them securely is by > >> IPSec tunnel. > >> > >> - Today Amazon already allows any hosts to be connected to > >> their chosen sites by IPSec (Amazon's VPC service). > >> > >> Model #2 gives VPN service providers an unique advantage of binding > >> valuable VPN services with virtual computing services, making it > >> more difficult for data centers who don't own network infrastructure > >> to compete. > >> > >> Do people agree? > >> > >> Linda > >> > >>> -----Original Message----- From: Luyuan Fang (lufang) > >>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41 > >>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > >>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > >>> > >>> Linda, > >>> > >>> Ben suggested that Ning and myself to work with co-authors of > >>> other problem statement drafts to come up with a combined view to > >>> be presented in Taipei meeting. The requirements drafts would be > >>> treated in the similar fashion. I plan to put gap analysis together > >>> with pb statement drafts. > >>> > >>> Though there would be no individual vpn4dc drafts presentations as > >>> in normal WG meetings, we welcome input on all three subjects from > >>> authors of vpn4dc related drafts, and everyone on the list. > >>> > >>> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was > >>> to gather feedback/input from the list, as the first step of > >>> meeting prep. > >>> > >>> Will get together with the authors of the relevant drafts to > >>> discuss soon, prefer we meet when Ning is back to office in a > >>> couple of days. Ping me if you cannot wait. > >>> > >>> Thanks, Luyuan > >>> > >>> > >>>> -----Original Message----- From: l3vpn-bounces@ietf.org > >>>> [mailto:l3vpn-bounces@ietf.org] On > >>> Behalf > >>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To: > >>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary > >>>> L3VPN/VPN4DC agenda @ IETF82 > >>>> > >>>> Who will lead the talk for each topic? > >>>> > >>>> Linda > >>>> > >>>>> -----Original Message----- From: l3vpn-bounces@ietf.org > >>>>> [mailto:l3vpn-bounces@ietf.org] On > >>>> Behalf > >>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 > >>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC > >>>>> agenda @ IETF82 > >>>>> > >>>>> Colleagues, > >>>>> > >>>>> Marshall& I have uploaded a preliminary L3VPN/VPN4DC agenda > >>>>> for > >>> IETF > >>>>> 82 in Taipei. You can find it here: > >>>>> > >>>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > >>>>> > >>>>> At the moment the agenda is a little vague because we are > >>>>> still > >>>> working > >>>>> with the VPN4DC proponents on who will lead each slot. > >>>>> > >>>>> We have purposely not put time on the agenda to > >>>>> present/discuss specific solution drafts as we would like the > >>>>> discussion to be > >>>> focussed > >>>>> on the problem/requirements posed by VPN4DC and its > >>>>> applicability > >>> to > >>>>> IETF (including L3VPN). Discussion of specific solution > >>>>> proposals > >>> can > >>>>> happen at future meetings if the VPN4DC work is adopted. > >>>>> > >>>>> Ben > >>>>> > >> > >> > >> From lufang@cisco.com Fri Nov 4 22:38:24 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 638EC21F8B55 for ; Fri, 4 Nov 2011 22:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.671 X-Spam-Level: X-Spam-Status: No, score=-4.671 tagged_above=-999 required=5 tests=[AWL=0.127, 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 0gunDXHLWbTC for ; Fri, 4 Nov 2011 22:38:22 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id D2B8821F8B54 for ; Fri, 4 Nov 2011 22:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=25443; q=dns/txt; s=iport; t=1320471501; x=1321681101; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=q6u+Nx/TWyqfh4qV8GcT6meRDnUdvB99/SCm1pTc8YE=; b=Y/cNPhyvAIpk5HT1UyDTGp64zUXl1Vw5OkoSkSysuytYichZUgwJ067m 9ZxsUU1x6AyMug3410jD0efeac1+Bh95YzEveF0KWi4wJiHGCKN8eD3fc 6Rf4EHRwWL0fKs1BUi6RLLW7yIpcUsPM45JJ9A/ZwXXutH5heU7UJx1Hr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMAABrLtE5Io8US/2dsb2JhbABDgk2XR45UgSCBBYFyAQEBBAEBAQ8BCREDPAILDAQCAQgOAwMBAQELBhAHAQYBJh8JCAEBBAESCAESB4domEgBnhWISGMEiAuRTYxP X-IronPort-AV: E=Sophos;i="4.69,459,1315180800"; d="scan'208,217";a="2460171" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-3.cisco.com with ESMTP; 05 Nov 2011 05:38:18 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA55cFYu014413; Sat, 5 Nov 2011 05:38:16 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); Sat, 5 Nov 2011 00:38:14 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: tUE= Ate0 C+rT IjMP JDxc KyIG LNDb RdCD R7VT VT88 WhBq XzeS a/Tn cM6x eQcJ g2aI; 3; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbABpAHoAaABvAC4AagBpAG4AQABnAG0AYQBpAGwALgBjAG8AbQA7AHIAbwBiAGUAcgB0AEAAcgBhAHMAegB1AGsALgBuAGUAdAA=; Sosha1_v1; 7; {D8C3DC4C-93F7-41FE-A31F-8108BBFD992F}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sat, 05 Nov 2011 05:38:01 GMT; UgBFADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9B7D.1CF8DE44" x-cr-puzzleid: {D8C3DC4C-93F7-41FE-A31F-8108BBFD992F} Content-class: urn:content-classes:message Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 Date: Sat, 5 Nov 2011 00:38:01 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CAAEF@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Index: AcybZ46hVuw8CQWyQo+gK203jRkfhQADWk5w References: From: "Luyuan Fang (lufang)" To: "Lizhong Jin" , X-OriginalArrivalTime: 05 Nov 2011 05:38:14.0898 (UTC) FILETIME=[1D236D20:01CC9B7D] Cc: robert@raszuk.net 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: Sat, 05 Nov 2011 05:38:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9B7D.1CF8DE44 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lizhong, =20 Just want to make sure we have a common understanding, we are not trying to stitch any types VPNs together here. We intend to work on L3VPN only per our initial VPN4DC BOF description. VLAN and PBB belong to L2VPN WG, where Nabil and Giles are chairs. =20 Thanks, Luyuan =20 From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, November 04, 2011 11:04 PM To: l3vpn@ietf.org Cc: robert@raszuk.net Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 =20 I tend to hold the same view as Nabil. The problem we can see now is "stitching the two VPN services". There will be various ways to implement VPN in datacenter, e.g, VLAN, PBB, VRF and etc. And I am not sure the cloud provider need a new kind of L3VPN in their datacenter? Whether setting up VPN in datacenter by network manager is a more easy and cost efficient way? Could anyone from cloud provider give some information? =20 Thanks Lizhong =20 =20 =09 ---------------------------------------------------------------------- =09 Message: 1 Date: Fri, 4 Nov 2011 14:16:19 -0400 From: "Bitar, Nabil N" To: "robert@raszuk.net" , Linda Dunbar Cc: L3VPN WG mailing list Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" =09 Hi, I think what we need to be careful about assuming that the cloud service provider is the same as the VPN service provider, and in particular a BGP/MPLS service provider. That is not to say that they cannot be the same, but it is over-restrictive to assume that they are and if one makes that assumption the solution or attributes of a solution will not be necessarily the same. Model #2 seems to assume that this is the case in the way it is worded. =09 There are a number of ways in which #1 can be achieved, and one of which can be overlapping with model#2 per suggested modification. I think it is fine to define a model that defines a type or types of DC tenant isolation (connectivity) that will be stitched to the tenant VPN WAN service provided by a service provider. The tenant VPN service can be focused on to be BGP/MPLS VPN provided by a service provider. The tenant connectivity within the data center can also be a BGP-MPLS VPN or an IPsec VPN or a layer2VPN, and one can focus on one, but I think we will find that that at the connection between the data center and the tenant WAN VPN provided by a service provider, the problem will be the same. That is, in terms of stitching the two VPN services. If the service provider VPN is integrated with that of data center, I think that will become a degenerate case. In addition, if there is no BGP/MPLS connectivity, and the customer is gaining access to the DC via an Ipsec tunnel starting from a customer CE and terminated in the data center, that will be transparent to the VPN service provider as a BGP MPLS service provider and I don't think in that case there is anything additional that should be done within the L3VPN WG. =09 Thanks, Nabil =09 On 11/3/11 1:42 PM, "Robert Raszuk" wrote: =09 >Linda, > > > Personally I don't think that we need to waste our time on Model #1 > > for the following reasons: > >Personally I don't think we need to waste our time on solving Model #2 >for one main reason - #2 is a subset of #1. If we solve #1 then #2 get's >solved automatically. > >Please note that IPSec access to provider's L3VPNs has been a >commercialized and deployed feature years ago. > >-- > >I really think that if we have any desire to constructively move forward >in this space time spend on finding the flexible and universal >auto-discovery tool for customer's network islands (be it VMs alone or >L3VPNs sites/set of sides or even specific mobile users) is a >prerequisite for any further work. > >Then we could worry about what tool to use to interconnect those islands. > >Even if those islands (more and more dynamic in nature) would all belong >under one SP .. such SP would also largely benefit from ability to >auto-discovery in real time needs to join or leave a VPN. Then the >toolkit of choice could be triggered to add/delete a site, a user or a >VM to/from given VPN via the orchestration system of his choice. > >To the best of my knowledge such dynamic VPN discovery tool has not been >invented yet. > >Best rgds, >R. > > > >> Here is the fundamental question for the goal of VPN4DC: >> >> 1. Is VPN4DC to create mechanisms which make it possible to connect >> hosts in any public data centers (e.g. Amazon' EC2) to hosts' >> corresponding VPNs? Or >> >> 2. Is VPN4DC to create a solution which allows VPN service provider >> to extend their VPN with computing service? In this model, customers >> (i.e. VPN clients) see their computing resources being offloaded to >> their VPN. Customers don't deal with data centers directly. >> >> >> Personally I don't think that we need to waste our time on Model #1 >> for the following reasons: - VPN service providers may not even >> have PEs in close proximity to "the public data centers" which >> clients choose. If a VPN client has leased some computing resource >> from a data center, the easiest way to connect them securely is by >> IPSec tunnel. >> >> - Today Amazon already allows any hosts to be connected to >> their chosen sites by IPSec (Amazon's VPC service). >> >> Model #2 gives VPN service providers an unique advantage of binding >> valuable VPN services with virtual computing services, making it >> more difficult for data centers who don't own network infrastructure >> to compete. >> >> Do people agree? >> >> Linda >> >>> -----Original Message----- From: Luyuan Fang (lufang) >>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41 >>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list >>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >>> >>> Linda, >>> >>> Ben suggested that Ning and myself to work with co-authors of >>> other problem statement drafts to come up with a combined view to >>> be presented in Taipei meeting. The requirements drafts would be >>> treated in the similar fashion. I plan to put gap analysis together >>> with pb statement drafts. >>> >>> Though there would be no individual vpn4dc drafts presentations as >>> in normal WG meetings, we welcome input on all three subjects from >>> authors of vpn4dc related drafts, and everyone on the list. >>> >>> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was >>> to gather feedback/input from the list, as the first step of >>> meeting prep. >>> >>> Will get together with the authors of the relevant drafts to >>> discuss soon, prefer we meet when Ning is back to office in a >>> couple of days. Ping me if you cannot wait. >>> >>> Thanks, Luyuan >>> >>> >>>> -----Original Message----- From: l3vpn-bounces@ietf.org >>>> [mailto:l3vpn-bounces@ietf.org] On >>> Behalf >>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To: >>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary >>>> L3VPN/VPN4DC agenda @ IETF82 >>>> >>>> Who will lead the talk for each topic? >>>> >>>> Linda >>>> >>>>> -----Original Message----- From: l3vpn-bounces@ietf.org >>>>> [mailto:l3vpn-bounces@ietf.org] On >>>> Behalf >>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 >>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC >>>>> agenda @ IETF82 >>>>> >>>>> Colleagues, >>>>> >>>>> Marshall& I have uploaded a preliminary L3VPN/VPN4DC agenda >>>>> for >>> IETF >>>>> 82 in Taipei. You can find it here: >>>>> >>>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt >>>>> >>>>> At the moment the agenda is a little vague because we are >>>>> still >>>> working >>>>> with the VPN4DC proponents on who will lead each slot. >>>>> >>>>> We have purposely not put time on the agenda to >>>>> present/discuss specific solution drafts as we would like the >>>>> discussion to be >>>> focussed >>>>> on the problem/requirements posed by VPN4DC and its >>>>> applicability >>> to >>>>> IETF (including L3VPN). Discussion of specific solution >>>>> proposals >>> can >>>>> happen at future meetings if the VPN4DC work is adopted. >>>>> >>>>> Ben >>>>> >> >> >> =09 =09 =09 ------------------------------ =09 _______________________________________________ L3VPN mailing list L3VPN@ietf.org https://www.ietf.org/mailman/listinfo/l3vpn =09 =09 End of L3VPN Digest, Vol 89, Issue 17 ************************************* =20 ------_=_NextPart_001_01CC9B7D.1CF8DE44 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lizhong,

 

Just want to make sure we have a common understanding, we = are not trying to stitch any types VPNs together here. We intend to work on = L3VPN only per our initial VPN4DC BOF description.

VLAN and PBB belong to L2VPN WG, where Nabil and Giles = are chairs.

 

Thanks,

Luyuan

 

From:= l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of = Lizhong Jin
Sent: Friday, November 04, 2011 11:04 PM
To: l3vpn@ietf.org
Cc: robert@raszuk.net
Subject: Re: Preliminary L3VPN/VPN4DC agenda @ = IETF82

 

I tend to hold the same view as Nabil. The problem = we can see now is "stitching the two VPN services". There will be = various ways to implement VPN in datacenter, e.g, VLAN, PBB, VRF and etc. And I = am not sure the cloud provider need a new kind of L3VPN in their = datacenter? Whether setting up VPN in datacenter by network manager is a more easy = and cost efficient way? Could anyone from cloud provider give some = information?

 

Thanks

Lizhong

 

 

-------------------------------------------------------= ---------------

Message: 1
Date: Fri, 4 Nov 2011 14:16:19 -0400
From: "Bitar, Nabil N" <nabil.n.bitar@verizon.com&g= t;
To: "robert@raszuk.net" <robert@raszuk.net>, Linda = Dunbar
       <linda.dunbar@huawei.com> Cc: L3VPN WG mailing list <l3vpn@ietf.org>
Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82
Message-ID: <CAD957A1.2C4B8= %nabil.n.bitar@verizon.com>
Content-Type: text/plain; charset=3D"us-ascii"

Hi,
I think what we need to be careful about assuming that the cloud = service
provider is the same as the VPN service provider, and in particular = a
BGP/MPLS service provider. That is not to say that they cannot be = the
same, but it is over-restrictive to assume that they are and if one = makes
that assumption the solution or attributes of a solution will not be
necessarily the same. Model #2 seems to assume that this is the case = in
the way it is worded.

There are a number of ways in which #1 can be achieved, and one of = which
can be overlapping with model#2 per suggested modification. I think it = is
fine to define a model that defines a type or types  of DC = tenant
isolation (connectivity)  that will be stitched to the tenant VPN = WAN
service provided by a service provider. The tenant VPN service can = be
focused on to be BGP/MPLS VPN provided by a service provider. The = tenant
connectivity within the data center can also be a BGP-MPLS VPN or an = IPsec
VPN or a layer2VPN, and one can focus on one, but I think we will = find
that that at the connection between the data center and the tenant WAN = VPN
provided by a service provider, the problem will be the same. That is, = in
terms of stitching the two VPN services. If the service provider VPN = is
integrated with that of data center, I think that will become a = degenerate
case. In addition, if there is no BGP/MPLS connectivity, and the = customer
is gaining access to the DC via an Ipsec tunnel starting from a = customer
CE and terminated in the data center, that will be transparent to the = VPN
service provider as a BGP MPLS service provider and I don't think in = that
case there is anything additional that should be done within the L3VPN = WG.

Thanks,
Nabil

On 11/3/11 1:42 PM, "Robert Raszuk" <robert@raszuk.net> wrote:

>Linda,
>
> > Personally I don't think that we need to waste our time on = Model #1
> > for the following reasons:
>
>Personally I don't think we need to waste our time on solving Model = #2
>for one main reason - #2 is a subset of #1. If we solve #1 then #2 = get's
>solved automatically.
>
>Please note that IPSec access to provider's L3VPNs has been a
>commercialized and deployed feature years ago.
>
>--
>
>I really think that if we have any desire to constructively move = forward
>in this space time spend on finding the flexible and universal
>auto-discovery tool for customer's network islands (be it VMs alone = or
>L3VPNs sites/set of sides or even specific mobile users) is a
>prerequisite for any further work.
>
>Then we could worry about what tool to use to interconnect those = islands.
>
>Even if those islands (more and more dynamic in nature) would all = belong
>under one SP .. such SP would also largely benefit from ability = to
>auto-discovery in real time needs to join or leave a VPN. Then = the
>toolkit of choice could be triggered to add/delete a site, a user or = a
>VM to/from given VPN via the orchestration system of his choice.
>
>To the best of my knowledge such dynamic VPN discovery tool has not = been
>invented yet.
>
>Best rgds,
>R.
>
>
>
>> Here is the fundamental question for the goal of VPN4DC:
>>
>> 1. Is VPN4DC to create mechanisms which make it possible to = connect
>> hosts in any public data centers (e.g. Amazon' EC2) to = hosts'
>> corresponding VPNs? Or
>>
>> 2. Is VPN4DC to create a solution which allows VPN service = provider
>> to extend their VPN with computing service? In this model, = customers
>> (i.e. VPN clients) see their computing resources being = offloaded to
>> their VPN. Customers don't deal with data centers directly.
>>
>>
>> Personally I don't think that we need to waste our time on = Model #1
>> for the following reasons: -       VPN service providers may not even
>> have PEs in close proximity to "the public data = centers" which
>> clients choose. If a VPN client has leased some computing = resource
>> from a data center, the easiest way to connect them securely is = by
>> IPSec tunnel.
>>
>> -       Today Amazon already allows any hosts to = be connected to
>> their chosen sites by IPSec (Amazon's VPC service).
>>
>> Model #2 gives VPN service providers an unique advantage of = binding
>> valuable VPN services with virtual computing services, =  making it
>> more difficult for data centers who don't own network = infrastructure
>> to compete.
>>
>> Do people agree?
>>
>> Linda
>>
>>> -----Original Message----- From: Luyuan Fang (lufang)
>>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41
>>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing = list
>>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82
>>>
>>> Linda,
>>>
>>> Ben suggested that Ning and myself to work with co-authors = of
>>> other problem statement drafts to come up with a combined = view to
>>> be presented in Taipei meeting. The requirements drafts = would be
>>> treated in the similar fashion. I plan to put gap analysis together
>>> with pb statement drafts.
>>>
>>> Though there would be no individual vpn4dc drafts = presentations as
>>> in normal WG meetings, we welcome input on all three = subjects from
>>> authors of vpn4dc related drafts, and everyone on the = list.
>>>
>>> In fact, the intent of vpn4dc Q&A I sent a couple of = days ago was
>>> to gather feedback/input from the list, as the first step = of
>>> meeting prep.
>>>
>>> Will get together with the authors of the relevant drafts = to
>>> discuss soon, prefer we meet when Ning is back to office in = a
>>> couple of days. Ping me if you cannot wait.
>>>
>>> Thanks, Luyuan
>>>
>>>
>>>> -----Original Message----- From: l3vpn-bounces@ietf.org
>>>> [mailto:l3vpn-bounces@ietf.org] On
>>> Behalf
>>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 = 10:56 PM To:
>>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary
>>>> L3VPN/VPN4DC agenda @ IETF82
>>>>
>>>> Who will lead the talk for each topic?
>>>>
>>>> Linda
>>>>
>>>>> -----Original Message----- From: l3vpn-bounces@ietf.org
>>>>> [mailto:l3vpn-bounces@ietf.org] On
>>>> Behalf
>>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, = 2011 1:01
>>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC
>>>>> agenda @ IETF82
>>>>>
>>>>> Colleagues,
>>>>>
>>>>> Marshall&  I have uploaded a preliminary L3VPN/VPN4DC agenda
>>>>> for
>>> IETF
>>>>> 82 in Taipei. You can find it here:
>>>>>
>>>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt=
>>>>>
>>>>> At the moment the agenda is a little vague because = we are
>>>>> still
>>>> working
>>>>> with the VPN4DC proponents on who will lead each = slot.
>>>>>
>>>>> We have purposely not put time on the agenda to
>>>>> present/discuss specific solution drafts as we = would like the
>>>>> discussion to be
>>>> focussed
>>>>> on the problem/requirements posed by VPN4DC and = its
>>>>> applicability
>>> to
>>>>> IETF (including L3VPN). Discussion of specific = solution
>>>>> proposals
>>> can
>>>>> happen at future meetings if the VPN4DC work is = adopted.
>>>>>
>>>>> Ben
>>>>>
>>
>>
>>



------------------------------

_______________________________________________
L3VPN mailing list
L3VPN@ietf.org
https://www.ietf.org/mailman/listinfo/l3vpn


End of L3VPN Digest, Vol 89, Issue 17
*************************************

 

------_=_NextPart_001_01CC9B7D.1CF8DE44-- From lufang@cisco.com Fri Nov 4 22:41: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 F261011E8073 for ; Fri, 4 Nov 2011 22:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.675 X-Spam-Level: X-Spam-Status: No, score=-4.675 tagged_above=-999 required=5 tests=[AWL=0.123, 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 O7ih7F1XmmZK for ; Fri, 4 Nov 2011 22:41:51 -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 A30C421F85A8 for ; Fri, 4 Nov 2011 22:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=32229; q=dns/txt; s=iport; t=1320471710; x=1321681310; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=CHRowVINJTcoiHjWxjKrBGRYdT5JvtyV76FybMxKPOA=; b=Z7ceuuTBBBXfN14dWXRl9SvR833pH63CUZ9IcjzBjvsH+1p9Nu5CYtPd feH+NOtFgHck5Ym8XPrfP6Iy1CFjKfA2dduZYLG31uPT3xgA3DbHc0lH8 j1B4mzTeFjper4elov6CNzLBT7qTOeFe4F0K6k4lRWjRsa5CzuUIWXDVY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoAACHMtE6tJV2a/2dsb2JhbAA9BoJNl0eNHYE3gSCBBYFyAQEBBBIBCREDPAIEBwwEAgEIDgMEAQELBhABBgEGAUUJCAEBBAESCAESB4domEMBnheGBYJDYwSIC5FNjE8 X-IronPort-AV: E=Sophos;i="4.69,459,1315180800"; d="scan'208,217";a="33585502" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 05 Nov 2011 05:41:49 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA55fnO1000407; Sat, 5 Nov 2011 05:41:49 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); Sat, 5 Nov 2011 00:41:49 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: BFUY BWPi EVs1 HZqf Knlt LDBH L63u XYqq Z7FV bl97 cP1Z hFs8 ijy+ i0rR lJhB q+ky; 5; YwBjAGkAZQAxADUANgA3ADIAQAB5AGEAaABvAG8ALgBjAG8AbQA7AGwAMwB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAaQBuAGQAYQAuAGQAdQBuAGIAYQByAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA7AG4AYQBiAGkAbAAuAG4ALgBiAGkAdABhAHIAQAB2AGUAcgBpAHoAbwBuAC4AYwBvAG0AOwByAG8AYgBlAHIAdABAAHIAYQBzAHoAdQBrAC4AbgBlAHQA; Sosha1_v1; 7; {7BC8F3AA-12F0-4D3E-8461-6F2A83EDB31D}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sat, 05 Nov 2011 05:41:33 GMT; UgBFADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9B7D.9CB202BC" x-cr-puzzleid: {7BC8F3AA-12F0-4D3E-8461-6F2A83EDB31D} Content-class: urn:content-classes:message Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 Date: Sat, 5 Nov 2011 00:41:33 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CAAF0@XMB-RCD-201.cisco.com> In-Reply-To: <1320458884.82254.YahooMailNeo@web161801.mail.bf1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Index: AcybX8dJX7F8CtVpS9OyEOTGf0TkCwAB26gA References: <4EB2D29D.8000701@raszuk.net> <1320458884.82254.YahooMailNeo@web161801.mail.bf1.yahoo.com> From: "Luyuan Fang (lufang)" To: "Derick Winkworth" , "Bitar, Nabil N" , , "Linda Dunbar" X-OriginalArrivalTime: 05 Nov 2011 05:41:49.0216 (UTC) FILETIME=[9CE1C200:01CC9B7D] Cc: L3VPN WG mailing list 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: Sat, 05 Nov 2011 05:41:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9B7D.9CB202BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Derick, =20 I believe your comments are toward http://tools.ietf.org/html/draft-ko-vaas-problem-statement-01 not toward Nabil's comments - which did not have direct relationship to the draft-ko-vaas from my reading.=20 =20 Regardless, I like the points you made. =20 The original intention of VPN4DC is to address L3VPN connectivity to DC VM networks.=20 The core set of the existing VPNs are BGP/MPLS VPNs, what you want seem to match the requests from several SPs and folks who operate those VPNs and providing cloud services. =20 Will follow up with a VPN4DC scope discussion. =20 Thanks, Luyuan =20 =20 From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Derick Winkworth Sent: Friday, November 04, 2011 10:08 PM To: Bitar, Nabil N; robert@raszuk.net; Linda Dunbar Cc: L3VPN WG mailing list Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 =20 I have read the VaaS document several times and I'm not seeing how it is relevant to VPN4DC. =20 =20 (1) These VMs are not mobile users on the internet.=20 (2) We are, in fact, creating network path isolation (with proper separation) for the VMs in the data center to/from their respective VRF. (3) No matter how great the software is that you are using on your host to establish the VPN... *my* customers, the reason I'm so interested in VPN4DC, do not want their servers exposed to the internet at any level. They want their servers effectively "jailed" in their L3VPN. there can be no dependency on software or configuration of the VM for its placement in their network. The vNIC is bound by path isolation to their private L3VPN. this is a not a unique or unusual requirement. (4) You are advocating VaaS as a replacement for MPLS (it would seem by your comments). I'm not interested in replacing MPLS. =20 =20 Feel free to correct or clarify any misunderstanding I may be suffering from... =20 =20 =20 =20 =20 ________________________________ From: "Bitar, Nabil N" To: "robert@raszuk.net" ; Linda Dunbar Cc: L3VPN WG mailing list Sent: Friday, November 4, 2011 1:16 PM Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Hi, I think what we need to be careful about assuming that the cloud service provider is the same as the VPN service provider, and in particular a BGP/MPLS service provider. That is not to say that they cannot be the same, but it is over-restrictive to assume that they are and if one makes that assumption the solution or attributes of a solution will not be necessarily the same. Model #2 seems to assume that this is the case in the way it is worded. There are a number of ways in which #1 can be achieved, and one of which can be overlapping with model#2 per suggested modification. I think it is fine to define a model that defines a type or types of DC tenant isolation (connectivity) that will be stitched to the tenant VPN WAN service provided by a service provider. The tenant VPN service can be focused on to be BGP/MPLS VPN provided by a service provider. The tenant connectivity within the data center can also be a BGP-MPLS VPN or an IPsec VPN or a layer2VPN, and one can focus on one, but I think we will find that that at the connection between the data center and the tenant WAN VPN provided by a service provider, the problem will be the same. That is, in terms of stitching the two VPN services. If the service provider VPN is integrated with that of data center, I think that will become a degenerate case. In addition, if there is no BGP/MPLS connectivity, and the customer is gaining access to the DC via an Ipsec tunnel starting from a customer CE and terminated in the data center, that will be transparent to the VPN service provider as a BGP MPLS service provider and I don't think in that case there is anything additional that should be done within the L3VPN WG. Thanks, Nabil On 11/3/11 1:42 PM, "Robert Raszuk" wrote: >Linda, > > > Personally I don't think that we need to waste our time on Model #1 > > for the following reasons: > >Personally I don't think we need to waste our time on solving Model #2 >for one main reason - #2 is a subset of #1. If we solve #1 then #2 get's >solved automatically. > >Please note that IPSec access to provider's L3VPNs has been a >commercialized and deployed feature years ago. > >-- > >I really think that if we have any desire to constructively move forward >in this space time spend on finding the flexible and universal >auto-discovery tool for customer's network islands (be it VMs alone or >L3VPNs sites/set of sides or even specific mobile users) is a >prerequisite for any further work. > >Then we could worry about what tool to use to interconnect those islands. > >Even if those islands (more and more dynamic in nature) would all belong >under one SP .. such SP would also largely benefit from ability to >auto-discovery in real time needs to join or leave a VPN. Then the >toolkit of choice could be triggered to add/delete a site, a user or a >VM to/from given VPN via the orchestration system of his choice. > >To the best of my knowledge such dynamic VPN discovery tool has not been >invented yet. > >Best rgds, >R. > > > >> Here is the fundamental question for the goal of VPN4DC: >> >> 1. Is VPN4DC to create mechanisms which make it possible to connect >> hosts in any public data centers (e.g. Amazon' EC2) to hosts' >> corresponding VPNs? Or >> >> 2. Is VPN4DC to create a solution which allows VPN service provider >> to extend their VPN with computing service? In this model, customers >> (i.e. VPN clients) see their computing resources being offloaded to >> their VPN. Customers don't deal with data centers directly. >> >> >> Personally I don't think that we need to waste our time on Model #1 >> for the following reasons: - VPN service providers may not even >> have PEs in close proximity to "the public data centers" which >> clients choose. If a VPN client has leased some computing resource >> from a data center, the easiest way to connect them securely is by >> IPSec tunnel. >> >> - Today Amazon already allows any hosts to be connected to >> their chosen sites by IPSec (Amazon's VPC service). >> >> Model #2 gives VPN service providers an unique advantage of binding >> valuable VPN services with virtual computing services, making it >> more difficult for data centers who don't own network infrastructure >> to compete. >> >> Do people agree? >> >> Linda >> >>> -----Original Message----- From: Luyuan Fang (lufang) >>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41 >>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list >>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >>> >>> Linda, >>> >>> Ben suggested that Ning and myself to work with co-authors of >>> other problem statement drafts to come up with a combined view to >>> be presented in Taipei meeting. The requirements drafts would be >>> treated in the similar fashion. I plan to put gap analysis together >>> with pb statement drafts. >>> >>> Though there would be no individual vpn4dc drafts presentations as >>> in normal WG meetings, we welcome input on all three subjects from >>> authors of vpn4dc related drafts, and everyone on the list. >>> >>> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was >>> to gather feedback/input from the list, as the first step of >>> meeting prep. >>> >>> Will get together with the authors of the relevant drafts to >>> discuss soon, prefer we meet when Ning is back to office in a >>> couple of days. Ping me if you cannot wait. >>> >>> Thanks, Luyuan >>> >>> >>>> -----Original Message----- From: l3vpn-bounces@ietf.org >>>> [mailto:l3vpn-bounces@ietf.org] On >>> Behalf >>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To: >>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary >>>> L3VPN/VPN4DC agenda @ IETF82 >>>> >>>> Who will lead the talk for each topic? >>>> >>>> Linda >>>> >>>>> -----Original Message----- From: l3vpn-bounces@ietf.org >>>>> [mailto:l3vpn-bounces@ietf.org] On >>>> Behalf >>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 >>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC >>>>> agenda @ IETF82 >>>>> >>>>> Colleagues, >>>>> >>>>> Marshall& I have uploaded a preliminary L3VPN/VPN4DC agenda >>>>> for >>> IETF >>>>> 82 in Taipei. You can find it here: >>>>> >>>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt >>>>> >>>>> At the moment the agenda is a little vague because we are >>>>> still >>>> working >>>>> with the VPN4DC proponents on who will lead each slot. >>>>> >>>>> We have purposely not put time on the agenda to >>>>> present/discuss specific solution drafts as we would like the >>>>> discussion to be >>>> focussed >>>>> on the problem/requirements posed by VPN4DC and its >>>>> applicability >>> to >>>>> IETF (including L3VPN). Discussion of specific solution >>>>> proposals >>> can >>>>> happen at future meetings if the VPN4DC work is adopted. >>>>> >>>>> Ben >>>>> >> >> >> ------_=_NextPart_001_01CC9B7D.9CB202BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Derick,

 =

I believe your comments are toward ht= tp://tools.ietf.org/html/draft-ko-vaas-problem-statement-01

not toward Nabil’s comments – which did not have direct = relationship to the draft-ko-vaas from my reading.

 =

Regardless,= I like the points you made.

 =

The original intention of VPN4DC= is to = address L3VPN connectivity to DC VM networks.

The core set of the existing VPNs are BGP/MPLS VPNs, what you want seem to = match the requests from several SPs and folks who operate those VPNs and providing = cloud services.

 =

Will follow up with a VPN4DC scope discussion.

 =

Thanks,

Luyuan=

 =

 

From:= l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of = Derick Winkworth
Sent: Friday, November 04, 2011 10:08 PM
To: Bitar, Nabil N; robert@raszuk.net; Linda Dunbar
Cc: L3VPN WG mailing list
Subject: Re: Preliminary L3VPN/VPN4DC agenda @ = IETF82

 

I have read the VaaS = document several times and I'm not seeing how it is relevant to VPN4DC. =  

 

(1) These VMs are not = mobile users on the internet. 

(2) We are, in fact, = creating network path isolation (with proper separation) for the VMs in the data = center to/from their respective VRF.

(3) No matter how great = the software is that you are using on your host to establish the VPN... *my* customers, the reason I'm so interested in VPN4DC, do not want their = servers exposed to the internet at any level.  They want their servers = effectively "jailed" in their L3VPN.  there can be no dependency on = software or configuration of the VM for its placement in their network.  The = vNIC is bound by path isolation to their private L3VPN.  this is a not a = unique or unusual requirement.

(4) You are advocating = VaaS as a replacement for MPLS (it would seem by your comments).  I'm not = interested in replacing MPLS.  

 

Feel free to correct or = clarify any misunderstanding I may be suffering from...

 

 

 

 

 

F= rom: "Bitar, Nabil N" <nabil.n.bitar@verizon.com>
To: "robert@raszuk.net" <robert@raszuk.net>; = Linda Dunbar <linda.dunbar@huawei.com>
Cc: L3VPN WG mailing list <l3vpn@ietf.org>
Sent: Friday, November 4, 2011 1:16 PM
Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82

Hi,
I think what we need to be careful about assuming that the cloud = service
provider is the same as the VPN service provider, and in particular = a
BGP/MPLS service provider. That is not to say that they cannot be = the
same, but it is over-restrictive to assume that they are and if one = makes
that assumption the solution or attributes of a solution will not be
necessarily the same. Model #2 seems to assume that this is the case = in
the way it is worded.

There are a number of ways in which #1 can be achieved, and one of = which
can be overlapping with model#2 per suggested modification. I think it = is
fine to define a model that defines a type or types  of DC = tenant
isolation (connectivity)  that will be stitched to the tenant VPN = WAN
service provided by a service provider. The tenant VPN service can = be
focused on to be BGP/MPLS VPN provided by a service provider. The = tenant
connectivity within the data center can also be a BGP-MPLS VPN or an = IPsec
VPN or a layer2VPN, and one can focus on one, but I think we will = find
that that at the connection between the data center and the tenant WAN = VPN
provided by a service provider, the problem will be the same. That is, = in
terms of stitching the two VPN services. If the service provider VPN = is
integrated with that of data center, I think that will become a = degenerate
case. In addition, if there is no BGP/MPLS connectivity, and the = customer
is gaining access to the DC via an Ipsec tunnel starting from a = customer
CE and terminated in the data center, that will be transparent to the = VPN
service provider as a BGP MPLS service provider and I don't think in = that
case there is anything additional that should be done within the L3VPN = WG.

Thanks,
Nabil

On 11/3/11 1:42 PM, "Robert Raszuk" <robert@raszuk.net> wrote:

>Linda,
>
> > Personally I don't think that we need to waste our time on = Model #1
> > for the following reasons:
>
>Personally I don't think we need to waste our time on solving Model = #2
>for one main reason - #2 is a subset of #1. If we solve #1 then #2 = get's
>solved automatically.
>
>Please note that IPSec access to provider's L3VPNs has been a
>commercialized and deployed feature years ago.
>
>--
>
>I really think that if we have any desire to constructively move = forward
>in this space time spend on finding the flexible and universal
>auto-discovery tool for customer's network islands (be it VMs alone = or
>L3VPNs sites/set of sides or even specific mobile users) is a
>prerequisite for any further work.
>
>Then we could worry about what tool to use to interconnect those = islands.
>
>Even if those islands (more and more dynamic in nature) would all = belong
>under one SP .. such SP would also largely benefit from ability = to
>auto-discovery in real time needs to join or leave a VPN. Then = the
>toolkit of choice could be triggered to add/delete a site, a user or = a
>VM to/from given VPN via the orchestration system of his choice.
>
>To the best of my knowledge such dynamic VPN discovery tool has not = been
>invented yet.
>
>Best rgds,
>R.
>
>
>
>> Here is the fundamental question for the goal of VPN4DC:
>>
>> 1. Is VPN4DC to create mechanisms which make it possible to = connect
>> hosts in any public data centers (e.g. Amazon' EC2) to = hosts'
>> corresponding VPNs? Or
>>
>> 2. Is VPN4DC to create a solution which allows VPN service = provider
>> to extend their VPN with computing service? In this model, = customers
>> (i.e. VPN clients) see their computing resources being = offloaded to
>> their VPN. Customers don't deal with data centers directly.
>>
>>
>> Personally I don't think that we need to waste our time on = Model #1
>> for the following reasons: -      VPN service = providers may not even
>> have PEs in close proximity to "the public data = centers" which
>> clients choose. If a VPN client has leased some computing = resource
>> from a data center, the easiest way to connect them securely is = by
>> IPSec tunnel.
>>
>> -      Today Amazon already allows any hosts to = be connected to
>> their chosen sites by IPSec (Amazon's VPC service).
>>
>> Model #2 gives VPN service providers an unique advantage of = binding
>> valuable VPN services with virtual computing services,  = making it
>> more difficult for data centers who don't own network = infrastructure
>> to compete.
>>
>> Do people agree?
>>
>> Linda
>>
>>> -----Original Message----- From: Luyuan Fang (lufang)
>>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41
>>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing = list
>>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82
>>>
>>> Linda,
>>>
>>> Ben suggested that Ning and myself to work with co-authors = of
>>> other problem statement drafts to come up with a combined = view to
>>> be presented in Taipei meeting. The requirements drafts = would be
>>> treated in the similar fashion. I plan to put gap analysis together
>>> with pb statement drafts.
>>>
>>> Though there would be no individual vpn4dc drafts = presentations as
>>> in normal WG meetings, we welcome input on all three = subjects from
>>> authors of vpn4dc related drafts, and everyone on the = list.
>>>
>>> In fact, the intent of vpn4dc Q&A I sent a couple of = days ago was
>>> to gather feedback/input from the list, as the first step = of
>>> meeting prep.
>>>
>>> Will get together with the authors of the relevant drafts = to
>>> discuss soon, prefer we meet when Ning is back to office in = a
>>> couple of days. Ping me if you cannot wait.
>>>
>>> Thanks, Luyuan
>>>
>>>
>>>> -----Original Message----- From: l3vpn-bounces@ietf.org
>>>> [mailto:l3vpn-bounces@ietf.org] On
>>> Behalf
>>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 = 10:56 PM To:
>>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary
>>>> L3VPN/VPN4DC agenda @ IETF82
>>>>
>>>> Who will lead the talk for each topic?
>>>>
>>>> Linda
>>>>
>>>>> -----Original Message----- From: l3vpn-bounces@ietf.org
>>>>> [mailto:l3vpn-bounces@ietf.org] On
>>>> Behalf
>>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, = 2011 1:01
>>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC
>>>>> agenda @ IETF82
>>>>>
>>>>> Colleagues,
>>>>>
>>>>> Marshall&  I have uploaded a preliminary L3VPN/VPN4DC agenda
>>>>> for
>>> IETF
>>>>> 82 in Taipei. You can find it here:
>>>>>
>>>>> = http://www.ietf.org/proceedings/82/agenda/l3vpn.txt
>>>>>
>>>>> At the moment the agenda is a little vague because = we are
>>>>> still
>>>> working
>>>>> with the VPN4DC proponents on who will lead each = slot.
>>>>>
>>>>> We have purposely not put time on the agenda to
>>>>> present/discuss specific solution drafts as we = would like the
>>>>> discussion to be
>>>> focussed
>>>>> on the problem/requirements posed by VPN4DC and = its
>>>>> applicability
>>> to
>>>>> IETF (including L3VPN). Discussion of specific = solution
>>>>> proposals
>>> can
>>>>> happen at future meetings if the VPN4DC work is = adopted.
>>>>>
>>>>> Ben
>>>>>
>>
>>
>>


------_=_NextPart_001_01CC9B7D.9CB202BC-- From lufang@cisco.com Fri Nov 4 23:25:35 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 9607011E8089 for ; Fri, 4 Nov 2011 23:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.979 X-Spam-Level: X-Spam-Status: No, score=-4.979 tagged_above=-999 required=5 tests=[AWL=0.419, 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 7g45GmEgHFDz for ; Fri, 4 Nov 2011 23:25:34 -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 2AD6011E8073 for ; Fri, 4 Nov 2011 23:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=10218; q=dns/txt; s=iport; t=1320474334; x=1321683934; h=mime-version:subject:date:message-id:from:to; bh=ICYzkw2C7Rand7QZMi4wbaflJqC5595YPt59D+6WM/0=; b=kaR//PTy9C5XMA/SEAOWJxVb8ULbUP7XV8Ri+yMR0RQHWslCk9HwbKPf e0pv6n4tiBl770jOOJetZqp1AmSpvQsyfDcK4gNQxLZ2TLPi99MY6W+Yi vG328CAaOJV38NO/O3FuBmzIEUtZPY1zFEl/QEH2ep0frmB99hbUzhIJn Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMrVtE6tJV2d/2dsb2JhbABCgk2nO4EFgXQBBBIBCREDWwEqBhgHQBcBBBsanlmBJgGeF4hIYwSIC5FNjE8 X-IronPort-AV: E=Sophos;i="4.69,459,1315180800"; d="scan'208,217";a="33557513" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2011 06:25:33 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pA56PXcG024307 for ; Sat, 5 Nov 2011 06:25: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); Sat, 5 Nov 2011 01:25:33 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: ATaC BWdh BqH8 Cnss CqjP Db1V E2T5 FRbf GgoA GyA3 HY4U Hil5 IALP KCGl KoIc LFk6; 1; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {D313A9EF-974B-456E-B0BD-195D532AE217}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sat, 05 Nov 2011 06:25:28 GMT; VgBQAE4ANABEAEMAIABTAGMAbwBwAGUA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9B83.B8EFD448" x-cr-puzzleid: {D313A9EF-974B-456E-B0BD-195D532AE217} Content-class: urn:content-classes:message Subject: VPN4DC Scope Date: Sat, 5 Nov 2011 01:25:28 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN4DC Scope Thread-Index: Acybg7Xre36EuiLJTVqFN1kI+DCFUQ== From: "Luyuan Fang (lufang)" To: X-OriginalArrivalTime: 05 Nov 2011 06:25:33.0508 (UTC) FILETIME=[B914F040:01CC9B83] 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: Sat, 05 Nov 2011 06:25:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9B83.B8EFD448 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear colleagues, =20 Thank you all for the constructive discussion/suggestions over the last few weeks on VPN4DC.=20 =20 I think we observed good interests/enthusiasm on solving the problems in this space.=20 =20 We need to narrow down the scope as the next step. I summarized the proposals sent on the list as the following: =20 =20 1. Leverage BGP/MPLS VPN technologies, extending it with l3vpn signaling protocols into DC VM virtual networks. 2. Using BGP/MPLS VPN exactly 'as it is' into DC VM virtual networks 3. Extending/creating any IP VPN technologies into DC=20 4. Extending/creating or reuse/managing security protocols for DC connections, including encryption, key distribution, key management 5. Extending/creating or reuse L2VPN based technologies into DC=20 =20 Some of you prefer to focus on one of the options, while others like to include multiple options. =20 Here is my observation and thought. =20 1 - It seems a common denominator. Did not hear no on this. It is exactly the problem Derick wanting to solve, it is Ning's starting point, and it is included in the requirements drafts. 2 - It does not need to create or extend protocols, should go to Operation and Management Area for any ops issues and best practice. 3 - The scope looks big to me, the list is potentially very long. 4 - If new encryption algorithm, better key distribution mechanism are needed, the work should go to Security Area; if nothing new, ops issues go to Operation and Management Area. 5 - L2VPN for DC work should go to L2VPN WG, it is defined in L2VPN charter. =20 Thanks, Luyuan ------_=_NextPart_001_01CC9B83.B8EFD448 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear colleagues,

 

Thank you all for the constructive = discussion/suggestions over the last few weeks on VPN4DC.

 

I think we observed good interests/enthusiasm on = solving the problems in this space.

 

We need to narrow down the scope as the next = step.

I summarized the proposals sent on the list as the = following:  

 

1.      Leverage BGP/MPLS VPN technologies, extending it with l3vpn signaling protocols = into DC VM virtual networks.

2.      Using BGP/MPLS VPN exactly ‘as it is’ into DC VM virtual = networks

3.      Extending/creating any IP VPN technologies into DC

4.      Extending/creating or reuse/managing security protocols for DC connections, including = encryption, key distribution, key management

5.      Extending/creating or reuse L2VPN based technologies into DC

 

Some of you prefer to focus on one of the options, = while others like to include multiple options.

 

Here is my observation and thought.

 

1 – It seems a common denominator. Did not = hear no on this.  It is exactly the problem Derick wanting to solve, it is = Ning’s starting point, and it is included in the requirements = drafts.

2 – It does not need to create or extend = protocols, should go to Operation and Management Area for any ops issues and best = practice.

3 - The scope looks big to me, the list is = potentially very long.

4 - If new encryption algorithm, better key = distribution mechanism are needed,  the work should go to Security Area; if nothing new, = ops issues go to Operation and Management Area.

5 - L2VPN for DC work should go to L2VPN WG, it is = defined in L2VPN charter.

 

Thanks,

Luyuan

------_=_NextPart_001_01CC9B83.B8EFD448-- From lufang@cisco.com Fri Nov 4 23:26: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 A9E3921F8B76 for ; Fri, 4 Nov 2011 23:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.693 X-Spam-Level: X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, GB_I_LETTER=-2, 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 MbnVW5qqdDvA for ; Fri, 4 Nov 2011 23:26:49 -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 80E1721F8B6E for ; Fri, 4 Nov 2011 23:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=9515; q=dns/txt; s=iport; t=1320474409; x=1321684009; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Tsp+eT87fIQm3Ca11H32vNnHyv1rXqH9+CEbOCL0vaM=; b=RJ4PBFHcpA+OxhrWROPXSRCXRXKO7uNadskDv/iPmyRMGYXDzreoOD5S oU0taOnB6PghNaRnUFUdIjCadgXyYioqA9s3rRCC9sbUZG6E+0lFqwaPs d1PB97ArRllsTu4KLL+qXlzuEChFf5mcAp7q4QRvJ/SwXWpiIDTaGnVzb s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMAAFfWtE6tJXG8/2dsb2JhbABCmhSOVIEggQWBcgEBAQQSAR0KMgILDAQCAQgRBAEBAQoGFwEGAUUJCAEBBAESCAESB4domBgBnhiISGMEiAuRTYxP X-IronPort-AV: E=Sophos;i="4.69,459,1315180800"; d="scan'208";a="33568146" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 05 Nov 2011 06:26:49 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA56QmmE004001; Sat, 5 Nov 2011 06:26:48 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); Sat, 5 Nov 2011 01:26:48 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AThW FBSM GRgB NiaR N80i SJNp Sk4j VIi+ W7Sd dj+0 d5fE f3M2 iH4n je+7 k8lp mLM1; 4; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbABpAG4AZABhAC4AZAB1AG4AYgBhAHIAQABoAHUAYQB3AGUAaQAuAGMAbwBtADsAbgBhAGIAaQBsAC4AbgAuAGIAaQB0AGEAcgBAAHYAZQByAGkAegBvAG4ALgBjAG8AbQA7AHIAbwBiAGUAcgB0AEAAcgBhAHMAegB1AGsALgBuAGUAdAA=; Sosha1_v1; 7; {53BE715C-031C-49F9-91AD-92E846F12B5F}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sat, 05 Nov 2011 06:26:35 GMT; UgBFADoAIABQAHIAZQBsAGkAbQBpAG4AYQByAHkAIABMADMAVgBQAE4ALwBWAFAATgA0AEQAQwAgAGEAZwBlAG4AZABhACAAQAAgAEkARQBUAEYAOAAyAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {53BE715C-031C-49F9-91AD-92E846F12B5F} Content-class: urn:content-classes:message Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 Date: Sat, 5 Nov 2011 01:26:35 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25073CAAF2@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E25073CAAEE@XMB-RCD-201.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Index: AcybHdz+seIH48DeTI+MFjyOvqTq7gAKe6+QAA78eiA= References: <4EB2D29D.8000701@raszuk.net> <238542D917511A45B6B8AA806E875E25073CAAEE@XMB-RCD-201.cisco.com> From: "Luyuan Fang (lufang)" To: "Bitar, Nabil N" , , "Linda Dunbar" X-OriginalArrivalTime: 05 Nov 2011 06:26:48.0575 (UTC) FILETIME=[E5D340F0:01CC9B83] Cc: L3VPN WG mailing list 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: Sat, 05 Nov 2011 06:26:50 -0000 Sorry about my typo, Nabil. > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Luyuan Fang (lufang) > Sent: Saturday, November 05, 2011 1:34 AM > To: Bitar, Nabil N; robert@raszuk.net; Linda Dunbar > Cc: L3VPN WG mailing list > Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >=20 > Babil, >=20 > Thanks for your comments, make sense. >=20 > Similar as Pedro commented to Linda before, we were not dealing with > one > or two biz models, we are focusing on defining the underlying > technologies. In this vpn4dc discussion, the underlying technology is > L3VPN. It is L3VPN4DC to be precise, we tried to save letters when > named > it. :-) >=20 > Appreciate your points on the general view. Here is what we see: >=20 > We have networks, and data centers. > The network may belong to a service provider, a content provider, or an > enterprise. Same applies to the data centers. > The connectivity between networks and DC can be any combination of the > above in terms of admin domain. Some combinations may be more common > than the others. >=20 > The technologies we are working on should support all scenarios. >=20 > Thanks, > Luyuan >=20 >=20 > > -----Original Message----- > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > Behalf > > Of Bitar, Nabil N > > Sent: Friday, November 04, 2011 2:16 PM > > To: robert@raszuk.net; Linda Dunbar > > Cc: L3VPN WG mailing list > > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > > > Hi, > > I think what we need to be careful about assuming that the cloud > > service > > provider is the same as the VPN service provider, and in particular a > > BGP/MPLS service provider. That is not to say that they cannot be the > > same, but it is over-restrictive to assume that they are and if one > > makes > > that assumption the solution or attributes of a solution will not be > > necessarily the same. Model #2 seems to assume that this is the case > in > > the way it is worded. > > > > There are a number of ways in which #1 can be achieved, and one of > > which > > can be overlapping with model#2 per suggested modification. I think > it > > is > > fine to define a model that defines a type or types of DC tenant > > isolation (connectivity) that will be stitched to the tenant VPN WAN > > service provided by a service provider. The tenant VPN service can be > > focused on to be BGP/MPLS VPN provided by a service provider. The > > tenant > > connectivity within the data center can also be a BGP-MPLS VPN or an > > IPsec > > VPN or a layer2VPN, and one can focus on one, but I think we will > find > > that that at the connection between the data center and the tenant > WAN > > VPN > > provided by a service provider, the problem will be the same. That > is, > > in > > terms of stitching the two VPN services. If the service provider VPN > is > > integrated with that of data center, I think that will become a > > degenerate > > case. In addition, if there is no BGP/MPLS connectivity, and the > > customer > > is gaining access to the DC via an Ipsec tunnel starting from a > > customer > > CE and terminated in the data center, that will be transparent to the > > VPN > > service provider as a BGP MPLS service provider and I don't think in > > that > > case there is anything additional that should be done within the > L3VPN > > WG. > > > > Thanks, > > Nabil > > > > On 11/3/11 1:42 PM, "Robert Raszuk" wrote: > > > > >Linda, > > > > > > > Personally I don't think that we need to waste our time on Model > #1 > > > > for the following reasons: > > > > > >Personally I don't think we need to waste our time on solving Model > #2 > > >for one main reason - #2 is a subset of #1. If we solve #1 then #2 > > get's > > >solved automatically. > > > > > >Please note that IPSec access to provider's L3VPNs has been a > > >commercialized and deployed feature years ago. > > > > > >-- > > > > > >I really think that if we have any desire to constructively move > > forward > > >in this space time spend on finding the flexible and universal > > >auto-discovery tool for customer's network islands (be it VMs alone > or > > >L3VPNs sites/set of sides or even specific mobile users) is a > > >prerequisite for any further work. > > > > > >Then we could worry about what tool to use to interconnect those > > islands. > > > > > >Even if those islands (more and more dynamic in nature) would all > > belong > > >under one SP .. such SP would also largely benefit from ability to > > >auto-discovery in real time needs to join or leave a VPN. Then the > > >toolkit of choice could be triggered to add/delete a site, a user or > a > > >VM to/from given VPN via the orchestration system of his choice. > > > > > >To the best of my knowledge such dynamic VPN discovery tool has not > > been > > >invented yet. > > > > > >Best rgds, > > >R. > > > > > > > > > > > >> Here is the fundamental question for the goal of VPN4DC: > > >> > > >> 1. Is VPN4DC to create mechanisms which make it possible to > connect > > >> hosts in any public data centers (e.g. Amazon' EC2) to hosts' > > >> corresponding VPNs? Or > > >> > > >> 2. Is VPN4DC to create a solution which allows VPN service > provider > > >> to extend their VPN with computing service? In this model, > customers > > >> (i.e. VPN clients) see their computing resources being offloaded > to > > >> their VPN. Customers don't deal with data centers directly. > > >> > > >> > > >> Personally I don't think that we need to waste our time on Model > #1 > > >> for the following reasons: - VPN service providers may not > > even > > >> have PEs in close proximity to "the public data centers" which > > >> clients choose. If a VPN client has leased some computing resource > > >> from a data center, the easiest way to connect them securely is by > > >> IPSec tunnel. > > >> > > >> - Today Amazon already allows any hosts to be connected to > > >> their chosen sites by IPSec (Amazon's VPC service). > > >> > > >> Model #2 gives VPN service providers an unique advantage of > binding > > >> valuable VPN services with virtual computing services, making it > > >> more difficult for data centers who don't own network > infrastructure > > >> to compete. > > >> > > >> Do people agree? > > >> > > >> Linda > > >> > > >>> -----Original Message----- From: Luyuan Fang (lufang) > > >>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 > 11:41 > > >>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > > >>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > > >>> > > >>> Linda, > > >>> > > >>> Ben suggested that Ning and myself to work with co-authors of > > >>> other problem statement drafts to come up with a combined view to > > >>> be presented in Taipei meeting. The requirements drafts would be > > >>> treated in the similar fashion. I plan to put gap analysis > together > > >>> with pb statement drafts. > > >>> > > >>> Though there would be no individual vpn4dc drafts presentations > as > > >>> in normal WG meetings, we welcome input on all three subjects > from > > >>> authors of vpn4dc related drafts, and everyone on the list. > > >>> > > >>> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was > > >>> to gather feedback/input from the list, as the first step of > > >>> meeting prep. > > >>> > > >>> Will get together with the authors of the relevant drafts to > > >>> discuss soon, prefer we meet when Ning is back to office in a > > >>> couple of days. Ping me if you cannot wait. > > >>> > > >>> Thanks, Luyuan > > >>> > > >>> > > >>>> -----Original Message----- From: l3vpn-bounces@ietf.org > > >>>> [mailto:l3vpn-bounces@ietf.org] On > > >>> Behalf > > >>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To: > > >>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: > Preliminary > > >>>> L3VPN/VPN4DC agenda @ IETF82 > > >>>> > > >>>> Who will lead the talk for each topic? > > >>>> > > >>>> Linda > > >>>> > > >>>>> -----Original Message----- From: l3vpn-bounces@ietf.org > > >>>>> [mailto:l3vpn-bounces@ietf.org] On > > >>>> Behalf > > >>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 > > >>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC > > >>>>> agenda @ IETF82 > > >>>>> > > >>>>> Colleagues, > > >>>>> > > >>>>> Marshall& I have uploaded a preliminary L3VPN/VPN4DC agenda > > >>>>> for > > >>> IETF > > >>>>> 82 in Taipei. You can find it here: > > >>>>> > > >>>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > >>>>> > > >>>>> At the moment the agenda is a little vague because we are > > >>>>> still > > >>>> working > > >>>>> with the VPN4DC proponents on who will lead each slot. > > >>>>> > > >>>>> We have purposely not put time on the agenda to > > >>>>> present/discuss specific solution drafts as we would like the > > >>>>> discussion to be > > >>>> focussed > > >>>>> on the problem/requirements posed by VPN4DC and its > > >>>>> applicability > > >>> to > > >>>>> IETF (including L3VPN). Discussion of specific solution > > >>>>> proposals > > >>> can > > >>>>> happen at future meetings if the VPN4DC work is adopted. > > >>>>> > > >>>>> Ben > > >>>>> > > >> > > >> > > >> From lizho.jin@gmail.com Sat Nov 5 06:51: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 B771921F869E for ; Sat, 5 Nov 2011 06:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.489, 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_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 r4ybM3MHk5np for ; Sat, 5 Nov 2011 06:51:04 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18F8C21F861E for ; Sat, 5 Nov 2011 06:51:03 -0700 (PDT) Received: by qadc10 with SMTP id c10so3518684qad.31 for ; Sat, 05 Nov 2011 06:51:03 -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=Zo/RxMMtL55IH+5RunxNAmAMdwInJ3uY5fBR0pF147s=; b=glkOOihwkxqDFUw4Ddnm5sj8E9Oa451cgiSQBlSv9WuJJd4FRpSuYdY6ijptdM5XPD EiiNEpr/QeIq60WJWzwDUsireWc+rJKE5ugVXjyp9g/1+o4g3rMQJIyR/BII1HhxarZf uucaaYxml9Ppcz1QoZPqAvM99wd3/clB17I2U= MIME-Version: 1.0 Received: by 10.224.199.134 with SMTP id es6mr9536011qab.2.1320501063419; Sat, 05 Nov 2011 06:51:03 -0700 (PDT) Received: by 10.224.54.147 with HTTP; Sat, 5 Nov 2011 06:51:03 -0700 (PDT) In-Reply-To: <238542D917511A45B6B8AA806E875E25073CAAEF@XMB-RCD-201.cisco.com> References: <238542D917511A45B6B8AA806E875E25073CAAEF@XMB-RCD-201.cisco.com> Date: Sat, 5 Nov 2011 21:51:03 +0800 Message-ID: Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 From: Lizhong Jin To: "Luyuan Fang (lufang)" Content-Type: multipart/alternative; boundary=20cf300fb241cf86dc04b0fd1cae Cc: l3vpn@ietf.org, robert@raszuk.net 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: Sat, 05 Nov 2011 13:51:05 -0000 --20cf300fb241cf86dc04b0fd1cae Content-Type: text/plain; charset=ISO-8859-1 Luyuan, Yes, agree with the VPN4DC scope, to focus only on L3VPN. Regards Lizhong 2011/11/5 Luyuan Fang (lufang) > Lizhong,**** > > ** ** > > Just want to make sure we have a common understanding, we are not trying > to stitch any types VPNs together here. We intend to work on L3VPN only per > our initial VPN4DC BOF description.**** > > VLAN and PBB belong to L2VPN WG, where Nabil and Giles are chairs.**** > > ** ** > > Thanks,**** > > Luyuan**** > > ** ** > > *From:* l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] *On Behalf > Of *Lizhong Jin > *Sent:* Friday, November 04, 2011 11:04 PM > *To:* l3vpn@ietf.org > *Cc:* robert@raszuk.net > > *Subject:* Re: Preliminary L3VPN/VPN4DC agenda @ IETF82**** > > ** ** > > I tend to hold the same view as Nabil. The problem we can see now is > "stitching the two VPN services". There will be various ways to implement > VPN in datacenter, e.g, VLAN, PBB, VRF and etc. And I am not sure the cloud > provider need a new kind of L3VPN in their datacenter? Whether setting up > VPN in datacenter by network manager is a more easy and cost efficient way? > Could anyone from cloud provider give some information?**** > > **** > > Thanks**** > > Lizhong**** > > **** > > **** > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 4 Nov 2011 14:16:19 -0400 > From: "Bitar, Nabil N" > To: "robert@raszuk.net" , Linda Dunbar > > Cc: L3VPN WG mailing list > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi, > I think what we need to be careful about assuming that the cloud service > provider is the same as the VPN service provider, and in particular a > BGP/MPLS service provider. That is not to say that they cannot be the > same, but it is over-restrictive to assume that they are and if one makes > that assumption the solution or attributes of a solution will not be > necessarily the same. Model #2 seems to assume that this is the case in > the way it is worded. > > There are a number of ways in which #1 can be achieved, and one of which > can be overlapping with model#2 per suggested modification. I think it is > fine to define a model that defines a type or types of DC tenant > isolation (connectivity) that will be stitched to the tenant VPN WAN > service provided by a service provider. The tenant VPN service can be > focused on to be BGP/MPLS VPN provided by a service provider. The tenant > connectivity within the data center can also be a BGP-MPLS VPN or an IPsec > VPN or a layer2VPN, and one can focus on one, but I think we will find > that that at the connection between the data center and the tenant WAN VPN > provided by a service provider, the problem will be the same. That is, in > terms of stitching the two VPN services. If the service provider VPN is > integrated with that of data center, I think that will become a degenerate > case. In addition, if there is no BGP/MPLS connectivity, and the customer > is gaining access to the DC via an Ipsec tunnel starting from a customer > CE and terminated in the data center, that will be transparent to the VPN > service provider as a BGP MPLS service provider and I don't think in that > case there is anything additional that should be done within the L3VPN WG. > > Thanks, > Nabil > > On 11/3/11 1:42 PM, "Robert Raszuk" wrote: > > >Linda, > > > > > Personally I don't think that we need to waste our time on Model #1 > > > for the following reasons: > > > >Personally I don't think we need to waste our time on solving Model #2 > >for one main reason - #2 is a subset of #1. If we solve #1 then #2 get's > >solved automatically. > > > >Please note that IPSec access to provider's L3VPNs has been a > >commercialized and deployed feature years ago. > > > >-- > > > >I really think that if we have any desire to constructively move forward > >in this space time spend on finding the flexible and universal > >auto-discovery tool for customer's network islands (be it VMs alone or > >L3VPNs sites/set of sides or even specific mobile users) is a > >prerequisite for any further work. > > > >Then we could worry about what tool to use to interconnect those islands. > > > >Even if those islands (more and more dynamic in nature) would all belong > >under one SP .. such SP would also largely benefit from ability to > >auto-discovery in real time needs to join or leave a VPN. Then the > >toolkit of choice could be triggered to add/delete a site, a user or a > >VM to/from given VPN via the orchestration system of his choice. > > > >To the best of my knowledge such dynamic VPN discovery tool has not been > >invented yet. > > > >Best rgds, > >R. > > > > > > > >> Here is the fundamental question for the goal of VPN4DC: > >> > >> 1. Is VPN4DC to create mechanisms which make it possible to connect > >> hosts in any public data centers (e.g. Amazon' EC2) to hosts' > >> corresponding VPNs? Or > >> > >> 2. Is VPN4DC to create a solution which allows VPN service provider > >> to extend their VPN with computing service? In this model, customers > >> (i.e. VPN clients) see their computing resources being offloaded to > >> their VPN. Customers don't deal with data centers directly. > >> > >> > >> Personally I don't think that we need to waste our time on Model #1 > >> for the following reasons: - VPN service providers may not even > >> have PEs in close proximity to "the public data centers" which > >> clients choose. If a VPN client has leased some computing resource > >> from a data center, the easiest way to connect them securely is by > >> IPSec tunnel. > >> > >> - Today Amazon already allows any hosts to be connected to > >> their chosen sites by IPSec (Amazon's VPC service). > >> > >> Model #2 gives VPN service providers an unique advantage of binding > >> valuable VPN services with virtual computing services, making it > >> more difficult for data centers who don't own network infrastructure > >> to compete. > >> > >> Do people agree? > >> > >> Linda > >> > >>> -----Original Message----- From: Luyuan Fang (lufang) > >>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41 > >>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list > >>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 > >>> > >>> Linda, > >>> > >>> Ben suggested that Ning and myself to work with co-authors of > >>> other problem statement drafts to come up with a combined view to > >>> be presented in Taipei meeting. The requirements drafts would be > >>> treated in the similar fashion. I plan to put gap analysis together > >>> with pb statement drafts. > >>> > >>> Though there would be no individual vpn4dc drafts presentations as > >>> in normal WG meetings, we welcome input on all three subjects from > >>> authors of vpn4dc related drafts, and everyone on the list. > >>> > >>> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was > >>> to gather feedback/input from the list, as the first step of > >>> meeting prep. > >>> > >>> Will get together with the authors of the relevant drafts to > >>> discuss soon, prefer we meet when Ning is back to office in a > >>> couple of days. Ping me if you cannot wait. > >>> > >>> Thanks, Luyuan > >>> > >>> > >>>> -----Original Message----- From: l3vpn-bounces@ietf.org > >>>> [mailto:l3vpn-bounces@ietf.org] On > >>> Behalf > >>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To: > >>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary > >>>> L3VPN/VPN4DC agenda @ IETF82 > >>>> > >>>> Who will lead the talk for each topic? > >>>> > >>>> Linda > >>>> > >>>>> -----Original Message----- From: l3vpn-bounces@ietf.org > >>>>> [mailto:l3vpn-bounces@ietf.org] On > >>>> Behalf > >>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 > >>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC > >>>>> agenda @ IETF82 > >>>>> > >>>>> Colleagues, > >>>>> > >>>>> Marshall& I have uploaded a preliminary L3VPN/VPN4DC agenda > >>>>> for > >>> IETF > >>>>> 82 in Taipei. You can find it here: > >>>>> > >>>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > >>>>> > >>>>> At the moment the agenda is a little vague because we are > >>>>> still > >>>> working > >>>>> with the VPN4DC proponents on who will lead each slot. > >>>>> > >>>>> We have purposely not put time on the agenda to > >>>>> present/discuss specific solution drafts as we would like the > >>>>> discussion to be > >>>> focussed > >>>>> on the problem/requirements posed by VPN4DC and its > >>>>> applicability > >>> to > >>>>> IETF (including L3VPN). Discussion of specific solution > >>>>> proposals > >>> can > >>>>> happen at future meetings if the VPN4DC work is adopted. > >>>>> > >>>>> Ben > >>>>> > >> > >> > >> > > > > ------------------------------ > > _______________________________________________ > L3VPN mailing list > L3VPN@ietf.org > https://www.ietf.org/mailman/listinfo/l3vpn > > > End of L3VPN Digest, Vol 89, Issue 17 > ***************************************** > > ** ** > --20cf300fb241cf86dc04b0fd1cae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Luyuan,
Yes, agree with the VPN4DC=A0scope, to focus only on L3VPN.
=A0
Regards
Lizhong

2011/11/5 Luyuan Fang (lufang) <lufang@cisco.com>

Lizh= ong,

<= /u>=A0

Just= want to make sure we have a common understanding, we are not trying to sti= tch any types VPNs together here. We intend to work on L3VPN only per our i= nitial VPN4DC BOF description.

VLAN= and PBB belong to L2VPN WG, where Nabil and Giles are chairs.

<= /u>=A0

Than= ks,

Luyu= an

<= /u>=A0

From:<= span style=3D"FONT-SIZE: 10pt"> l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Beha= lf Of Lizhong Jin
Sent: Friday, November 04, 2011 11:04 PM
To: l3vpn@ietf.org
Cc: robert@raszuk.net= =20


Subject: Re: Preliminary L3VPN/VPN4DC agenda @= IETF82

=A0

I tend to hold the same view as Nabil. The problem w= e can see now is "stitching the two VPN services". There will be = various ways to implement VPN in datacenter, e.g, VLAN, PBB, VRF and etc. A= nd I am not sure=A0the cloud provider need a new kind of L3VPN in their dat= acenter? Whether setting up VPN in datacenter by network manager is a more = easy and cost efficient way? Could anyone from cloud provider give some inf= ormation?

=A0

Thanks

Lizhong

=A0

=A0

----------------------------------------------------= ------------------

Message: 1
Date: Fri, 4 Nov 2011 14:16:19 -040= 0
From: "Bitar, Nabil N" <nabil.n.bitar@verizon.com>
To: "robert@ras= zuk.net" <robert@raszuk.net>, Linda Dunbar
=A0 =A0 =A0 =A0<linda.dunbar@huawei.com>
Cc: L3VPN WG mailing list <l3vpn@ietf.org>
Subject: Re: Preliminary L3VPN/VPN4DC agen= da @ IETF82
Message-ID: <CAD957A1.2C4B8%nabil.n.bitar@verizon.co= m>
Content-Type: text/plain; charset=3D"us-ascii"

Hi,
I th= ink what we need to be careful about assuming that the cloud service
pro= vider is the same as the VPN service provider, and in particular a
BGP/M= PLS service provider. That is not to say that they cannot be the
same, but it is over-restrictive to assume that they are and if one makesthat assumption the solution or attributes of a solution will not be
n= ecessarily the same. Model #2 seems to assume that this is the case in
the way it is worded.

There are a number of ways in which #1 can be = achieved, and one of which
can be overlapping with model#2 per suggested= modification. I think it is
fine to define a model that defines a type = or types =A0of DC tenant
isolation (connectivity) =A0that will be stitched to the tenant VPN WAN
= service provided by a service provider. The tenant VPN service can be
fo= cused on to be BGP/MPLS VPN provided by a service provider. The tenant
connectivity within the data center can also be a BGP-MPLS VPN or an IPsec<= br>VPN or a layer2VPN, and one can focus on one, but I think we will findthat that at the connection between the data center and the tenant WAN VP= N
provided by a service provider, the problem will be the same. That is, interms of stitching the two VPN services. If the service provider VPN isintegrated with that of data center, I think that will become a degenerat= e
case. In addition, if there is no BGP/MPLS connectivity, and the customeris gaining access to the DC via an Ipsec tunnel starting from a customer<= br>CE and terminated in the data center, that will be transparent to the VP= N
service provider as a BGP MPLS service provider and I don't think in th= at
case there is anything additional that should be done within the L3VP= N WG.

Thanks,
Nabil

On 11/3/11 1:42 PM, "Robert Raszu= k" <robert@r= aszuk.net> wrote:

>Linda,
>
> > Personally I don't think that we ne= ed to waste our time on Model #1
> > for the following reasons:>
>Personally I don't think we need to waste our time on solv= ing Model #2
>for one main reason - #2 is a subset of #1. If we solve #1 then #2 get&= #39;s
>solved automatically.
>
>Please note that IPSec ac= cess to provider's L3VPNs has been a
>commercialized and deployed= feature years ago.
>
>--
>
>I really think that if we have any desire to = constructively move forward
>in this space time spend on finding the = flexible and universal
>auto-discovery tool for customer's networ= k islands (be it VMs alone or
>L3VPNs sites/set of sides or even specific mobile users) is a
>pr= erequisite for any further work.
>
>Then we could worry about w= hat tool to use to interconnect those islands.
>
>Even if those= islands (more and more dynamic in nature) would all belong
>under one SP .. such SP would also largely benefit from ability to
&= gt;auto-discovery in real time needs to join or leave a VPN. Then the
&g= t;toolkit of choice could be triggered to add/delete a site, a user or a >VM to/from given VPN via the orchestration system of his choice.
>= ;
>To the best of my knowledge such dynamic VPN discovery tool has no= t been
>invented yet.
>
>Best rgds,
>R.
>
>
>
>> Here is the fundamental question for the goal of V= PN4DC:
>>
>> 1. Is VPN4DC to create mechanisms which make= it possible to connect
>> hosts in any public data centers (e.g. = Amazon' EC2) to hosts'
>> corresponding VPNs? Or
>>
>> 2. Is VPN4DC to cre= ate a solution which allows VPN service provider
>> to extend thei= r VPN with computing service? In this model, customers
>> (i.e. VP= N clients) see their computing resources being offloaded to
>> their VPN. Customers don't deal with data centers directly.>>
>>
>> Personally I don't think that we need= to waste our time on Model #1
>> for the following reasons: - =A0= =A0 =A0 VPN service providers may not even
>> have PEs in close proximity to "the public data centers"= which
>> clients choose. If a VPN client has leased some computin= g resource
>> from a data center, the easiest way to connect them = securely is by
>> IPSec tunnel.
>>
>> - =A0 =A0 =A0 Today Amazon a= lready allows any hosts to be connected to
>> their chosen sites b= y IPSec (Amazon's VPC service).
>>
>> Model #2 gives = VPN service providers an unique advantage of binding
>> valuable VPN services with virtual computing services, =A0making i= t
>> more difficult for data centers who don't own network inf= rastructure
>> to compete.
>>
>> Do people agree= ?
>>
>> Linda
>>
>>> -----Original Messag= e----- From: Luyuan Fang (lufang)
>>> [mailto:lufang@cisco.com] Sent: Wednesday,= November 02, 2011 11:41
>>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list<= br>>>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82
&g= t;>>
>>> Linda,
>>>
>>> Ben sugge= sted that Ning and myself to work with co-authors of
>>> other problem statement drafts to come up with a combined view= to
>>> be presented in Taipei meeting. The requirements drafts= would be
>>> treated in the similar fashion. I plan to put gap= analysis together
>>> with pb statement drafts.
>>>
>>> Thou= gh there would be no individual vpn4dc drafts presentations as
>>&= gt; in normal WG meetings, we welcome input on all three subjects from
>>> authors of vpn4dc related drafts, and everyone on the list.>>>
>>> In fact, the intent of vpn4dc Q&A I sent = a couple of days ago was
>>> to gather feedback/input from the = list, as the first step of
>>> meeting prep.
>>>
>>> Will get togethe= r with the authors of the relevant drafts to
>>> discuss soon, = prefer we meet when Ning is back to office in a
>>> couple of d= ays. Ping me if you cannot wait.
>>>
>>> Thanks, Luyuan
>>>
>>>=
>>>> -----Original Message----- From: l3vpn-bounces@ietf.org
>&g= t;>> [mailto:l3vpn-bounces@ietf.org] On
>>> Behalf
>>>> Of Linda Dunbar Sent: Wednesday, No= vember 02, 2011 10:56 PM To:
>>>> Ben Niven-Jenkins; L3VPN W= G mailing list Subject: RE: Preliminary
>>>> L3VPN/VPN4DC ag= enda @ IETF82
>>>>
>>>> Who will lead the talk for each topic?=
>>>>
>>>> Linda
>>>>
>&= gt;>>> -----Original Message----- From: l3vpn-bounces@ietf.org
>>>>> [mailto:l3vpn-bounces@ietf.org] On
>>>> Behalf
= >>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 201= 1 1:01
>>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VP= N/VPN4DC
>>>>> agenda @ IETF82
>>>>>>>>>> Colleagues,
>>>>>
>>>&g= t;> Marshall& =A0I have uploaded a preliminary L3VPN/VPN4DC agenda >>>>> for
>>> IETF
>>>>> 82 in= Taipei. You can find it here:
>>>>>
>>>>&= gt; http://www.ietf.org/proceedings/82/agenda/l3vpn.txt
>>>>>
>>>>> At the moment the agenda is a = little vague because we are
>>>>> still
>>>&g= t; working
>>>>> with the VPN4DC proponents on who will l= ead each slot.
>>>>>
>>>>> We have purposely not put time= on the agenda to
>>>>> present/discuss specific solution= drafts as we would like the
>>>>> discussion to be
>>>> focussed
>>>>> on the problem/requiremen= ts posed by VPN4DC and its
>>>>> applicability
>>= ;> to
>>>>> IETF (including L3VPN). Discussion of spec= ific solution
>>>>> proposals
>>> can
>>>>> = happen at future meetings if the VPN4DC work is adopted.
>>>>= ;>
>>>>> Ben
>>>>>
>>
>>
>>



------------------------------

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


End of L3VPN Digest, Vol 89, Issue 17
**************************= ***********

=A0

<= /blockquote>

--20cf300fb241cf86dc04b0fd1cae-- From lucy.yong@huawei.com Sun Nov 6 10:45: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 8DB4A21F8569 for ; Sun, 6 Nov 2011 10:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 Pcv9UHbUptiW for ; Sun, 6 Nov 2011 10:45:35 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6726421F858C for ; Sun, 6 Nov 2011 10:45:35 -0800 (PST) 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 <0LU900GQS5FNL5@usaga02-in.huawei.com> for l3vpn@ietf.org; Sun, 06 Nov 2011 12:45:23 -0600 (CST) Received: from dfweml202-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 <0LU9001HF5FNLY@usaga02-in.huawei.com> for l3vpn@ietf.org; Sun, 06 Nov 2011 12:45:23 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 06 Nov 2011 10:45:23 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Sun, 06 Nov 2011 10:45:14 -0800 Date: Sun, 06 Nov 2011 18:45:14 +0000 From: Lucy yong Subject: RE: VPN4DC Scope In-reply-to: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> X-Originating-IP: [10.47.129.152] To: "Luyuan Fang (lufang)" , "l3vpn@ietf.org" Message-id: <2691CE0099834E4A9C5044EEC662BB9D118DE89B@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_WoGkSPXQl1spNqjox0paFA)" Content-language: en-US Accept-Language: en-US Thread-topic: VPN4DC Scope Thread-index: Acybg7Xre36EuiLJTVqFN1kI+DCFUQBKnAVw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.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: Sun, 06 Nov 2011 18:45:37 -0000 --Boundary_(ID_WoGkSPXQl1spNqjox0paFA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Luyuan, I don't think this matches VPN4DC objective and requirements. (draft-so-vpn4dc) The draft objective is to enhance network service provider L3VPN services for Enterprise DCs and Provider DC interconnection. Enterprise can use virtual resources in Provider DC as if the resources are in its own datacenter and run Enterprise intranet applications. It does not constraint any architecture in Enterprise DC and Provider DC. The in-band signaling capability for host joining a L3VPN in a service provider network does not mean the DC that host resides need to implement L3VPN. The proposals you put here aims on extending L3VPN technologies into DC or DC VM virtual networks. Will this be network service providers' requirement or DC providers' requirement? I don't see such requirement anywhere. Today, Enterprise DC rarely implement L3VPN as well as DC provider. For getting some virtual resources in Provider DC, why does Enterprise need to change their DC architecture? Do I miss something? I agree that DC VPN or DC VM virtual network are potential subject to work on, but this is not what VPN4DC target for. Are we changing the direction? Regards, Lucy From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Luyuan Fang (lufang) Sent: Saturday, November 05, 2011 1:25 AM To: l3vpn@ietf.org Subject: VPN4DC Scope Dear colleagues, Thank you all for the constructive discussion/suggestions over the last few weeks on VPN4DC. I think we observed good interests/enthusiasm on solving the problems in this space. We need to narrow down the scope as the next step. I summarized the proposals sent on the list as the following: 1. Leverage BGP/MPLS VPN technologies, extending it with l3vpn signaling protocols into DC VM virtual networks. 2. Using BGP/MPLS VPN exactly 'as it is' into DC VM virtual networks 3. Extending/creating any IP VPN technologies into DC 4. Extending/creating or reuse/managing security protocols for DC connections, including encryption, key distribution, key management 5. Extending/creating or reuse L2VPN based technologies into DC Some of you prefer to focus on one of the options, while others like to include multiple options. Here is my observation and thought. 1 - It seems a common denominator. Did not hear no on this. It is exactly the problem Derick wanting to solve, it is Ning's starting point, and it is included in the requirements drafts. 2 - It does not need to create or extend protocols, should go to Operation and Management Area for any ops issues and best practice. 3 - The scope looks big to me, the list is potentially very long. 4 - If new encryption algorithm, better key distribution mechanism are needed, the work should go to Security Area; if nothing new, ops issues go to Operation and Management Area. 5 - L2VPN for DC work should go to L2VPN WG, it is defined in L2VPN charter. Thanks, Luyuan --Boundary_(ID_WoGkSPXQl1spNqjox0paFA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Luyuan,

 

I don’t think this matches VPN4DC objective and requirements.  (draft-so-vpn4dc)

 

The draft objective is to enhance network service provider L3VPN services  for Enterprise DCs and Provider DC interconnection.   Enterprise can use virtual resources in Provider DC as if the resources are in its own datacenter and run Enterprise intranet applications.  It does not constraint any architecture in Enterprise DC and Provider DC. The in-band signaling capability for host joining a L3VPN in a service provider network does not mean the DC that host resides need to implement L3VPN.

 

The proposals you put here aims on extending L3VPN technologies into DC or DC VM virtual networks. Will this be network service providers’ requirement or DC providers’ requirement? I don’t see such requirement anywhere.

 

Today, Enterprise DC rarely implement L3VPN as well as DC provider. For getting some virtual resources in Provider DC, why does Enterprise need to change their DC architecture? Do I miss something?

 

I agree that DC VPN or DC VM virtual network are potential subject to work on, but this is not what VPN4DC target for. Are we changing the direction?

 

Regards,

Lucy

 

From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Luyuan Fang (lufang)
Sent: Saturday, November 05, 2011 1:25 AM
To: l3vpn@ietf.org
Subject: VPN4DC Scope

 

Dear colleagues,

 

Thank you all for the constructive discussion/suggestions over the last few weeks on VPN4DC.

 

I think we observed good interests/enthusiasm on solving the problems in this space.

 

We need to narrow down the scope as the next step.

I summarized the proposals sent on the list as the following:  

 

1.      Leverage BGP/MPLS VPN technologies, extending it with l3vpn signaling protocols into DC VM virtual networks.

2.      Using BGP/MPLS VPN exactly ‘as it is’ into DC VM virtual networks

3.      Extending/creating any IP VPN technologies into DC

4.      Extending/creating or reuse/managing security protocols for DC connections, including encryption, key distribution, key management

5.      Extending/creating or reuse L2VPN based technologies into DC

 

Some of you prefer to focus on one of the options, while others like to include multiple options.

 

Here is my observation and thought.

 

1 – It seems a common denominator. Did not hear no on this.  It is exactly the problem Derick wanting to solve, it is Ning’s starting point, and it is included in the requirements drafts.

2 – It does not need to create or extend protocols, should go to Operation and Management Area for any ops issues and best practice.

3 - The scope looks big to me, the list is potentially very long.

4 - If new encryption algorithm, better key distribution mechanism are needed,  the work should go to Security Area; if nothing new, ops issues go to Operation and Management Area.

5 - L2VPN for DC work should go to L2VPN WG, it is defined in L2VPN charter.

 

Thanks,

Luyuan

--Boundary_(ID_WoGkSPXQl1spNqjox0paFA)-- From ccie15672@yahoo.com Sun Nov 6 16:19: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 BAF0521F86AA for ; Sun, 6 Nov 2011 16:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.617 X-Spam-Level: X-Spam-Status: No, score=0.617 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_40=-0.185, 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 rfqcIIp7Y9RG for ; Sun, 6 Nov 2011 16:19:16 -0800 (PST) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with SMTP id B175221F86A6 for ; Sun, 6 Nov 2011 16:19:15 -0800 (PST) Received: from [98.139.212.148] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2011 00:19:11 -0000 Received: from [98.139.212.246] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2011 00:19:11 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 07 Nov 2011 00:19:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 36519.29248.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 82056 invoked by uid 60001); 7 Nov 2011 00:19:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1320625150; bh=+8IO8/2cFGKQNPHgQ4lPuvapRgWl3+31HCy20ikKpTg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=VX05z+UkRdxH75YoFb8b5+oJJNfeKCe95ZYp2CuoZlA3SrO3m9jJUTK7U+TmTDKt1QTv7nn6NMGHL1groCkBDx9VD8MGLW34alkKXDTARKzUGegupExjsevLKG7pb7i84WL/tL+eWuMgtLy1KjIWkufxRxEx0DYWrvrjbrG0+B0= 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=OrBB6jvydZppSppqSOd4ws2p2TuvtrNXjlv1iyAuHwBpTshk8AYgrGFx3UiBxaYCBl+D/dHwW230V64ilUs95gqP5dGvmbCimqwf2t9ekM+UjdlXrjjV4VyZY1rtkCKr/jiJ7+1FTVT0QDqcm9So7zj2iQsNouV0119yLfdngrg=; X-YMail-OSG: nt0QyIkVM1liPuK3saLAQCWlOP5lGJD_6qvC2D4gBRGszcS Xfrwf_B1drQjfaZA7GJvGyCMSzB3Xp2ghaT1W8YvN9ycSF35vO.6l_SBqZ8Z uggsRRk.e6mRak89ntkmk62Lby3iYUkGOV.iUxgBNIPPmyXVx.cjTL56snpW h_wfnMgkZjh7a8vRDBy.L3wFXJKONio6sCJjWHSXk11XRBSZUfKjA0pJKXgY uD.4_KwNgkHH9oDUfoQf1g0tON1z0l.5yaRrM8zVmRZ3NpD7baAPCOhfyA_2 b_lm_bxFQx7vY9ze3jshMX5pZkhw0NVmSONWy36b52w1cjnYHCiOqna5gAvO p0F5dvV4xIr1WV8VNY8Famq_qdupIMqZyiIO7GERxIH3md9HRaH9wzYI4xne tN5w4yQELBqoxxtLU8eR8Jr05qf5vq2jJ.KWAm6FCctZyifg4G1MbT2f6nRW Kmdh3eA-- Received: from [76.194.43.66] by web161802.mail.bf1.yahoo.com via HTTP; Sun, 06 Nov 2011 16:19:10 PST X-Mailer: YahooMailWebService/0.8.114.317681 References: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D118DE89B@dfweml506-mbx> Message-ID: <1320625150.80915.YahooMailNeo@web161802.mail.bf1.yahoo.com> Date: Sun, 6 Nov 2011 16:19:10 -0800 (PST) From: Derick Winkworth Subject: Re: VPN4DC Scope To: Lucy yong , "Luyuan Fang \(lufang\)" , "l3vpn@ietf.org" In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D118DE89B@dfweml506-mbx> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2096837515-1477042901-1320625150=:80915" 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: Mon, 07 Nov 2011 00:19:16 -0000 ---2096837515-1477042901-1320625150=:80915 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Lucy:=0A=0AThat draft is older, try: =C2=A0http://tools.ietf.org/html/draft= -so-vdcs-02=0A=0ADerick=0A=0A=0A________________________________=0AFrom: Lu= cy yong =0ATo: Luyuan Fang (lufang) ; "l3vpn@ietf.org" =0ASent: Sunday, November 6, 2011 12:45= PM=0ASubject: RE: VPN4DC Scope=0A=0A=0A =0ALuyuan,=0A=C2=A0=0AI don=E2=80= =99t think this matches VPN4DC objective and requirements. =C2=A0(draft-so-= vpn4dc) =0A=C2=A0=0AThe draft objective is to enhance network service provi= der L3VPN services =C2=A0for Enterprise DCs and Provider DC interconnection= . =C2=A0=C2=A0Enterprise can use virtual resources in Provider DC as if the= resources are in its own datacenter and run Enterprise intranet applicatio= ns. =C2=A0It does not constraint any architecture in Enterprise DC and Prov= ider DC. The in-band signaling capability for host joining a L3VPN in a ser= vice provider network does not mean the DC that host resides need to implem= ent L3VPN.=0A=C2=A0=0AThe proposals you put here aims on extending L3VPN te= chnologies into DC or DC VM virtual networks. Will this be network service = providers=E2=80=99 requirement or DC providers=E2=80=99 requirement? I don= =E2=80=99t see such requirement anywhere.=0A=C2=A0=0AToday, Enterprise DC r= arely implement L3VPN as well as DC provider. For getting some virtual reso= urces in Provider DC, why does Enterprise need to change their DC architect= ure? Do I miss something?=0A=C2=A0=0AI agree that DC VPN or DC VM virtual n= etwork are potential subject to work on, but this is not what VPN4DC target= for. Are we changing the direction?=0A=C2=A0=0ARegards,=0ALucy=0A=C2=A0=0A= From:l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Lu= yuan Fang (lufang)=0ASent: Saturday, November 05, 2011 1:25 AM=0ATo: l3vpn@= ietf.org=0ASubject: VPN4DC Scope=0A=C2=A0=0ADear colleagues,=0A=C2=A0=0ATha= nk you all for the constructive discussion/suggestions over the last few we= eks on VPN4DC. =0A=C2=A0=0AI think we observed good interests/enthusiasm on= solving the problems in this space. =0A=C2=A0=0AWe need to narrow down the= scope as the next step.=0AI summarized the proposals sent on the list as t= he following: =C2=A0=0A=C2=A0=0A1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Leverage B= GP/MPLS VPN technologies, extending it with l3vpn signaling protocols into = DC VM virtual networks.=0A2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Using BGP/MPLS V= PN exactly =E2=80=98as it is=E2=80=99 into DC VM virtual networks=0A3.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Extending/creating any IP VPN technologies into= DC =0A4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extending/creating or reuse/managin= g security protocols for DC connections, including encryption, key distribu= tion, key management=0A5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extending/creating = or reuse L2VPN based technologies into DC =0A=C2=A0=0ASome of you prefer to= focus on one of the options, while others like to include multiple options= .=0A=C2=A0=0AHere is my observation and thought.=0A=C2=A0=0A1 =E2=80=93 It = seems a common denominator. Did not hear no on this. =C2=A0It is exactly th= e problem Derick wanting to solve, it is Ning=E2=80=99s starting point, and= it is included in the requirements drafts.=0A2 =E2=80=93 It does not need = to create or extend protocols, should go to Operation and Management Area f= or any ops issues and best practice.=0A3 - The scope looks big to me, the l= ist is potentially very long.=0A4 - If new encryption algorithm, better key= distribution mechanism are needed, =C2=A0the work should go to Security Ar= ea; if nothing new, ops issues go to Operation and Management Area.=0A5 - L= 2VPN for DC work should go to L2VPN WG, it is defined in L2VPN charter.=0A= =C2=A0=0AThanks,=0ALuyuan ---2096837515-1477042901-1320625150=:80915 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Lucy:

<= div>That draft is older, try:  http://tools.ietf.org/html/draft-so-vdcs-02
=
Derick

From: Lucy yong <lucy.yong@huawei.com>
To: Luyuan Fang (lufang) <lufang@cisco.com>= ; "l3vpn@ietf.org" <l3vpn@ietf.org>
Sent: Sunday, November 6, 2011 12:45 PM
Subject: RE: VPN4DC Scope
=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
Luyuan,
=0A
 
=0A
I don=E2=80=99t think this matches VPN4DC objective and requirements. &nbs= p;(draft-so-vpn4dc)=0A
=0A
 
=0A<= div class=3D"yiv1259216122MsoNormal">The draft objective is to enhance network service provider L3VPN = services  for Enterprise DCs and Provider DC interconnection.  &n= bsp;Enterprise can use virtual=0A resources in Provider DC as if the resour= ces are in its own datacenter and run Enterprise intranet applications. &nb= sp;It does not constraint any architecture in Enterprise DC and Provider DC= . The in-band signaling capability for host joining a L3VPN in a service=0A= provider network does not mean the DC that host resides need to implement = L3VPN.
=0A
 
=0A
The pr= oposals you put here aims on extending L3VPN technologies into DC or DC VM = virtual networks. Will this be network service providers=E2=80=99 requireme= nt or DC=0A providers=E2=80=99 requirement? I don=E2=80=99t see such requir= ement anywhere.
=0A
 
=0A
Today, Enterprise DC rarely implement L3VPN as well as DC provider. For = getting some virtual resources in Provider DC, why does Enterprise need to = change their=0A DC architecture? Do I miss something?
=0A
 
=0A
I agree that DC VPN or DC VM virtu= al network are potential subject to work on, but this is not what VPN4DC ta= rget for. Are we changing the direction?
=0A
 =
=0A
Regards,
=0A
Lucy=
=0A
=0A
 
=0A=0A
=0A
From: l3vpn= -bounces@ietf.org [mailto:l3vpn-bounces@ietf.org]=0AOn Behalf Of Luy= uan Fang (lufang)
=0ASent: Saturday, November 05, 2011 1:25 AM=0ATo: l3vpn@ietf.org
=0ASubject: VPN4DC Scope =0A
=0A
=0A
 
= =0A
Dear colleagues,
=0A
 
=0A
Thank you all for the constructive discussion/suggestions over t= he last few weeks on VPN4DC.=0A
=0A
 
=0A
I think we obser= ved good interests/enthusiasm on solving the problems in this space.=0A =0A
 
=0A
We need to narrow down the scope as the next step.<= /div> =0A
I summarized the proposals s= ent on the list as the following:  
=0A
 
=0A
1.     =0ALeverage BGP/MPLS VPN technologies, extending= it with l3vpn signaling protocols into DC VM virtual networks. =0A
2. &n= bsp;   =0AUsing BGP/MPLS VPN exactly =E2=80=98as it is=E2=80=99 into DC VM virtu= al networks
=0A
3.     =0AExtending/creating any IP VPN technologies in= to DC=0A
=0A
4.     =0AExtending/creating or reuse/managing security prot= ocols for DC connections, including encryption, key distribution, key manag= ement
=0A
5.     =0AExtending/creating or reuse L2VPN based technologies= into DC=0A
=0A
  =0A
Some of you prefer to focus o= n one of the options, while others like to include multiple options.
= =0A
 
=0A
Here is my observation and thought.
=0A
 
=0A
1 =E2=80=93 It seems a common denominator. Did not hear no on this= .  It is exactly the problem Derick wanting to solve, it is Ning=E2=80= =99s starting point, and it is included in the requirements drafts.
= =0A
2 =E2=80=93 It does not need to cr= eate or extend protocols, should go to Operation and Management Area for an= y ops issues and best practice.
=0A
3 - The scope looks big to me, the list is potentially very long.
= =0A
4 - If new encryption algorithm, = better key distribution mechanism are needed,  the work should go to S= ecurity Area; if nothing new, ops issues go to Operation and Management Are= a.
=0A
5 - L2VPN for DC work sho= uld go to L2VPN WG, it is defined in L2VPN charter.
=0A
 
=0A
Thanks,
=0A
Luyuan
=0A=
=0A
=0A=0A


---2096837515-1477042901-1320625150=:80915-- From yudelei@huawei.com Mon Nov 7 02:01: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 70F2421F8ABC for ; Mon, 7 Nov 2011 02:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 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, 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 dJOOzxS3FKZG for ; Mon, 7 Nov 2011 02:01:09 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 78AB121F8A70 for ; Mon, 7 Nov 2011 02:01:09 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUA00BNHBST26@szxga03-in.huawei.com> for l3vpn@ietf.org; Mon, 07 Nov 2011 18:00:29 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUA00JEYBSOM5@szxga03-in.huawei.com> for l3vpn@ietf.org; Mon, 07 Nov 2011 18:00:29 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEU56112; Mon, 07 Nov 2011 18:00:28 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 18:00:26 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.102]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 18:00:18 +0800 Date: Mon, 07 Nov 2011 10:00:03 +0000 From: Yudelei Subject: RE: VPN4DC Scope In-reply-to: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> X-Originating-IP: [10.108.4.109] To: "l3vpn@ietf.org" Message-id: <397489E39F2A984AB838214767A532AD19BDBB5C@SZXEML511-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Yi9Oo8flOLwBabKedmy6pQ)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: VPN4DC Scope Thread-index: Acybg7Xre36EuiLJTVqFN1kI+DCFUQBp27JA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.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: Mon, 07 Nov 2011 10:01:10 -0000 --Boundary_(ID_Yi9Oo8flOLwBabKedmy6pQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 RGVhciBMdXl1YW4sDQpJcyBpdCBwcm92ZWQgYSBtYXR1cmUgdGVjaG5vbG9neSBmb3IgREMgVk0g dmlydHVhbCBuZXR3b3JrIHRvIHN1cHBvcnQgTDMgcm91dGluZyBhbmQgTDNWUE4/IEJ1dCBMM1ZQ TiBjYW4gYmUgc3VwcG9ydGVkIHdlbGwgb24gYSBnZW5lcmFsIHJvdXRlciBkZXZpY2UuIFdoZW4g dGFsa2luZyBhYm91dCBWUE40REMsIEkgdGhpbmsgaXShr3MgYmV0dGVyIHRvIGFzc3VtZSBMM1ZQ TnMgYXJlIHByb2Nlc3NlZCBhdCByb3V0ZXIgZGV2aWNlIGluIERDLCBlLmcuIERDIGdhdGV3YXkg cm91dGVyLg0KDQpUaGFua3MNCkRlbGVpDQoNCmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSBMdXl1YW4gRmFuZyAobHVmYW5nKQ0KMjAxMcTqMTHU wjXI1SAxNDoyNQ0KbDN2cG5AaWV0Zi5vcmcNClZQTjREQyBTY29wZQ0KDQpEZWFyIGNvbGxlYWd1 ZXMsDQoNClRoYW5rIHlvdSBhbGwgZm9yIHRoZSBjb25zdHJ1Y3RpdmUgZGlzY3Vzc2lvbi9zdWdn ZXN0aW9ucyBvdmVyIHRoZSBsYXN0IGZldyB3ZWVrcyBvbiBWUE40REMuDQoNCkkgdGhpbmsgd2Ug b2JzZXJ2ZWQgZ29vZCBpbnRlcmVzdHMvZW50aHVzaWFzbSBvbiBzb2x2aW5nIHRoZSBwcm9ibGVt cyBpbiB0aGlzIHNwYWNlLg0KDQpXZSBuZWVkIHRvIG5hcnJvdyBkb3duIHRoZSBzY29wZSBhcyB0 aGUgbmV4dCBzdGVwLg0KSSBzdW1tYXJpemVkIHRoZSBwcm9wb3NhbHMgc2VudCBvbiB0aGUgbGlz dCBhcyB0aGUgZm9sbG93aW5nOg0KDQoNCjEuICAgICAgTGV2ZXJhZ2UgQkdQL01QTFMgVlBOIHRl Y2hub2xvZ2llcywgZXh0ZW5kaW5nIGl0IHdpdGggbDN2cG4gc2lnbmFsaW5nIHByb3RvY29scyBp bnRvIERDIFZNIHZpcnR1YWwgbmV0d29ya3MuDQoNCjIuICAgICAgVXNpbmcgQkdQL01QTFMgVlBO IGV4YWN0bHkgoa5hcyBpdCBpc6GvIGludG8gREMgVk0gdmlydHVhbCBuZXR3b3Jrcw0KDQozLiAg ICAgIEV4dGVuZGluZy9jcmVhdGluZyBhbnkgSVAgVlBOIHRlY2hub2xvZ2llcyBpbnRvIERDDQoN CjQuICAgICAgRXh0ZW5kaW5nL2NyZWF0aW5nIG9yIHJldXNlL21hbmFnaW5nIHNlY3VyaXR5IHBy b3RvY29scyBmb3IgREMgY29ubmVjdGlvbnMsIGluY2x1ZGluZyBlbmNyeXB0aW9uLCBrZXkgZGlz dHJpYnV0aW9uLCBrZXkgbWFuYWdlbWVudA0KDQo1LiAgICAgIEV4dGVuZGluZy9jcmVhdGluZyBv ciByZXVzZSBMMlZQTiBiYXNlZCB0ZWNobm9sb2dpZXMgaW50byBEQw0KDQpTb21lIG9mIHlvdSBw cmVmZXIgdG8gZm9jdXMgb24gb25lIG9mIHRoZSBvcHRpb25zLCB3aGlsZSBvdGhlcnMgbGlrZSB0 byBpbmNsdWRlIG11bHRpcGxlIG9wdGlvbnMuDQoNCkhlcmUgaXMgbXkgb2JzZXJ2YXRpb24gYW5k IHRob3VnaHQuDQoNCjEgqEMgSXQgc2VlbXMgYSBjb21tb24gZGVub21pbmF0b3IuIERpZCBub3Qg aGVhciBubyBvbiB0aGlzLiAgSXQgaXMgZXhhY3RseSB0aGUgcHJvYmxlbSBEZXJpY2sgd2FudGlu ZyB0byBzb2x2ZSwgaXQgaXMgTmluZ6GvcyBzdGFydGluZyBwb2ludCwgYW5kIGl0IGlzIGluY2x1 ZGVkIGluIHRoZSByZXF1aXJlbWVudHMgZHJhZnRzLg0KMiCoQyBJdCBkb2VzIG5vdCBuZWVkIHRv IGNyZWF0ZSBvciBleHRlbmQgcHJvdG9jb2xzLCBzaG91bGQgZ28gdG8gT3BlcmF0aW9uIGFuZCBN YW5hZ2VtZW50IEFyZWEgZm9yIGFueSBvcHMgaXNzdWVzIGFuZCBiZXN0IHByYWN0aWNlLg0KMyAt IFRoZSBzY29wZSBsb29rcyBiaWcgdG8gbWUsIHRoZSBsaXN0IGlzIHBvdGVudGlhbGx5IHZlcnkg bG9uZy4NCjQgLSBJZiBuZXcgZW5jcnlwdGlvbiBhbGdvcml0aG0sIGJldHRlciBrZXkgZGlzdHJp YnV0aW9uIG1lY2hhbmlzbSBhcmUgbmVlZGVkLCAgdGhlIHdvcmsgc2hvdWxkIGdvIHRvIFNlY3Vy aXR5IEFyZWE7IGlmIG5vdGhpbmcgbmV3LCBvcHMgaXNzdWVzIGdvIHRvIE9wZXJhdGlvbiBhbmQg TWFuYWdlbWVudCBBcmVhLg0KNSAtIEwyVlBOIGZvciBEQyB3b3JrIHNob3VsZCBnbyB0byBMMlZQ TiBXRywgaXQgaXMgZGVmaW5lZCBpbiBMMlZQTiBjaGFydGVyLg0KDQpUaGFua3MsDQpMdXl1YW4N Cg== --Boundary_(ID_Yi9Oo8flOLwBabKedmy6pQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Dear Luyua= n,

Is it prov= ed a mature technology for DC VM virtual network to support L3 routing and = L3VPN? But L3VPN can be supported well on a general router device. When talking about VPN4DC, I think it=A1=AFs better to assume L3VP= Ns are processed at router device in DC, e.g. DC gateway router.

 = ;

Thanks

Delei=

 = ;

l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org]= Luyuan Fang (lufang)
2011=C4=EA= 11=D4=C25=C8=D5 14:25
l3vpn@ietf.org
VPN4DC Scope

 

Dear colleagues,

 

Thank you all for the construct= ive discussion/suggestions over the last few weeks on VPN4DC.

 

I think we observed good intere= sts/enthusiasm on solving the problems in this space.

 

We need to narrow down the scop= e as the next step.

I summarized the proposals sent= on the list as the following:  

 

1.=       Leverage BGP/= MPLS VPN technologies, extending it with l3vpn signaling protocols into DC = VM virtual networks.

2.=       Using BGP/MPL= S VPN exactly =A1=AEas it is=A1=AF into DC VM virtual networks

3.=       Extending/cre= ating any IP VPN technologies into DC

4.=       Extending/cre= ating or reuse/managing security protocols for DC connections, including en= cryption, key distribution, key management

5.=       Extending/cre= ating or reuse L2VPN based technologies into DC

 

Some of you prefer to focus on = one of the options, while others like to include multiple options.

 

Here is my observation and thou= ght.

 

1 =A8C It seems a common denomi= nator. Did not hear no on this.  It is exactly the problem Derick want= ing to solve, it is Ning=A1=AFs starting point, and it is included in the r= equirements drafts.

2 =A8C It does not need to crea= te or extend protocols, should go to Operation and Management Area for any = ops issues and best practice.

3 - The scope looks big to me, = the list is potentially very long.

4 - If new encryption algorithm= , better key distribution mechanism are needed,  the work should go to= Security Area; if nothing new, ops issues go to Operation and Management A= rea.

5 - L2VPN for DC work should go= to L2VPN WG, it is defined in L2VPN charter.

 

Thanks,

Luyuan

--Boundary_(ID_Yi9Oo8flOLwBabKedmy6pQ)-- From nabil.n.bitar@verizon.com Mon Nov 7 05:31: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 195D221F8508 for ; Mon, 7 Nov 2011 05:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=-0.610, 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_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 dcedQLYNq6gV for ; Mon, 7 Nov 2011 05:31:24 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id A4E4F21F8B7B for ; Mon, 7 Nov 2011 05:31:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 07 Nov 2011 13:31:19 +0000 From: "Bitar, Nabil N" To: Derick Winkworth , "Bitar, Nabil N" , "robert@raszuk.net" , Linda Dunbar X-IronPort-AV: E=Sophos;i="4.69,470,1315180800"; d="scan'208,217";a="174916891" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi01.verizon.com with ESMTP; 07 Nov 2011 13:31:18 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.102]) by FLDP1LUMXC7HB01.us.one.verizon.com ([166.68.45.78]) with mapi; Mon, 7 Nov 2011 08:31:18 -0500 Date: Mon, 7 Nov 2011 08:31:18 -0500 Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Topic: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-Index: AcydUYfYNeK+0LuJQ+WHvu7z5rSQvQ== Message-ID: In-Reply-To: <1320458884.82254.YahooMailNeo@web161801.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CADD47172C6BBnabilnbitarverizoncom_" MIME-Version: 1.0 Cc: L3VPN WG mailing list 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, 07 Nov 2011 13:31:26 -0000 --_000_CADD47172C6BBnabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Derick, I am not sure how you got to that conclusion if you are really responding t= o my email. I am not saying what you concluded at all. Thanks, Nabil From: Derick Winkworth > Reply-To: Derick Winkworth = > Date: Fri, 4 Nov 2011 22:08:04 -0400 To: "Bitar, Nabil N" >, "robert@raszuk.net" >, Linda Dunbar > Cc: L3VPN WG mailing list > Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 I have read the VaaS document several times and I'm not seeing how it is re= levant to VPN4DC. (1) These VMs are not mobile users on the internet. (2) We are, in fact, creating network path isolation (with proper separatio= n) for the VMs in the data center to/from their respective VRF. (3) No matter how great the software is that you are using on your host to = establish the VPN... *my* customers, the reason I'm so interested in VPN4DC= , do not want their servers exposed to the internet at any level. They wan= t their servers effectively "jailed" in their L3VPN. there can be no depen= dency on software or configuration of the VM for its placement in their net= work. The vNIC is bound by path isolation to their private L3VPN. this is= a not a unique or unusual requirement. (4) You are advocating VaaS as a replacement for MPLS (it would seem by you= r comments). I'm not interested in replacing MPLS. Feel free to correct or clarify any misunderstanding I may be suffering fro= m... ________________________________ From: "Bitar, Nabil N" > To: "robert@raszuk.net" >; Linda Dunbar > Cc: L3VPN WG mailing list > Sent: Friday, November 4, 2011 1:16 PM Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Hi, I think what we need to be careful about assuming that the cloud service provider is the same as the VPN service provider, and in particular a BGP/MPLS service provider. That is not to say that they cannot be the same, but it is over-restrictive to assume that they are and if one makes that assumption the solution or attributes of a solution will not be necessarily the same. Model #2 seems to assume that this is the case in the way it is worded. There are a number of ways in which #1 can be achieved, and one of which can be overlapping with model#2 per suggested modification. I think it is fine to define a model that defines a type or types of DC tenant isolation (connectivity) that will be stitched to the tenant VPN WAN service provided by a service provider. The tenant VPN service can be focused on to be BGP/MPLS VPN provided by a service provider. The tenant connectivity within the data center can also be a BGP-MPLS VPN or an IPsec VPN or a layer2VPN, and one can focus on one, but I think we will find that that at the connection between the data center and the tenant WAN VPN provided by a service provider, the problem will be the same. That is, in terms of stitching the two VPN services. If the service provider VPN is integrated with that of data center, I think that will become a degenerate case. In addition, if there is no BGP/MPLS connectivity, and the customer is gaining access to the DC via an Ipsec tunnel starting from a customer CE and terminated in the data center, that will be transparent to the VPN service provider as a BGP MPLS service provider and I don't think in that case there is anything additional that should be done within the L3VPN WG. Thanks, Nabil On 11/3/11 1:42 PM, "Robert Raszuk" > wrote: >Linda, > > > Personally I don't think that we need to waste our time on Model #1 > > for the following reasons: > >Personally I don't think we need to waste our time on solving Model #2 >for one main reason - #2 is a subset of #1. If we solve #1 then #2 get's >solved automatically. > >Please note that IPSec access to provider's L3VPNs has been a >commercialized and deployed feature years ago. > >-- > >I really think that if we have any desire to constructively move forward >in this space time spend on finding the flexible and universal >auto-discovery tool for customer's network islands (be it VMs alone or >L3VPNs sites/set of sides or even specific mobile users) is a >prerequisite for any further work. > >Then we could worry about what tool to use to interconnect those islands. > >Even if those islands (more and more dynamic in nature) would all belong >under one SP .. such SP would also largely benefit from ability to >auto-discovery in real time needs to join or leave a VPN. Then the >toolkit of choice could be triggered to add/delete a site, a user or a >VM to/from given VPN via the orchestration system of his choice. > >To the best of my knowledge such dynamic VPN discovery tool has not been >invented yet. > >Best rgds, >R. > > > >> Here is the fundamental question for the goal of VPN4DC: >> >> 1. Is VPN4DC to create mechanisms which make it possible to connect >> hosts in any public data centers (e.g. Amazon' EC2) to hosts' >> corresponding VPNs? Or >> >> 2. Is VPN4DC to create a solution which allows VPN service provider >> to extend their VPN with computing service? In this model, customers >> (i.e. VPN clients) see their computing resources being offloaded to >> their VPN. Customers don't deal with data centers directly. >> >> >> Personally I don't think that we need to waste our time on Model #1 >> for the following reasons: - VPN service providers may not even >> have PEs in close proximity to "the public data centers" which >> clients choose. If a VPN client has leased some computing resource >> from a data center, the easiest way to connect them securely is by >> IPSec tunnel. >> >> - Today Amazon already allows any hosts to be connected to >> their chosen sites by IPSec (Amazon's VPC service). >> >> Model #2 gives VPN service providers an unique advantage of binding >> valuable VPN services with virtual computing services, making it >> more difficult for data centers who don't own network infrastructure >> to compete. >> >> Do people agree? >> >> Linda >> >>> -----Original Message----- From: Luyuan Fang (lufang) >>> [mailto:lufang@cisco.com] Sent: Wednesday, Nov= ember 02, 2011 11:41 >>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list >>> Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82 >>> >>> Linda, >>> >>> Ben suggested that Ning and myself to work with co-authors of >>> other problem statement drafts to come up with a combined view to >>> be presented in Taipei meeting. The requirements drafts would be >>> treated in the similar fashion. I plan to put gap analysis together >>> with pb statement drafts. >>> >>> Though there would be no individual vpn4dc drafts presentations as >>> in normal WG meetings, we welcome input on all three subjects from >>> authors of vpn4dc related drafts, and everyone on the list. >>> >>> In fact, the intent of vpn4dc Q&A I sent a couple of days ago was >>> to gather feedback/input from the list, as the first step of >>> meeting prep. >>> >>> Will get together with the authors of the relevant drafts to >>> discuss soon, prefer we meet when Ning is back to office in a >>> couple of days. Ping me if you cannot wait. >>> >>> Thanks, Luyuan >>> >>> >>>> -----Original Message----- From: l3vpn-bounces@ietf.org >>>> [mailto:l3vpn-bounces@ietf.org] On >>> Behalf >>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To: >>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary >>>> L3VPN/VPN4DC agenda @ IETF82 >>>> >>>> Who will lead the talk for each topic? >>>> >>>> Linda >>>> >>>>> -----Original Message----- From: l3vpn-bounces@ietf.org >>>>> [mailto:l3vpn-bounces@ietf.org] On >>>> Behalf >>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01 >>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC >>>>> agenda @ IETF82 >>>>> >>>>> Colleagues, >>>>> >>>>> Marshall& I have uploaded a preliminary L3VPN/VPN4DC agenda >>>>> for >>> IETF >>>>> 82 in Taipei. You can find it here: >>>>> >>>>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt >>>>> >>>>> At the moment the agenda is a little vague because we are >>>>> still >>>> working >>>>> with the VPN4DC proponents on who will lead each slot. >>>>> >>>>> We have purposely not put time on the agenda to >>>>> present/discuss specific solution drafts as we would like the >>>>> discussion to be >>>> focussed >>>>> on the problem/requirements posed by VPN4DC and its >>>>> applicability >>> to >>>>> IETF (including L3VPN). Discussion of specific solution >>>>> proposals >>> can >>>>> happen at future meetings if the VPN4DC work is adopted. >>>>> >>>>> Ben >>>>> >> >> >> --_000_CADD47172C6BBnabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Derick,
I am n= ot sure how you got to that conclusion if you are really responding to my e= mail. I am not saying what you concluded at all.

T= hanks,
Nabil 

From: Derick Winkworth <ccie15672@yahoo.com>
= Reply-To: Derick Winkworth <ccie15672@yahoo.com>
Date: Fri, 4 Nov 2011 22:08:04 -0400
To= : "Bitar, Nabil N" <nabil.n.bitar@one.verizon.com>, "robert@raszuk.net" <robe= rt@raszuk.net>, Linda Dunbar <linda.dunbar@huawei.com>
Cc: L3VPN WG mailing list <l3= vpn@ietf.org>
Subject: R= e: Preliminary L3VPN/VPN4DC agenda @ IETF82

I have read the VaaS document = several times and I'm not seeing how it is relevant to VPN4DC.  

(1) These VMs are not mobile = users on the internet. 
(2) We are, in fact, cr= eating network path isolation (with proper separation) for the VMs in the d= ata center to/from their respective VRF.
(3) No matt= er how great the software is that you are using on your host to establish t= he VPN... *my* customers, the reason I'm so interested in VPN4DC, do not wa= nt their servers exposed to the internet at any level.  They want thei= r servers effectively "jailed" in their L3VPN.  there can be no depend= ency on software or configuration of the VM for its placement in their netw= ork.  The vNIC is bound by path isolation to their private L3VPN.  this is a not a unique or unusual requirement.=
(4) You are advocating VaaS as a replacement for MPLS (it = would seem by your comments).  I'm not interested in replacing MPLS. &= nbsp;

Feel free to corre= ct or clarify any misunderstanding I may be suffering from...
<= div>




From: "Bitar, Nabil N" <nab= il.n.bitar@verizon.com>
To:= "robert@raszuk.net" &l= t;robert@raszuk.net>; Linda Dun= bar <linda.dunbar@huawei.com<= /a>>
Cc: L3VPN WG ma= iling list <l3vpn@ietf.org>
= Sent: Friday, November 4, = 2011 1:16 PM
Subject: R= e: Preliminary L3VPN/VPN4DC agenda @ IETF82

Hi,
I think what we need to be careful about assuming that the cloud ser= vice
provider is the same as the VPN service provider, and in particular= a
BGP/MPLS service provider. That is not to say that they cannot be the=
same, but it is over-restrictive to assume that they are and if one mak= es
that assumption the solution or attributes of a solution will not be<= br>necessarily the same. Model #2 seems to assume that this is the case in<= br>the way it is worded.

There are a number of ways in which #1 can = be achieved, and one of which
can be overlapping with model#2 per sugges= ted modification. I think it is
fine to define a model that defines a ty= pe or types  of DC tenant
isolation (connectivity)  that will = be stitched to the tenant VPN WAN
service provided by a service provider= . The tenant VPN service can be
focused on to be BGP/MPLS VPN provided b= y a service provider. The tenant
connectivity within the data center can also be a BGP-MPLS VPN or an IPsec
VPN or a layer2VPN, and o= ne can focus on one, but I think we will find
that that at the connectio= n between the data center and the tenant WAN VPN
provided by a service p= rovider, the problem will be the same. That is, in
terms of stitching th= e two VPN services. If the service provider VPN is
integrated with that = of data center, I think that will become a degenerate
case. In addition,= if there is no BGP/MPLS connectivity, and the customer
is gaining acces= s to the DC via an Ipsec tunnel starting from a customer
CE and terminat= ed in the data center, that will be transparent to the VPN
service provi= der as a BGP MPLS service provider and I don't think in that
case there = is anything additional that should be done within the L3VPN WG.

Than= ks,
Nabil

On 11/3/11 1:42 PM, "Robert Raszuk" <robert@raszuk.ne= t> wrote:

>Linda,
>
> > Personally I don't = think that we need to waste our time on Model #1
> > for the follo= wing reasons:
>
>Personally I don't think we need to waste our = time on solving Model #2
>for one main reason - #2 is a subset of #1.= If we solve #1 then #2 get's
>solved automatically.
>
>P= lease note that IPSec access to provider's L3VPNs has been a
>commerc= ialized and deployed feature years ago.
>
>--
>
>I = really think that if we have any desire to constructively move forward
&= gt;in this space time spend on finding the flexible and universal
>au= to-discovery tool for customer's network islands (be it VMs alone or
>= ;L3VPNs sites/set of sides or even specific mobile users) is a
>prere= quisite for any further work.
>
>Then we could worry about what= tool to use to interconnect those islands.
>
>Even if those islands (more and= more dynamic in nature) would all belong
>under one SP .. such SP wo= uld also largely benefit from ability to
>auto-discovery in real time= needs to join or leave a VPN. Then the
>toolkit of choice could be t= riggered to add/delete a site, a user or a
>VM to/from given VPN via = the orchestration system of his choice.
>
>To the best of my kn= owledge such dynamic VPN discovery tool has not been
>invented yet.>
>Best rgds,
>R.
>
>
>
>> Here= is the fundamental question for the goal of VPN4DC:
>>
>>= ; 1. Is VPN4DC to create mechanisms which make it possible to connect
&g= t;> hosts in any public data centers (e.g. Amazon' EC2) to hosts'
>= ;> corresponding VPNs? Or
>>
>> 2. Is VPN4DC to create= a solution which allows VPN service provider
>> to extend their VPN with computing service? In this model, customers
>> (i.= e. VPN clients) see their computing resources being offloaded to
>>= ; their VPN. Customers don't deal with data centers directly.
>>>>
>> Personally I don't think that we need to waste our t= ime on Model #1
>> for the following reasons: -     = ; VPN service providers may not even
>> have PEs in close proximi= ty to "the public data centers" which
>> clients choose. If a VPN = client has leased some computing resource
>> from a data center, t= he easiest way to connect them securely is by
>> IPSec tunnel.
= >>
>> -      Today Amazon already allows any= hosts to be connected to
>> their chosen sites by IPSec (Amazon's= VPC service).
>>
>> Model #2 gives VPN service providers= an unique advantage of binding
>> valuable VPN services with virtual computing services,  making it
>> more difficul= t for data centers who don't own network infrastructure
>> to comp= ete.
>>
>> Do people agree?
>>
>> Linda=
>>
>>> -----Original Message----- From: Luyuan Fang (= lufang)
>>> [mailto:lufang@cisco.com] Sent: Wednesday, Novembe= r 02, 2011 11:41
>>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3= VPN WG mailing list
>>> Subject: RE: Preliminary L3VPN/VPN4DC a= genda @ IETF82
>>>
>>> Linda,
>>>
&g= t;>> Ben suggested that Ning and myself to work with co-authors of>>> other problem statement drafts to come up with a combined vie= w to
>>> be presented in Taipei meeting. The requirements draft= s would be
>>> treated in the similar fashion. I plan to put gap analysis together
>>> with pb statement drafts.
>>= ;>
>>> Though there would be no individual vpn4dc drafts pre= sentations as
>>> in normal WG meetings, we welcome input on al= l three subjects from
>>> authors of vpn4dc related drafts, and= everyone on the list.
>>>
>>> In fact, the intent = of vpn4dc Q&A I sent a couple of days ago was
>>> to gather= feedback/input from the list, as the first step of
>>> meeting= prep.
>>>
>>> Will get together with the authors o= f the relevant drafts to
>>> discuss soon, prefer we meet when = Ning is back to office in a
>>> couple of days. Ping me if you = cannot wait.
>>>
>>> Thanks, Luyuan
>>>=
>>>
>>>> -----Original Message----- From: l3vpn-bounces@ietf.org
>>>> [mailto:l3vpn-b= ounces@ietf.org] On
>>> Behalf
>>>> Of Linda= Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To:
>>>>= Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary
>&= gt;>> L3VPN/VPN4DC agenda @ IETF82
>>>>
>>>= ;> Who will lead the talk for each topic?
>>>>
>>= ;>> Linda
>>>>
>>>>> -----Original M= essage----- From: l3vpn-bounces@ietf.org
>>>>&g= t; [mailto:l3vpn-bounces@ietf.org] On
>>>> Beha= lf
>>>>> Of Ben Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01
>>>>&= gt; PM To: L3VPN WG mailing list Subject: Preliminary L3VPN/VPN4DC
>&= gt;>>> agenda @ IETF82
>>>>>
>>>>= > Colleagues,
>>>>>
>>>>> Marshall&a= mp;  I have uploaded a preliminary L3VPN/VPN4DC agenda
>>>= >> for
>>> IETF
>>>>> 82 in Taipei. You= can find it here:
>>>>>
>>>>> http://www.ietf.or= g/proceedings/82/agenda/l3vpn.txt
>>>>>
>>&g= t;>> At the moment the agenda is a little vague because we are
>= ;>>>> still
>>>> working
>>>>>= with the VPN4DC proponents on who will lead each slot.
>>>>= >
>>>>> We have purposely not put time on the agenda t= o
>>>>> present/discuss specific solution drafts as we would like the
>>>>> discussion to be
&g= t;>>> focussed
>>>>> on the problem/requirements= posed by VPN4DC and its
>>>>> applicability
>>&= gt; to
>>>>> IETF (including L3VPN). Discussion of specif= ic solution
>>>>> proposals
>>> can
>&g= t;>>> happen at future meetings if the VPN4DC work is adopted.
= >>>>>
>>>>> Ben
>>>>>>>
>>
>>



--_000_CADD47172C6BBnabilnbitarverizoncom_-- From ccie15672@yahoo.com Mon Nov 7 05:42:30 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 7358221F8B48 for ; Mon, 7 Nov 2011 05:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.233 X-Spam-Level: X-Spam-Status: No, score=-0.233 tagged_above=-999 required=5 tests=[AWL=0.565, 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 oAK4hG1K7tzY for ; Mon, 7 Nov 2011 05:42:26 -0800 (PST) Received: from nm2-vm0.bullet.mail.bf1.yahoo.com (nm2-vm0.bullet.mail.bf1.yahoo.com [98.139.213.127]) by ietfa.amsl.com (Postfix) with SMTP id E3C8321F8B36 for ; Mon, 7 Nov 2011 05:42:22 -0800 (PST) Received: from [98.139.214.32] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2011 13:42:19 -0000 Received: from [98.139.212.193] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2011 13:42:19 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 07 Nov 2011 13:42:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 498788.62668.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 59138 invoked by uid 60001); 7 Nov 2011 13:42:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1320673339; bh=Pjk9IcJSVrLk23EPKSl153QEJT42Z7Hev5/FicHqliU=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=iZs1RMCLshkMZ0gTL1guUxlf5VdspnNGbw+rwaYycQ5ePzP68W8IwoQBynR+QHuM2pf/P5bshsW5IArc1b2MkjeZV7e9b5MEiKCgM0hIi64BwqmsgY50qgsiCth6ST5BdYzhETyymew6Qs8VNLfu4wFDwX3umz5me5CjTCqDRfo= 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=khytDSjRlWZjAFDZQLeAtFxO10RutzE1nsekFVutirqolVh6uK7eOnbG2BIvvCMblKPvBPZzWaVrA6u9OgvVq3GMR0oNDyouZitYV61dDuwlR3rZSeMYuwOohbUIIes4XkLodohZC95cSOGZZcsmeSgxD6VJEKS+307MpoUgLfY=; X-YMail-OSG: 3mZbWEIVM1kDy4N7brjdPzFvLnZOlVhFlu5V85y.geueqzH iGr.yCzyn3lojuellv81sAGahT63lm1mdTBGWjnRNs_L4bAAHsxvwjtttD5L U.fcjY4R88xVl9euCyD4qr5UVge.sLeBljJZ9kC4TZ7URM1UyBfMM4in15nM xsY79nrMyQ5WPm9abJHt_7Ao5ANLXYs89sXBe9iMUqhd00jbgX84mERgOVFd IIj3dbN18A44snfOpv6BTkPTVaGHbygNXGTpAOczMku82E9ygVBoVSLqUKSU s7N3FvJ0oBTW7o53h_NqT50xVfqKUJIyxatx5.AFDFsfvf2AI1zNn7o9f4Xw Kw05RJ.NY.p58dmHzvR6yftx7_asuL7jaj8t5M.3QsuVQfcG.ZNFoPvbDLx1 cFavusuH1kNgAdCU6gmZW8QpY_tjfT6sXUJ3ahGTz2owKUX6EAcLZOPGvwGh I4vC.jjU- Received: from [76.194.43.66] by web161801.mail.bf1.yahoo.com via HTTP; Mon, 07 Nov 2011 05:42:19 PST X-Mailer: YahooMailWebService/0.8.114.317681 References: <1320458884.82254.YahooMailNeo@web161801.mail.bf1.yahoo.com> Message-ID: <1320673339.26821.YahooMailNeo@web161801.mail.bf1.yahoo.com> Date: Mon, 7 Nov 2011 05:42:19 -0800 (PST) From: Derick Winkworth Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82 To: "l3vpn@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1882999342-583791890-1320673339=:26821" 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: Mon, 07 Nov 2011 13:42:30 -0000 --1882999342-583791890-1320673339=:26821 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I hit reply on the wrong e-mail. =A0Sorry, Nabil.=0A=0A=0A=0A=0A___________= _____________________=0AFrom: "Bitar, Nabil N" = =0ATo: Derick Winkworth ; "Bitar, Nabil N" ; "robert@raszuk.net" ; Linda Dunbar =0ACc: L3VPN WG mailing list =0ASent:= Monday, November 7, 2011 7:31 AM=0ASubject: Re: Preliminary L3VPN/VPN4DC a= genda @ IETF82=0A=0A=0ADerick,=0AI am not sure how you got to that conclusi= on if you are really responding to my email. I am not saying what you concl= uded at all.=0A=0AThanks,=0ANabil=A0=0AFrom: Derick Winkworth =0AReply-To: Derick Winkworth =0ADate: Fri,= 4 Nov 2011 22:08:04 -0400=0ATo: "Bitar, Nabil N" , "robert@raszuk.net" , Linda Dunbar =0ACc: L3VPN WG mailing list =0ASubject: Re:= Preliminary L3VPN/VPN4DC agenda @ IETF82=0A=0A=0AI have read the VaaS docu= ment several times and I'm not seeing how it is relevant to VPN4DC. =A0=0A= =0A(1) These VMs are not mobile users on the internet.=A0=0A(2) We are, in = fact, creating network path isolation (with proper separation) for the VMs = in the data center to/from their respective VRF.=0A(3) No matter how great = the software is that you are using on your host to establish the VPN... *my= * customers, the reason I'm so interested in VPN4DC, do not want their serv= ers exposed to the internet at any level. =A0They want their servers effect= ively "jailed" in their L3VPN. =A0there can be no dependency on software or= configuration of the VM for its placement in their network. =A0The vNIC is= bound by path isolation to their private L3VPN. =A0this is a not a unique = or unusual requirement.=0A(4) You are advocating VaaS as a replacement for = MPLS (it would seem by your comments). =A0I'm not interested in replacing M= PLS. =A0=0A=0AFeel free to correct or clarify any misunderstanding I may be= suffering from...=0A=0A=0A=0A=0A=0A=0A________________________________=0AF= rom: "Bitar, Nabil N" =0ATo: "robert@raszuk.net"= ; Linda Dunbar =0ACc: L3VPN WG= mailing list =0ASent: Friday, November 4, 2011 1:16 PM=0AS= ubject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82=0A=0AHi,=0AI think wha= t we need to be careful about assuming that the cloud service=0Aprovider is= the same as the VPN service provider, and in particular a=0ABGP/MPLS servi= ce provider. That is not to say that they cannot be the=0Asame, but it is o= ver-restrictive to assume that they are and if one makes=0Athat assumption = the solution or attributes of a solution will not be=0Anecessarily the same= . Model #2 seems to assume that this is the case in=0Athe way it is worded.= =0A=0AThere are a number of ways in which #1 can be achieved, and one of wh= ich=0Acan be overlapping with model#2 per suggested modification. I think i= t is=0Afine to define a model that defines a type or types=A0 of DC tenant= =0Aisolation (connectivity)=A0 that will be stitched to the tenant VPN WAN= =0Aservice provided by a service provider. The tenant VPN service can be=0A= focused on to be BGP/MPLS VPN provided by a service provider. The tenant=0A= connectivity within the data=0A center can also be a BGP-MPLS VPN or an IPs= ec=0AVPN or a layer2VPN, and one can focus on one, but I think we will find= =0Athat that at the connection between the data center and the tenant WAN V= PN=0Aprovided by a service provider, the problem will be the same. That is,= in=0Aterms of stitching the two VPN services. If the service provider VPN = is=0Aintegrated with that of data center, I think that will become a degene= rate=0Acase. In addition, if there is no BGP/MPLS connectivity, and the cus= tomer=0Ais gaining access to the DC via an Ipsec tunnel starting from a cus= tomer=0ACE and terminated in the data center, that will be transparent to t= he VPN=0Aservice provider as a BGP MPLS service provider and I don't think = in that=0Acase there is anything additional that should be done within the = L3VPN WG.=0A=0AThanks,=0ANabil=0A=0AOn 11/3/11 1:42 PM, "Robert Raszuk" wrote:=0A=0A>Linda,=0A>=0A> > Personally I don't think tha= t we need to waste our time on Model #1=0A> > for the following reasons:=0A= >=0A>Personally I don't think we need to waste our time on solving Model #2= =0A>for one main reason - #2 is a subset of #1. If we solve #1 then #2 get'= s=0A>solved automatically.=0A>=0A>Please note that IPSec access to provider= 's L3VPNs has been a=0A>commercialized and deployed feature years ago.=0A>= =0A>--=0A>=0A>I really think that if we have any desire to constructively m= ove forward=0A>in this space time spend on finding the flexible and univers= al=0A>auto-discovery tool for customer's network islands (be it VMs alone o= r=0A>L3VPNs sites/set of sides or even specific mobile users) is a=0A>prere= quisite for any further work.=0A>=0A>Then we could worry about what tool to= use to=0A interconnect those islands.=0A>=0A>Even if those islands (more a= nd more dynamic in nature) would all belong=0A>under one SP .. such SP woul= d also largely benefit from ability to=0A>auto-discovery in real time needs= to join or leave a VPN. Then the=0A>toolkit of choice could be triggered t= o add/delete a site, a user or a=0A>VM to/from given VPN via the orchestrat= ion system of his choice.=0A>=0A>To the best of my knowledge such dynamic V= PN discovery tool has not been=0A>invented yet.=0A>=0A>Best rgds,=0A>R.=0A>= =0A>=0A>=0A>> Here is the fundamental question for the goal of VPN4DC:=0A>>= =0A>> 1. Is VPN4DC to create mechanisms which make it possible to connect= =0A>> hosts in any public data centers (e.g. Amazon' EC2) to hosts'=0A>> co= rresponding VPNs? Or=0A>>=0A>> 2. Is VPN4DC to create a solution which allo= ws VPN service provider=0A>> to extend=0A their VPN with computing service?= In this model, customers=0A>> (i.e. VPN clients) see their computing resou= rces being offloaded to=0A>> their VPN. Customers don't deal with data cent= ers directly.=0A>>=0A>>=0A>> Personally I don't think that we need to waste= our time on Model #1=0A>> for the following reasons: -=A0 =A0 =A0 VPN ser= vice providers may not even=0A>> have PEs in close proximity to "the public= data centers" which=0A>> clients choose. If a VPN client has leased some c= omputing resource=0A>> from a data center, the easiest way to connect them = securely is by=0A>> IPSec tunnel.=0A>>=0A>> -=A0 =A0 =A0 Today Amazon alre= ady allows any hosts to be connected to=0A>> their chosen sites by IPSec (A= mazon's VPC service).=0A>>=0A>> Model #2 gives VPN service providers an uni= que advantage of binding=0A>> valuable VPN services=0A with virtual computi= ng services,=A0 making it=0A>> more difficult for data centers who don't ow= n network infrastructure=0A>> to compete.=0A>>=0A>> Do people agree?=0A>>= =0A>> Linda=0A>>=0A>>> -----Original Message----- From: Luyuan Fang (lufang= )=0A>>> [mailto:lufang@cisco.com] Sent: Wednesday, November 02, 2011 11:41= =0A>>> PM To: Linda Dunbar; Ben Niven-Jenkins; L3VPN WG mailing list=0A>>> = Subject: RE: Preliminary L3VPN/VPN4DC agenda @ IETF82=0A>>>=0A>>> Linda,=0A= >>>=0A>>> Ben suggested that Ning and myself to work with co-authors of=0A>= >> other problem statement drafts to come up with a combined view to=0A>>> = be presented in Taipei meeting. The requirements drafts would be=0A>>> trea= ted in the similar fashion. I plan to put=0A gap analysis together=0A>>> wi= th pb statement drafts.=0A>>>=0A>>> Though there would be no individual vpn= 4dc drafts presentations as=0A>>> in normal WG meetings, we welcome input o= n all three subjects from=0A>>> authors of vpn4dc related drafts, and every= one on the list.=0A>>>=0A>>> In fact, the intent of vpn4dc Q&A I sent a cou= ple of days ago was=0A>>> to gather feedback/input from the list, as the fi= rst step of=0A>>> meeting prep.=0A>>>=0A>>> Will get together with the auth= ors of the relevant drafts to=0A>>> discuss soon, prefer we meet when Ning = is back to office in a=0A>>> couple of days. Ping me if you cannot wait.=0A= >>>=0A>>> Thanks, Luyuan=0A>>>=0A>>>=0A>>>> -----Original Message----- From= : l3vpn-bounces@ietf.org=0A>>>> [mailto:l3vpn-bounces@ietf.org] On=0A>>> Be= half=0A>>>> Of Linda Dunbar Sent: Wednesday, November 02, 2011 10:56 PM To:= =0A>>>> Ben Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary= =0A>>>> L3VPN/VPN4DC agenda @ IETF82=0A>>>>=0A>>>> Who will lead the talk f= or each topic?=0A>>>>=0A>>>> Linda=0A>>>>=0A>>>>> -----Original Message----= - From: l3vpn-bounces@ietf.org=0A>>>>> [mailto:l3vpn-bounces@ietf.org] On= =0A>>>> Behalf=0A>>>>> Of Ben=0A Niven-Jenkins Sent: Wednesday, November 02= , 2011 1:01=0A>>>>> PM To: L3VPN WG mailing list Subject: Preliminary L3VPN= /VPN4DC=0A>>>>> agenda @ IETF82=0A>>>>>=0A>>>>> Colleagues,=0A>>>>>=0A>>>>>= Marshall&=A0 I have uploaded a preliminary L3VPN/VPN4DC agenda=0A>>>>> for= =0A>>> IETF=0A>>>>> 82 in Taipei. You can find it here:=0A>>>>>=0A>>>>> htt= p://www.ietf.org/proceedings/82/agenda/l3vpn.txt=0A>>>>>=0A>>>>> At the mom= ent the agenda is a little vague because we are=0A>>>>> still=0A>>>> workin= g=0A>>>>> with the VPN4DC proponents on who will lead each slot.=0A>>>>>=0A= >>>>> We have purposely not put time on the agenda to=0A>>>>> present/discu= ss specific solution=0A drafts as we would like the=0A>>>>> discussion to b= e=0A>>>> focussed=0A>>>>> on the problem/requirements posed by VPN4DC and i= ts=0A>>>>> applicability=0A>>> to=0A>>>>> IETF (including L3VPN). Discussio= n of specific solution=0A>>>>> proposals=0A>>> can=0A>>>>> happen at future= meetings if the VPN4DC work is adopted.=0A>>>>>=0A>>>>> Ben=0A>>>>>=0A>>= =0A>>=0A>> --1882999342-583791890-1320673339=:26821 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I hit reply on the wrong e-= mail.  Sorry, Nabil.



From: "Bitar, Nabil N" <nabil.n.bi= tar@verizon.com>
To:= Derick Winkworth <ccie15672@yahoo.com>; "Bitar, Nabil N" <nabil.n= .bitar@verizon.com>; "robert@raszuk.net" <robert@raszuk.net>; Lind= a Dunbar <linda.dunbar@huawei.com>
Cc: L3VPN WG mailing list <l3vpn@ietf.org>
Sent: Monday, November 7, 2011 = 7:31 AM
Subject: Re: Prelim= inary L3VPN/VPN4DC agenda @ IETF82

=0A
Derick,
I am not sure how you got to that conclusion = if you are really responding to my email. I am not saying what you conclude= d at all.

Thanks,
Nabil 
=
From: Derick Winkworth <ccie15672@yahoo.com>
Reply-To: Derick Winkworth <ccie15672@yahoo.com>
Date: Fri, 4 Nov 2011 22:08:04 -0400
To: "Bitar, Nabil N" <nabil.n.bitar@one.verizon.com= >, "robert@raszuk.net" <robert@raszuk.net>, Linda Dunbar <<= a rel=3D"nofollow" ymailto=3D"mailto:linda.dunbar@huawei.com" target=3D"_bl= ank" href=3D"mailto:linda.dunbar@huawei.com">linda.dunbar@huawei.com>Cc: L3VPN WG mailing list <l3vpn@ietf.org>
Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82

I have read the VaaS document several times an= d I'm not seeing how it is relevant to VPN4DC.  

(1) These VMs are not mobile users on the int= ernet. 
(2) We are, in fact, creating network p= ath isolation (with proper separation) for the VMs in the data center to/fr= om their respective VRF.
(3) No matter how great the= software is that you are using on your host to establish the VPN... *my* customers,= the reason I'm so interested in VPN4DC, do not want their servers exposed = to the internet at any level.  They want their servers effectively "ja= iled" in their L3VPN.  there can be no dependency on software or confi= guration of the VM for its placement in their network.  The vNIC is bo= und by path isolation to their=0A private L3VPN.  this is a not a uniq= ue or unusual requirement.
(4) You are advocating Va= aS as a replacement for MPLS (it would seem by your comments).  I'm no= t interested in replacing MPLS.  

Feel free to correct or clarify any misunderstanding I may b= e suffering from...


=



From: "Bitar, Nabil N" <nabil.n.bitar@verizon.com>
To: "robert@raszuk.net" <robert@raszuk.net>; Linda Dunbar <linda.dunbar@huawei.com>
Cc: L3VPN WG mailing list <l3vpn@ietf.org>
Sent:= Friday, November 4, 2011 1:16 PM
Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82<= br>
=0AHi,
I think what we need to be careful about assuming t= hat the cloud service
provider is the same as the VPN service provider, = and in particular a
BGP/MPLS service provider. That is not to say that t= hey cannot be the
same, but it is over-restrictive to assume that they a= re and if one makes
that assumption the solution or attributes of a solu= tion will not be
necessarily the same. Model #2 seems to assume that thi= s is the case in
the way it is worded.

There are a number of ways= in which #1 can be achieved, and one of which
can be overlapping with m= odel#2 per suggested modification. I think it is
fine to define a model = that defines a type or types  of DC tenant
isolation (connectivity)=   that will be stitched to the tenant VPN WAN
service provided by a= service provider. The tenant VPN service can be
focused on to be BGP/MP= LS VPN provided by a service provider. The tenant
connectivity within th= e data=0A center can also be a BGP-MPLS VPN or an IPsec
VPN or a layer2V= PN, and one can focus on one, but I think we will find
that that at the = connection between the data center and the tenant WAN VPN
provided by a = service provider, the problem will be the same. That is, in
terms of sti= tching the two VPN services. If the service provider VPN is
integrated w= ith that of data center, I think that will become a degenerate
case. In = addition, if there is no BGP/MPLS connectivity, and the customer
is gain= ing access to the DC via an Ipsec tunnel starting from a customer
CE and= terminated in the data center, that will be transparent to the VPN
serv= ice provider as a BGP MPLS service provider and I don't think in that
ca= se there is anything additional that should be done within the L3VPN WG.
Thanks,
Nabil

On 11/3/11 1:42 PM, "Robert Raszuk" <robert@raszuk.net> wrote:

= >Linda,
>
> > Personally I don't think that we need to wa= ste our time on Model #1
> > for the following reasons:
>>Personally I don't think we need to waste our time on solving Model #2=
>for one main reason - #2 is a subset of #1. If we solve #1 then #2 = get's
>solved automatically.
>
>Please note that IPSec ac= cess to provider's L3VPNs has been a
>commercialized and deployed fea= ture years ago.
>
>--
>
>I really think that if we = have any desire to constructively move forward
>in this space time sp= end on finding the flexible and universal
>auto-discovery tool for cu= stomer's network islands (be it VMs alone or
>L3VPNs sites/set of sid= es or even specific mobile users) is a
>prerequisite for any further = work.
>
>Then we could worry about what tool to use to=0A inter= connect those islands.
>
>Even if those islands (more and more = dynamic in nature) would all belong
>under one SP .. such SP would al= so largely benefit from ability to
>auto-discovery in real time needs= to join or leave a VPN. Then the
>toolkit of choice could be trigger= ed to add/delete a site, a user or a
>VM to/from given VPN via the or= chestration system of his choice.
>
>To the best of my knowledg= e such dynamic VPN discovery tool has not been
>invented yet.
>=
>Best rgds,
>R.
>
>
>
>> Here is th= e fundamental question for the goal of VPN4DC:
>>
>> 1. I= s VPN4DC to create mechanisms which make it possible to connect
>>= hosts in any public data centers (e.g. Amazon' EC2) to hosts'
>> = corresponding VPNs? Or
>>
>> 2. Is VPN4DC to create a sol= ution which allows VPN service provider
>> to extend=0A their VPN = with computing service? In this model, customers
>> (i.e. VPN clie= nts) see their computing resources being offloaded to
>> their VPN= . Customers don't deal with data centers directly.
>>
>><= br>>> Personally I don't think that we need to waste our time on Mode= l #1
>> for the following reasons: -      VPN serv= ice providers may not even
>> have PEs in close proximity to "the = public data centers" which
>> clients choose. If a VPN client has = leased some computing resource
>> from a data center, the easiest = way to connect them securely is by
>> IPSec tunnel.
>>>> -      Today Amazon already allows any hosts to b= e connected to
>> their chosen sites by IPSec (Amazon's VPC servic= e).
>>
>> Model #2 gives VPN service providers an unique = advantage of binding
>> valuable VPN services=0A with virtual comp= uting services,  making it
>> more difficult for data centers= who don't own network infrastructure
>> to compete.
>>>> Do people agree?
>>
>> Linda
>>
&g= t;>> -----Original Message----- From: Luyuan Fang (lufang)
>>= ;> [mailto:lufang@cisco.com] Sent: W= ednesday, November 02, 2011 11:41
>>> PM To: Linda Dunbar; Ben = Niven-Jenkins; L3VPN WG mailing list
>>> Subject: RE: Prelimina= ry L3VPN/VPN4DC agenda @ IETF82
>>>
>>> Linda,
&= gt;>>
>>> Ben suggested that Ning and myself to work with= co-authors of
>>> other problem statement drafts to come up wi= th a combined view to
>>> be presented in Taipei meeting. The r= equirements drafts would be
>>> treated in the similar fashion. I plan to put=0A gap analysis together
>>> wi= th pb statement drafts.
>>>
>>> Though there would = be no individual vpn4dc drafts presentations as
>>> in normal W= G meetings, we welcome input on all three subjects from
>>> aut= hors of vpn4dc related drafts, and everyone on the list.
>>>>>> In fact, the intent of vpn4dc Q&A I sent a couple of days= ago was
>>> to gather feedback/input from the list, as the fir= st step of
>>> meeting prep.
>>>
>>> Wi= ll get together with the authors of the relevant drafts to
>>> = discuss soon, prefer we meet when Ning is back to office in a
>>&g= t; couple of days. Ping me if you cannot wait.
>>>
>>&= gt; Thanks, Luyuan
>>>
>>>
>>>> ----= -Original Message----- From: l3vpn-bounces@ietf.org
>&= gt;>> [mailto:l3vpn-bounc= es@ietf.org] On
>>> Behalf
>>>> Of Linda Dun= bar Sent: Wednesday, November 02, 2011 10:56 PM To:
>>>> Ben= Niven-Jenkins; L3VPN WG mailing list Subject: RE: Preliminary
>>&= gt;> L3VPN/VPN4DC agenda @ IETF82
>>>>
>>>>= ; Who will lead the talk for each topic?
>>>>
>>>= ;> Linda
>>>>
>>>>> -----Original Messa= ge----- From: l3vpn-bounces@iet= f.org
>>>>> [mailto:l3vpn-bounces@ietf.org] On
&= gt;>>> Behalf
>>>>> Of Ben=0A Niven-Jenkins Sent= : Wednesday, November 02, 2011 1:01
>>>>> PM To: L3VPN WG= mailing list Subject: Preliminary L3VPN/VPN4DC
>>>>> age= nda @ IETF82
>>>>>
>>>>> Colleagues,>>>>>
>>>>> Marshall&  I have up= loaded a preliminary L3VPN/VPN4DC agenda
>>>>> for
>= ;>> IETF
>>>>> 82 in Taipei. You can find it here:<= br>>>>>>
>>>>> http://www.ietf.org/proceed= ings/82/agenda/l3vpn.txt
>>>>>
>>>>> At= the moment the agenda is a little vague because we are
>>>>= > still
>>>> working
>>>>> with the VPN= 4DC proponents on who will lead each slot.
>>>>>
>&= gt;>>> We have purposely not put time on the agenda to
>>= >>> present/discuss specific solution=0A drafts as we would like t= he
>>>>> discussion to be
>>>> focussed>>>>> on the problem/requirements posed by VPN4DC and its>>>>> applicability
>>> to
>>>>= > IETF (including L3VPN). Discussion of specific solution
>>>= ;>> proposals
>>> can
>>>>> happen at f= uture meetings if the VPN4DC work is adopted.
>>>>>
&g= t;>>>> Ben
>>>>>
>>
>>
&= gt;>



=0A
=

--1882999342-583791890-1320673339=:26821-- From lucy.yong@huawei.com Mon Nov 7 08:11:33 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 18EC721F8906 for ; Mon, 7 Nov 2011 08:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.673 X-Spam-Level: X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 Rnyt00gTL8b2 for ; Mon, 7 Nov 2011 08:11:28 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id CB05621F8481 for ; Mon, 7 Nov 2011 08:11:28 -0800 (PST) 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 <0LUA003EZSNAII@usaga02-in.huawei.com> for l3vpn@ietf.org; Mon, 07 Nov 2011 10:04:23 -0600 (CST) 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 <0LUA004EUSNA8M@usaga02-in.huawei.com> for l3vpn@ietf.org; Mon, 07 Nov 2011 10:04:22 -0600 (CST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 08:04:20 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 08:04:12 -0800 Date: Mon, 07 Nov 2011 16:04:13 +0000 From: Lucy yong Subject: RE: VPN4DC Scope In-reply-to: <1320625150.80915.YahooMailNeo@web161802.mail.bf1.yahoo.com> X-Originating-IP: [10.47.144.191] To: Derick Winkworth , "Luyuan Fang (lufang)" , "l3vpn@ietf.org" Message-id: <2691CE0099834E4A9C5044EEC662BB9D118DEAD0@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2mj2zC1tCId3aTaJJHj3cw)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: VPN4DC Scope Thread-index: AQHMnOLke36EuiLJTVqFN1kI+DCFUZWhkEBg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D118DE89B@dfweml506-mbx> <1320625150.80915.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: Mon, 07 Nov 2011 16:11:33 -0000 --Boundary_(ID_2mj2zC1tCId3aTaJJHj3cw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 RGVyaWNrIGFuZCBMdXl1YW4sDQoNClRoZSBuZXdlciBkcmFmdCBoYXMgb25lIHJlcXVpcmVtZW50 IGZvciBleHRlbmRpbmcgVlBOcyBpbnRvIGRhdGFjZW50ZXIgbmV0d29ya3Mgd2l0aCBMMi9MM1ZQ TiwgYW5kIGEgbGFyZ2UgcG9ydGlvbiBvZiByZXF1aXJlbWVudHMgZm9yIHVzaW5nIFZQTiBnYXRl d2F5IGZvciBWUE4gZXh0ZW5zaW9uIGludG8gZGF0YWNlbnRlci4gV2Ugc2hvdWxkIGluY2x1ZGUg VlBOIGdhdGV3YXkgY2FzZSBpbiB0aGUgc2NvcGUgdG9vLg0KDQpJbiBWRENTLCBzb21lIERDcyBh cmUgb3duZWQgYnkgY3VzdG9tZXIgYW5kIHNvbWUgYnkgREMgcHJvdmlkZXIgREMuIEl0IGlzIG5v dCBwcmFjdGljYWwgdG8gcmVxdWlyZSBjdXN0b21lciBwcml2YXRlIGRhdGFjZW50ZXIgdG8gaW1w bGVtZW50IEwyL0wzVlBOIGZvciBnZXR0aW5nIGEgVkRDUyBzZXJ2aWNlLg0KDQpUaGFua3MsDQpM dWN5DQoNCkZyb206IERlcmljayBXaW5rd29ydGggW21haWx0bzpjY2llMTU2NzJAeWFob28uY29t XQ0KU2VudDogU3VuZGF5LCBOb3ZlbWJlciAwNiwgMjAxMSA2OjE5IFBNDQpUbzogTHVjeSB5b25n OyBMdXl1YW4gRmFuZyAobHVmYW5nKTsgbDN2cG5AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBWUE40 REMgU2NvcGUNCg0KTHVjeToNCg0KVGhhdCBkcmFmdCBpcyBvbGRlciwgdHJ5OiAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc28tdmRjcy0wMg0KDQpEZXJpY2sNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdl aS5jb20+DQpUbzogTHV5dWFuIEZhbmcgKGx1ZmFuZykgPGx1ZmFuZ0BjaXNjby5jb20+OyAibDN2 cG5AaWV0Zi5vcmciIDxsM3ZwbkBpZXRmLm9yZz4NClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgNiwg MjAxMSAxMjo0NSBQTQ0KU3ViamVjdDogUkU6IFZQTjREQyBTY29wZQ0KTHV5dWFuLA0KDQpJIGRv buKAmXQgdGhpbmsgdGhpcyBtYXRjaGVzIFZQTjREQyBvYmplY3RpdmUgYW5kIHJlcXVpcmVtZW50 cy4gIChkcmFmdC1zby12cG40ZGMpDQoNClRoZSBkcmFmdCBvYmplY3RpdmUgaXMgdG8gZW5oYW5j ZSBuZXR3b3JrIHNlcnZpY2UgcHJvdmlkZXIgTDNWUE4gc2VydmljZXMgIGZvciBFbnRlcnByaXNl IERDcyBhbmQgUHJvdmlkZXIgREMgaW50ZXJjb25uZWN0aW9uLiAgIEVudGVycHJpc2UgY2FuIHVz ZSB2aXJ0dWFsIHJlc291cmNlcyBpbiBQcm92aWRlciBEQyBhcyBpZiB0aGUgcmVzb3VyY2VzIGFy ZSBpbiBpdHMgb3duIGRhdGFjZW50ZXIgYW5kIHJ1biBFbnRlcnByaXNlIGludHJhbmV0IGFwcGxp Y2F0aW9ucy4gIEl0IGRvZXMgbm90IGNvbnN0cmFpbnQgYW55IGFyY2hpdGVjdHVyZSBpbiBFbnRl cnByaXNlIERDIGFuZCBQcm92aWRlciBEQy4gVGhlIGluLWJhbmQgc2lnbmFsaW5nIGNhcGFiaWxp dHkgZm9yIGhvc3Qgam9pbmluZyBhIEwzVlBOIGluIGEgc2VydmljZSBwcm92aWRlciBuZXR3b3Jr IGRvZXMgbm90IG1lYW4gdGhlIERDIHRoYXQgaG9zdCByZXNpZGVzIG5lZWQgdG8gaW1wbGVtZW50 IEwzVlBOLg0KDQpUaGUgcHJvcG9zYWxzIHlvdSBwdXQgaGVyZSBhaW1zIG9uIGV4dGVuZGluZyBM M1ZQTiB0ZWNobm9sb2dpZXMgaW50byBEQyBvciBEQyBWTSB2aXJ0dWFsIG5ldHdvcmtzLiBXaWxs IHRoaXMgYmUgbmV0d29yayBzZXJ2aWNlIHByb3ZpZGVyc+KAmSByZXF1aXJlbWVudCBvciBEQyBw cm92aWRlcnPigJkgcmVxdWlyZW1lbnQ/IEkgZG9u4oCZdCBzZWUgc3VjaCByZXF1aXJlbWVudCBh bnl3aGVyZS4NCg0KVG9kYXksIEVudGVycHJpc2UgREMgcmFyZWx5IGltcGxlbWVudCBMM1ZQTiBh cyB3ZWxsIGFzIERDIHByb3ZpZGVyLiBGb3IgZ2V0dGluZyBzb21lIHZpcnR1YWwgcmVzb3VyY2Vz IGluIFByb3ZpZGVyIERDLCB3aHkgZG9lcyBFbnRlcnByaXNlIG5lZWQgdG8gY2hhbmdlIHRoZWly IERDIGFyY2hpdGVjdHVyZT8gRG8gSSBtaXNzIHNvbWV0aGluZz8NCg0KSSBhZ3JlZSB0aGF0IERD IFZQTiBvciBEQyBWTSB2aXJ0dWFsIG5ldHdvcmsgYXJlIHBvdGVudGlhbCBzdWJqZWN0IHRvIHdv cmsgb24sIGJ1dCB0aGlzIGlzIG5vdCB3aGF0IFZQTjREQyB0YXJnZXQgZm9yLiBBcmUgd2UgY2hh bmdpbmcgdGhlIGRpcmVjdGlvbj8NCg0KUmVnYXJkcywNCkx1Y3kNCg0KRnJvbTogbDN2cG4tYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBMdXl1YW4gRmFuZyAobHVmYW5nKQ0KU2VudDogU2F0dXJkYXksIE5vdmVtYmVyIDA1LCAyMDEx IDE6MjUgQU0NClRvOiBsM3ZwbkBpZXRmLm9yZw0KU3ViamVjdDogVlBONERDIFNjb3BlDQoNCkRl YXIgY29sbGVhZ3VlcywNCg0KVGhhbmsgeW91IGFsbCBmb3IgdGhlIGNvbnN0cnVjdGl2ZSBkaXNj dXNzaW9uL3N1Z2dlc3Rpb25zIG92ZXIgdGhlIGxhc3QgZmV3IHdlZWtzIG9uIFZQTjREQy4NCg0K SSB0aGluayB3ZSBvYnNlcnZlZCBnb29kIGludGVyZXN0cy9lbnRodXNpYXNtIG9uIHNvbHZpbmcg dGhlIHByb2JsZW1zIGluIHRoaXMgc3BhY2UuDQoNCldlIG5lZWQgdG8gbmFycm93IGRvd24gdGhl IHNjb3BlIGFzIHRoZSBuZXh0IHN0ZXAuDQpJIHN1bW1hcml6ZWQgdGhlIHByb3Bvc2FscyBzZW50 IG9uIHRoZSBsaXN0IGFzIHRoZSBmb2xsb3dpbmc6DQoNCjEuICAgICAgTGV2ZXJhZ2UgQkdQL01Q TFMgVlBOIHRlY2hub2xvZ2llcywgZXh0ZW5kaW5nIGl0IHdpdGggbDN2cG4gc2lnbmFsaW5nIHBy b3RvY29scyBpbnRvIERDIFZNIHZpcnR1YWwgbmV0d29ya3MuDQoyLiAgICAgIFVzaW5nIEJHUC9N UExTIFZQTiBleGFjdGx5IOKAmGFzIGl0IGlz4oCZIGludG8gREMgVk0gdmlydHVhbCBuZXR3b3Jr cw0KMy4gICAgICBFeHRlbmRpbmcvY3JlYXRpbmcgYW55IElQIFZQTiB0ZWNobm9sb2dpZXMgaW50 byBEQw0KNC4gICAgICBFeHRlbmRpbmcvY3JlYXRpbmcgb3IgcmV1c2UvbWFuYWdpbmcgc2VjdXJp dHkgcHJvdG9jb2xzIGZvciBEQyBjb25uZWN0aW9ucywgaW5jbHVkaW5nIGVuY3J5cHRpb24sIGtl eSBkaXN0cmlidXRpb24sIGtleSBtYW5hZ2VtZW50DQo1LiAgICAgIEV4dGVuZGluZy9jcmVhdGlu ZyBvciByZXVzZSBMMlZQTiBiYXNlZCB0ZWNobm9sb2dpZXMgaW50byBEQw0KDQpTb21lIG9mIHlv dSBwcmVmZXIgdG8gZm9jdXMgb24gb25lIG9mIHRoZSBvcHRpb25zLCB3aGlsZSBvdGhlcnMgbGlr ZSB0byBpbmNsdWRlIG11bHRpcGxlIG9wdGlvbnMuDQoNCkhlcmUgaXMgbXkgb2JzZXJ2YXRpb24g YW5kIHRob3VnaHQuDQoNCjEg4oCTIEl0IHNlZW1zIGEgY29tbW9uIGRlbm9taW5hdG9yLiBEaWQg bm90IGhlYXIgbm8gb24gdGhpcy4gIEl0IGlzIGV4YWN0bHkgdGhlIHByb2JsZW0gRGVyaWNrIHdh bnRpbmcgdG8gc29sdmUsIGl0IGlzIE5pbmfigJlzIHN0YXJ0aW5nIHBvaW50LCBhbmQgaXQgaXMg aW5jbHVkZWQgaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdHMuDQoyIOKAkyBJdCBkb2VzIG5vdCBu ZWVkIHRvIGNyZWF0ZSBvciBleHRlbmQgcHJvdG9jb2xzLCBzaG91bGQgZ28gdG8gT3BlcmF0aW9u IGFuZCBNYW5hZ2VtZW50IEFyZWEgZm9yIGFueSBvcHMgaXNzdWVzIGFuZCBiZXN0IHByYWN0aWNl Lg0KMyAtIFRoZSBzY29wZSBsb29rcyBiaWcgdG8gbWUsIHRoZSBsaXN0IGlzIHBvdGVudGlhbGx5 IHZlcnkgbG9uZy4NCjQgLSBJZiBuZXcgZW5jcnlwdGlvbiBhbGdvcml0aG0sIGJldHRlciBrZXkg ZGlzdHJpYnV0aW9uIG1lY2hhbmlzbSBhcmUgbmVlZGVkLCAgdGhlIHdvcmsgc2hvdWxkIGdvIHRv IFNlY3VyaXR5IEFyZWE7IGlmIG5vdGhpbmcgbmV3LCBvcHMgaXNzdWVzIGdvIHRvIE9wZXJhdGlv biBhbmQgTWFuYWdlbWVudCBBcmVhLg0KNSAtIEwyVlBOIGZvciBEQyB3b3JrIHNob3VsZCBnbyB0 byBMMlZQTiBXRywgaXQgaXMgZGVmaW5lZCBpbiBMMlZQTiBjaGFydGVyLg0KDQpUaGFua3MsDQpM dXl1YW4NCg0K --Boundary_(ID_2mj2zC1tCId3aTaJJHj3cw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYg OSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC55aXYx MjU5MjE2MTIybXNvcGxhaW50ZXh0LCBsaS55aXYxMjU5MjE2MTIybXNvcGxhaW50ZXh0LCBkaXYu eWl2MTI1OTIxNjEyMm1zb3BsYWludGV4dA0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjU5MjE2MTIy bXNvcGxhaW50ZXh0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQpwLnlpdjEyNTkyMTYxMjJtc29saXN0cGFyYWdyYXBoLCBsaS55aXYxMjU5MjE2MTIybXNvbGlz dHBhcmFncmFwaCwgZGl2LnlpdjEyNTkyMTYxMjJtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHls ZS1uYW1lOnlpdjEyNTkyMTYxMjJtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLnlpdjEyNTkyMTYxMjJtc29ub3JtYWwsIGxpLnlp djEyNTkyMTYxMjJtc29ub3JtYWwsIGRpdi55aXYxMjU5MjE2MTIybXNvbm9ybWFsDQoJe21zby1z dHlsZS1uYW1lOnlpdjEyNTkyMTYxMjJtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MTI1OTIxNjEyMm1zb2NocGRlZmF1bHQsIGxpLnlp djEyNTkyMTYxMjJtc29jaHBkZWZhdWx0LCBkaXYueWl2MTI1OTIxNjEyMm1zb2NocGRlZmF1bHQN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2MTI1OTIxNjEyMm1zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2MTI1OTIxNjEyMm1zb2h5 cGVybGluaw0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjU5MjE2MTIybXNvaHlwZXJsaW5rO30NCnNw YW4ueWl2MTI1OTIxNjEyMm1zb2h5cGVybGlua2ZvbGxvd2VkDQoJe21zby1zdHlsZS1uYW1lOnlp djEyNTkyMTYxMjJtc29oeXBlcmxpbmtmb2xsb3dlZDt9DQpzcGFuLnlpdjEyNTkyMTYxMjJwbGFp bnRleHRjaGFyDQoJe21zby1zdHlsZS1uYW1lOnlpdjEyNTkyMTYxMjJwbGFpbnRleHRjaGFyO30N CnNwYW4ueWl2MTI1OTIxNjEyMmVtYWlsc3R5bGUyMA0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjU5 MjE2MTIyZW1haWxzdHlsZTIwO30NCnNwYW4ueWl2MTI1OTIxNjEyMmVtYWlsc3R5bGUyMQ0KCXtt c28tc3R5bGUtbmFtZTp5aXYxMjU5MjE2MTIyZW1haWxzdHlsZTIxO30NCnAueWl2MTI1OTIxNjEy Mm1zb25vcm1hbDEsIGxpLnlpdjEyNTkyMTYxMjJtc29ub3JtYWwxLCBkaXYueWl2MTI1OTIxNjEy Mm1zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTI1OTIxNjEyMm1zb25vcm1hbDE7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2MTI1OTIx NjEyMm1zb2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTI1OTIxNjEyMm1zb2h5cGVy bGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u eWl2MTI1OTIxNjEyMm1zb2h5cGVybGlua2ZvbGxvd2VkMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYx MjU5MjE2MTIybXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAueWl2MTI1OTIxNjEyMm1zb3BsYWludGV4dDEsIGxpLnlp djEyNTkyMTYxMjJtc29wbGFpbnRleHQxLCBkaXYueWl2MTI1OTIxNjEyMm1zb3BsYWludGV4dDEN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2MTI1OTIxNjEyMm1zb3BsYWludGV4dDE7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZh bWlseTpDb25zb2xhczt9DQpwLnlpdjEyNTkyMTYxMjJtc29saXN0cGFyYWdyYXBoMSwgbGkueWl2 MTI1OTIxNjEyMm1zb2xpc3RwYXJhZ3JhcGgxLCBkaXYueWl2MTI1OTIxNjEyMm1zb2xpc3RwYXJh Z3JhcGgxDQoJe21zby1zdHlsZS1uYW1lOnlpdjEyNTkyMTYxMjJtc29saXN0cGFyYWdyYXBoMTsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi55aXYx MjU5MjE2MTIycGxhaW50ZXh0Y2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTI1OTIxNjEyMnBs YWludGV4dGNoYXIxOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4ueWl2MTI1OTIxNjEy MmVtYWlsc3R5bGUyMDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTI1OTIxNjEyMmVtYWlsc3R5bGUy MDE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLnlpdjEyNTkyMTYxMjJlbWFpbHN0eWxlMjExDQoJe21zby1zdHlsZS1uYW1lOnlp djEyNTkyMTYxMjJlbWFpbHN0eWxlMjExOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC55aXYxMjU5MjE2MTIybXNvY2hwZGVmYXVsdDEsIGxp LnlpdjEyNTkyMTYxMjJtc29jaHBkZWZhdWx0MSwgZGl2LnlpdjEyNTkyMTYxMjJtc29jaHBkZWZh dWx0MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjU5MjE2MTIybXNvY2hwZGVmYXVsdDE7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTM1 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlcmljayBhbmQgTHV5dWFuLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhlIG5ld2VyIGRyYWZ0IGhhcyBvbmUgcmVxdWlyZW1lbnQgZm9yIGV4dGVuZGluZyBWUE5z IGludG8gZGF0YWNlbnRlciBuZXR3b3JrcyB3aXRoIEwyL0wzVlBOLCBhbmQgYSBsYXJnZSBwb3J0 aW9uIG9mIHJlcXVpcmVtZW50cyBmb3IgdXNpbmcgVlBOIGdhdGV3YXkgZm9yDQogVlBOIGV4dGVu c2lvbiBpbnRvIGRhdGFjZW50ZXIuIFdlIHNob3VsZCBpbmNsdWRlIFZQTiBnYXRld2F5IGNhc2Ug aW4gdGhlIHNjb3BlIHRvby4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gVkRDUywgc29tZSBEQ3MgYXJlIG93bmVk IGJ5IGN1c3RvbWVyIGFuZCBzb21lIGJ5IERDIHByb3ZpZGVyIERDLiBJdCBpcyBub3QgcHJhY3Rp Y2FsIHRvIHJlcXVpcmUgY3VzdG9tZXIgcHJpdmF0ZSBkYXRhY2VudGVyIHRvIGltcGxlbWVudCBM Mi9MM1ZQTiBmb3IgZ2V0dGluZw0KIGEgVkRDUyBzZXJ2aWNlLiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+THVjeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERl cmljayBXaW5rd29ydGggW21haWx0bzpjY2llMTU2NzJAeWFob28uY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFN1bmRheSwgTm92ZW1iZXIgMDYsIDIwMTEgNjoxOSBQTTxicj4NCjxiPlRvOjwvYj4g THVjeSB5b25nOyBMdXl1YW4gRmFuZyAobHVmYW5nKTsgbDN2cG5AaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFZQTjREQyBTY29wZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkx1Y3k6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5UaGF0IGRyYWZ0IGlzIG9sZGVyLCB0cnk6ICZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNvLXZkY3MtMDIiPmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNvLXZkY3MtMDI8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5EZXJpY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9 InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIGFsaWduPSJj ZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4gTHVjeSB5b25nICZsdDtsdWN5LnlvbmdAaHVhd2VpLmNvbSZndDs8 YnI+DQo8Yj5Ubzo8L2I+IEx1eXVhbiBGYW5nIChsdWZhbmcpICZsdDtsdWZhbmdAY2lzY28uY29t Jmd0OzsgJnF1b3Q7bDN2cG5AaWV0Zi5vcmcmcXVvdDsgJmx0O2wzdnBuQGlldGYub3JnJmd0Ozxi cj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE5vdmVtYmVyIDYsIDIwMTEgMTI6NDUgUE08YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUkU6IFZQTjREQyBTY29wZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9InlpdjEyNTkyMTYxMjIiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkx1 eXVhbiw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkkgZG9u 4oCZdCB0aGluayB0aGlzIG1hdGNoZXMgVlBONERDIG9iamVjdGl2ZSBhbmQgcmVxdWlyZW1lbnRz LiAmbmJzcDsoZHJhZnQtc28tdnBuNGRjKQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj5UaGUgZHJhZnQgb2JqZWN0aXZlIGlzIHRvIGVuaGFuY2UgbmV0d29y ayBzZXJ2aWNlIHByb3ZpZGVyIEwzVlBOIHNlcnZpY2VzICZuYnNwO2ZvciBFbnRlcnByaXNlIERD cyBhbmQgUHJvdmlkZXIgREMgaW50ZXJjb25uZWN0aW9uLiAmbmJzcDsmbmJzcDtFbnRlcnByaXNl IGNhbiB1c2UgdmlydHVhbCByZXNvdXJjZXMNCiBpbiBQcm92aWRlciBEQyBhcyBpZiB0aGUgcmVz b3VyY2VzIGFyZSBpbiBpdHMgb3duIGRhdGFjZW50ZXIgYW5kIHJ1biBFbnRlcnByaXNlIGludHJh bmV0IGFwcGxpY2F0aW9ucy4gJm5ic3A7SXQgZG9lcyBub3QgY29uc3RyYWludCBhbnkgYXJjaGl0 ZWN0dXJlIGluIEVudGVycHJpc2UgREMgYW5kIFByb3ZpZGVyIERDLiBUaGUgaW4tYmFuZCBzaWdu YWxpbmcgY2FwYWJpbGl0eSBmb3IgaG9zdCBqb2luaW5nIGEgTDNWUE4gaW4gYSBzZXJ2aWNlIHBy b3ZpZGVyDQogbmV0d29yayBkb2VzIG5vdCBtZWFuIHRoZSBEQyB0aGF0IGhvc3QgcmVzaWRlcyBu ZWVkIHRvIGltcGxlbWVudCBMM1ZQTi48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMxRjQ5N0QiPlRoZSBwcm9wb3NhbHMgeW91IHB1dCBoZXJlIGFpbXMgb24gZXh0ZW5kaW5n IEwzVlBOIHRlY2hub2xvZ2llcyBpbnRvIERDIG9yIERDIFZNIHZpcnR1YWwgbmV0d29ya3MuIFdp bGwgdGhpcyBiZSBuZXR3b3JrIHNlcnZpY2UgcHJvdmlkZXJz4oCZIHJlcXVpcmVtZW50IG9yIERD IHByb3ZpZGVyc+KAmQ0KIHJlcXVpcmVtZW50PyBJIGRvbuKAmXQgc2VlIHN1Y2ggcmVxdWlyZW1l bnQgYW55d2hlcmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij5Ub2RheSwgRW50ZXJwcmlzZSBEQyByYXJlbHkgaW1wbGVtZW50IEwzVlBOIGFzIHdlbGwgYXMg REMgcHJvdmlkZXIuIEZvciBnZXR0aW5nIHNvbWUgdmlydHVhbCByZXNvdXJjZXMgaW4gUHJvdmlk ZXIgREMsIHdoeSBkb2VzIEVudGVycHJpc2UgbmVlZCB0byBjaGFuZ2UgdGhlaXIgREMgYXJjaGl0 ZWN0dXJlPw0KIERvIEkgbWlzcyBzb21ldGhpbmc/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgREMgVlBOIG9yIERDIFZNIHZpcnR1YWwg bmV0d29yayBhcmUgcG90ZW50aWFsIHN1YmplY3QgdG8gd29yayBvbiwgYnV0IHRoaXMgaXMgbm90 IHdoYXQgVlBONERDIHRhcmdldCBmb3IuIEFyZSB3ZSBjaGFuZ2luZyB0aGUgZGlyZWN0aW9uPzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+THVjeTwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6YmxhY2siPiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4t Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+THV5dWFuIEZhbmcgKGx1ZmFu Zyk8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE5vdmVtYmVyIDA1LCAyMDExIDE6MjUgQU08 YnI+DQo8Yj5Ubzo8L2I+IGwzdnBuQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFZQTjRE QyBTY29wZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5E ZWFyIGNvbGxlYWd1ZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+VGhhbmsgeW91IGFsbCBmb3IgdGhlIGNvbnN0cnVjdGl2ZSBkaXNjdXNz aW9uL3N1Z2dlc3Rpb25zIG92ZXIgdGhlIGxhc3QgZmV3IHdlZWtzIG9uIFZQTjREQy4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgdGhp bmsgd2Ugb2JzZXJ2ZWQgZ29vZCBpbnRlcmVzdHMvZW50aHVzaWFzbSBvbiBzb2x2aW5nIHRoZSBw cm9ibGVtcyBpbiB0aGlzIHNwYWNlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2UgbmVlZCB0byBuYXJyb3cgZG93biB0aGUgc2NvcGUg YXMgdGhlIG5leHQgc3RlcC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5JIHN1bW1hcml6ZWQgdGhlIHByb3Bvc2FscyBzZW50IG9uIHRoZSBsaXN0 IGFzIHRoZSBmb2xsb3dpbmc6ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TGV2ZXJhZ2UgQkdQL01QTFMgVlBOIHRlY2hub2xv Z2llcywgZXh0ZW5kaW5nIGl0IHdpdGggbDN2cG4gc2lnbmFsaW5nIHByb3RvY29scyBpbnRvIERD IFZNIHZpcnR1YWwgbmV0d29ya3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Mi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5Vc2luZyBCR1AvTVBMUyBWUE4gZXhhY3RseSDigJhhcyBpdCBp c+KAmSBpbnRvIERDIFZNIHZpcnR1YWwgbmV0d29ya3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkV4dGVuZGluZy9jcmVhdGluZyBhbnkgSVAg VlBOIHRlY2hub2xvZ2llcyBpbnRvIERDDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj40Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkV4dGVuZGluZy9jcmVhdGluZyBvciByZXVzZS9tYW5h Z2luZyBzZWN1cml0eSBwcm90b2NvbHMgZm9yIERDIGNvbm5lY3Rpb25zLCBpbmNsdWRpbmcgZW5j cnlwdGlvbiwga2V5IGRpc3RyaWJ1dGlvbiwga2V5IG1hbmFnZW1lbnQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj41Ljwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkV4dGVuZGluZy9jcmVhdGlu ZyBvciByZXVzZSBMMlZQTiBiYXNlZCB0ZWNobm9sb2dpZXMgaW50byBEQw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U29tZSBvZiB5b3Ug cHJlZmVyIHRvIGZvY3VzIG9uIG9uZSBvZiB0aGUgb3B0aW9ucywgd2hpbGUgb3RoZXJzIGxpa2Ug dG8gaW5jbHVkZSBtdWx0aXBsZSBvcHRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhlcmUgaXMgbXkgb2JzZXJ2YXRpb24gYW5kIHRo b3VnaHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+MSDigJMgSXQgc2VlbXMgYSBjb21tb24gZGVub21pbmF0b3IuIERpZCBub3QgaGVhciBu byBvbiB0aGlzLiAmbmJzcDtJdCBpcyBleGFjdGx5IHRoZSBwcm9ibGVtIERlcmljayB3YW50aW5n IHRvIHNvbHZlLCBpdCBpcyBOaW5n4oCZcyBzdGFydGluZyBwb2ludCwgYW5kIGl0IGlzIGluY2x1 ZGVkIGluIHRoZSByZXF1aXJlbWVudHMgZHJhZnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIg4oCTIEl0IGRvZXMgbm90IG5lZWQgdG8gY3Jl YXRlIG9yIGV4dGVuZCBwcm90b2NvbHMsIHNob3VsZCBnbyB0byBPcGVyYXRpb24gYW5kIE1hbmFn ZW1lbnQgQXJlYSBmb3IgYW55IG9wcyBpc3N1ZXMgYW5kIGJlc3QgcHJhY3RpY2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MyAtIFRoZSBzY29w ZSBsb29rcyBiaWcgdG8gbWUsIHRoZSBsaXN0IGlzIHBvdGVudGlhbGx5IHZlcnkgbG9uZy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj40IC0gSWYg bmV3IGVuY3J5cHRpb24gYWxnb3JpdGhtLCBiZXR0ZXIga2V5IGRpc3RyaWJ1dGlvbiBtZWNoYW5p c20gYXJlIG5lZWRlZCwgJm5ic3A7dGhlIHdvcmsgc2hvdWxkIGdvIHRvIFNlY3VyaXR5IEFyZWE7 IGlmIG5vdGhpbmcgbmV3LCBvcHMgaXNzdWVzIGdvIHRvIE9wZXJhdGlvbiBhbmQgTWFuYWdlbWVu dCBBcmVhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjUgLSBMMlZQTiBmb3IgREMgd29yayBzaG91bGQgZ28gdG8gTDJWUE4gV0csIGl0IGlzIGRl ZmluZWQgaW4gTDJWUE4gY2hhcnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+THV5dWFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --Boundary_(ID_2mj2zC1tCId3aTaJJHj3cw)-- From pedro.r.marques@gmail.com Mon Nov 7 09:24: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 15D4221F8C51 for ; Mon, 7 Nov 2011 09:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.100, 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 lWD2TxNcOTSn for ; Mon, 7 Nov 2011 09:24:15 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 887B221F8C49 for ; Mon, 7 Nov 2011 09:24:15 -0800 (PST) Received: by ggnv1 with SMTP id v1so6459360ggn.31 for ; Mon, 07 Nov 2011 09:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=q+lmv8YigfAGvb2QKQfxKO7nn9vX54+6O2G6668W1n4=; b=tKGcFXdm0rTYmlMFcZUngtJkH/6XjmAR1B9Gq9xv9f33UtoxNXnLhBQf0geobH6O5s 8NIhgCZaJ+1GXeDbG9QbhhJ9J4r1xxPQpoi72RcrpfLHL2pZM3Y1q8ACaI2u3N9SNyY7 zJzfi4mVqPzLCqgbTmYlKlUKCAzcYBpDr6VBM= MIME-Version: 1.0 Received: by 10.50.42.198 with SMTP id q6mr46378488igl.34.1320686653929; Mon, 07 Nov 2011 09:24:13 -0800 (PST) Received: by 10.231.12.2 with HTTP; Mon, 7 Nov 2011 09:24:13 -0800 (PST) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D118DE89B@dfweml506-mbx> References: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D118DE89B@dfweml506-mbx> Date: Mon, 7 Nov 2011 09:24:13 -0800 Message-ID: Subject: Re: VPN4DC Scope From: Pedro Marques To: Lucy yong Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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, 07 Nov 2011 17:24:16 -0000 Lucy, On Sun, Nov 6, 2011 at 10:45 AM, Lucy yong wrote: > I don=92t think this matches VPN4DC objective and requirements. > =A0(draft-so-vpn4dc) > > > > The draft objective is to enhance network service provider L3VPN services > =A0for Enterprise DCs and Provider DC interconnection. Does "Enhancing L3VPN services" describe a business model concept or a specific technical problem ? > =A0=A0Enterprise can use > virtual resources in Provider DC as if the resources are in its own > datacenter and run Enterprise intranet applications. Business model aside, that sounds perfectly doable with today's set of standards. > =A0It does not constraint > any architecture in Enterprise DC and Provider DC. Section 5 of the document you referred to as a set of requirements that seem to imply an architecture for the DC connectivity although i'm not able to understand the context where they fit. For example: o Once the hypervisor or Top Of Rack switch is configured to connect the host to a DC gateway, the hosts in DC SHALL be able to signal to DC gateway switch/router (L3VPN CE) to join a specific VPN. The join request CAN include the basic service requirements such as bandwidth and QoS. In this context it is unclear to me what the "host" is or the set of assumptions that lead the author to specify that the hosts SHALL be able to signal the gateway. If one does assume, for instance, that the VPN network associated with a given DC tenant is implemented as an isolated VLAN, which is a common assumption made by lots of solutions, why would there be the need to "signal" a "join" request ? What does that mean in that context ? > The in-band signaling > capability for host joining a L3VPN in a service provider network does no= t > mean the DC that host resides need to implement L3VPN. I don't understand the assumption that there is any need for in-band signaling. Please explain why do you believe there is such a need. It is also unclear what is being signaled. > > The proposals you put here aims on extending L3VPN technologies into DC o= r > DC VM virtual networks. > Will this be network service providers=92 requirement > or DC providers=92 requirement? I don=92t see such requirement anywhere. You do seem to see a requirement for "signaling". That probably means that you have some assumption of how the DC network provides network virtualization for a given tenant. It would be interesting if you could share that assumption and at least compare it with the minimum common denominator which seems to be the assumption of a VLAN per tenant. regards, Pedro. From lucy.yong@huawei.com Mon Nov 7 10:08: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 A551E1F0C3E for ; Mon, 7 Nov 2011 10:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.653 X-Spam-Level: X-Spam-Status: No, score=-5.653 tagged_above=-999 required=5 tests=[AWL=-0.254, 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 yTGb1MfJHPYM for ; Mon, 7 Nov 2011 10:08:15 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 190441F0C38 for ; Mon, 7 Nov 2011 10:08:15 -0800 (PST) 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 <0LUA00MPTXVU59@usaga02-in.huawei.com> for l3vpn@ietf.org; Mon, 07 Nov 2011 11:57:30 -0600 (CST) 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 <0LUA001Z6XVUA4@usaga02-in.huawei.com> for l3vpn@ietf.org; Mon, 07 Nov 2011 11:57:30 -0600 (CST) 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, 07 Nov 2011 09:57:28 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 09:57:23 -0800 Date: Mon, 07 Nov 2011 17:57:23 +0000 From: Lucy yong Subject: RE: VPN4DC Scope In-reply-to: X-Originating-IP: [10.47.144.191] To: Pedro Marques Message-id: <2691CE0099834E4A9C5044EEC662BB9D118DEBED@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: VPN4DC Scope Thread-index: AQHMnXIRe36EuiLJTVqFN1kI+DCFUZWhqnNA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D118DE89B@dfweml506-mbx> 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, 07 Nov 2011 18:08:15 -0000 Hi Pedro, See inline. -----Original Message----- From: Pedro Marques [mailto:pedro.r.marques@gmail.com]=20 Sent: Monday, November 07, 2011 11:24 AM To: Lucy yong Cc: Luyuan Fang (lufang); l3vpn@ietf.org Subject: Re: VPN4DC Scope Lucy, On Sun, Nov 6, 2011 at 10:45 AM, Lucy yong wrote: > I don't think this matches VPN4DC objective and requirements. > =A0(draft-so-vpn4dc) > > > > The draft objective is to enhance network service provider L3VPN services > =A0for Enterprise DCs and Provider DC interconnection. Does "Enhancing L3VPN services" describe a business model concept or a specific technical problem ? [[LY]] It is both. There is a business model that can't be supported with t= oday's technology.=20 > =A0=A0Enterprise can use > virtual resources in Provider DC as if the resources are in its own > datacenter and run Enterprise intranet applications. Business model aside, that sounds perfectly doable with today's set of standards. [[LY]] How does a customer ensure the virtual resource in Provider DC it bu= ys to attach the L3VPN it uses? > =A0It does not constraint > any architecture in Enterprise DC and Provider DC. Section 5 of the document you referred to as a set of requirements that seem to imply an architecture for the DC connectivity although i'm not able to understand the context where they fit. For example: o Once the hypervisor or Top Of Rack switch is configured to connect the host to a DC gateway, the hosts in DC SHALL be able to signal to DC gateway switch/router (L3VPN CE) to join a specific VPN. The join request CAN include the basic service requirements such as bandwidth and QoS. In this context it is unclear to me what the "host" is or the set of assumptions that lead the author to specify that the hosts SHALL be able to signal the gateway. If one does assume, for instance, that the VPN network associated with a given DC tenant is implemented as an isolated VLAN, which is a common assumption made by lots of solutions, why would there be the need to "signal" a "join" request ? What does that mean in that context ? > The in-band signaling > capability for host joining a L3VPN in a service provider network does no= t > mean the DC that host resides need to implement L3VPN. I don't understand the assumption that there is any need for in-band signaling. Please explain why do you believe there is such a need. It is also unclear what is being signaled. [[LY]] VPN4DC and VDCS draft express the need clear. > > The proposals you put here aims on extending L3VPN technologies into DC o= r > DC VM virtual networks. > Will this be network service providers' requirement > or DC providers' requirement? I don't see such requirement anywhere. You do seem to see a requirement for "signaling". That probably means that you have some assumption of how the DC network provides network virtualization for a given tenant. It would be interesting if you could share that assumption and at least compare it with the minimum common denominator which seems to be the assumption of a VLAN per tenant. [[LY]] what I mean is DC virtualization is not VPN4DC goal. But I agree tha= t DC host/network virtualization has some technical problems today. IEEE is= working on it and your draft also proposes one solution. Regards, Lucy regards, Pedro. From pedro.r.marques@gmail.com Mon Nov 7 11:10:32 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 092F121F84F5 for ; Mon, 7 Nov 2011 11:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.094, 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 oFSouIZmaqIC for ; Mon, 7 Nov 2011 11:10:31 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DACCF21F84AC for ; Mon, 7 Nov 2011 11:10:30 -0800 (PST) Received: by iaeo4 with SMTP id o4so7875158iae.31 for ; Mon, 07 Nov 2011 11:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EAJBZdC/Tapi9TwaumisGPP7DtchlnFs55W6JqRBSKo=; b=Jg7TVi+G+/4YGHGQo6smIkgUUyrjAYVQw+lWwCUjtvUN0pwhBElkcwGKhNtJDRVMGb EOhKkpC+XsI8X97bSpfyoEdF3/lNvlYL7oSAFeeSaB1ffoyEqud6/5q+fXx5Xo5LIMUE 1mMgnLdNDBM/ixRVfVThT/JQHMTqCxJsBtZxU= MIME-Version: 1.0 Received: by 10.231.83.201 with SMTP id g9mr5413224ibl.68.1320693022855; Mon, 07 Nov 2011 11:10:22 -0800 (PST) Received: by 10.231.12.2 with HTTP; Mon, 7 Nov 2011 11:10:22 -0800 (PST) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D118DEBED@dfweml506-mbx> References: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D118DE89B@dfweml506-mbx> <2691CE0099834E4A9C5044EEC662BB9D118DEBED@dfweml506-mbx> Date: Mon, 7 Nov 2011 11:10:22 -0800 Message-ID: Subject: Re: VPN4DC Scope From: Pedro Marques To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 07 Nov 2011 19:10:32 -0000 Lucy, On Mon, Nov 7, 2011 at 9:57 AM, Lucy yong wrote: >> =A0=A0Enterprise can use >> virtual resources in Provider DC as if the resources are in its own >> datacenter and run Enterprise intranet applications. > > Business model aside, that sounds perfectly doable with today's set of > standards. > [[LY]] How does a customer ensure the virtual resource in Provider DC it = buys to attach the L3VPN it uses? I'll assume that you question is "how does an enterprise VPN interconnect with the corresponding data-center VPN for that tennant", assuming the customer uses an l3vpn. This is no different from VPN interconnection between multiple service providers. Both inter-as option A and option B would work to establish the interconnect. > I don't understand the assumption that there is any need for in-band > signaling. Please explain why do you believe there is such a need. It > is also unclear what is being signaled. > [[LY]] VPN4DC and VDCS draft express the need clear. It is not clear to me. Can you please elaborate ? For instance assume that the DC uses a VLAN per tenant and uses option B interconnect to a carrier. That would be a reasonable starting point, i believe. > [[LY]] what I mean is DC virtualization is not VPN4DC goal. But I agree t= hat DC host/network virtualization has some technical problems today. IEEE = is working on it and your draft also proposes one solution. > As far as i can see you do assume some solution to the DC network virtualization problem that is neither IEEE based or what is described in the l3vpn-end-system draft since you have identified the need from signaling from the "host". That need is not present in either of these approaches. Pedro. From ning.so@verizon.com Mon Nov 7 12:18: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 779C611E80BB for ; Mon, 7 Nov 2011 12:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_41=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 SscnqV3nAd3o for ; Mon, 7 Nov 2011 12:18:28 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id A32E111E80B8 for ; Mon, 7 Nov 2011 12:18:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 07 Nov 2011 20:18:27 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.69,471,1315180800"; d="scan'208";a="175280521" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 07 Nov 2011 20:18:27 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.133]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Mon, 7 Nov 2011 15:18:27 -0500 To: "l3vpn@ietf.org" Date: Mon, 7 Nov 2011 15:18:25 -0500 Subject: RE: RE: VPN4DC Scope Thread-Topic: RE: VPN4DC Scope Thread-Index: Acydic8q+rAEJnuxTiSm+xr0icDy1Q== Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08F9B4FC6@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: Mon, 07 Nov 2011 20:18:29 -0000 Lucy, Thanks for your input. Luyuan summarized pretty well the discussions we ha= ve had in the past week. I combined the 1st two items she listed and gener= alized the goal of VPN4DC effort as follows: leverage BGP/MPLS VPN technol= ogies and L3VPN signaling protocols, extending and/or interworking them wit= h DC virtual networks so that the hosts in DC can automatically join the L3= VPN to form any-host-to-any-host connections through L3VPN. That goal is the foundation for all the other discussions around this topic= , and there seems to be common agreement to it. Please let me know your th= oughts. =20 =A0 Best regards, =A0 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =A0 Derick and Luyuan, The newer draft has one requirement for extending VPNs into datacenter netw= orks with L2/L3VPN, and a large portion of requirements for using VPN gatew= ay for VPN extension into datacenter. We should include VPN gateway case in= the scope too. In VDCS, some DCs are owned by customer and some by DC provider DC. It is n= ot practical to require customer private datacenter to implement L2/L3VPN f= or getting a VDCS service. Thanks, Lucy From: Derick Winkworth [mailto:ccie15672@yahoo.com] Sent: Sunday, November 06, 2011 6:19 PM To: Lucy yong; Luyuan Fang (lufang); l3vpn@ietf.org Subject: Re: VPN4DC Scope Lucy: That draft is older, try: http://tools.ietf.org/html/draft-so-vdcs-02 Derick ________________________________ From: Lucy yong To: Luyuan Fang (lufang) ; "l3vpn@ietf.org" Sent: Sunday, November 6, 2011 12:45 PM Subject: RE: VPN4DC Scope Luyuan, I don?t think this matches VPN4DC objective and requirements. (draft-so-vp= n4dc) The draft objective is to enhance network service provider L3VPN services = for Enterprise DCs and Provider DC interconnection. Enterprise can use vi= rtual resources in Provider DC as if the resources are in its own datacente= r and run Enterprise intranet applications. It does not constraint any arc= hitecture in Enterprise DC and Provider DC. The in-band signaling capabilit= y for host joining a L3VPN in a service provider network does not mean the = DC that host resides need to implement L3VPN. The proposals you put here aims on extending L3VPN technologies into DC or = DC VM virtual networks. Will this be network service providers? requirement= or DC providers? requirement? I don?t see such requirement anywhere. Today, Enterprise DC rarely implement L3VPN as well as DC provider. For get= ting some virtual resources in Provider DC, why does Enterprise need to cha= nge their DC architecture? Do I miss something? I agree that DC VPN or DC VM virtual network are potential subject to work = on, but this is not what VPN4DC target for. Are we changing the direction? Regards, Lucy From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of L= uyuan Fang (lufang) Sent: Saturday, November 05, 2011 1:25 AM To: l3vpn@ietf.org Subject: VPN4DC Scope Dear colleagues, Thank you all for the constructive discussion/suggestions over the last few= weeks on VPN4DC. I think we observed good interests/enthusiasm on solving the problems in th= is space. We need to narrow down the scope as the next step. I summarized the proposals sent on the list as the following: 1. Leverage BGP/MPLS VPN technologies, extending it with l3vpn signali= ng protocols into DC VM virtual networks. 2. Using BGP/MPLS VPN exactly ?as it is? into DC VM virtual networks 3. Extending/creating any IP VPN technologies into DC 4. Extending/creating or reuse/managing security protocols for DC conn= ections, including encryption, key distribution, key management 5. Extending/creating or reuse L2VPN based technologies into DC Some of you prefer to focus on one of the options, while others like to inc= lude multiple options. Here is my observation and thought. 1 ? It seems a common denominator. Did not hear no on this. It is exactly = the problem Derick wanting to solve, it is Ning?s starting point, and it is= included in the requirements drafts. 2 ? It does not need to create or extend protocols, should go to Operation = and Management Area for any ops issues and best practice. 3 - The scope looks big to me, the list is potentially very long. 4 - If new encryption algorithm, better key distribution mechanism are need= ed, the work should go to Security Area; if nothing new, ops issues go to = Operation and Management Area. 5 - L2VPN for DC work should go to L2VPN WG, it is defined in L2VPN charter= . Thanks, Luyuan -------------- 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 89, Issue 25 ************************************* From robert@raszuk.net Mon Nov 7 16:04:14 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 A12541F0C44 for ; Mon, 7 Nov 2011 16:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=-0.247, 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 cBIvx0XHnw15 for ; Mon, 7 Nov 2011 16:04:14 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id AFFD221F85A1 for ; Mon, 7 Nov 2011 16:04:13 -0800 (PST) Received: (qmail 20185 invoked by uid 399); 8 Nov 2011 00:04:08 -0000 Received: from unknown (HELO ?216.69.73.175?) (216.69.73.175) by mail37.opentransfer.com with SMTP; 8 Nov 2011 00:04:08 -0000 Message-ID: <4EB871F7.5000605@raszuk.net> Date: Tue, 08 Nov 2011 01:04:07 +0100 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: "Luyuan Fang (lufang)" Subject: Re: VPN4DC Scope References: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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, 08 Nov 2011 00:04:14 -0000 Hi Luyuan, As we are getting down to the scope debate I think it would be quite productive to discuss one solution apparently already available for arbitrary secured interconnection of host or sites. http://vcider.com/ In particular I think it would be quite interesting to know what is missing from the above solution or this class of solutions in general for the problem space we are discussing here. It seems to me that this class of solutions is sufficiently flexible to address number of VPN4DC and beyond needs without any prerequisites reg topology or connectivity requirements. Many thx, R. > Dear colleagues, > > Thank you all for the constructive discussion/suggestions over the last > few weeks on VPN4DC. > > > > I think we observed good interests/enthusiasm on solving the problems in > this space. > > > > We need to narrow down the scope as the next step. > > I summarized the proposals sent on the list as the following: > > > > 1. Leverage BGP/MPLS VPN technologies, extending it with l3vpn > signaling protocols into DC VM virtual networks. > > 2. Using BGP/MPLS VPN exactly 'as it is' into DC VM virtual > networks > > 3. Extending/creating any IP VPN technologies into DC > > 4. Extending/creating or reuse/managing security protocols for DC > connections, including encryption, key distribution, key management > > 5. Extending/creating or reuse L2VPN based technologies into DC > > > > Some of you prefer to focus on one of the options, while others like to > include multiple options. > > > > Here is my observation and thought. > > > > 1 - It seems a common denominator. Did not hear no on this. It is > exactly the problem Derick wanting to solve, it is Ning's starting > point, and it is included in the requirements drafts. > > 2 - It does not need to create or extend protocols, should go to > Operation and Management Area for any ops issues and best practice. > > 3 - The scope looks big to me, the list is potentially very long. > > 4 - If new encryption algorithm, better key distribution mechanism are > needed, the work should go to Security Area; if nothing new, ops issues > go to Operation and Management Area. > > 5 - L2VPN for DC work should go to L2VPN WG, it is defined in L2VPN > charter. > > > > Thanks, > > Luyuan > > From ccie15672@yahoo.com Mon Nov 7 18:12: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 DAD471F0C52 for ; Mon, 7 Nov 2011 18:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.326 X-Spam-Level: X-Spam-Status: No, score=0.326 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_20=-0.74, 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 IUKbpCuijkOY for ; Mon, 7 Nov 2011 18:12:27 -0800 (PST) Received: from nm17.bullet.mail.bf1.yahoo.com (nm17.bullet.mail.bf1.yahoo.com [98.139.212.176]) by ietfa.amsl.com (Postfix) with SMTP id 4BB8C1F0C54 for ; Mon, 7 Nov 2011 18:12:24 -0800 (PST) Received: from [98.139.212.145] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 08 Nov 2011 02:12:21 -0000 Received: from [98.139.212.244] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 08 Nov 2011 02:12:21 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 08 Nov 2011 02:12:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 177878.84415.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 58173 invoked by uid 60001); 8 Nov 2011 02:12:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1320718341; bh=V9WGOov1N0XpD+tDNpTxOfPpBtLDWnfBmpeYDky5YiI=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hY6ZXMPcLVDRtdA6GrQUkscsJVDK/BwMWneebPo2Azu9cDT+xB0+TvdaGh3kweNkf3sgLol3uU+5+3mCNEwGxqND3hUXGeabf0lHmJZuY//JJs7GPeOpo51oiIm3/PBYRKKCMMYat+DFGHf0V3TfvlEoibH7cMUgN60215Y3/10= 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=ktD5ddg0kAbJJ8RrRc7ZhJ+5BSkGo/Q9QMtdv30D95VSHTA4ql2ZwYPJ0VyB05OZRUw9X69xSvCeVTenWvN2FJrqW4glrxASfGWqwCIXgOfmYzkPz196vL6SJ0amjlZ5IdvmT5GTRzqCEvKrh7Hz/JOhCng9R/RnelGk4C3X5JE=; X-YMail-OSG: v1u4GwQVM1mti_8nPoBrh3umFR2It6q29nwhj1pIk1eBLe9 zI0_4nsOo3F01bCQp8J5.arPhGCQe4ZXdPrbohsxP1.hVumul9cq1S21uM8K iBv90K0k0B6AIfXFDzjLQsqAaXFTtJXEtaokCBvhCo.qhG2jaziPgshAUtUU z4XPcjQC5fPsJxYx5qBnaY4VeE5DpKd17CpiquSXUr_mBHZ2PDD97NpfbEvq t66he7AK9P3Gy7GnNRRDtQ1Hs0goV8fObp67uWton7ryGSqS2IPGa_X8VJVx RWyxihVQYnbqO5Xda1AG5WAUVFIHfJqUX1Z370sGIe4yv1XTsSStZ2oTYe4o PziUY3l2p_SuxYNPKJ0VNIX1C1aNcOjgrcyUF7PYb9afzGg7DQ5BWsGWpV0i BjajOiXlzpZnBd3AV3UDXXA2sAv0X9QA0RJpsqQ.OgEqK3OWdV49b76fbyed sPWiNFXZJvFdFIxmWLCpUoCgKY1dNuzA- Received: from [76.194.43.66] by web161801.mail.bf1.yahoo.com via HTTP; Mon, 07 Nov 2011 18:12:21 PST X-Mailer: YahooMailWebService/0.8.114.317681 References: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D118DE89B@dfweml506-mbx> <1320625150.80915.YahooMailNeo@web161802.mail.bf1.yahoo.com> <2691CE0099834E4A9C5044EEC662BB9D118DEAD0@dfweml506-mbx> Message-ID: <1320718341.28927.YahooMailNeo@web161801.mail.bf1.yahoo.com> Date: Mon, 7 Nov 2011 18:12:21 -0800 (PST) From: Derick Winkworth Subject: Re: VPN4DC Scope To: "l3vpn@ietf.org" In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D118DEAD0@dfweml506-mbx> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1882999342-394671999-1320718341=:28927" 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, 08 Nov 2011 02:12:29 -0000 --1882999342-394671999-1320718341=:28927 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Lucy:=0A=0A----------=0AIn VDCS, some DCs are owned by customer and some by= DC provider DC. It is not practical to require customer private datacenter= to implement L2/L3VPN for getting a VDCS service.=0A=0A-----------=0A=0ATh= e customer is not required to manage their own MPLS network (i.e., label-sw= itching 'P' nodes and 'PE' nodes). =C2=A0However, in the scenario we are pr= oposing the customer would be using an L3VPN service provided by an SP such= as Verizon or twTelecom (i.e., the customer has CE devices in their locati= ons connecting to service-provider's PE devices over a circuit).=C2=A0=0A= =0ADerick=0A=0A=0A=0A=C2=A0=0A=0A=0A=0A________________________________=0AF= rom: Lucy yong =0ATo: Derick Winkworth ; Luyuan Fang (lufang) ; "l3vpn@ietf.org" =0ASent: Monday, November 7, 2011 10:04 AM=0ASubject: RE: VPN4DC Sc= ope=0A=0A=0A =0ADerick and Luyuan,=0A=C2=A0=0AThe newer draft has one requi= rement for extending VPNs into datacenter networks with L2/L3VPN, and a lar= ge portion of requirements for using VPN gateway for VPN extension into dat= acenter. We should include VPN gateway case in the scope too. =0A=C2=A0=0AI= n VDCS, some DCs are owned by customer and some by DC provider DC. It is no= t practical to require customer private datacenter to implement L2/L3VPN fo= r getting a VDCS service. =0A=C2=A0=0AThanks,=0ALucy=0A=C2=A0=0AFrom:Derick= Winkworth [mailto:ccie15672@yahoo.com] =0ASent: Sunday, November 06, 2011 = 6:19 PM=0ATo: Lucy yong; Luyuan Fang (lufang); l3vpn@ietf.org=0ASubject: Re= : VPN4DC Scope=0A=C2=A0=0ALucy:=0A=C2=A0=0AThat draft is older, try: =C2=A0= http://tools.ietf.org/html/draft-so-vdcs-02=0A=C2=A0=0ADerick=0A=C2=A0=0A= =0A________________________________=0A =0AFrom:Lucy yong =0ATo: Luyuan Fang (lufang) ; "l3vpn@ietf.org" =0ASent: Sunday, November 6, 2011 12:45 PM=0ASubject: RE: VPN4DC = Scope=0ALuyuan,=0A=C2=A0=0AI don=E2=80=99t think this matches VPN4DC object= ive and requirements. =C2=A0(draft-so-vpn4dc) =0A=C2=A0=0AThe draft objecti= ve is to enhance network service provider L3VPN services =C2=A0for Enterpri= se DCs and Provider DC interconnection. =C2=A0=C2=A0Enterprise can use virt= ual resources in Provider DC as if the resources are in its own datacenter = and run Enterprise intranet applications. =C2=A0It does not constraint any = architecture in Enterprise DC and Provider DC. The in-band signaling capabi= lity for host joining a L3VPN in a service provider network does not mean t= he DC that host resides need to implement L3VPN.=0A=C2=A0=0AThe proposals y= ou put here aims on extending L3VPN technologies into DC or DC VM virtual n= etworks. Will this be network service providers=E2=80=99 requirement or DC = providers=E2=80=99 requirement? I don=E2=80=99t see such requirement anywhe= re.=0A=C2=A0=0AToday, Enterprise DC rarely implement L3VPN as well as DC pr= ovider. For getting some virtual resources in Provider DC, why does Enterpr= ise need to change their DC architecture? Do I miss something?=0A=C2=A0=0AI= agree that DC VPN or DC VM virtual network are potential subject to work o= n, but this is not what VPN4DC target for. Are we changing the direction?= =0A=C2=A0=0ARegards,=0ALucy=0A=C2=A0=0AFrom:l3vpn-bounces@ietf.org [mailto:= l3vpn-bounces@ietf.org] On Behalf Of Luyuan Fang (lufang)=0ASent: Saturday,= November 05, 2011 1:25 AM=0ATo: l3vpn@ietf.org=0ASubject: VPN4DC Scope=0A= =C2=A0=0ADear colleagues,=0A=C2=A0=0AThank you all for the constructive dis= cussion/suggestions over the last few weeks on VPN4DC. =0A=C2=A0=0AI think = we observed good interests/enthusiasm on solving the problems in this space= . =0A=C2=A0=0AWe need to narrow down the scope as the next step.=0AI summar= ized the proposals sent on the list as the following: =C2=A0=0A=C2=A0=0A1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Leverage BGP/MPLS VPN technologies, extendin= g it with l3vpn signaling protocols into DC VM virtual networks.=0A2.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Using BGP/MPLS VPN exactly =E2=80=98as it is=E2=80= =99 into DC VM virtual networks=0A3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extendin= g/creating any IP VPN technologies into DC =0A4.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Extending/creating or reuse/managing security protocols for DC connecti= ons, including encryption, key distribution, key management=0A5.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Extending/creating or reuse L2VPN based technologies = into DC =0A=C2=A0=0ASome of you prefer to focus on one of the options, whil= e others like to include multiple options.=0A=C2=A0=0AHere is my observatio= n and thought.=0A=C2=A0=0A1 =E2=80=93 It seems a common denominator. Did no= t hear no on this. =C2=A0It is exactly the problem Derick wanting to solve,= it is Ning=E2=80=99s starting point, and it is included in the requirement= s drafts.=0A2 =E2=80=93 It does not need to create or extend protocols, sho= uld go to Operation and Management Area for any ops issues and best practic= e.=0A3 - The scope looks big to me, the list is potentially very long.=0A4 = - If new encryption algorithm, better key distribution mechanism are needed= , =C2=A0the work should go to Security Area; if nothing new, ops issues go = to Operation and Management Area.=0A5 - L2VPN for DC work should go to L2VP= N WG, it is defined in L2VPN charter.=0A=C2=A0=0AThanks,=0ALuyuan --1882999342-394671999-1320718341=:28927 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Lucy:
----------
In VDCS,= some DCs are owned by customer and some by DC provider DC. It is not pract= ical to require customer private datacenter to implement L2/L3VPN for getti= ng a VDCS service.
-----------

<= /div>
The customer is not required to manage their own MPLS network (i.= e., label-switching 'P' nodes and 'PE' nodes).  However, in the scenar= io we are proposing the customer would be using an L3VPN service provided b= y an SP such as Verizon or twTelecom (i.e., the customer has CE devices in = their locations connecting to service-provider's PE devices over a circuit)= . 

Derick


=

 


From: Lucy yong <lucy.yong@huawe= i.com>
To: Derick Wi= nkworth <ccie15672@yahoo.com>; Luyuan Fang (lufang) <lufang@cisco.= com>; "l3vpn@ietf.org" <l3vpn@ietf.org>
Sent: Monday, November 7, 2011 10:04 AM
Subject: RE: VPN4DC Scope

=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
Derick and Luyuan,
=0A
 
=0A
The newer draft has one requirement = for extending VPNs into datacenter networks with L2/L3VPN, and a large port= ion of requirements for using VPN gateway for=0A VPN extension into datacen= ter. We should include VPN gateway case in the scope too.=0A
= =0A
 
=0A
In VDCS, some DCs are owne= d by customer and some by DC provider DC. It is not practical to require cu= stomer private datacenter to implement L2/L3VPN for getting=0A a VDCS servi= ce.
=0A
 
=0A
Thanks,<= /span>
=0A
Lucy
=0A
  =0A
=0A
=0A
From: Derick Winkworth [mailto:ccie15672@yahoo.com]=0A
=0ASent: Su= nday, November 06, 2011 6:19 PM
=0ATo: Lucy yong; Luyuan Fang (lu= fang); l3vpn@ietf.org
=0ASubject: Re: VPN4DC Scope
= =0A
=0A
=0A
 
= =0A
=0A
=0A
Lucy:
= =0A
=0A
=0A
  =0A
=0A
=0A
That draft is o= lder, try:  http://tools.ietf.org/html/draft-so-vdcs-02
= =0A
=0A
=0A
  =0A
=0A
=0A
Derick =0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
From: Lucy yong <lucy.yong@huawei.com>
=0ATo: Luyuan Fang (= lufang) <lufang@cisco.com>; "l3vpn@ietf.org" <l3vpn@ietf.org>=0ASent: Sunday, November 6, 2011 12:45 PM
=0ASubject: R= E: VPN4DC Scope
=0A
=0A
=0A
=0A
=0A
Luyuan,
=0A=0A
=0A
 
=0A
=0A
=0A
I don=E2=80=99t think this matches VPN4DC objective and req= uirements.  (draft-so-vpn4dc)=0A
=0A
=0A
=0A
&nbs= p;
=0A
=0A
=0AThe draft objective is to enhance netw= ork service provider L3VPN services  for Enterprise DCs and Provider D= C interconnection.   Enterprise can use virtual resources=0A in P= rovider DC as if the resources are in its own datacenter and run Enterprise= intranet applications.  It does not constraint any architecture in En= terprise DC and Provider DC. The in-band signaling capability for host join= ing a L3VPN in a service provider=0A network does not mean the DC that host= resides need to implement L3VPN.
=0A
=0A
=0A
 
=0A
=0A
=0A
The proposals you put here aims on extendin= g L3VPN technologies into DC or DC VM virtual networks. Will this be networ= k service providers=E2=80=99 requirement or DC providers=E2=80=99=0A requir= ement? I don=E2=80=99t see such requirement anywhere.
=0A
=0A
=0A
 
=0A=0A
=0A
Today, Enterprise DC ra= rely implement L3VPN as well as DC provider. For getting some virtual resou= rces in Provider DC, why does Enterprise need to change their DC architectu= re?=0A Do I miss something? =0A
=0A
=0A
 <= span style=3D"color:black;">
=0A
=0A
=0A
I agree that DC VPN or DC VM virtual network are = potential subject to work on, but this is not what VPN4DC target for. Are w= e changing the direction?
= =0A
=0A
=0A
 
=0A
=0A
=0A
Regards,=
=0A
=0A
=0A
Lucy
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org]=0AOn Behalf O= f Luyuan Fang (lufang)
=0ASent: Saturday, November 05, 2011 1= :25 AM
=0ATo: l3vpn@ietf.org
=0ASubject: VPN4DC Scope
=0A
=0A
=0A
= =0A
=0A
 
=0A
=0A
=0ADear colleagues,
=0A
=0A
=0A
 
=0A
=0A
=0A
Th= ank you all for the constructive discussion/suggestions over the last few w= eeks on VPN4DC.=0A
=0A
=0A
=0A
&nb= sp;
=0A
=0A
=0A
I think we observe= d good interests/enthusiasm on solving the problems in this space.=0A
=0A
=0A
=0A
 
=0A=0A
=0A
We need to narrow down the scope as the ne= xt step.
=0A
=0A
=0A
I summarized = the proposals sent on the list as the following:  
=0A=0A
=0A
 
=0A
=0A
=0A<= div class=3D"yiv1928754807MsoNormal" style=3D"background:white;">1.&n= bsp;    =0ALeverage= BGP/MPLS VPN technologies, extending it with l3vpn signaling protocols int= o DC VM virtual networks.
=0A
=0A
=0A
2.   = ;  =0AUsing BGP/MPLS VPN exac= tly =E2=80=98as it is=E2=80=99 into DC VM virtual networks
=0A=
=0A
=0A
3.     =0AExtending/creating any IP VPN technologies into DC=0A =0A
=0A
=0A
4.     =0AExtending/creating or reuse/managing security protocols for = DC connections, including encryption, key distribution, key management
=0A
=0A
=0A
5.     =0AExtending/creating or reuse L2VPN based technologies = into DC=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
Some of you prefer to focu= s on one of the options, while others like to include multiple options.
=0A
=0A
=0A
 
=0A=
=0A
=0A
Here is my observation and thought.
=0A
=0A
=0A
 
=0A=
=0A
=0A
1 =E2=80=93 It seems a common denomina= tor. Did not hear no on this.  It is exactly the problem Derick wantin= g to solve, it is Ning=E2=80=99s starting point, and it is included in the = requirements drafts.
=0A
=0A
=0A
2= =E2=80=93 It does not need to create or extend protocols, should go to Ope= ration and Management Area for any ops issues and best practice. =0A
=0A
=0A
3 - The scope looks big to me, t= he list is potentially very long.
=0A
=0A
=0A
4 - If new encryption algorithm, better key distribution mechan= ism are needed,  the work should go to Security Area; if nothing new, = ops issues go to Operation and Management Area.
=0A
=0A=0A
5 - L2VPN for DC work should go to L2VPN WG, it i= s defined in L2VPN charter.
=0A
=0A
=0A
 
=0A
=0A
=0A
Thanks,
=0A
=0A
=0A
Luyuan
=0A=
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A=0A<= /div>

--1882999342-394671999-1320718341=:28927-- From ccie15672@yahoo.com Mon Nov 7 18:25: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 6BEB121F8753 for ; Mon, 7 Nov 2011 18:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.341 X-Spam-Level: X-Spam-Status: No, score=0.341 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_20=-0.74, 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 fF9ByayNHp0V for ; Mon, 7 Nov 2011 18:25:25 -0800 (PST) Received: from nm40-vm4.bullet.mail.bf1.yahoo.com (nm40-vm4.bullet.mail.bf1.yahoo.com [72.30.239.212]) by ietfa.amsl.com (Postfix) with SMTP id 64F0D21F86FF for ; Mon, 7 Nov 2011 18:25:21 -0800 (PST) Received: from [98.139.212.148] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 08 Nov 2011 02:25:14 -0000 Received: from [98.139.212.231] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 08 Nov 2011 02:25:14 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 08 Nov 2011 02:25:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 878685.86433.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 59461 invoked by uid 60001); 8 Nov 2011 02:25:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1320719114; bh=pSS0mL1F+3y8UMG6MQJYzstvofOGVo6jsL3MzPrsYX4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=qR4tBhGtokenCI9t9iiIcwggViQLqrOZqi6W4dluScJ0UfCP0bPEsu6O2YBnYyGNLxTH9lB5VIGV6TJtk3e8V4bWrDRaZhK8teK+1w9wdnWVT4LnNCjMHwqgmzQEWzVTh/wb/wscMqduWqQo3z3ULLzC4FdryxJygGcDN4LbzMg= 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=1wmWy1IGQ+JS4pi3gHBo5u2ZqIXIpgx+lxnVIvCP1l8rNXuGKCAAerT9+oXFbLYS3PugDa878VJCn6+ytfeI76jcPHZtLvg0VyOwCrkCuRFNTEX494agtWIEGINgYIHOFdxO1RaXdvRjbzXSGnaDhGiRwUg72/EPOGR9xie2sT4=; X-YMail-OSG: pyoUM0oVM1mHHuytR7azy9guviLg4HKTA5cET3vgTpcpZW7 jzz3KZBYmqIXAqdKLQsb6wFPn2vWoapCVthRRod6X4QinR3KGnVFXaACzGbh 9mNFaGdHkw0KZS2si8cb1Kp62gClyQ1TyjikcVypF6iAGv48q1uZE8YAXCH6 oLLNqvxuATlRTFuxCeZbp8BTRMpqvfPnzwN9yz7Wocbm4B4xq6_HDUL7gVzT oJj6KTHyPYBwcOQi418YktoaQbUJq_ekiQkFTwwEUlRNFV9To1416DbSh4oT Qj8d_i4z0C0jLYc2d6u3izwFoomqKgPdTPVN0jJdZYtYoXHPKFLGM5ml.qGB 4zPQyPzgl72f3TcJbx9s2XxwRJiuT2aF6lDUb6H0zng3B1W_ZpunBDt0P89p pQ2_g0M05rlP8WaACmhFhxZLQOsexRE5cZ1aKCzl7xfi1LVT3XyOKMDml81N W1tQI3VlgorD6NfmmBgy5jQyoL0oGLi5VYnD91GqHDYIC8ef3O1QI4GpSib4 - Received: from [76.194.43.66] by web161805.mail.bf1.yahoo.com via HTTP; Mon, 07 Nov 2011 18:25:14 PST X-Mailer: YahooMailWebService/0.8.114.317681 References: <238542D917511A45B6B8AA806E875E25073CAAF1@XMB-RCD-201.cisco.com> <4EB871F7.5000605@raszuk.net> Message-ID: <1320719114.59379.YahooMailNeo@web161805.mail.bf1.yahoo.com> Date: Mon, 7 Nov 2011 18:25:14 -0800 (PST) From: Derick Winkworth Subject: Re: VPN4DC Scope To: "l3vpn@ietf.org" In-Reply-To: <4EB871F7.5000605@raszuk.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-337026386-1553810809-1320719114=:59379" 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, 08 Nov 2011 02:25:26 -0000 ---337026386-1553810809-1320719114=:59379 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Rob:=0A=0AvCider does not provide for the secure interconnection of sites. = =A0It is software that is installed on the VMs themselves which allows them= to talk to each other as if they were on the same VLAN on a switch regardl= ess of where the VMs exists. =A0Typically these are public-cloud provisione= d VMs that are exposed to the internet.=0A=0AIn the context of VPN4DC, the = customer could very well be running vCider on the VMs in the Provider's DC = but neither the provider nor the customer should require software like this= for attachment of the VM to the customer's L3VPN (which this particular so= ftware would not do, BTW). =A0The goal, again, is not secure host-to-host c= onnectivity (we really shouldn't say that). =A0I don't care what the VM is = talking to per se. =A0The VMs' vNIC should be bound by path isolation to th= e VRF on the provider's PE in the provider's Data Center. =A0The customer o= nly needs to put an IP on the VM as far as the SP is concerned. =A0Whatever= the customer does on top of that (IPSec or vCider) is up to the customer.= =0A=0A=0ADerick=0A=0A=0A=0A=0A=0A________________________________=0AFrom: R= obert Raszuk =0ATo: Luyuan Fang (lufang) =0ACc: l3vpn@ietf.org=0ASent: Monday, November 7, 2011 6:04 PM=0ASubject= : Re: VPN4DC Scope=0A=0AHi Luyuan,=0A=0AAs we are getting down to the scope= debate I think it would be quite =0Aproductive to discuss one solution app= arently already available for =0Aarbitrary secured interconnection of host = or sites.=0A=0Ahttp://vcider.com/=0A=0AIn particular I think it would be qu= ite interesting to know what is =0Amissing from the above solution or this = class of solutions in general =0Afor the problem space we are discussing he= re.=0A=0AIt seems to me that this class of solutions is sufficiently flexib= le to =0Aaddress number of VPN4DC and beyond needs without any prerequisite= s reg =0Atopology or connectivity requirements.=0A=0AMany thx,=0AR.=0A=0A> = Dear colleagues,=0A>=0A> Thank you all for the constructive discussion/sugg= estions over the last=0A> few weeks on VPN4DC.=0A>=0A>=0A>=0A> I think we o= bserved good interests/enthusiasm on solving the problems in=0A> this space= .=0A>=0A>=0A>=0A> We need to narrow down the scope as the next step.=0A>=0A= > I summarized the proposals sent on the list as the following:=0A>=0A>=0A>= =0A> 1.=A0 =A0 =A0 Leverage BGP/MPLS VPN technologies, extending it with l3= vpn=0A> signaling protocols into DC VM virtual networks.=0A>=0A> 2.=A0 =A0 = =A0 Using BGP/MPLS VPN exactly 'as it is' into DC VM virtual=0A> networks= =0A>=0A> 3.=A0 =A0 =A0 Extending/creating any IP VPN technologies into DC= =0A>=0A> 4.=A0 =A0 =A0 Extending/creating or reuse/managing security protoc= ols for DC=0A> connections, including encryption, key distribution, key man= agement=0A>=0A> 5.=A0 =A0 =A0 Extending/creating or reuse L2VPN based techn= ologies into DC=0A>=0A>=0A>=0A> Some of you prefer to focus on one of the o= ptions, while others like to=0A> include multiple options.=0A>=0A>=0A>=0A> = Here is my observation and thought.=0A>=0A>=0A>=0A> 1 - It seems a common d= enominator. Did not hear no on this.=A0 It is=0A> exactly the problem Deric= k wanting to solve, it is Ning's starting=0A> point, and it is included in = the requirements drafts.=0A>=0A> 2 - It does not need to create or extend p= rotocols, should go to=0A> Operation and Management Area for any ops issues= and best practice.=0A>=0A> 3 - The scope looks big to me, the list is pote= ntially very long.=0A>=0A> 4 - If new encryption algorithm, better key dist= ribution mechanism are=0A> needed,=A0 the work should go to Security Area; = if nothing new, ops issues=0A> go to Operation and Management Area.=0A>=0A>= 5 - L2VPN for DC work should go to L2VPN WG, it is defined in L2VPN=0A> ch= arter.=0A>=0A>=0A>=0A> Thanks,=0A>=0A> Luyuan=0A>=0A> ---337026386-1553810809-1320719114=:59379 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Rob:

vCider does not provide for the secure i= nterconnection of sites.  It is software that is installed on the VMs = themselves which allows them to talk to each other as if they were on the s= ame VLAN on a switch regardless of where the VMs exists.  Typically th= ese are public-cloud provisioned VMs that are exposed to the internet.

In the context of VPN4DC, the cust= omer could very well be running vCider on the VMs in the Provider's DC but = neither the provider nor the customer should require software like this for= attachment of the VM to the customer's L3VPN (which this particular softwa= re would not do, BTW).  The goal, again, is not secure host-to-host co= nnectivity (we really shouldn't say that).  I don't care what the VM is talking to per se.  The VMs' vNIC should be bound by path isola= tion to the VRF on the provider's PE in the provider's Data Center.  T= he customer only needs to put an IP on the VM as far as the SP is concerned= .  Whatever the customer does on top of that (IPSec or vCider) is up t= o the customer.


Derick



From: Robert Raszuk <robert@raszuk.net>
To: Luyuan Fang (lufang) <lufang@c= isco.com>
Cc: l3vpn@= ietf.org
Sent: Monday, = November 7, 2011 6:04 PM
Subject: = Re: VPN4DC Scope

=0AHi Luyuan,

As we are getting down = to the scope debate I think it would be quite
productive to discuss one= solution apparently already available for
arbitrary secured interconne= ction of host or sites.

http://vcider.com/

In particular I th= ink it would be quite interesting to know what is
missing from the abov= e solution or this class of solutions in general
for the problem space = we are discussing here.

It seems to me that this class of solutions = is sufficiently flexible to
address number of VPN4DC and beyond needs w= ithout any prerequisites reg
topology or connectivity requirements.
=
Many thx,
R.

> Dear colleagues,
>
> Thank you = all for the constructive discussion/suggestions over the last
> few w= eeks on VPN4DC.
>
>
>
> I think we observed good in= terests/enthusiasm on solving the problems in
> this space.
>>
>
> We need to narrow down the scope as the next step.
>
> I summariz= ed the proposals sent on the list as the following:
>
>
>=
> 1.      Leverage BGP/MPLS VPN technologies, extendi= ng it with l3vpn
> signaling protocols into DC VM virtual networks.>
> 2.      Using BGP/MPLS VPN exactly 'as it is'= into DC VM virtual
> networks
>
> 3.     = Extending/creating any IP VPN technologies into DC
>
> 4. = ;     Extending/creating or reuse/managing security protocols for= DC
> connections, including encryption, key distribution, key manage= ment
>
> 5.      Extending/creating or reuse L2V= PN based technologies into DC
>
>
>
> Some of you p= refer to focus on one of the options, while others like to
> include = multiple options.
>
>
>
> Here is my observation and thought.
>
>
>
> 1 - It seems a co= mmon denominator. Did not hear no on this.  It is
> exactly the = problem Derick wanting to solve, it is Ning's starting
> point, and i= t is included in the requirements drafts.
>
> 2 - It does not n= eed to create or extend protocols, should go to
> Operation and Manag= ement Area for any ops issues and best practice.
>
> 3 - The sc= ope looks big to me, the list is potentially very long.
>
> 4 -= If new encryption algorithm, better key distribution mechanism are
>= needed,  the work should go to Security Area; if nothing new, ops iss= ues
> go to Operation and Management Area.
>
> 5 - L2VPN = for DC work should go to L2VPN WG, it is defined in L2VPN
> charter.<= br>>
>
>
> Thanks,
>
> Luyuan
>
&= gt;



---337026386-1553810809-1320719114=:59379-- From robert@raszuk.net Mon Nov 7 18:39:17 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 AD54811E80CA for ; Mon, 7 Nov 2011 18:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, SARE_SUB_ENC_UTF8=0.152] 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 j3BK03W5zV29 for ; Mon, 7 Nov 2011 18:39:16 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 4DBB111E80D1 for ; Mon, 7 Nov 2011 18:39:16 -0800 (PST) Received: (qmail 31144 invoked by uid 399); 8 Nov 2011 02:39:14 -0000 Received: from unknown (HELO ?192.168.13.22?) (202.245.31.253) by mail37.opentransfer.com with SMTP; 8 Nov 2011 02:39:14 -0000 To: ccie15672@yahoo.com,"=?utf-8?B?bDN2cG5AaWV0Zi5vcmc=?=" From: "=?utf-8?B?cm9iZXJ0QHJhc3p1ay5uZXQ=?=" Subject: =?utf-8?B?UmU6IFZQTjREQyBTY29wZQ==?= Date: Tue, 08 Nov 2011 11:39:14 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1_1320719954480" Message-Id: <20111108023916.4DBB111E80D1@ietfa.amsl.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, 08 Nov 2011 02:39:17 -0000 ------=_Part_1_1320719954480 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpKdXN0IHRvIGNsYXJpZnkgb25lIG5pdCBoZXJlLiBJIGFtIG5vdCBzYXlpbmcgdG8gdXNl IHZjaWRlciBhcyBpcyBub3IgSSBhbSBzYXlpbmcgdGhhdCBhdHRhY2hpbmcgYSBncm91cCBvZiBW TSB0byB5b3VyIEwzIFZQTiBpcyBhIGJhZCB0aGluZy4KCkhvd2V2ZXIgd2hhdCBJIGFtIHBvaW50 aW5nIG91dCB0aGF0IHNjb3BlIG9mIHRoZSBWUE40REMgc2hvdWxkIG5vdCBzdG9wIG9uIGp1c3Qg ZXh0ZW5kaW5nIDI1NDcuIFJhdGhlciB0aGVuIHRoYXQgc3RhbmRhcmRpemluZyB2Y2lkZXIgbGlr ZSBhcHByb2FjaCB3aXRoIHN1cHBsZW1lbnRzIGxpa2UgdXBhcmNpZSBvciByb3V0aW5nIHdpbGwg c2VydmUgdG8gbXVjaCBicm9hZGVyIGN1c3RvbWVyIHNwYWNlLgoKU28gd2hpbGUgZXh0ZW5kaW5n IGwzdnBuIHRvIHRoZSBob3N0IGlzIGEgbmVhdCBpZGVhIGFuZCBsZXRzIHB1c2ggaXQgZm9yd2Fy ZCBpbiB0aGUgc2FtZSB0aW1lIGxldCdzIG5vdCBoYWx0IGVxdWFsbHkgc2ltcGxlIHNvbHV0aW9u cyB3aGljaCBjYW4gYWRkcmVzcyB0aGUgcHJvYmxlbSBmb3IgbWFueSBtb3JlIHJlYWwgY2FzZXMu CgpSZ2RzLApSLgoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiRGVyaWNrIFdpbmt3 b3J0aCIgPGNjaWUxNTY3MkB5YWhvby5jb20+ClRvOiAibDN2cG5AaWV0Zi5vcmciIDxsM3ZwbkBp ZXRmLm9yZz4KU3ViamVjdDogVlBONERDIFNjb3BlCkRhdGU6IFR1ZSwgTm92IDgsIDIwMTEgMTE6 MjUgYW0KCgpSb2I6Cgp2Q2lkZXIgZG9lcyBub3QgcHJvdmlkZSBmb3IgdGhlIHNlY3VyZSBpbnRl cmNvbm5lY3Rpb24gb2Ygc2l0ZXMuIMKgSXQgaXMgc29mdHdhcmUgdGhhdCBpcyBpbnN0YWxsZWQg b24gdGhlIFZNcyB0aGVtc2VsdmVzIHdoaWNoIGFsbG93cyB0aGVtIHRvIHRhbGsgdG8gZWFjaCBv dGhlciBhcyBpZiB0aGV5IHdlcmUgb24gdGhlIHNhbWUgVkxBTiBvbiBhIHN3aXRjaCByZWdhcmRs ZXNzIG9mIHdoZXJlIHRoZSBWTXMgZXhpc3RzLiDCoFR5cGljYWxseSB0aGVzZSBhcmUgcHVibGlj LWNsb3VkIHByb3Zpc2lvbmVkIFZNcyB0aGF0IGFyZSBleHBvc2VkIHRvIHRoZSBpbnRlcm5ldC4K CkluIHRoZSBjb250ZXh0IG9mIFZQTjREQywgdGhlIGN1c3RvbWVyIGNvdWxkIHZlcnkgd2VsbCBi ZSBydW5uaW5nIHZDaWRlciBvbiB0aGUgVk1zIGluIHRoZSBQcm92aWRlcidzIERDIGJ1dCBuZWl0 aGVyIHRoZSBwcm92aWRlciBub3IgdGhlIGN1c3RvbWVyIHNob3VsZCByZXF1aXJlIHNvZnR3YXJl IGxpa2UgdGhpcyBmb3IgYXR0YWNobWVudCBvZiB0aGUgVk0gdG8gdGhlIGN1c3RvbWVyJ3MgTDNW UE4gKHdoaWNoIHRoaXMgcGFydGljdWxhciBzb2Z0d2FyZSB3b3VsZCBub3QgZG8sIEJUVykuIMKg VGhlIGdvYWwsIGFnYWluLCBpcyBub3Qgc2VjdXJlIGhvc3QtdG8taG9zdCBjb25uZWN0aXZpdHkg KHdlIHJlYWxseSBzaG91bGRuJ3Qgc2F5IHRoYXQpLiDCoEkgZG9uJ3QgY2FyZSB3aGF0IHRoZSBW TSBpcyB0YWxraW5nIHRvIHBlciBzZS4gwqBUaGUgVk1zJyB2TklDIHNob3VsZCBiZSBib3VuZCBi eSBwYXRoIGlzb2xhdGlvbiB0byB0aGUgVlJGIG9uIHRoZSBwcm92aWRlcidzIFBFIGluIHRoZSBw cm92aWRlcidzIERhdGEgQ2VudGVyLiDCoFRoZSBjdXN0b21lciBvbmx5IG5lZWRzIHRvIHB1dCBh biBJUCBvbiB0aGUgVk0gYXMgZmFyIGFzIHRoZSBTUCBpcyBjb25jZXJuZWQuIMKgV2hhdGV2ZXIg dGhlIGN1c3RvbWVyIGRvZXMgb24gdG9wIG9mIHRoYXQgKElQU2VjIG9yIHZDaWRlcikgaXMgdXAg dG8gdGhlIGN1c3RvbWVyLgoKCkRlcmljawoKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCkZyb206IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PgpUbzogTHV5dWFu IEZhbmcgKGx1ZmFuZykgPGx1ZmFuZ0BjaXNjby5jb20+CkNjOiBsM3ZwbkBpZXRmLm9yZwpTZW50 OiBNb25kYXksIE5vdmVtYmVyIDcsIDIwMTEgNjowNCBQTQpTdWJqZWN0OiBSZTogVlBONERDIFNj b3BlCgpIaSBMdXl1YW4sCgpBcyB3ZSBhcmUgZ2V0dGluZyBkb3duIHRvIHRoZSBzY29wZSBkZWJh dGUgSSB0aGluayBpdCB3b3VsZCBiZSBxdWl0ZSAKcHJvZHVjdGl2ZSB0byBkaXNjdXNzIG9uZSBz b2x1dGlvbiBhcHBhcmVudGx5IGFscmVhZHkgYXZhaWxhYmxlIGZvciAKYXJiaXRyYXJ5IHNlY3Vy ZWQgaW50ZXJjb25uZWN0aW9uIG9mIGhvc3Qgb3Igc2l0ZXMuCgpodHRwOi8vdmNpZGVyLmNvbS8K CkluIHBhcnRpY3VsYXIgSSB0aGluayBpdCB3b3VsZCBiZSBxdWl0ZSBpbnRlcmVzdGluZyB0byBr bm93IHdoYXQgaXMgCm1pc3NpbmcgZnJvbSB0aGUgYWJvdmUgc29sdXRpb24gb3IgdGhpcyBjbGFz cyBvZiBzb2x1dGlvbnMgaW4gZ2VuZXJhbCAKZm9yIHRoZSBwcm9ibGVtIHNwYWNlIHdlIGFyZSBk aXNjdXNzaW5nIGhlcmUuCgpJdCBzZWVtcyB0byBtZSB0aGF0IHRoaXMgY2xhc3Mgb2Ygc29sdXRp b25zIGlzIHN1ZmZpY2llbnRseSBmbGV4aWJsZSB0byAKYWRkcmVzcyBudW1iZXIgb2YgVlBONERD IGFuZCBiZXlvbmQgbmVlZHMgd2l0aG91dCBhbnkgcHJlcmVxdWlzaXRlcyByZWcgCnRvcG9sb2d5 IG9yIGNvbm5lY3Rpdml0eSByZXF1aXJlbWVudHMuCgpNYW55IHRoeCwKUi4KCj4gRGVhciBjb2xs ZWFndWVzLAo+Cj4gVGhhbmsgeW91IGFsbCBmb3IgdGhlIGNvbnN0cnVjdGl2ZSBkaXNjdXNzaW9u L3N1Z2dlc3Rpb25zIG92ZXIgdGhlIGxhc3QKPiBmZXcgd2Vla3Mgb24gVlBONERDLgo+Cj4KPgo+ IEkgdGhpbmsgd2Ugb2JzZXJ2ZWQgZ29vZCBpbnRlcmVzdHMvZW50aHVzaWFzbSBvbiBzb2x2aW5n IHRoZSBwcm9ibGVtcyBpbgo+IHRoaXMgc3BhY2UuLgo+Cj4KPgo+IFdlIG5lZWQgdG8gbmFycm93 IGRvd24gdGhlIHNjb3BlIGFzIHRoZSBuZXh0IHN0ZXAuCj4KPiBJIHN1bW1hcml6ZWQgdGhlIHBy b3Bvc2FscyBzZW50IG9uIHRoZSBsaXN0IGFzIHRoZSBmb2xsb3dpbmc6Cj4KPgo+Cj4gMS7CoCDC oCDCoCBMZXZlcmFnZSBCR1AvTVBMUyBWUE4gdGVjaG5vbG9naWVzLCBleHRlbmRpbmcgaXQgd2l0 aCBsM3Zwbgo+IHNpZ25hbGluZyBwcm90b2NvbHMgaW50byBEQyBWTSB2aXJ0dWFsIG5ldHdvcmtz Lgo+Cj4gMi7CoCDCoCDCoCBVc2luZyBCR1AvTVBMUyBWUE4gZXhhY3RseSAnYXMgaXQgaXMnIGlu dG8gREMgVk0gdmlydHVhbAo+IG5ldHdvcmtzCj4KPiAzLsKgIMKgIMKgIEV4dGVuZGluZy9jcmVh dGluZyBhbnkgSVAgVlBOIHRlY2hub2xvZ2llcyBpbnRvIERDCj4KPiA0LsKgIMKgIMKgIEV4dGVu ZGluZy9jcmVhdGluZyBvciByZXVzZS9tYW5hZ2luZyBzZWN1cml0eSBwcm90b2NvbHMgZm9yIERD Cj4gY29ubmVjdGlvbnMsIGluY2x1ZGluZyBlbmNyeXB0aW9uLCBrZXkgZGlzdHJpYnV0aW9uLCBr ZXkgbWFuYWdlbWVudAo+Cj4gNS7CoCDCoCDCoCBFeHRlbmRpbmcvY3JlYXRpbmcgb3IgcmV1c2Ug TDJWUE4gYmFzZWQgdGVjaG5vbG9naWVzIGludG8gREMKPgo+Cj4KPiBTb21lIG9mIHlvdSBwcmVm ZXIgdG8gZm9jdXMgb24gb25lIG9mIHRoZSBvcHRpb25zLCB3aGlsZSBvdGhlcnMgbGlrZSB0bwo+ IGluY2x1ZGUgbXVsdGlwbGUgb3B0aW9ucy4KPgo+Cj4KPiBIZXJlIGlzIG15IG9ic2VydmF0aW9u IGFuZCB0aG91Z2h0Lgo+Cj4KPgo+IDEgLSBJdCBzZWVtcyBhIGNvbW1vbiBkZW5vbWluYXRvci4g RGlkIG5vdCBoZWFyIG5vIG9uIHRoaXMuwqAgSXQgaXMKPiBleGFjdGx5IHRoZSBwcm9ibGVtIERl cmljayB3YW50aW5nIHRvIHNvbHZlLCBpdCBpcyBOaW5nJ3Mgc3RhcnRpbmcKPiBwb2ludCwgYW5k IGl0IGlzIGluY2x1ZGVkIGluIHRoZSByZXF1aXJlbWVudHMgZHJhZnRzLgo+Cj4gMiAtIEl0IGRv ZXMgbm90IG5lZWQgdG8gY3JlYXRlIG9yIGV4dGVuZCBwcm90b2NvbHMsIHNob3VsZCBnbyB0bwo+ IE9wZXJhdGlvbiBhbmQgTWFuYWdlbWVudCBBcmVhIGZvciBhbnkgb3BzIGlzc3VlcyBhbmQgYmVz dCBwcmFjdGljZS4KPgo+IDMgLSBUaGUgc2NvcGUgbG9va3MgYmlnIHRvIG1lLCB0aGUgbGlzdCBp cyBwb3RlbnRpYWxseSB2ZXJ5IGxvbmcuCj4KPiA0IC0gSWYgbmV3IGVuY3J5cHRpb24gYWxnb3Jp dGhtLCBiZXR0ZXIga2V5IGRpc3RyaWJ1dGlvbiBtZWNoYW5pc20gYXJlCj4gbmVlZGVkLMKgIHRo ZSB3b3JrIHNob3VsZCBnbyB0byBTZWN1cml0eSBBcmVhOyBpZiBub3RoaW5nIG5ldywgb3BzIGlz c3Vlcwo+IGdvIHRvIE9wZXJhdGlvbiBhbmQgTWFuYWdlbWVudCBBcmVhLgo+Cj4gNSAtIEwyVlBO IGZvciBEQyB3b3JrIHNob3VsZCBnbyB0byBMMlZQTiBXRywgaXQgaXMgZGVmaW5lZCBpbiBMMlZQ Tgo+IGNoYXJ0ZXIuCj4KPgo+Cj4gVGhhbmtzLAo+Cj4gTHV5dWFuCj4KPgo= ------=_Part_1_1320719954480 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksPGJyPjxicj5KdXN0IHRvIGNsYXJpZnkgb25lIG5pdCBoZXJlLiBJIGFtIG5vdCBzYXlpbmcg dG8gdXNlIHZjaWRlciBhcyBpcyBub3IgSSBhbSBzYXlpbmcgdGhhdCBhdHRhY2hpbmcgYSBncm91 cCBvZiBWTSB0byB5b3VyIEwzIFZQTiBpcyBhIGJhZCB0aGluZy48YnI+PGJyPkhvd2V2ZXIgd2hh dCBJIGFtIHBvaW50aW5nIG91dCB0aGF0IHNjb3BlIG9mIHRoZSBWUE40REMgc2hvdWxkIG5vdCBz dG9wIG9uIGp1c3QgZXh0ZW5kaW5nIDI1NDcuIFJhdGhlciB0aGVuIHRoYXQgc3RhbmRhcmRpemlu ZyB2Y2lkZXIgbGlrZSBhcHByb2FjaCB3aXRoIHN1cHBsZW1lbnRzIGxpa2UgdXBhcmNpZSBvciBy b3V0aW5nIHdpbGwgc2VydmUgdG8gbXVjaCBicm9hZGVyIGN1c3RvbWVyIHNwYWNlLjxicj48YnI+ U28gd2hpbGUgZXh0ZW5kaW5nIGwzdnBuIHRvIHRoZSBob3N0IGlzIGEgbmVhdCBpZGVhIGFuZCBs ZXRzIHB1c2ggaXQgZm9yd2FyZCBpbiB0aGUgc2FtZSB0aW1lIGxldCYjMzk7cyBub3QgaGFsdCBl cXVhbGx5IHNpbXBsZSBzb2x1dGlvbnMgd2hpY2ggY2FuIGFkZHJlc3MgdGhlIHByb2JsZW0gZm9y IG1hbnkgbW9yZSByZWFsIGNhc2VzLjxicj48YnI+Umdkcyw8YnI+Ui48YnI+PGJyPi0tLS0tIFJl cGx5IG1lc3NhZ2UgLS0tLS08YnI+RnJvbTogJnF1b3Q7RGVyaWNrIFdpbmt3b3J0aCZxdW90OyAm bHQ7Y2NpZTE1NjcyQHlhaG9vLmNvbSZndDs8YnI+VG86ICZxdW90O2wzdnBuQGlldGYub3JnJnF1 b3Q7ICZsdDtsM3ZwbkBpZXRmLm9yZyZndDs8YnI+U3ViamVjdDogVlBONERDIFNjb3BlPGJyPkRh dGU6IFR1ZSwgTm92IDgsIDIwMTEgMTE6MjUgYW08YnI+PGJyPjxicj5Sb2I6PGJyPjxicj52Q2lk ZXIgZG9lcyBub3QgcHJvdmlkZSBmb3IgdGhlIHNlY3VyZSBpbnRlcmNvbm5lY3Rpb24gb2Ygc2l0 ZXMuIMKgSXQgaXMgc29mdHdhcmUgdGhhdCBpcyBpbnN0YWxsZWQgb24gdGhlIFZNcyB0aGVtc2Vs dmVzIHdoaWNoIGFsbG93cyB0aGVtIHRvIHRhbGsgdG8gZWFjaCBvdGhlciBhcyBpZiB0aGV5IHdl cmUgb24gdGhlIHNhbWUgVkxBTiBvbiBhIHN3aXRjaCByZWdhcmRsZXNzIG9mIHdoZXJlIHRoZSBW TXMgZXhpc3RzLiDCoFR5cGljYWxseSB0aGVzZSBhcmUgcHVibGljLWNsb3VkIHByb3Zpc2lvbmVk IFZNcyB0aGF0IGFyZSBleHBvc2VkIHRvIHRoZSBpbnRlcm5ldC48YnI+PGJyPkluIHRoZSBjb250 ZXh0IG9mIFZQTjREQywgdGhlIGN1c3RvbWVyIGNvdWxkIHZlcnkgd2VsbCBiZSBydW5uaW5nIHZD aWRlciBvbiB0aGUgVk1zIGluIHRoZSBQcm92aWRlciYjMzk7cyBEQyBidXQgbmVpdGhlciB0aGUg cHJvdmlkZXIgbm9yIHRoZSBjdXN0b21lciBzaG91bGQgcmVxdWlyZSBzb2Z0d2FyZSBsaWtlIHRo aXMgZm9yIGF0dGFjaG1lbnQgb2YgdGhlIFZNIHRvIHRoZSBjdXN0b21lciYjMzk7cyBMM1ZQTiAo d2hpY2ggdGhpcyBwYXJ0aWN1bGFyIHNvZnR3YXJlIHdvdWxkIG5vdCBkbywgQlRXKS4gwqBUaGUg Z29hbCwgYWdhaW4sIGlzIG5vdCBzZWN1cmUgaG9zdC10by1ob3N0IGNvbm5lY3Rpdml0eSAod2Ug cmVhbGx5IHNob3VsZG4mIzM5O3Qgc2F5IHRoYXQpLiDCoEkgZG9uJiMzOTt0IGNhcmUgd2hhdCB0 aGUgVk0gaXMgdGFsa2luZyB0byBwZXIgc2UuIMKgVGhlIFZNcyYjMzk7IHZOSUMgc2hvdWxkIGJl IGJvdW5kIGJ5IHBhdGggaXNvbGF0aW9uIHRvIHRoZSBWUkYgb24gdGhlIHByb3ZpZGVyJiMzOTtz IFBFIGluIHRoZSBwcm92aWRlciYjMzk7cyBEYXRhIENlbnRlci4gwqBUaGUgY3VzdG9tZXIgb25s eSBuZWVkcyB0byBwdXQgYW4gSVAgb24gdGhlIFZNIGFzIGZhciBhcyB0aGUgU1AgaXMgY29uY2Vy bmVkLiDCoFdoYXRldmVyIHRoZSBjdXN0b21lciBkb2VzIG9uIHRvcCBvZiB0aGF0IChJUFNlYyBv ciB2Q2lkZXIpIGlzIHVwIHRvIHRoZSBjdXN0b21lci48YnI+PGJyPjxicj5EZXJpY2s8YnI+PGJy Pjxicj48YnI+PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5Gcm9t OiBSb2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFzenVrLm5ldCZndDs8YnI+VG86IEx1eXVhbiBG YW5nIChsdWZhbmcpICZsdDtsdWZhbmdAY2lzY28uY29tJmd0Ozxicj5DYzogbDN2cG5AaWV0Zi5v cmc8YnI+U2VudDogTW9uZGF5LCBOb3ZlbWJlciA3LCAyMDExIDY6MDQgUE08YnI+U3ViamVjdDog UmU6IFZQTjREQyBTY29wZTxicj48YnI+SGkgTHV5dWFuLDxicj48YnI+QXMgd2UgYXJlIGdldHRp bmcgZG93biB0byB0aGUgc2NvcGUgZGViYXRlIEkgdGhpbmsgaXQgd291bGQgYmUgcXVpdGUgPGJy PnByb2R1Y3RpdmUgdG8gZGlzY3VzcyBvbmUgc29sdXRpb24gYXBwYXJlbnRseSBhbHJlYWR5IGF2 YWlsYWJsZSBmb3IgPGJyPmFyYml0cmFyeSBzZWN1cmVkIGludGVyY29ubmVjdGlvbiBvZiBob3N0 IG9yIHNpdGVzLjxicj48YnI+aHR0cDovL3ZjaWRlci5jb20vPGJyPjxicj5JbiBwYXJ0aWN1bGFy IEkgdGhpbmsgaXQgd291bGQgYmUgcXVpdGUgaW50ZXJlc3RpbmcgdG8ga25vdyB3aGF0IGlzIDxi cj5taXNzaW5nIGZyb20gdGhlIGFib3ZlIHNvbHV0aW9uIG9yIHRoaXMgY2xhc3Mgb2Ygc29sdXRp b25zIGluIGdlbmVyYWwgPGJyPmZvciB0aGUgcHJvYmxlbSBzcGFjZSB3ZSBhcmUgZGlzY3Vzc2lu ZyBoZXJlLjxicj48YnI+SXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIGNsYXNzIG9mIHNvbHV0aW9u cyBpcyBzdWZmaWNpZW50bHkgZmxleGlibGUgdG8gPGJyPmFkZHJlc3MgbnVtYmVyIG9mIFZQTjRE QyBhbmQgYmV5b25kIG5lZWRzIHdpdGhvdXQgYW55IHByZXJlcXVpc2l0ZXMgcmVnIDxicj50b3Bv bG9neSBvciBjb25uZWN0aXZpdHkgcmVxdWlyZW1lbnRzLjxicj48YnI+TWFueSB0aHgsPGJyPlIu PGJyPjxicj4mZ3Q7IERlYXIgY29sbGVhZ3Vlcyw8YnI+Jmd0Ozxicj4mZ3Q7IFRoYW5rIHlvdSBh bGwgZm9yIHRoZSBjb25zdHJ1Y3RpdmUgZGlzY3Vzc2lvbi9zdWdnZXN0aW9ucyBvdmVyIHRoZSBs YXN0PGJyPiZndDsgZmV3IHdlZWtzIG9uIFZQTjREQy48YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8 YnI+Jmd0OyBJIHRoaW5rIHdlIG9ic2VydmVkIGdvb2QgaW50ZXJlc3RzL2VudGh1c2lhc20gb24g c29sdmluZyB0aGUgcHJvYmxlbXMgaW48YnI+Jmd0OyB0aGlzIHNwYWNlLi48YnI+Jmd0Ozxicj4m Z3Q7PGJyPiZndDs8YnI+Jmd0OyBXZSBuZWVkIHRvIG5hcnJvdyBkb3duIHRoZSBzY29wZSBhcyB0 aGUgbmV4dCBzdGVwLjxicj4mZ3Q7PGJyPiZndDsgSSBzdW1tYXJpemVkIHRoZSBwcm9wb3NhbHMg c2VudCBvbiB0aGUgbGlzdCBhcyB0aGUgZm9sbG93aW5nOjxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0 Ozxicj4mZ3Q7IDEuwqAgwqAgwqAgTGV2ZXJhZ2UgQkdQL01QTFMgVlBOIHRlY2hub2xvZ2llcywg ZXh0ZW5kaW5nIGl0IHdpdGggbDN2cG48YnI+Jmd0OyBzaWduYWxpbmcgcHJvdG9jb2xzIGludG8g REMgVk0gdmlydHVhbCBuZXR3b3Jrcy48YnI+Jmd0Ozxicj4mZ3Q7IDIuwqAgwqAgwqAgVXNpbmcg QkdQL01QTFMgVlBOIGV4YWN0bHkgJiMzOTthcyBpdCBpcyYjMzk7IGludG8gREMgVk0gdmlydHVh bDxicj4mZ3Q7IG5ldHdvcmtzPGJyPiZndDs8YnI+Jmd0OyAzLsKgIMKgIMKgIEV4dGVuZGluZy9j cmVhdGluZyBhbnkgSVAgVlBOIHRlY2hub2xvZ2llcyBpbnRvIERDPGJyPiZndDs8YnI+Jmd0OyA0 LsKgIMKgIMKgIEV4dGVuZGluZy9jcmVhdGluZyBvciByZXVzZS9tYW5hZ2luZyBzZWN1cml0eSBw cm90b2NvbHMgZm9yIERDPGJyPiZndDsgY29ubmVjdGlvbnMsIGluY2x1ZGluZyBlbmNyeXB0aW9u LCBrZXkgZGlzdHJpYnV0aW9uLCBrZXkgbWFuYWdlbWVudDxicj4mZ3Q7PGJyPiZndDsgNS7CoCDC oCDCoCBFeHRlbmRpbmcvY3JlYXRpbmcgb3IgcmV1c2UgTDJWUE4gYmFzZWQgdGVjaG5vbG9naWVz IGludG8gREM8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBTb21lIG9mIHlvdSBwcmVm ZXIgdG8gZm9jdXMgb24gb25lIG9mIHRoZSBvcHRpb25zLCB3aGlsZSBvdGhlcnMgbGlrZSB0bzxi cj4mZ3Q7IGluY2x1ZGUgbXVsdGlwbGUgb3B0aW9ucy48YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8 YnI+Jmd0OyBIZXJlIGlzIG15IG9ic2VydmF0aW9uIGFuZCB0aG91Z2h0Ljxicj4mZ3Q7PGJyPiZn dDs8YnI+Jmd0Ozxicj4mZ3Q7IDEgLSBJdCBzZWVtcyBhIGNvbW1vbiBkZW5vbWluYXRvci4gRGlk IG5vdCBoZWFyIG5vIG9uIHRoaXMuwqAgSXQgaXM8YnI+Jmd0OyBleGFjdGx5IHRoZSBwcm9ibGVt IERlcmljayB3YW50aW5nIHRvIHNvbHZlLCBpdCBpcyBOaW5nJiMzOTtzIHN0YXJ0aW5nPGJyPiZn dDsgcG9pbnQsIGFuZCBpdCBpcyBpbmNsdWRlZCBpbiB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0cy48 YnI+Jmd0Ozxicj4mZ3Q7IDIgLSBJdCBkb2VzIG5vdCBuZWVkIHRvIGNyZWF0ZSBvciBleHRlbmQg cHJvdG9jb2xzLCBzaG91bGQgZ28gdG88YnI+Jmd0OyBPcGVyYXRpb24gYW5kIE1hbmFnZW1lbnQg QXJlYSBmb3IgYW55IG9wcyBpc3N1ZXMgYW5kIGJlc3QgcHJhY3RpY2UuPGJyPiZndDs8YnI+Jmd0 OyAzIC0gVGhlIHNjb3BlIGxvb2tzIGJpZyB0byBtZSwgdGhlIGxpc3QgaXMgcG90ZW50aWFsbHkg dmVyeSBsb25nLjxicj4mZ3Q7PGJyPiZndDsgNCAtIElmIG5ldyBlbmNyeXB0aW9uIGFsZ29yaXRo bSwgYmV0dGVyIGtleSBkaXN0cmlidXRpb24gbWVjaGFuaXNtIGFyZTxicj4mZ3Q7IG5lZWRlZCzC oCB0aGUgd29yayBzaG91bGQgZ28gdG8gU2VjdXJpdHkgQXJlYTsgaWYgbm90aGluZyBuZXcsIG9w cyBpc3N1ZXM8YnI+Jmd0OyBnbyB0byBPcGVyYXRpb24gYW5kIE1hbmFnZW1lbnQgQXJlYS48YnI+ Jmd0Ozxicj4mZ3Q7IDUgLSBMMlZQTiBmb3IgREMgd29yayBzaG91bGQgZ28gdG8gTDJWUE4gV0cs IGl0IGlzIGRlZmluZWQgaW4gTDJWUE48YnI+Jmd0OyBjaGFydGVyLjxicj4mZ3Q7PGJyPiZndDs8 YnI+Jmd0Ozxicj4mZ3Q7IFRoYW5rcyw8YnI+Jmd0Ozxicj4mZ3Q7IEx1eXVhbjxicj4mZ3Q7PGJy PiZndDs8YnI+ ------=_Part_1_1320719954480-- From robert@raszuk.net Mon Nov 7 18:43: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 1051311E80D3 for ; Mon, 7 Nov 2011 18:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, SARE_SUB_ENC_UTF8=0.152] 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 6J46LhjjopVh for ; Mon, 7 Nov 2011 18:43:03 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 8FC5811E80CA for ; Mon, 7 Nov 2011 18:42:57 -0800 (PST) Received: (qmail 32367 invoked by uid 399); 8 Nov 2011 02:42:56 -0000 Received: from unknown (HELO ?192.168.13.22?) (202.245.31.253) by mail37.opentransfer.com with SMTP; 8 Nov 2011 02:42:56 -0000 To: "=?utf-8?B?cm9iZXJ0QHJhc3p1ay5uZXQ=?=" , ccie15672@yahoo.com, "=?utf-8?B?bDN2cG5AaWV0Zi5vcmc=?=" From: "=?utf-8?B?cm9iZXJ0QHJhc3p1ay5uZXQ=?=" Subject: =?utf-8?B?UmU6IFZQTjREQyBTY29wZQ==?= Date: Tue, 08 Nov 2011 11:42:56 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2_1320720176744" Message-Id: <20111108024257.8FC5811E80CA@ietfa.amsl.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, 08 Nov 2011 02:43:04 -0000 ------=_Part_2_1320720176744 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline cy9saWtlIHVwYXJjaWUvbGlrZSBpcHNlYy8KClNvcnJ5IGFuZHJvaWQncyBmYXVsdCA7KAoKUi4K Ci0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJvbTogInJvYmVydEByYXN6dWsubmV0IiA8cm9i ZXJ0QHJhc3p1ay5uZXQ+ClRvOiA8Y2NpZTE1NjcyQHlhaG9vLmNvbT4sICJsM3ZwbkBpZXRmLm9y ZyIgPGwzdnBuQGlldGYub3JnPgpTdWJqZWN0OiBSZTogVlBONERDIFNjb3BlCkRhdGU6IFR1ZSwg Tm92IDgsIDIwMTEgMTE6MzkgYW0KCgpIaSwKCkp1c3QgdG8gY2xhcmlmeSBvbmUgbml0IGhlcmUu IEkgYW0gbm90IHNheWluZyB0byB1c2UgdmNpZGVyIGFzIGlzIG5vciBJIGFtIHNheWluZyB0aGF0 IGF0dGFjaGluZyBhIGdyb3VwIG9mIFZNIHRvIHlvdXIgTDMgVlBOIGlzIGEgYmFkIHRoaW5nLgoK SG93ZXZlciB3aGF0IEkgYW0gcG9pbnRpbmcgb3V0IHRoYXQgc2NvcGUgb2YgdGhlIFZQTjREQyBz aG91bGQgbm90IHN0b3Agb24ganVzdCBleHRlbmRpbmcgMjU0Ny4gUmF0aGVyIHRoZW4gdGhhdCBz dGFuZGFyZGl6aW5nIHZjaWRlciBsaWtlIGFwcHJvYWNoIHdpdGggc3VwcGxlbWVudHMgbGlrZSB1 cGFyY2llIG9yIHJvdXRpbmcgd2lsbCBzZXJ2ZSB0byBtdWNoIGJyb2FkZXIgY3VzdG9tZXIgc3Bh Y2UuCgpTbyB3aGlsZSBleHRlbmRpbmcgbDN2cG4gdG8gdGhlIGhvc3QgaXMgYSBuZWF0IGlkZWEg YW5kIGxldHMgcHVzaCBpdCBmb3J3YXJkIGluIHRoZSBzYW1lIHRpbWUgbGV0J3Mgbm90IGhhbHQg ZXF1YWxseSBzaW1wbGUgc29sdXRpb25zIHdoaWNoIGNhbiBhZGRyZXNzIHRoZSBwcm9ibGVtIGZv ciBtYW55IG1vcmUgcmVhbCBjYXNlcy4KClJnZHMsClIuLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0t LQpGcm9tOiAiRGVyaWNrIFdpbmt3b3J0aCIgPGNjaWUxNTY3MkB5YWhvby5jb20+ClRvOiAibDN2 cG5AaWV0Zi5vcmciIDxsM3ZwbkBpZXRmLm9yZz4KU3ViamVjdDogVlBONERDIFNjb3BlCkRhdGU6 IFR1ZSwgTm92IDgsIDIwMTEgMTE6MjUgYW0KClJvYjoKCnZDaWRlciBkb2VzIG5vdCBwcm92aWRl IGZvciB0aGUgc2VjdXJlIGludGVyY29ubmVjdGlvbiBvZiBzaXRlcy4gwqBJdCBpcyBzb2Z0d2Fy ZSB0aGF0IGlzIGluc3RhbGxlZCBvbiB0aGUgVk1zIHRoZW1zZWx2ZXMgd2hpY2ggYWxsb3dzIHRo ZW0gdG8gdGFsayB0byBlYWNoIG90aGVyIGFzIGlmIHRoZXkgd2VyZSBvbiB0aGUgc2FtZSBWTEFO IG9uIGEgc3dpdGNoIHJlZ2FyZGxlc3Mgb2Ygd2hlcmUgdGhlIFZNcyBleGlzdHMuIMKgVHlwaWNh bGx5IHRoZXNlIGFyZSBwdWJsaWMtY2xvdWQgcHJvdmlzaW9uZWQgVk1zIHRoYXQgYXJlIGV4cG9z ZWQgdG8gdGhlIGludGVybmV0LgoKSW4gdGhlIGNvbnRleHQgb2YgVlBONERDLCB0aGUgY3VzdG9t ZXIgY291bGQgdmVyeSB3ZWxsIGJlIHJ1bm5pbmcgdkNpZGVyIG9uIHRoZSBWTXMgaW4gdGhlIFBy b3ZpZGVyJ3MgREMgYnV0IG5laXRoZXIgdGhlIHByb3ZpZGVyIG5vciB0aGUgY3VzdG9tZXIgc2hv dWxkIHJlcXVpcmUgc29mdHdhcmUgbGlrZSB0aGlzIGZvciBhdHRhY2htZW50IG9mIHRoZSBWTSB0 byB0aGUgY3VzdG9tZXIncyBMM1ZQTiAod2hpY2ggdGhpcyBwYXJ0aWN1bGFyIHNvZnR3YXJlIHdv dWxkIG5vdCBkbywgQlRXKS4gwqBUaGUgZ29hbCwgYWdhaW4sIGlzIG5vdCBzZWN1cmUgaG9zdC10 by1ob3N0IGNvbm5lY3Rpdml0eSAod2UgcmVhbGx5IHNob3VsZG4ndCBzYXkgdGhhdCkuIMKgSSBk b24ndCBjYXJlIHdoYXQgdGhlIFZNIGlzIHRhbGtpbmcgdG8gcGVyIHNlLiDCoFRoZSBWTXMnIHZO SUMgc2hvdWxkIGJlIGJvdW5kIGJ5IHBhdGggaXNvbGF0aW9uIHRvIHRoZSBWUkYgb24gdGhlIHBy b3ZpZGVyJ3MgUEUgaW4gdGhlIHByb3ZpZGVyJ3MgRGF0YSBDZW50ZXIuIMKgVGhlIGN1c3RvbWVy IG9ubHkgbmVlZHMgdG8gcHV0IGFuIElQIG9uIHRoZSBWTSBhcyBmYXIgYXMgdGhlIFNQIGlzIGNv bmNlcm5lZC4gwqBXaGF0ZXZlciB0aGUgY3VzdG9tZXIgZG9lcyBvbiB0b3Agb2YgdGhhdCAoSVBT ZWMgb3IgdkNpZGVyKSBpcyB1cCB0byB0aGUgY3VzdG9tZXIuCgoKRGVyaWNrCgoKCgoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJh c3p1ay5uZXQ+ClRvOiBMdXl1YW4gRmFuZyAobHVmYW5nKSA8bHVmYW5nQGNpc2NvLmNvbT4KQ2M6 IGwzdnBuQGlldGYub3JnClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgNywgMjAxMSA2OjA0IFBNClN1 YmplY3Q6IFJlOiBWUE40REMgU2NvcGUKCkhpIEx1eXVhbiwKCkFzIHdlIGFyZSBnZXR0aW5nIGRv d24gdG8gdGhlIHNjb3BlIGRlYmF0ZSBJIHRoaW5rIGl0IHdvdWxkIGJlIHF1aXRlIApwcm9kdWN0 aXZlIHRvIGRpc2N1c3Mgb25lIHNvbHV0aW9uIGFwcGFyZW50bHkgYWxyZWFkeSBhdmFpbGFibGUg Zm9yIAphcmJpdHJhcnkgc2VjdXJlZCBpbnRlcmNvbm5lY3Rpb24gb2YgaG9zdCBvciBzaXRlcy4K Cmh0dHA6Ly92Y2lkZXIuY29tLwoKSW4gcGFydGljdWxhciBJIHRoaW5rIGl0IHdvdWxkIGJlIHF1 aXRlIGludGVyZXN0aW5nIHRvIGtub3cgd2hhdCBpcyAKbWlzc2luZyBmcm9tIHRoZSBhYm92ZSBz b2x1dGlvbiBvciB0aGlzIGNsYXNzIG9mIHNvbHV0aW9ucyBpbiBnZW5lcmFsIApmb3IgdGhlIHBy b2JsZW0gc3BhY2Ugd2UgYXJlIGRpc2N1c3NpbmcgaGVyZS4KCkl0IHNlZW1zIHRvIG1lIHRoYXQg dGhpcyBjbGFzcyBvZiBzb2x1dGlvbnMgaXMgc3VmZmljaWVudGx5IGZsZXhpYmxlIHRvIAphZGRy ZXNzIG51bWJlciBvZiBWUE40REMgYW5kIGJleW9uZCBuZWVkcyB3aXRob3V0IGFueSBwcmVyZXF1 aXNpdGVzIHJlZyAKdG9wb2xvZ3kgb3IgY29ubmVjdGl2aXR5IHJlcXVpcmVtZW50cy4KCk1hbnkg dGh4LApSLgoKPiBEZWFyIGNvbGxlYWd1ZXMsCj4KPiBUaGFuayB5b3UgYWxsIGZvciB0aGUgY29u c3RydWN0aXZlIGRpc2N1c3Npb24vc3VnZ2VzdGlvbnMgb3ZlciB0aGUgbGFzdAo+IGZldyB3ZWVr cyBvbiBWUE40REMuCj4KPgo+Cj4gSSB0aGluayB3ZSBvYnNlcnZlZCBnb29kIGludGVyZXN0cy9l bnRodXNpYXNtIG9uIHNvbHZpbmcgdGhlIHByb2JsZW1zIGluCj4gdGhpcyBzcGFjZS4uCj4KPgo+ Cj4gV2UgbmVlZCB0byBuYXJyb3cgZG93biB0aGUgc2NvcGUgYXMgdGhlIG5leHQgc3RlcC4KPgo+ IEkgc3VtbWFyaXplZCB0aGUgcHJvcG9zYWxzIHNlbnQgb24gdGhlIGxpc3QgYXMgdGhlIGZvbGxv d2luZzoKPgo+Cj4KPiAxLsKgIMKgIMKgIExldmVyYWdlIEJHUC9NUExTIFZQTiB0ZWNobm9sb2dp ZXMsIGV4dGVuZGluZyBpdCB3aXRoIGwzdnBuCj4gc2lnbmFsaW5nIHByb3RvY29scyBpbnRvIERD IFZNIHZpcnR1YWwgbmV0d29ya3MuCj4KPiAyLsKgIMKgIMKgIFVzaW5nIEJHUC9NUExTIFZQTiBl eGFjdGx5ICdhcyBpdCBpcycgaW50byBEQyBWTSB2aXJ0dWFsCj4gbmV0d29ya3MKPgo+IDMuwqAg wqAgwqAgRXh0ZW5kaW5nL2NyZWF0aW5nIGFueSBJUCBWUE4gdGVjaG5vbG9naWVzIGludG8gREMK Pgo+IDQuwqAgwqAgwqAgRXh0ZW5kaW5nL2NyZWF0aW5nIG9yIHJldXNlL21hbmFnaW5nIHNlY3Vy aXR5IHByb3RvY29scyBmb3IgREMKPiBjb25uZWN0aW9ucywgaW5jbHVkaW5nIGVuY3J5cHRpb24s IGtleSBkaXN0cmlidXRpb24sIGtleSBtYW5hZ2VtZW50Cj4KPiA1LsKgIMKgIMKgIEV4dGVuZGlu Zy9jcmVhdGluZyBvciByZXVzZSBMMlZQTiBiYXNlZCB0ZWNobm9sb2dpZXMgaW50byBEQwo+Cj4K Pgo+IFNvbWUgb2YgeW91IHByZWZlciB0byBmb2N1cyBvbiBvbmUgb2YgdGhlIG9wdGlvbnMsIHdo aWxlIG90aGVycyBsaWtlIHRvCj4gaW5jbHVkZSBtdWx0aXBsZSBvcHRpb25zLgo+Cj4KPgo+IEhl cmUgaXMgbXkgb2JzZXJ2YXRpb24gYW5kIHRob3VnaHQuCj4KPgo+Cj4gMSAtIEl0IHNlZW1zIGEg Y29tbW9uIGRlbm9taW5hdG9yLiBEaWQgbm90IGhlYXIgbm8gb24gdGhpcy7CoCBJdCBpcwo+IGV4 YWN0bHkgdGhlIHByb2JsZW0gRGVyaWNrIHdhbnRpbmcgdG8gc29sdmUsIGl0IGlzIE5pbmcncyBz dGFydGluZwo+IHBvaW50LCBhbmQgaXQgaXMgaW5jbHVkZWQgaW4gdGhlIHJlcXVpcmVtZW50cyBk cmFmdHMuCj4KPiAyIC0gSXQgZG9lcyBub3QgbmVlZCB0byBjcmVhdGUgb3IgZXh0ZW5kIHByb3Rv Y29scywgc2hvdWxkIGdvIHRvCj4gT3BlcmF0aW9uIGFuZCBNYW5hZ2VtZW50IEFyZWEgZm9yIGFu eSBvcHMgaXNzdWVzIGFuZCBiZXN0IHByYWN0aWNlLgo+Cj4gMyAtIFRoZSBzY29wZSBsb29rcyBi aWcgdG8gbWUsIHRoZSBsaXN0IGlzIHBvdGVudGlhbGx5IHZlcnkgbG9uZy4KPgo+IDQgLSBJZiBu ZXcgZW5jcnlwdGlvbiBhbGdvcml0aG0sIGJldHRlciBrZXkgZGlzdHJpYnV0aW9uIG1lY2hhbmlz bSBhcmUKPiBuZWVkZWQswqAgdGhlIHdvcmsgc2hvdWxkIGdvIHRvIFNlY3VyaXR5IEFyZWE7IGlm IG5vdGhpbmcgbmV3LCBvcHMgaXNzdWVzCj4gZ28gdG8gT3BlcmF0aW9uIGFuZCBNYW5hZ2VtZW50 IEFyZWEuCj4KPiA1IC0gTDJWUE4gZm9yIERDIHdvcmsgc2hvdWxkIGdvIHRvIEwyVlBOIFdHLCBp dCBpcyBkZWZpbmVkIGluIEwyVlBOCj4gY2hhcnRlci4KPgo+Cj4KPiBUaGFua3MsCj4KPiBMdXl1 YW4KPgo+Cg== ------=_Part_2_1320720176744 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline cy9saWtlIHVwYXJjaWUvbGlrZSBpcHNlYy88YnI+PGJyPlNvcnJ5IGFuZHJvaWQmIzM5O3MgZmF1 bHQgOyg8YnI+PGJyPlIuPGJyPjxicj4tLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tPGJyPkZyb206 ICZxdW90O3JvYmVydEByYXN6dWsubmV0JnF1b3Q7ICZsdDtyb2JlcnRAcmFzenVrLm5ldCZndDs8 YnI+VG86ICZsdDtjY2llMTU2NzJAeWFob28uY29tJmd0OywgJnF1b3Q7bDN2cG5AaWV0Zi5vcmcm cXVvdDsgJmx0O2wzdnBuQGlldGYub3JnJmd0Ozxicj5TdWJqZWN0OiBSZTogVlBONERDIFNjb3Bl PGJyPkRhdGU6IFR1ZSwgTm92IDgsIDIwMTEgMTE6MzkgYW08YnI+PGJyPjxicj5IaSw8YnI+PGJy Pkp1c3QgdG8gY2xhcmlmeSBvbmUgbml0IGhlcmUuIEkgYW0gbm90IHNheWluZyB0byB1c2UgdmNp ZGVyIGFzIGlzIG5vciBJIGFtIHNheWluZyB0aGF0IGF0dGFjaGluZyBhIGdyb3VwIG9mIFZNIHRv IHlvdXIgTDMgVlBOIGlzIGEgYmFkIHRoaW5nLjxicj48YnI+SG93ZXZlciB3aGF0IEkgYW0gcG9p bnRpbmcgb3V0IHRoYXQgc2NvcGUgb2YgdGhlIFZQTjREQyBzaG91bGQgbm90IHN0b3Agb24ganVz dCBleHRlbmRpbmcgMjU0Ny4gUmF0aGVyIHRoZW4gdGhhdCBzdGFuZGFyZGl6aW5nIHZjaWRlciBs aWtlIGFwcHJvYWNoIHdpdGggc3VwcGxlbWVudHMgbGlrZSB1cGFyY2llIG9yIHJvdXRpbmcgd2ls bCBzZXJ2ZSB0byBtdWNoIGJyb2FkZXIgY3VzdG9tZXIgc3BhY2UuPGJyPjxicj5TbyB3aGlsZSBl eHRlbmRpbmcgbDN2cG4gdG8gdGhlIGhvc3QgaXMgYSBuZWF0IGlkZWEgYW5kIGxldHMgcHVzaCBp dCBmb3J3YXJkIGluIHRoZSBzYW1lIHRpbWUgbGV0JiMzOTtzIG5vdCBoYWx0IGVxdWFsbHkgc2lt cGxlIHNvbHV0aW9ucyB3aGljaCBjYW4gYWRkcmVzcyB0aGUgcHJvYmxlbSBmb3IgbWFueSBtb3Jl IHJlYWwgY2FzZXMuPGJyPjxicj5SZ2RzLDxicj5SLi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS08 YnI+RnJvbTogJnF1b3Q7RGVyaWNrIFdpbmt3b3J0aCZxdW90OyAmbHQ7Y2NpZTE1NjcyQHlhaG9v LmNvbSZndDs8YnI+VG86ICZxdW90O2wzdnBuQGlldGYub3JnJnF1b3Q7ICZsdDtsM3ZwbkBpZXRm Lm9yZyZndDs8YnI+U3ViamVjdDogVlBONERDIFNjb3BlPGJyPkRhdGU6IFR1ZSwgTm92IDgsIDIw MTEgMTE6MjUgYW08YnI+PGJyPlJvYjo8YnI+PGJyPnZDaWRlciBkb2VzIG5vdCBwcm92aWRlIGZv ciB0aGUgc2VjdXJlIGludGVyY29ubmVjdGlvbiBvZiBzaXRlcy4gwqBJdCBpcyBzb2Z0d2FyZSB0 aGF0IGlzIGluc3RhbGxlZCBvbiB0aGUgVk1zIHRoZW1zZWx2ZXMgd2hpY2ggYWxsb3dzIHRoZW0g dG8gdGFsayB0byBlYWNoIG90aGVyIGFzIGlmIHRoZXkgd2VyZSBvbiB0aGUgc2FtZSBWTEFOIG9u IGEgc3dpdGNoIHJlZ2FyZGxlc3Mgb2Ygd2hlcmUgdGhlIFZNcyBleGlzdHMuIMKgVHlwaWNhbGx5 IHRoZXNlIGFyZSBwdWJsaWMtY2xvdWQgcHJvdmlzaW9uZWQgVk1zIHRoYXQgYXJlIGV4cG9zZWQg dG8gdGhlIGludGVybmV0Ljxicj48YnI+SW4gdGhlIGNvbnRleHQgb2YgVlBONERDLCB0aGUgY3Vz dG9tZXIgY291bGQgdmVyeSB3ZWxsIGJlIHJ1bm5pbmcgdkNpZGVyIG9uIHRoZSBWTXMgaW4gdGhl IFByb3ZpZGVyJiMzOTtzIERDIGJ1dCBuZWl0aGVyIHRoZSBwcm92aWRlciBub3IgdGhlIGN1c3Rv bWVyIHNob3VsZCByZXF1aXJlIHNvZnR3YXJlIGxpa2UgdGhpcyBmb3IgYXR0YWNobWVudCBvZiB0 aGUgVk0gdG8gdGhlIGN1c3RvbWVyJiMzOTtzIEwzVlBOICh3aGljaCB0aGlzIHBhcnRpY3VsYXIg c29mdHdhcmUgd291bGQgbm90IGRvLCBCVFcpLiDCoFRoZSBnb2FsLCBhZ2FpbiwgaXMgbm90IHNl Y3VyZSBob3N0LXRvLWhvc3QgY29ubmVjdGl2aXR5ICh3ZSByZWFsbHkgc2hvdWxkbiYjMzk7dCBz YXkgdGhhdCkuIMKgSSBkb24mIzM5O3QgY2FyZSB3aGF0IHRoZSBWTSBpcyB0YWxraW5nIHRvIHBl ciBzZS4gwqBUaGUgVk1zJiMzOTsgdk5JQyBzaG91bGQgYmUgYm91bmQgYnkgcGF0aCBpc29sYXRp b24gdG8gdGhlIFZSRiBvbiB0aGUgcHJvdmlkZXImIzM5O3MgUEUgaW4gdGhlIHByb3ZpZGVyJiMz OTtzIERhdGEgQ2VudGVyLiDCoFRoZSBjdXN0b21lciBvbmx5IG5lZWRzIHRvIHB1dCBhbiBJUCBv biB0aGUgVk0gYXMgZmFyIGFzIHRoZSBTUCBpcyBjb25jZXJuZWQuIMKgV2hhdGV2ZXIgdGhlIGN1 c3RvbWVyIGRvZXMgb24gdG9wIG9mIHRoYXQgKElQU2VjIG9yIHZDaWRlcikgaXMgdXAgdG8gdGhl IGN1c3RvbWVyLjxicj48YnI+PGJyPkRlcmljazxicj48YnI+PGJyPjxicj48YnI+PGJyPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPkZyb206IFJvYmVydCBSYXN6dWsgJmx0O3Jv YmVydEByYXN6dWsubmV0Jmd0Ozxicj5UbzogTHV5dWFuIEZhbmcgKGx1ZmFuZykgJmx0O2x1ZmFu Z0BjaXNjby5jb20mZ3Q7PGJyPkNjOiBsM3ZwbkBpZXRmLm9yZzxicj5TZW50OiBNb25kYXksIE5v dmVtYmVyIDcsIDIwMTEgNjowNCBQTTxicj5TdWJqZWN0OiBSZTogVlBONERDIFNjb3BlPGJyPjxi cj5IaSBMdXl1YW4sPGJyPjxicj5BcyB3ZSBhcmUgZ2V0dGluZyBkb3duIHRvIHRoZSBzY29wZSBk ZWJhdGUgSSB0aGluayBpdCB3b3VsZCBiZSBxdWl0ZSA8YnI+cHJvZHVjdGl2ZSB0byBkaXNjdXNz IG9uZSBzb2x1dGlvbiBhcHBhcmVudGx5IGFscmVhZHkgYXZhaWxhYmxlIGZvciA8YnI+YXJiaXRy YXJ5IHNlY3VyZWQgaW50ZXJjb25uZWN0aW9uIG9mIGhvc3Qgb3Igc2l0ZXMuPGJyPjxicj5odHRw Oi8vdmNpZGVyLmNvbS88YnI+PGJyPkluIHBhcnRpY3VsYXIgSSB0aGluayBpdCB3b3VsZCBiZSBx dWl0ZSBpbnRlcmVzdGluZyB0byBrbm93IHdoYXQgaXMgPGJyPm1pc3NpbmcgZnJvbSB0aGUgYWJv dmUgc29sdXRpb24gb3IgdGhpcyBjbGFzcyBvZiBzb2x1dGlvbnMgaW4gZ2VuZXJhbCA8YnI+Zm9y IHRoZSBwcm9ibGVtIHNwYWNlIHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUuPGJyPjxicj5JdCBzZWVt cyB0byBtZSB0aGF0IHRoaXMgY2xhc3Mgb2Ygc29sdXRpb25zIGlzIHN1ZmZpY2llbnRseSBmbGV4 aWJsZSB0byA8YnI+YWRkcmVzcyBudW1iZXIgb2YgVlBONERDIGFuZCBiZXlvbmQgbmVlZHMgd2l0 aG91dCBhbnkgcHJlcmVxdWlzaXRlcyByZWcgPGJyPnRvcG9sb2d5IG9yIGNvbm5lY3Rpdml0eSBy ZXF1aXJlbWVudHMuPGJyPjxicj5NYW55IHRoeCw8YnI+Ui48YnI+PGJyPiZndDsgRGVhciBjb2xs ZWFndWVzLDxicj4mZ3Q7PGJyPiZndDsgVGhhbmsgeW91IGFsbCBmb3IgdGhlIGNvbnN0cnVjdGl2 ZSBkaXNjdXNzaW9uL3N1Z2dlc3Rpb25zIG92ZXIgdGhlIGxhc3Q8YnI+Jmd0OyBmZXcgd2Vla3Mg b24gVlBONERDLjxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IEkgdGhpbmsgd2Ugb2Jz ZXJ2ZWQgZ29vZCBpbnRlcmVzdHMvZW50aHVzaWFzbSBvbiBzb2x2aW5nIHRoZSBwcm9ibGVtcyBp bjxicj4mZ3Q7IHRoaXMgc3BhY2UuLjxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IFdl IG5lZWQgdG8gbmFycm93IGRvd24gdGhlIHNjb3BlIGFzIHRoZSBuZXh0IHN0ZXAuPGJyPiZndDs8 YnI+Jmd0OyBJIHN1bW1hcml6ZWQgdGhlIHByb3Bvc2FscyBzZW50IG9uIHRoZSBsaXN0IGFzIHRo ZSBmb2xsb3dpbmc6PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgMS7CoCDCoCDCoCBM ZXZlcmFnZSBCR1AvTVBMUyBWUE4gdGVjaG5vbG9naWVzLCBleHRlbmRpbmcgaXQgd2l0aCBsM3Zw bjxicj4mZ3Q7IHNpZ25hbGluZyBwcm90b2NvbHMgaW50byBEQyBWTSB2aXJ0dWFsIG5ldHdvcmtz Ljxicj4mZ3Q7PGJyPiZndDsgMi7CoCDCoCDCoCBVc2luZyBCR1AvTVBMUyBWUE4gZXhhY3RseSAm IzM5O2FzIGl0IGlzJiMzOTsgaW50byBEQyBWTSB2aXJ0dWFsPGJyPiZndDsgbmV0d29ya3M8YnI+ Jmd0Ozxicj4mZ3Q7IDMuwqAgwqAgwqAgRXh0ZW5kaW5nL2NyZWF0aW5nIGFueSBJUCBWUE4gdGVj aG5vbG9naWVzIGludG8gREM8YnI+Jmd0Ozxicj4mZ3Q7IDQuwqAgwqAgwqAgRXh0ZW5kaW5nL2Ny ZWF0aW5nIG9yIHJldXNlL21hbmFnaW5nIHNlY3VyaXR5IHByb3RvY29scyBmb3IgREM8YnI+Jmd0 OyBjb25uZWN0aW9ucywgaW5jbHVkaW5nIGVuY3J5cHRpb24sIGtleSBkaXN0cmlidXRpb24sIGtl eSBtYW5hZ2VtZW50PGJyPiZndDs8YnI+Jmd0OyA1LsKgIMKgIMKgIEV4dGVuZGluZy9jcmVhdGlu ZyBvciByZXVzZSBMMlZQTiBiYXNlZCB0ZWNobm9sb2dpZXMgaW50byBEQzxicj4mZ3Q7PGJyPiZn dDs8YnI+Jmd0Ozxicj4mZ3Q7IFNvbWUgb2YgeW91IHByZWZlciB0byBmb2N1cyBvbiBvbmUgb2Yg dGhlIG9wdGlvbnMsIHdoaWxlIG90aGVycyBsaWtlIHRvPGJyPiZndDsgaW5jbHVkZSBtdWx0aXBs ZSBvcHRpb25zLjxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IEhlcmUgaXMgbXkgb2Jz ZXJ2YXRpb24gYW5kIHRob3VnaHQuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgMSAt IEl0IHNlZW1zIGEgY29tbW9uIGRlbm9taW5hdG9yLiBEaWQgbm90IGhlYXIgbm8gb24gdGhpcy7C oCBJdCBpczxicj4mZ3Q7IGV4YWN0bHkgdGhlIHByb2JsZW0gRGVyaWNrIHdhbnRpbmcgdG8gc29s dmUsIGl0IGlzIE5pbmcmIzM5O3Mgc3RhcnRpbmc8YnI+Jmd0OyBwb2ludCwgYW5kIGl0IGlzIGlu Y2x1ZGVkIGluIHRoZSByZXF1aXJlbWVudHMgZHJhZnRzLjxicj4mZ3Q7PGJyPiZndDsgMiAtIEl0 IGRvZXMgbm90IG5lZWQgdG8gY3JlYXRlIG9yIGV4dGVuZCBwcm90b2NvbHMsIHNob3VsZCBnbyB0 bzxicj4mZ3Q7IE9wZXJhdGlvbiBhbmQgTWFuYWdlbWVudCBBcmVhIGZvciBhbnkgb3BzIGlzc3Vl cyBhbmQgYmVzdCBwcmFjdGljZS48YnI+Jmd0Ozxicj4mZ3Q7IDMgLSBUaGUgc2NvcGUgbG9va3Mg YmlnIHRvIG1lLCB0aGUgbGlzdCBpcyBwb3RlbnRpYWxseSB2ZXJ5IGxvbmcuPGJyPiZndDs8YnI+ Jmd0OyA0IC0gSWYgbmV3IGVuY3J5cHRpb24gYWxnb3JpdGhtLCBiZXR0ZXIga2V5IGRpc3RyaWJ1 dGlvbiBtZWNoYW5pc20gYXJlPGJyPiZndDsgbmVlZGVkLMKgIHRoZSB3b3JrIHNob3VsZCBnbyB0 byBTZWN1cml0eSBBcmVhOyBpZiBub3RoaW5nIG5ldywgb3BzIGlzc3Vlczxicj4mZ3Q7IGdvIHRv IE9wZXJhdGlvbiBhbmQgTWFuYWdlbWVudCBBcmVhLjxicj4mZ3Q7PGJyPiZndDsgNSAtIEwyVlBO IGZvciBEQyB3b3JrIHNob3VsZCBnbyB0byBMMlZQTiBXRywgaXQgaXMgZGVmaW5lZCBpbiBMMlZQ Tjxicj4mZ3Q7IGNoYXJ0ZXIuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgVGhhbmtz LDxicj4mZ3Q7PGJyPiZndDsgTHV5dWFuPGJyPiZndDs8YnI+Jmd0Ozxicj4= ------=_Part_2_1320720176744-- From ccie15672@yahoo.com Mon Nov 7 19:10: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 869D321F848A for ; Mon, 7 Nov 2011 19:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.353 X-Spam-Level: X-Spam-Status: No, score=0.353 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_20=-0.74, 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 6aD0npBSGPl2 for ; Mon, 7 Nov 2011 19:09:59 -0800 (PST) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) by ietfa.amsl.com (Postfix) with SMTP id 358E921F847F for ; Mon, 7 Nov 2011 19:09:59 -0800 (PST) Received: from [98.139.212.144] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 08 Nov 2011 03:09:49 -0000 Received: from [98.139.212.214] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 08 Nov 2011 03:09:49 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 08 Nov 2011 03:09:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 637604.81779.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 86338 invoked by uid 60001); 8 Nov 2011 03:09:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1320721789; bh=Ve4gApZcToxZbM4rHAAg3DuD/Tgw8f04Mo8tkcCLWHI=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=L26F8bBPVk/8RgVOpG7p/2+hkyxtAchYNkjCECpl09QBjKiqM0ndLuxSXyft13o5L3VGS64thpLgBVKAabdoLy1DShN5gJuZPFSk4/dflKJNWV1tBWG9YV8LHzWVoXG9MZKIQxRF2pQHy4oqyEaXCJ1p8a4XsXFPRcqyoXE0EFA= 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:MIME-Version:Content-Type; b=EhvGU6IOQQ2TH5c6p2qk7L1gZOZrADY9JWr/QZFiU7cg6NKl3XBTMe+kUp2i2A4SNhYD0G8qz1rHqb76C3c9zjOAFcKEjR31x0AWuZv1+u4MRdynyJkYmqEWjrwRtsd7pSz1XczDEH3VRYBcrJ3OPa4rZBEg1tr6S9M8hKuRWaU=; X-YMail-OSG: DDYoSn0VM1mYACAk4qBy6MK434_SD09In66PToOOMIvhP8v TIfhCuNHiVGDYCVaDxr_ycwFPT0EWhFliGCsm64Pjm0aJ03tEdTZYHOwLv3H Qvq3jq9bp3lPsSgK5DD1ZP1qETEBpNqNEH7DdjAppuYGUMuMVDgo0H0VaBCB H2G9X95Z2H0ISWk7IigFXDELl8YrWDwjMjWqm6kcrJkQBQUcfkoEzNWER4ha tXZBxTofdu30AB0wBfBq6UXaLHWHXJd4JwMn2BYZqdAnk3xVET.TEzg_0otq dLvMN9TX0e2X95xMFiT9dNF3ckogNGbyCPCZIQOKu3QAzaxNTads45LoayJX sF0qXPA5XORcOD9ERLLdfYNVnt538xbmps6lnSNF8OUFsmLmW7gwQNUKYV14 O2th1WqpfLYyLnwL0C1W0_Gz9yh1.cweZ4.iY.xLgE2Vgyb0r.Ss5moMJLwZ h.9sZMSKtzWvsMltKmpJuNqagNZwZl6fFWRXKdAt2WYTJAxbbgwX3CMZWX.M - Received: from [76.194.43.66] by web161806.mail.bf1.yahoo.com via HTTP; Mon, 07 Nov 2011 19:09:49 PST X-Mailer: YahooMailWebService/0.8.114.317681 References: Message-ID: <1320721789.80856.YahooMailNeo@web161806.mail.bf1.yahoo.com> Date: Mon, 7 Nov 2011 19:09:49 -0800 (PST) From: Derick Winkworth Subject: Re: VPN4DC Scope To: "l3vpn@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1665047788-1943295256-1320721789=:80856" 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, 08 Nov 2011 03:10:00 -0000 --1665047788-1943295256-1320721789=:80856 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable See comments in-line=0A=0A=0A________________________________=0AFrom: "robe= rt@raszuk.net" =0ATo: ccie15672@yahoo.com; "l3vpn@ietf.o= rg" =0ASent: Monday, November 7, 2011 8:39 PM=0ASubject: Re= : VPN4DC Scope=0A=0A=0AHi,=0A=0AJust to clarify one nit here. I am not sayi= ng to use vcider as is nor I am saying that attaching a group of VM to your= L3 VPN is a bad thing.=0A=0AHowever what I am pointing out that scope of t= he VPN4DC should not stop on just extending 2547. Rather then that standard= izing vcider like approach with supplements like uparcie or routing will se= rve to much broader customer space.=0A=0A-----------=0AOk, understood. =A0I= think it has been asked of the VPN4DC contributors to narrow the scope and= be specific. =A0At this stage MPLS/L3VPN integration within a provider DC = has been chosen as the scope, thus the L3VPN mailing list has been chosen f= or this discussion. =A0Personally, I think there will be multiple ways of c= onnecting VMs to different kinds of networks. =A0I think multiple tools wil= l be necessary.=0A-----------=0A=0A---------=0ASo while extending l3vpn to = the host is a neat idea and lets push it forward in the same time let's not= halt equally simple solutions which can address the problem for many more = real cases.=0A---------=0A=0AI'm not sure what you mean by "many more." =A0= If you are indicating that the current scope of VPN4DC is too narrow and on= ly addresses a minority of cases, I would disagree.=A0=0A=0A=0A=0A----- Rep= ly message -----=0AFrom: "Derick Winkworth" =0ATo: "l3= vpn@ietf.org" =0ASubject: VPN4DC Scope=0ADate: Tue, Nov 8, = 2011 11:25 am=0A=0A=0ARob:=0A=0AvCider does not provide for the secure inte= rconnection of sites. =A0It is software that is installed on the VMs themse= lves which allows them to talk to each other as if they were on the same VL= AN on a switch regardless of where the VMs exists. =A0Typically these are p= ublic-cloud provisioned VMs that are exposed to the internet.=0A=0AIn the c= ontext of VPN4DC, the customer could very well be running vCider on the VMs= in the Provider's DC but neither the provider nor the customer should requ= ire software like this for attachment of the VM to the customer's L3VPN (wh= ich this particular software would not do, BTW). =A0The goal, again, is not= secure host-to-host connectivity (we really shouldn't say that). =A0I don'= t care what the VM is talking to per se. =A0The VMs' vNIC should be bound b= y path isolation to the VRF on the provider's PE in the provider's Data Cen= ter. =A0The customer only needs to put an IP on the VM as far as the SP is = concerned. =A0Whatever the customer does on top of that (IPSec or vCider) i= s up to the customer.=0A=0A=0ADerick=0A=0A=0A=0A=0A=0A_____________________= ___________=0AFrom: Robert Raszuk =0ATo: Luyuan Fang (lu= fang) =0ACc: l3vpn@ietf.org=0ASent: Monday, November 7, 2= 011 6:04 PM=0ASubject: Re: VPN4DC Scope=0A=0AHi Luyuan,=0A=0AAs we are gett= ing down to the scope debate I think it would be quite =0Aproductive to dis= cuss one solution apparently already available for =0Aarbitrary secured int= erconnection of host or sites.=0A=0Ahttp://vcider.com/=0A=0AIn particular I= think it would be quite interesting to know what is =0Amissing from the ab= ove solution or this class of solutions in general =0Afor the problem space= we are discussing here.=0A=0AIt seems to me that this class of solutions i= s sufficiently flexible to =0Aaddress number of VPN4DC and beyond needs wit= hout any prerequisites reg =0Atopology or connectivity requirements.=0A=0AM= any thx,=0AR.=0A=0A> Dear colleagues,=0A>=0A> Thank you all for the constru= ctive discussion/suggestions over the last=0A> few weeks on VPN4DC.=0A>=0A>= =0A>=0A> I think we observed good interests/enthusiasm on solving the probl= ems in=0A> this space..=0A>=0A>=0A>=0A> We need to narrow down the scope as= the next step.=0A>=0A> I summarized the proposals sent on the list as the = following:=0A>=0A>=0A>=0A> 1.=A0 =A0 =A0 Leverage BGP/MPLS VPN technologies= , extending it with l3vpn=0A> signaling protocols into DC VM virtual networ= ks.=0A>=0A> 2.=A0 =A0 =A0 Using BGP/MPLS VPN exactly 'as it is' into DC VM = virtual=0A> networks=0A>=0A> 3.=A0 =A0 =A0 Extending/creating any IP VPN te= chnologies into DC=0A>=0A> 4.=A0 =A0 =A0 Extending/creating or reuse/managi= ng security protocols for DC=0A> connections, including encryption, key dis= tribution, key management=0A>=0A> 5.=A0 =A0 =A0 Extending/creating or reuse= L2VPN based technologies into DC=0A>=0A>=0A>=0A> Some of you prefer to foc= us on one of the options, while others like to=0A> include multiple options= .=0A>=0A>=0A>=0A> Here is my observation and thought.=0A>=0A>=0A>=0A> 1 - I= t seems a common denominator. Did not hear no on this.=A0 It is=0A> exactly= the problem Derick wanting to solve, it is Ning's starting=0A> point, and = it is included in the requirements drafts.=0A>=0A> 2 - It does not need to = create or extend protocols, should go to=0A> Operation and Management Area = for any ops issues and best practice.=0A>=0A> 3 - The scope looks big to me= , the list is potentially very long.=0A>=0A> 4 - If new encryption algorith= m, better key distribution mechanism are=0A> needed,=A0 the work should go = to Security Area; if nothing new, ops issues=0A> go to Operation and Manage= ment Area.=0A>=0A> 5 - L2VPN for DC work should go to L2VPN WG, it is defin= ed in L2VPN=0A> charter.=0A>=0A>=0A>=0A> Thanks,=0A>=0A> Luyuan=0A>=0A> --1665047788-1943295256-1320721789=:80856 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
See comments in-line
<= div>
From: "robert@raszuk.net= " <robert@raszuk.net>
To: ccie15672@yahoo.com; "l3vpn@ietf.org" <l3vpn@ietf.org>
Sent: Monday, November 7, 20= 11 8:39 PM
Subject: Re:= VPN4DC Scope

=0A
Hi,

Just to= clarify one nit here. I am not saying to use vcider as is nor I am saying = that attaching a group of VM to your L3 VPN is a bad thing.

However = what I am pointing out that scope of the VPN4DC should not stop on just ext= ending 2547. Rather then that standardizing vcider like approach with suppl= ements like uparcie or routing will serve to much broader customer space.
-----------
Ok, understood.  I th= ink it has been asked of the VPN4DC contributors to narrow the scope and be= specific.  At this stage MPLS/L3VPN integration within a provider DC = has been chosen as the scope, thus the L3VPN mailing list has been chosen f= or this discussion.  Personally, I think there will be multiple ways o= f connecting VMs to different kinds of networks.  I think multiple too= ls will be necessary.
-----------

---------
So while extending l3vpn to the host= is a neat idea and lets push it forward in the same time let's not halt eq= ually simple solutions which can address the problem for many more real cas= es.
---------

I'm not sure what you mean by "many mo= re."  If you are indicating that the current scope of VPN4DC is too na= rrow and only addresses a minority of cases, I would disagree. 
<= div id=3D"yiv1117690141">


----- Reply message -----
From: "De= rick Winkworth" <ccie15672@yahoo.com>
To: "l3vpn@ietf.org" <l3v= pn@ietf.org>
Subject: VPN4DC Scope
Date: Tue, Nov 8, 2011 11:25 am=


Rob:

vCider does not provide for the secure interconnect= ion of sites.  It is software that is installed on the VMs themselves = which allows them to talk to each other as if they were on the same VLAN on= a switch regardless of where the VMs exists.  Typically these are publi= c-cloud provisioned VMs that are exposed to the internet.

In the con= text of VPN4DC, the customer could very well be running vCider on the VMs i= n the Provider's DC but neither the provider nor the customer should requir= e software like this for attachment of the VM to the customer's L3VPN (whic= h this particular software would not do, BTW).  The goal, again, is no= t secure host-to-host connectivity (we really shouldn't say that).  I = don't care what the VM is talking to per se.  The VMs' vNIC should be = bound by path isolation to the VRF on the provider's PE in the provider's D= ata Center.  The customer only needs to put an IP on the VM as far as = the SP is concerned.  Whatever the customer does on top of that (IPSec= or vCider) is up to the customer.


Derick




________________________________
From: Robert Raszuk <robert@raszuk.net>
To: Luyuan Fang (lufang) <lufang@cisco.com= >
Cc: l3vpn@ietf.org
Sent: Monday, November 7, 2011 6:04 PM
Sub= ject: Re: VPN4DC Scope

Hi Luyuan,

As we are getting down to t= he scope debate I think it would be quite
productive to discuss one sol= ution apparently already available for
arbitrary secured interconnectio= n of host or sites.

http://vcider.com/

In particular I think = it would be quite interesting to know what is
missing from the above so= lution or this class of solutions in general
for the problem space we a= re discussing here.

It seems to me that this class of solutions is s= ufficiently flexible to
address number of VPN4DC and beyond needs witho= ut any prerequisites reg
topology or connectivity requirements.

= Many thx,
R.

> Dear colleagues,
>
> Thank you all = for the constructive discussion/suggestions over the last
> few weeks on VPN4DC.
>
>
>
> I think we observed g= ood interests/enthusiasm on solving the problems in
> this space..>
>
>
> We need to narrow down the scope as the next = step.
>
> I summarized the proposals sent on the list as the fo= llowing:
>
>
>
> 1.      Leverage BG= P/MPLS VPN technologies, extending it with l3vpn
> signaling protocol= s into DC VM virtual networks.
>
> 2.      Using= BGP/MPLS VPN exactly 'as it is' into DC VM virtual
> networks
>= ;
> 3.      Extending/creating any IP VPN technologies= into DC
>
> 4.      Extending/creating or reuse= /managing security protocols for DC
> connections, including encrypti= on, key distribution, key management
>
> 5.     = Extending/creating or reuse L2VPN based technologies into DC
>
>
>
> Some of you prefer to focus on one of t= he options, while others like to
> include multiple options.
><= br>>
>
> Here is my observation and thought.
>
>=
>
> 1 - It seems a common denominator. Did not hear no on this= .  It is
> exactly the problem Derick wanting to solve, it is Ni= ng's starting
> point, and it is included in the requirements drafts.=
>
> 2 - It does not need to create or extend protocols, should= go to
> Operation and Management Area for any ops issues and best pr= actice.
>
> 3 - The scope looks big to me, the list is potentia= lly very long.
>
> 4 - If new encryption algorithm, better key = distribution mechanism are
> needed,  the work should go to Secu= rity Area; if nothing new, ops issues
> go to Operation and Managemen= t Area.
>
> 5 - L2VPN for DC work should go to L2VPN WG, it is defined in L2VPN
> charter.
>
>
>
> Th= anks,
>
> Luyuan
>
>


<= /div> --1665047788-1943295256-1320721789=:80856-- From xuxiaohu@huawei.com Mon Nov 7 19:59:08 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 2EA8411E80E3 for ; Mon, 7 Nov 2011 19:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.242 X-Spam-Level: X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajuHzG9ppspW for ; Mon, 7 Nov 2011 19:59:07 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC9E11E8096 for ; Mon, 7 Nov 2011 19:59:07 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUB009IIPQ0MY@szxga04-in.huawei.com> for l3vpn@ietf.org; Tue, 08 Nov 2011 11:58:48 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUB006K7PQ0BM@szxga04-in.huawei.com> for l3vpn@ietf.org; Tue, 08 Nov 2011 11:58:48 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEX02135; Tue, 08 Nov 2011 11:58:48 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 08 Nov 2011 11:58:44 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Tue, 08 Nov 2011 11:58:41 +0800 Date: Tue, 08 Nov 2011 03:58:40 +0000 From: Xuxiaohu Subject: re: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda @ IETF82 In-reply-to: X-Originating-IP: [10.108.4.59] To: Pedro Marques Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7476F8@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda @ IETF82 Thread-index: AQHMncqz2qXmvIgWQEe50AvHCMW38Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120B1CD6@dfweml505-mbx> <238542D917511A45B6B8AA806E875E25073CA33E@XMB-RCD-201.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F6120B1F7A@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120B209B@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D016@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73D107@szxeml525-mbs.china.huawei.com> Cc: L3VPN WG mailing list 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, 08 Nov 2011 03:59:08 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IFBlZHJvIE1hcnF1ZXMgW21haWx0bzpw ZWRyby5yLm1hcnF1ZXNAZ21haWwuY29tXQ0KPiC3osvNyrG85DogMjAxMcTqMTHUwjXI1SAwOjE1 DQo+IMrVvP7IyzogWHV4aWFvaHUNCj4gs63LzTogTDNWUE4gV0cgbWFpbGluZyBsaXN0DQo+INb3 zOI6IFJlOiC08Li0OiBBcHBsaWNhdGlvbiBvZiBMM1ZQTiBmb3IgRENJLy9yZTogUHJlbGltaW5h cnkgTDNWUE4vVlBONERDDQo+IGFnZW5kYSBAIElFVEY4Mg0KPiANCj4gWGlhb2h1LA0KPiBZb3Ug YXJlIGNvcnJlY3QsIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGwzdnBuLWVuZC1zeXN0ZW0g cHJvcG9zYWwNCj4gYW5kIGN1cnJlbnQgbDN2cG4gZGVwbG95bWVudHMgaXMgdGhlIGZhY3QgdGhh dCB0aGUgZm9yd2FyZGluZw0KPiBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhlIG92ZXJsYXkgbmV0 d29yayBpcyBlbnRpcmVseSBwdXNoZWQgdG8gdGhlDQo+IGVkZ2UuIEluIHRoYXQgc2NlbmFyaW8g dGhlIGRhdGEgY2VudGVyIGZhYnJpYyBoYXMgbm8ga25vd2xlZGdlIG9mIHRoZQ0KPiBvdmVybGF5 IG5ldHdvcmsuDQo+IA0KPiBXaGV0aGVyIHRoZSBsYXRlciBpcyBpbXBvcnRhbnQgZGVwZW5kcyBv biBhc3N1bXB0aW9ucyBvZiBzY2FsZSBhbmQgaG93DQo+IHNjYWxlIGltcGFjdHMgdGhlIGVjb25v bWljcyBvZiBuZXR3b3JrIGRldmljZXMuDQoNClBlZHJvLA0KDQpJIGFncmVlIHRoYXQgc2NhbGFi aWxpdHkgaXMgYSBtdWNoIGltcG9ydGFudCByZXF1aXJlbWVudCBmb3IgZGF0YSBjZW50ZXIgaW50 ZXJjb25uZWN0IGFuZCBJIGJlbGlldmUgaG9zdCByb3V0ZSBiYXNlZCBMM1ZQTiBzb2x1dGlvbiBp cyBhIGdvb2Qgb3B0aW9uIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Rpb24gZXNwZWNpYWxs eSB3aGVuIHdlIGFyZSBjb25zaWRlcmluZyBwYXRoIG9wdGltaXphdGlvbiBmb3IgaW50ZXItc3Vi bmV0IHRyYWZmaWMuIEhvd2V2ZXIsIEkgd29uZGVyIHdoZXRoZXIgaXQgaXMgcHJhY3RpY2FsIHRv IGFzc3VtZSBhbGwgZGF0YSBjZW50ZXJzIHRvIGJlIGNvbm5lY3RlZCwgZXNwZWNpYWxseSB0aG9z ZSBleGlzdGluZyBlbnRlcnByaXNlIGRhdGEgY2VudGVycywgYXJlIHJlYWR5IHRvIHN1cHBvcnQg dGhlIEwzVlBOIFBFIGZ1bmN0aW9ucyBvbiBlbmQgc3lzdGVtcy4gDQoNCkhlbmNlIEkgYmVsaWV2 ZSB3ZSBhbHNvIG5lZWQgYSBob3N0IHJvdXRlIGJhc2VkIEwzVlBOIHNvbHV0aW9uIHdoaWNoIGRv ZXNuJ3QgcmVxdWlyZSBleHRlbmRpbmcgdGhlIFBFIGZ1bmN0aW9ucyB0byBlbmQtc3lzdGVtcyAo ZS5nLiwgdmlydHVhbCBzdWJuZXQpIGluIG9yZGVyIHRvIGFsbG93IHRob3NlIGV4aXN0aW5nIGVu dGVycHJpc2UgZGF0YSBjZW50ZXJzIHdoaWNoIHVzZSBsYXllcjIgbmV0d29yayB0ZWNobm9sb2dp ZXMgKGUuZy4sIFNUUCwgU1BCIGFuZCBWUExTIGV0Yy4pIHRvIGJlIGNvbm5lY3RlZCB0byB0aGUg cHJvdmlkZXIncyBjbG91ZCBkYXRhIGNlbnRlcnMuIEluIHRoaXMgd2F5LCB0aG9zZSBlbnRlcnBy aXNlIGRhdGEgY2VudGVycyBjb3VsZCBiZSBjb25uZWN0ZWQgdG8gdGhlIG5ldHdvcmstYmFzZWQg TDNWUE4gUEUgcm91dGVycyB3aXRob3V0IHJlcXVpcmluZyB1cGdyYWRpbmcgdGhlaXIgc2VydmVy cywgd2hpbGUgdGhlIHByb3ZpZGVyJ3MgZGF0YSBjZW50ZXJzIGFyZSBhYmxlIHRvIHN1cHBvcnQg dGhlIGwzdnBuLWVuZC1zeXN0ZW0uDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KIA0KPiAgIFBl ZHJvLg0KPiANCj4gMjAxMS8xMS80IFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPjoNCj4g Pg0KPiA+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPj4gt6K8/sjLOiBYdXhpYW9odQ0KPiA+PiC3 osvNyrG85DogMjAxMcTqMTHUwjTI1SAxNToyMA0KPiA+PiDK1bz+yMs6ICdQZWRybyBNYXJxdWVz Jw0KPiA+PiCzrcvNOiBMM1ZQTiBXRyBtYWlsaW5nIGxpc3QNCj4gPj4g1vfM4jogtPC4tDogQXBw bGljYXRpb24gb2YgTDNWUE4gZm9yIERDSS8vcmU6IFByZWxpbWluYXJ5IEwzVlBOL1ZQTjREQw0K PiA+PiBhZ2VuZGEgQCBJRVRGODINCj4gPj4NCj4gPj4NCj4gPj4gPiAtLS0tLdPKvP7Urbz+LS0t LS0NCj4gPj4gPiC3orz+yMs6IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1i b3VuY2VzQGlldGYub3JnXSC0+rHtDQo+ID4+IFBlZHJvDQo+ID4+ID4gTWFycXVlcw0KPiA+PiA+ ILeiy83KsbzkOiAyMDExxOoxMdTCNMjVIDEyOjE0DQo+ID4+ID4gytW8/sjLOiBYdXhpYW9odQ0K PiA+PiA+ILOty806IEwzVlBOIFdHIG1haWxpbmcgbGlzdA0KPiA+PiA+INb3zOI6IFJlOiBBcHBs aWNhdGlvbiBvZiBMM1ZQTiBmb3IgRENJLy9yZTogUHJlbGltaW5hcnkgTDNWUE4vVlBONERDDQo+ ID4+IGFnZW5kYQ0KPiA+PiA+IEAgSUVURjgyDQo+ID4+ID4NCj4gPj4gPiBYaWFvaHUsDQo+ID4+ ID4NCj4gPj4gPiBPbiBUaHUsIE5vdiAzLCAyMDExIGF0IDg6NTQgUE0sIFh1eGlhb2h1IDx4dXhp YW9odUBodWF3ZWkuY29tPg0KPiB3cm90ZToNCj4gPj4gPiA+PiBUaGVyZSBpcyBhIHNlY29uZCBy ZWFzb24gd2h5IHRoZSBkYXRhLWNlbnRlciBuZXR3b3JrIHRvcG9sb2d5IGlzDQo+ID4+ID4gPj4g dmlydHVhbGl6ZWQgd2hpY2ggaXMgdGhlIG5lZWQgdG8gc3VwcG9ydCBWTSBtb3Zlcy4gVGhpcyBp bXBsaWVzIHRoYXQNCj4gPj4gPiA+PiB0aGUgSVAgYWRkcmVzc2VzIHVzZWQgZm9yIGNvbW11bmlj YXRpb24gYmV0d2VlbiBhcHBsaWNhdGlvbnMgbWF5IGJlDQo+ID4+ID4gPj4gYW55d2hlcmUgYWNy b3NzIHRoZSBkYXRhLWNlbnRlci4gVXNpbmcgYSB2aXJ0dWFsIHRvcG9sb2d5IGlzIGFuDQo+ID4+ ID4gPj4gYXR0cmFjdGl2ZSB3YXkgdG8gc29sdmUgdGhpcyBwcm9ibGVtLg0KPiA+PiA+ID4NCj4g Pj4gPiA+IEkgZ3Vlc3MgVk0gbW9iaWxpdHkgaXMgbm90IHRoZSBvYmplY3QgZm9yIFZQTjREQy4g Rm9yIFZNIG1vYmlsaXR5IGFjcm9zcw0KPiA+PiA+IGRhdGEgY2VudGVycywgc3VibmV0IGV4dGVu c2lvbiBhdCBsZWFzdCBpcyByZXF1aXJlZCBzbyBhcyB0byBhbGxvdyB0aGUgSVANCj4gPj4gPiBh ZGRyZXNzZXMgdXNlZCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGFwcGxpY2F0aW9ucyB0byBi ZSBhbnl3aGVyZQ0KPiA+PiA+IGFjcm9zcyB0aGUgZGF0YS1jZW50ZXJzLg0KPiA+PiA+DQo+ID4+ ID4gVGhlcmUgaXMgbm8gcmVhc29uIHRvIHRoaW5rIGluIHRlcm1zIG9mIHN1Ym5ldHMuIEdpdmVu IHRoYXQgdGhlcmUgaXMNCj4gPj4gPiBubyBsb2NhbGl0eSB0aGUgY29uY2VwdCBvZiBzdWJuZXQg bm8gbG9uZ2VyIG1ha2VzIGFueSBzZW5zZS4gVGh1cyBvbmUNCj4gPj4gPiBoYXMgYSBjb2xsZWN0 aW9uIG9mIGhvc3Qgcm91dGVzIHNwcmVhZCByYW5kb21seSBhY3Jvc3MgYSBsYXJnZSBhcmVhLg0K PiA+PiA+DQo+ID4+ID4gSXQgaXMgdHJpdmlhbCB0byBtYWtlIGFsbCBWTSB0byBWTSBjb21tdW5p Y2F0aW9uIHJvdXRlZC4gSWYgeW91IGxvb2sNCj4gPj4gPiBhdCB0aGUgZGV0YWlscyBpbiB0aGUg bDN2cG4tZW5kLXN5c3RlbSBwcm9wb3NhbCwgcGFja2V0cyBhcmUgcm91dGVkDQo+ID4+DQo+ID4+ IEFmdGVyIHJlYWRpbmcgeW91ciBsM3Zwbi1lbmQtc3lzdGVtIHByb3Bvc2FsIGF0IGEgZ2xhbmNl LCBJIGZlbHQgdGhhdCBib3RoDQo+ID4+IGwzdnBuLWVuZC1zeXN0ZW0gcHJvcG9zYWwgYW5kIFZp cnR1YWwgU3VibmV0IHByb3Bvc2FsIGFyZSB1c2luZyBMM1ZQTiB0bw0KPiA+PiBleGNoYW5nZSBo b3N0IHJvdXRlcyB3aGlsZSB0aGUgbWFqb3IgZGlmZmVyZW5jZSBpcyB0aGF0IHlvdXIgcHJvcG9z YWwNCj4gZXhwZWN0cw0KPiA+PiB0byBleHRlbmQgdGhlIFBFIGZ1bmN0aW9ucyB0byB0aGUgaG9z dHMgYW5kIG15IHByb3Bvc2FsIGludGVuZHMgdG8gcmV0YWluDQo+IHRoZQ0KPiA+PiBQRSBmdW5j dGlvbnMgb24gdGhlIHJvdXRlcnMuIEl0J3MgaW50ZXJlc3Rpbmc6KQ0KPiA+DQo+ID4gQWhhLCBp ZiB0aGUgZGF0YSBjZW50ZXIgb3BlcmF0b3JzIHdvdWxkIGxpa2UgdG8gcGVyZm9ybSB0aGUgUEUg ZnVuY3Rpb25zIG9mDQo+IFZpcnR1YWwgU3VibmV0IGF0IFRvUiBzd2l0Y2hlcywgaXQgc2VlbXMg YWxtb3N0IG5vIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGVzZQ0KPiB0d28gcHJvcG9zYWxzIGZyb20g dGhlIHBlcnNwZWN0aXZlIG9mIGVmZmVjdC4NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBY aWFvaHUNCj4gPj4NCj4gPj4gPiBmcm9tIHRoZSBWTSB0byB0aGUgaG9zdC1vcyBhbmQgYnkgdGhl IGhvc3Qtb3Mgd2hpY2ggZW5jYXBzdWxhdGVzIHRoZQ0KPiA+PiA+IHBhY2tldHMuIFRoZSBsYXR0 ZXIgaGFzIGEgY29sbGVjdGlvbiBvZiBob3N0IHJvdXRlcy4gVGhpbmtpbmcgaW4gdGVybXMNCj4g Pj4gPiBvZiBzdWJuZXRzIGlzIG5vdCBoZWxwZnVsLCB0aGUgY29uY2VwdCBpcyBqdXN0IG5vdCBh cHBsaWNhYmxlLg0KPiA+PiA+DQo+ID4+ID4gVXNpbmcgQVJQLCBwcm94eSBvciBvdGhlcndpc2Us IGlzIHNpbXBseSBzZWxmIGluZmxpY3RlZCBwYWluIGFuZA0KPiA+PiA+IHN1ZmZlcmluZy4gVGhl cmUgaXMgbm8gcmVhc29uIHRvIGNhcmUgYWJvdXQgdGhlIG1hYyBhZGRyZXNzIG9mIHRoZQ0KPiA+ PiA+IHJlbW90ZSBzeXN0ZW0uDQo+ID4+ID4NCj4gPj4gPiByZWdhcmRzLA0KPiA+PiA+ICAgUGVk cm8uDQo+ID4NCg== From nabil.n.bitar@verizon.com Mon Nov 7 21:41: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 33C8B11E80F9; Mon, 7 Nov 2011 21:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.092, 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 60V5Aa6djadN; Mon, 7 Nov 2011 21:41:57 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id B33CC11E80F4; Mon, 7 Nov 2011 21:41:56 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 08 Nov 2011 05:41:55 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.69,475,1315180800"; d="scan'208,217";a="175610936" Received: from fldp1lumxc7hb02.verizon.com (HELO FLDP1LUMXC7HB02.us.one.verizon.com) ([166.68.75.85]) by fldsmtpi03.verizon.com with ESMTP; 08 Nov 2011 05:41:55 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.102]) by FLDP1LUMXC7HB02.us.one.verizon.com ([166.68.75.85]) with mapi; Tue, 8 Nov 2011 00:41:55 -0500 To: "l3vpn@ietf.org" , "l2vpn@ietf.org" Date: Tue, 8 Nov 2011 00:41:54 -0500 Subject: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CADE2A322CAF3nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Sagessi , "marc.lasserre@alcatel-lucent.com" , "mircea.pisica@bt.com" , "y.ikejiri@ntt.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, 08 Nov 2011 05:41:58 -0000 --_000_CADE2A322CAF3nabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We had submitted the following draft on vpn applicability for data center. = Your input on the draft is appreciated in light of some of the ongoing disc= ussion. The draft is targeted for l3vpn and l2vpn. Here is the link: http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 Abstract Cloud Computing has been attracting a lot of attention from the networking industry. Some of the most publicized requirements are related to the evolution of the Cloud Networking Infrastructure to accommodate a large number of tenants, efficient network utilization, scalable loop avoidance, and Virtual Machine Mobility. This draft describes a framework for cloud networking, highlighting the applicability of existing work in various IETF Working Groups (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working Groups) to cloud networking, and the gaps and problems that need to be further addressed. That is, the goal is to understand what may be re-used from the current protocols and call out requirements specific to the Cloud space that need to be addressed by new standardization work with proposed solutions in certain cases. Thanks, Nabil --_000_CADE2A322CAF3nabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
We had sub= mitted the following draft on vpn applicability for data center. Your input= on the draft is appreciated in light of some of the ongoing discussion. Th= e draft is targeted for l3vpn and l2vpn.
Here is the link: <= /div>


Abstract

   Cloud Computing has been attracting a lot of attention from the
   networking industry. Some of the most publicized requirements are
   related to the evolution of the Cloud Networking Infrastructure to
   accommodate a large number of tenants, efficient network utilization,
   scalable loop avoidance, and Virtual Machine Mobility.

   This draft describes a framework for cloud networking, highlighting
   the applicability of existing work in various IETF Working Groups
   (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the gaps and problems that need to
   be further addressed. That is, the goal is to understand what may be
   re-used from the current protocols and call out requirements specific
   to the Cloud space that need to be addressed by new standardization
   work with proposed solutions in certain cases.

Thanks,=

Nabil
--_000_CADE2A322CAF3nabilnbitarverizoncom_-- From xuxiaohu@huawei.com Mon Nov 7 23:55: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 E141921F8B45; Mon, 7 Nov 2011 23:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+Fv+wWXLbTo; Mon, 7 Nov 2011 23:55:05 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 83E8E21F8B72; Mon, 7 Nov 2011 23:55:04 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUC00EXG0KTBP@szxga03-in.huawei.com>; Tue, 08 Nov 2011 15:53:18 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUC00KLN0K69B@szxga03-in.huawei.com>; Tue, 08 Nov 2011 15:53:17 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV09745; Tue, 08 Nov 2011 15:53:17 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 08 Nov 2011 15:53:14 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Tue, 08 Nov 2011 15:53:09 +0800 Date: Tue, 08 Nov 2011 07:53:09 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: X-Originating-IP: [10.108.4.59] To: "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cqqGcxB/wl2CapfjX1xEoA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAC+Spw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.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, 08 Nov 2011 07:55:06 -0000 --Boundary_(ID_cqqGcxB/wl2CapfjX1xEoA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgTmFiaWwsDQoNCkl0oa9zIGEgdmVyeSBjb21wcmVoZW5zaXZlIGRvYy4NCg0KU29tZSBjb21t b25zOg0KDQoxoaIgIEluIHNlY3Rpb24gNi4xLCBpdCBzYWlkOiChsEFzIHRoZSBudW1iZXIgb2Yg dGVuYW50cyBpbiBpbmRpdmlkdWFsIFZMQU4gaXNsYW5kcyBzdXJwYXNzZXMgNEssIHRoZSBvcGVy YXRvciBjb3VsZCBwdXNoIFZQTFMgZGVwbG95bWVudCBkZWVwZXIgaW4gdGhlIERDIG5ldHdvcmuh rS4gVGhlIFRvUiBhbmQgREMgY29yZSBlbGVtZW50cyBuZWVkIHRvIGJlIE1QTFMgZW5hYmxlZCB3 aXRoIGV4aXN0aW5nIFZQTFMgc29sdXRpb25zobEsIElNSE8sIERDIGNvcmUgc3dpdGNoZXMgZG9u oa90IG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHNpbmNlIElQIGJhc2VkIHR1bm5lbCBpcyBhbHNv IGF2YWlsYWJsZS4NCg0KMqGiICBTdGlsbCBpbiBzZWN0aW9uIDYuMSwgaXQgc2FpZDogobEgoa1I b3dldmVyLCB0aGlzIG1vZGVsIGRvZXMgbm90IHNvbHZlIHRoZSBNQUMgZXhwbG9zaW9uIGlzc3Vl IGFzIFRvUnMgc3RpbGwgbmVlZCB0byBsZWFybiBWTSBNQUMgYWRkcmVzc2VzLqGxIEhvd2V2ZXIs IGluIHNlY3Rpb24gNi4yLjEsIGl0IHNhaWQ6obGhrUFsdGVybmF0aXZlbHksIHRoZSBQQkIgZW5j YXBzdWxhdGlvbiBjYW4gYmUgZG9uZSBhdCB0aGUgVG9SLqGxICBJdCBpcyBjb25mdXNlZCBzaW5j ZSBwZXJmb3JtaW5nIFBCQiBlbmNhcHN1bGF0aW9uIGF0IHRoZSBUb1Igd291bGQgbm90IGFsbGV2 aWF0ZSB0aGUgTUFDLWxlYXJuaW5nIGJ1cmRlbiBvbiB0aGF0IFRvUi4NCg0KM6GiICBJbiA2LjIu Ni4yLiBQQkJOIGluIFZTdywgTDJWUE4gaW4gdGhlIFRvUiwgaXQgc2FpZDqhsSBUaGUgcHJvY2Vk dXJlcyBmcm9tIHRoZSBwcmV2aW91cyBzZWN0aW9uIGFyZSB1c2VkIGF0IHRoZSBWU3c6IFBCQiBl bmNhcHN1bGF0aW9uIGFuZCBFdGhlcm5ldCBCVkxBTnMgY2FuIGJlIHVzZWQgb24gdGhlIFZTdyB1 cGxpbmsuIEwyVlBOIGluZnJhc3RydWN0dXJlIGlzIHJlcGxhY2luZyB0aGUgQlZMQU4gYXQgdGhl IFRvUiBlbmFibGluZyB0aGUgdXNlIG9mIElQIChHUkUgb3IgTDJUUCkgb3IgTVBMUyB0dW5uZWxp bmcuICBMMiBuZXR3b3JraW5nIHN0aWxsIGhhcyB0aGUgc2FtZSBjb250cm9sIHBsYW5lIGNob2lj ZXM6IElTLUlTIFs4MDIuMWFxXSBhbmQvb3IgQkdQIFtQQkItRVZQTl0sIGluZGVwZW5kZW50bHkg ZnJvbSB0aGUgdHVubmVsaW5nIGNob2ljZS6hsSBTaW5jZSBQQkIgZW5jYXBzdWxhdGlvbiBoYXMg YWxyZWFkeSBiZWVuIGRvbmUgb24gdGhlIFZTdywgd2h5IGRvIHdlIHN0aWxsIG5lZWQgdG8gcnVu IDgwMi4xYXEgYW5kIFBCQi1FVlBOIHdpdGggYW5vdGhlciBQQkIgZW5jYXBzdWxhdGlvbiBsYXll cj8gQ2Fuoa90IHdlIHNpbXBseSB1c2UgYW55IEwyVlBOIHRlY2hub2xvZ3ksIGUuZy4sIFZQTFMu IEluIGFkZGl0aW9uLCBub3RlIHRoYXQgaW4gRmlndXJlIDUsIGl0IHNhaWQgobBpbnRyYS1EQyBM MlZQTiBvdmVyIElQIG9yIE1QTFMgdHVubmVsaW5nobEuDQoNCg0KQmVzdCByZWdhcmRzLA0KWGlh b2h1DQoNCreivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gQml0YXIsIE5hYmlsIE4NCreiy83KsbzkOiAyMDExxOoxMdTCOMjV IDEzOjQyDQrK1bz+yMs6IGwzdnBuQGlldGYub3JnOyBsMnZwbkBpZXRmLm9yZw0Ks63LzTogU2Fn ZXNzaTsgbWlyY2VhLnBpc2ljYUBidC5jb207IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5LmlrZWpp cmlAbnR0LmNvbQ0K1vfM4jogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFw cHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4 dA0KDQpIaSwNCldlIGhhZCBzdWJtaXR0ZWQgdGhlIGZvbGxvd2luZyBkcmFmdCBvbiB2cG4gYXBw bGljYWJpbGl0eSBmb3IgZGF0YSBjZW50ZXIuIFlvdXIgaW5wdXQgb24gdGhlIGRyYWZ0IGlzIGFw cHJlY2lhdGVkIGluIGxpZ2h0IG9mIHNvbWUgb2YgdGhlIG9uZ29pbmcgZGlzY3Vzc2lvbi4gVGhl IGRyYWZ0IGlzIHRhcmdldGVkIGZvciBsM3ZwbiBhbmQgbDJ2cG4uDQpIZXJlIGlzIHRoZSBsaW5r Og0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXRhci1kYXRhY2VudGVyLXZw bi1hcHBsaWNhYmlsaXR5LTAxDQoNCg0KQWJzdHJhY3QNCg0KDQoNCiAgIENsb3VkIENvbXB1dGlu ZyBoYXMgYmVlbiBhdHRyYWN0aW5nIGEgbG90IG9mIGF0dGVudGlvbiBmcm9tIHRoZQ0KDQogICBu ZXR3b3JraW5nIGluZHVzdHJ5LiBTb21lIG9mIHRoZSBtb3N0IHB1YmxpY2l6ZWQgcmVxdWlyZW1l bnRzIGFyZQ0KDQogICByZWxhdGVkIHRvIHRoZSBldm9sdXRpb24gb2YgdGhlIENsb3VkIE5ldHdv cmtpbmcgSW5mcmFzdHJ1Y3R1cmUgdG8NCg0KICAgYWNjb21tb2RhdGUgYSBsYXJnZSBudW1iZXIg b2YgdGVuYW50cywgZWZmaWNpZW50IG5ldHdvcmsgdXRpbGl6YXRpb24sDQoNCiAgIHNjYWxhYmxl IGxvb3AgYXZvaWRhbmNlLCBhbmQgVmlydHVhbCBNYWNoaW5lIE1vYmlsaXR5Lg0KDQoNCg0KICAg VGhpcyBkcmFmdCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgZm9yIGNsb3VkIG5ldHdvcmtpbmcsIGhp Z2hsaWdodGluZw0KDQogICB0aGUgYXBwbGljYWJpbGl0eSBvZiBleGlzdGluZyB3b3JrIGluIHZh cmlvdXMgSUVURiBXb3JraW5nIEdyb3Vwcw0KDQogICAoZS5nLiwgUkZDcyBhbmQgZHJhZnRzIGRl dmVsb3BlZCBpbiBJRVRGIEwyVlBOIGFuZCBMM1ZQTiBXb3JraW5nDQoNCiAgIEdyb3VwcykgdG8g Y2xvdWQgbmV0d29ya2luZywgYW5kIHRoZSBnYXBzIGFuZCBwcm9ibGVtcyB0aGF0IG5lZWQgdG8N Cg0KICAgYmUgZnVydGhlciBhZGRyZXNzZWQuIFRoYXQgaXMsIHRoZSBnb2FsIGlzIHRvIHVuZGVy c3RhbmQgd2hhdCBtYXkgYmUNCg0KICAgcmUtdXNlZCBmcm9tIHRoZSBjdXJyZW50IHByb3RvY29s cyBhbmQgY2FsbCBvdXQgcmVxdWlyZW1lbnRzIHNwZWNpZmljDQoNCiAgIHRvIHRoZSBDbG91ZCBz cGFjZSB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGJ5IG5ldyBzdGFuZGFyZGl6YXRpb24NCg0K ICAgd29yayB3aXRoIHByb3Bvc2VkIHNvbHV0aW9ucyBpbiBjZXJ0YWluIGNhc2VzLg0KDQoNClRo YW5rcywNCg0KTmFiaWwNCg== --Boundary_(ID_cqqGcxB/wl2CapfjX1xEoA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Nabil,<= o:p>

 = ;

It=A1=AFs = a very comprehensive doc.

 = ;

Some commo= ns:

1=A1=A2  In section 6.1, it said: =A1=B0As t=
he number of tenants in individual VLAN islands surpasses 4K, the operator =
could push VPLS deployment deeper in the DC network=A1=AD. The ToR and DC c=
ore elements need to be MPLS enabled with existing VPLS solutions=A1=B1, IM=
HO, DC core switches don=A1=AFt need to be MPLS enabled since IP based tunn=
el is also available.
2=A1=A2  Still in section 6.1, it said: =A1=
=B1 =A1=ADHowever, this model does not solve the MAC explosion issue as ToR=
s still need to learn VM MAC addresses.=A1=B1 However, in section 6.2.1, it=
 said:=A1=B1=A1=ADAlternatively, the PBB encapsulation can be done at the T=
oR.=A1=B1  It is confused since performing PBB encapsulation at the To=
R would not alleviate the MAC-learning burden on that ToR. 
3=A1=A2  In 6.2.=
6.2. PBBN in VSw, L2VPN in the ToR, it said:=A1=B1 The procedures fro=
m the previous section are used at the VSw: PBB encapsulation and Ethernet =
BVLANs can be used on the VSw uplink. L2VPN infrastructure is replacing the=
 BVLAN at the ToR enabling the use of IP (GRE or L2TP) or MPLS tunneling.&n=
bsp; L2 networking still has the same control plane choices: IS-IS [802.1aq=
] and/or BGP [PBB-EVPN], independently from the tunneling choice.=A1=B1 Sin=
ce PBB encapsulation has already been done on the VSw, why do we still need=
 to run 802.1aq and PBB-EVPN with another PBB encapsulation layer? Can=A1=
=AFt we simply use any L2VPN technology, e.g., VPLS. In addition, note that=
 in Figure 5, it said =A1=B0intra-DC L2VPN over IP or MPLS tunneling=A1=B1.=

=  

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: l2vpn-b= ounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA= =B1=ED Bitar, Nabil N
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5 13:42
=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com =D6=F7=CC=E2: Your input on the following draft is appreciated: draft-bitar-datacenter-= vpn-applicability-01.txt

 

Hi,

We had submi= tted the following draft on vpn applicability for data center. Your input o= n the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the = link: 

 <= /o:p>

 <= /o:p>

Abstract
 
   Cloud Computing has been attracting a=
 lot of attention from the
   networking industry. Some of the most=
 publicized requirements are
   related to the evolution of the Cloud=
 Networking Infrastructure to
   accommodate a large number of tenants=
, efficient network utilization,
   scalable loop avoidance, and Virtual =
Machine Mobility.
 
   This draft describes a framework for =
cloud networking, highlighting
   the applicability of existing work in=
 various IETF Working Groups
   (e.g., RFCs and drafts developed in I=
ETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the =
gaps and problems that need to
   be further addressed. That is, the go=
al is to understand what may be
   re-used from the current protocols an=
d call out requirements specific
   to the Cloud space that need to be ad=
dressed by new standardization
   work with proposed solutions in certa=
in cases.

 
Thanks,
Nabil
--Boundary_(ID_cqqGcxB/wl2CapfjX1xEoA)-- From xuxiaohu@huawei.com Tue Nov 8 01:41: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 0792F21F8CC5; Tue, 8 Nov 2011 01:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qppoG-hgNHou; Tue, 8 Nov 2011 01:41:58 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id AD92521F8CC4; Tue, 8 Nov 2011 01:41:57 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUC003HP5J7D2@szxga04-in.huawei.com>; Tue, 08 Nov 2011 17:40:19 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUC00CQP5J6V0@szxga04-in.huawei.com>; Tue, 08 Nov 2011 17:40:19 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEX20235; Tue, 08 Nov 2011 17:39:52 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 08 Nov 2011 17:39:21 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Tue, 08 Nov 2011 17:39:15 +0800 Date: Tue, 08 Nov 2011 09:39:14 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: X-Originating-IP: [10.108.4.59] To: "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7477A2@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ajcU9sdPc9Yi7uJ41c3fGA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAFQgBA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: LbQp RpvY VwYt WDYs XiTN aUgq awRA clfy jLbR kfYn lpGT qGQT sBNe u4HK 01Uu 1HGw; 7; bAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA7AG0AaQByAGMAZQBhAC4AcABpAHMAaQBjAGEAQABiAHQALgBjAG8AbQA7AG4AYQBiAGkAbAAuAG4ALgBiAGkAdABhAHIAQAB2AGUAcgBpAHoAbwBuAC4AYwBvAG0AOwBzAGEAagBhAHMAcwBpAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwB5AC4AaQBrAGUAagBpAHIAaQBAAG4AdAB0AC4AYwBvAG0A; Sosha1_v1; 7; {0532F2EF-C25D-480F-BF96-05B2C724DE96}; eAB1AHgAaQBhAG8AaAB1AEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Tue, 08 Nov 2011 09:53:11 GMT; cgBlADoAIABZAG8AdQByACAAaQBuAHAAdQB0ACAAbwBuACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGQAcgBhAGYAdAAgAGkAcwAgAGEAcABwAHIAZQBjAGkAYQB0AGUAZAA6AAkAZAByAGEAZgB0AC0AYgBpAHQAYQByAC0AZABhAHQAYQBjAGUAbgB0AGUAcgAtAHYAcABuAC0AYQBwAHAAbABpAGMAYQBiAGkAbABpAHQAeQAtADAAMQAuAHQAeAB0AA== x-cr-puzzleid: {0532F2EF-C25D-480F-BF96-05B2C724DE96} X-CFilter-Loop: Reflected References: Cc: Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.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, 08 Nov 2011 09:41:59 -0000 --Boundary_(ID_ajcU9sdPc9Yi7uJ41c3fGA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 DQoNCkhpLA0KDQpTb21lIGNvbW1lbnRzIGFib3V0IHBhdGggb3B0aW1pemF0aW9uOg0KDQoxo65J biBzZWN0aW9uIDUuNSwgIGl0IHNhaWQgobBJUC1iYXNlZCBmb3J3YXJkaW5nIHJlbGllcyBvbiB0 aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzc6GtSG93ZXZlciwgd2hlbiBWTXMsIGFzIElQIGhvc3Rz IGFjcm9zcyBsYXllcjIgdmlydHVhbA0KICAgZG9tYWlucywgbmVlZCB0byBjb21tdW5pY2F0ZSB0 aGV5IHJlbHkgb24gdGhlIHVuZGVybHlpbmcgSVAgcm91dGluZyBpbmZyYXN0cnVjdHVyZS6hsSAg Q291bGQgeW91IGV4cGxhaW4gbW9yZSBhYm91dCChsGxheWVyMiB2aXJ0dWFsIGRvbWFpbnOhsT8N Cg0KMi4gICBJbiBzZWN0aW9uIDUuNSwgaXQgc2FpZCChsG9wdGltYWxpdHkgaW4gdHJhZmZpYyBm b3J3YXJkaW5nIHRvIGEgVk0gd2lsbCByZXF1aXJlIHJlYWNoYWJpbGl0eSB0byB0aGUgVk0gaG9z dCBhZGRyZXNzIHJhdGhlciB0aGFuIG9ubHkgdGhlIHN1Ym5ldC6hsSBJTUhPLCBwcm9wYWdhdGlu ZyBob3N0IHJvdXRlcyBmb3IgVk1zIGlzIG9ubHkgdXNlZnVsIGZvciBvcHRpbWl6aW5nIHRoZSBw YXRoIGZvciBWUE4gYWNjZXNzLCByYXRoZXIgdGhhbiBmb3IgSW50ZXJuZXQgYWNjZXNzIHNpbmNl IHByb3BhZ2F0aW5nIGhvc3Qgcm91dGUgdG8gdGhlIEludGVybmV0IHdpbGwgZGFtYWdlIHRoZSBJ bnRlcm5ldCByb3V0aW5nIHNjYWxhYmlsaXR5IHNlcmlvdXNseS4gIFRvIG9wdGltaXplIHRoZSBw YXRoIGZvciBJbnRlcm5ldCBhY2Nlc3MsICBJTUhPLCBETlMtYmFzZWQgR0xTQiBpcyBhIG1vcmUg cHJhY3RpY2FsIGFwcHJvYWNoIGluc3RlYWQuIFdpdGggdGhpcyBhcHByb2FjaCwgc2luY2UgdGhl IGNvbm5lY3Rpb25zIGVzdGFibGlzaGVkIGJlZm9yZSB0aGUgVk0gbW92ZW1lbnQgdXNlIHRoZSBv bGQgTkFUZWQgYWRkcmVzcyBvZiB0aGUgVk0sIHRoZSBpbmJvdW5kIHRyYWZmaWMgb2YgdGhvc2Ug Y29ubmVjdGlvbnMgd2lsbCBzdGlsbCB0cmF2ZWwgdGhyb3VnaCB0aGUgb2xkIGdhdGV3YXkgd2hl cmUgdGhlIFZNIHVzZWQgdG8gYmUgYXR0YWNoZWQuIEl0oa9zIGVhc3kgZm9yIHRoZSBvbGQgZ2F0 ZXdheSB0byBmb3J3YXJkIHRoZSB0cmFmZmljIGZ1cnRoZXIgdG8gdGhlIG5ldyBsb2NhdGlvbi4g SG93ZXZlciwgdGhlIGhhcmQgaXNzdWUgaXMgaG93IHRvIGd1YXJhbnRlZSB0aGUgb3V0Ym91bmQg dHJhZmZpYyBvZiB0aG9zZSBjb25uZWN0aW9ucyB0cmF2ZWwgdGhyb3VnaCB0aGUgc2FtZSBnYXRl d2F5IGFzIHRoZSBpbmJvdW5kIHRyYWZmaWMgZG9lcyAoaS5lLiwgcGF0aCBzeW1tZXRyeSkgaW4g dGhlIHNjZW5hcmlvIHdoZXJlIHN0YXRlZnVsIGRldmljZXMgc3VjaCBhcyBOQVRzLCBmaXJld2Fs bHMgZXRjLiBhcmUgZGVwbG95ZWQgYXQgdGhlIERDIGV4aXRzLg0KDQpCZXN0IHJlZ2FyZHMsDQpY aWFvaHUNCg0Kt6K8/sjLOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBCaXRhciwgTmFiaWwgTg0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI4 yNUgMTM6NDINCsrVvP7IyzogbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQqzrcvNOiBT YWdlc3NpOyBtaXJjZWEucGlzaWNhQGJ0LmNvbTsgTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IHkuaWtl amlyaUBudHQuY29tDQrW98ziOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMg YXBwcmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEu dHh0DQoNCkhpLA0KV2UgaGFkIHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5nIGRyYWZ0IG9uIHZwbiBh cHBsaWNhYmlsaXR5IGZvciBkYXRhIGNlbnRlci4gWW91ciBpbnB1dCBvbiB0aGUgZHJhZnQgaXMg YXBwcmVjaWF0ZWQgaW4gbGlnaHQgb2Ygc29tZSBvZiB0aGUgb25nb2luZyBkaXNjdXNzaW9uLiBU aGUgZHJhZnQgaXMgdGFyZ2V0ZWQgZm9yIGwzdnBuIGFuZCBsMnZwbi4NCkhlcmUgaXMgdGhlIGxp bms6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpdGFyLWRhdGFjZW50ZXIt dnBuLWFwcGxpY2FiaWxpdHktMDENCg0KDQpBYnN0cmFjdA0KDQoNCg0KICAgQ2xvdWQgQ29tcHV0 aW5nIGhhcyBiZWVuIGF0dHJhY3RpbmcgYSBsb3Qgb2YgYXR0ZW50aW9uIGZyb20gdGhlDQoNCiAg IG5ldHdvcmtpbmcgaW5kdXN0cnkuIFNvbWUgb2YgdGhlIG1vc3QgcHVibGljaXplZCByZXF1aXJl bWVudHMgYXJlDQoNCiAgIHJlbGF0ZWQgdG8gdGhlIGV2b2x1dGlvbiBvZiB0aGUgQ2xvdWQgTmV0 d29ya2luZyBJbmZyYXN0cnVjdHVyZSB0bw0KDQogICBhY2NvbW1vZGF0ZSBhIGxhcmdlIG51bWJl ciBvZiB0ZW5hbnRzLCBlZmZpY2llbnQgbmV0d29yayB1dGlsaXphdGlvbiwNCg0KICAgc2NhbGFi bGUgbG9vcCBhdm9pZGFuY2UsIGFuZCBWaXJ0dWFsIE1hY2hpbmUgTW9iaWxpdHkuDQoNCg0KDQog ICBUaGlzIGRyYWZ0IGRlc2NyaWJlcyBhIGZyYW1ld29yayBmb3IgY2xvdWQgbmV0d29ya2luZywg aGlnaGxpZ2h0aW5nDQoNCiAgIHRoZSBhcHBsaWNhYmlsaXR5IG9mIGV4aXN0aW5nIHdvcmsgaW4g dmFyaW91cyBJRVRGIFdvcmtpbmcgR3JvdXBzDQoNCiAgIChlLmcuLCBSRkNzIGFuZCBkcmFmdHMg ZGV2ZWxvcGVkIGluIElFVEYgTDJWUE4gYW5kIEwzVlBOIFdvcmtpbmcNCg0KICAgR3JvdXBzKSB0 byBjbG91ZCBuZXR3b3JraW5nLCBhbmQgdGhlIGdhcHMgYW5kIHByb2JsZW1zIHRoYXQgbmVlZCB0 bw0KDQogICBiZSBmdXJ0aGVyIGFkZHJlc3NlZC4gVGhhdCBpcywgdGhlIGdvYWwgaXMgdG8gdW5k ZXJzdGFuZCB3aGF0IG1heSBiZQ0KDQogICByZS11c2VkIGZyb20gdGhlIGN1cnJlbnQgcHJvdG9j b2xzIGFuZCBjYWxsIG91dCByZXF1aXJlbWVudHMgc3BlY2lmaWMNCg0KICAgdG8gdGhlIENsb3Vk IHNwYWNlIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgYnkgbmV3IHN0YW5kYXJkaXphdGlvbg0K DQogICB3b3JrIHdpdGggcHJvcG9zZWQgc29sdXRpb25zIGluIGNlcnRhaW4gY2FzZXMuDQoNCg0K VGhhbmtzLA0KDQpOYWJpbA0K --Boundary_(ID_ajcU9sdPc9Yi7uJ41c3fGA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

 = ;

 = ;

Hi,

 = ;

Some comme= nts about path optimization:

 = ;

1=A3= =AEIn section 5.5,  it said =A1=B0IP-based forwarding relies on the destina= tion IP address=A1=ADHowever, when VMs, as IP hosts across layer2 virtual

 &nbs= p; domains, need to communicate they rely on the underlying IP routing infr= astructure.=A1=B1  Could you explain more about =A1=B0layer2 virtual d= omains=A1=B1?  

 = ;

2. &n= bsp; In section 5.5, it said =A1=B0optimality in traffic forwarding to a VM= will require reachability to the VM host address rather than only the subn= et.=A1=B1 IMHO, propagating host routes for VMs is only useful for optimizing the pa= th for VPN access, rather than for Internet access since propagating host r= oute to the Internet will damage the Internet routing scalability seriously= .  To optimize the path for Internet access,  IMHO, DNS-based GLSB is a more practical approach instead. W= ith this approach, since the connections established before the VM movement= use the old NATed address of the VM, the inbound traffic of those connecti= ons will still travel through the old gateway where the VM used to be attached. It=A1=AFs easy for the old gatew= ay to forward the traffic further to the new location. However, the hard is= sue is how to guarantee the outbound traffic of those connections travel th= rough the same gateway as the inbound traffic does (i.e., path symmetry) in the scenario where stateful devices = such as NATs, firewalls etc. are deployed at the DC exits.

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: l2vpn-b= ounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA= =B1=ED Bitar, Nabil N
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5 13:42
=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com =D6=F7=CC=E2: Your input on the following draft is appreciated: draft-bitar-datacenter-= vpn-applicability-01.txt

 

Hi,

We had submi= tted the following draft on vpn applicability for data center. Your input o= n the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the = link: 

 <= /o:p>

 <= /o:p>

Abstract
 
   Cloud Computing has been attracting a=
 lot of attention from the
   networking industry. Some of the most=
 publicized requirements are
   related to the evolution of the Cloud=
 Networking Infrastructure to
   accommodate a large number of tenants=
, efficient network utilization,
   scalable loop avoidance, and Virtual =
Machine Mobility.
 
   This draft describes a framework for =
cloud networking, highlighting
   the applicability of existing work in=
 various IETF Working Groups
   (e.g., RFCs and drafts developed in I=
ETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the =
gaps and problems that need to
   be further addressed. That is, the go=
al is to understand what may be
   re-used from the current protocols an=
d call out requirements specific
   to the Cloud space that need to be ad=
dressed by new standardization
   work with proposed solutions in certa=
in cases.

 
Thanks,
Nabil
--Boundary_(ID_ajcU9sdPc9Yi7uJ41c3fGA)-- From ben@niven-jenkins.co.uk Tue Nov 8 03:28: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 8756D21F8B72 for ; Tue, 8 Nov 2011 03:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.816 X-Spam-Level: X-Spam-Status: No, score=-102.816 tagged_above=-999 required=5 tests=[AWL=-0.417, 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 eHbvXg7GOjrn for ; Tue, 8 Nov 2011 03:28:26 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 9216221F8AE1 for ; Tue, 8 Nov 2011 03:28:26 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-125-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RNjqq-0005Mb-IM; Tue, 08 Nov 2011 11:28:25 +0000 Subject: Re: VPN4DC Scope Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <20111108023916.4DBB111E80D1@ietfa.amsl.com> Date: Tue, 8 Nov 2011 11:28:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111108023916.4DBB111E80D1@ietfa.amsl.com> To: robert@raszuk.net 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, 08 Nov 2011 11:28:27 -0000 This is not directed at Robert in particular, his e-mail just prompted = me to say it. On 8 Nov 2011, at 02:39, robert@raszuk.net wrote: > Hi, >=20 > Just to clarify one nit here. I am not saying to use vcider as is nor = I am saying that attaching a group of VM to your L3 VPN is a bad thing. >=20 > However what I am pointing out that scope of the VPN4DC should not = stop on just extending 2547. Rather then that standardizing vcider like = approach with supplements like uparcie or routing will serve to much = broader customer space. >=20 > So while extending l3vpn to the host is a neat idea and lets push it = forward in the same time let's not halt equally simple solutions which = can address the problem for many more real cases. The purpose of the VPN4DC session in Taipei and the on-going discussions = leading up to it is to gather feedback (& hopefully gain consensus) on: - Whether there is a real problem(s) in this space that needs solving? - Whether there is a common understanding of the scope of that = problem(s)? - Whether there are gaps that mean that problem(s) can not be solved = with existing technology? - Whether the IETF is the right place to address some or all of those = gaps? It seems to me that the problem space is potentially quite large with a = number of differing use cases & requirements and a varied range of = existing deployments which might drive very different solutions (be they = L2, L3, host based, network based etc.) depending on the subset of use = cases/requirements being addressed. It might help if folks consider the questions above when trying to = iterate towards some kind of consensus (for or against) on what is being = proposed and whether or not IETF is a suitable place to address any = technology gaps. Ben >=20 > Rgds, > R. >=20 > ----- Reply message ----- > From: "Derick Winkworth" > To: "l3vpn@ietf.org" > Subject: VPN4DC Scope > Date: Tue, Nov 8, 2011 11:25 am >=20 >=20 > Rob: >=20 > vCider does not provide for the secure interconnection of sites. It = is software that is installed on the VMs themselves which allows them to = talk to each other as if they were on the same VLAN on a switch = regardless of where the VMs exists. Typically these are public-cloud = provisioned VMs that are exposed to the internet. >=20 > In the context of VPN4DC, the customer could very well be running = vCider on the VMs in the Provider's DC but neither the provider nor the = customer should require software like this for attachment of the VM to = the customer's L3VPN (which this particular software would not do, BTW). = The goal, again, is not secure host-to-host connectivity (we really = shouldn't say that). I don't care what the VM is talking to per se. = The VMs' vNIC should be bound by path isolation to the VRF on the = provider's PE in the provider's Data Center. The customer only needs to = put an IP on the VM as far as the SP is concerned. Whatever the = customer does on top of that (IPSec or vCider) is up to the customer. >=20 >=20 > Derick >=20 >=20 >=20 >=20 >=20 > ________________________________ > From: Robert Raszuk > To: Luyuan Fang (lufang) > Cc: l3vpn@ietf.org > Sent: Monday, November 7, 2011 6:04 PM > Subject: Re: VPN4DC Scope >=20 > Hi Luyuan, >=20 > As we are getting down to the scope debate I think it would be quite=20= > productive to discuss one solution apparently already available for=20 > arbitrary secured interconnection of host or sites. >=20 > http://vcider.com/ >=20 > In particular I think it would be quite interesting to know what is=20 > missing from the above solution or this class of solutions in general=20= > for the problem space we are discussing here. >=20 > It seems to me that this class of solutions is sufficiently flexible = to=20 > address number of VPN4DC and beyond needs without any prerequisites = reg=20 > topology or connectivity requirements. >=20 > Many thx, > R. >=20 > > Dear colleagues, > > > > Thank you all for the constructive discussion/suggestions over the = last > > few weeks on VPN4DC. > > > > > > > > I think we observed good interests/enthusiasm on solving the = problems in > > this space.. > > > > > > > > We need to narrow down the scope as the next step. > > > > I summarized the proposals sent on the list as the following: > > > > > > > > 1. Leverage BGP/MPLS VPN technologies, extending it with l3vpn > > signaling protocols into DC VM virtual networks. > > > > 2. Using BGP/MPLS VPN exactly 'as it is' into DC VM virtual > > networks > > > > 3. Extending/creating any IP VPN technologies into DC > > > > 4. Extending/creating or reuse/managing security protocols for = DC > > connections, including encryption, key distribution, key management > > > > 5. Extending/creating or reuse L2VPN based technologies into DC > > > > > > > > Some of you prefer to focus on one of the options, while others like = to > > include multiple options. > > > > > > > > Here is my observation and thought. > > > > > > > > 1 - It seems a common denominator. Did not hear no on this. It is > > exactly the problem Derick wanting to solve, it is Ning's starting > > point, and it is included in the requirements drafts. > > > > 2 - It does not need to create or extend protocols, should go to > > Operation and Management Area for any ops issues and best practice. > > > > 3 - The scope looks big to me, the list is potentially very long. > > > > 4 - If new encryption algorithm, better key distribution mechanism = are > > needed, the work should go to Security Area; if nothing new, ops = issues > > go to Operation and Management Area. > > > > 5 - L2VPN for DC work should go to L2VPN WG, it is defined in L2VPN > > charter. > > > > > > > > Thanks, > > > > Luyuan > > > > From robert@raszuk.net Tue Nov 8 06:13: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 27A4221F8CB7 for ; Tue, 8 Nov 2011 06:13:38 -0800 (PST) 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 v4qrdRp4o7Xx for ; Tue, 8 Nov 2011 06:13:37 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 53CAC21F8CB4 for ; Tue, 8 Nov 2011 06:13:37 -0800 (PST) Received: (qmail 7086 invoked by uid 399); 8 Nov 2011 14:13:34 -0000 Received: from unknown (HELO ?10.0.1.3?) (220.110.142.114) by mail37.opentransfer.com with SMTP; 8 Nov 2011 14:13:34 -0000 Message-ID: <4EB9390E.6010903@raszuk.net> Date: Tue, 08 Nov 2011 15:13:34 +0100 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: Derick Winkworth Subject: Re: VPN4DC Scope References: <1320721789.80856.YahooMailNeo@web161806.mail.bf1.yahoo.com> In-Reply-To: <1320721789.80856.YahooMailNeo@web161806.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "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, 08 Nov 2011 14:13:38 -0000 Hi Derick, > --------- So while extending l3vpn to the host is a neat idea and > lets push it forward in the same time let's not halt equally simple > solutions which can address the problem for many more real cases. > --------- > > I'm not sure what you mean by "many more." If you are indicating > that the current scope of VPN4DC is too narrow and only addresses a > minority of cases, I would disagree. I think we do not need to argue if this is minority or majority which extending L3VPN to the host would address. However to do that you really do not need any new protocol extension. As you very well know you can install a software router (either public domain or from commercial vendors) in your DC host or TOR and treat it as fully functional PE. No changes to host OS/kernel needed. You configure VRFs of such software router and simply bridge to VMs virtual interfaces directly or via VLANs. Zero touch to VMs and your customers see their VMs as part of L3VPN service you are offering. So I really do not think we need to duplicate solutions to solve the already solved problem. I would rather see L3VPN or new group focusing more on problems which still need to be solved. And either online or offline I would be glad to hear why the above proposal would not address today your needs to extend L3VPN service to the data center you own and want to offer to your L3VPN customers. Best regards, R. From lucy.yong@huawei.com Tue Nov 8 09:48: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 B172011E80B3; Tue, 8 Nov 2011 09:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNSAF5cn3EPE; Tue, 8 Nov 2011 09:48:12 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id CCECE11E80CB; Tue, 8 Nov 2011 09:48:12 -0800 (PST) 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 <0LUC00181RQRMU@usaga02-in.huawei.com>; Tue, 08 Nov 2011 11:40:03 -0600 (CST) 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 <0LUC00EDURQRDF@usaga02-in.huawei.com>; Tue, 08 Nov 2011 11:40:03 -0600 (CST) 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, 08 Nov 2011 09:39:59 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Tue, 08 Nov 2011 09:39:53 -0800 Date: Tue, 08 Nov 2011 17:39:52 +0000 From: Lucy yong Subject: RE: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: X-Originating-IP: [10.47.146.243] To: "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <2691CE0099834E4A9C5044EEC662BB9D118E00D4@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vBvrhMipwuzr1ZzOQUpRkg)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAYBJpg X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: A9LN Dtqg HscH TN1Y VEuD bTnc hK+U szZg tYLv 659x 9Cme AAr8GA== AAyK1A== ABp8Tg== ACKOZQ== ADO+DA==; 7; bAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA7AG0AaQByAGMAZQBhAC4AcABpAHMAaQBjAGEAQABiAHQALgBjAG8AbQA7AG4AYQBiAGkAbAAuAG4ALgBiAGkAdABhAHIAQAB2AGUAcgBpAHoAbwBuAC4AYwBvAG0AOwBzAGEAagBhAHMAcwBpAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwB5AC4AaQBrAGUAagBpAHIAaQBAAG4AdAB0AC4AYwBvAG0A; Sosha1_v1; 7; {315816D8-2381-4DE2-894F-8D3771369BFA}; bAB1AGMAeQAuAHkAbwBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Tue, 08 Nov 2011 17:39:40 GMT; UgBFADoAIABZAG8AdQByACAAaQBuAHAAdQB0ACAAbwBuACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGQAcgBhAGYAdAAgAGkAcwAgAGEAcABwAHIAZQBjAGkAYQB0AGUAZAA6AAkAZAByAGEAZgB0AC0AYgBpAHQAYQByAC0AZABhAHQAYQBjAGUAbgB0AGUAcgAtAHYAcABuAC0AYQBwAHAAbABpAGMAYQBiAGkAbABpAHQAeQAtADAAMQAuAHQAeAB0AA== x-cr-puzzleid: {315816D8-2381-4DE2-894F-8D3771369BFA} References: Cc: Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.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, 08 Nov 2011 17:48:13 -0000 --Boundary_(ID_vBvrhMipwuzr1ZzOQUpRkg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Nabil and other co-authors, First of all, this is a very good draft to gather DC problem statements and explore VPN applicability for cloud networking. Good information for the community. Thank you very much. Some comments: 1) The document has heavy amount portion to describe all different use cases for PBB but few sentence for TRILL and L3VPN applicability in DC. Suggest to elaborate more on TRILL and L3VPN cases. 2) It is very possible that DC use L2VPN and WAN use L3VPN. It is nice that document this applicability. 3) Provider DC and enterprise DC may implement different L2VPN or L3VPN technologies, it is valuable to describe what kind of interworking scenarios is allowed or not allowed. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N Sent: Monday, November 07, 2011 11:42 PM To: l3vpn@ietf.org; l2vpn@ietf.org Cc: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com Subject: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Hi, We had submitted the following draft on vpn applicability for data center. Your input on the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn. Here is the link: http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 Abstract Cloud Computing has been attracting a lot of attention from the networking industry. Some of the most publicized requirements are related to the evolution of the Cloud Networking Infrastructure to accommodate a large number of tenants, efficient network utilization, scalable loop avoidance, and Virtual Machine Mobility. This draft describes a framework for cloud networking, highlighting the applicability of existing work in various IETF Working Groups (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working Groups) to cloud networking, and the gaps and problems that need to be further addressed. That is, the goal is to understand what may be re-used from the current protocols and call out requirements specific to the Cloud space that need to be addressed by new standardization work with proposed solutions in certain cases. Thanks, Nabil --Boundary_(ID_vBvrhMipwuzr1ZzOQUpRkg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Nabil  and other co-authors,

 

First of all, this is a very good draft to gather DC problem statements and explore VPN applicability for cloud networking.  Good information for the community. Thank you very much.

 

Some comments:

 

1)      The document has heavy amount portion to describe all different use cases for PBB but few sentence for TRILL and L3VPN applicability in DC. Suggest to elaborate more on TRILL and L3VPN cases.

2)      It is very possible that DC use L2VPN and WAN use L3VPN.  It is nice that document this applicability.

3)      Provider DC and enterprise DC may implement different L2VPN or L3VPN technologies, it is valuable to describe what kind of interworking scenarios is allowed or not allowed.

 

Best Regards,

Lucy

 

 

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N
Sent: Monday, November 07, 2011 11:42 PM
To: l3vpn@ietf.org; l2vpn@ietf.org
Cc: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com
Subject: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

 

Hi,

We had submitted the following draft on vpn applicability for data center. Your input on the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the link: 

 

 

Abstract
 
   Cloud Computing has been attracting a lot of attention from the
   networking industry. Some of the most publicized requirements are
   related to the evolution of the Cloud Networking Infrastructure to
   accommodate a large number of tenants, efficient network utilization,
   scalable loop avoidance, and Virtual Machine Mobility.
 
   This draft describes a framework for cloud networking, highlighting
   the applicability of existing work in various IETF Working Groups
   (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the gaps and problems that need to
   be further addressed. That is, the goal is to understand what may be
   re-used from the current protocols and call out requirements specific
   to the Cloud space that need to be addressed by new standardization
   work with proposed solutions in certain cases.

 
Thanks,
Nabil
--Boundary_(ID_vBvrhMipwuzr1ZzOQUpRkg)-- From nabil.n.bitar@verizon.com Tue Nov 8 12:19: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 F41A01F0C62; Tue, 8 Nov 2011 12:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.078, 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 EImih4yJ1brZ; Tue, 8 Nov 2011 12:19:06 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 170EC1F0C65; Tue, 8 Nov 2011 12:19:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 08 Nov 2011 20:18:50 +0000 From: "Bitar, Nabil N" To: Xuxiaohu , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" X-IronPort-AV: E=Sophos;i="4.69,478,1315180800"; d="scan'208,217";a="176108808" Received: from fldp1lumxc7hb02.verizon.com (HELO FLDP1LUMXC7HB02.us.one.verizon.com) ([166.68.75.85]) by fldsmtpi01.verizon.com with ESMTP; 08 Nov 2011 20:18:49 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.102]) by FLDP1LUMXC7HB02.us.one.verizon.com ([166.68.75.85]) with mapi; Tue, 8 Nov 2011 15:18:49 -0500 Date: Tue, 8 Nov 2011 15:18:48 -0500 Subject: Re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Index: AcyeU5+fYUMrNyT1Tce5gwm9rg/XnA== Message-ID: In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CADE5C802D069nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.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, 08 Nov 2011 20:19:10 -0000 --_000_CADE5C802D069nabilnbitarverizoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpUaGFua3MuIFBsZWFzZSBzZWUgaW5saW5lLg0KDQpUaGFua3MsDQpOYWJpbA0KDQpGcm9t OiBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNv bT4+DQpEYXRlOiBUdWUsIDggTm92IDIwMTEgMDI6NTM6MDkgLTA1MDANClRvOiAiQml0YXIsIE5h YmlsIE4iIDxuYWJpbC5uLmJpdGFyQG9uZS52ZXJpem9uLmNvbTxtYWlsdG86bmFiaWwubi5iaXRh ckBvbmUudmVyaXpvbi5jb20+PiwgImwzdnBuQGlldGYub3JnPG1haWx0bzpsM3ZwbkBpZXRmLm9y Zz4iIDxsM3ZwbkBpZXRmLm9yZzxtYWlsdG86bDN2cG5AaWV0Zi5vcmc+PiwgImwydnBuQGlldGYu b3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+Pg0KQ2M6IFNhZ2Vzc2kgPHNhamFzc2lAY2lzY28uY29tPG1haWx0bzpzYWphc3Np QGNpc2NvLmNvbT4+LCAibWlyY2VhLnBpc2ljYUBidC5jb208bWFpbHRvOm1pcmNlYS5waXNpY2FA YnQuY29tPiIgPG1pcmNlYS5waXNpY2FAYnQuY29tPG1haWx0bzptaXJjZWEucGlzaWNhQGJ0LmNv bT4+LCAiTHV5dWFuIEZhbmcgKGx1ZmFuZykiIDxsdWZhbmdAY2lzY28uY29tPG1haWx0bzpsdWZh bmdAY2lzY28uY29tPj4sICJ5LmlrZWppcmlAbnR0LmNvbTxtYWlsdG86eS5pa2VqaXJpQG50dC5j b20+IiA8eS5pa2VqaXJpQG50dC5jb208bWFpbHRvOnkuaWtlamlyaUBudHQuY29tPj4NClN1Ympl Y3Q6IHJlOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVjaWF0ZWQ6 IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0DQoNCkhpIE5h YmlsLA0KDQpJdOKAmXMgYSB2ZXJ5IGNvbXByZWhlbnNpdmUgZG9jLg0KDQoNClNvbWUgY29tbW9u czoNCg0KMeOAgSAgSW4gc2VjdGlvbiA2LjEsIGl0IHNhaWQ6IOKAnEFzIHRoZSBudW1iZXIgb2Yg dGVuYW50cyBpbiBpbmRpdmlkdWFsIFZMQU4gaXNsYW5kcyBzdXJwYXNzZXMgNEssIHRoZSBvcGVy YXRvciBjb3VsZCBwdXNoIFZQTFMgZGVwbG95bWVudCBkZWVwZXIgaW4gdGhlIERDIG5ldHdvcmvi gKYuIFRoZSBUb1IgYW5kIERDIGNvcmUgZWxlbWVudHMgbmVlZCB0byBiZSBNUExTIGVuYWJsZWQg d2l0aCBleGlzdGluZyBWUExTIHNvbHV0aW9uc+KAnSwgSU1ITywgREMgY29yZSBzd2l0Y2hlcyBk b27igJl0IG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHNpbmNlIElQIGJhc2VkIHR1bm5lbCBpcyBh bHNvIGF2YWlsYWJsZS4NCg0KPE5CPiBJdCBpcyBvbmUgc2NlbmFyaW8gYW5kIGl0IGlzIG9uZSBk ZXBsb3ltZW50IGNob2ljZS4NCg0KMuOAgSAgU3RpbGwgaW4gc2VjdGlvbiA2LjEsIGl0IHNhaWQ6 IOKAnSDigKZIb3dldmVyLCB0aGlzIG1vZGVsIGRvZXMgbm90IHNvbHZlIHRoZSBNQUMgZXhwbG9z aW9uIGlzc3VlIGFzIFRvUnMgc3RpbGwgbmVlZCB0byBsZWFybiBWTSBNQUMgYWRkcmVzc2VzLuKA nSBIb3dldmVyLCBpbiBzZWN0aW9uIDYuMi4xLCBpdCBzYWlkOuKAneKApkFsdGVybmF0aXZlbHks IHRoZSBQQkIgZW5jYXBzdWxhdGlvbiBjYW4gYmUgZG9uZSBhdCB0aGUgVG9SLuKAnSAgSXQgaXMg Y29uZnVzZWQgc2luY2UgcGVyZm9ybWluZyBQQkIgZW5jYXBzdWxhdGlvbiBhdCB0aGUgVG9SIHdv dWxkIG5vdCBhbGxldmlhdGUgdGhlIE1BQy1sZWFybmluZyBidXJkZW4gb24gdGhhdCBUb1IuDQoN ClNlY3Rpb24gMi4xLCB0byBoYW5kbGUgdGhlIE1BQyBzY2FsZSwgYW5kIGxldmlhdGluZyBWTSBN QUNzIGZyb20gVG9ycyBhbmQgY29yZSBzd2l0Y2hlcywgUEJCIHdvdWxkIHN0YXJ0IGF0IHRoZSBW c3cuIEhlcmUgaXMgdGhlIHRleHQ6DQoNCg0KDQoiSW4gYSBEQyBlbnZpcm9ubWVudCwgUEJCIG1h aW50YWlucyB0cmFkaXRpb25hbCBFdGhlcm5ldCBmb3J3YXJkaW5nDQogICBwbGFuZSBhbmQgb3Bl cmF0aW9uYWwgbW9kZWwuIEZvciBleGFtcGxlLCBhIFZTdyBpbXBsZW1lbnRhdGlvbiBvZiBQQkIN CiAgIGNhbiBtYWtlIHVzZSBvZiB0aGUgMjQgYml0IElTSUQgdGFnIGluc3RlYWQgb2YgdGhlIDEy IGJpdCBWTEFOIHRhZyB0bw0KICAgaWRlbnRpZnkgdGhlIHZpcnR1YWwgYnJpZGdpbmcgZG9tYWlu cyBhc3NvY2lhdGVkIHdpdGggZGlmZmVyZW50IFZNDQogICBncm91cHMuIFRoZSBWU3cgdXBsaW5r IHRvd2FyZHMgdGhlIFRvUiBpbiBGaWd1cmUgMSBjYW4gc3RpbGwgYmUNCiAgIHRyZWF0ZWQgYXMg YW4gRXRoZXJuZXQgYmFja2JvbmUgaW50ZXJmYWNlLiBBIGZyYW1lIG9yaWdpbmF0ZWQgYnkgYSBW TQ0KICAgY2FuIGJlIGVuY2Fwc3VsYXRlZCB3aXRoIHRoZSBJU0lEIGFzc2lnbmVkIHRvIHRoZSBW TSBWU3cgaW50ZXJmYWNlDQogICBhbmQgd2l0aCB0aGUgb3V0ZXIgREEgYW5kIFNBIE1BQ3MgYXNz b2NpYXRlZCB3aXRoIHRoZSByZXNwZWN0aXZlDQogICBkZXN0aW5hdGlvbiBhbmQgc291cmNlIHNl cnZlciBibGFkZXMsIGFuZCB0aGVuIHNlbnQgdG8gdGhlIFRvUg0KICAgU3dpdGNoLg0KDQoNCiAg IDxzbmFwPg0KDQoNCiJXaXRoIFBCQiBlbmNhcHN1bGF0aW9uLCBUb1JzIGFuZCBDb3JlIFNXcyBk byBub3QgaGF2ZSB0byBoYW5kbGUgVk0gTUFDIGFkZHJlc3NlcyBzbyB0aGUgc2l6ZSBvZiB0aGVp ciBNQUMgRklCIHRhYmxlcyBtYXkgZGVjcmVhc2UiDQoNCg0KDQoz44CBICBJbiA2LjIuNi4yLiBQ QkJOIGluIFZTdywgTDJWUE4gaW4gdGhlIFRvUiwgaXQgc2FpZDrigJ0gVGhlIHByb2NlZHVyZXMg ZnJvbSB0aGUgcHJldmlvdXMgc2VjdGlvbiBhcmUgdXNlZCBhdCB0aGUgVlN3OiBQQkIgZW5jYXBz dWxhdGlvbiBhbmQgRXRoZXJuZXQgQlZMQU5zIGNhbiBiZSB1c2VkIG9uIHRoZSBWU3cgdXBsaW5r LiBMMlZQTiBpbmZyYXN0cnVjdHVyZSBpcyByZXBsYWNpbmcgdGhlIEJWTEFOIGF0IHRoZSBUb1Ig ZW5hYmxpbmcgdGhlIHVzZSBvZiBJUCAoR1JFIG9yIEwyVFApIG9yIE1QTFMgdHVubmVsaW5nLiAg TDIgbmV0d29ya2luZyBzdGlsbCBoYXMgdGhlIHNhbWUgY29udHJvbCBwbGFuZSBjaG9pY2VzOiBJ Uy1JUyBbODAyLjFhcV0gYW5kL29yIEJHUCBbUEJCLUVWUE5dLCBpbmRlcGVuZGVudGx5IGZyb20g dGhlIHR1bm5lbGluZyBjaG9pY2Uu4oCdIFNpbmNlIFBCQiBlbmNhcHN1bGF0aW9uIGhhcyBhbHJl YWR5IGJlZW4gZG9uZSBvbiB0aGUgVlN3LCB3aHkgZG8gd2Ugc3RpbGwgbmVlZCB0byBydW4gODAy LjFhcSBhbmQgUEJCLUVWUE4gd2l0aCBhbm90aGVyIFBCQiBlbmNhcHN1bGF0aW9uIGxheWVyPyBD YW7igJl0IHdlIHNpbXBseSB1c2UgYW55IEwyVlBOIHRlY2hub2xvZ3ksIGUuZy4sIFZQTFMuIElu IGFkZGl0aW9uLCBub3RlIHRoYXQgaW4gRmlndXJlIDUsIGl0IHNhaWQg4oCcaW50cmEtREMgTDJW UE4gb3ZlciBJUCBvciBNUExTIHR1bm5lbGluZ+KAnS4NCg0KPE5CPiBJIGFncmVlIHdlIG5lZWQg dG8gbWFrZSB0aGlzIGNsZWFyZXIuIEhvd2V2ZXIsIFBCQi1FVlBOIGlzIHN0aWxsIGFwcGxpY2Fi bGUgZXNwZWNpYWxseSBpbiB0aGUgV0FOIGFzIGluZGljYXRlZCBhbmQgY2FuIGJlIGluIHRoZSBM QU4gYXMgaW5kaWNhdGVkLiA4MDIuMWFxIGlzIGxlc3Mgb2YgYW4gaXNzdWUgaW4gdGhpcyBzY2Vu YXJpbyBhcyBkZXBpY3RlZCBidXQgY2FuIGV4aXRlZCBpbiBvdGhlciBEY3Mvb3RoZXIgY3VzdG9t ZXIgc2l0ZXMgY29tbXVuaWNhdGluZyB0byB0aGUgZGVpY3RlZCBEQyBpcyBydW5uaW5nIG9yIGlm IHRoZXJlIGlzIGEgc2VnbWVudCBpbiB0aGUgc2FtZSBEQyBydW5uaW5nIDgwMi4xYXEgc2ltdWx0 YW5lb3VzbHkuDQoNCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCuWPkeS7tuS6ujogbDJ2cG4t Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzps MnZwbi1ib3VuY2VzQGlldGYub3JnXSDku6PooaggQml0YXIsIE5hYmlsIE4NCuWPkemAgeaXtumX tDogMjAxMeW5tDEx5pyIOOaXpSAxMzo0Mg0K5pS25Lu25Lq6OiBsM3ZwbkBpZXRmLm9yZzxtYWls dG86bDN2cG5AaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+ DQrmioTpgIE6IFNhZ2Vzc2k7IG1pcmNlYS5waXNpY2FAYnQuY29tPG1haWx0bzptaXJjZWEucGlz aWNhQGJ0LmNvbT47IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5LmlrZWppcmlAbnR0LmNvbTxtYWls dG86eS5pa2VqaXJpQG50dC5jb20+DQrkuLvpopg6IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2lu ZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBwbGlj YWJpbGl0eS0wMS50eHQNCg0KSGksDQpXZSBoYWQgc3VibWl0dGVkIHRoZSBmb2xsb3dpbmcgZHJh ZnQgb24gdnBuIGFwcGxpY2FiaWxpdHkgZm9yIGRhdGEgY2VudGVyLiBZb3VyIGlucHV0IG9uIHRo ZSBkcmFmdCBpcyBhcHByZWNpYXRlZCBpbiBsaWdodCBvZiBzb21lIG9mIHRoZSBvbmdvaW5nIGRp c2N1c3Npb24uIFRoZSBkcmFmdCBpcyB0YXJnZXRlZCBmb3IgbDN2cG4gYW5kIGwydnBuLg0KSGVy ZSBpcyB0aGUgbGluazoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYml0YXIt ZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0eS0wMQ0KDQoNCkFic3RyYWN0DQoNCg0KDQogICBD bG91ZCBDb21wdXRpbmcgaGFzIGJlZW4gYXR0cmFjdGluZyBhIGxvdCBvZiBhdHRlbnRpb24gZnJv bSB0aGUNCg0KICAgbmV0d29ya2luZyBpbmR1c3RyeS4gU29tZSBvZiB0aGUgbW9zdCBwdWJsaWNp emVkIHJlcXVpcmVtZW50cyBhcmUNCg0KICAgcmVsYXRlZCB0byB0aGUgZXZvbHV0aW9uIG9mIHRo ZSBDbG91ZCBOZXR3b3JraW5nIEluZnJhc3RydWN0dXJlIHRvDQoNCiAgIGFjY29tbW9kYXRlIGEg bGFyZ2UgbnVtYmVyIG9mIHRlbmFudHMsIGVmZmljaWVudCBuZXR3b3JrIHV0aWxpemF0aW9uLA0K DQogICBzY2FsYWJsZSBsb29wIGF2b2lkYW5jZSwgYW5kIFZpcnR1YWwgTWFjaGluZSBNb2JpbGl0 eS4NCg0KDQoNCiAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgZnJhbWV3b3JrIGZvciBjbG91ZCBu ZXR3b3JraW5nLCBoaWdobGlnaHRpbmcNCg0KICAgdGhlIGFwcGxpY2FiaWxpdHkgb2YgZXhpc3Rp bmcgd29yayBpbiB2YXJpb3VzIElFVEYgV29ya2luZyBHcm91cHMNCg0KICAgKGUuZy4sIFJGQ3Mg YW5kIGRyYWZ0cyBkZXZlbG9wZWQgaW4gSUVURiBMMlZQTiBhbmQgTDNWUE4gV29ya2luZw0KDQog ICBHcm91cHMpIHRvIGNsb3VkIG5ldHdvcmtpbmcsIGFuZCB0aGUgZ2FwcyBhbmQgcHJvYmxlbXMg dGhhdCBuZWVkIHRvDQoNCiAgIGJlIGZ1cnRoZXIgYWRkcmVzc2VkLiBUaGF0IGlzLCB0aGUgZ29h bCBpcyB0byB1bmRlcnN0YW5kIHdoYXQgbWF5IGJlDQoNCiAgIHJlLXVzZWQgZnJvbSB0aGUgY3Vy cmVudCBwcm90b2NvbHMgYW5kIGNhbGwgb3V0IHJlcXVpcmVtZW50cyBzcGVjaWZpYw0KDQogICB0 byB0aGUgQ2xvdWQgc3BhY2UgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZCBieSBuZXcgc3RhbmRh cmRpemF0aW9uDQoNCiAgIHdvcmsgd2l0aCBwcm9wb3NlZCBzb2x1dGlvbnMgaW4gY2VydGFpbiBj YXNlcy4NCg0KDQpUaGFua3MsDQoNCk5hYmlsDQo= --_000_CADE5C802D069nabilnbitarverizoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsgIj48ZGl2PkhpLDwvZGl2PjxkaXY+VGhhbmtzLiBQbGVhc2Ug c2VlIGlubGluZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyw8L2Rpdj48ZGl2Pk5h YmlsPC9kaXY+PGRpdj48YnI+PC9kaXY+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGln bjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47 IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRF Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+IFh1eGlhb2h1ICZsdDs8YSBocmVmPSJtYWlsdG86 eHV4aWFvaHVAaHVhd2VpLmNvbSI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+IFR1ZSwgOCBOb3YgMjAxMSAw Mjo1MzowOSAtMDUwMDxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh bj4gIkJpdGFyLCBOYWJpbCBOIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hYmlsLm4uYml0YXJAb25l LnZlcml6b24uY29tIj5uYWJpbC5uLmJpdGFyQG9uZS52ZXJpem9uLmNvbTwvYT4mZ3Q7LCAiPGEg aHJlZj0ibWFpbHRvOmwzdnBuQGlldGYub3JnIj5sM3ZwbkBpZXRmLm9yZzwvYT4iICZsdDs8YSBo cmVmPSJtYWlsdG86bDN2cG5AaWV0Zi5vcmciPmwzdnBuQGlldGYub3JnPC9hPiZndDssICI8YSBo cmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYub3JnPC9hPiIgJmx0OzxhIGhy ZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+Jmd0Ozxicj48c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4gU2FnZXNzaSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNhamFzc2lAY2lzY28uY29tIj5zYWphc3NpQGNpc2NvLmNvbTwvYT4mZ3Q7LCAi PGEgaHJlZj0ibWFpbHRvOm1pcmNlYS5waXNpY2FAYnQuY29tIj5taXJjZWEucGlzaWNhQGJ0LmNv bTwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86bWlyY2VhLnBpc2ljYUBidC5jb20iPm1pcmNlYS5w aXNpY2FAYnQuY29tPC9hPiZndDssICJMdXl1YW4gRmFuZyAobHVmYW5nKSIgJmx0OzxhIGhyZWY9 Im1haWx0bzpsdWZhbmdAY2lzY28uY29tIj5sdWZhbmdAY2lzY28uY29tPC9hPiZndDssICI8YSBo cmVmPSJtYWlsdG86eS5pa2VqaXJpQG50dC5jb20iPnkuaWtlamlyaUBudHQuY29tPC9hPiIgJmx0 OzxhIGhyZWY9Im1haWx0bzp5LmlrZWppcmlAbnR0LmNvbSI+eS5pa2VqaXJpQG50dC5jb208L2E+ Jmd0Ozxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPiBy ZTogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVkOiBkcmFm dC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dDxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4 bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93 d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+PG1ldGEgbmFtZT0iR2VuZXJhdG9y IiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwh LS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L 5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFu b3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1z cGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5IVE1MQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5oNTENCgl7bXNvLXN0eWxlLW5hbWU6aDUxOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 ODI1Nzk1NDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjIwMDc1MTYyIC0yMTI2OTk1NjI4IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6OTI1NjUyOTI0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoxNDAwNTY1NDA2IDE1MTAxMDM5OTQgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7 fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiUx44CBOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PGRpdiBsYW5nPSJaSC1DTiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDstd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZSI+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+SGkgTmFiaWwsPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyAiPkl0JiM4MjE3O3MgYSB2ZXJ5IGNvbXByZWhlbnNpdmUgZG9jLjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFuPjxkaXY+PGJyPjwvZGl2PjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+PGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t OnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48ZGl2IGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOy13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTstd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIj48 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDEwLjVwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+ U29tZSBjb21tb25zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXM7bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPjHjgIE8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlm XS0tPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5JbiBz ZWN0aW9uIDYuMSwgaXQgc2FpZDogJiM4MjIwO0FzIHRoZSBudW1iZXIgb2YgdGVuYW50cyBpbiBp bmRpdmlkdWFsIFZMQU4gaXNsYW5kcyBzdXJwYXNzZXMgNEssIHRoZSBvcGVyYXRvciBjb3VsZCBw dXNoIFZQTFMgZGVwbG95bWVudCBkZWVwZXIgaW4gdGhlIERDIG5ldHdvcmsmIzgyMzA7LiBUaGUg VG9SIGFuZCBEQyBjb3JlIGVsZW1lbnRzIG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHdpdGggZXhp c3RpbmcgVlBMUyBzb2x1dGlvbnMmIzgyMjE7LCBJTUhPLCBEQyBjb3JlIHN3aXRjaGVzIGRvbiYj ODIxNzt0IG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHNpbmNlIElQIGJhc2VkIHR1bm5lbCBpcyBh bHNvIGF2YWlsYWJsZS48L3NwYW4+PC9wcmU+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFuPjxkaXY+ Jmx0O05CJmd0OyBJdCBpcyBvbmUgc2NlbmFyaW8gYW5kIGl0IGlzIG9uZSBkZXBsb3ltZW50IGNo b2ljZS4mbmJzcDs8L2Rpdj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPjxkaXYgeG1s bnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0 bWw0MCI+PGRpdiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1s aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSI+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXM7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT48cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtwYWdl LWJyZWFrLWJlZm9yZTphbHdheXM7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhLS1baWYgIXN1 cHBvcnRMaXN0c10tLT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjLjgIE8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyA8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgIj5TdGlsbCBpbiBzZWN0aW9uIDYuMSwgaXQgc2FpZDogJiM4MjIx OyAmIzgyMzA7SG93ZXZlciwgdGhpcyBtb2RlbCBkb2VzIG5vdCBzb2x2ZSB0aGUgTUFDIGV4cGxv c2lvbiBpc3N1ZSBhcyBUb1JzIHN0aWxsIG5lZWQgdG8gbGVhcm4gVk0gTUFDIGFkZHJlc3Nlcy4m IzgyMjE7IEhvd2V2ZXIsIGluIHNlY3Rpb24gNi4yLjEsIGl0IHNhaWQ6JiM4MjIxOyYjODIzMDtB bHRlcm5hdGl2ZWx5LCB0aGUgUEJCIGVuY2Fwc3VsYXRpb24gY2FuIGJlIGRvbmUgYXQgdGhlIFRv Ui4mIzgyMjE7ICZuYnNwO0l0IGlzIGNvbmZ1c2VkIHNpbmNlIHBlcmZvcm1pbmcgUEJCIGVuY2Fw c3VsYXRpb24gYXQgdGhlIFRvUiB3b3VsZCBub3QgYWxsZXZpYXRlIHRoZSBNQUMtbGVhcm5pbmcg YnVyZGVuIG9uIHRoYXQgVG9SLiA8L3NwYW4+PC9wcmU+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFu PjxkaXY+PGJyPjwvZGl2PjxkaXY+U2VjdGlvbiAyLjEsIHRvIGhhbmRsZSB0aGUgTUFDIHNjYWxl LCBhbmQgbGV2aWF0aW5nIFZNIE1BQ3MgZnJvbSBUb3JzIGFuZCBjb3JlIHN3aXRjaGVzLCBQQkIg d291bGQgc3RhcnQgYXQgdGhlIFZzdy4gSGVyZSBpcyB0aGUgdGV4dDo8L2Rpdj48ZGl2PjxzcGFu IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxNnB4OyBmb250LWZh bWlseTogVGltZXM7ICI+PHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVt OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6 IGFsd2F5czsgIj4gICZuYnNwOzwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250 LXNpemU6IDFlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJl YWstYmVmb3JlOiBhbHdheXM7ICI+IkluIGEgREMgZW52aXJvbm1lbnQsIFBCQiBtYWludGFpbnMg dHJhZGl0aW9uYWwgRXRoZXJuZXQgZm9yd2FyZGluZw0KICAgcGxhbmUgYW5kIG9wZXJhdGlvbmFs IG1vZGVsLiBGb3IgZXhhbXBsZSwgYSBWU3cgaW1wbGVtZW50YXRpb24gb2YgUEJCDQogICBjYW4g bWFrZSB1c2Ugb2YgdGhlIDI0IGJpdCBJU0lEIHRhZyBpbnN0ZWFkIG9mIHRoZSAxMiBiaXQgVkxB TiB0YWcgdG8NCiAgIGlkZW50aWZ5IHRoZSB2aXJ0dWFsIGJyaWRnaW5nIGRvbWFpbnMgYXNzb2Np YXRlZCB3aXRoIGRpZmZlcmVudCBWTQ0KICAgZ3JvdXBzLiBUaGUgVlN3IHVwbGluayB0b3dhcmRz IHRoZSBUb1IgaW4gRmlndXJlIDEgY2FuIHN0aWxsIGJlDQogICB0cmVhdGVkIGFzIGFuIEV0aGVy bmV0IGJhY2tib25lIGludGVyZmFjZS4gQSBmcmFtZSBvcmlnaW5hdGVkIGJ5IGEgVk0NCiAgIGNh biBiZSBlbmNhcHN1bGF0ZWQgd2l0aCB0aGUgSVNJRCBhc3NpZ25lZCB0byB0aGUgVk0gVlN3IGlu dGVyZmFjZQ0KICAgYW5kIHdpdGggdGhlIG91dGVyIERBIGFuZCBTQSBNQUNzIGFzc29jaWF0ZWQg d2l0aCB0aGUgcmVzcGVjdGl2ZQ0KICAgZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzZXJ2ZXIgYmxh ZGVzLCBhbmQgdGhlbiBzZW50IHRvIHRoZSBUb1INCiAgIFN3aXRjaC48L3ByZT48cHJlIGNsYXNz PSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyAiPjxicj48L3ByZT48cHJl IGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsg bWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyAiPiAgICZsdDtz bmFwJmd0OzwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDFlbTsg bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBh bHdheXM7ICI+PGJyPjwvcHJlPjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIg c3R5bGU9ImZvbnQtc2l6ZTogMTZweDsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1pbHk6ICdD b3VyaWVyIE5ldyc7ICI+IldpdGggUEJCIGVuY2Fwc3VsYXRpb24sIFRvUnMgYW5kIENvcmUgU1dz IGRvIG5vdCBoYXZlIHRvIGhhbmRsZSBWTSA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxl LXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE2cHg7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFt aWx5OiAnQ291cmllciBOZXcnOyAiPiBNQUMgYWRkcmVzc2VzIHNvIHRoZSBzaXplIG9mIHRoZWly IE1BQyBGSUIgdGFibGVzIG1heSBkZWNyZWFzZSI8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXN0 eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE2cHg7IGZvbnQtZmFtaWx5OiBUaW1lczsgIj48 cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyAiPjxzcGFu IGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+CTwvc3Bhbj48 L3ByZT48L3NwYW4+PC9kaXY+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48ZGl2IHht bG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPjxkaXYgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UiPjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7cGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD48L286cD48L3NwYW4+PC9w cmU+PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7cGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IS0tW2lmICFz dXBwb3J0TGlzdHNdLS0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4z44CBPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7ICI+SW4gPGEgbmFtZT0ic2VjdGlvbi02LjIuNi4yIj42LjIuNi4y PC9hPi4gUEJCTiBpbiBWU3csIEwyVlBOIGluIHRoZSBUb1IsIGl0IHNhaWQ6JiM4MjIxOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7ICI+VGhlIHByb2NlZHVyZXMgZnJvbSB0aGUgcHJldmlvdXMgc2Vj dGlvbiBhcmUgdXNlZCBhdCB0aGUgVlN3OiBQQkIgZW5jYXBzdWxhdGlvbiBhbmQgRXRoZXJuZXQg QlZMQU5zIGNhbiBiZSB1c2VkIG9uIHRoZSBWU3cgdXBsaW5rLiBMMlZQTiBpbmZyYXN0cnVjdHVy ZSBpcyByZXBsYWNpbmcgdGhlIEJWTEFOIGF0IHRoZSBUb1IgZW5hYmxpbmcgdGhlIHVzZSBvZiBJ UCAoR1JFIG9yIEwyVFApIG9yIE1QTFMgdHVubmVsaW5nLiZuYnNwOyBMMiBuZXR3b3JraW5nIHN0 aWxsIGhhcyB0aGUgc2FtZSBjb250cm9sIHBsYW5lIGNob2ljZXM6IElTLUlTIFs4MDIuMWFxXSBh bmQvb3IgQkdQIFtQQkItRVZQTl0sIGluZGVwZW5kZW50bHkgZnJvbSB0aGUgdHVubmVsaW5nIGNo b2ljZS4mIzgyMjE7IFNpbmNlIFBCQiBlbmNhcHN1bGF0aW9uIGhhcyBhbHJlYWR5IGJlZW4gZG9u ZSBvbiB0aGUgVlN3LCB3aHkgZG8gd2Ugc3RpbGwgbmVlZCB0byBydW4gODAyLjFhcSBhbmQgUEJC LUVWUE4gd2l0aCBhbm90aGVyIFBCQiBlbmNhcHN1bGF0aW9uIGxheWVyPyBDYW4mIzgyMTc7dCB3 ZSBzaW1wbHkgdXNlIGFueSBMMlZQTiB0ZWNobm9sb2d5LCBlLmcuLCBWUExTLiBJbiBhZGRpdGlv biwgbm90ZSB0aGF0IGluIEZpZ3VyZSA1LCBpdCBzYWlkICYjODIyMDtpbnRyYS1EQyBMMlZQTiBv dmVyIElQIG9yIE1QTFMgdHVubmVsaW5nJiM4MjIxOy48L3NwYW4+PC9wcmU+PC9kaXY+PC9kaXY+ PC9kaXY+PC9zcGFuPjxkaXY+Jmx0O05CJmd0OyBJIGFncmVlIHdlIG5lZWQgdG8gbWFrZSB0aGlz IGNsZWFyZXIuIEhvd2V2ZXIsIFBCQi1FVlBOIGlzIHN0aWxsIGFwcGxpY2FibGUgZXNwZWNpYWxs eSBpbiB0aGUgV0FOIGFzIGluZGljYXRlZCBhbmQgY2FuIGJlIGluIHRoZSBMQU4gYXMgaW5kaWNh dGVkLiA4MDIuMWFxIGlzIGxlc3Mgb2YgYW4gaXNzdWUgaW4gdGhpcyBzY2VuYXJpbyBhcyBkZXBp Y3RlZCBidXQgY2FuIGV4aXRlZCBpbiBvdGhlciBEY3Mvb3RoZXIgY3VzdG9tZXIgc2l0ZXMgY29t bXVuaWNhdGluZyB0byB0aGUgZGVpY3RlZCBEQyBpcyBydW5uaW5nIG9yIGlmIHRoZXJlIGlzIGEg c2VnbWVudCBpbiB0aGUgc2FtZSBEQyBydW5uaW5nIDgwMi4xYXEgc2ltdWx0YW5lb3VzbHkuPC9k aXY+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48ZGl2IHhtbG5zOnY9InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl OndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQv MTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPjxkaXYgbGFu Zz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2UiPjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+PHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7cGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNt Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5CZXN0IHJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5YaWFvaHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPjxkaXY+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R5Lu2 5Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4gPGEgaHJlZj0i bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmciPmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ IFs8YSBocmVmPSJtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+Qml0YXIsIE5h YmlsIE48YnI+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OuWui+S9kyI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk65a6L5L2TIj4gMjAxMTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTrlrovkvZMiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMTwvc3Bhbj7mnIg8c3BhbiBs YW5nPSJFTi1VUyI+ODwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMTM6NDI8YnI+PC9z cGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IDxhIGhyZWY9Im1haWx0bzpsM3ZwbkBpZXRmLm9yZyI+bDN2cG5AaWV0Zi5vcmc8 L2E+OyA8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYub3JnPC9hPjxi cj48L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gU2FnZXNzaTsgPGEgaHJlZj0ibWFpbHRvOm1pcmNlYS5waXNpY2FAYnQuY29t Ij5taXJjZWEucGlzaWNhQGJ0LmNvbTwvYT47IEx1eXVhbiBGYW5nIChsdWZhbmcpOyA8YSBocmVm PSJtYWlsdG86eS5pa2VqaXJpQG50dC5jb20iPnkuaWtlamlyaUBudHQuY29tPC9hPjxicj48L3Nw YW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4gWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVkOiBk cmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNv bG9yOiBibGFjazsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+SGksPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgY29sb3I6IGJsYWNrOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5XZSBoYWQgc3VibWl0dGVkIHRoZSBmb2xsb3dp bmcgZHJhZnQgb24gdnBuIGFwcGxpY2FiaWxpdHkgZm9yIGRhdGEgY2VudGVyLiBZb3VyIGlucHV0 IG9uIHRoZSBkcmFmdCBpcyBhcHByZWNpYXRlZCBpbiBsaWdodCBvZiBzb21lIG9mIHRoZSBvbmdv aW5nDQogZGlzY3Vzc2lvbi4gVGhlIGRyYWZ0IGlzIHRhcmdldGVkIGZvciBsM3ZwbiBhbmQgbDJ2 cG4uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgY29sb3I6IGJsYWNr OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5IZXJlIGlzIHRoZSBsaW5rOiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiBibGFj azsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgY29sb3I6IGJsYWNrOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5 LTAxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiBi bGFjazsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkFic3RyYWN0PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQ2xvdWQgQ29tcHV0aW5nIGhh cyBiZWVuIGF0dHJhY3RpbmcgYSBsb3Qgb2YgYXR0ZW50aW9uIGZyb20gdGhlPG86cD48L286cD48 L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBuZXR3b3JraW5nIGluZHVzdHJ5LiBTb21lIG9mIHRoZSBtb3N0IHB1YmxpY2l6ZWQgcmVx dWlyZW1lbnRzIGFyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVsYXRlZCB0byB0aGUgZXZvbHV0aW9uIG9m IHRoZSBDbG91ZCBOZXR3b3JraW5nIEluZnJhc3RydWN0dXJlIHRvPG86cD48L286cD48L3NwYW4+ PC9wcmU+PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBh Y2NvbW1vZGF0ZSBhIGxhcmdlIG51bWJlciBvZiB0ZW5hbnRzLCBlZmZpY2llbnQgbmV0d29yayB1 dGlsaXphdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHNjYWxhYmxlIGxvb3AgYXZvaWRhbmNlLCBhbmQg VmlydHVhbCBNYWNoaW5lIE1vYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT48cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoaXMg ZHJhZnQgZGVzY3JpYmVzIGEgZnJhbWV3b3JrIGZvciBjbG91ZCBuZXR3b3JraW5nLCBoaWdobGln aHRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoZSBhcHBsaWNhYmlsaXR5IG9mIGV4aXN0aW5nIHdvcmsg aW4gdmFyaW91cyBJRVRGIFdvcmtpbmcgR3JvdXBzPG86cD48L286cD48L3NwYW4+PC9wcmU+PHBy ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAoZS5nLiwgUkZD cyBhbmQgZHJhZnRzIGRldmVsb3BlZCBpbiBJRVRGIEwyVlBOIGFuZCBMM1ZQTiBXb3JraW5nPG86 cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBHcm91cHMpIHRvIGNsb3VkIG5ldHdvcmtpbmcsIGFuZCB0aGUgZ2FwcyBh bmQgcHJvYmxlbXMgdGhhdCBuZWVkIHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBiZSBmdXJ0aGVyIGFkZHJl c3NlZC4gVGhhdCBpcywgdGhlIGdvYWwgaXMgdG8gdW5kZXJzdGFuZCB3aGF0IG1heSBiZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgcmUtdXNlZCBmcm9tIHRoZSBjdXJyZW50IHByb3RvY29scyBhbmQgY2FsbCBv dXQgcmVxdWlyZW1lbnRzIHNwZWNpZmljPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0byB0aGUgQ2xvdWQgc3Bh Y2UgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZCBieSBuZXcgc3RhbmRhcmRpemF0aW9uPG86cD48 L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyB3b3JrIHdpdGggcHJvcG9zZWQgc29sdXRpb25zIGluIGNlcnRhaW4gY2FzZXMu PG86cD48L286cD48L3NwYW4+PC9wcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDEycHQ7IGNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PGJy IGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjwvc3Bhbj48cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5OYWJpbDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjwvc3Bhbj48L2Jv ZHk+PC9odG1sPg0K --_000_CADE5C802D069nabilnbitarverizoncom_-- From florin.balus@alcatel-lucent.com Tue Nov 8 13:34: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 30D6D11E80B1; Tue, 8 Nov 2011 13:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[AWL=-2.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDoJaWIN+Y3S; Tue, 8 Nov 2011 13:34:33 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id E93F611E80AD; Tue, 8 Nov 2011 13:34:32 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pA8LYJlu007812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Nov 2011 15:34:19 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA8LYH57002179 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Nov 2011 15:34:18 -0600 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 8 Nov 2011 15:34:18 -0600 From: "Balus, Florin Stelian (Florin)" To: Xuxiaohu , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Date: Tue, 8 Nov 2011 15:34:10 -0600 Subject: RE: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAC+SpwABxhHfA= Message-ID: <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2073A6C5467C99478898544C6EBA3F4602BD5D2CF4USNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "y.ikejiri@ntt.com" , Sagessi , "mircea.pisica@bt.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, 08 Nov 2011 21:34:34 -0000 --_000_2073A6C5467C99478898544C6EBA3F4602BD5D2CF4USNAVSXCHMBSC_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHNlZSBpbi1saW5loa0NCg0KRnJvbTogbDJ2cG4tYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBYdXhpYW9odQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwNywgMjAxMSAxMTo1MyBQTQ0KVG86 IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCkNjOiBMdXl1 YW4gRmFuZyAobHVmYW5nKTsgU2FnZXNzaTsgeS5pa2VqaXJpQG50dC5jb207IG1pcmNlYS5waXNp Y2FAYnQuY29tDQpTdWJqZWN0OiByZTogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0 IGlzIGFwcHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5 LTAxLnR4dA0KDQpIaSBOYWJpbCwNCg0KSXShr3MgYSB2ZXJ5IGNvbXByZWhlbnNpdmUgZG9jLg0K DQpTb21lIGNvbW1vbnM6DQoNCjGhoiAgSW4gc2VjdGlvbiA2LjEsIGl0IHNhaWQ6IKGwQXMgdGhl IG51bWJlciBvZiB0ZW5hbnRzIGluIGluZGl2aWR1YWwgVkxBTiBpc2xhbmRzIHN1cnBhc3NlcyA0 SywgdGhlIG9wZXJhdG9yIGNvdWxkIHB1c2ggVlBMUyBkZXBsb3ltZW50IGRlZXBlciBpbiB0aGUg REMgbmV0d29ya6GtLiBUaGUgVG9SIGFuZCBEQyBjb3JlIGVsZW1lbnRzIG5lZWQgdG8gYmUgTVBM UyBlbmFibGVkIHdpdGggZXhpc3RpbmcgVlBMUyBzb2x1dGlvbnOhsSwgSU1ITywgREMgY29yZSBz d2l0Y2hlcyBkb26hr3QgbmVlZCB0byBiZSBNUExTIGVuYWJsZWQgc2luY2UgSVAgYmFzZWQgdHVu bmVsIGlzIGFsc28gYXZhaWxhYmxlLg0KDQoNCg0KRkI+IFlvdSBhcmUgcmlnaHQgd2Ugc2hvdWxk IGhhdmUgc2FpZCChsElQIG9yIE1QTFMgZW5hYmxlZKGxIGFzIGJvdGggY2FzZXMgYXJlIHBvc3Np Ymxloa0NCg0KDQoNCjKhoiAgU3RpbGwgaW4gc2VjdGlvbiA2LjEsIGl0IHNhaWQ6IKGxIKGtSG93 ZXZlciwgdGhpcyBtb2RlbCBkb2VzIG5vdCBzb2x2ZSB0aGUgTUFDIGV4cGxvc2lvbiBpc3N1ZSBh cyBUb1JzIHN0aWxsIG5lZWQgdG8gbGVhcm4gVk0gTUFDIGFkZHJlc3Nlcy6hsSBIb3dldmVyLCBp biBzZWN0aW9uIDYuMi4xLCBpdCBzYWlkOqGxoa1BbHRlcm5hdGl2ZWx5LCB0aGUgUEJCIGVuY2Fw c3VsYXRpb24gY2FuIGJlIGRvbmUgYXQgdGhlIFRvUi6hsSAgSXQgaXMgY29uZnVzZWQgc2luY2Ug cGVyZm9ybWluZyBQQkIgZW5jYXBzdWxhdGlvbiBhdCB0aGUgVG9SIHdvdWxkIG5vdCBhbGxldmlh dGUgdGhlIE1BQy1sZWFybmluZyBidXJkZW4gb24gdGhhdCBUb1IuDQoNCg0KDQpGQj4gTWF5YmUg dGhlIHBocmFzZSBsb2NhdGlvbiBpcyBwdXp6bGluZy4gVGhlIGZvY3VzIG9mIHNlY3Rpb24gNi4y IGlzIHRoZSB1c2Ugb2YgYW4gZXh0ZW5kZWQgMjRiIFBCQiBJLUlTSUQgdGFnIHN0YXJ0aW5nIGF0 IHRoZSBWU3cgdG8gaWRlbnRpZnkgdGhlIEVMQU4gYnJvYWRjYXN0IGRvbWFpbi4NCg0KVGhpcyB3 aWxsIG1heGltaXplIHRoZSBiZW5lZml0cy4gSG93ZXZlciBpbiByZWFsaXR5IGl0IGlzIHZlcnkg bGlrZWx5IHRoZXJlIHdpbGwgYmUgbGVnYWN5IERDIHJlZ2lvbnMgc3RpbGwgcnVubmluZyBWTEFO cyB3aGljaCByZXF1aXJlIGEgR2F0ZXdheSBmdW5jdGlvbiBkdXJpbmcgdGhlIG1pZ3JhdGlvbi4g U2VlIHRoZSBWTEFOIEludGVyb3AgZGlzY3Vzc2lvbiBpbiBzZWN0aW9uIDYuMi45Lg0KDQoNCg0K M6GiICBJbiA2LjIuNi4yLiBQQkJOIGluIFZTdywgTDJWUE4gaW4gdGhlIFRvUiwgaXQgc2FpZDqh sSBUaGUgcHJvY2VkdXJlcyBmcm9tIHRoZSBwcmV2aW91cyBzZWN0aW9uIGFyZSB1c2VkIGF0IHRo ZSBWU3c6IFBCQiBlbmNhcHN1bGF0aW9uIGFuZCBFdGhlcm5ldCBCVkxBTnMgY2FuIGJlIHVzZWQg b24gdGhlIFZTdyB1cGxpbmsuIEwyVlBOIGluZnJhc3RydWN0dXJlIGlzIHJlcGxhY2luZyB0aGUg QlZMQU4gYXQgdGhlIFRvUiBlbmFibGluZyB0aGUgdXNlIG9mIElQIChHUkUgb3IgTDJUUCkgb3Ig TVBMUyB0dW5uZWxpbmcuDQoNCg0KDQpGQj4gVGhpcyBpcyBhYm91dCB0aGUgdHVubmVsaW5nIGVu Y2Fwc3VsYXRpb24gb3B0aW9ucyB0byBiZSB1c2VkIGluIHRoZSBjb3JlOiAyNGIgSS1TSUQgdGFn IGlzIHRoZSBjb21tb24gdGVuYW50IElEIHdoaWNoIGNhbiBiZSB0cmFuc3BvcnRlZCBvdmVyIGFu IEV0aGVybmV0IG9yIGFuIElQIG9yIGFuIE1QTFMgYmFzZWQgREMgbmV0d29yay4gQ29tYmluYXRp b25zIG9mIHRoZXNlIHR1bm5lbGluZyBvcHRpb25zIGFyZSBhbHNvIHBvc3NpYmxlOiBlLmcuIG9u ZSBEQyBtYXkgYmUgRXRoZXJuZXQgYmFzZWQgdGhlIG90aGVyIElQIGJhc2VkOyBvciB0aGUgVlN3 IG1heSB1c2UgRXRoZXJuZXQgVkxBTiB0dW5uZWxzIHdoaWxlIElQIHR1bm5lbHMgbWF5IHN0YXJ0 IGF0IHRoZSBUb1IuDQoNCg0KDQogTDIgbmV0d29ya2luZyBzdGlsbCBoYXMgdGhlIHNhbWUgY29u dHJvbCBwbGFuZSBjaG9pY2VzOiBJUy1JUyBbODAyLjFhcV0gYW5kL29yIEJHUCBbUEJCLUVWUE5d LCBpbmRlcGVuZGVudGx5IGZyb20gdGhlIHR1bm5lbGluZyBjaG9pY2UuobEgU2luY2UgUEJCIGVu Y2Fwc3VsYXRpb24gaGFzIGFscmVhZHkgYmVlbiBkb25lIG9uIHRoZSBWU3csIHdoeSBkbyB3ZSBz dGlsbCBuZWVkIHRvIHJ1biA4MDIuMWFxIGFuZCBQQkItRVZQTiB3aXRoIGFub3RoZXIgUEJCIGVu Y2Fwc3VsYXRpb24gbGF5ZXI/DQoNCg0KDQpGQj4gTm8gbmVlZCBmb3IgYW4gYWRkaXRpb25hbCBQ QkIgZW5jYXBzdWxhdGlvbiBsYXllciEgVGhpcyBpcyBzdHJpY3RseSBhYm91dCBjb250cm9sIHBs YW5lIG9wdGlvbnM6IElTLUlTIGFuZCBCR1AgYXJlIHVzZWQgdGhlIHNhbWUgd2F5IGFzIGluIHJl Z3VsYXIgSVAgcm91dGluZyB0byBwZXJmb3JtIE11bHRpcGF0aGluZywgRmFzdCBDb252ZXJnZW5j ZSwgc2VydmljZSBBRCwgcHJvZ3JhbSB0aGUgY29yZSBGSUJzIGV0Y6GtDQoNCg0KDQogQ2Fuoa90 IHdlIHNpbXBseSB1c2UgYW55IEwyVlBOIHRlY2hub2xvZ3ksIGUuZy4sIFZQTFMuIEluIGFkZGl0 aW9uLCBub3RlIHRoYXQgaW4gRmlndXJlIDUsIGl0IHNhaWQgobBpbnRyYS1EQyBMMlZQTiBvdmVy IElQIG9yIE1QTFMgdHVubmVsaW5nobEuDQoNCg0KRkI+IHllcyB5b3UgY2FuLiBXZSBqdXN0IGZv Y3VzZWQgaGVyZSBvbiB0aGUgb3B0aW9ucyB0aGF0IHdpbGwgYWRkcmVzcyB0aGUgY2hhbGxlbmdl cyBkZXNjcmliZWQgaW4gdGhlIHByb2JsZW0gc3RhdGVtZW50IHNlY3Rpb24uIE90aGVyd2lzZSB0 aGUgY29udGVudCB3aWxsIGhhdmUgZ3Jvd24gdG9vIG11Y2guDQoNCg0KQmVzdCByZWdhcmRzLA0K WGlhb2h1DQoNCreivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gQml0YXIsIE5hYmlsIE4NCreiy83KsbzkOiAyMDExxOoxMdTC OMjVIDEzOjQyDQrK1bz+yMs6IGwzdnBuQGlldGYub3JnOyBsMnZwbkBpZXRmLm9yZw0Ks63LzTog U2FnZXNzaTsgbWlyY2VhLnBpc2ljYUBidC5jb207IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5Lmlr ZWppcmlAbnR0LmNvbQ0K1vfM4jogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlz IGFwcHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAx LnR4dA0KDQpIaSwNCldlIGhhZCBzdWJtaXR0ZWQgdGhlIGZvbGxvd2luZyBkcmFmdCBvbiB2cG4g YXBwbGljYWJpbGl0eSBmb3IgZGF0YSBjZW50ZXIuIFlvdXIgaW5wdXQgb24gdGhlIGRyYWZ0IGlz IGFwcHJlY2lhdGVkIGluIGxpZ2h0IG9mIHNvbWUgb2YgdGhlIG9uZ29pbmcgZGlzY3Vzc2lvbi4g VGhlIGRyYWZ0IGlzIHRhcmdldGVkIGZvciBsM3ZwbiBhbmQgbDJ2cG4uDQpIZXJlIGlzIHRoZSBs aW5rOg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXRhci1kYXRhY2VudGVy LXZwbi1hcHBsaWNhYmlsaXR5LTAxDQoNCg0KQWJzdHJhY3QNCg0KDQoNCiAgIENsb3VkIENvbXB1 dGluZyBoYXMgYmVlbiBhdHRyYWN0aW5nIGEgbG90IG9mIGF0dGVudGlvbiBmcm9tIHRoZQ0KDQog ICBuZXR3b3JraW5nIGluZHVzdHJ5LiBTb21lIG9mIHRoZSBtb3N0IHB1YmxpY2l6ZWQgcmVxdWly ZW1lbnRzIGFyZQ0KDQogICByZWxhdGVkIHRvIHRoZSBldm9sdXRpb24gb2YgdGhlIENsb3VkIE5l dHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUgdG8NCg0KICAgYWNjb21tb2RhdGUgYSBsYXJnZSBudW1i ZXIgb2YgdGVuYW50cywgZWZmaWNpZW50IG5ldHdvcmsgdXRpbGl6YXRpb24sDQoNCiAgIHNjYWxh YmxlIGxvb3AgYXZvaWRhbmNlLCBhbmQgVmlydHVhbCBNYWNoaW5lIE1vYmlsaXR5Lg0KDQoNCg0K ICAgVGhpcyBkcmFmdCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgZm9yIGNsb3VkIG5ldHdvcmtpbmcs IGhpZ2hsaWdodGluZw0KDQogICB0aGUgYXBwbGljYWJpbGl0eSBvZiBleGlzdGluZyB3b3JrIGlu IHZhcmlvdXMgSUVURiBXb3JraW5nIEdyb3Vwcw0KDQogICAoZS5nLiwgUkZDcyBhbmQgZHJhZnRz IGRldmVsb3BlZCBpbiBJRVRGIEwyVlBOIGFuZCBMM1ZQTiBXb3JraW5nDQoNCiAgIEdyb3Vwcykg dG8gY2xvdWQgbmV0d29ya2luZywgYW5kIHRoZSBnYXBzIGFuZCBwcm9ibGVtcyB0aGF0IG5lZWQg dG8NCg0KICAgYmUgZnVydGhlciBhZGRyZXNzZWQuIFRoYXQgaXMsIHRoZSBnb2FsIGlzIHRvIHVu ZGVyc3RhbmQgd2hhdCBtYXkgYmUNCg0KICAgcmUtdXNlZCBmcm9tIHRoZSBjdXJyZW50IHByb3Rv Y29scyBhbmQgY2FsbCBvdXQgcmVxdWlyZW1lbnRzIHNwZWNpZmljDQoNCiAgIHRvIHRoZSBDbG91 ZCBzcGFjZSB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGJ5IG5ldyBzdGFuZGFyZGl6YXRpb24N Cg0KICAgd29yayB3aXRoIHByb3Bvc2VkIHNvbHV0aW9ucyBpbiBjZXJ0YWluIGNhc2VzLg0KDQoN ClRoYW5rcywNCg0KTmFiaWwNCg== --_000_2073A6C5467C99478898544C6EBA3F4602BD5D2CF4USNAVSXCHMBSC_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thanks for the comments, see in-line=A1=AD=

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
Cc: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

 

Hi Nabil,

 

It=A1=AFs a very comprehensive doc.

 

Some commons:

1=A1=A2  In section 6.1, it said: =A1=B0As the number of tenants in individual VLAN=
 islands surpasses 4K, the operator could push VPLS deployment deeper in th=
e DC network=A1=AD. The ToR and DC core elements need to be MPLS enabled wi=
th existing VPLS solutions=A1=B1, IMHO, DC core switches don=A1=AFt need to=
 be MPLS enabled since IP based tunnel is also available.=

 
FB> You are right we should hav= e said =A1=B0IP or MPLS enabled=A1=B1 as both cases are possible=A1=AD 
 
2=A1=A2  Still in section 6.1, it said: =A1=B1 =A1=ADHowever, this model does not s= olve the MAC explosion issue as ToRs still need to learn VM MAC addresses.= =A1=B1 However, in section 6.2.1, it said:=A1=B1=A1=ADAlternatively, the PB= B encapsulation can be done at the ToR.=A1=B1  It is confused since pe= rforming PBB encapsulation at the ToR would not alleviate the MAC-learning = burden on that ToR.
 
FB> Maybe the phrase location i= s puzzling. The focus of section 6.2 is the use of an extended 24b PBB I-IS= ID tag starting at the VSw to identify the ELAN broadcast domain. 
This will maximize the benefits. H=
owever in reality it is very likely there will be legacy DC regions still r=
unning VLANs which require a Gateway function during the migration. See the=
 VLAN Interop discussion in section 6.2.9. 
 <=
/pre>
3=A1=A2  In 6.2.6.2. PBBN in VSw, L2VPN in the ToR, it said:=
=A1=B1 The procedures from the previous section are used at the VSw: PBB encapsul=
ation and Ethernet BVLANs can be used on the VSw uplink. L2VPN infrastructu=
re is replacing the BVLAN at the ToR enabling the use of IP (GRE or L2TP) o=
r MPLS tunneling. 
 
FB> This is about the tunneling=
 encapsulation options to be used in the core: 24b I-SID tag is the common =
tenant ID which can be transported over an Ethernet or an IP or an MPLS bas=
ed DC network. Combinations of these tunneling options are also possible: e=
.g. one DC may be Ethernet based the other IP based; or the VSw may use Eth=
ernet VLAN tunnels while IP tunnels may start at the ToR.=

 
L2 networking still has = the same control plane choices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], inde= pendently from the tunneling choice.=A1=B1 Since PBB encapsulation has alre= ady been done on the VSw, why do we still need to run 802.1aq and PBB-EVPN = with another PBB encapsulation layer?
 
FB> No need for an additional P= BB encapsulation layer! This is strictly about control plane options: IS-IS= and BGP are used the same way as in regular IP routing to perform Multipat= hing, Fast Convergence, service AD, program the core FIBs etc=A1=AD
 <=
/pre>
 Can=A1=AFt we simply use=
 any L2VPN technology, e.g., VPLS. In addition, note that in Figure 5, it s=
aid =A1=B0intra-DC L2VPN over IP or MPLS tunneling=A1=B1.=




 



FB> yes you can. We just focused here on the options that will addre=
ss the challenges described in the problem statement section. Otherwise the=
 content will have grown too much.



 



 



Best regards,



Xiaohu



 












=B7=A2=BC=FE=C8=CB:
l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA=
=B1=ED Bitar, Nabil N

=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5 13:42

=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org

=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang
(lufang); y.ikejiri@ntt.com

=D6=F7=CC=E2: Your input on the following draft is appreciate=
d:
draft-bitar-datacenter-vpn-applicability-01.txt









 






Hi,









We had submitted the following draft on vpn applicability for =
data
center. Your input on the draft is appreciated in light of some of the ongo=
ing
discussion. The draft is targeted for l3vpn and l2vpn.








Here is the link: 









 











 






Abstract
 
   Cloud Computing has been attracting a lot of attention fr=
om the
   networking industry. Some of the most publicized requirem=
ents are
   related to the evolution of the Cloud Networking Infrastr=
ucture to
   accommodate a large number of tenants, efficient network =
utilization,
   scalable loop avoidance, and Virtual Machine Mobility.
 
   This draft describes a framework for cloud networking, hi=
ghlighting
   the applicability of existing work in various IETF Workin=
g Groups
   (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN =
Working
   Groups) to cloud networking, and the gaps and problems th=
at need to
   be further addressed. That is, the goal is to understand =
what may be
   re-used from the current protocols and call out requireme=
nts specific
   to the Cloud space that need to be addressed by new stand=
ardization
   work with proposed solutions in certain cases.=




Thanks,
Nabil
--_000_2073A6C5467C99478898544C6EBA3F4602BD5D2CF4USNAVSXCHMBSC_-- From xuxiaohu@huawei.com Tue Nov 8 17:55: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 7451921F893C; Tue, 8 Nov 2011 17:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8yG6NV1-QEF; Tue, 8 Nov 2011 17:54:59 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4EC21F8922; Tue, 8 Nov 2011 17:54:58 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00FPSEN13D@szxga03-in.huawei.com>; Wed, 09 Nov 2011 09:54:37 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00DK0EN14A@szxga03-in.huawei.com>; Wed, 09 Nov 2011 09:54:37 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV51330; Wed, 09 Nov 2011 09:54:34 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 09:54:28 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 09:54:22 +0800 Date: Wed, 09 Nov 2011 01:54:22 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> X-Originating-IP: [10.108.4.59] To: "Balus, Florin Stelian (Florin)" , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C00@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_MJVV+Xg41PwZ5j6Kuj9Qhw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAC+SpwABxhHfAACrvcUA== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Bt1U EXY7 MTnc NOSF TZfN Y6wx dEGO dVPN gTEc kYLh 3TCM 6xTX ACIKHA== ADE1vw== ADc1hg== AFePCw==; 8; ZgBsAG8AcgBpAG4ALgBiAGEAbAB1AHMAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AGwAMgB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAMwB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAdQBmAGEAbgBnAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBtAGkAcgBjAGUAYQAuAHAAaQBzAGkAYwBhAEAAYgB0AC4AYwBvAG0AOwBuAGEAYgBpAGwALgBuAC4AYgBpAHQAYQByAEAAdgBlAHIAaQB6AG8AbgAuAGMAbwBtADsAcwBhAGoAYQBzAHMAaQBAAGMAaQBzAGMAbwAuAGMAbwBtADsAeQAuAGkAawBlAGoAaQByAGkAQABuAHQAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {4EC2E246-5519-4E3C-B755-44DA9563B63A}; eAB1AHgAaQBhAG8AaAB1AEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Wed, 09 Nov 2011 02:08:14 GMT; cgBlADoAIABZAG8AdQByACAAaQBuAHAAdQB0ACAAbwBuACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGQAcgBhAGYAdAAgAGkAcwAgAGEAcABwAHIAZQBjAGkAYQB0AGUAZAA6AAkAZAByAGEAZgB0AC0AYgBpAHQAYQByAC0AZABhAHQAYQBjAGUAbgB0AGUAcgAtAHYAcABuAC0AYQBwAHAAbABpAGMAYQBiAGkAbABpAHQAeQAtADAAMQAuAHQAeAB0AA== x-cr-puzzleid: {4EC2E246-5519-4E3C-B755-44DA9563B63A} X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Cc: "y.ikejiri@ntt.com" , Sagessi , "mircea.pisica@bt.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: Wed, 09 Nov 2011 01:55:00 -0000 --Boundary_(ID_MJVV+Xg41PwZ5j6Kuj9Qhw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 t6K8/sjLOiBCYWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3JpbikgW21haWx0bzpmbG9yaW4uYmFs dXNAYWxjYXRlbC1sdWNlbnQuY29tXQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI5yNUgNTozNA0KytW8 /sjLOiBYdXhpYW9odTsgQml0YXIsIE5hYmlsIE47IGwzdnBuQGlldGYub3JnOyBsMnZwbkBpZXRm Lm9yZw0Ks63LzTogTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IFNhZ2Vzc2k7IHkuaWtlamlyaUBudHQu Y29tOyBtaXJjZWEucGlzaWNhQGJ0LmNvbQ0K1vfM4jogUkU6IFlvdXIgaW5wdXQgb24gdGhlIGZv bGxvd2luZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4t YXBwbGljYWJpbGl0eS0wMS50eHQNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHNlZSBpbi1s aW5loa0NCg0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBYdXhpYW9odQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJl ciAwNywgMjAxMSAxMTo1MyBQTQ0KVG86IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsg bDJ2cG5AaWV0Zi5vcmcNCkNjOiBMdXl1YW4gRmFuZyAobHVmYW5nKTsgU2FnZXNzaTsgeS5pa2Vq aXJpQG50dC5jb207IG1pcmNlYS5waXNpY2FAYnQuY29tDQpTdWJqZWN0OiByZTogWW91ciBpbnB1 dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRh Y2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dA0KDQpIaSBOYWJpbCwNCg0KSXShr3MgYSB2 ZXJ5IGNvbXByZWhlbnNpdmUgZG9jLg0KDQpTb21lIGNvbW1vbnM6DQoNCjGhoiAgSW4gc2VjdGlv biA2LjEsIGl0IHNhaWQ6IKGwQXMgdGhlIG51bWJlciBvZiB0ZW5hbnRzIGluIGluZGl2aWR1YWwg VkxBTiBpc2xhbmRzIHN1cnBhc3NlcyA0SywgdGhlIG9wZXJhdG9yIGNvdWxkIHB1c2ggVlBMUyBk ZXBsb3ltZW50IGRlZXBlciBpbiB0aGUgREMgbmV0d29ya6GtLiBUaGUgVG9SIGFuZCBEQyBjb3Jl IGVsZW1lbnRzIG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHdpdGggZXhpc3RpbmcgVlBMUyBzb2x1 dGlvbnOhsSwgSU1ITywgREMgY29yZSBzd2l0Y2hlcyBkb26hr3QgbmVlZCB0byBiZSBNUExTIGVu YWJsZWQgc2luY2UgSVAgYmFzZWQgdHVubmVsIGlzIGFsc28gYXZhaWxhYmxlLg0KDQoNCg0KRkI+ IFlvdSBhcmUgcmlnaHQgd2Ugc2hvdWxkIGhhdmUgc2FpZCChsElQIG9yIE1QTFMgZW5hYmxlZKGx IGFzIGJvdGggY2FzZXMgYXJlIHBvc3NpYmxloa0NCg0KDQoNCjxYWEg+IEdvb2QgcG9pbnQuDQoN Cg0KDQoyoaIgIFN0aWxsIGluIHNlY3Rpb24gNi4xLCBpdCBzYWlkOiChsSChrUhvd2V2ZXIsIHRo aXMgbW9kZWwgZG9lcyBub3Qgc29sdmUgdGhlIE1BQyBleHBsb3Npb24gaXNzdWUgYXMgVG9ScyBz dGlsbCBuZWVkIHRvIGxlYXJuIFZNIE1BQyBhZGRyZXNzZXMuobEgSG93ZXZlciwgaW4gc2VjdGlv biA2LjIuMSwgaXQgc2FpZDqhsaGtQWx0ZXJuYXRpdmVseSwgdGhlIFBCQiBlbmNhcHN1bGF0aW9u IGNhbiBiZSBkb25lIGF0IHRoZSBUb1IuobEgIEl0IGlzIGNvbmZ1c2VkIHNpbmNlIHBlcmZvcm1p bmcgUEJCIGVuY2Fwc3VsYXRpb24gYXQgdGhlIFRvUiB3b3VsZCBub3QgYWxsZXZpYXRlIHRoZSBN QUMtbGVhcm5pbmcgYnVyZGVuIG9uIHRoYXQgVG9SLg0KDQoNCg0KRkI+IE1heWJlIHRoZSBwaHJh c2UgbG9jYXRpb24gaXMgcHV6emxpbmcuIFRoZSBmb2N1cyBvZiBzZWN0aW9uIDYuMiBpcyB0aGUg dXNlIG9mIGFuIGV4dGVuZGVkIDI0YiBQQkIgSS1JU0lEIHRhZyBzdGFydGluZyBhdCB0aGUgVlN3 IHRvIGlkZW50aWZ5IHRoZSBFTEFOIGJyb2FkY2FzdCBkb21haW4uDQoNCg0KDQo8WFhIPiBUaGUg dGl0bGUgb2Ygc2VjdGlvbiA2LjIuMSBpcyChsEFkZHJlc3NpbmcgVkxBTiBzcGFjZSBleGhhdXN0 aW9uIGFuZCBNQUMgZXhwbG9zaW9uobEuIFNvIEkgdGhpbmsgc2F5aW5nIG1vcmUgd29yZHMgYWZ0 ZXIgdGhhdCBzZW50ZW5jZSBpcyBtdWNoIGhlbHBmdWwgaW4gYXZvaWRpbmcgY29uZnVzaW9uLg0K DQoNCg0KDQoNClRoaXMgd2lsbCBtYXhpbWl6ZSB0aGUgYmVuZWZpdHMuIEhvd2V2ZXIgaW4gcmVh bGl0eSBpdCBpcyB2ZXJ5IGxpa2VseSB0aGVyZSB3aWxsIGJlIGxlZ2FjeSBEQyByZWdpb25zIHN0 aWxsIHJ1bm5pbmcgVkxBTnMgd2hpY2ggcmVxdWlyZSBhIEdhdGV3YXkgZnVuY3Rpb24gZHVyaW5n IHRoZSBtaWdyYXRpb24uIFNlZSB0aGUgVkxBTiBJbnRlcm9wIGRpc2N1c3Npb24gaW4gc2VjdGlv biA2LjIuOS4NCg0KDQoNCjOhoiAgSW4gNi4yLjYuMi4gUEJCTiBpbiBWU3csIEwyVlBOIGluIHRo ZSBUb1IsIGl0IHNhaWQ6obEgVGhlIHByb2NlZHVyZXMgZnJvbSB0aGUgcHJldmlvdXMgc2VjdGlv biBhcmUgdXNlZCBhdCB0aGUgVlN3OiBQQkIgZW5jYXBzdWxhdGlvbiBhbmQgRXRoZXJuZXQgQlZM QU5zIGNhbiBiZSB1c2VkIG9uIHRoZSBWU3cgdXBsaW5rLiBMMlZQTiBpbmZyYXN0cnVjdHVyZSBp cyByZXBsYWNpbmcgdGhlIEJWTEFOIGF0IHRoZSBUb1IgZW5hYmxpbmcgdGhlIHVzZSBvZiBJUCAo R1JFIG9yIEwyVFApIG9yIE1QTFMgdHVubmVsaW5nLg0KDQoNCg0KRkI+IFRoaXMgaXMgYWJvdXQg dGhlIHR1bm5lbGluZyBlbmNhcHN1bGF0aW9uIG9wdGlvbnMgdG8gYmUgdXNlZCBpbiB0aGUgY29y ZTogMjRiIEktU0lEIHRhZyBpcyB0aGUgY29tbW9uIHRlbmFudCBJRCB3aGljaCBjYW4gYmUgdHJh bnNwb3J0ZWQgb3ZlciBhbiBFdGhlcm5ldCBvciBhbiBJUCBvciBhbiBNUExTIGJhc2VkIERDIG5l dHdvcmsuIENvbWJpbmF0aW9ucyBvZiB0aGVzZSB0dW5uZWxpbmcgb3B0aW9ucyBhcmUgYWxzbyBw b3NzaWJsZTogZS5nLiBvbmUgREMgbWF5IGJlIEV0aGVybmV0IGJhc2VkIHRoZSBvdGhlciBJUCBi YXNlZDsgb3IgdGhlIFZTdyBtYXkgdXNlIEV0aGVybmV0IFZMQU4gdHVubmVscyB3aGlsZSBJUCB0 dW5uZWxzIG1heSBzdGFydCBhdCB0aGUgVG9SLg0KDQoNCg0KPFhYSD4gWWVzLCBJIGFncmVlIHdp dGggeW91ciBzdGF0ZW1lbnQgYWJvdmUuIEFkZGluZyB0aGUgYWJvdmUgdGV4dCBpbnRvIHRoZSBk cmFmdCB3b3VsZCBiZSBtdWNoIGhlbHBmdWw6KQ0KDQoNCg0KIEwyIG5ldHdvcmtpbmcgc3RpbGwg aGFzIHRoZSBzYW1lIGNvbnRyb2wgcGxhbmUgY2hvaWNlczogSVMtSVMgWzgwMi4xYXFdIGFuZC9v ciBCR1AgW1BCQi1FVlBOXSwgaW5kZXBlbmRlbnRseSBmcm9tIHRoZSB0dW5uZWxpbmcgY2hvaWNl LqGxIFNpbmNlIFBCQiBlbmNhcHN1bGF0aW9uIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBvbiB0aGUg VlN3LCB3aHkgZG8gd2Ugc3RpbGwgbmVlZCB0byBydW4gODAyLjFhcSBhbmQgUEJCLUVWUE4gd2l0 aCBhbm90aGVyIFBCQiBlbmNhcHN1bGF0aW9uIGxheWVyPw0KDQoNCg0KRkI+IE5vIG5lZWQgZm9y IGFuIGFkZGl0aW9uYWwgUEJCIGVuY2Fwc3VsYXRpb24gbGF5ZXIhIFRoaXMgaXMgc3RyaWN0bHkg YWJvdXQgY29udHJvbCBwbGFuZSBvcHRpb25zOiBJUy1JUyBhbmQgQkdQIGFyZSB1c2VkIHRoZSBz YW1lIHdheSBhcyBpbiByZWd1bGFyIElQIHJvdXRpbmcgdG8gcGVyZm9ybSBNdWx0aXBhdGhpbmcs IEZhc3QgQ29udmVyZ2VuY2UsIHNlcnZpY2UgQUQsIHByb2dyYW0gdGhlIGNvcmUgRklCcyBldGOh rQ0KDQoNCg0KPFhYSD4gQWJzb2x1dGVseSBhZ3JlZS4gU3VjaCBiZWluZyB0aGUgY2FzZSwgd2h5 IG5vdCByZW1vdmUgdGhlIHR3byBzcGVjaWZpYyBleGFtcGxlcyAoYm90aCBvZiB0aGVtIGFkZCBh bm90aGVyIFBCQiBsYXllcikgZnJvbSB0aGF0IHNlbnRlbmNlIHNvIGFzIHRvIGVsaW1pbmF0ZSB0 aGUgcG9zc2libGUgY29uZnVzaW9uPw0KDQoNCg0KIENhbqGvdCB3ZSBzaW1wbHkgdXNlIGFueSBM MlZQTiB0ZWNobm9sb2d5LCBlLmcuLCBWUExTLiBJbiBhZGRpdGlvbiwgbm90ZSB0aGF0IGluIEZp Z3VyZSA1LCBpdCBzYWlkIKGwaW50cmEtREMgTDJWUE4gb3ZlciBJUCBvciBNUExTIHR1bm5lbGlu Z6GxLg0KDQoNCkZCPiB5ZXMgeW91IGNhbi4gV2UganVzdCBmb2N1c2VkIGhlcmUgb24gdGhlIG9w dGlvbnMgdGhhdCB3aWxsIGFkZHJlc3MgdGhlIGNoYWxsZW5nZXMgZGVzY3JpYmVkIGluIHRoZSBw cm9ibGVtIHN0YXRlbWVudCBzZWN0aW9uLiBPdGhlcndpc2UgdGhlIGNvbnRlbnQgd2lsbCBoYXZl IGdyb3duIHRvbyBtdWNoLg0KDQo8WFhIPiBUaGFua3MgZm9yIHlvdXIgZXhwbGFuYXRpb24uDQoN CkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQq3orz+yMs6IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJpdGFyLCBOYWJpbCBODQq3osvN yrG85DogMjAxMcTqMTHUwjjI1SAxMzo0Mg0KytW8/sjLOiBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5A aWV0Zi5vcmcNCrOty806IFNhZ2Vzc2k7IG1pcmNlYS5waXNpY2FAYnQuY29tOyBMdXl1YW4gRmFu ZyAobHVmYW5nKTsgeS5pa2VqaXJpQG50dC5jb20NCtb3zOI6IFlvdXIgaW5wdXQgb24gdGhlIGZv bGxvd2luZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4t YXBwbGljYWJpbGl0eS0wMS50eHQNCg0KSGksDQpXZSBoYWQgc3VibWl0dGVkIHRoZSBmb2xsb3dp bmcgZHJhZnQgb24gdnBuIGFwcGxpY2FiaWxpdHkgZm9yIGRhdGEgY2VudGVyLiBZb3VyIGlucHV0 IG9uIHRoZSBkcmFmdCBpcyBhcHByZWNpYXRlZCBpbiBsaWdodCBvZiBzb21lIG9mIHRoZSBvbmdv aW5nIGRpc2N1c3Npb24uIFRoZSBkcmFmdCBpcyB0YXJnZXRlZCBmb3IgbDN2cG4gYW5kIGwydnBu Lg0KSGVyZSBpcyB0aGUgbGluazoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Yml0YXItZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0eS0wMQ0KDQoNCkFic3RyYWN0DQoNCg0K DQogICBDbG91ZCBDb21wdXRpbmcgaGFzIGJlZW4gYXR0cmFjdGluZyBhIGxvdCBvZiBhdHRlbnRp b24gZnJvbSB0aGUNCg0KICAgbmV0d29ya2luZyBpbmR1c3RyeS4gU29tZSBvZiB0aGUgbW9zdCBw dWJsaWNpemVkIHJlcXVpcmVtZW50cyBhcmUNCg0KICAgcmVsYXRlZCB0byB0aGUgZXZvbHV0aW9u IG9mIHRoZSBDbG91ZCBOZXR3b3JraW5nIEluZnJhc3RydWN0dXJlIHRvDQoNCiAgIGFjY29tbW9k YXRlIGEgbGFyZ2UgbnVtYmVyIG9mIHRlbmFudHMsIGVmZmljaWVudCBuZXR3b3JrIHV0aWxpemF0 aW9uLA0KDQogICBzY2FsYWJsZSBsb29wIGF2b2lkYW5jZSwgYW5kIFZpcnR1YWwgTWFjaGluZSBN b2JpbGl0eS4NCg0KDQoNCiAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgZnJhbWV3b3JrIGZvciBj bG91ZCBuZXR3b3JraW5nLCBoaWdobGlnaHRpbmcNCg0KICAgdGhlIGFwcGxpY2FiaWxpdHkgb2Yg ZXhpc3Rpbmcgd29yayBpbiB2YXJpb3VzIElFVEYgV29ya2luZyBHcm91cHMNCg0KICAgKGUuZy4s IFJGQ3MgYW5kIGRyYWZ0cyBkZXZlbG9wZWQgaW4gSUVURiBMMlZQTiBhbmQgTDNWUE4gV29ya2lu Zw0KDQogICBHcm91cHMpIHRvIGNsb3VkIG5ldHdvcmtpbmcsIGFuZCB0aGUgZ2FwcyBhbmQgcHJv YmxlbXMgdGhhdCBuZWVkIHRvDQoNCiAgIGJlIGZ1cnRoZXIgYWRkcmVzc2VkLiBUaGF0IGlzLCB0 aGUgZ29hbCBpcyB0byB1bmRlcnN0YW5kIHdoYXQgbWF5IGJlDQoNCiAgIHJlLXVzZWQgZnJvbSB0 aGUgY3VycmVudCBwcm90b2NvbHMgYW5kIGNhbGwgb3V0IHJlcXVpcmVtZW50cyBzcGVjaWZpYw0K DQogICB0byB0aGUgQ2xvdWQgc3BhY2UgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZCBieSBuZXcg c3RhbmRhcmRpemF0aW9uDQoNCiAgIHdvcmsgd2l0aCBwcm9wb3NlZCBzb2x1dGlvbnMgaW4gY2Vy dGFpbiBjYXNlcy4NCg0KDQpUaGFua3MsDQoNCk5hYmlsDQo= --Boundary_(ID_MJVV+Xg41PwZ5j6Kuj9Qhw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

=B7=A2=BC=FE=C8=CB: Balus, = Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 5:34
=CA=D5=BC=FE=C8=CB: Xuxiaohu; Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com =D6=F7=CC=E2: RE: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

Thank= s for the comments, see in-line=A1=AD

=  

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
Cc: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@= bt.com
Subject: re: Your input on the following draft is appreciated: draft= -bitar-datacenter-vpn-applicability-01.txt

 

Hi Nabil,<= o:p>

 = ;

It=A1=AFs = a very comprehensive doc.

 = ;

Some commo= ns:

1=A1=A2  In section 6.1, it said: =A1=B0As t=
he number of tenants in individual VLAN islands surpasses 4K, the operator =
could push VPLS deployment deeper in the DC network=A1=AD. The ToR and DC c=
ore elements need to be MPLS enabled with existing VPLS solutions=A1=B1, IM=
HO, DC core switches don=A1=AFt need to be MPLS enabled since IP based tunn=
el is also available.
 
FB> You are right we should have said =A1=B0IP or MPLS enabled=
=A1=B1 as both cases are possible=A1=AD 
 
<XXH> Good point.
 
2=A1=A2  Still in section 6.1, it said: =A1=
=B1 =A1=ADHowever, this model does not solve the MAC explosion issue as ToR=
s still need to learn VM MAC addresses.=A1=B1 However, in section 6.2.1, it=
 said:=A1=B1=A1=ADAlternatively, the PBB encapsulation can be done at the T=
oR.=A1=B1  It is confused since performing PBB encapsulation at the To=
R would not alleviate the MAC-learning burden on that ToR.
 
FB> Maybe the phrase location is puzzling. The focus of sectio=
n 6.2 is the use of an extended 24b PBB I-ISID tag starting at the VSw to i=
dentify the ELAN broadcast domain. 
 
<XXH> The title of section 6.2.1 is =A1=B0Addressing VLAN spac=
e exhaustion and MAC explosion=A1=B1. So I think saying more words after th=
at sentence is much helpful in avoiding confusion.
 
 
This will maximize the benefits. However in reality it is very li=
kely there will be legacy DC regions still running VLANs which require a Ga=
teway function during the migration. See the VLAN Interop discussion in sec=
tion 6.2.9. 
 
3=A1=A2  In 6.2.=
6.2. PBBN in VSw, L2VPN in the ToR, it said:=A1=B1 The procedures from the previo=
us section are used at the VSw: PBB encapsulation and Ethernet BVLANs can b=
e used on the VSw uplink. L2VPN infrastructure is replacing the BVLAN at th=
e ToR enabling the use of IP (GRE or L2TP) or MPLS tunneling. 
 
FB> This is about the tunneling encapsulation options to be us=
ed in the core: 24b I-SID tag is the common tenant ID which can be transpor=
ted over an Ethernet or an IP or an MPLS based DC network. Combinations of =
these tunneling options are also possible: e.g. one DC may be Ethernet base=
d the other IP based; or the VSw may use Ethernet VLAN tunnels while IP tun=
nels may start at the ToR.
 
<XXH> Yes, I agree with your statement above. Adding the above=
 text into the draft would be much helpfulJ
 
 L2 networking still has the same control plane c=
hoices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], independently from the tunne=
ling choice.=A1=B1 Since PBB encapsulation has already been done on the VSw=
, why do we still need to run 802.1aq and PBB-EVPN with another PBB encapsu=
lation layer?
 
FB> No need for an additional PBB encapsulation layer! This is=
 strictly about control plane options: IS-IS and BGP are used the same way =
as in regular IP routing to perform Multipathing, Fast Convergence, service=
 AD, program the core FIBs etc=A1=AD
 
<XXH> Absolutely agree. Such being the case, why not remove th=
e two specific examples (both of them add another PBB layer) from that sent=
ence so as to eliminate the possible confusion?
 
 Can=A1=AFt we simply use any L2VPN technology, e=
.g., VPLS. In addition, note that in Figure 5, it said =A1=B0intra-DC L2VPN=
 over IP or MPLS tunneling=A1=B1.

 = ;

FB> yes you can. We just focused here on th=
e options that will address the challenges described in the problem stateme=
nt section. Otherwise the content will have grown too much.

 = ;

<XXH>= ; Thanks for your explanation.

=  

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: l2vpn-b= ounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA= =B1=ED Bitar, Nabil N
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5 13:42
=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com =D6=F7=CC=E2: Your input on the following draft is appreciated: draft-bitar-datacenter-= vpn-applicability-01.txt

 

Hi,

We had submi= tted the following draft on vpn applicability for data center. Your input o= n the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the = link: 

 <= /o:p>

 <= /o:p>

Abstract

 


   Cloud Computing ha=
s been attracting a lot of attention from the


   networking industr=
y. Some of the most publicized requirements are


   related to the evo=
lution of the Cloud Networking Infrastructure to


   accommodate a larg=
e number of tenants, efficient network utilization,


   scalable loop avoi=
dance, and Virtual Machine Mobility.


 


   This draft describ=
es a framework for cloud networking, highlighting


   the applicability =
of existing work in various IETF Working Groups


   (e.g., RFCs and dr=
afts developed in IETF L2VPN and L3VPN Working


   Groups) to cloud n=
etworking, and the gaps and problems that need to


   be further address=
ed. That is, the goal is to understand what may be


   re-used from the c=
urrent protocols and call out requirements specific


   to the Cloud space=
 that need to be addressed by new standardization


   work with proposed=
 solutions in certain cases.





Thanks,


Nabil
--Boundary_(ID_MJVV+Xg41PwZ5j6Kuj9Qhw)-- From xuxiaohu@huawei.com Tue Nov 8 18:51: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 7C77C1F0C5C; Tue, 8 Nov 2011 18:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+eUVwmgWfaP; Tue, 8 Nov 2011 18:50:59 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3134D1F0C54; Tue, 8 Nov 2011 18:50:58 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00APWH8NK4@szxga04-in.huawei.com>; Wed, 09 Nov 2011 10:50:47 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00AIWH8NKM@szxga04-in.huawei.com>; Wed, 09 Nov 2011 10:50:47 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV56594; Wed, 09 Nov 2011 10:50:46 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 10:50:41 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 10:50:37 +0800 Date: Wed, 09 Nov 2011 02:50:36 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt X-Originating-IP: [10.108.4.59] To: Xuxiaohu , "Balus, Florin Stelian (Florin)" , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C3A@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rOt2fZb4QA4ok2JU0SxtNw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAC+SpwABxhHfAACrvcUAAB0LLw X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: HVh2 I6zi RCGE hQEV jBB2 oA1n qDE6 xVJ2 z92/ 2jLD 4zSa 60CV 63jf ABI2pw== AEn4Iw== AE5BRA==; 8; ZgBsAG8AcgBpAG4ALgBiAGEAbAB1AHMAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AGwAMgB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAMwB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAdQBmAGEAbgBnAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBtAGkAcgBjAGUAYQAuAHAAaQBzAGkAYwBhAEAAYgB0AC4AYwBvAG0AOwBuAGEAYgBpAGwALgBuAC4AYgBpAHQAYQByAEAAdgBlAHIAaQB6AG8AbgAuAGMAbwBtADsAcwBhAGoAYQBzAHMAaQBAAGMAaQBzAGMAbwAuAGMAbwBtADsAeQAuAGkAawBlAGoAaQByAGkAQABuAHQAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {4D51806C-0CA1-4CC8-8A08-99645B9F24FA}; eAB1AHgAaQBhAG8AaAB1AEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Wed, 09 Nov 2011 03:03:31 GMT; cgBlADoAIABZAG8AdQByACAAaQBuAHAAdQB0ACAAbwBuACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGQAcgBhAGYAdAAgAGkAcwAgAGEAcABwAHIAZQBjAGkAYQB0AGUAZAA6AAkAZAByAGEAZgB0AC0AYgBpAHQAYQByAC0AZABhAHQAYQBjAGUAbgB0AGUAcgAtAHYAcABuAC0AYQBwAHAAbABpAGMAYQBiAGkAbABpAHQAeQAtADAAMQAuAHQAeAB0AA== x-cr-puzzleid: {4D51806C-0CA1-4CC8-8A08-99645B9F24FA} X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Cc: "y.ikejiri@ntt.com" , Sagessi , "mircea.pisica@bt.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: Wed, 09 Nov 2011 02:51:00 -0000 --Boundary_(ID_rOt2fZb4QA4ok2JU0SxtNw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 QnkgdGhlIHdheSwgaXQgd291bGQgYmUgYmV0dGVyIHRvIHB1c2ggdGhlIFBCQiBhcyBjbG9zZSB0 byB0aGUgZW5kLXN5c3RlbXMgYXMgcG9zc2libGUgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgTUFD IGZvcndhcmRpbmcgdGFibGUgc2NhbGFiaWxpdHkuIEhvd2V2ZXIsIHRoZSB1bmtub3duIHVuaWNh c3QgZmxvb2QgaW1wYWN0IGlzc3VlIHdvdWxkIGJlIHdvcnNlbiBhY2NvcmRpbmdseS4gRm9yIGV4 YW1wbGUsIGluIGEgbm9ybWFsIExheWVyMiBuZXR3b3JrLCBpZiB0d28gVk1zIGF0dGFjaGVkIHRv IHRoZSBnaXZlbiBUb1IgYXJlIGZyZXF1ZW50bHkgY29tbXVuaWNhdGVkIHdpdGggZWFjaCBvdGhl ciBhbmQgaGVuY2UgdGhlaXIgTUFDIGFkZHJlc3MgZW50cmllcyBvbiB0aGlzIFRvUiB3aWxsIG5v dCBiZSBleHBpcmVkLCB0aGUgdHJhZmZpYyBkZXN0aW5lZCBmb3IgYW55IG9mIHRob3NlIHR3byBW TXMgZnJvbSBhIHJlbW90ZSBWTSBjb3VsZCBiZSBmbG9vZGVkIGFzIHVua25vd24gdW5pY2FzdCB1 bnRpbCB0aGUgdHJhZmZpYyByZWFjaCB0aGlzIFRvUiB3aGljaCBpbiB0dXJuIGZvcndhcmQgdGhl IHRyYWZmaWMgdG8gdGhlIGRlc3RpbmF0aW9uIFZNIGluIHVuaWNhc3QuICBIb3dldmVyLCBvbmNl IFBCQiBpcyBwZXJmb3JtZWQgYXQgZWFjaCBWU3csIHRoYXQgdHJhZmZpYyB3b3VsZCBiZSBmbG9v ZGVkIHVudGlsIGl0IHJlYWNoIHRoZSBmaW5hbCBkZXN0aW5hdGlvbiBwaHlzaWNhbCBzZXJ2ZXIu ICBJdKGvcyBhIGhhcmQgdHJhZGVvZmYsIGlzbqGvdCBpdD8NCg0KWGlhb2h1DQoNCg0Kt6K8/sjL OiBYdXhpYW9odQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI5yNUgMTA6MDgNCsrVvP7IyzogJ0JhbHVz LCBGbG9yaW4gU3RlbGlhbiAoRmxvcmluKSc7IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9y ZzsgbDJ2cG5AaWV0Zi5vcmcNCrOty806IEx1eXVhbiBGYW5nIChsdWZhbmcpOyBTYWdlc3NpOyB5 LmlrZWppcmlAbnR0LmNvbTsgbWlyY2VhLnBpc2ljYUBidC5jb20NCtb3zOI6IHJlOiBZb3VyIGlu cHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRh dGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0DQoNCreivP7IyzogQmFsdXMsIEZsb3Jp biBTdGVsaWFuIChGbG9yaW4pIFttYWlsdG86ZmxvcmluLmJhbHVzQGFsY2F0ZWwtbHVjZW50LmNv bV0NCreiy83KsbzkOiAyMDExxOoxMdTCOcjVIDU6MzQNCsrVvP7IyzogWHV4aWFvaHU7IEJpdGFy LCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCrOty806IEx1eXVhbiBG YW5nIChsdWZhbmcpOyBTYWdlc3NpOyB5LmlrZWppcmlAbnR0LmNvbTsgbWlyY2VhLnBpc2ljYUBi dC5jb20NCtb3zOI6IFJFOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBw cmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0 DQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCBzZWUgaW4tbGluZaGtDQoNCkZyb206IGwydnBu LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgWHV4aWFvaHUNClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDcsIDIwMTEgMTE6NTMgUE0N ClRvOiBCaXRhciwgTmFiaWwgTjsgbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQpDYzog THV5dWFuIEZhbmcgKGx1ZmFuZyk7IFNhZ2Vzc2k7IHkuaWtlamlyaUBudHQuY29tOyBtaXJjZWEu cGlzaWNhQGJ0LmNvbQ0KU3ViamVjdDogcmU6IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2luZyBk cmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBwbGljYWJp bGl0eS0wMS50eHQNCg0KSGkgTmFiaWwsDQoNCkl0oa9zIGEgdmVyeSBjb21wcmVoZW5zaXZlIGRv Yy4NCg0KU29tZSBjb21tb25zOg0KDQoxoaIgIEluIHNlY3Rpb24gNi4xLCBpdCBzYWlkOiChsEFz IHRoZSBudW1iZXIgb2YgdGVuYW50cyBpbiBpbmRpdmlkdWFsIFZMQU4gaXNsYW5kcyBzdXJwYXNz ZXMgNEssIHRoZSBvcGVyYXRvciBjb3VsZCBwdXNoIFZQTFMgZGVwbG95bWVudCBkZWVwZXIgaW4g dGhlIERDIG5ldHdvcmuhrS4gVGhlIFRvUiBhbmQgREMgY29yZSBlbGVtZW50cyBuZWVkIHRvIGJl IE1QTFMgZW5hYmxlZCB3aXRoIGV4aXN0aW5nIFZQTFMgc29sdXRpb25zobEsIElNSE8sIERDIGNv cmUgc3dpdGNoZXMgZG9uoa90IG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHNpbmNlIElQIGJhc2Vk IHR1bm5lbCBpcyBhbHNvIGF2YWlsYWJsZS4NCg0KDQoNCkZCPiBZb3UgYXJlIHJpZ2h0IHdlIHNo b3VsZCBoYXZlIHNhaWQgobBJUCBvciBNUExTIGVuYWJsZWShsSBhcyBib3RoIGNhc2VzIGFyZSBw b3NzaWJsZaGtDQoNCg0KDQo8WFhIPiBHb29kIHBvaW50Lg0KDQoNCg0KMqGiICBTdGlsbCBpbiBz ZWN0aW9uIDYuMSwgaXQgc2FpZDogobEgoa1Ib3dldmVyLCB0aGlzIG1vZGVsIGRvZXMgbm90IHNv bHZlIHRoZSBNQUMgZXhwbG9zaW9uIGlzc3VlIGFzIFRvUnMgc3RpbGwgbmVlZCB0byBsZWFybiBW TSBNQUMgYWRkcmVzc2VzLqGxIEhvd2V2ZXIsIGluIHNlY3Rpb24gNi4yLjEsIGl0IHNhaWQ6obGh rUFsdGVybmF0aXZlbHksIHRoZSBQQkIgZW5jYXBzdWxhdGlvbiBjYW4gYmUgZG9uZSBhdCB0aGUg VG9SLqGxICBJdCBpcyBjb25mdXNlZCBzaW5jZSBwZXJmb3JtaW5nIFBCQiBlbmNhcHN1bGF0aW9u IGF0IHRoZSBUb1Igd291bGQgbm90IGFsbGV2aWF0ZSB0aGUgTUFDLWxlYXJuaW5nIGJ1cmRlbiBv biB0aGF0IFRvUi4NCg0KDQoNCkZCPiBNYXliZSB0aGUgcGhyYXNlIGxvY2F0aW9uIGlzIHB1enps aW5nLiBUaGUgZm9jdXMgb2Ygc2VjdGlvbiA2LjIgaXMgdGhlIHVzZSBvZiBhbiBleHRlbmRlZCAy NGIgUEJCIEktSVNJRCB0YWcgc3RhcnRpbmcgYXQgdGhlIFZTdyB0byBpZGVudGlmeSB0aGUgRUxB TiBicm9hZGNhc3QgZG9tYWluLg0KDQoNCg0KPFhYSD4gVGhlIHRpdGxlIG9mIHNlY3Rpb24gNi4y LjEgaXMgobBBZGRyZXNzaW5nIFZMQU4gc3BhY2UgZXhoYXVzdGlvbiBhbmQgTUFDIGV4cGxvc2lv bqGxLiBTbyBJIHRoaW5rIHNheWluZyBtb3JlIHdvcmRzIGFmdGVyIHRoYXQgc2VudGVuY2UgaXMg bXVjaCBoZWxwZnVsIGluIGF2b2lkaW5nIGNvbmZ1c2lvbi4NCg0KDQoNCg0KDQpUaGlzIHdpbGwg bWF4aW1pemUgdGhlIGJlbmVmaXRzLiBIb3dldmVyIGluIHJlYWxpdHkgaXQgaXMgdmVyeSBsaWtl bHkgdGhlcmUgd2lsbCBiZSBsZWdhY3kgREMgcmVnaW9ucyBzdGlsbCBydW5uaW5nIFZMQU5zIHdo aWNoIHJlcXVpcmUgYSBHYXRld2F5IGZ1bmN0aW9uIGR1cmluZyB0aGUgbWlncmF0aW9uLiBTZWUg dGhlIFZMQU4gSW50ZXJvcCBkaXNjdXNzaW9uIGluIHNlY3Rpb24gNi4yLjkuDQoNCg0KDQozoaIg IEluIDYuMi42LjIuIFBCQk4gaW4gVlN3LCBMMlZQTiBpbiB0aGUgVG9SLCBpdCBzYWlkOqGxIFRo ZSBwcm9jZWR1cmVzIGZyb20gdGhlIHByZXZpb3VzIHNlY3Rpb24gYXJlIHVzZWQgYXQgdGhlIFZT dzogUEJCIGVuY2Fwc3VsYXRpb24gYW5kIEV0aGVybmV0IEJWTEFOcyBjYW4gYmUgdXNlZCBvbiB0 aGUgVlN3IHVwbGluay4gTDJWUE4gaW5mcmFzdHJ1Y3R1cmUgaXMgcmVwbGFjaW5nIHRoZSBCVkxB TiBhdCB0aGUgVG9SIGVuYWJsaW5nIHRoZSB1c2Ugb2YgSVAgKEdSRSBvciBMMlRQKSBvciBNUExT IHR1bm5lbGluZy4NCg0KDQoNCkZCPiBUaGlzIGlzIGFib3V0IHRoZSB0dW5uZWxpbmcgZW5jYXBz dWxhdGlvbiBvcHRpb25zIHRvIGJlIHVzZWQgaW4gdGhlIGNvcmU6IDI0YiBJLVNJRCB0YWcgaXMg dGhlIGNvbW1vbiB0ZW5hbnQgSUQgd2hpY2ggY2FuIGJlIHRyYW5zcG9ydGVkIG92ZXIgYW4gRXRo ZXJuZXQgb3IgYW4gSVAgb3IgYW4gTVBMUyBiYXNlZCBEQyBuZXR3b3JrLiBDb21iaW5hdGlvbnMg b2YgdGhlc2UgdHVubmVsaW5nIG9wdGlvbnMgYXJlIGFsc28gcG9zc2libGU6IGUuZy4gb25lIERD IG1heSBiZSBFdGhlcm5ldCBiYXNlZCB0aGUgb3RoZXIgSVAgYmFzZWQ7IG9yIHRoZSBWU3cgbWF5 IHVzZSBFdGhlcm5ldCBWTEFOIHR1bm5lbHMgd2hpbGUgSVAgdHVubmVscyBtYXkgc3RhcnQgYXQg dGhlIFRvUi4NCg0KDQoNCjxYWEg+IFllcywgSSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50IGFi b3ZlLiBBZGRpbmcgdGhlIGFib3ZlIHRleHQgaW50byB0aGUgZHJhZnQgd291bGQgYmUgbXVjaCBo ZWxwZnVsOikNCg0KDQoNCiBMMiBuZXR3b3JraW5nIHN0aWxsIGhhcyB0aGUgc2FtZSBjb250cm9s IHBsYW5lIGNob2ljZXM6IElTLUlTIFs4MDIuMWFxXSBhbmQvb3IgQkdQIFtQQkItRVZQTl0sIGlu ZGVwZW5kZW50bHkgZnJvbSB0aGUgdHVubmVsaW5nIGNob2ljZS6hsSBTaW5jZSBQQkIgZW5jYXBz dWxhdGlvbiBoYXMgYWxyZWFkeSBiZWVuIGRvbmUgb24gdGhlIFZTdywgd2h5IGRvIHdlIHN0aWxs IG5lZWQgdG8gcnVuIDgwMi4xYXEgYW5kIFBCQi1FVlBOIHdpdGggYW5vdGhlciBQQkIgZW5jYXBz dWxhdGlvbiBsYXllcj8NCg0KDQoNCkZCPiBObyBuZWVkIGZvciBhbiBhZGRpdGlvbmFsIFBCQiBl bmNhcHN1bGF0aW9uIGxheWVyISBUaGlzIGlzIHN0cmljdGx5IGFib3V0IGNvbnRyb2wgcGxhbmUg b3B0aW9uczogSVMtSVMgYW5kIEJHUCBhcmUgdXNlZCB0aGUgc2FtZSB3YXkgYXMgaW4gcmVndWxh ciBJUCByb3V0aW5nIHRvIHBlcmZvcm0gTXVsdGlwYXRoaW5nLCBGYXN0IENvbnZlcmdlbmNlLCBz ZXJ2aWNlIEFELCBwcm9ncmFtIHRoZSBjb3JlIEZJQnMgZXRjoa0NCg0KDQoNCjxYWEg+IEFic29s dXRlbHkgYWdyZWUuIFN1Y2ggYmVpbmcgdGhlIGNhc2UsIHdoeSBub3QgcmVtb3ZlIHRoZSB0d28g c3BlY2lmaWMgZXhhbXBsZXMgKGJvdGggb2YgdGhlbSBhZGQgYW5vdGhlciBQQkIgbGF5ZXIpIGZy b20gdGhhdCBzZW50ZW5jZSBzbyBhcyB0byBlbGltaW5hdGUgdGhlIHBvc3NpYmxlIGNvbmZ1c2lv bj8NCg0KDQoNCiBDYW6hr3Qgd2Ugc2ltcGx5IHVzZSBhbnkgTDJWUE4gdGVjaG5vbG9neSwgZS5n LiwgVlBMUy4gSW4gYWRkaXRpb24sIG5vdGUgdGhhdCBpbiBGaWd1cmUgNSwgaXQgc2FpZCChsGlu dHJhLURDIEwyVlBOIG92ZXIgSVAgb3IgTVBMUyB0dW5uZWxpbmehsS4NCg0KDQpGQj4geWVzIHlv dSBjYW4uIFdlIGp1c3QgZm9jdXNlZCBoZXJlIG9uIHRoZSBvcHRpb25zIHRoYXQgd2lsbCBhZGRy ZXNzIHRoZSBjaGFsbGVuZ2VzIGRlc2NyaWJlZCBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2Vj dGlvbi4gT3RoZXJ3aXNlIHRoZSBjb250ZW50IHdpbGwgaGF2ZSBncm93biB0b28gbXVjaC4NCg0K PFhYSD4gVGhhbmtzIGZvciB5b3VyIGV4cGxhbmF0aW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFv aHUNCg0Kt6K8/sjLOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBCaXRhciwgTmFiaWwgTg0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI4yNUg MTM6NDINCsrVvP7IyzogbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQqzrcvNOiBTYWdl c3NpOyBtaXJjZWEucGlzaWNhQGJ0LmNvbTsgTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IHkuaWtlamly aUBudHQuY29tDQrW98ziOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBw cmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0 DQoNCkhpLA0KV2UgaGFkIHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5nIGRyYWZ0IG9uIHZwbiBhcHBs aWNhYmlsaXR5IGZvciBkYXRhIGNlbnRlci4gWW91ciBpbnB1dCBvbiB0aGUgZHJhZnQgaXMgYXBw cmVjaWF0ZWQgaW4gbGlnaHQgb2Ygc29tZSBvZiB0aGUgb25nb2luZyBkaXNjdXNzaW9uLiBUaGUg ZHJhZnQgaXMgdGFyZ2V0ZWQgZm9yIGwzdnBuIGFuZCBsMnZwbi4NCkhlcmUgaXMgdGhlIGxpbms6 DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBu LWFwcGxpY2FiaWxpdHktMDENCg0KDQpBYnN0cmFjdA0KDQoNCg0KICAgQ2xvdWQgQ29tcHV0aW5n IGhhcyBiZWVuIGF0dHJhY3RpbmcgYSBsb3Qgb2YgYXR0ZW50aW9uIGZyb20gdGhlDQoNCiAgIG5l dHdvcmtpbmcgaW5kdXN0cnkuIFNvbWUgb2YgdGhlIG1vc3QgcHVibGljaXplZCByZXF1aXJlbWVu dHMgYXJlDQoNCiAgIHJlbGF0ZWQgdG8gdGhlIGV2b2x1dGlvbiBvZiB0aGUgQ2xvdWQgTmV0d29y a2luZyBJbmZyYXN0cnVjdHVyZSB0bw0KDQogICBhY2NvbW1vZGF0ZSBhIGxhcmdlIG51bWJlciBv ZiB0ZW5hbnRzLCBlZmZpY2llbnQgbmV0d29yayB1dGlsaXphdGlvbiwNCg0KICAgc2NhbGFibGUg bG9vcCBhdm9pZGFuY2UsIGFuZCBWaXJ0dWFsIE1hY2hpbmUgTW9iaWxpdHkuDQoNCg0KDQogICBU aGlzIGRyYWZ0IGRlc2NyaWJlcyBhIGZyYW1ld29yayBmb3IgY2xvdWQgbmV0d29ya2luZywgaGln aGxpZ2h0aW5nDQoNCiAgIHRoZSBhcHBsaWNhYmlsaXR5IG9mIGV4aXN0aW5nIHdvcmsgaW4gdmFy aW91cyBJRVRGIFdvcmtpbmcgR3JvdXBzDQoNCiAgIChlLmcuLCBSRkNzIGFuZCBkcmFmdHMgZGV2 ZWxvcGVkIGluIElFVEYgTDJWUE4gYW5kIEwzVlBOIFdvcmtpbmcNCg0KICAgR3JvdXBzKSB0byBj bG91ZCBuZXR3b3JraW5nLCBhbmQgdGhlIGdhcHMgYW5kIHByb2JsZW1zIHRoYXQgbmVlZCB0bw0K DQogICBiZSBmdXJ0aGVyIGFkZHJlc3NlZC4gVGhhdCBpcywgdGhlIGdvYWwgaXMgdG8gdW5kZXJz dGFuZCB3aGF0IG1heSBiZQ0KDQogICByZS11c2VkIGZyb20gdGhlIGN1cnJlbnQgcHJvdG9jb2xz IGFuZCBjYWxsIG91dCByZXF1aXJlbWVudHMgc3BlY2lmaWMNCg0KICAgdG8gdGhlIENsb3VkIHNw YWNlIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgYnkgbmV3IHN0YW5kYXJkaXphdGlvbg0KDQog ICB3b3JrIHdpdGggcHJvcG9zZWQgc29sdXRpb25zIGluIGNlcnRhaW4gY2FzZXMuDQoNCg0KVGhh bmtzLA0KDQpOYWJpbA0K --Boundary_(ID_rOt2fZb4QA4ok2JU0SxtNw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

By the way= , it would be better to push the PBB as close to the end-systems as possibl= e from the perspective of MAC forwarding table scalability. However, the unknown unicast flood impact issue would be worsen accordingl= y. For example, in a normal Layer2 network, if two VMs attached to the give= n ToR are frequently communicated with each other and hence their MAC addre= ss entries on this ToR will not be expired, the traffic destined for any of those two VMs from a remote VM= could be flooded as unknown unicast until the traffic reach this ToR which= in turn forward the traffic to the destination VM in unicast.  Howeve= r, once PBB is performed at each VSw, that traffic would be flooded until it reach the final destination physica= l server.  It=A1=AFs a hard tradeoff, isn=A1=AFt it?=

 = ;

Xiaohu

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: Xuxiaoh= u
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 10:08
=CA=D5=BC=FE=C8=CB: 'Balus, Florin Stelian (Florin)'; Bitar, Nabil N; l3vpn@ietf.org; l= 2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com =D6=F7=CC=E2: re: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

=B7=A2=BC=FE=C8=CB: Balus, = Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 5:34
=CA=D5=BC=FE=C8=CB: Xuxiaohu; Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com =D6=F7=CC=E2: RE: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

Thank= s for the comments, see in-line=A1=AD

=  

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
Cc: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@= bt.com
Subject: re: Your input on the following draft is appreciated: draft= -bitar-datacenter-vpn-applicability-01.txt

 

Hi Nabil,<= o:p>

 = ;

It=A1=AFs = a very comprehensive doc.

 = ;

Some commo= ns:

1=A1=A2  In section 6.1, it said: =A1=B0As t=
he number of tenants in individual VLAN islands surpasses 4K, the operator =
could push VPLS deployment deeper in the DC network=A1=AD. The ToR and DC c=
ore elements need to be MPLS enabled with existing VPLS solutions=A1=B1, IM=
HO, DC core switches don=A1=AFt need to be MPLS enabled since IP based tunn=
el is also available.
 
FB> You are right we should have said =A1=B0IP or MPLS enabled=
=A1=B1 as both cases are possible=A1=AD 
 
<XXH> Good point.
 
2=A1=A2  Still in section 6.1, it said: =A1=
=B1 =A1=ADHowever, this model does not solve the MAC explosion issue as ToR=
s still need to learn VM MAC addresses.=A1=B1 However, in section 6.2.1, it=
 said:=A1=B1=A1=ADAlternatively, the PBB encapsulation can be done at the T=
oR.=A1=B1  It is confused since performing PBB encapsulation at the To=
R would not alleviate the MAC-learning burden on that ToR.
 
FB> Maybe the phrase location is puzzling. The focus of sectio=
n 6.2 is the use of an extended 24b PBB I-ISID tag starting at the VSw to i=
dentify the ELAN broadcast domain. 
 
<XXH> The title of section 6.2.1 is =A1=B0Addressing VLAN spac=
e exhaustion and MAC explosion=A1=B1. So I think saying more words after th=
at sentence is much helpful in avoiding confusion.
 
 
This will maximize the benefits. However in reality it is very li=
kely there will be legacy DC regions still running VLANs which require a Ga=
teway function during the migration. See the VLAN Interop discussion in sec=
tion 6.2.9. 
 
3=A1=A2  In 6.2.=
6.2. PBBN in VSw, L2VPN in the ToR, it said:=A1=B1 The procedures from the previo=
us section are used at the VSw: PBB encapsulation and Ethernet BVLANs can b=
e used on the VSw uplink. L2VPN infrastructure is replacing the BVLAN at th=
e ToR enabling the use of IP (GRE or L2TP) or MPLS tunneling. 
 
FB> This is about the tunneling encapsulation options to be us=
ed in the core: 24b I-SID tag is the common tenant ID which can be transpor=
ted over an Ethernet or an IP or an MPLS based DC network. Combinations of =
these tunneling options are also possible: e.g. one DC may be Ethernet base=
d the other IP based; or the VSw may use Ethernet VLAN tunnels while IP tun=
nels may start at the ToR.
 
<XXH> Yes, I agree with your statement above. Adding the above=
 text into the draft would be much helpfulJ
 
 L2 networking still has the same control plane c=
hoices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], independently from the tunne=
ling choice.=A1=B1 Since PBB encapsulation has already been done on the VSw=
, why do we still need to run 802.1aq and PBB-EVPN with another PBB encapsu=
lation layer?
 
FB> No need for an additional PBB encapsulation layer! This is=
 strictly about control plane options: IS-IS and BGP are used the same way =
as in regular IP routing to perform Multipathing, Fast Convergence, service=
 AD, program the core FIBs etc=A1=AD
 
<XXH> Absolutely agree. Such being the case, why not remove th=
e two specific examples (both of them add another PBB layer) from that sent=
ence so as to eliminate the possible confusion?
 
 Can=A1=AFt we simply use any L2VPN technology, e=
.g., VPLS. In addition, note that in Figure 5, it said =A1=B0intra-DC L2VPN=
 over IP or MPLS tunneling=A1=B1.

 = ;

FB> yes you can. We just focused here on th=
e options that will address the challenges described in the problem stateme=
nt section. Otherwise the content will have grown too much.

 = ;

<XXH>= ; Thanks for your explanation.

=  

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: l2vpn-b= ounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA= =B1=ED Bitar, Nabil N
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5 13:42
=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com =D6=F7=CC=E2: Your input on the following draft is appreciated: draft-bitar-datacenter-= vpn-applicability-01.txt

 

Hi,

We had submi= tted the following draft on vpn applicability for data center. Your input o= n the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the = link: 

 <= /o:p>

 <= /o:p>

Abstract

 


   Cloud Computing ha=
s been attracting a lot of attention from the


   networking industr=
y. Some of the most publicized requirements are


   related to the evo=
lution of the Cloud Networking Infrastructure to


   accommodate a larg=
e number of tenants, efficient network utilization,


   scalable loop avoi=
dance, and Virtual Machine Mobility.


 


   This draft describ=
es a framework for cloud networking, highlighting


   the applicability =
of existing work in various IETF Working Groups


   (e.g., RFCs and dr=
afts developed in IETF L2VPN and L3VPN Working


   Groups) to cloud n=
etworking, and the gaps and problems that need to


   be further address=
ed. That is, the goal is to understand what may be


   re-used from the c=
urrent protocols and call out requirements specific


   to the Cloud space=
 that need to be addressed by new standardization


   work with proposed=
 solutions in certain cases.





Thanks,


Nabil
--Boundary_(ID_rOt2fZb4QA4ok2JU0SxtNw)-- From xuxiaohu@huawei.com Tue Nov 8 19:29: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 383D31F0C51; Tue, 8 Nov 2011 19:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[AWL=-2.548, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnhU3J+lv2Ws; Tue, 8 Nov 2011 19:29:57 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D38341F0C4D; Tue, 8 Nov 2011 19:29:56 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00CQFIYOMH@szxga05-in.huawei.com>; Wed, 09 Nov 2011 11:28:00 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00GCWIYMN3@szxga05-in.huawei.com>; Wed, 09 Nov 2011 11:28:00 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEX43420; Wed, 09 Nov 2011 11:27:58 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 11:27:53 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 11:27:49 +0800 Date: Wed, 09 Nov 2011 03:27:47 +0000 From: Xuxiaohu Subject: =?gb2312?B?tPC4tDogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFw?= =?gb2312?B?cHJlY2lhdGVkOglkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNh?= =?gb2312?Q?bility-01.txt?= In-reply-to: <2691CE0099834E4A9C5044EEC662BB9D118E00D4@dfweml506-mbx> X-Originating-IP: [10.108.4.59] To: Lucy yong , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C99@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FHfWXvmU2MRDXXUc1vGA/w)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAYBJpgABUayqA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2691CE0099834E4A9C5044EEC662BB9D118E00D4@dfweml506-mbx> Cc: Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.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: Wed, 09 Nov 2011 03:29:58 -0000 --Boundary_(ID_FHfWXvmU2MRDXXUc1vGA/w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 DQoNCreivP7IyzogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gTHVjeSB5b25nDQq3osvNyrG85DogMjAxMcTqMTHUwjnI1SAxOjQwDQrK 1bz+yMs6IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCrOt y806IFNhZ2Vzc2k7IHkuaWtlamlyaUBudHQuY29tOyBtaXJjZWEucGlzaWNhQGJ0LmNvbQ0K1vfM 4jogUkU6IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2luZyBkcmFmdCBpcyBhcHByZWNpYXRlZDog ZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0eS0wMS50eHQNCg0KSGkgTmFi aWwgIGFuZCBvdGhlciBjby1hdXRob3JzLA0KDQpGaXJzdCBvZiBhbGwsIHRoaXMgaXMgYSB2ZXJ5 IGdvb2QgZHJhZnQgdG8gZ2F0aGVyIERDIHByb2JsZW0gc3RhdGVtZW50cyBhbmQgZXhwbG9yZSBW UE4gYXBwbGljYWJpbGl0eSBmb3IgY2xvdWQgbmV0d29ya2luZy4gIEdvb2QgaW5mb3JtYXRpb24g Zm9yIHRoZSBjb21tdW5pdHkuIFRoYW5rIHlvdSB2ZXJ5IG11Y2guDQoNClNvbWUgY29tbWVudHM6 DQoNCg0KMSkgICAgICBUaGUgZG9jdW1lbnQgaGFzIGhlYXZ5IGFtb3VudCBwb3J0aW9uIHRvIGRl c2NyaWJlIGFsbCBkaWZmZXJlbnQgdXNlIGNhc2VzIGZvciBQQkIgYnV0IGZldyBzZW50ZW5jZSBm b3IgVFJJTEwgYW5kIEwzVlBOIGFwcGxpY2FiaWxpdHkgaW4gREMuIFN1Z2dlc3QgdG8gZWxhYm9y YXRlIG1vcmUgb24gVFJJTEwgYW5kIEwzVlBOIGNhc2VzLg0KDQo8WFhIPiBJIGd1ZXNzIHBhcnRp YWwgcGFyYWdyYXBocyBpbiBzZWN0aW9uIDUuNS4gobBPcHRpbWFsIHRyYWZmaWMgZm9yd2FyZGlu Z6GxIGRpZCBtZW50aW9uIEwzVlBOIGFwcGxpY2FiaWxpdHkgaW4gREMuIFNwZWNpZmljYWxseSwg dGhlIHBhcmFncmFwaCBzdGFydGluZyB3aXRoIKGwSVAtYmFzZWQgZm9yd2FyZGluZyByZWxpZXMg b24gdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3OhrSBkZXNjcmliZXMgYSBMM1ZQTiBhcHBsaWNh dGlvbiBhcHByb2FjaCBsaWtlIFZpcnR1YWwgU3VibmV0IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC14dS12aXJ0dWFsLXN1Ym5ldC0wNikgYW5kIHRoZSBmb2xsb3dpbmcgcGFyYWdy YXBoIGRlc2NyaWJlcyBhbm90aGVyIEwzVlBOIGFwcGxpY2F0aW9uIGxpa2UgbDN2cG4tZW5kLXN5 c3RlbSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFycXVlcy1sM3Zwbi1lbmQt c3lzdGVtLTAyKS4gTm90ZSB0aGF0IGl0oa9zIGp1c3QgbXkgZ3Vlc3MgdGhhdCBoYXMgbm90IGJl IGNvbmZpcm1lZCB5ZXQgYnkgY28tYXV0aG9ycyBvZiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZw bi1hcHBsaWNhYmlsaXR5LTAxOikNCg0KDQoyKSAgICAgIEl0IGlzIHZlcnkgcG9zc2libGUgdGhh dCBEQyB1c2UgTDJWUE4gYW5kIFdBTiB1c2UgTDNWUE4uICBJdCBpcyBuaWNlIHRoYXQgZG9jdW1l bnQgdGhpcyBhcHBsaWNhYmlsaXR5Lg0KDQo8WFhIPiBpdKGvcyBhIGdvb2Qgb3Bpbmlvbi4gQXMg Zm9yIERDSSwgaG9zdCByb3V0ZSBiYXNlZCBMM1ZQTiBhcHByb2FjaGVzIHdpbGwgYnJpbmcgb3Bl cmF0b3JzIG1vcmUgYXR0cmFjdGl2ZSBhZHZhbnRhZ2VzIGNvbXBhcmVkIHRvIHRob3NlIE1BQyBm b3J3YXJkaW5nIGJhc2VkIEwyVlBOIGFwcHJvYWNoLCBzdWNoIGFzIGJyb2FkY2FzdC9mbG9vZCBp bXBhY3QgZWxpbWluYXRpb24sIE1BQyB0YWJsZSBzY2FsYWJpbGl0eSBvbiBkYXRhIGNlbnRlciBz d2l0Y2hlcywgYW5kIGVzcGVjaWFsbHkgcGF0aCBvcHRpbWl6YXRpb24uDQoNCkJlc3QgcmVnYXJk cywNClhpYW9odQ0KDQoNCjMpICAgICAgUHJvdmlkZXIgREMgYW5kIGVudGVycHJpc2UgREMgbWF5 IGltcGxlbWVudCBkaWZmZXJlbnQgTDJWUE4gb3IgTDNWUE4gdGVjaG5vbG9naWVzLCBpdCBpcyB2 YWx1YWJsZSB0byBkZXNjcmliZSB3aGF0IGtpbmQgb2YgaW50ZXJ3b3JraW5nIHNjZW5hcmlvcyBp cyBhbGxvd2VkIG9yIG5vdCBhbGxvd2VkLg0KDQpCZXN0IFJlZ2FyZHMsDQpMdWN5DQoNCg0KDQpG cm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEJpdGFyLCBOYWJpbCBODQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDA3 LCAyMDExIDExOjQyIFBNDQpUbzogbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQpDYzog U2FnZXNzaTsgbWlyY2VhLnBpc2ljYUBidC5jb207IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5Lmlr ZWppcmlAbnR0LmNvbQ0KU3ViamVjdDogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0 IGlzIGFwcHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5 LTAxLnR4dA0KDQpIaSwNCldlIGhhZCBzdWJtaXR0ZWQgdGhlIGZvbGxvd2luZyBkcmFmdCBvbiB2 cG4gYXBwbGljYWJpbGl0eSBmb3IgZGF0YSBjZW50ZXIuIFlvdXIgaW5wdXQgb24gdGhlIGRyYWZ0 IGlzIGFwcHJlY2lhdGVkIGluIGxpZ2h0IG9mIHNvbWUgb2YgdGhlIG9uZ29pbmcgZGlzY3Vzc2lv bi4gVGhlIGRyYWZ0IGlzIHRhcmdldGVkIGZvciBsM3ZwbiBhbmQgbDJ2cG4uDQpIZXJlIGlzIHRo ZSBsaW5rOg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXRhci1kYXRhY2Vu dGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxDQoNCg0KQWJzdHJhY3QNCg0KDQoNCiAgIENsb3VkIENv bXB1dGluZyBoYXMgYmVlbiBhdHRyYWN0aW5nIGEgbG90IG9mIGF0dGVudGlvbiBmcm9tIHRoZQ0K DQogICBuZXR3b3JraW5nIGluZHVzdHJ5LiBTb21lIG9mIHRoZSBtb3N0IHB1YmxpY2l6ZWQgcmVx dWlyZW1lbnRzIGFyZQ0KDQogICByZWxhdGVkIHRvIHRoZSBldm9sdXRpb24gb2YgdGhlIENsb3Vk IE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUgdG8NCg0KICAgYWNjb21tb2RhdGUgYSBsYXJnZSBu dW1iZXIgb2YgdGVuYW50cywgZWZmaWNpZW50IG5ldHdvcmsgdXRpbGl6YXRpb24sDQoNCiAgIHNj YWxhYmxlIGxvb3AgYXZvaWRhbmNlLCBhbmQgVmlydHVhbCBNYWNoaW5lIE1vYmlsaXR5Lg0KDQoN Cg0KICAgVGhpcyBkcmFmdCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgZm9yIGNsb3VkIG5ldHdvcmtp bmcsIGhpZ2hsaWdodGluZw0KDQogICB0aGUgYXBwbGljYWJpbGl0eSBvZiBleGlzdGluZyB3b3Jr IGluIHZhcmlvdXMgSUVURiBXb3JraW5nIEdyb3Vwcw0KDQogICAoZS5nLiwgUkZDcyBhbmQgZHJh ZnRzIGRldmVsb3BlZCBpbiBJRVRGIEwyVlBOIGFuZCBMM1ZQTiBXb3JraW5nDQoNCiAgIEdyb3Vw cykgdG8gY2xvdWQgbmV0d29ya2luZywgYW5kIHRoZSBnYXBzIGFuZCBwcm9ibGVtcyB0aGF0IG5l ZWQgdG8NCg0KICAgYmUgZnVydGhlciBhZGRyZXNzZWQuIFRoYXQgaXMsIHRoZSBnb2FsIGlzIHRv IHVuZGVyc3RhbmQgd2hhdCBtYXkgYmUNCg0KICAgcmUtdXNlZCBmcm9tIHRoZSBjdXJyZW50IHBy b3RvY29scyBhbmQgY2FsbCBvdXQgcmVxdWlyZW1lbnRzIHNwZWNpZmljDQoNCiAgIHRvIHRoZSBD bG91ZCBzcGFjZSB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGJ5IG5ldyBzdGFuZGFyZGl6YXRp b24NCg0KICAgd29yayB3aXRoIHByb3Bvc2VkIHNvbHV0aW9ucyBpbiBjZXJ0YWluIGNhc2VzLg0K DQoNClRoYW5rcywNCg0KTmFiaWwNCg== --Boundary_(ID_FHfWXvmU2MRDXXUc1vGA/w) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: l3vpn-b= ounces@ietf.org [mailto:l3vpn-bounces@ietf.org] =B4=FA= =B1=ED Lucy yong
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 1:40
=CA=D5=BC=FE=C8=CB: Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
=D6=F7=CC=E2: RE: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

Hi Nabil&n= bsp; and other co-authors,

 = ;

First of a= ll, this is a very good draft to gather DC problem statements and explore V= PN applicability for cloud networking.  Good information for the community. Thank you very much.

 = ;

Some comme= nts:

 = ;

1)      Th= e document has heavy amount portion to describe all different use cases for= PBB but few sentence for TRILL and L3VPN applicability in DC. Suggest to elaborate more on TRILL and L3VPN cases.

 = ;

<XXH>= ; I guess partial paragraphs in section 5.5. =A1=B0Optimal traffic forwarding=A1=B1 did= mention L3VPN applicability in DC. Specifically, the paragraph starting wi= th =A1=B0IP-based forwarding relies on the destination IP address=A1=AD des= cribes a L3VPN application approach like Virtual Subnet (http://tools.ietf.org/html/draft-xu-virtual-subnet-06) and the following = paragraph describes another L3VPN application like l3vpn-end-system (http://t= ools.ietf.org/html/draft-marques-l3vpn-end-system-02). Note that it=A1=AFs just my guess that has not be confirmed yet by co-auth= ors of draft-bitar-datacenter-vpn-applicability-01J<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Calibri&quo= t;,"sans-serif";color:#1F497D">

 = ;

2)      It= is very possible that DC use L2VPN and WAN use L3VPN.  It is nice tha= t document this applicability.

 = ;

<XXH>= ; it=A1=AFs a good opinion. As for DCI, host route based L3VPN approaches w= ill bring operators more attractive advantages compared to those MAC forwarding based L2VPN approach, such as broadcast/flood impact eliminatio= n, MAC table scalability on data center switches, and especially path optim= ization.

 = ;

Best regar= ds,

Xiaohu

 = ;

3)      Pr= ovider DC and enterprise DC may implement different L2VPN or L3VPN technolo= gies, it is valuable to describe what kind of interworking scenarios is allowed or not allowed.

 = ;

Best Regar= ds,

Lucy<= /o:p>

 = ;

 = ;

 = ;

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Bitar, Nabil N
Sent: Monday, November 07, 2011 11:42 PM
To: l3vpn@ietf.org; l2vpn@ietf.org
Cc: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@n= tt.com
Subject: Your input on the following draft is appreciated: draft-bit= ar-datacenter-vpn-applicability-01.txt

 

Hi,

We had submi= tted the following draft on vpn applicability for data center. Your input o= n the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the = link: 

 <= /o:p>

 <= /o:p>

Abstract
 
   Cloud Computing has been attracting a=
 lot of attention from the
   networking industry. Some of the most=
 publicized requirements are
   related to the evolution of the Cloud=
 Networking Infrastructure to
   accommodate a large number of tenants=
, efficient network utilization,
   scalable loop avoidance, and Virtual =
Machine Mobility.
 
   This draft describes a framework for =
cloud networking, highlighting
   the applicability of existing work in=
 various IETF Working Groups
   (e.g., RFCs and drafts developed in I=
ETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the =
gaps and problems that need to
   be further addressed. That is, the go=
al is to understand what may be
   re-used from the current protocols an=
d call out requirements specific
   to the Cloud space that need to be ad=
dressed by new standardization
   work with proposed solutions in certa=
in cases.

 
Thanks,
Nabil
--Boundary_(ID_FHfWXvmU2MRDXXUc1vGA/w)-- From linda.dunbar@huawei.com Wed Nov 9 11:32:06 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 241BE11E808B; Wed, 9 Nov 2011 11:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=-0.127, 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 UHe7IPEz0YeJ; Wed, 9 Nov 2011 11:32:05 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 78E3E11E8089; Wed, 9 Nov 2011 11:32:05 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUE00B5VRLA9K@usaga04-in.huawei.com>; Wed, 09 Nov 2011 13:31:59 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUE009U3RKV0G@usaga04-in.huawei.com>; Wed, 09 Nov 2011 13:31:58 -0600 (CST) 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; Wed, 09 Nov 2011 11:31:39 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 11:31:33 -0800 Date: Wed, 09 Nov 2011 19:31:33 +0000 From: Linda Dunbar Subject: Need your action to review draft-ietf-armd-problem-statement-00.txt X-Originating-IP: [10.192.11.155] To: "l2vpn@ietf.org" , L3VPN WG mailing list , "sdnp@lucidvision.com" Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A)" Content-language: en-US Accept-Language: en-US Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMnxYw0sp2lA3FXUyNvGuBDlwwdw== X-MS-Has-Attach: yes 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: Wed, 09 Nov 2011 19:32:06 -0000 --Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A) Content-type: multipart/alternative; boundary="Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ)" --Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT For those of you who touch upon Data Center networking or server virtualization, be it Overlay, VPN4DC, or Application/Software driven Controller for Data Center, Address Resolution is something Data Center Gateways will encounter because hosts/applications in data centers do communicate with peers which are not in the same Overlay, outside the VPN domain, or from general public. ARMD has published its WG problem statement draft. Your comments and suggestions are appreciated (send to armd@ietf.org). Thanks, Linda Dunbar ----------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Address Resolution for Massive numbers of hosts in the Data center Working Group of the IETF. Title : Problem Statement for ARMD Author(s) : Thomas Narten Filename : draft-ietf-armd-problem-statement-00.txt Pages : 11 Date : 2011-10-17 This document examines issues related to the massive scaling of data centers. Our initial scope is relatively narrow. Specifically, we focus on address resolution (ARP and ND) within the data center. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-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-ietf-armd-problem-statement-00.txt --Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

For those of you who t= ouch upon Data Center networking or server virtualization, be it Overlay, V= PN4DC, or Application/Software driven Controller for Data Center, Address R= esolution is something Data Center Gateways  will encounter because hosts/applications in data centers do communi= cate with peers which are not in the same Overlay, outside the VPN domain, = or from general public. ARMD has published its WG problem statement draft. = Your comments and suggestions are appreciated (send to armd@ietf.org). <= /span>

 

Thanks, Linda Dunbar

 

----------------------= -------------------------------------------------------------

 

 

A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories. This draft is a work item of the Address Resolution for Massive n=
umbers of hosts in the Data center Working Group of the IETF.

 


        Title   &nbs=
p;       : Problem Statement for ARMD


        Author(s)   =
    : Thomas Narten


        Filename   &=
nbsp;    : draft-ietf-armd-problem-statement-00.txt


        Pages   &nbs=
p;       : 11


        Date    =
;        : 2011-10-17


 


   This document examines issues related to the massive scal=
ing of data


   centers.  Our initial scope is relatively narrow.&nb=
sp; Specifically, we


   focus on address resolution (ARP and ND) within the data =
center.


 


 


A URL for this Internet-Draft is:


http://www.ietf.org/internet-drafts/draft-ietf-armd-prob=
lem-statement-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-ietf-armd-proble=
m-statement-00.txt


 
--Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ)-- --Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A) Content-id: <318D3282CFCD0C45A8C99283FF38289A@huawei.com> Content-type: text/plain; name=ATT00001.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00001.txt; size=127; creation-date="Fri, 04 Nov 2011 15:30:31 GMT"; modification-date="Fri, 04 Nov 2011 15:30:31 GMT" Content-description: ATT00001.txt _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd --Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A)-- From pedro.r.marques@gmail.com Wed Nov 9 11:52:02 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 EEB8C21F848C; Wed, 9 Nov 2011 11:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+0pq750uVCR; Wed, 9 Nov 2011 11:52:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47F9621F848A; Wed, 9 Nov 2011 11:52:02 -0800 (PST) Received: by iaeo4 with SMTP id o4so2690124iae.31 for ; Wed, 09 Nov 2011 11:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=a79ejb1F58MgUgbAyMDMUHkCJYubn5OSVkDuL0yNKbs=; b=XrppjTzzMJG+jmuZ3DPrM1xm5EBhM+vIHQEBU9OPx74qEhYR9ITIqiWuzRJwGZGfNA UWuYx5MWFg7eEZ13QkN/KocjK+Cyz6dfRhxXW6R2Zz9zbopnnJH2M7q9EVIbj5tLFv2S ds0azcAWRSkK0tOBbH9G+gA3ETLr6ZdzhPmL8= MIME-Version: 1.0 Received: by 10.231.83.201 with SMTP id g9mr1053454ibl.68.1320868320096; Wed, 09 Nov 2011 11:52:00 -0800 (PST) Received: by 10.231.12.2 with HTTP; Wed, 9 Nov 2011 11:52:00 -0800 (PST) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> Date: Wed, 9 Nov 2011 11:52:00 -0800 Message-ID: Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt From: Pedro Marques To: Linda Dunbar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , armd@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, 09 Nov 2011 19:52:03 -0000 Linda, I'd like to point out that the problem does not need to be solved if only IP connectivity is required. This I-D: http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 describes a solution in which address resolution is not required irrespective of the location of the traffic destination. Simply put, traffic can be routed at each hop. As per previous threads in this list, the concept of subnet which is of no practical usefulness in this space. Since VMs can be randomly distributed across the network the subnet does not provide any information aggregation value. Thus there is no need to do address resolution. Pedro. On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar wro= te: > For those of you who touch upon Data Center networking or server > virtualization, be it Overlay, VPN4DC, or Application/Software driven > Controller for Data Center, Address Resolution is something Data Center > Gateways =A0will encounter because hosts/applications in data centers do > communicate with peers which are not in the same Overlay, outside the VPN > domain, or from general public. ARMD has published its WG problem stateme= nt > draft. Your comments and suggestions are appreciated (send to > armd@ietf.org). > > > > Thanks, Linda Dunbar > > > > -------------------------------------------------------------------------= ---------- > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Address Resolution for Mass= ive > numbers of hosts in the Data center Working Group of the IETF. > > > > =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Problem State= ment for ARMD > > =A0=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : Thomas Narten > > =A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-ietf-armd-pro= blem-statement-00.txt > > =A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 11 > > =A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-10-17 > > > > =A0=A0 This document examines issues related to the massive scaling of da= ta > > =A0=A0 centers.=A0 Our initial scope is relatively narrow.=A0 Specificall= y, we > > =A0=A0 focus on address resolution (ARP and ND) within the data center. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-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-ietf-armd-problem-statement-00.t= xt > > From linda.dunbar@huawei.com Wed Nov 9 12:12: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 8DB191F0C43; Wed, 9 Nov 2011 12:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.821 X-Spam-Level: X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=-0.422, 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 kj6hzNo6IzUQ; Wed, 9 Nov 2011 12:12:25 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id DDE341F0C41; Wed, 9 Nov 2011 12:12:25 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUE00B35TGH9K@usaga04-in.huawei.com>; Wed, 09 Nov 2011 14:12:18 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUE0096HTGE0G@usaga04-in.huawei.com>; Wed, 09 Nov 2011 14:12:17 -0600 (CST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 12:12:11 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 12:11:58 -0800 Date: Wed, 09 Nov 2011 20:12:08 +0000 From: Linda Dunbar Subject: RE: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: X-Originating-IP: [10.192.11.155] To: Pedro Marques Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMnxkRlZozan+p5EmwsYAz13twApWk988g X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@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, 09 Nov 2011 20:12:26 -0000 Pedro,=20 You are absolutely right that there is no ARP/ND scaling issue if IP can be= extended to hosts. Even if IP can be extended to Access switches, there is= not much ARP/ND issues.=20 The draft lists down several common data center network designs, and states= that some of the designs don't have ARP/ND scaling issues (but may have ot= her issues for data centers).=20 That is why I encourage people to read the draft and provides comments.=20 Linda=20 > -----Original Message----- > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > Sent: Wednesday, November 09, 2011 1:52 PM > To: Linda Dunbar > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; > armd@ietf.org > Subject: Re: Need your action to review draft-ietf-armd-problem- > statement-00.txt >=20 > Linda, > I'd like to point out that the problem does not need to be solved if > only IP connectivity is required. This I-D: > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 describes > a solution in which address resolution is not required irrespective of > the location of the traffic destination. Simply put, traffic can be > routed at each hop. >=20 > As per previous threads in this list, the concept of subnet which is > of no practical usefulness in this space. Since VMs can be randomly > distributed across the network the subnet does not provide any > information aggregation value. Thus there is no need to do address > resolution. >=20 > Pedro. >=20 > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar > wrote: > > For those of you who touch upon Data Center networking or server > > virtualization, be it Overlay, VPN4DC, or Application/Software driven > > Controller for Data Center, Address Resolution is something Data > Center > > Gateways =A0will encounter because hosts/applications in data centers > do > > communicate with peers which are not in the same Overlay, outside the > VPN > > domain, or from general public. ARMD has published its WG problem > statement > > draft. Your comments and suggestions are appreciated (send to > > armd@ietf.org). > > > > > > > > Thanks, Linda Dunbar > > > > > > > > --------------------------------------------------------------------- > -------------- > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Address Resolution for > Massive > > numbers of hosts in the Data center Working Group of the IETF. > > > > > > > > =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Problem Sta= tement for ARMD > > > > =A0=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : Thomas Narten > > > > =A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-ietf-armd-p= roblem-statement-00.txt > > > > =A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 11 > > > > =A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-10-1= 7 > > > > > > > > =A0=A0 This document examines issues related to the massive scaling of > data > > > > =A0=A0 centers.=A0 Our initial scope is relatively narrow.=A0 Specifica= lly, > we > > > > =A0=A0 focus on address resolution (ARP and ND) within the data center. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- > statement-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-ietf-armd-problem-statement- > 00.txt > > > > From pedro.r.marques@gmail.com Wed Nov 9 14:20: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 62F1C11E8090; Wed, 9 Nov 2011 14:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.668, 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 6eIqHnYlZcmd; Wed, 9 Nov 2011 14:20:55 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D81611E8080; Wed, 9 Nov 2011 14:20:55 -0800 (PST) Received: by iaeo4 with SMTP id o4so2843009iae.31 for ; Wed, 09 Nov 2011 14:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oLwP+ID7yPLVTzPY5yfEGHdExfYTow5LSJdpXQW50Bc=; b=q9ndhoGRRWmmmWeaFlPgfndDnMilZljIqv1diOLeVSujVqVXKbU+IQvuGU1T7cVEKF 7lVlo2ZM6Bsrfjag/b17cGCzCkLb6eamGpxuIMZePTVtv6tCIYoCgM2OjHq3Thp8yQNm pcdkPoWZQJS6Epg1TICS3eZEWjU+Ozw5vD7R0= MIME-Version: 1.0 Received: by 10.42.72.135 with SMTP id o7mr5031566icj.45.1320877253259; Wed, 09 Nov 2011 14:20:53 -0800 (PST) Received: by 10.231.12.2 with HTTP; Wed, 9 Nov 2011 14:20:53 -0800 (PST) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> Date: Wed, 9 Nov 2011 14:20:53 -0800 Message-ID: Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt From: Pedro Marques To: Linda Dunbar Content-Type: text/plain; charset=ISO-8859-1 Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@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, 09 Nov 2011 22:20:56 -0000 Linda, Please see inline. On Wed, Nov 9, 2011 at 12:12 PM, Linda Dunbar wrote: > Pedro, > > You are absolutely right that there is no ARP/ND scaling issue if IP can be extended to hosts. Even if IP can be extended to Access switches, there is not much ARP/ND issues. The draft is a bit unclear in terms of its assumptions regarding the connectivity of the VMs. It does state that the VMs typically have their own IP and mac addresses but doesn't mention that these are typically also associated with different VLANs. There are multiple proposals (e.g. VXLAN) in which these VLANs are data-center wide. Thus if the VM sees a LAN adjacency to its "subnet" there is an ARP/ND issue to solve. VXLAN for instance assumes that ARP requests will be broadcasted using IP multicast groups per VLAN. You may want to characterize the several 'categories' of proposals that satisfy the requirements of VM mobility and closed user group isolation. For example: L2 approaches: (e.g. VXLAN) These tend towards creating a data-center wide broadcast domain. The broadcast domain can then be used to send ARP/ND requests. Routed L2/L3 approaches (e.g. EVPN): Present an L2 interface to the VM but transform it to a routed approach in a network element and advertise mac (optionally) + ip host prefixes from the network elements. An important sub category here is whether these solutions then assume multicast capability or not in the underlying network. Host based approaches. These can present either an L2 or L3 "service" and assume or not the presence of an underlying multicast service on the part of the underlying "fabric" network. Map service based approaches: Use a query based mechanism rather than a "push" based mechanism like routing to distributed the overlay network information. Each of these has its own way to address ARP/ND related issues. If you your intent is to document the possibilities there is plenty of options to choose from. :-) Pedro. From pe-jiang@kddilabs.jp Thu Nov 10 01:49: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 6523421F888A for ; Thu, 10 Nov 2011 01:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hemv9WVnt0dh for ; Thu, 10 Nov 2011 01:49:03 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id CB79921F8AE6 for ; Thu, 10 Nov 2011 01:49:00 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 505681748163; Thu, 10 Nov 2011 18:48:52 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGfFdR2Op4bF; Thu, 10 Nov 2011 18:48:51 +0900 (JST) Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [172.19.98.10]) by mandala.kddilabs.jp (Postfix) with ESMTP id 88B881748153; Thu, 10 Nov 2011 18:48:51 +0900 (JST) Received: from [172.19.124.102] (dhcp102.west-4f.cn.kddilabs.jp [172.19.124.102]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id 71DD11E0002; Thu, 10 Nov 2011 18:48:51 +0900 (JST) Message-ID: <4EBB9DC8.2020700@kddilabs.jp> Date: Thu, 10 Nov 2011 18:47:52 +0900 From: Peng JIANG User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: l3vpn@ietf.org Subject: Updates on draft-kumaki-murai-l3vpn-rsvp-te-04 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: satoru.matsushima@tm.softbank.co.jp, Dean cheng , Kenji Kumaki 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, 10 Nov 2011 09:49:04 -0000 Hi all, We've submitted an updated version of draft-kumaki-murai-l3vpn-rsvp-te: http://tools.ietf.org/html/draft-kumaki-murai-l3vpn-rsvp-te-04 The above document defines new RSVP-TE extensions to support multiple MPLS-TE LSPs in different BGP/MPLS IP-VPNs that are interconnected via the same Provider Edge (PE) routers. Furukawa Network Solution Corporation (FNSC) has implemented this feature. Huawei and Softbank are interested in this I-D and has joined as co-authors. We have also updated text for clarity and readability. -Cleaned up the abstract -Rewrote some of the introduction text to clarify application and intention of the document -Clarified motivation and network example -Various edits and nits We are planning to request the WG to accept this I-D as a WG document at the TAIPEI meeting. Please provide comments and feedback. Thanks. Best Regards, -- PENG JIANG KDDI R&D LABS TEL: +81-49-278-7879 E-mail: pe-jiang@kddilabs.jp From narten@us.ibm.com Thu Nov 10 08:00:06 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 12F4521F8B1F for ; Thu, 10 Nov 2011 08:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.339 X-Spam-Level: X-Spam-Status: No, score=-106.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyzUrBUIsU-X for ; Thu, 10 Nov 2011 08:00:05 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 589BD21F8B45 for ; Thu, 10 Nov 2011 08:00:05 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 10 Nov 2011 10:49:47 -0500 Received: from d01relay03.pok.ibm.com ([9.56.227.235]) by e8.ny.us.ibm.com ([192.168.1.108]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 10 Nov 2011 10:49:45 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAAFniJO269046; Thu, 10 Nov 2011 10:49:44 -0500 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAAFneMY021246; Thu, 10 Nov 2011 08:49:41 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-211-231.mts.ibm.com [9.65.211.231]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pAAFndTb021036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Nov 2011 08:49:40 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pAAFnajV013933; Thu, 10 Nov 2011 10:49:37 -0500 Message-Id: <201111101549.pAAFnajV013933@cichlid.raleigh.ibm.com> To: Pedro Marques Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> Comments: In-reply-to Pedro Marques message dated "Wed, 09 Nov 2011 14:20:53 -0800." Date: Thu, 10 Nov 2011 10:49:36 -0500 From: Thomas Narten x-cbid: 11111015-9360-0000-0000-0000007CF0E1 Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , "armd@ietf.org" , L3VPN WG mailing list 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, 10 Nov 2011 16:00:06 -0000 Hi Pedro. > The draft is a bit unclear in terms of its assumptions regarding the > connectivity of the VMs. It does state that the VMs typically have > their own IP and mac addresses but doesn't mention that these are > typically also associated with different VLANs. Fair enough. I'll look at clarifying this in the next version (though I'm not sure right off how it changes anything). > There are multiple proposals (e.g. VXLAN) in which these VLANs are > data-center wide. Thus if the VM sees a LAN adjacency to its "subnet" > there is an ARP/ND issue to solve. VXLAN for instance assumes that ARP > requests will be broadcasted using IP multicast groups per VLAN. I don't think it is quite right to say that VXLAN uses "data center wide VLANs". VXLAN (and overlay approaches in general) use their own instance identifier space. It is conceptually like a VLAN (in that it groups together related servers). But it is not the same as a VLAN, and using that terminology in the context of VXLAN is probably going to confuse folk. > You may want to characterize the several 'categories' of proposals > that satisfy the requirements of VM mobility and closed user group > isolation. > For example: > L2 approaches: (e.g. VXLAN) > These tend towards creating a data-center wide broadcast domain. The > broadcast domain can then be used to send ARP/ND requests. Correct. But there are also optimizations that can be done (like Proxy ARP) to limit the need to actually broadcast. > Routed L2/L3 approaches (e.g. EVPN): > Present an L2 interface to the VM but transform it to a routed > approach in a network element and advertise mac (optionally) + ip host > prefixes from the network elements. An important sub category here is > whether these solutions then assume multicast capability or not in the > underlying network. And how is VXLAN not a routed approach? It presents an L2 interface to the VM, but everything is routed at L3 from the switch on out. The main differences I see between EVPN and overlay approachs like VXLAN are: 1) VXLAN goes all the way to the hypervisor. It's only the VM->Hypervisor "link" that is L2. 2) VXLAN uses a different control plane (e.g., IEEE 802 approach) whereas EVPN appears to be BGP based. > Host based approaches. > These can present either an L2 or L3 "service" and assume or not the > presence of an underlying multicast service on the part of the > underlying "fabric" network. Not sure what you mean here. Is this where the Host (VM) itself is aware of the service and interacts directly with it? And wouldn't that require host changes, which IMO is pretty much a non-starter? > Map service based approaches: > Use a query based mechanism rather than a "push" based mechanism > like routing to distributed the overlay network information. > Each of these has its own way to address ARP/ND related issues. If you > your intent is to document the possibilities there is plenty of > options to choose from. :-) Indeed! Thomas From pedro.r.marques@gmail.com Thu Nov 10 08:59: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 1805621F8AE6; Thu, 10 Nov 2011 08:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.964 X-Spam-Level: X-Spam-Status: No, score=-2.964 tagged_above=-999 required=5 tests=[AWL=0.635, 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 94guZtq+udAm; Thu, 10 Nov 2011 08:59:38 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABED21F8B30; Thu, 10 Nov 2011 08:59:37 -0800 (PST) Received: by iaeo4 with SMTP id o4so4079457iae.31 for ; Thu, 10 Nov 2011 08:59:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LU8FDDxDJ46LSZ4l5YTLLqvBzdTycUTucfP/wNvyHz0=; b=pd8QEP0XKG+x1SKbqvh95zxTV31M/PkgAVyDzq+j3sBC3UzxptgmdooDGdAGjH5rB+ kOdHosQNrm4F9//e9mf8hJ3q/KUOSUN5CTru8485wDg+jPGykvYYywepO04gGu+juijL CQc6O4L/gu9ORpgCkiObVcRNPOpn9jI5PmEjs= MIME-Version: 1.0 Received: by 10.231.84.135 with SMTP id j7mr1996731ibl.81.1320944377485; Thu, 10 Nov 2011 08:59:37 -0800 (PST) Received: by 10.231.12.2 with HTTP; Thu, 10 Nov 2011 08:59:37 -0800 (PST) In-Reply-To: <201111101549.pAAFnajV013933@cichlid.raleigh.ibm.com> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> <201111101549.pAAFnajV013933@cichlid.raleigh.ibm.com> Date: Thu, 10 Nov 2011 08:59:37 -0800 Message-ID: Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt From: Pedro Marques To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , "armd@ietf.org" , L3VPN WG mailing list 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, 10 Nov 2011 16:59:39 -0000 Thomas, On Thu, Nov 10, 2011 at 7:49 AM, Thomas Narten wrote: >> There are multiple proposals (e.g. VXLAN) in which these VLANs are >> data-center wide. Thus if the VM sees a LAN adjacency to its "subnet" >> there is an ARP/ND issue to solve. VXLAN for instance assumes that ARP >> requests will be broadcasted using IP multicast groups per VLAN. > > I don't think it is quite right to say that VXLAN uses "data center > wide VLANs". =A0VXLAN (and overlay approaches in general) use their own > instance identifier space. It is conceptually like a VLAN (in that it > groups together related servers). But it is not the same as a VLAN, > and using that terminology in the context of VXLAN is probably going > to confuse folk. The proposal uses a data-center wide broadcast domain. In common terminology people often refer to a broadcast domain as a VLAN. > >> You may want to characterize the several 'categories' of proposals >> that satisfy the requirements of VM mobility and closed user group >> isolation. > >> For example: > >> L2 approaches: (e.g. VXLAN) >> =A0 These tend towards creating a data-center wide broadcast domain. The >> broadcast domain can then be used to send ARP/ND requests. > > Correct. But there are also optimizations that can be done (like Proxy > ARP) to limit the need to actually broadcast. It depends on what action is taken when a VM moves. In what i'm labeling as an "L2 based" approach a VM move is handled by generating a gratuitous ARP reply to update all ARP caches and learning tables. If that is the VM move update mechanism proxy ARP cannot be used. > >> Routed L2/L3 approaches (e.g. EVPN): > >> =A0 Present an L2 interface to the VM but transform it to a routed >> approach in a network element and advertise mac (optionally) + ip host >> prefixes from the network elements. An important sub category here is >> whether these solutions then assume multicast capability or not in the >> underlying network. > > And how is VXLAN not a routed approach? It presents an L2 interface to > the VM, but everything is routed at L3 from the switch on out. The addresses of the overlay network are learned by the egress switches and it depends on a broadcast domain. It sees the underlying "fabric" network as a LAN. This is in contrast with approach in which the information regarding the overlay network is advertised via routing protocols (your get your choice of ISIS variants and BGP). > > The main differences I see between EVPN and overlay approachs like > VXLAN are: > > 1) VXLAN goes all the way to the hypervisor. It's only the > VM->Hypervisor "link" that is L2. > > 2) VXLAN uses a different control plane (e.g., IEEE 802 approach) > whereas EVPN appears to be BGP based. VXLAN treats the underlying DC fabric network as a LAN. And uses learning on the data plane. EVPN only "learns" on the edge facing interface. This has consequences on VM moves for instance. In the second case the move can be done as a "route advertisement". It also has consequences on the operational state. With a learning based approach the actual state of the network is just valid at that precise moment. Which makes it very difficult to understand whether the state is correct or not. That is common with all data-driven approaches. > >> Host based approaches. >> =A0 These can present either an L2 or L3 "service" and assume or not the >> presence of an underlying multicast service on the part of the >> underlying "fabric" network. > > Not sure what you mean here. Is this where the Host (VM) itself is > aware of the service and interacts directly with it? And wouldn't that > require host changes, which IMO is pretty much a non-starter? The Host OS / hypervisor. Not the Guest VM. It is a common practice that the network stack of the host OS is a special purpose stack (e.g. vSwitch style approaches). The network stack is not the only aspect of the VM hosting software that is modified to support this class of applications. Pedro. From lucy.yong@huawei.com Sat Nov 12 13:40: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 D758021F87C2 for ; Sat, 12 Nov 2011 13:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.638 X-Spam-Level: X-Spam-Status: No, score=-5.638 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 0JOffju-n4MT for ; Sat, 12 Nov 2011 13:40:28 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id E8EF321F8672 for ; Sat, 12 Nov 2011 13:40:27 -0800 (PST) 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 <0LUK00KQNHJDYX@usaga02-in.huawei.com> for l3vpn@ietf.org; Sat, 12 Nov 2011 15:40:26 -0600 (CST) 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 <0LUK00I10HJDPO@usaga02-in.huawei.com> for l3vpn@ietf.org; Sat, 12 Nov 2011 15:40:25 -0600 (CST) 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; Sat, 12 Nov 2011 13:40:16 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Sat, 12 Nov 2011 13:40:16 -0800 Date: Sat, 12 Nov 2011 21:40:15 +0000 From: Lucy yong Subject: RE: [vpn4dc] Question on the problem In-reply-to: <1320196237.96003.YahooMailNeo@web161803.mail.bf1.yahoo.com> X-Originating-IP: [10.47.117.192] To: Derick Winkworth , "robert@raszuk.net" Message-id: <2691CE0099834E4A9C5044EEC662BB9D118E10CC@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Av8lW409XgN6RwjqjO40cQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [vpn4dc] Question on the problem Thread-index: AQHMmCjvzeXzAwYHcUWsWnPF/T1vrJWYvmyAgAAHaQCAAASigIAAD/gAgABGJ4CAAAWHAIAAF1+AgA7WrmA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> <4EB04576.1010905@raszuk.net> <1320190031.96972.YahooMailNeo@web161801.mail.bf1.yahoo.com> <4EB084F2.8030702@raszuk.net> <1320196237.96003.YahooMailNeo@web161803.mail.bf1.yahoo.com> Cc: L3VPN , Fred Baker 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: Sat, 12 Nov 2011 21:40:29 -0000 --Boundary_(ID_Av8lW409XgN6RwjqjO40cQ) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT I really like what Derick describes below. This is exactly the first goal we want to achieve in VPN4DC. I really wish to read this mail early. Summary is here: A MPLS network operator, the tenant's private networks already exist at the edge of my data center in the form of virtual-routers. My customers would like the VMs I provisions for them to appear native to their L3VPN network. I, on the other hand, would like to automate turning up a VM and attaching it to a customers L3VPN so it appears native to their private network and provide the same illusion of simplicity to my tenant. End. The problem statement is that existing L3VPN protocols can not support automate turning up a VM and attaching it to a customers L3VPN. Thanks Derick. Hope people can reach the same view and agree the value to work on this. Cheers, Lucy From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Derick Winkworth Sent: Tuesday, November 01, 2011 8:11 PM To: robert@raszuk.net Cc: L3VPN; Fred Baker Subject: Re: [vpn4dc] Question on the problem Answers in-line. ________________________________ From: Robert Raszuk To: Derick Winkworth Cc: Pedro Marques ; L3VPN ; Fred Baker Sent: Tuesday, November 1, 2011 6:46 PM Subject: Re: [vpn4dc] Question on the problem Hi Derick, Very glad you have asked. ---------- When I establish a VPN from any of my hosts, from my CE router(s) or from my smartphones I do not tell my providers that I need my device to securely participate in the VPN. ---------- Your VPN is implied. Your VMs are not able to directly communicate with the VMs of another of Google's customers by default. I wonder how Google achieves this separation... ----- I fail to see why adding VM to any VPN would need to be any harder or any different than the examples provided above. ---- The complexity is hidden from you in the case of Google or Amazon. It would be hidden from the tenant in the case of VPN4DC. the difference is that, as a MPLS network operator, the tenant's private networks already exist at the edge of my data center in the form of virtual-routers. My customers would like the VMs I provision for them to appear native to their L3VPN network. Think virtual-datacenter for private networks. ---------- Note that VMs can be short lived and placed in arbitrary data center locations on the network. Who do you tell that you need to join a VPN ? ---------- The tenant tells noone. I, on the other hand, would like to automate turning up a VM and attaching it to a customers L3VPN so it appears native to their private network and provide the same illusion of simplicity to my tenant as Google or Amazon provides to customers who find internet-based cloud services acceptable. ------- In other words if I would like to buy a VM resources from any cloud providers (for example: Amazon, Google ...) all I should need is to log in to such VPN and establish a VPN connection to the rest of my enterprise network - smartphones included. ---------- You realize there is more going on under the hood in your example than you have indicated? Thx, R. > Robert: > > ########## That is in fact another reason why such VPN isolation > should rather not require configuration of number of other elements > then VMs itself. > > ######### > > Can you elaborate on this statement? On the face of it, I could not > disagree more. We absolutely want to containerize VMs in the network > and not have any dependencies at all on configuration within the VM > itself.. > > Derick --Boundary_(ID_Av8lW409XgN6RwjqjO40cQ) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

I really like what  Derick describ= es below. This is exactly the first goal we want to achieve in VPN4DC. &nbs= p;I really wish to read this mail early.

 

Summary is here:

 <= /p>

A MPLS network operator,= the tenant's private networks already exist at the edge of my data center = in the form of virtual-routers.  My customers would like the VMs I pro= visions for them to appear native to their L3VPN network.

 =

I, on the other hand, wo= uld like to automate turning up a VM and attaching it to a customers L3VPN = so it appears native to their private network and provide the same illusion= of simplicity to my tenant.

 =

End.

 =

The problem statement is= that existing L3VPN protocols can not support automate turning up a VM and= attaching it to a customers L3VPN.

 =

Thanks Derick. Hope peop= le can reach the same view and agree the value to work on this.<= /span>

 =

Cheers,

Lucy

 =

 

 <= /p>

From: l3vpn-bo= unces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Derick Winkworth
Sent: Tuesday, November 01, 2011 8:11 PM
To: robert@raszuk.net
Cc: L3VPN; Fred Baker
Subject: Re: [vpn4dc] Question on the problem

 

An= swers in-line.

 

From: Robert Raszuk <robert@raszuk.ne= t>
To: Derick Winkworth <ccie15672@yahoo.com>
Cc: Pedro Marques <pedro.r.marques@gmail.com>; L3VPN <l3vpn= @ietf.org>; Fred Baker <fred@cisco.com>
Sent: Tuesday, November 1, 2011 6:46 PM
Subject: Re: [vpn4dc] Question on the problem

Hi Derick,

Very glad you have asked.

----------
When I establish a VPN from any of my hosts, from my CE router(s) or from m= y smartphones I do not tell my providers that I need my device to securely = participate in the VPN.

----------

 

Your VPN is implied.  Your VMs are not able to directly communicate= with the VMs of another of Google's customers by default.  I wonder h= ow Google achieves this separation... 

 

-----
I fail to see why adding VM to any VPN would need to be any harder or any d= ifferent than the examples provided above.

----

 

The complexity is hidden from you in the case of Google or Amazon.  = ;It would be hidden from the tenant in the case of VPN4DC.  the differ= ence is that, as a MPLS network operator, the tenant's private networks already exist at the edge of my data center in the form o= f virtual-routers.  My customers would like the VMs I provision for th= em to appear native to their L3VPN network.  Think virtual-datacenter = for private networks.

 


----------
Note that VMs can be short lived and placed in arbitrary data center locati= ons on the network. Who do you tell that you need to join a VPN ?

----------

 

The tenant tells noone.   I, on the other hand, would like to autom= ate turning up a VM and attaching it to a customers L3VPN so it appears nat= ive to their private network and provide the same illusion of simplicity to my tenant as Google or Amazon provides to c= ustomers who find internet-based cloud services acceptable.


-------
In other words if I would like to buy a VM resources from any cloud provide= rs (for example: Amazon, Google ...) all I should need is to log in to such= VPN and establish a VPN connection to the rest of my enterprise network - = smartphones included.
----------

 

You realize there is more going on under the hood in your example than y= ou have indicated?

 

 


Thx,
R.

> Robert:
>
> ########## That is in fact another reason why such VPN isolation
> should rather not require configuration of number of other elements > then VMs itself.
>
> #########
>
> Can you elaborate on this statement?  On the face of it, I could = not
> disagree more.  We absolutely want to containerize VMs in the net= work
> and not have any dependencies at all on configuration within the VM > itself..
>
> Derick

--Boundary_(ID_Av8lW409XgN6RwjqjO40cQ)-- From lucy.yong@huawei.com Sat Nov 12 13:40:30 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 74C6021F87C2 for ; Sat, 12 Nov 2011 13:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.624 X-Spam-Level: X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 MOfyLmpIUtxD for ; Sat, 12 Nov 2011 13:40:29 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id C8ACB21F8672 for ; Sat, 12 Nov 2011 13:40:29 -0800 (PST) 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 <0LUK00KR2HJHYX@usaga02-in.huawei.com> for l3vpn@ietf.org; Sat, 12 Nov 2011 15:40:29 -0600 (CST) Received: from dfweml202-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 <0LUK00I17HJHPO@usaga02-in.huawei.com> for l3vpn@ietf.org; Sat, 12 Nov 2011 15:40:29 -0600 (CST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 12 Nov 2011 13:40:31 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Sat, 12 Nov 2011 13:39:58 -0800 Date: Sat, 12 Nov 2011 21:40:19 +0000 From: Lucy yong Subject: RE: [vpn4dc] Question on the problem In-reply-to: <4EB0F385.9090402@raszuk.net> X-Originating-IP: [10.47.117.192] To: "robert@raszuk.net" , Derick Winkworth Message-id: <2691CE0099834E4A9C5044EEC662BB9D118E10D5@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [vpn4dc] Question on the problem Thread-index: AQHMmCjvzeXzAwYHcUWsWnPF/T1vrJWYvmyAgAAHaQCAAASigIAAD/gAgABGJ4CAAAWHAIAAF1+AgABscYCADnGNcA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6527FECE-3B49-4D67-BEA1-AD4ECEE420F5@cisco.com> <4EB0342E.1080909@raszuk.net> <4EB04576.1010905@raszuk.net> <1320190031.96972.YahooMailNeo@web161801.mail.bf1.yahoo.com> <4EB084F2.8030702@raszuk.net> <1320196237.96003.YahooMailNeo@web161803.mail.bf1.yahoo.com> <4EB0F385.9090402@raszuk.net> Cc: L3VPN , Fred Baker 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: Sat, 12 Nov 2011 21:40:30 -0000 Please see inline. -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, November 02, 2011 2:39 AM To: Derick Winkworth Cc: L3VPN; Fred Baker Subject: Re: [vpn4dc] Question on the problem Hi Derick, > Your VMs are not able to directly communicate > with the VMs of another of Google's customers by default. I wonder > how Google achieves this separation... I can buy VM from my or any hosting provider in the Internet in few seconds and this VM will have full access to the Internet ON by default and for that matter to any other VM running in public space. In some cases I can either upload which image such VM should be booted with. My hosting provider does not have any link to you as the SP. [[LY]] This is not in the scope of the situation that VPN4DC start with. VPN4DC assumes that provider has PE nearby the hosting provider. So even if I am your L3VPN customer how are you going to attach such VM to be part of my VPN ? How long such attachment will take you ? [[LY]] This is the problem we try to target here. Hope the ability of automated VM turning-up and attaching to L3VPN can short it down to seconds. How are you going to convince my hosting provider to enable host level separation per some solutions proposed already. [[LY]] Good point. Hosting provider needs host level separation in DC. Hosting provider convince you not Network Provider. -- The other topic is when you as the L3VPN SP own data center/cloud and would like to enhance your current MPLS-VPN service offering to offer to your customers an additional VM resources. [[LY]] This can be one deployment scenario. We do not want to limit this one scenarios. If this is the model you are describing that I am completely fine with it. However while this is a valid model this is only a subset of VPN models for secure data center inter-connectivity requirements. [[LY]] Yes, you make the point. BR, Lucy Best regards, R. > ----- I fail to see why adding VM to any VPN would need to be any > harder or any different than the examples provided above. ---- > > The complexity is hidden from you in the case of Google or Amazon. > It would be hidden from the tenant in the case of VPN4DC. the > difference is that, as a MPLS network operator, the tenant's private > networks already exist at the edge of my data center in the form of > virtual-routers. My customers would like the VMs I provision for > them to appear native to their L3VPN network. Think > virtual-datacenter for private networks. > > > ---------- Note that VMs can be short lived and placed in arbitrary > data center locations on the network. Who do you tell that you need > to join a VPN ? ---------- > > The tenant tells noone. I, on the other hand, would like to > automate turning up a VM and attaching it to a customers L3VPN so it > appears native to their private network and provide the same illusion > of simplicity to my tenant as Google or Amazon provides to customers > who find internet-based cloud services acceptable. > > ------- In other words if I would like to buy a VM resources from any > cloud providers (for example: Amazon, Google ...) all I should need > is to log in to such VPN and establish a VPN connection to the rest > of my enterprise network - smartphones included. ---------- > > You realize there is more going on under the hood in your example > than you have indicated? > > > > Thx, R. > >> Robert: >> >> ########## That is in fact another reason why such VPN isolation >> should rather not require configuration of number of other >> elements then VMs itself. >> >> ######### >> >> Can you elaborate on this statement? On the face of it, I could >> not disagree more. We absolutely want to containerize VMs in the >> network and not have any dependencies at all on configuration >> within the VM itself.. >> >> Derick From iesg-secretary@ietf.org Sat Nov 12 15:42:24 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 12B4921F877F; Sat, 12 Nov 2011 15:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 EkCKwYWXYGOz; Sat, 12 Nov 2011 15:42:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EAA21F84BD; Sat, 12 Nov 2011 15:42:23 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (OSPFv3 as a PE-CE routing protocol) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111112234223.20827.13913.idtracker@ietfa.amsl.com> Date: Sat, 12 Nov 2011 15:42:23 -0800 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 23:42:24 -0000 The IESG has received a request from the Layer 3 Virtual Private Networks WG (l3vpn) to consider the following document: - 'OSPFv3 as a PE-CE routing protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ No IPR declarations have been submitted directly on this I-D. From nabil.n.bitar@verizon.com Sun Nov 13 17:20:02 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 AE58011E809F; Sun, 13 Nov 2011 17:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.069, 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 dtTGxUaheZUw; Sun, 13 Nov 2011 17:20:01 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3A24621F877F; Sun, 13 Nov 2011 17:20:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 14 Nov 2011 01:20:00 +0000 From: "Bitar, Nabil N" To: Lucy yong , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" X-IronPort-AV: E=Sophos;i="4.69,504,1315180800"; d="scan'208,217";a="179278859" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi03.verizon.com with ESMTP; 14 Nov 2011 01:20:00 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.102]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Sun, 13 Nov 2011 20:20:00 -0500 Date: Sun, 13 Nov 2011 20:19:59 -0500 Subject: Re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Index: Acyia4brD/hAZroiQHC1PTxCHDHhsw== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D118E00D4@dfweml506-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CADEF3C42D57Bnabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.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: Mon, 14 Nov 2011 01:20:02 -0000 --_000_CADEF3C42D57Bnabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lucy, Thanks for the input/comments. Please, see inline. Thanks, Nabil From: Lucy yong > Date: Tue, 8 Nov 2011 12:39:52 -0500 To: "Bitar, Nabil N" >, "l3vpn@ietf.org" >, "l2vpn@ietf.org" > Cc: Sagessi >, "mircea.pisica@b= t.com" >, "Luyuan Fang (lufang)" >, "y.ikejiri@ntt.com" > Subject: RE: Your input on the following draft is appreciated: draft-bitar-= datacenter-vpn-applicability-01.txt Hi Nabil and other co-authors, First of all, this is a very good draft to gather DC problem statements and= explore VPN applicability for cloud networking. Good information for the = community. Thank you very much. Thanks Lucy. That is one of the purposes of the draft. Some comments: 1) The document has heavy amount portion to describe all different use= cases for PBB but few sentence for TRILL and L3VPN applicability in DC. Su= ggest to elaborate more on TRILL and L3VPN cases. Agree, it is more focused on PBB from layer2 aspect in addition to 802= .1aq in terms of the scenarios, but not neglecting TRILL as we state the ca= ses where TRILL also applies as it can be looked at as alternative to 802.1= aq/Qbp but and the co-authors will be adding more on that. L3VPN case is i= s in section 7. 2) It is very possible that DC use L2VPN and WAN use L3VPN. It is nic= e that document this applicability. These are documented in sections 3, 4, 5, and 7 in addition to some re= lated challenges that need to be addressed in section 8. In particular, we = talk about l3vpn within the data center, L3VPN starting at the DC GW with n= ative Ethernet in the lDC where a tenant is identfied by a layer2 service I= D that is used also as the interface to the tenant VRF at the DC GW. In add= ition, we discuss the different models where the WAN service provider and t= he DC provider are the same entities, and 2 different enetities (Ass) inter= connected via multi-AS backbone options A, B or C per RFC 4364. Finally, we= talk about the case of Integrated routing and bridging per tenant. 3) Provider DC and enterprise DC may implement different L2VPN or L3VP= N technologies, it is valuable to describe what kind of interworking scenar= ios is allowed or not allowed. I am not sure you can say "allowed" or "not allowed". The approach tha= t we took is to dsay: (1) what are the common practices, (2) what are the o= ptions, and (3) what are the tradeoffs among the different options. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Bitar, Nabil N Sent: Monday, November 07, 2011 11:42 PM To: l3vpn@ietf.org; l2vpn@ietf.org Cc: Sagessi; mircea.pisica@bt.com; Luyuan Fang= (lufang); y.ikejiri@ntt.com Subject: Your input on the following draft is appreciated: draft-bitar-data= center-vpn-applicability-01.txt Hi, We had submitted the following draft on vpn applicability for data center. = Your input on the draft is appreciated in light of some of the ongoing disc= ussion. The draft is targeted for l3vpn and l2vpn. Here is the link: http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 Abstract Cloud Computing has been attracting a lot of attention from the networking industry. Some of the most publicized requirements are related to the evolution of the Cloud Networking Infrastructure to accommodate a large number of tenants, efficient network utilization, scalable loop avoidance, and Virtual Machine Mobility. This draft describes a framework for cloud networking, highlighting the applicability of existing work in various IETF Working Groups (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working Groups) to cloud networking, and the gaps and problems that need to be further addressed. That is, the goal is to understand what may be re-used from the current protocols and call out requirements specific to the Cloud space that need to be addressed by new standardization work with proposed solutions in certain cases. Thanks, Nabil --_000_CADEF3C42D57Bnabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lucy,
Thank= s for the input/comments. Please, see inline.

Than= ks,
Nabil

<= div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:bl= ack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: = 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; = BORDER-RIGHT: medium none; PADDING-TOP: 3pt">From: Lucy yong <lucy= .yong@huawei.com>
Date: = Tue, 8 Nov 2011 12:39:52 -0500
To: "Bitar, Nabil N" <n= abil.n.bitar@one.verizon.com>, "l3= vpn@ietf.org" <l3vpn@ietf.org&= gt;, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Sagessi <sajassi= @cisco.com>, "mircea.pisica@= bt.com" <mircea.pisica@bt.co= m>, "Luyuan Fang (lufang)" <l= ufang@cisco.com>, "y.ikejiri@nt= t.com" <y.ikejiri@ntt.com&g= t;
Subject: RE: Your input on t= he following draft is appreciated: draft-bitar-datacenter-vpn-applicability= -01.txt

Hi Nabil  and other co-authors,

 <= /p>

First of all, this is a very go= od draft to gather DC problem statements and explore VPN applicability for = cloud networking.  Good information for the community. Thank you very much.

<NB> Th= anks Lucy. That is one of the purposes of the draft.

 

Some comments:

=  

1)      The document has heavy= amount portion to describe all different use cases for PBB but few sentenc= e for TRILL and L3VPN applicability in DC. Suggest to elaborate more on TRILL and L3VPN cases.

<NB> Agree, it is more focused on PBB from layer2 aspect in= addition to 802.1aq in terms of the scenarios, but not neglecting TRILL as= we state the cases where TRILL also applies as it can be looked at as alte= rnative to 802.1aq/Qbp but  and the co-authors will be adding more on = that. L3VPN case is is in section 7. 

2)      It is very possible th= at DC use L2VPN and WAN use L3VPN.  It is nice that document this appl= icability.

<NB> These are doc= umented in sections 3, 4, 5, and 7 in addition to some related challenges t= hat need to be addressed in section 8. In particular, we talk about l3vpn w= ithin the data center, L3VPN starting at the DC GW with native Ethernet in = the lDC where a tenant is identfied by a layer2 service ID that is used als= o as the interface to the tenant VRF at the DC GW. In addition, we discuss = the different models where the WAN service provider and the DC provider are= the same entities, and 2 different enetities (Ass) interconnected via mult= i-AS backbone options A, B or C per RFC 4364. Finally, we talk about the ca= se of Integrated routing and bridging per tenant.

=

3)      Provider DC and enterp= rise DC may implement different L2VPN or L3VPN technologies, it is valuable= to describe what kind of interworking scenarios is allowed or not allowed.

<NB&= gt; I am not sure you can say "allowed" or "not allowed". The approach that= we took is to dsay: (1) what are the common practices, (2) what are the op= tions, and (3) what are the tradeoffs among the different options.

 

Best Regards,

<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibr= i, sans-serif; ">Lucy

 

 

 

<= /div>

http://tools.ietf.org/htm= l/draft-bitar-datacenter-vpn-applicability-01

 

Abstract
 
   Cloud Computing has been attracting a lot =
of attention from the
   network=
ing industry. Some of the most publicized requirements are
   related to the evolution of the Cloud Network=
ing Infrastructure to
   accommo=
date a large number of tenants, efficient network utilization,
   scalable loop avoidance, and Virtual Mach=
ine Mobility.
 
   This draft describes a framework for cloud network=
ing, highlighting
   the applica=
bility of existing work in various IETF Working Groups
   (e.g., RFCs and drafts developed in IETF L2VPN an=
d L3VPN Working
   Groups) to cl=
oud networking, and the gaps and problems that need to
   be further addressed. That is, the goal is to und=
erstand what may be
   re-used f=
rom the current protocols and call out requirements specific
   to the Cloud space that need to be addresse=
d by new standardization
   work=
 with proposed solutions in certain cases.

Thanks,<=
/o:p>
Nabil
=
--_000_CADEF3C42D57Bnabilnbitarverizoncom_-- From ben@niven-jenkins.co.uk Mon Nov 14 03:50: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 201DE21F8F41 for ; Mon, 14 Nov 2011 03:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 3ahdC+2HJBXA for ; Mon, 14 Nov 2011 03:50:22 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAFF21F8F19 for ; Mon, 14 Nov 2011 03:50:18 -0800 (PST) Received: from dhcp-4719.meeting.ietf.org ([130.129.71.25]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RPv3I-0000xw-Rv for l3vpn@ietf.org; Mon, 14 Nov 2011 11:50:17 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Final L3VPN agenda @ IETF82 Date: Mon, 14 Nov 2011 11:50:13 +0000 Message-Id: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> To: "l3vpn@ietf.org 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, 14 Nov 2011 11:50:23 -0000 Colleagues, I have uploaded a new version of the L3VPN/VPN4DC agenda which includes = the names of the people who will lead each topic. You can find it here: http://www.ietf.org/proceedings/82/agenda/l3vpn.txt The agenda is not arranged around specific drafts per-se but Marshall & = I have asked the person leading each topic to co-ordinate with the = various draft authors to produce a consolidated view/presentation which = they will present on behalf of the numerous authors/contributors. As a reminder: We have purposely not put time on the agenda to = present/discuss specific solution drafts as we would like the discussion = to be focussed on the problem/requirements posed by VPN4DC and its = applicability to IETF (including L3VPN). Discussion of specific solution = proposals can happen at future meetings if the VPN4DC work is adopted. Ben From linda.dunbar@huawei.com Mon Nov 14 06:46: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 88F5D11E819B for ; Mon, 14 Nov 2011 06:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=-0.414, 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 l-IIi7GjECRb for ; Mon, 14 Nov 2011 06:46:42 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 16CE711E8090 for ; Mon, 14 Nov 2011 06:46:42 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUN001NDNPOA9@usaga04-in.huawei.com> for l3vpn@ietf.org; Mon, 14 Nov 2011 08:46:36 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUN0088JNPFTY@usaga04-in.huawei.com> for l3vpn@ietf.org; Mon, 14 Nov 2011 08:46:36 -0600 (CST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 14 Nov 2011 06:46:31 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Mon, 14 Nov 2011 06:45:36 -0800 Date: Mon, 14 Nov 2011 14:46:03 +0000 From: Linda Dunbar Subject: RE: Final L3VPN agenda @ IETF82 In-reply-to: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> X-Originating-IP: [10.47.139.232] To: Ben Niven-Jenkins , "l3vpn@ietf.org mailing list" Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120C1D7C@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Final L3VPN agenda @ IETF82 Thread-index: AQHMosOXnxfN81uKMkysTXyNL8lq/pWscSzQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> 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, 14 Nov 2011 14:46:42 -0000 Ben, I am confused with this agenda. Which drafts are to be discussed at the VPN4DC Background&Problem session led by Ping Pan? We have submitted problem statement for VPN4DC which describes the background and problem space, and requested for presentation, why not giving us the opportunity to talk at this VPN4DC session? Linda > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: Monday, November 14, 2011 7:50 PM > To: l3vpn@ietf.org mailing list > Subject: Final L3VPN agenda @ IETF82 > > Colleagues, > > I have uploaded a new version of the L3VPN/VPN4DC agenda which includes > the names of the people who will lead each topic. You can find it here: > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > The agenda is not arranged around specific drafts per-se but Marshall & > I have asked the person leading each topic to co-ordinate with the > various draft authors to produce a consolidated view/presentation which > they will present on behalf of the numerous authors/contributors. > > As a reminder: We have purposely not put time on the agenda to > present/discuss specific solution drafts as we would like the > discussion to be focussed on the problem/requirements posed by VPN4DC > and its applicability to IETF (including L3VPN). Discussion of specific > solution proposals can happen at future meetings if the VPN4DC work is > adopted. > > Ben From yakov@juniper.net Mon Nov 14 12:46: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 9B8C01F0CE2; Mon, 14 Nov 2011 12:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.899 X-Spam-Level: X-Spam-Status: No, score=-105.899 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 fF0u1QMKUvX8; Mon, 14 Nov 2011 12:46:02 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4681F0CD6; Mon, 14 Nov 2011 12:45:32 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTsF963T2URePAxuV5U/Y5Wq8bkaBAZfq@postini.com; Mon, 14 Nov 2011 12:46:02 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Nov 2011 12:42:02 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id pAEKg1h21336; Mon, 14 Nov 2011 12:42:01 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201111142042.pAEKg1h21336@magenta.juniper.net> To: Linda Dunbar Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> X-MH-In-Reply-To: Linda Dunbar message dated "Wed, 09 Nov 2011 20:12:08 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <42954.1321303321.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 12:42:01 -0800 From: Yakov Rekhter Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@ietf.org" , yakov@juniper.net 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, 14 Nov 2011 20:46:03 -0000 Linda, > Pedro, = > = > You are absolutely right that there is no ARP/ND scaling issue if > IP can be extended to hosts. Even if IP can be extended to Access > switches, there is not much ARP/ND issues. > = > The draft lists down several common data center network designs, > and states that some of the designs don't have ARP/ND scaling > issues (but may have other issues for data centers). > = > That is why I encourage people to read the draft and provides > comments. =46rom 4.2 of the draft: 4.2. Scenario 2: L3 Terminates at the Aggregation Switch In Scenario 2, the L3 network extends only to the aggregation switches (or perhaps to routers that connect to the aggregation switches). The aggregation switches (or the routers that connect to multiple aggregation switches) could terminate multiple distinct IP subnets (e.g., one per VLAN) or one large IP subnet. In order to let hosts belonging to different IP subnets be placed under any access switches, it is necessary for access switches to enable multiple VLANs and aggregation switches to enable some VLANs (or subnets) over many physical ports. This configuration breaks the confinement of the VLAN's broadcast domain and makes it equivalent to all the access switches being part of the same L2 broadcast domain (and IP subnet). Thus, this configuration allows VMs to be moved to servers connected to other access switches, but increases the size of the L2 broadcast domain, which can lead to difficulties outlined below. This is the scenario that is used to justify the need for large L2 domain. = The draft assumes that in order to move a given VM from one server to another, where these two servers are connected to different access switches, *all* the access switches must be configured with the VM's IP subnet, and thus *all* the access switches must be part of the VM's L2 broadcast domain. This is even if at any particular point in time the servers hosting all the VMs of that IP subnet are connected to only a subset of these switches. But is it truly necessary, or could the L2 broadcast domain span only the switches connected to the servers that presently host VMs of the IP subnet ? Moreover, even if all the access switches need to be part of the same L2 broadcast domain, the increase in the size of the L2 broadcast domain in the above scenario is caused by the access switches, not by the number of VMs per L2 domain. The difficulies mentioned in the last sentence of the quoted paragraph are due to ARP, but ARP is generated by VMs, not by the access switches. Given that, how the increase in the size of the L2 broadcast domain *due solely to the access switches*, could increase the amount of ARP traffic that routers have to process ? Yakov. > = > > -----Original Message----- > > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > > Sent: Wednesday, November 09, 2011 1:52 PM > > To: Linda Dunbar > > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; > > armd@ietf.org > > Subject: Re: Need your action to review draft-ietf-armd-problem- > > statement-00.txt > > = > > Linda, > > I'd like to point out that the problem does not need to be solved if > > only IP connectivity is required. This I-D: > > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 describes > > a solution in which address resolution is not required irrespective of > > the location of the traffic destination. Simply put, traffic can be > > routed at each hop. > > = > > As per previous threads in this list, the concept of subnet which is > > of no practical usefulness in this space. Since VMs can be randomly > distributed across the network the subnet does not provide any > > information aggregation value. Thus there is no need to do address > > resolution. > > = > > Pedro. > > = > > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar > > wrote: > > > For those of you who touch upon Data Center networking or server > > > virtualization, be it Overlay, VPN4DC, or Application/Software drive= n > > > Controller for Data Center, Address Resolution is something Data > > Center > > > Gateways =A0will encounter because hosts/applications in data center= s > > do > > > communicate with peers which are not in the same Overlay, outside th= e > > VPN > > > domain, or from general public. ARMD has published its WG problem > > statement > > > draft. Your comments and suggestions are appreciated (send to > > > armd@ietf.org). > > > > > > > > > > > > Thanks, Linda Dunbar > > > > > > > > > > > > --------------------------------------------------------------------= - > > -------------- > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. This draft is a work item of the Address Resolution for > > Massive > > > numbers of hosts in the Data center Working Group of the IETF. > > > > > > > > > > > > =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Problem = Statement for ARMD > > > > > > =A0=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : Thomas Narten > > > > > > =A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-ietf-arm= d-problem-statement-00.txt > > > > > > =A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 11 > > > > > > =A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-1= 0-17 > > > > > > > > > > > > =A0=A0 This document examines issues related to the massive scaling = of > > data > > > > > > =A0=A0 centers.=A0 Our initial scope is relatively narrow.=A0 Specif= ically, > > we > > > > > > =A0=A0 focus on address resolution (ARP and ND) within the data cent= er. > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- > > statement-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-ietf-armd-problem-statement= - > > 00.txt > > > > > > > = From vumip1@gmail.com Mon Nov 14 19:24: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 C3C381F0DA8; Mon, 14 Nov 2011 19:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2fWxG4D7Xzf; Mon, 14 Nov 2011 19:24:25 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 131C81F0DA0; Mon, 14 Nov 2011 19:24:25 -0800 (PST) Received: by iaeo4 with SMTP id o4so10255830iae.31 for ; Mon, 14 Nov 2011 19:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=UbclDjDVjLHhl4Y7cW8z2uGagLagIYNDTjgY7WUxtOo=; b=eZLMpCSIy1tiHpmnHpEXnn8iTdLhN7kgEfuq0Y4nDCdKyY69d+c4Cf5MieI4Czj3Xm OZhFDAva9YxmCegX8Dtw+v3s6mXOHxpDPkFeh35WEBS7D7fKXwSo5R2jfTc5DutYF6+c BChs6AcgDxhrD8hGrrPrVRLkGUpmU/dmxbPo4= MIME-Version: 1.0 Received: by 10.50.194.231 with SMTP id hz7mr27882254igc.7.1321327464707; Mon, 14 Nov 2011 19:24:24 -0800 (PST) Received: by 10.50.187.161 with HTTP; Mon, 14 Nov 2011 19:24:24 -0800 (PST) Date: Mon, 14 Nov 2011 22:24:24 -0500 Message-ID: Subject: looking forward to your comments on the Security Framework for Virtualized Data Center Services draft From: Bhumip Khasnabish To: l3vpn@ietf.org, opsawg@ietf.org Content-Type: multipart/alternative; boundary=14dae9340dc12a753d04b1bd8680 Cc: igor.faynberg@alcatel-lucent.com, wei.yinxing@zte.com.cn, Lin.ZhaoJi@zte.com.cn, Zachary.Zeltsan@alcatel-lucent.com, zhang.ruishan@zte.com.cn 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, 15 Nov 2011 03:24:25 -0000 --14dae9340dc12a753d04b1bd8680 Content-Type: text/plain; charset=ISO-8859-1 Hello, We are planning to update Security Framework for Virtualized Data Center Services draft based on the comments that we received so far. If you have any additional comments, pls send to the dist. lists before middle of December 2011. Many thanks in advance. Best. Bhumip ================================================================== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security Framework for Virtualized Data Center Services Author(s) : Suren Karavettil Bhumip Khasnabish Ning So Wei Dong Filename : draft-karavettil-vdcs-security-framework-00.txt Pages : 20 Date : 2011-06-30 This document discusses the requirements and technology gaps related to security in the virtualized data center services (VDCS). The objective is to ensure end-to-end security for various types of carrier services built on virtualized infrastructure. The issues covered in this draft are focused on confidentiality and integrity of the services in the virtualized environment; including but not limited to infrastructure (IaaS), platform (PaaS), and application (SaaS) services. This draft also takes into account transient nature of identity, resources and connectivity in the virtualized environment. A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-karavettil-vdcs-security-framework-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-karavettil-vdcs-security-framework-00.txt --14dae9340dc12a753d04b1bd8680 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
=A0
We are planning to update Security Framework for Virtualized Data Cent= er Services draft
based on the comments that we received so far.
=A0
If you have any additional comments, pls send to the dist. lists befor= e middle of December 2011.
=A0
Many thanks in advance.
=A0
Best.
=A0
Bhumip
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A Ne=
w Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Security Framework for Virtualized Data Center Services
	Author(s)       : Suren Karavettil
                          Bhumip Khasnabish
                          Ning So
                          Wei Dong
	Filename        : draft-karavettil-vdcs-security-framework-00.txt
	Pages           : 20
	Date            : 2011-06-30

   This document discusses the requirements and technology gaps related
   to security in the virtualized data center services (VDCS).  The
   objective is to ensure end-to-end security for various types of
   carrier services built on virtualized infrastructure.  The issues
   covered in this draft are focused on confidentiality and integrity of
   the services in the virtualized environment; including but not
   limited to infrastructure (IaaS), platform (PaaS), and application
   (SaaS) services.  This draft also takes into account transient nature
   of identity, resources and connectivity in the virtualized
   environment.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/d=
raft-karavettil-vdcs-security-framework-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/dra=
ft-karavettil-vdcs-security-framework-00.txt
--14dae9340dc12a753d04b1bd8680-- From pedro.r.marques@gmail.com Tue Nov 15 09:47:02 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 9834F1F0C3C; Tue, 15 Nov 2011 09:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.004, 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 xIiJflHPKYg5; Tue, 15 Nov 2011 09:46:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44DCE1F0C41; Tue, 15 Nov 2011 09:46:52 -0800 (PST) Received: by iaeo4 with SMTP id o4so11278303iae.31 for ; Tue, 15 Nov 2011 09:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eQpeXGh8hWjyUGWx6RruiKeBml2xuTC5z7YrtWFs6kk=; b=A8SQVpxNKnZX3GvTxzZ8Os1IYGnye0VhfDCZ2vCBmbcZtcoJsNUvy5m09dmvXZMsew znXT2gPsT4c6tVDmo0v1ZaPKik7YZ4pnjpmnn74gWowQJX4WdJe6X+cxoP6HjaOENhw4 1xVOodN8nr+XcXVZkDyqzoA/2JK53Tsgs3qE8= MIME-Version: 1.0 Received: by 10.231.8.143 with SMTP id h15mr6454119ibh.94.1321379211837; Tue, 15 Nov 2011 09:46:51 -0800 (PST) Received: by 10.231.12.2 with HTTP; Tue, 15 Nov 2011 09:46:51 -0800 (PST) In-Reply-To: <011101cca35e$a93be5b0$fbb3b110$@com> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> <201111142042.pAEKg1h21336@magenta.juniper.net> <011101cca35e$a93be5b0$fbb3b110$@com> Date: Tue, 15 Nov 2011 09:46:51 -0800 Message-ID: Subject: Re: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt From: Pedro Marques To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, sdnp@lucidvision.com, L3VPN WG mailing list , armd@ietf.org, Yakov Rekhter 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, 15 Nov 2011 17:47:02 -0000 Sue, I think the following statements capture a common configuration for small / low-bandwidth (1g) / private DCs: - VLANs are used for isolation. - These vlans are locally scoped to a pair of aggregation switches. - They are statically configured at the access switches. - Traffic exchange between vlans is done at the aggregation switches (often subject to service modules). The above is not contentious, i presume. I think that everyone would also agree that: - It is highly desirable to be able to have an application (a process running on a server) to be placed in an arbitrary location of the DC. (which conflicts with vlan locality). - It is expected that the number of application processes that participate in the same isolation domain will grow significantly (due to external factors related to application design). - It is expected that the bandwidth requirements for severs will increase by an order of magnitude (along with higher server utilization). I hope we all agree so far. Now from the 2 sets of premises above it does not directly follow that the answer is to build larger and larger L2 domains. I do understand that to be a common perception but that is actually not necessary and imho not useful. The fundamental misconception is that the application processes (in a VM or other wise) do need VLANs. They do not. They need connectivity; both within an inner level of isolation (today's vlan) and to other services in the data center (which today is routed often subject to security policies). An example of the later would be a set of database servers; database servers are often expensive and shared among different applications. In order to be able to place any VM anywhere, the VM needs to have direct connectivity to multiple isolation domains. isolation domains which are today modeled as L2 and isolation domains that are today modeled as L3. The concept of an L2/L3 boundary is not useful if you assume that a VM can be placed in an arbitrary location. Anywhere you choose to put that "boundary": top-of-rack, aggregation, etc, you are likely to find that the boundary gets in the way of the VMs being able to be located anywhere. At least without causing traffic to cross the core twice which is a non-starter. So to actually solve the problem according to requirements one needs to get rid of the boundary and move to a solution that is all L2 or all L3. And ARP/ND is really not a relevant problem. With an "L2" solution tends to come the assumption that there is a single "isolation" domain... and a single subnet, which doesn't really cut it. "L3" and specially BGP-based IP/VPNs natively support the concept of direct traffic exchanges between different isolation domains, subject to policy. Even if you do decide to select an L2 approach that limits an application to a single isolation domain, the L2 mac information will need to be present at every switch where that L2 VLAN is present. If you follow an approach where there is core-interface to core-interface mac-learning (VXLAN for instance) then indeed you do have ARP broadcasts being used to update forwarding tables. But approaches such as EVPN can perform learning on the edge interface only eliminating the need to generate ARP broadcasts. It is entirely likely that the approaches that attempt to provide for large broadcast domains already contain a solution for L2 address discovery. Conversely it is rather unclear that you can address the ARP/ND scaling issue independently of the design of the L2 solution itself. regards, Pedro. On Mon, Nov 14, 2011 at 10:20 PM, Susan Hares wrote: > Yakov: > > We are not trying to justify any definition we have, but to report what D= C > operators have given as the problem in an OPS draft. > > In many ways, the text has been successful by having you comment on this > point so that operators can consider in depth this scenario. > > With all due respect to you as a grand master of word-smithing, let me > restate some of the argument so that I can attempt to inspire discussion. > > The "all" in this discussion indicates "all" within this domain which > crosses the VLANs in the text. The 802.1q VLAN mechanism provides some > scoping of broadcast and unicast for an L2 grouping. The IP Subset provid= es > a scoping for scoping for IP (L3 grouping). ARP maps the L2 grouping to t= he > l3 grouping. The growth in the number of nodes (VM or access) in the > combined groupings of mapped nodes are the problem. > > If you want to restrict nodes within this at L2 or L3, you must find a me= ans > to determine the L2 grouping. The mapping of the IP to MAC Address is sco= ped > by the combination of L2/L3 grouping. > > So.. at some point the VM or the real nodes reach an "aggregation groupin= g" > at the access switch or the VMs forming an access switch. This grouping > point is stressed by the underlying growth of L2/L3 node combination. On = the > ARMD BOF/List, Manish Karir (Merit) published a study in looking at the A= RP > problem using VMs groupings. > > Some large scale operators stated the VM aggregation I described above di= d > not represent a case widely used. Therefore the discussion focused on the > deployed access switches, servers, and VMs as described in the text. =A0P= lease > refer to past discussion from Igor G. on this list or his drafts on > solutions/problems. Also, you can refer to NANOG session on this. > > Yakov - let me know of I am unclear or just misunderstood your discussion > point. Linda, Manish, and Igor let me know if I was incorrect in anything= I > said. > > Hopefully, I've given the discussion a push. If nothing else, it will > > Sue > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Yakov Rekhter > Sent: Monday, November 14, 2011 3:42 PM > To: Linda Dunbar > Cc: l2vpn@ietf.org; sdnp@lucidvision.com; L3VPN WG mailing list; > armd@ietf.org; yakov@juniper.net; Pedro Marques > Subject: Re: [armd] Need your action to review > draft-ietf-armd-problem-statement-00.txt > > Linda, > >> Pedro, >> >> You are absolutely right that there is no ARP/ND scaling issue if IP >> can be extended to hosts. Even if IP can be extended to Access >> switches, there is not much ARP/ND issues. >> >> The draft lists down several common data center network designs, and >> states that some of the designs don't have ARP/ND scaling issues (but >> may have other issues for data centers). >> >> That is why I encourage people to read the draft and provides >> comments. > > From 4.2 of the draft: > > =A04.2. =A0Scenario 2: L3 Terminates at the Aggregation Switch > > =A0 In Scenario 2, the L3 network extends only to the aggregation > =A0 switches (or perhaps to routers that connect to the aggregation > =A0 switches). =A0The aggregation switches (or the routers that connect t= o > =A0 multiple aggregation switches) could terminate multiple distinct IP > =A0 subnets (e.g., one per VLAN) or one large IP subnet. =A0In order to l= et > =A0 hosts belonging to different IP subnets be placed under any access > =A0 switches, it is necessary for access switches to enable multiple > =A0 VLANs and aggregation switches to enable some VLANs (or subnets) over > =A0 many physical ports. =A0This configuration breaks the confinement of > =A0 the VLAN's broadcast domain and makes it equivalent to all the access > =A0 switches being part of the same L2 broadcast domain (and IP subnet). > =A0 Thus, this configuration allows VMs to be moved to servers connected > =A0 to other access switches, but increases the size of the L2 broadcast > =A0 domain, which can lead to difficulties outlined below. > > This is the scenario that is used to justify the need for large L2 domain= . > > The draft assumes that in order to move a given VM from one server to > another, where these two servers are connected to different access switch= es, > *all* the access switches must be configured with the VM's IP subnet, and > thus *all* the access switches must be part of the VM's L2 broadcast doma= in. > This is even if at any particular point in time the servers hosting all t= he > VMs of that IP subnet are connected to only a subset of these switches. B= ut > is it truly necessary, or could the L2 broadcast domain span only the > switches connected to the servers that presently host VMs of the IP subne= t ? > > Moreover, even if all the access switches need to be part of the same L2 > broadcast domain, the increase in the size of the L2 broadcast domain in = the > above scenario is caused by the access switches, not by the number of VMs > per L2 domain. The difficulies mentioned in the last sentence of the quot= ed > paragraph are due to ARP, but ARP is generated by VMs, not by the access > switches. Given that, how the increase in the size of the L2 broadcast > domain *due solely to the access switches*, could increase the amount of = ARP > traffic that routers have to process ? > > Yakov. > >> >> > -----Original Message----- >> > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >> > Sent: Wednesday, November 09, 2011 1:52 PM >> > To: Linda Dunbar >> > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; >> > armd@ietf.org >> > Subject: Re: Need your action to review draft-ietf-armd-problem- >> > statement-00.txt >> > >> > Linda, >> > I'd like to point out that the problem does not need to be solved if >> > only IP connectivity is required. This I-D: >> > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >> > describes a solution in which address resolution is not required >> > irrespective of the location of the traffic destination. Simply put, >> > traffic can be routed at each hop. >> > >> > As per previous threads in this list, the concept of subnet which is >> > of no practical usefulness in this space. Since VMs can be randomly >> distributed across the network the subnet does not provide any >> > information aggregation value. Thus there is no need to do address >> > resolution. >> > >> > =A0 Pedro. >> > >> > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar >> > >> > wrote: >> > > For those of you who touch upon Data Center networking or server >> > > virtualization, be it Overlay, VPN4DC, or Application/Software >> > > driven Controller for Data Center, Address Resolution is something >> > > Data >> > Center >> > > Gateways =A0will encounter because hosts/applications in data >> > > centers >> > do >> > > communicate with peers which are not in the same Overlay, outside >> > > the >> > VPN >> > > domain, or from general public. ARMD has published its WG problem >> > statement >> > > draft. Your comments and suggestions are appreciated (send to >> > > armd@ietf.org). >> > > >> > > >> > > >> > > Thanks, Linda Dunbar >> > > >> > > >> > > >> > > ------------------------------------------------------------------ >> > > --- >> > -------------- >> > > >> > > >> > > >> > > >> > > >> > > A New Internet-Draft is available from the on-line Internet-Drafts >> > > directories. This draft is a work item of the Address Resolution >> > > for >> > Massive >> > > numbers of hosts in the Data center Working Group of the IETF. >> > > >> > > >> > > >> > > =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Problem Statement for AR= MD >> > > >> > > =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Thomas Narten >> > > >> > > =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-armd-problem-st= atement-00.txt >> > > >> > > =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 11 >> > > >> > > =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-17 >> > > >> > > >> > > >> > > =A0 =A0This document examines issues related to the massive scaling = of >> > data >> > > >> > > =A0 =A0centers. =A0Our initial scope is relatively narrow. >> > > Specifically, >> > we >> > > >> > > =A0 =A0focus on address resolution (ARP and ND) within the data cent= er. >> > > >> > > >> > > >> > > >> > > >> > > A URL for this Internet-Draft is: >> > > >> > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- >> > statement-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-ietf-armd-problem-stateme >> > > nt- >> > 00.txt >> > > >> > > >> > > From marshall.eubanks@gmail.com Tue Nov 15 11:02: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 9E23111E80D7 for ; Tue, 15 Nov 2011 11:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8ttwXP8ZhaK for ; Tue, 15 Nov 2011 11:02:20 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D485F11E8073 for ; Tue, 15 Nov 2011 11:02:18 -0800 (PST) Received: by wwe5 with SMTP id 5so4763185wwe.13 for ; Tue, 15 Nov 2011 11:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=h/EvXmQhDkpJSCosYIAWMgIFpb1KyWzTAeUYT0m5Dko=; b=xhP24gMxpnxIpXE6I2xEkPwcJ9Dq37B3BvZkHvt8OqMu5c3qvwn+CKViSJtlChGrfM 21U8mukLfKm+HeNbspALrGJcrOl/VH5VHgl/D1ho0pAPtbQpQPUMxedylqlKCGnO8e3D y5MTndpEz+9eObWjBDlieZ9H/zxw/iQlbJVvU= MIME-Version: 1.0 Received: by 10.182.115.106 with SMTP id jn10mr6338987obb.54.1321383737796; Tue, 15 Nov 2011 11:02:17 -0800 (PST) Received: by 10.182.159.73 with HTTP; Tue, 15 Nov 2011 11:02:17 -0800 (PST) Date: Tue, 15 Nov 2011 14:02:17 -0500 Message-ID: Subject: We need slides From: Marshall Eubanks To: L3VPN 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, 15 Nov 2011 19:02:25 -0000 VPN4DC presenters : If you have slides, you need to send them to Ben or me as soon as you read this. Regards Marshall From yakov@juniper.net Tue Nov 15 11:22:24 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 4BDCC21F89B8; Tue, 15 Nov 2011 11:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.519 X-Spam-Level: X-Spam-Status: No, score=-103.519 tagged_above=-999 required=5 tests=[AWL=-2.720, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6, MANGLED_MEDS=2.3, MANGLED_PRBLMS=2.3, 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 DFNrZaLhHhUF; Tue, 15 Nov 2011 11:22:18 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 564A711E8081; Tue, 15 Nov 2011 11:21:47 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTsK7yiEIkQhW7dGbkp4id8lgufQR/wuZ@postini.com; Tue, 15 Nov 2011 11:22:18 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Nov 2011 11:19:22 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id pAFJJJh74426; Tue, 15 Nov 2011 11:19:22 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201111151919.pAFJJJh74426@magenta.juniper.net> To: Linda Dunbar Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> X-MH-In-Reply-To: Linda Dunbar message dated "Wed, 09 Nov 2011 19:31:33 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93043.1321384759.1@juniper.net> Date: Tue, 15 Nov 2011 11:19:19 -0800 From: Yakov Rekhter Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , armd@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, 15 Nov 2011 19:22:24 -0000 Linda, > For those of you who touch upon Data Center networking or server > virtualization, be it Overlay, VPN4DC, or Application/Software > driven Controller for Data Center, Address Resolution is something > Data Center Gateways will encounter because hosts/applications > in data centers do communicate with peers which are not in the same > Overlay, outside the VPN domain, or from general public. ARMD has > published its WG problem statement draft. Your comments and suggestions > are app reciated (send to armd@ietf.org). Should the overhead due to the broadcast unknown be considered as yet another "pain point" associated with large L2 domains ? Yakov. > > Thanks, Linda Dunbar > > ----------------------------------------------------------------------------- ------ > > > > A New Internet-Draft is available from the on-line Internet-Drafts directorie s. This draft is a work item of the Address Resolution for Massive numbers of h osts in the Data center Working Group of the IETF. > > > > Title : Problem Statement for ARMD > > Author(s) : Thomas Narten > > Filename : draft-ietf-armd-problem-statement-00.txt > > Pages : 11 > > Date : 2011-10-17 > > > > This document examines issues related to the massive scaling of data > > centers. Our initial scope is relatively narrow. Specifically, we > > focus on address resolution (ARP and ND) within the data center. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-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-ietf-armd-problem-statement-00.txt > > > --Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ) > Content-type: text/html; charset=us-ascii > Content-transfer-encoding: quoted-printable > > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= > icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= > :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= > uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= > t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= > m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= > t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= > :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= > soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = > xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= > icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= > schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= > point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= > /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= > =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= > schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= > .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= > /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= > ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= > repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= > xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= > schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= > /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= > ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= > p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= > /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= > mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= > crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= > s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= > ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= > om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= > ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= > partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= > 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= > 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= > deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= > Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= > st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > > > > > >
>

For those of you who t= > ouch upon Data Center networking or server virtualization, be it Overlay, V= > PN4DC, or Application/Software driven Controller for Data Center, Address R= > esolution is something Data Center Gateways >  will encounter because hosts/applications in data centers do communi= > cate with peers which are not in the same Overlay, outside the VPN domain, = > or from general public. ARMD has published its WG problem statement draft. = > Your comments and suggestions are appreciated > (send to armd@ietf.org). <= > /span>

>

  n>

>

Thanks, Linda Dunbar :p>

>

  n>

>

----------------------= > ------------------------------------------------------------- pan>

>

  n>

>

 

> 
A New Internet-Draft is available from the on-line Internet-Drafts dir=
> ectories. This draft is a work item of the Address Resolution for Massive n=
> umbers of hosts in the Data center Working Group of the IETF. re>
> 
 

> 
        Title   &nbs=
> p;       : Problem Statement for ARMD :p>

> 
        Author(s)   =
>     : Thomas Narten

> 
        Filename   &=
> nbsp;    : draft-ietf-armd-problem-statement-00.txt p>

> 
        Pages   &nbs=
> p;       : 11

> 
        Date    =
> ;        : 2011-10-17

> 
 

> 
   This document examines issues related to the massive scal=
> ing of data

> 
   centers.  Our initial scope is relatively narrow.&nb=
> sp; Specifically, we

> 
   focus on address resolution (ARP and ND) within the data =
> center.

> 
 

> 
 

> 
A URL for this Internet-Draft is:

> 
 -statement-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-armd-prob=
> lem-statement-00.txt

> 
 

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

> 
 

> 
This Internet-Draft can be retrieved at:

> 
 statement-00.txt">ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-proble=
> m-statement-00.txt

> 
 

>
> > > > --Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ)-- > > --Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A) > Content-id: <318D3282CFCD0C45A8C99283FF38289A@huawei.com> > Content-type: text/plain; name=ATT00001.txt > Content-transfer-encoding: 7BIT > Content-disposition: attachment; filename=ATT00001.txt; size=127; > creation-date="Fri, 04 Nov 2011 15:30:31 GMT"; > modification-date="Fri, 04 Nov 2011 15:30:31 GMT" > Content-description: ATT00001.txt > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > --Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A)-- From xuxiaohu@huawei.com Tue Nov 15 17:30:49 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 165031F0C93; Tue, 15 Nov 2011 17:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.079 X-Spam-Level: * X-Spam-Status: No, score=1.079 tagged_above=-999 required=5 tests=[AWL=-2.925, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6, MANGLED_MEDS=2.3, MANGLED_PRBLMS=2.3, 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 QBj89QQ-GvW5; Tue, 15 Nov 2011 17:30:43 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8974B1F0C95; Tue, 15 Nov 2011 17:30:42 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00EUHC74J8@szxga04-in.huawei.com>; Wed, 16 Nov 2011 09:30:40 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00DERC6TVQ@szxga04-in.huawei.com>; Wed, 16 Nov 2011 09:30:40 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB62265; Wed, 16 Nov 2011 09:30:30 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 09:30:25 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 09:30:23 +0800 Date: Wed, 16 Nov 2011 01:30:22 +0000 From: Xuxiaohu Subject: re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: <201111151919.pAFJJJh74426@magenta.juniper.net> X-Originating-IP: [172.24.2.41] To: Yakov Rekhter , Linda Dunbar Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BDCA@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMo8vtYH3v59PbJ0yNrS5G7pYICZWutQxx X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@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, 16 Nov 2011 01:30:49 -0000 SGkgWWFrb3YsDQoNCkkgYmVsaWV2ZSB1bmtub3duIHVuaWNhc3QgZmxvb2Qgc2hvdWxkIGJlIGNv bnNpZGVyZWQgYXMgYW5vdGhlciBwYWluIHBvaW50IGFzc29jaWF0ZWQgd2l0aCBsYXJnZSBMMiBk b21haW5zIHdoaWNoIGFyZSBleHRlbmRlZCBhY3Jvc3MgbXVsdGlwbGUgZGF0YSBjZW50ZXJzLiBU aGUgcmVhc29uIGlzIHRoZSBXQU4gYmFuZHdpZHRoIGlzIG11Y2ggbGltaXRlZCBhbmQgZXhwZW5z aXZlLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUgDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQq3orz+yMs6IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW2wzdnBuLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gWWFrb3YgUmVraHRlciBbeWFrb3ZAanVuaXBlci5uZXRdDQq3 osvNyrG85DogMjAxMcTqMTHUwjE2yNUgMzoxOQ0Ktb06IExpbmRhIER1bmJhcg0KQ2M6IGwydnBu QGlldGYub3JnOyBzZG5wQGx1Y2lkdmlzaW9uLmNvbTsgTDNWUE4gV0cgbWFpbGluZyBsaXN0OyBh cm1kQGlldGYub3JnDQrW98ziOiBSZTogTmVlZCB5b3VyIGFjdGlvbiB0byByZXZpZXcgICAgICBk cmFmdC1pZXRmLWFybWQtcHJvYmxlbS1zdGF0ZW1lbnQtMDAudHh0DQoNCkxpbmRhLA0KDQo+IEZv ciB0aG9zZSBvZiB5b3Ugd2hvIHRvdWNoIHVwb24gRGF0YSBDZW50ZXIgbmV0d29ya2luZyBvciBz ZXJ2ZXINCj4gdmlydHVhbGl6YXRpb24sIGJlIGl0IE92ZXJsYXksIFZQTjREQywgb3IgQXBwbGlj YXRpb24vU29mdHdhcmUNCj4gZHJpdmVuIENvbnRyb2xsZXIgZm9yIERhdGEgQ2VudGVyLCBBZGRy ZXNzIFJlc29sdXRpb24gaXMgc29tZXRoaW5nDQo+IERhdGEgQ2VudGVyIEdhdGV3YXlzICB3aWxs IGVuY291bnRlciBiZWNhdXNlIGhvc3RzL2FwcGxpY2F0aW9ucw0KPiBpbiBkYXRhIGNlbnRlcnMg ZG8gY29tbXVuaWNhdGUgd2l0aCBwZWVycyB3aGljaCBhcmUgbm90IGluIHRoZSBzYW1lDQo+IE92 ZXJsYXksIG91dHNpZGUgdGhlIFZQTiBkb21haW4sIG9yIGZyb20gZ2VuZXJhbCBwdWJsaWMuIEFS TUQgaGFzDQo+IHB1Ymxpc2hlZCBpdHMgV0cgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQuIFlvdXIg Y29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zDQo+IGFyZSBhcHAgcmVjaWF0ZWQgKHNlbmQgdG8gYXJt ZEBpZXRmLm9yZzxtYWlsdG86YXJtZEBpZXRmLm9yZz4pLg0KDQpTaG91bGQgdGhlIG92ZXJoZWFk IGR1ZSB0byB0aGUgYnJvYWRjYXN0IHVua25vd24gYmUgY29uc2lkZXJlZCBhcyB5ZXQNCmFub3Ro ZXIgInBhaW4gcG9pbnQiIGFzc29jaWF0ZWQgd2l0aCBsYXJnZSBMMiBkb21haW5zID8NCg0KWWFr b3YuDQoNCj4NCj4gVGhhbmtzLCBMaW5kYSBEdW5iYXINCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCi0tLS0tLQ0KPg0KPg0KPg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZQ0Kcy4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQWRkcmVzcyBSZXNvbHV0aW9uIGZvciBNYXNzaXZlIG51 bWJlcnMgb2YgaA0Kb3N0cyBpbiB0aGUgRGF0YSBjZW50ZXIgV29ya2luZyBHcm91cCBvZiB0aGUg SUVURi4NCj4NCj4NCj4NCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBQcm9ibGVtIFN0YXRl bWVudCBmb3IgQVJNRA0KPg0KPiAgICAgICAgIEF1dGhvcihzKSAgICAgICA6IFRob21hcyBOYXJ0 ZW4NCj4NCj4gICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWFybWQtcHJvYmxl bS1zdGF0ZW1lbnQtMDAudHh0DQo+DQo+ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTENCj4N Cj4gICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDExLTEwLTE3DQo+DQo+DQo+DQo+ICAgIFRo aXMgZG9jdW1lbnQgZXhhbWluZXMgaXNzdWVzIHJlbGF0ZWQgdG8gdGhlIG1hc3NpdmUgc2NhbGlu ZyBvZiBkYXRhDQo+DQo+ICAgIGNlbnRlcnMuICBPdXIgaW5pdGlhbCBzY29wZSBpcyByZWxhdGl2 ZWx5IG5hcnJvdy4gIFNwZWNpZmljYWxseSwgd2UNCj4NCj4gICAgZm9jdXMgb24gYWRkcmVzcyBy ZXNvbHV0aW9uIChBUlAgYW5kIE5EKSB3aXRoaW4gdGhlIGRhdGEgY2VudGVyLg0KPg0KPg0KPg0K Pg0KPg0KPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4NCj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hcm1kLXByb2JsZW0tc3RhdGVt ZW50LTAwLnR4dA0KPg0KPg0KPg0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQo+DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvDQo+DQo+DQo+DQo+IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBh dDoNCj4NCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWFy bWQtcHJvYmxlbS1zdGF0ZW1lbnQtMDAudHh0DQo+DQo+DQo+IC0tQm91bmRhcnlfKElEXzJ4WUVR YWJTSlVKZVh4aW9nTUowZlEpDQo+IENvbnRlbnQtdHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PXVz LWFzY2lpDQo+IENvbnRlbnQtdHJhbnNmZXItZW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCj4N Cj4gPGh0bWwgeG1sbnM6dj0zRCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6 bz0zRCJ1cm46c2NoZW1hcy1taWNyPQ0KPiBvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0zRCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiA9DQo+IHhtbG5zOng9 M0QidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9M0QidXJu OnNjaGVtYXMtbT0NCj4gaWNyb3NvZnQtY29tOm9mZmljZTpwb3dlcnBvaW50IiB4bWxuczphPTNE InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlPQ0KPiA6YWNjZXNzIiB4bWxuczpkdD0z RCJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1BMjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6cz0zRCI9 DQo+IHV1aWQ6QkRDNkUzRjAtNkRBMy0xMWQxLUEyQTMtMDBBQTAwQzE0ODgyIiB4bWxuczpycz0z RCJ1cm46c2NoZW1hcy1taWNyb3NvZj0NCj4gdC1jb206cm93c2V0IiB4bWxuczp6PTNEIiNSb3dz ZXRTY2hlbWEiIHhtbG5zOmI9M0QidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvPQ0KPiBtOm9mZmlj ZTpwdWJsaXNoZXIiIHhtbG5zOnNzPTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl OnNwcmVhZHNoZWU9DQo+IHQiIHhtbG5zOmM9M0QidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6Y29tcG9uZW50OnNwcmVhZHNoZWV0IiB4bWxucz0NCj4gOm9kYz0zRCJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTpvZGMiIHhtbG5zOm9hPTNEInVybjpzY2hlbWFzLW1pY3Jv PQ0KPiBzb2Z0LWNvbTpvZmZpY2U6YWN0aXZhdGlvbiIgeG1sbnM6aHRtbD0zRCJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIiA9DQo+IHhtbG5zOnE9M0QiaHR0cDovL3NjaGVtYXMueG1s c29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnJ0Yz0zRCJodHRwOi8vbT0NCj4gaWNyb3Nv ZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9M0QiREFWOiIgeG1sbnM6UmVw bD0zRCJodHRwOi8vPQ0KPiBzY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5zOm10PTNE Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmU9DQo+IHBvaW50L3NvYXAvbWVldGlu Z3MvIiB4bWxuczp4Mj0zRCJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNl bD0NCj4gLzIwMDMveG1sIiB4bWxuczpwcGRhPTNEImh0dHA6Ly93d3cucGFzc3BvcnQuY29tL05h bWVTcGFjZS54c2QiIHhtbG5zOm9pcz0NCj4gPTNEImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vc2hhcmVwb2ludC9zb2FwL29pcy8iIHhtbG5zOmRpcj0zRCJodHRwOi8vPQ0KPiBzY2hlbWFz Lm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPTNEImh0 dHA6Ly93d3cudzM9DQo+IC5vcmcvMjAwMC8wOS94bWxkc2lnIyIgeG1sbnM6ZHNwPTNEImh0dHA6 Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludD0NCj4gL2RzcCIgeG1sbnM6dWRjPTNE Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0YS91ZGMiIHhtbG5zOnhzZD0zRCJodHRw PQ0KPiA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxuczpzdWI9M0QiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGE9DQo+IHJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRzLyIg eG1sbnM6ZWM9M0QiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIj0NCj4gIHhtbG5z OnNwPTNEImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNw cz0zRCJodHRwOi8vPQ0KPiBzY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIg eG1sbnM6eHNpPTNEImh0dHA6Ly93d3cudzMub3JnLzIwMDE9DQo+IC9YTUxTY2hlbWEtaW5zdGFu Y2UiIHhtbG5zOnVkY3M9M0QiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9z bz0NCj4gYXAiIHhtbG5zOnVkY3hmPTNEImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0 YS91ZGMveG1sZmlsZSIgeG1sbnM6dWRjPQ0KPiBwMnA9M0QiaHR0cDovL3NjaGVtYXMubWljcm9z b2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3Zj0zRCJodHRwOi89DQo+IC9zY2hl bWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL3dvcmtmbG93LyIgeG1sbnM6ZHNzcz0z RCJodHRwOi8vc2NoZT0NCj4gbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDYvZGlnc2lnLXNl dHVwIiB4bWxuczpkc3NpPTNEImh0dHA6Ly9zY2hlbWFzLm1pPQ0KPiBjcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPTNEImh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3Jt YXQ9DQo+IHMub3JnL3BhY2thZ2UvMjAwNi9kaWdpdGFsLXNpZ25hdHVyZSIgeG1sbnM6bXZlcj0z RCJodHRwOi8vc2NoZW1hcy5vcGVueG1sZj0NCj4gb3JtYXRzLm9yZy9tYXJrdXAtY29tcGF0aWJp bGl0eS8yMDA2IiB4bWxuczptPTNEImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jPQ0KPiBvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptcmVscz0zRCJodHRwOi8vc2NoZW1hcy5vcGVueG1s Zm9ybWF0cy5vcmcvcGE9DQo+IGNrYWdlLzIwMDYvcmVsYXRpb25zaGlwcyIgeG1sbnM6c3B3cD0z RCJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3dlYj0NCj4gcGFydHBhZ2VzIiB4bWxu czpleDEydD0zRCJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2Vz LzIwPQ0KPiAwNi90eXBlcyIgeG1sbnM6ZXgxMm09M0QiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9leGNoYW5nZS9zZXJ2aWNlcy8yMDA9DQo+IDYvbWVzc2FnZXMiIHhtbG5zOnBwdHNsPTNE Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaT0NCj4gZGVM aWJyYXJ5LyIgeG1sbnM6c3BzbD0zRCJodHRwOi8vbWljcm9zb2Z0LmNvbS93ZWJzZXJ2aWNlcy9T aGFyZVBvaW50UG9ydGFsPQ0KPiBTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpa PTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206IiB4bWxuczo9DQo+IHN0PTNEIiYjMTsiIHht bG5zPTNEImh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPiA8aGVhZD4NCj4gPG1l dGEgaHR0cC1lcXVpdj0zRCJDb250ZW50LVR5cGUiIGNvbnRlbnQ9M0QidGV4dC9odG1sOyBjaGFy c2V0PTNEdXMtYXNjaWkiPQ0KPiA+DQo+IDxtZXRhIG5hbWU9M0QiR2VuZXJhdG9yIiBjb250ZW50 PTNEIk1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCj4gPHN0eWxlPjwhLS0N Cj4gLyogRm9udCBEZWZpbml0aW9ucyAqLw0KPiBAZm9udC1mYWNlDQo+ICAgICAgIHtmb250LWZh bWlseTpTaW1TdW47DQo+ICAgICAgIHBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KPiBA Zm9udC1mYWNlDQo+ICAgICAgIHtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCj4gICAgICAg cGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQo+IEBmb250LWZhY2UNCj4gICAgICAge2Zv bnQtZmFtaWx5OkNhbGlicmk7DQo+ICAgICAgIHBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0 O30NCj4gQGZvbnQtZmFjZQ0KPiAgICAgICB7Zm9udC1mYW1pbHk6U2ltU3VuOw0KPiAgICAgICBw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCj4gLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N Cj4gcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KPiAgICAgICB7bWFy Z2luOjBpbjsNCj4gICAgICAgbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KPiAgICAgICBmb250LXNp emU6MTEuMHB0Ow0KPiAgICAgICBmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N Cj4gYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KPiAgICAgICB7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KPiAgICAgICBjb2xvcjpibHVlOw0KPiAgICAgICB0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCj4gYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQo+ICAgICAgIHtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQo+ICAgICAgIGNvbG9yOnB1cnBsZTsNCj4gICAgICAgdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQo+IHByZQ0KPiAgICAgICB7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KPiAgICAgICBtc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQo+ICAgICAgIG1hcmdpbjowaW47DQo+ICAgICAgIG1hcmdpbi1ib3R0b206LjAwMDFwdDsNCj4g ICAgICAgZm9udC1zaXplOjEwLjBwdDsNCj4gICAgICAgZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQo+IHNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCj4gICAgICAge21zby1zdHlsZS1uYW1l OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCj4gICAgICAgbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KPiAgICAgICBtc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KPiAgICAgICBm b250LWZhbWlseToiQ291cmllciBOZXciO30NCj4gc3Bhbi5FbWFpbFN0eWxlMTkNCj4gICAgICAg e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KPiAgICAgICBmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KPiAgICAgICBjb2xvcjp3aW5kb3d0ZXh0O30NCj4gc3Bhbi5FbWFpbFN0 eWxlMjANCj4gICAgICAge21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KPiAgICAgICBm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KPiAgICAgICBjb2xvcjojMUY0OTdE O30NCj4gLk1zb0NocERlZmF1bHQNCj4gICAgICAge21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KPiAgICAgICBmb250LXNpemU6MTAuMHB0O30NCj4gQHBhZ2UgV29yZFNlY3Rpb24xDQo+ICAg ICAgIHtzaXplOjguNWluIDExLjBpbjsNCj4gICAgICAgbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBp biAxLjI1aW47fQ0KPiBkaXYuV29yZFNlY3Rpb24xDQo+ICAgICAgIHtwYWdlOldvcmRTZWN0aW9u MTt9DQo+IC0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo+IDxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9M0QiZWRpdCIgc3BpZG1heD0zRCIxMDI2IiAvPg0KPiA8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCj4gPG86c2hhcGVsYXlvdXQgdjpleHQ9M0Qi ZWRpdCI+DQo+IDxvOmlkbWFwIHY6ZXh0PTNEImVkaXQiIGRhdGE9M0QiMSIgLz4NCj4gPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPiA8L2hlYWQ+DQo+IDxib2R5IGxhbmc9M0Qi RU4tVVMiIGxpbms9M0QiYmx1ZSIgdmxpbms9M0QicHVycGxlIj4NCj4gPGRpdiBjbGFzcz0zRCJX b3JkU2VjdGlvbjEiPg0KPiA8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPTNEImNv bG9yOiMxRjQ5N0QiPkZvciB0aG9zZSBvZiB5b3Ugd2hvIHQ9DQo+IG91Y2ggdXBvbiBEYXRhIENl bnRlciBuZXR3b3JraW5nIG9yIHNlcnZlciB2aXJ0dWFsaXphdGlvbiwgYmUgaXQgT3ZlcmxheSwg Vj0NCj4gUE40REMsIG9yIEFwcGxpY2F0aW9uL1NvZnR3YXJlIGRyaXZlbiBDb250cm9sbGVyIGZv ciBEYXRhIENlbnRlciwgQWRkcmVzcyBSPQ0KPiBlc29sdXRpb24gaXMgc29tZXRoaW5nIERhdGEg Q2VudGVyIEdhdGV3YXlzDQo+ICAmbmJzcDt3aWxsIGVuY291bnRlciBiZWNhdXNlIGhvc3RzL2Fw cGxpY2F0aW9ucyBpbiBkYXRhIGNlbnRlcnMgZG8gY29tbXVuaT0NCj4gY2F0ZSB3aXRoIHBlZXJz IHdoaWNoIGFyZSBub3QgaW4gdGhlIHNhbWUgT3ZlcmxheSwgb3V0c2lkZSB0aGUgVlBOIGRvbWFp biwgPQ0KPiBvciBmcm9tIGdlbmVyYWwgcHVibGljLiBBUk1EIGhhcyBwdWJsaXNoZWQgaXRzIFdH IHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0LiA9DQo+IFlvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rp b25zIGFyZSBhcHByZWNpYXRlZA0KPiAgKHNlbmQgdG8gPGEgaHJlZj0zRCJtYWlsdG86YXJtZEBp ZXRmLm9yZyI+YXJtZEBpZXRmLm9yZzwvYT4pLiA8bzpwPjwvbzpwPjw9DQo+IC9zcGFuPjwvcD4N Cj4gPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0zRCJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3BhPQ0KPiBuPjwvcD4NCj4gPHAgY2xhc3M9M0QiTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0zRCJjb2xvcjojMUY0OTdEIj5UaGFua3MsIExpbmRhIER1bmJhcjxvPQ0K PiA6cD48L286cD48L3NwYW4+PC9wPg0KPiA8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPTNEImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGE9DQo+IG4+PC9wPg0K PiA8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPTNEImNvbG9yOiMxRjQ5N0QiPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS09DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcz0NCj4gcGFuPjwvcD4N Cj4gPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0zRCJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3BhPQ0KPiBuPjwvcD4NCj4gPHAgY2xhc3M9M0QiTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCj4gPHByZT5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyPQ0KPiBlY3Rvcmll cy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQWRkcmVzcyBSZXNvbHV0aW9uIGZv ciBNYXNzaXZlIG49DQo+IHVtYmVycyBvZiBob3N0cyBpbiB0aGUgRGF0YSBjZW50ZXIgV29ya2lu ZyBHcm91cCBvZiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcD0NCj4gcmU+DQo+IDxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCj4gPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzPQ0KPiBwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IFByb2JsZW0gU3RhdGVtZW50IGZvciBBUk1EPG86 cD48L289DQo+IDpwPjwvcHJlPg0KPiA8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBBdXRob3IocykmbmJzcDsmbmJzcDsmbmJzcDs9DQo+ICZuYnNwOyZuYnNw OyZuYnNwOyA6IFRob21hcyBOYXJ0ZW48bzpwPjwvbzpwPjwvcHJlPg0KPiA8cHJlPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWxlbmFtZSZuYnNwOyZuYnNwOyZu YnNwOyY9DQo+IG5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1hcm1kLXByb2Js ZW0tc3RhdGVtZW50LTAwLnR4dDxvOnA+PC9vOj0NCj4gcD48L3ByZT4NCj4gPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGFnZXMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzPQ0KPiBwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDExPG86 cD48L286cD48L3ByZT4NCj4gPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwPQ0KPiA7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjAxMS0xMC0xNzxvOnA+PC9vOnA+PC9wcmU+ DQo+IDxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCj4gPHByZT4mbmJzcDsmbmJzcDsgVGhp cyBkb2N1bWVudCBleGFtaW5lcyBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgbWFzc2l2ZSBzY2FsPQ0K PiBpbmcgb2YgZGF0YTxvOnA+PC9vOnA+PC9wcmU+DQo+IDxwcmU+Jm5ic3A7Jm5ic3A7IGNlbnRl cnMuJm5ic3A7IE91ciBpbml0aWFsIHNjb3BlIGlzIHJlbGF0aXZlbHkgbmFycm93LiZuYj0NCj4g c3A7IFNwZWNpZmljYWxseSwgd2U8bzpwPjwvbzpwPjwvcHJlPg0KPiA8cHJlPiZuYnNwOyZuYnNw OyBmb2N1cyBvbiBhZGRyZXNzIHJlc29sdXRpb24gKEFSUCBhbmQgTkQpIHdpdGhpbiB0aGUgZGF0 YSA9DQo+IGNlbnRlci48bzpwPjwvbzpwPjwvcHJlPg0KPiA8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo+IDxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCj4gPHByZT5BIFVSTCBmb3Ig dGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8bzpwPjwvbzpwPjwvcHJlPg0KPiA8cHJlPjxhIGhyZWY9 M0QiaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hcm1kLXBy b2JsZW09DQo+IC1zdGF0ZW1lbnQtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLWFybWQtcHJvYj0NCj4gbGVtLXN0YXRlbWVudC0wMC50eHQ8L2E+ PG86cD48L286cD48L3ByZT4NCj4gPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPiA8cHJl PkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8 bzpwPjwvbzpwPjwvcHI9DQo+IGU+DQo+IDxwcmU+PGEgaHJlZj0zRCJmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLyI+ZnRwOi8vZnRwLmlldGYub3JnL2ludD0NCj4gZXJuZXQtZHJh ZnRzLzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPiA8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo+IDxwcmU+VGhpcyBJbnRlcm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVkIGF0OjxvOnA+PC9v OnA+PC9wcmU+DQo+IDxwcmU+PGEgaHJlZj0zRCJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtYXJtZC1wcm9ibGVtLT0NCj4gc3RhdGVtZW50LTAwLnR4dCI+ZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWFybWQtcHJvYmxlPQ0K PiBtLXN0YXRlbWVudC0wMC50eHQ8L2E+PG86cD48L286cD48L3ByZT4NCj4gPHAgY2xhc3M9M0Qi TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCj4gPC9kaXY+DQo+IDwvYm9keT4NCj4g PC9odG1sPg0KPg0KPiAtLUJvdW5kYXJ5XyhJRF8yeFlFUWFiU0pVSmVYeGlvZ01KMGZRKS0tDQo+ DQo+IC0tQm91bmRhcnlfKElEX3BxeFpIT0ZYR0E2OWdKdWhMeUVHK0EpDQo+IENvbnRlbnQtaWQ6 IDwzMThEMzI4MkNGQ0QwQzQ1QThDOTkyODNGRjM4Mjg5QUBodWF3ZWkuY29tPg0KPiBDb250ZW50 LXR5cGU6IHRleHQvcGxhaW47IG5hbWU9QVRUMDAwMDEudHh0DQo+IENvbnRlbnQtdHJhbnNmZXIt ZW5jb2Rpbmc6IDdCSVQNCj4gQ29udGVudC1kaXNwb3NpdGlvbjogYXR0YWNobWVudDsgZmlsZW5h bWU9QVRUMDAwMDEudHh0OyBzaXplPTEyNzsNCj4gIGNyZWF0aW9uLWRhdGU9IkZyaSwgMDQgTm92 IDIwMTEgMTU6MzA6MzEgR01UIjsNCj4gIG1vZGlmaWNhdGlvbi1kYXRlPSJGcmksIDA0IE5vdiAy MDExIDE1OjMwOjMxIEdNVCINCj4gQ29udGVudC1kZXNjcmlwdGlvbjogQVRUMDAwMDEudHh0DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFy bWQgbWFpbGluZyBsaXN0DQo+IGFybWRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hcm1kDQo+DQo+IC0tQm91bmRhcnlfKElEX3BxeFpIT0ZYR0E2OWdK dWhMeUVHK0EpLS0NCg== From ben@niven-jenkins.co.uk Tue Nov 15 17:37:53 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 1BDF821F8D1C for ; Tue, 15 Nov 2011 17:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.325, 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 QBVEtP9C1Rlq for ; Tue, 15 Nov 2011 17:37:49 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id F2DD321F8D11 for ; Tue, 15 Nov 2011 17:37:48 -0800 (PST) Received: from dhcp-15fb.meeting.ietf.org ([130.129.21.251]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RQURf-0001QS-5o for l3vpn@ietf.org; Wed, 16 Nov 2011 01:37:47 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Slides for L3VPN agenda @ IETF82 From: Ben Niven-Jenkins In-Reply-To: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> Date: Wed, 16 Nov 2011 01:37:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> To: "l3vpn@ietf.org mailing list" 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: Wed, 16 Nov 2011 01:37:53 -0000 Colleagues, The slides that will be used in the L3VPN session this afternoon are now = available from the meeting material page, i.e. here: https://datatracker.ietf.org/meeting/82/materials.html Ben On 14 Nov 2011, at 11:50, Ben Niven-Jenkins wrote: > Colleagues, >=20 > I have uploaded a new version of the L3VPN/VPN4DC agenda which = includes the names of the people who will lead each topic. You can find = it here: >=20 > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt >=20 > The agenda is not arranged around specific drafts per-se but Marshall = & I have asked the person leading each topic to co-ordinate with the = various draft authors to produce a consolidated view/presentation which = they will present on behalf of the numerous authors/contributors. >=20 > As a reminder: We have purposely not put time on the agenda to = present/discuss specific solution drafts as we would like the discussion = to be focussed on the problem/requirements posed by VPN4DC and its = applicability to IETF (including L3VPN). Discussion of specific solution = proposals can happen at future meetings if the VPN4DC work is adopted. >=20 > Ben >=20 From xuxiaohu@huawei.com Tue Nov 15 18:03: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 921C411E815B; Tue, 15 Nov 2011 18:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=1.885, 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 CJsF3NXAw2Zm; Tue, 15 Nov 2011 18:03:37 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id F2BCF11E818E; Tue, 15 Nov 2011 18:03:36 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ005KADORJ3@szxga03-in.huawei.com>; Wed, 16 Nov 2011 10:02:51 +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 <0LUQ0061LDNZWM@szxga03-in.huawei.com>; Wed, 16 Nov 2011 10:02:51 +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 AFB64641; Wed, 16 Nov 2011 10:02:51 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 10:02:47 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 10:02:45 +0800 Date: Wed, 16 Nov 2011 02:02:45 +0000 From: Xuxiaohu Subject: re: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: X-Originating-IP: [172.24.2.41] To: Pedro Marques , Susan Hares Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BDE5@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMo76d77GNeTc5a0yss6siAfODR5Wuu7sI X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> <201111142042.pAEKg1h21336@magenta.juniper.net> <011101cca35e$a93be5b0$fbb3b110$@com> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , Yakov Rekhter , L3VPN WG mailing list , "armd@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, 16 Nov 2011 02:03:41 -0000 The concept of an L2/L3 boundary is not useful if you assume that a VM can be placed in an arbitrary location. Anywhere you choose to put that "boundary": top-of-rack, aggregation, etc, you are likely to find that the boundary gets in the way of the VMs being able to be located anywhere. At least without causing traffic to cross the core twice which is a non-starter. Agree. So to actually solve the problem according to requirements one needs to get rid of the boundary and move to a solution that is all L2 or all L3. And ARP/ND is really not a relevant problem. With an "L2" solution tends to come the assumption that there is a single "isolation" domain... and a single subnet, which doesn't really cut it. "L3" and specially BGP-based IP/VPNs natively support the concept of direct traffic exchanges between different isolation domains, subject to policy. Even if you do decide to select an L2 approach that limits an application to a single isolation domain, the L2 mac information will need to be present at every switch where that L2 VLAN is present. If you follow an approach where there is core-interface to core-interface mac-learning (VXLAN for instance) then indeed you do have ARP broadcasts being used to update forwarding tables. But approaches such as EVPN can perform learning on the edge interface only eliminating the need to generate ARP broadcasts. It is entirely likely that the approaches that attempt to provide for large broadcast domains already contain a solution for L2 address discovery. Conversely it is rather unclear that you can address the ARP/ND scaling issue independently of the design of the L2 solution itself. Reasonable. However, the ARP cache mechanism is suitble for most MAC-forwarding based DCN solutions (e.g., VPLS) and much helpful for ARP broadcast reduction unless the L2VPN PE function is pushed to the physical server. Best regards, Xiaohu regards, Pedro. On Mon, Nov 14, 2011 at 10:20 PM, Susan Hares wrote: > Yakov: > > We are not trying to justify any definition we have, but to report what DC > operators have given as the problem in an OPS draft. > > In many ways, the text has been successful by having you comment on this > point so that operators can consider in depth this scenario. > > With all due respect to you as a grand master of word-smithing, let me > restate some of the argument so that I can attempt to inspire discussion. > > The "all" in this discussion indicates "all" within this domain which > crosses the VLANs in the text. The 802.1q VLAN mechanism provides some > scoping of broadcast and unicast for an L2 grouping. The IP Subset provides > a scoping for scoping for IP (L3 grouping). ARP maps the L2 grouping to the > l3 grouping. The growth in the number of nodes (VM or access) in the > combined groupings of mapped nodes are the problem. > > If you want to restrict nodes within this at L2 or L3, you must find a means > to determine the L2 grouping. The mapping of the IP to MAC Address is scoped > by the combination of L2/L3 grouping. > > So.. at some point the VM or the real nodes reach an "aggregation grouping" > at the access switch or the VMs forming an access switch. This grouping > point is stressed by the underlying growth of L2/L3 node combination. On the > ARMD BOF/List, Manish Karir (Merit) published a study in looking at the ARP > problem using VMs groupings. > > Some large scale operators stated the VM aggregation I described above did > not represent a case widely used. Therefore the discussion focused on the > deployed access switches, servers, and VMs as described in the text. Please > refer to past discussion from Igor G. on this list or his drafts on > solutions/problems. Also, you can refer to NANOG session on this. > > Yakov - let me know of I am unclear or just misunderstood your discussion > point. Linda, Manish, and Igor let me know if I was incorrect in anything I > said. > > Hopefully, I've given the discussion a push. If nothing else, it will > > Sue > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Yakov Rekhter > Sent: Monday, November 14, 2011 3:42 PM > To: Linda Dunbar > Cc: l2vpn@ietf.org; sdnp@lucidvision.com; L3VPN WG mailing list; > armd@ietf.org; yakov@juniper.net; Pedro Marques > Subject: Re: [armd] Need your action to review > draft-ietf-armd-problem-statement-00.txt > > Linda, > >> Pedro, >> >> You are absolutely right that there is no ARP/ND scaling issue if IP >> can be extended to hosts. Even if IP can be extended to Access >> switches, there is not much ARP/ND issues. >> >> The draft lists down several common data center network designs, and >> states that some of the designs don't have ARP/ND scaling issues (but >> may have other issues for data centers). >> >> That is why I encourage people to read the draft and provides >> comments. > > From 4.2 of the draft: > > 4.2. Scenario 2: L3 Terminates at the Aggregation Switch > > In Scenario 2, the L3 network extends only to the aggregation > switches (or perhaps to routers that connect to the aggregation > switches). The aggregation switches (or the routers that connect to > multiple aggregation switches) could terminate multiple distinct IP > subnets (e.g., one per VLAN) or one large IP subnet. In order to let > hosts belonging to different IP subnets be placed under any access > switches, it is necessary for access switches to enable multiple > VLANs and aggregation switches to enable some VLANs (or subnets) over > many physical ports. This configuration breaks the confinement of > the VLAN's broadcast domain and makes it equivalent to all the access > switches being part of the same L2 broadcast domain (and IP subnet). > Thus, this configuration allows VMs to be moved to servers connected > to other access switches, but increases the size of the L2 broadcast > domain, which can lead to difficulties outlined below. > > This is the scenario that is used to justify the need for large L2 domain. > > The draft assumes that in order to move a given VM from one server to > another, where these two servers are connected to different access switches, > *all* the access switches must be configured with the VM's IP subnet, and > thus *all* the access switches must be part of the VM's L2 broadcast domain. > This is even if at any particular point in time the servers hosting all the > VMs of that IP subnet are connected to only a subset of these switches. But > is it truly necessary, or could the L2 broadcast domain span only the > switches connected to the servers that presently host VMs of the IP subnet ? > > Moreover, even if all the access switches need to be part of the same L2 > broadcast domain, the increase in the size of the L2 broadcast domain in the > above scenario is caused by the access switches, not by the number of VMs > per L2 domain. The difficulies mentioned in the last sentence of the quoted > paragraph are due to ARP, but ARP is generated by VMs, not by the access > switches. Given that, how the increase in the size of the L2 broadcast > domain *due solely to the access switches*, could increase the amount of ARP > traffic that routers have to process ? > > Yakov. > >> >> > -----Original Message----- >> > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >> > Sent: Wednesday, November 09, 2011 1:52 PM >> > To: Linda Dunbar >> > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; >> > armd@ietf.org >> > Subject: Re: Need your action to review draft-ietf-armd-problem- >> > statement-00.txt >> > >> > Linda, >> > I'd like to point out that the problem does not need to be solved if >> > only IP connectivity is required. This I-D: >> > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >> > describes a solution in which address resolution is not required >> > irrespective of the location of the traffic destination. Simply put, >> > traffic can be routed at each hop. >> > >> > As per previous threads in this list, the concept of subnet which is >> > of no practical usefulness in this space. Since VMs can be randomly >> distributed across the network the subnet does not provide any >> > information aggregation value. Thus there is no need to do address >> > resolution. >> > >> > Pedro. >> > >> > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar >> > >> > wrote: >> > > For those of you who touch upon Data Center networking or server >> > > virtualization, be it Overlay, VPN4DC, or Application/Software >> > > driven Controller for Data Center, Address Resolution is something >> > > Data >> > Center >> > > Gateways will encounter because hosts/applications in data >> > > centers >> > do >> > > communicate with peers which are not in the same Overlay, outside >> > > the >> > VPN >> > > domain, or from general public. ARMD has published its WG problem >> > statement >> > > draft. Your comments and suggestions are appreciated (send to >> > > armd@ietf.org). >> > > >> > > >> > > >> > > Thanks, Linda Dunbar >> > > >> > > >> > > >> > > ------------------------------------------------------------------ >> > > --- >> > -------------- >> > > >> > > >> > > >> > > >> > > >> > > A New Internet-Draft is available from the on-line Internet-Drafts >> > > directories. This draft is a work item of the Address Resolution >> > > for >> > Massive >> > > numbers of hosts in the Data center Working Group of the IETF. >> > > >> > > >> > > >> > > Title : Problem Statement for ARMD >> > > >> > > Author(s) : Thomas Narten >> > > >> > > Filename : draft-ietf-armd-problem-statement-00.txt >> > > >> > > Pages : 11 >> > > >> > > Date : 2011-10-17 >> > > >> > > >> > > >> > > This document examines issues related to the massive scaling of >> > data >> > > >> > > centers. Our initial scope is relatively narrow. >> > > Specifically, >> > we >> > > >> > > focus on address resolution (ARP and ND) within the data center. >> > > >> > > >> > > >> > > >> > > >> > > A URL for this Internet-Draft is: >> > > >> > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- >> > statement-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-ietf-armd-problem-stateme >> > > nt- >> > 00.txt >> > > >> > > >> > > _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From giles.heron@gmail.com Tue Nov 15 18:11: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 E772311E81A0 for ; Tue, 15 Nov 2011 18:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 p14wIRlrpaRn for ; Tue, 15 Nov 2011 18:11:25 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 727A811E81A4 for ; Tue, 15 Nov 2011 18:11:16 -0800 (PST) Received: by iaeo4 with SMTP id o4so11840968iae.31 for ; Tue, 15 Nov 2011 18:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=2z1xxje4zf/5dcM9P8mvD39kfFiwxq+Meh3aoI8DX0Y=; b=PDBXFjCutQOr9b+gDvB1mCw35uUH2NFLM/jGjKebI82hVh0a+dnbSydlarSvIKrzru X4cDVr2PGZbXmZ2HRZJFr0oSykdbtHMm9SC0oh/XkeD2M2vCc5OjX7ZTfSlWz5hwCBMY i74QiKTdu8nUqATEXGVidUVAWd4dIwUAKO6b8= Received: by 10.42.151.196 with SMTP id f4mr30010740icw.17.1321409458957; Tue, 15 Nov 2011 18:10:58 -0800 (PST) Received: from [10.21.88.148] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id g16sm37850877ibs.8.2011.11.15.18.10.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 18:10:58 -0800 (PST) User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 16 Nov 2011 02:10:54 +0000 Subject: Re: Slides for L3VPN agenda @ IETF82 From: Giles Heron To: Ben Niven-Jenkins , "l3vpn@ietf.org mailing list" Message-ID: Thread-Topic: Slides for L3VPN agenda @ IETF82 Thread-Index: AcykBPhUIy/+RYeFGUKWYvLUXaXqLA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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, 16 Nov 2011 02:11:29 -0000 Quick comment on the discussion slides. On slide 4 did you mean "L2vpn technologies MAY be used within data centers", or "L2 technologies MAY be used within data centres"? Giles On 16/11/2011 01:37, "Ben Niven-Jenkins" wrote: > Colleagues, > > The slides that will be used in the L3VPN session this afternoon are now > available from the meeting material page, i.e. here: > > https://datatracker.ietf.org/meeting/82/materials.html > > Ben > > On 14 Nov 2011, at 11:50, Ben Niven-Jenkins wrote: > >> Colleagues, >> >> I have uploaded a new version of the L3VPN/VPN4DC agenda which includes the >> names of the people who will lead each topic. You can find it here: >> >> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt >> >> The agenda is not arranged around specific drafts per-se but Marshall & I >> have asked the person leading each topic to co-ordinate with the various >> draft authors to produce a consolidated view/presentation which they will >> present on behalf of the numerous authors/contributors. >> >> As a reminder: We have purposely not put time on the agenda to >> present/discuss specific solution drafts as we would like the discussion to >> be focussed on the problem/requirements posed by VPN4DC and its applicability >> to IETF (including L3VPN). Discussion of specific solution proposals can >> happen at future meetings if the VPN4DC work is adopted. >> >> Ben >> > From linda.dunbar@huawei.com Tue Nov 15 18:16: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 4BDE511E810A; Tue, 15 Nov 2011 18:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNB61oCxp4oC; Tue, 15 Nov 2011 18:16:28 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id CF4B221F8DEF; Tue, 15 Nov 2011 18:16:28 -0800 (PST) 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 <0LUQ0033CEBFGC@usaga02-in.huawei.com>; Tue, 15 Nov 2011 20:16:28 -0600 (CST) 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 <0LUQ006O9EBFJF@usaga02-in.huawei.com>; Tue, 15 Nov 2011 20:16:27 -0600 (CST) 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, 15 Nov 2011 18:16:24 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Tue, 15 Nov 2011 18:16:02 -0800 Date: Wed, 16 Nov 2011 02:16:02 +0000 From: Linda Dunbar Subject: RE: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: <201111151919.pAFJJJh74426@magenta.juniper.net> X-Originating-IP: [10.47.141.142] To: Yakov Rekhter Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMo8vVNnT5eJ8uDU6UO66dRJaZAJWvSePw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@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, 16 Nov 2011 02:16:29 -0000 Yakov, You are absolutely right. We will make sure it is properly captured in the document. Thanks, Linda > -----Original Message----- > > Should the overhead due to the broadcast unknown be considered as yet > another "pain point" associated with large L2 domains ? > > Yakov. > From xuxiaohu@huawei.com Tue Nov 15 18:39: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 BC0151F0C9D for ; Tue, 15 Nov 2011 18:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97ZZcbfPxtx3 for ; Tue, 15 Nov 2011 18:38:59 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7273F1F0C9B for ; Tue, 15 Nov 2011 18:38:59 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00MMHFBYI9@szxga05-in.huawei.com> for l3vpn@ietf.org; Wed, 16 Nov 2011 10:38:23 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ0045DFBYWK@szxga05-in.huawei.com> for l3vpn@ietf.org; Wed, 16 Nov 2011 10:38:22 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA13001; Wed, 16 Nov 2011 10:38:20 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 10:37:58 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 10:37:32 +0800 Date: Wed, 16 Nov 2011 02:37:53 +0000 From: Xuxiaohu Subject: re: Slides for L3VPN agenda @ IETF82 In-reply-to: X-Originating-IP: [172.24.2.41] To: Ben Niven-Jenkins , "l3vpn@ietf.org mailing list" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Slides for L3VPN agenda @ IETF82 Thread-index: AQHMpABi3hhbuKdOVE+mYh8wfPnXYpWuxW/B X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> 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, 16 Nov 2011 02:39:03 -0000 SGksDQoNCkkgd29uZGVyIHdoZXRoZXIgdGhlIHNsaWRlcyB0aXRsZWQgIlZQTjREQyBzbGlkZXMi IGFyZSB0aGUgbWFpbiBzbGlkZXMgZm9yIGRpc2N1c3Npb24uIA0KDQpZZXMsIG5vIG9uZSBkb3Vi dHMgdGhhdCAibGF5ZXIgMyAoSVAgb3IgTVBMUykgVlBOIGNvbm5lY3Rpdml0eSBpcyBpbiBJRVRG IHJvdXRpbmcgYXJlYSIuIEhvd2V2ZXIsIGl0IHNlZW1zIHRvIG1lIHRoYXQgaXQncyBzdGlsbCBu b3QgY2xlYXJseSBleHBsYWluZWQgaW4gdGhvc2Ugc2xpZGVzIHdoeSBJUCBwcm90b2NvbCBleHRl bnNpb25zIG9yIG5ldyBtZWNoYW5pc20gZm9yIGN1cnJlbnQgc29sdXRpb25zIHRvIERDIGlzIHJl cXVpcmVkLg0KDQpJZiBJIHJlbWVtYmVyZWQgY29ycmVjdGx5LCBpdCBpcyBzYWlkIGluIHRoZSBC b0YgbGF1bmNoIGVtYWlsIHRoYXQgdGhlcmUgYXJlIGF0IGxlYXN0IHR3byBxdWVzdGlvbnMgd2hp Y2ggbmVlZCB0byBiZSBhbnN3ZXJlZCBiZWZvcmUgY29uc2lkZXJpbmcgZGV2ZWxvcGluZyBhbnkg bmV3IHByb3RvY29scy4gVGhlIGZpcnN0IGlzIHdoZXRoZXIgdGhlIGN1cnJlbnQgTDNWUE4gYXBw cm9hY2ggY2FuIG1lZXQgdGhlIHJlcXVpcmVtZW50IGZvciBEQ04gb3IgRENJLCBhbmQgdGhlIHNl Y29uZCBpcyB3ZXRoZXIgdGhlIG1hbmFnZW1lbnQgdG9vbHMgYXJlIGFscmVhZHkgZW5vdWdoIHRv IG1lZXQgdGhlIHJlcXVpcmVtZW50LiBJIHRoaW5rIHRoZXNlIHR3byBxdWVzdGlvbiB3aWxsIGhl bHAgdXMgdG8gZXhwbG9yZSBtb3JlIGRlZXBseSB3aGF0IHRoZSByZWFsIHByb2JsZW1zIGFyZS4N Cg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCreivP7IyzogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbDN2cG4tYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBCZW4gTml2ZW4tSmVua2lucyBbYmVuQG5pdmVuLWplbmtpbnMuY28u dWtdDQq3osvNyrG85DogMjAxMcTqMTHUwjE2yNUgOTozNw0Ktb06IGwzdnBuQGlldGYub3JnIG1h aWxpbmcgbGlzdA0K1vfM4jogU2xpZGVzIGZvciBMM1ZQTiBhZ2VuZGEgQCBJRVRGODINCg0KQ29s bGVhZ3VlcywNCg0KVGhlIHNsaWRlcyB0aGF0IHdpbGwgYmUgdXNlZCBpbiB0aGUgTDNWUE4gc2Vz c2lvbiB0aGlzIGFmdGVybm9vbiBhcmUgbm93IGF2YWlsYWJsZSBmcm9tIHRoZSBtZWV0aW5nIG1h dGVyaWFsIHBhZ2UsIGkuZS4gaGVyZToNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9t ZWV0aW5nLzgyL21hdGVyaWFscy5odG1sDQoNCkJlbg0KDQpPbiAxNCBOb3YgMjAxMSwgYXQgMTE6 NTAsIEJlbiBOaXZlbi1KZW5raW5zIHdyb3RlOg0KDQo+IENvbGxlYWd1ZXMsDQo+DQo+IEkgaGF2 ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBMM1ZQTi9WUE40REMgYWdlbmRhIHdoaWNo IGluY2x1ZGVzIHRoZSBuYW1lcyBvZiB0aGUgcGVvcGxlIHdobyB3aWxsIGxlYWQgZWFjaCB0b3Bp Yy4gWW91IGNhbiBmaW5kIGl0IGhlcmU6DQo+DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvODIvYWdlbmRhL2wzdnBuLnR4dA0KPg0KPiBUaGUgYWdlbmRhIGlzIG5vdCBhcnJhbmdl ZCBhcm91bmQgc3BlY2lmaWMgZHJhZnRzIHBlci1zZSBidXQgTWFyc2hhbGwgJiBJIGhhdmUgYXNr ZWQgdGhlIHBlcnNvbiBsZWFkaW5nIGVhY2ggdG9waWMgdG8gY28tb3JkaW5hdGUgd2l0aCB0aGUg dmFyaW91cyBkcmFmdCBhdXRob3JzIHRvIHByb2R1Y2UgYSBjb25zb2xpZGF0ZWQgdmlldy9wcmVz ZW50YXRpb24gd2hpY2ggdGhleSB3aWxsIHByZXNlbnQgb24gYmVoYWxmIG9mIHRoZSBudW1lcm91 cyBhdXRob3JzL2NvbnRyaWJ1dG9ycy4NCj4NCj4gQXMgYSByZW1pbmRlcjogV2UgaGF2ZSBwdXJw b3NlbHkgbm90IHB1dCB0aW1lIG9uIHRoZSBhZ2VuZGEgdG8gcHJlc2VudC9kaXNjdXNzIHNwZWNp ZmljIHNvbHV0aW9uIGRyYWZ0cyBhcyB3ZSB3b3VsZCBsaWtlIHRoZSBkaXNjdXNzaW9uIHRvIGJl IGZvY3Vzc2VkIG9uIHRoZSBwcm9ibGVtL3JlcXVpcmVtZW50cyBwb3NlZCBieSBWUE40REMgYW5k IGl0cyBhcHBsaWNhYmlsaXR5IHRvIElFVEYgKGluY2x1ZGluZyBMM1ZQTikuIERpc2N1c3Npb24g b2Ygc3BlY2lmaWMgc29sdXRpb24gcHJvcG9zYWxzIGNhbiBoYXBwZW4gYXQgZnV0dXJlIG1lZXRp bmdzIGlmIHRoZSBWUE40REMgd29yayBpcyBhZG9wdGVkLg0KPg0KPiBCZW4NCj4NCg0K From xuxiaohu@huawei.com Tue Nov 15 19:24: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 9C5EE11E809C; Tue, 15 Nov 2011 19:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob2Tcp76FL2j; Tue, 15 Nov 2011 19:24:11 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0305C11E8089; Tue, 15 Nov 2011 19:24:11 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00EJYHDDJG@szxga04-in.huawei.com>; Wed, 16 Nov 2011 11:22:25 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00BQEHDDXF@szxga04-in.huawei.com>; Wed, 16 Nov 2011 11:22:25 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA16627; Wed, 16 Nov 2011 11:22:25 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 11:22:20 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 11:21:52 +0800 Date: Wed, 16 Nov 2011 03:22:13 +0000 From: Xuxiaohu Subject: re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> X-Originating-IP: [172.24.2.41] To: Linda Dunbar , Yakov Rekhter Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEA6@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMpAfDSj1Fik0WlEub2ME5FLnYWJWu1HW5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@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, 16 Nov 2011 03:24:11 -0000 DQpCeSB0aGUgd2F5LCBJIGFsc28gbm90aWNlZCB0aGF0IHRoZSBNQUMgZm9yd2FyZGluZyB0YWJs ZSBzY2FsYWJpbGl0eSBpc3N1ZSBpcyBtZW50aW9uZWQgaW4gdGhlIEFSTUQgcHJvYmxlbSBzdGF0 ZW1lbnQgZG9jLiBTaG91bGQgd2UgZXh0ZW5kIHRoZSBjaGFydGVyIHNjb3BlIG9mIEFSTUQgV0cg b3IgcmUtZm9ybSB0aGUgRENPUFMgV0cgdG8gZGlzY3VzcyBzbyBtYW55IGNoYWxsZW5nZXMgYW5k IHJlcXVpcmVtZW50cyBpbiBkYXRhIGNlbnRlcnM/DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBsMnZwbi1i b3VuY2VzQGlldGYub3JnIFtsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExpbmRhIER1bmJh ciBbbGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQq3osvNyrG85DogMjAxMcTqMTHUwjE2yNUgMTA6 MTYNCrW9OiBZYWtvdiBSZWtodGVyDQpDYzogbDJ2cG5AaWV0Zi5vcmc7IHNkbnBAbHVjaWR2aXNp b24uY29tOyBMM1ZQTiBXRyBtYWlsaW5nIGxpc3Q7IGFybWRAaWV0Zi5vcmcNCtb3zOI6IFJFOiBO ZWVkIHlvdXIgYWN0aW9uIHRvIHJldmlldyAgICAgIGRyYWZ0LWlldGYtYXJtZC1wcm9ibGVtLXN0 YXRlbWVudC0wMC50eHQNCg0KWWFrb3YsDQoNCllvdSBhcmUgYWJzb2x1dGVseSByaWdodC4gV2Ug d2lsbCBtYWtlIHN1cmUgaXQgaXMgcHJvcGVybHkgY2FwdHVyZWQgaW4gdGhlIGRvY3VtZW50Lg0K DQpUaGFua3MsIExpbmRhDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPg0KPiBT aG91bGQgdGhlIG92ZXJoZWFkIGR1ZSB0byB0aGUgYnJvYWRjYXN0IHVua25vd24gYmUgY29uc2lk ZXJlZCBhcyB5ZXQNCj4gYW5vdGhlciAicGFpbiBwb2ludCIgYXNzb2NpYXRlZCB3aXRoIGxhcmdl IEwyIGRvbWFpbnMgPw0KPg0KPiBZYWtvdi4NCj4NCg== From linda.dunbar@huawei.com Tue Nov 15 19:27:47 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 D865811E80CC; Tue, 15 Nov 2011 19:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.004 X-Spam-Level: X-Spam-Status: No, score=-4.004 tagged_above=-999 required=5 tests=[AWL=-2.208, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rENoKzWDZ2q; Tue, 15 Nov 2011 19:27:47 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6338211E8081; Tue, 15 Nov 2011 19:27:47 -0800 (PST) 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 <0LUQ003LZHMAGC@usaga02-in.huawei.com>; Tue, 15 Nov 2011 21:27:46 -0600 (CST) 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 <0LUQ00EF0HM9OQ@usaga02-in.huawei.com>; Tue, 15 Nov 2011 21:27:45 -0600 (CST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 15 Nov 2011 19:27:42 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Tue, 15 Nov 2011 19:27:01 -0800 Date: Wed, 16 Nov 2011 03:27:33 +0000 From: Linda Dunbar Subject: RE: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEA6@szxeml525-mbs.china.huawei.com> X-Originating-IP: [10.47.141.142] To: Xuxiaohu , Yakov Rekhter Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120C3940@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMpA7joFQ3R5rJREugHGM3mM6D1ZWu1wLA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEA6@szxeml525-mbs.china.huawei.com> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@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, 16 Nov 2011 03:27:48 -0000 WGlhb0h1LCANCg0KTUFDIGZvcndhcmRpbmcgdGFibGUgc2l6ZSBpc3N1ZXMgYXJlIGFkZHJlc3Nl ZCBieSBJRUVFODAyLjEuIFRoZXJlIGFyZSBzZXZlcmFsIHByb3Bvc2FscyB0aGVyZSB0YXJnZXRp bmcgYXQgdGhlIGlzc3Vlcy4gDQoNCkxpbmRhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogWHV4aWFvaHUNCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAx MSAxMToyMiBBTQ0KPiBUbzogTGluZGEgRHVuYmFyOyBZYWtvdiBSZWtodGVyDQo+IENjOiBsMnZw bkBpZXRmLm9yZzsgc2RucEBsdWNpZHZpc2lvbi5jb207IEwzVlBOIFdHIG1haWxpbmcgbGlzdDsN Cj4gYXJtZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiByZTogTmVlZCB5b3VyIGFjdGlvbiB0byByZXZp ZXcgZHJhZnQtaWV0Zi1hcm1kLXByb2JsZW0tDQo+IHN0YXRlbWVudC0wMC50eHQNCj4gDQo+IA0K PiBCeSB0aGUgd2F5LCBJIGFsc28gbm90aWNlZCB0aGF0IHRoZSBNQUMgZm9yd2FyZGluZyB0YWJs ZSBzY2FsYWJpbGl0eQ0KPiBpc3N1ZSBpcyBtZW50aW9uZWQgaW4gdGhlIEFSTUQgcHJvYmxlbSBz dGF0ZW1lbnQgZG9jLiBTaG91bGQgd2UgZXh0ZW5kDQo+IHRoZSBjaGFydGVyIHNjb3BlIG9mIEFS TUQgV0cgb3IgcmUtZm9ybSB0aGUgRENPUFMgV0cgdG8gZGlzY3VzcyBzbyBtYW55DQo+IGNoYWxs ZW5nZXMgYW5kIHJlcXVpcmVtZW50cyBpbiBkYXRhIGNlbnRlcnM/DQo+IA0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IFhpYW9odQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ILeivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbDJ2cG4tYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBMaW5kYQ0KPiBEdW5iYXIgW2xpbmRhLmR1bmJhckBodWF3ZWkuY29tXQ0KPiC3osvN yrG85DogMjAxMcTqMTHUwjE2yNUgMTA6MTYNCj4gtb06IFlha292IFJla2h0ZXINCj4gQ2M6IGwy dnBuQGlldGYub3JnOyBzZG5wQGx1Y2lkdmlzaW9uLmNvbTsgTDNWUE4gV0cgbWFpbGluZyBsaXN0 Ow0KPiBhcm1kQGlldGYub3JnDQo+INb3zOI6IFJFOiBOZWVkIHlvdXIgYWN0aW9uIHRvIHJldmll dyAgICAgIGRyYWZ0LWlldGYtYXJtZC1wcm9ibGVtLQ0KPiBzdGF0ZW1lbnQtMDAudHh0DQo+IA0K PiBZYWtvdiwNCj4gDQo+IFlvdSBhcmUgYWJzb2x1dGVseSByaWdodC4gV2Ugd2lsbCBtYWtlIHN1 cmUgaXQgaXMgcHJvcGVybHkgY2FwdHVyZWQgaW4NCj4gdGhlIGRvY3VtZW50Lg0KPiANCj4gVGhh bmtzLCBMaW5kYQ0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPg0K PiA+IFNob3VsZCB0aGUgb3ZlcmhlYWQgZHVlIHRvIHRoZSBicm9hZGNhc3QgdW5rbm93biBiZSBj b25zaWRlcmVkIGFzIHlldA0KPiA+IGFub3RoZXIgInBhaW4gcG9pbnQiIGFzc29jaWF0ZWQgd2l0 aCBsYXJnZSBMMiBkb21haW5zID8NCj4gPg0KPiA+IFlha292Lg0KPiA+DQo= From xuxiaohu@huawei.com Tue Nov 15 19:37: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 51CCB1F0C4B; Tue, 15 Nov 2011 19:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67kbrdVb19nv; Tue, 15 Nov 2011 19:37:43 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 94A441F0C42; Tue, 15 Nov 2011 19:37:43 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00DKRHZL47@szxga03-in.huawei.com>; Wed, 16 Nov 2011 11:35:45 +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 <0LUQ00M83HZKX6@szxga03-in.huawei.com>; Wed, 16 Nov 2011 11:35:44 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB72050; Wed, 16 Nov 2011 11:35:44 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 11:35:39 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 11:35:38 +0800 Date: Wed, 16 Nov 2011 03:35:37 +0000 From: Xuxiaohu Subject: re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F6120C3940@dfweml506-mbx> X-Originating-IP: [172.24.2.41] To: Linda Dunbar , Yakov Rekhter Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEE9@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMpAfDSj1Fik0WlEub2ME5FLnYWJWu1HW5//98uoCAAIfTMw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEA6@szxeml525-mbs.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F6120C3940@dfweml506-mbx> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@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, 16 Nov 2011 03:37:44 -0000 DQpTbywgZGlkIHlvdSBtZWFuIHRoZSBkZXNjcmlwdGlvbiB0ZXh0IGZvciB0aGUgTUFDIHRhYmxl IHNjYWxhYmlsaXR5IGlzc3VlIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIEFSTUQgcHJvYmxl bSBzdGF0ZW1lbnQgZG9jPw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogTGluZGEgRHVuYmFyDQq3osvNyrG8 5DogMjAxMcTqMTHUwjE2yNUgMTE6MjcNCrW9OiBYdXhpYW9odTsgWWFrb3YgUmVraHRlcg0KQ2M6 IGwydnBuQGlldGYub3JnOyBzZG5wQGx1Y2lkdmlzaW9uLmNvbTsgTDNWUE4gV0cgbWFpbGluZyBs aXN0OyBhcm1kQGlldGYub3JnDQrW98ziOiBSRTogTmVlZCB5b3VyIGFjdGlvbiB0byByZXZpZXcg ICAgICBkcmFmdC1pZXRmLWFybWQtcHJvYmxlbS1zdGF0ZW1lbnQtMDAudHh0DQoNClhpYW9IdSwN Cg0KTUFDIGZvcndhcmRpbmcgdGFibGUgc2l6ZSBpc3N1ZXMgYXJlIGFkZHJlc3NlZCBieSBJRUVF ODAyLjEuIFRoZXJlIGFyZSBzZXZlcmFsIHByb3Bvc2FscyB0aGVyZSB0YXJnZXRpbmcgYXQgdGhl IGlzc3Vlcy4NCg0KTGluZGENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBYdXhpYW9odQ0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE2LCAyMDExIDExOjIyIEFN DQo+IFRvOiBMaW5kYSBEdW5iYXI7IFlha292IFJla2h0ZXINCj4gQ2M6IGwydnBuQGlldGYub3Jn OyBzZG5wQGx1Y2lkdmlzaW9uLmNvbTsgTDNWUE4gV0cgbWFpbGluZyBsaXN0Ow0KPiBhcm1kQGll dGYub3JnDQo+IFN1YmplY3Q6IHJlOiBOZWVkIHlvdXIgYWN0aW9uIHRvIHJldmlldyBkcmFmdC1p ZXRmLWFybWQtcHJvYmxlbS0NCj4gc3RhdGVtZW50LTAwLnR4dA0KPg0KPg0KPiBCeSB0aGUgd2F5 LCBJIGFsc28gbm90aWNlZCB0aGF0IHRoZSBNQUMgZm9yd2FyZGluZyB0YWJsZSBzY2FsYWJpbGl0 eQ0KPiBpc3N1ZSBpcyBtZW50aW9uZWQgaW4gdGhlIEFSTUQgcHJvYmxlbSBzdGF0ZW1lbnQgZG9j LiBTaG91bGQgd2UgZXh0ZW5kDQo+IHRoZSBjaGFydGVyIHNjb3BlIG9mIEFSTUQgV0cgb3IgcmUt Zm9ybSB0aGUgRENPUFMgV0cgdG8gZGlzY3VzcyBzbyBtYW55DQo+IGNoYWxsZW5nZXMgYW5kIHJl cXVpcmVtZW50cyBpbiBkYXRhIGNlbnRlcnM/DQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1 DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gt6K8/sjLOiBs MnZwbi1ib3VuY2VzQGlldGYub3JnIFtsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExpbmRh DQo+IER1bmJhciBbbGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQo+ILeiy83KsbzkOiAyMDExxOox MdTCMTbI1SAxMDoxNg0KPiC1vTogWWFrb3YgUmVraHRlcg0KPiBDYzogbDJ2cG5AaWV0Zi5vcmc7 IHNkbnBAbHVjaWR2aXNpb24uY29tOyBMM1ZQTiBXRyBtYWlsaW5nIGxpc3Q7DQo+IGFybWRAaWV0 Zi5vcmcNCj4g1vfM4jogUkU6IE5lZWQgeW91ciBhY3Rpb24gdG8gcmV2aWV3ICAgICAgZHJhZnQt aWV0Zi1hcm1kLXByb2JsZW0tDQo+IHN0YXRlbWVudC0wMC50eHQNCj4NCj4gWWFrb3YsDQo+DQo+ IFlvdSBhcmUgYWJzb2x1dGVseSByaWdodC4gV2Ugd2lsbCBtYWtlIHN1cmUgaXQgaXMgcHJvcGVy bHkgY2FwdHVyZWQgaW4NCj4gdGhlIGRvY3VtZW50Lg0KPg0KPiBUaGFua3MsIExpbmRhDQo+DQo+ DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPg0KPiA+IFNob3VsZCB0aGUgb3Zl cmhlYWQgZHVlIHRvIHRoZSBicm9hZGNhc3QgdW5rbm93biBiZSBjb25zaWRlcmVkIGFzIHlldA0K PiA+IGFub3RoZXIgInBhaW4gcG9pbnQiIGFzc29jaWF0ZWQgd2l0aCBsYXJnZSBMMiBkb21haW5z ID8NCj4gPg0KPiA+IFlha292Lg0KPiA+DQo= From pedro.r.marques@gmail.com Tue Nov 15 21:33:09 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 1EEE01F0C9B for ; Tue, 15 Nov 2011 21:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=-1.221, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PS2O468kfZh for ; Tue, 15 Nov 2011 21:33:05 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D70FA1F0C6F for ; Tue, 15 Nov 2011 21:33:04 -0800 (PST) Received: by ggnr5 with SMTP id r5so3597055ggn.31 for ; Tue, 15 Nov 2011 21:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=z1T1hat1qcLZ4S3EIKxuaxoIk0k7drBgl69WYYjPW2M=; b=XXY8113UTL4jsnp6R5lll7WAkULHSA9g7szCabwNL8a5XSettitkxdlaxttR2iDjRn 3ZWkUNzWtnbevmLyHjLADmLHNohWLTV6S6eMEx4dLVkP0LhSc2hl12Xn6okVBAyqSlcE ES05LKG5N+R3M1b+L1myQQwKhhVUO9p0l43Mk= MIME-Version: 1.0 Received: by 10.50.180.193 with SMTP id dq1mr16372671igc.34.1321421584046; Tue, 15 Nov 2011 21:33:04 -0800 (PST) Received: by 10.231.12.2 with HTTP; Tue, 15 Nov 2011 21:33:03 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> Date: Tue, 15 Nov 2011 21:33:03 -0800 Message-ID: Subject: Re: Slides for L3VPN agenda @ IETF82 From: Pedro Marques To: Xuxiaohu Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org mailing list" 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, 16 Nov 2011 05:33:09 -0000 Xuxiaohu, 2011/11/15 Xuxiaohu : > Hi, > > I wonder whether the slides titled "VPN4DC slides" are the main slides fo= r discussion. > > Yes, no one doubts that "layer 3 (IP or MPLS) VPN connectivity is in IETF= routing area". However, it seems to me that it's still not clearly explain= ed in those slides why IP protocol extensions or new mechanism for current = solutions to DC is required. > > If I remembered correctly, it is said in the BoF launch email that there = are at least two questions which need to be answered before considering dev= eloping any new protocols. The first is whether the current L3VPN approach = can meet the requirement for DCN or DCI, and the second is wether the manag= ement tools are already enough to meet the requirement. There are two, largely independent, problems under which to evaluate these statements: A - l3vpn Interconnection between a service provider and a DC. B - network virtualization solution within a data-center. In terms of problem A, the current l3vpn approach is the set of inter-as solutions (option a, b, c). They seem to be at the very least the necessary starting point for any future development. In terms of problem B, it is unclear what one could consider to be the "current L3VPN approach". I would consider draft-l3vpn-end-system to be the current l3vpn approach applied to a slightly different environment. I'm not sure however if that view is generally shared... When discussing "management tools" it is also unclear what "the current approach" is. > I think these two question will help us to explore more deeply what the r= eal problems are. I believe that it would be useful to clearly distinguish between problems A and B above and add the question of "what is the current approach". > > Best regards, > Xiaohu > > ________________________________________ > =B7=A2=BC=FE=C8=CB: l3vpn-bounces@ietf.org [l3vpn-bounces@ietf.org] =B4= =FA=B1=ED Ben Niven-Jenkins [ben@niven-jenkins.co.uk] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C216=C8=D5 9:37 > =B5=BD: l3vpn@ietf.org mailing list > =D6=F7=CC=E2: Slides for L3VPN agenda @ IETF82 > > Colleagues, > > The slides that will be used in the L3VPN session this afternoon are now = available from the meeting material page, i.e. here: > > https://datatracker.ietf.org/meeting/82/materials.html > > Ben > > On 14 Nov 2011, at 11:50, Ben Niven-Jenkins wrote: > >> Colleagues, >> >> I have uploaded a new version of the L3VPN/VPN4DC agenda which includes = the names of the people who will lead each topic. You can find it here: >> >> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt >> >> The agenda is not arranged around specific drafts per-se but Marshall & = I have asked the person leading each topic to co-ordinate with the various = draft authors to produce a consolidated view/presentation which they will p= resent on behalf of the numerous authors/contributors. >> >> As a reminder: We have purposely not put time on the agenda to present/d= iscuss specific solution drafts as we would like the discussion to be focus= sed on the problem/requirements posed by VPN4DC and its applicability to IE= TF (including L3VPN). Discussion of specific solution proposals can happen = at future meetings if the VPN4DC work is adopted. >> >> Ben >> > > From xuxiaohu@huawei.com Tue Nov 15 21:58: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 872751F0D1A for ; Tue, 15 Nov 2011 21:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biRd3tUY-HvU for ; Tue, 15 Nov 2011 21:58:34 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id EDE341F0CF5 for ; Tue, 15 Nov 2011 21:58:33 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00037OJP45@szxga04-in.huawei.com> for l3vpn@ietf.org; Wed, 16 Nov 2011 13:57:25 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ005MJOJNZX@szxga04-in.huawei.com> for l3vpn@ietf.org; Wed, 16 Nov 2011 13:57:25 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA26139; Wed, 16 Nov 2011 13:57:07 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 13:57:01 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 13:56:57 +0800 Date: Wed, 16 Nov 2011 05:56:57 +0000 From: Xuxiaohu Subject: re: Slides for L3VPN agenda @ IETF82 In-reply-to: X-Originating-IP: [172.24.2.41] To: Pedro Marques Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFB8@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Slides for L3VPN agenda @ IETF82 Thread-index: AQHMpABi3hhbuKdOVE+mYh8wfPnXYpWuxW/B//+u34CAAIf9BA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> Cc: "l3vpn@ietf.org mailing list" 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, 16 Nov 2011 05:58:38 -0000 UGVkcm8sDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6 IFBlZHJvIE1hcnF1ZXMgW3BlZHJvLnIubWFycXVlc0BnbWFpbC5jb21dDQq3osvNyrG85DogMjAx McTqMTHUwjE2yNUgMTM6MzMNCrW9OiBYdXhpYW9odQ0KQ2M6IEJlbiBOaXZlbi1KZW5raW5zOyBs M3ZwbkBpZXRmLm9yZyBtYWlsaW5nIGxpc3QNCtb3zOI6IFJlOiBTbGlkZXMgZm9yIEwzVlBOIGFn ZW5kYSBAIElFVEY4Mg0KDQpYdXhpYW9odSwNCg0KMjAxMS8xMS8xNSBYdXhpYW9odSA8eHV4aWFv aHVAaHVhd2VpLmNvbT46DQo+IEhpLA0KPg0KPiBJIHdvbmRlciB3aGV0aGVyIHRoZSBzbGlkZXMg dGl0bGVkICJWUE40REMgc2xpZGVzIiBhcmUgdGhlIG1haW4gc2xpZGVzIGZvciBkaXNjdXNzaW9u Lg0KPg0KPiBZZXMsIG5vIG9uZSBkb3VidHMgdGhhdCAibGF5ZXIgMyAoSVAgb3IgTVBMUykgVlBO IGNvbm5lY3Rpdml0eSBpcyBpbiBJRVRGIHJvdXRpbmcgYXJlYSIuIEhvd2V2ZXIsIGl0IHNlZW1z IHRvIG1lIHRoYXQgaXQncyBzdGlsbCBub3QgY2xlYXJseSBleHBsYWluZWQgaW4gdGhvc2Ugc2xp ZGVzIHdoeSBJUCBwcm90b2NvbCBleHRlbnNpb25zIG9yIG5ldyBtZWNoYW5pc20gZm9yIGN1cnJl bnQgc29sdXRpb25zIHRvIERDIGlzIHJlcXVpcmVkLg0KPg0KPiBJZiBJIHJlbWVtYmVyZWQgY29y cmVjdGx5LCBpdCBpcyBzYWlkIGluIHRoZSBCb0YgbGF1bmNoIGVtYWlsIHRoYXQgdGhlcmUgYXJl IGF0IGxlYXN0IHR3byBxdWVzdGlvbnMgd2hpY2ggbmVlZCB0byBiZSBhbnN3ZXJlZCBiZWZvcmUg Y29uc2lkZXJpbmcgZGV2ZWxvcGluZyBhbnkgbmV3IHByb3RvY29scy4gVGhlIGZpcnN0IGlzIHdo ZXRoZXIgdGhlIGN1cnJlbnQgTDNWUE4gYXBwcm9hY2ggY2FuIG1lZXQgdGhlIHJlcXVpcmVtZW50 IGZvciBEQ04gb3IgRENJLCBhbmQgdGhlIHNlY29uZCBpcyB3ZXRoZXIgdGhlIG1hbmFnZW1lbnQg dG9vbHMgYXJlIGFscmVhZHkgZW5vdWdoIHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50Lg0KDQpUaGVy ZSBhcmUgdHdvLCBsYXJnZWx5IGluZGVwZW5kZW50LCBwcm9ibGVtcyB1bmRlciB3aGljaCB0byBl dmFsdWF0ZQ0KdGhlc2Ugc3RhdGVtZW50czoNCiAgQSAtIGwzdnBuIEludGVyY29ubmVjdGlvbiBi ZXR3ZWVuIGEgc2VydmljZSBwcm92aWRlciBhbmQgYSBEQy4NCiAgQiAtIG5ldHdvcmsgdmlydHVh bGl6YXRpb24gc29sdXRpb24gd2l0aGluIGEgZGF0YS1jZW50ZXIuDQoNCkluIHRlcm1zIG9mIHBy b2JsZW0gQSwgdGhlIGN1cnJlbnQgbDN2cG4gYXBwcm9hY2ggaXMgdGhlIHNldCBvZg0KaW50ZXIt YXMgc29sdXRpb25zIChvcHRpb24gYSwgYiwgYykuIFRoZXkgc2VlbSB0byBiZSBhdCB0aGUgdmVy eSBsZWFzdA0KdGhlIG5lY2Vzc2FyeSBzdGFydGluZyBwb2ludCBmb3IgYW55IGZ1dHVyZSBkZXZl bG9wbWVudC4NCg0KSW4gdGVybXMgb2YgcHJvYmxlbSBCLCBpdCBpcyB1bmNsZWFyIHdoYXQgb25l IGNvdWxkIGNvbnNpZGVyIHRvIGJlIHRoZQ0KImN1cnJlbnQgTDNWUE4gYXBwcm9hY2giLiBJIHdv dWxkIGNvbnNpZGVyIGRyYWZ0LWwzdnBuLWVuZC1zeXN0ZW0gdG8NCmJlIHRoZSBjdXJyZW50IGwz dnBuIGFwcHJvYWNoIGFwcGxpZWQgdG8gYSBzbGlnaHRseSBkaWZmZXJlbnQNCmVudmlyb25tZW50 LiBJJ20gbm90IHN1cmUgaG93ZXZlciBpZiB0aGF0IHZpZXcgaXMgZ2VuZXJhbGx5IHNoYXJlZC4u Lg0KDQo8WFhIPiBUaGFua3MgYSBsb3QgZm9yIHRoaXMgY2xhcmlmaWNhdGlvbi4gSWYgSSB1bmRl cnN0YW5kIHlvdXIgcG9pbnRzIGNvcnJlY3RseSwgdGhlIHByb2JsZW0gQSBpcyBvdXRzaWRlIG9m IHRoZSBWUE40REMgc2NvcGUgc2luY2UgaXQgZG9lc24ndCByZXF1aXJlIGFueSBmdXJ0aGVyIGRl dmVsb3BtZW50LiAgQXMgZm9yIHByb2JsZW0gQiB3aGljaCBzZWVtcyB0byBiZSB3aXRoaW4gdGhl IHNjb3BlLCB0aGUgVlBONERDIGlzIGludGVuZGVkIHRvIGZvY3VzIG9uIHRoZSBhcHByb2FjaCB0 aGF0IHRoZSBMM1ZQTiBQRSBmdW5jdGlvbnMgYXJlIHBlcmZvcm1lZCBvbiBob3N0cyAoZS5nLixk cmFmdC1sM3Zwbi1lbmQtc3lzdGVtKSwgcmF0aGVyIHRoYW4gb24gcm91dGVycy4gUGxlYXNlIGNv cnJlY3QgbWUgaWYgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZy4NCg0KQmVzdCByZWdhcmRzLA0K WGlhb2h1DQoNCldoZW4gZGlzY3Vzc2luZyAibWFuYWdlbWVudCB0b29scyIgaXQgaXMgYWxzbyB1 bmNsZWFyIHdoYXQgInRoZQ0KY3VycmVudCBhcHByb2FjaCIgaXMuDQoNCg0KPiBJIHRoaW5rIHRo ZXNlIHR3byBxdWVzdGlvbiB3aWxsIGhlbHAgdXMgdG8gZXhwbG9yZSBtb3JlIGRlZXBseSB3aGF0 IHRoZSByZWFsIHByb2JsZW1zIGFyZS4NCg0KSSBiZWxpZXZlIHRoYXQgaXQgd291bGQgYmUgdXNl ZnVsIHRvIGNsZWFybHkgZGlzdGluZ3Vpc2ggYmV0d2Vlbg0KcHJvYmxlbXMgQSBhbmQgQiBhYm92 ZSBhbmQgYWRkIHRoZSBxdWVzdGlvbiBvZiAid2hhdCBpcyB0aGUgY3VycmVudA0KYXBwcm9hY2gi Lg0KDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gt6K8/sjLOiBsM3Zwbi1ib3VuY2VzQGlldGYub3Jn IFtsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJlbiBOaXZlbi1KZW5raW5zIFtiZW5Abml2 ZW4tamVua2lucy5jby51a10NCj4gt6LLzcqxvOQ6IDIwMTHE6jEx1MIxNsjVIDk6MzcNCj4gtb06 IGwzdnBuQGlldGYub3JnIG1haWxpbmcgbGlzdA0KPiDW98ziOiBTbGlkZXMgZm9yIEwzVlBOIGFn ZW5kYSBAIElFVEY4Mg0KPg0KPiBDb2xsZWFndWVzLA0KPg0KPiBUaGUgc2xpZGVzIHRoYXQgd2ls bCBiZSB1c2VkIGluIHRoZSBMM1ZQTiBzZXNzaW9uIHRoaXMgYWZ0ZXJub29uIGFyZSBub3cgYXZh aWxhYmxlIGZyb20gdGhlIG1lZXRpbmcgbWF0ZXJpYWwgcGFnZSwgaS5lLiBoZXJlOg0KPg0KPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvODIvbWF0ZXJpYWxzLmh0bWwNCj4N Cj4gQmVuDQo+DQo+IE9uIDE0IE5vdiAyMDExLCBhdCAxMTo1MCwgQmVuIE5pdmVuLUplbmtpbnMg d3JvdGU6DQo+DQo+PiBDb2xsZWFndWVzLA0KPj4NCj4+IEkgaGF2ZSB1cGxvYWRlZCBhIG5ldyB2 ZXJzaW9uIG9mIHRoZSBMM1ZQTi9WUE40REMgYWdlbmRhIHdoaWNoIGluY2x1ZGVzIHRoZSBuYW1l cyBvZiB0aGUgcGVvcGxlIHdobyB3aWxsIGxlYWQgZWFjaCB0b3BpYy4gWW91IGNhbiBmaW5kIGl0 IGhlcmU6DQo+Pg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Mi9hZ2VuZGEv bDN2cG4udHh0DQo+Pg0KPj4gVGhlIGFnZW5kYSBpcyBub3QgYXJyYW5nZWQgYXJvdW5kIHNwZWNp ZmljIGRyYWZ0cyBwZXItc2UgYnV0IE1hcnNoYWxsICYgSSBoYXZlIGFza2VkIHRoZSBwZXJzb24g bGVhZGluZyBlYWNoIHRvcGljIHRvIGNvLW9yZGluYXRlIHdpdGggdGhlIHZhcmlvdXMgZHJhZnQg YXV0aG9ycyB0byBwcm9kdWNlIGEgY29uc29saWRhdGVkIHZpZXcvcHJlc2VudGF0aW9uIHdoaWNo IHRoZXkgd2lsbCBwcmVzZW50IG9uIGJlaGFsZiBvZiB0aGUgbnVtZXJvdXMgYXV0aG9ycy9jb250 cmlidXRvcnMuDQo+Pg0KPj4gQXMgYSByZW1pbmRlcjogV2UgaGF2ZSBwdXJwb3NlbHkgbm90IHB1 dCB0aW1lIG9uIHRoZSBhZ2VuZGEgdG8gcHJlc2VudC9kaXNjdXNzIHNwZWNpZmljIHNvbHV0aW9u IGRyYWZ0cyBhcyB3ZSB3b3VsZCBsaWtlIHRoZSBkaXNjdXNzaW9uIHRvIGJlIGZvY3Vzc2VkIG9u IHRoZSBwcm9ibGVtL3JlcXVpcmVtZW50cyBwb3NlZCBieSBWUE40REMgYW5kIGl0cyBhcHBsaWNh YmlsaXR5IHRvIElFVEYgKGluY2x1ZGluZyBMM1ZQTikuIERpc2N1c3Npb24gb2Ygc3BlY2lmaWMg c29sdXRpb24gcHJvcG9zYWxzIGNhbiBoYXBwZW4gYXQgZnV0dXJlIG1lZXRpbmdzIGlmIHRoZSBW UE40REMgd29yayBpcyBhZG9wdGVkLg0KPj4NCj4+IEJlbg0KPj4NCj4NCj4NCg== From robert@raszuk.net Tue Nov 15 22:05: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 33AA21F0D31 for ; Tue, 15 Nov 2011 22:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKxqrDm6RWCV for ; Tue, 15 Nov 2011 22:05:09 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 023811F0D2B for ; Tue, 15 Nov 2011 22:05:08 -0800 (PST) Received: (qmail 20207 invoked by uid 399); 16 Nov 2011 06:05:07 -0000 Received: from unknown (HELO ?130.129.19.9?) (130.129.19.9) by mail1310.opentransfer.com with ESMTP; 16 Nov 2011 06:05:07 -0000 X-Originating-IP: 130.129.19.9 Message-ID: <4EC35292.5090405@raszuk.net> Date: Wed, 16 Nov 2011 07:05:06 +0100 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: Xuxiaohu Subject: Re: Slides for L3VPN agenda @ IETF82 References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFB8@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFB8@szxeml525-mbs.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "l3vpn@ietf.org mailing list" 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: Wed, 16 Nov 2011 06:05:13 -0000 Xuxiaohu, While there are two problems at hand I really do not think this would be that difficult to address both with one solution as oppose to complicate even more and have two solutions. As a matter of fact I can easily see a scenario where A and B can coexist for a given customer. Rgs, R. > Pedro, > ________________________________________ > ·¢¼þÈË: Pedro Marques [pedro.r.marques@gmail.com] > ·¢ËÍʱ¼ä: 2011Äê11ÔÂ16ÈÕ 13:33 > µ½: Xuxiaohu > Cc: Ben Niven-Jenkins; l3vpn@ietf.org mailing list > Ö÷Ìâ: Re: Slides for L3VPN agenda @ IETF82 > > Xuxiaohu, > > 2011/11/15 Xuxiaohu: >> Hi, >> >> I wonder whether the slides titled "VPN4DC slides" are the main slides for discussion. >> >> Yes, no one doubts that "layer 3 (IP or MPLS) VPN connectivity is in IETF routing area". However, it seems to me that it's still not clearly explained in those slides why IP protocol extensions or new mechanism for current solutions to DC is required. >> >> If I remembered correctly, it is said in the BoF launch email that there are at least two questions which need to be answered before considering developing any new protocols. The first is whether the current L3VPN approach can meet the requirement for DCN or DCI, and the second is wether the management tools are already enough to meet the requirement. > > There are two, largely independent, problems under which to evaluate > these statements: > A - l3vpn Interconnection between a service provider and a DC. > B - network virtualization solution within a data-center. > > In terms of problem A, the current l3vpn approach is the set of > inter-as solutions (option a, b, c). They seem to be at the very least > the necessary starting point for any future development. > > In terms of problem B, it is unclear what one could consider to be the > "current L3VPN approach". I would consider draft-l3vpn-end-system to > be the current l3vpn approach applied to a slightly different > environment. I'm not sure however if that view is generally shared... > > Thanks a lot for this clarification. If I understand your points correctly, the problem A is outside of the VPN4DC scope since it doesn't require any further development. As for problem B which seems to be within the scope, the VPN4DC is intended to focus on the approach that the L3VPN PE functions are performed on hosts (e.g.,draft-l3vpn-end-system), rather than on routers. Please correct me if my understanding is wrong. > > Best regards, > Xiaohu > > When discussing "management tools" it is also unclear what "the > current approach" is. > > >> I think these two question will help us to explore more deeply what the real problems are. > > I believe that it would be useful to clearly distinguish between > problems A and B above and add the question of "what is the current > approach". > >> >> Best regards, >> Xiaohu >> >> ________________________________________ >> ·¢¼þÈË: l3vpn-bounces@ietf.org [l3vpn-bounces@ietf.org] ´ú±í Ben Niven-Jenkins [ben@niven-jenkins.co.uk] >> ·¢ËÍʱ¼ä: 2011Äê11ÔÂ16ÈÕ 9:37 >> µ½: l3vpn@ietf.org mailing list >> Ö÷Ìâ: Slides for L3VPN agenda @ IETF82 >> >> Colleagues, >> >> The slides that will be used in the L3VPN session this afternoon are now available from the meeting material page, i.e. here: >> >> https://datatracker.ietf.org/meeting/82/materials.html >> >> Ben >> >> On 14 Nov 2011, at 11:50, Ben Niven-Jenkins wrote: >> >>> Colleagues, >>> >>> I have uploaded a new version of the L3VPN/VPN4DC agenda which includes the names of the people who will lead each topic. You can find it here: >>> >>> http://www.ietf.org/proceedings/82/agenda/l3vpn.txt >>> >>> The agenda is not arranged around specific drafts per-se but Marshall& I have asked the person leading each topic to co-ordinate with the various draft authors to produce a consolidated view/presentation which they will present on behalf of the numerous authors/contributors. >>> >>> As a reminder: We have purposely not put time on the agenda to present/discuss specific solution drafts as we would like the discussion to be focussed on the problem/requirements posed by VPN4DC and its applicability to IETF (including L3VPN). Discussion of specific solution proposals can happen at future meetings if the VPN4DC work is adopted. >>> >>> Ben >>> >> >> From xuxiaohu@huawei.com Tue Nov 15 22:14: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 E986421F9198 for ; Tue, 15 Nov 2011 22:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUZyigG+wqDD for ; Tue, 15 Nov 2011 22:14:12 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 53CB221F9124 for ; Tue, 15 Nov 2011 22:14:09 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00KIQP9A01@szxga05-in.huawei.com> for l3vpn@ietf.org; Wed, 16 Nov 2011 14:12:47 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00BESP96FV@szxga05-in.huawei.com> for l3vpn@ietf.org; Wed, 16 Nov 2011 14:12:46 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB81787; Wed, 16 Nov 2011 14:12:45 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 14:12:38 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 14:12:37 +0800 Date: Wed, 16 Nov 2011 06:12:37 +0000 From: Xuxiaohu Subject: re: Slides for L3VPN agenda @ IETF82 In-reply-to: <4EC35292.5090405@raszuk.net> X-Originating-IP: [172.24.2.41] To: "robert@raszuk.net" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFFC@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Slides for L3VPN agenda @ IETF82 Thread-index: AQHMpABi3hhbuKdOVE+mYh8wfPnXYpWuxW/B//+u34CAAIf9BP//gPcAgACHLoY= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFB8@szxeml525-mbs.china.huawei.com> <4EC35292.5090405@raszuk.net> Cc: "l3vpn@ietf.org mailing list" 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, 16 Nov 2011 06:14:17 -0000 Um9iZXJ0LA0KDQpJdCdzIGFic29sdXRlbHkgT0sgdGhhdCBhIHNpbmdsZSBzb2x1dGlvbiBjb3Vs ZCBhZGRyZXNzIHR3byBwcm9ibGVtcy4gSSBqdXN0IHdhbnQgdG8gaWRlbnRpZnkgd2hpY2ggaXMg dGhlIHByb2JsZW0gdGhhdCBzdGlsbCBoYXMgbm8gY29ycmVzcG9uZGluZyBzb2x1dGlvbi4NCg0K QmVzdCByZWdhcmRzLA0KWGlhb2h1DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQq3orz+yMs6IFJvYmVydCBSYXN6dWsgW3JvYmVydEByYXN6dWsubmV0XQ0Kt6LLzcqx vOQ6IDIwMTHE6jEx1MIxNsjVIDE0OjA1DQq1vTogWHV4aWFvaHUNCkNjOiBQZWRybyBNYXJxdWVz OyBsM3ZwbkBpZXRmLm9yZyBtYWlsaW5nIGxpc3QNCtb3zOI6IFJlOiBTbGlkZXMgZm9yIEwzVlBO IGFnZW5kYSBAIElFVEY4Mg0KDQpYdXhpYW9odSwNCg0KV2hpbGUgdGhlcmUgYXJlIHR3byBwcm9i bGVtcyBhdCBoYW5kIEkgcmVhbGx5IGRvIG5vdCB0aGluayB0aGlzIHdvdWxkIGJlDQp0aGF0IGRp ZmZpY3VsdCB0byBhZGRyZXNzIGJvdGggd2l0aCBvbmUgc29sdXRpb24gYXMgb3Bwb3NlIHRvIGNv bXBsaWNhdGUNCmV2ZW4gbW9yZSBhbmQgaGF2ZSB0d28gc29sdXRpb25zLg0KDQpBcyBhIG1hdHRl ciBvZiBmYWN0IEkgY2FuIGVhc2lseSBzZWUgYSBzY2VuYXJpbyB3aGVyZSBBIGFuZCBCIGNhbg0K Y29leGlzdCBmb3IgYSBnaXZlbiBjdXN0b21lci4NCg0KUmdzLA0KUi4NCg0KDQo+IFBlZHJvLA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILeivP7IyzogUGVk cm8gTWFycXVlcyBbcGVkcm8uci5tYXJxdWVzQGdtYWlsLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTHE 6jEx1MIxNsjVIDEzOjMzDQo+ILW9OiBYdXhpYW9odQ0KPiBDYzogQmVuIE5pdmVuLUplbmtpbnM7 IGwzdnBuQGlldGYub3JnIG1haWxpbmcgbGlzdA0KPiDW98ziOiBSZTogU2xpZGVzIGZvciBMM1ZQ TiBhZ2VuZGEgQCBJRVRGODINCj4NCj4gWHV4aWFvaHUsDQo+DQo+IDIwMTEvMTEvMTUgWHV4aWFv aHU8eHV4aWFvaHVAaHVhd2VpLmNvbT46DQo+PiBIaSwNCj4+DQo+PiBJIHdvbmRlciB3aGV0aGVy IHRoZSBzbGlkZXMgdGl0bGVkICJWUE40REMgc2xpZGVzIiBhcmUgdGhlIG1haW4gc2xpZGVzIGZv ciBkaXNjdXNzaW9uLg0KPj4NCj4+IFllcywgbm8gb25lIGRvdWJ0cyB0aGF0ICJsYXllciAzIChJ UCBvciBNUExTKSBWUE4gY29ubmVjdGl2aXR5IGlzIGluIElFVEYgcm91dGluZyBhcmVhIi4gSG93 ZXZlciwgaXQgc2VlbXMgdG8gbWUgdGhhdCBpdCdzIHN0aWxsIG5vdCBjbGVhcmx5IGV4cGxhaW5l ZCBpbiB0aG9zZSBzbGlkZXMgd2h5IElQIHByb3RvY29sIGV4dGVuc2lvbnMgb3IgbmV3IG1lY2hh bmlzbSBmb3IgY3VycmVudCBzb2x1dGlvbnMgdG8gREMgaXMgcmVxdWlyZWQuDQo+Pg0KPj4gSWYg SSByZW1lbWJlcmVkIGNvcnJlY3RseSwgaXQgaXMgc2FpZCBpbiB0aGUgQm9GIGxhdW5jaCBlbWFp bCB0aGF0IHRoZXJlIGFyZSBhdCBsZWFzdCB0d28gcXVlc3Rpb25zIHdoaWNoIG5lZWQgdG8gYmUg YW5zd2VyZWQgYmVmb3JlIGNvbnNpZGVyaW5nIGRldmVsb3BpbmcgYW55IG5ldyBwcm90b2NvbHMu IFRoZSBmaXJzdCBpcyB3aGV0aGVyIHRoZSBjdXJyZW50IEwzVlBOIGFwcHJvYWNoIGNhbiBtZWV0 IHRoZSByZXF1aXJlbWVudCBmb3IgRENOIG9yIERDSSwgYW5kIHRoZSBzZWNvbmQgaXMgd2V0aGVy IHRoZSBtYW5hZ2VtZW50IHRvb2xzIGFyZSBhbHJlYWR5IGVub3VnaCB0byBtZWV0IHRoZSByZXF1 aXJlbWVudC4NCj4NCj4gVGhlcmUgYXJlIHR3bywgbGFyZ2VseSBpbmRlcGVuZGVudCwgcHJvYmxl bXMgdW5kZXIgd2hpY2ggdG8gZXZhbHVhdGUNCj4gdGhlc2Ugc3RhdGVtZW50czoNCj4gICAgQSAt IGwzdnBuIEludGVyY29ubmVjdGlvbiBiZXR3ZWVuIGEgc2VydmljZSBwcm92aWRlciBhbmQgYSBE Qy4NCj4gICAgQiAtIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gc29sdXRpb24gd2l0aGluIGEgZGF0 YS1jZW50ZXIuDQo+DQo+IEluIHRlcm1zIG9mIHByb2JsZW0gQSwgdGhlIGN1cnJlbnQgbDN2cG4g YXBwcm9hY2ggaXMgdGhlIHNldCBvZg0KPiBpbnRlci1hcyBzb2x1dGlvbnMgKG9wdGlvbiBhLCBi LCBjKS4gVGhleSBzZWVtIHRvIGJlIGF0IHRoZSB2ZXJ5IGxlYXN0DQo+IHRoZSBuZWNlc3Nhcnkg c3RhcnRpbmcgcG9pbnQgZm9yIGFueSBmdXR1cmUgZGV2ZWxvcG1lbnQuDQo+DQo+IEluIHRlcm1z IG9mIHByb2JsZW0gQiwgaXQgaXMgdW5jbGVhciB3aGF0IG9uZSBjb3VsZCBjb25zaWRlciB0byBi ZSB0aGUNCj4gImN1cnJlbnQgTDNWUE4gYXBwcm9hY2giLiBJIHdvdWxkIGNvbnNpZGVyIGRyYWZ0 LWwzdnBuLWVuZC1zeXN0ZW0gdG8NCj4gYmUgdGhlIGN1cnJlbnQgbDN2cG4gYXBwcm9hY2ggYXBw bGllZCB0byBhIHNsaWdodGx5IGRpZmZlcmVudA0KPiBlbnZpcm9ubWVudC4gSSdtIG5vdCBzdXJl IGhvd2V2ZXIgaWYgdGhhdCB2aWV3IGlzIGdlbmVyYWxseSBzaGFyZWQuLi4NCj4NCj4gPFhYSD4g IFRoYW5rcyBhIGxvdCBmb3IgdGhpcyBjbGFyaWZpY2F0aW9uLiBJZiBJIHVuZGVyc3RhbmQgeW91 ciBwb2ludHMgY29ycmVjdGx5LCB0aGUgcHJvYmxlbSBBIGlzIG91dHNpZGUgb2YgdGhlIFZQTjRE QyBzY29wZSBzaW5jZSBpdCBkb2Vzbid0IHJlcXVpcmUgYW55IGZ1cnRoZXIgZGV2ZWxvcG1lbnQu ICBBcyBmb3IgcHJvYmxlbSBCIHdoaWNoIHNlZW1zIHRvIGJlIHdpdGhpbiB0aGUgc2NvcGUsIHRo ZSBWUE40REMgaXMgaW50ZW5kZWQgdG8gZm9jdXMgb24gdGhlIGFwcHJvYWNoIHRoYXQgdGhlIEwz VlBOIFBFIGZ1bmN0aW9ucyBhcmUgcGVyZm9ybWVkIG9uIGhvc3RzIChlLmcuLGRyYWZ0LWwzdnBu LWVuZC1zeXN0ZW0pLCByYXRoZXIgdGhhbiBvbiByb3V0ZXJzLiBQbGVhc2UgY29ycmVjdCBtZSBp ZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9o dQ0KPg0KPiBXaGVuIGRpc2N1c3NpbmcgIm1hbmFnZW1lbnQgdG9vbHMiIGl0IGlzIGFsc28gdW5j bGVhciB3aGF0ICJ0aGUNCj4gY3VycmVudCBhcHByb2FjaCIgaXMuDQo+DQo+DQo+PiBJIHRoaW5r IHRoZXNlIHR3byBxdWVzdGlvbiB3aWxsIGhlbHAgdXMgdG8gZXhwbG9yZSBtb3JlIGRlZXBseSB3 aGF0IHRoZSByZWFsIHByb2JsZW1zIGFyZS4NCj4NCj4gSSBiZWxpZXZlIHRoYXQgaXQgd291bGQg YmUgdXNlZnVsIHRvIGNsZWFybHkgZGlzdGluZ3Vpc2ggYmV0d2Vlbg0KPiBwcm9ibGVtcyBBIGFu ZCBCIGFib3ZlIGFuZCBhZGQgdGhlIHF1ZXN0aW9uIG9mICJ3aGF0IGlzIHRoZSBjdXJyZW50DQo+ IGFwcHJvYWNoIi4NCj4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBYaWFvaHUNCj4+DQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiC3orz+yMs6IGwzdnBu LWJvdW5jZXNAaWV0Zi5vcmcgW2wzdnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQmVuIE5pdmVu LUplbmtpbnMgW2JlbkBuaXZlbi1qZW5raW5zLmNvLnVrXQ0KPj4gt6LLzcqxvOQ6IDIwMTHE6jEx 1MIxNsjVIDk6MzcNCj4+ILW9OiBsM3ZwbkBpZXRmLm9yZyBtYWlsaW5nIGxpc3QNCj4+INb3zOI6 IFNsaWRlcyBmb3IgTDNWUE4gYWdlbmRhIEAgSUVURjgyDQo+Pg0KPj4gQ29sbGVhZ3VlcywNCj4+ DQo+PiBUaGUgc2xpZGVzIHRoYXQgd2lsbCBiZSB1c2VkIGluIHRoZSBMM1ZQTiBzZXNzaW9uIHRo aXMgYWZ0ZXJub29uIGFyZSBub3cgYXZhaWxhYmxlIGZyb20gdGhlIG1lZXRpbmcgbWF0ZXJpYWwg cGFnZSwgaS5lLiBoZXJlOg0KPj4NCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVl dGluZy84Mi9tYXRlcmlhbHMuaHRtbA0KPj4NCj4+IEJlbg0KPj4NCj4+IE9uIDE0IE5vdiAyMDEx LCBhdCAxMTo1MCwgQmVuIE5pdmVuLUplbmtpbnMgd3JvdGU6DQo+Pg0KPj4+IENvbGxlYWd1ZXMs DQo+Pj4NCj4+PiBJIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgTDNWUE4vVlBO NERDIGFnZW5kYSB3aGljaCBpbmNsdWRlcyB0aGUgbmFtZXMgb2YgdGhlIHBlb3BsZSB3aG8gd2ls bCBsZWFkIGVhY2ggdG9waWMuIFlvdSBjYW4gZmluZCBpdCBoZXJlOg0KPj4+DQo+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Mi9hZ2VuZGEvbDN2cG4udHh0DQo+Pj4NCj4+PiBU aGUgYWdlbmRhIGlzIG5vdCBhcnJhbmdlZCBhcm91bmQgc3BlY2lmaWMgZHJhZnRzIHBlci1zZSBi dXQgTWFyc2hhbGwmICBJIGhhdmUgYXNrZWQgdGhlIHBlcnNvbiBsZWFkaW5nIGVhY2ggdG9waWMg dG8gY28tb3JkaW5hdGUgd2l0aCB0aGUgdmFyaW91cyBkcmFmdCBhdXRob3JzIHRvIHByb2R1Y2Ug YSBjb25zb2xpZGF0ZWQgdmlldy9wcmVzZW50YXRpb24gd2hpY2ggdGhleSB3aWxsIHByZXNlbnQg b24gYmVoYWxmIG9mIHRoZSBudW1lcm91cyBhdXRob3JzL2NvbnRyaWJ1dG9ycy4NCj4+Pg0KPj4+ IEFzIGEgcmVtaW5kZXI6IFdlIGhhdmUgcHVycG9zZWx5IG5vdCBwdXQgdGltZSBvbiB0aGUgYWdl bmRhIHRvIHByZXNlbnQvZGlzY3VzcyBzcGVjaWZpYyBzb2x1dGlvbiBkcmFmdHMgYXMgd2Ugd291 bGQgbGlrZSB0aGUgZGlzY3Vzc2lvbiB0byBiZSBmb2N1c3NlZCBvbiB0aGUgcHJvYmxlbS9yZXF1 aXJlbWVudHMgcG9zZWQgYnkgVlBONERDIGFuZCBpdHMgYXBwbGljYWJpbGl0eSB0byBJRVRGIChp bmNsdWRpbmcgTDNWUE4pLiBEaXNjdXNzaW9uIG9mIHNwZWNpZmljIHNvbHV0aW9uIHByb3Bvc2Fs cyBjYW4gaGFwcGVuIGF0IGZ1dHVyZSBtZWV0aW5ncyBpZiB0aGUgVlBONERDIHdvcmsgaXMgYWRv cHRlZC4NCj4+Pg0KPj4+IEJlbg0KPj4+DQo+Pg0KPj4NCg0K From yhkang@etri.re.kr Wed Nov 16 02:38: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 5D8D221F94F9 for ; Wed, 16 Nov 2011 02:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.907 X-Spam-Level: X-Spam-Status: No, score=-88.907 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, 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 WUFZX3Do-yrH for ; Wed, 16 Nov 2011 02:38:02 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA9B21F949E for ; Wed, 16 Nov 2011 02:37:53 -0800 (PST) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Wed, 16 Nov 2011 19:37:51 +0900 priority: normal thread-index: AcykS8qYWi83XvO+S/+wgTiDHGAiNg== Thread-Topic: Slides for L3VPN agenda @ IETF82 From: =?ks_c_5601-1987?B?sK3Ar8it?= To: "Ben Niven-Jenkins" , Subject: RE: Slides for L3VPN agenda @ IETF82 Date: Wed, 16 Nov 2011 19:37:51 +0900 Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCC/yLTPx8O3zr/svcO9ug==?= =?ks_c_5601-1987?B?xdu/rLG4xsAsILTjtOc=?= Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_D57E_01CCA497.3A82A840" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 X-OriginalArrivalTime: 16 Nov 2011 10:37:51.0759 (UTC) FILETIME=[CAB9F9F0:01CCA44B] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?ks_c_5601-1987?B?sK3Ar8it?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 10:38:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_D57E_01CCA497.3A82A840 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ------=_NextPart_000_D57E_01CCA497.3A82A840 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PERJViBzdHlsZT0iRk9OVC1GQU1JTFk6ILG8uLI7IEZPTlQtU0laRTogMTBwdCIgaWQ9bXNnYm9k eT4NCjxESVY+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhhbmsgeW91IGZv ciBMM1ZQTiBzbGlkZXMgYW5kIGhhcHB5IHRvIGF0dGVuZCB0b2RheSdzJm5ic3A7c2Vzc2lvbi48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+SSBhbSB2ZXJ5IGludGVyZXNldGVkIGluIGlzc3VlcyBvZiBWUE40REMgYW5kIEkgdGhpbmsg dGhhdCBMM1ZQTiBjYW4gYmUgYSBrZXkgc29sdXRpb24gdG8gY29ubmVjdCBiZXR3ZWVuIEVudGVy cHJpc2UgYW5kIERDLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+QWxzbywgSSdtIHBsYW5uaW5nIGEmbmJzcDs8L0ZPTlQ+PEZPTlQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+bmV3IHByb2plY3QgaW4mbmJzcDtteSZuYnNwO2NvbXBh bnkmbmJzcDt0byZuYnNwO2RldmVsb3AmbmJzcDtMM1ZQTiBzb2x1dGlvbiBiZXR3ZWVuJm5ic3A7 dGhlbS4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPkhvcGUgdGhlIHByb2dyZXNzIG9mIHRoaXMgaXNzdWVzLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEJSPjwvRk9OVD4NCjxE SVYgc3R5bGU9IkZPTlQtRkFNSUxZOiCxvLiyOyBXT1JELUJSRUFLOiBicmVhay1hbGwiPg0KPERJ Vj4NCjxESVYgc3R5bGU9IkZPTlQtRkFNSUxZOiCxvLiyOyBXT1JELUJSRUFLOiBicmVhay1hbGwi Pg0KPERJVj4NCjxESVYgc3R5bGU9IkZPTlQtRkFNSUxZOiCxvLiyOyBXT1JELUJSRUFLOiBicmVh ay1hbGwiPg0KPERJVj48U1BBTiBzdHlsZT0iQ09MT1I6ICMzOTM5MzkiIGxhbmc9RU4tVVM+PEZP TlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8RElWIHN0eWxlPSJGT05ULUZBTUlM WTogsby4sjsgV09SRC1CUkVBSzogYnJlYWstYWxsIj4NCjxESVY+DQo8RElWIHN0eWxlPSJGT05U LUZBTUlMWTogsby4sjsgV09SRC1CUkVBSzogYnJlYWstYWxsIj4NCjxESVY+DQo8RElWIHN0eWxl PSJGT05ULUZBTUlMWTogsby4sjsgV09SRC1CUkVBSzogYnJlYWstYWxsIj4NCjxESVY+DQo8UCBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1 dG8iIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0iQ09MT1I6ICMzOTM5MzkiIGxhbmc9RU4t VVM+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+WW9vaHdhIEthbmc8L0ZPTlQ+ PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJn aW4tYm90dG9tLWFsdDogYXV0byIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJDT0xPUjog IzM5MzkzOSIgbGFuZz1FTi1VUz48Rk9OVCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 QlI+PC9GT05UPjwvU1BBTj48U1BBTiBzdHlsZT0iQ09MT1I6ICMzOTM5MzkiIGxhbmc9RU4tVVM+ PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+TmV0d29yayBjb252ZXJnZW5jZSBy ZXNlYXJjaCBkZXBhcnRtZW50LCBFVFJJKDwvRk9OVD48QSBocmVmPSJodHRwOi8vd3d3LmV0cmku cmUua3IvIiB0YXJnZXQ9X2JsYW5rPjxTUEFOIHN0eWxlPSJDT0xPUjogIzM5MzkzOTsgVEVYVC1E RUNPUkFUSU9OOiBub25lIj48Rk9OVCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj53d3cu ZXRyaS5yZS5rcjwvRk9OVD48L1NQQU4+PC9BPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPik8QlI+RS1tYWlsOiA8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOnloa2FuZ0BldHJpLnJl LmtyIiB0YXJnZXQ9X2JsYW5rPjxTUEFOIHN0eWxlPSJDT0xPUjogIzM5MzkzOTsgVEVYVC1ERUNP UkFUSU9OOiBub25lIj48Rk9OVCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj55aGthbmdA ZXRyaS5yZS5rcjwvRk9OVD48L1NQQU4+PC9BPjw/eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5z ID0gInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgLz48bzpwPjwvbzpw PjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+DQo8UCBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8i IGNsYXNzPU1zb05vcm1hbD48QlI+PC9GT05UPjwvU1BBTj4tLS0tLb/4ursguN69w8H2LS0tLS08 QlI+PEI+RnJvbTo8L0I+ICJCZW4gTml2ZW4tSmVua2lucyIgJmx0O2JlbkBuaXZlbi1qZW5raW5z LmNvLnVrJmd0OzxCUj48Qj5Gcm9tIERhdGU6PC9CPiAyMDExLTExLTE2IL/AwPwgMTA6Mzc6NDM8 QlI+PEI+VG86PC9CPiAibDN2cG5AaWV0Zi5vcmcgbWFpbGluZyBsaXN0IiAmbHQ7bDN2cG5AaWV0 Zi5vcmcmZ3Q7PEJSPjxCPkNjOjwvQj4gPEJSPjxCPlN1YmplY3Q6PC9CPiBTbGlkZXMgZm9yIEwz VlBOIGFnZW5kYSBAIElFVEY4MjxCUj48QlI+PC9QPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwv RElWPjwvRElWPg0KPERJVj48IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0t PjxCUj4NCjxQPjxGT05UIHNpemU9Mj5Db2xsZWFndWVzLDxCUj48QlI+VGhlIHNsaWRlcyB0aGF0 IHdpbGwgYmUgdXNlZCBpbiB0aGUgTDNWUE4gc2Vzc2lvbiB0aGlzIGFmdGVybm9vbiBhcmUgbm93 IGF2YWlsYWJsZSBmcm9tIHRoZSBtZWV0aW5nIG1hdGVyaWFsIHBhZ2UsIGkuZS4gaGVyZTo8QlI+ PEJSPjxBIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy84Mi9tYXRl cmlhbHMuaHRtbCIgdGFyZ2V0PV9ibGFuaz5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvODIvbWF0ZXJpYWxzLmh0bWw8L0E+PEJSPjxCUj5CZW48QlI+PEJSPk9uIDE0IE5vdiAy MDExLCBhdCAxMTo1MCwgQmVuIE5pdmVuLUplbmtpbnMgd3JvdGU6PEJSPjxCUj4mZ3Q7IENvbGxl YWd1ZXMsPEJSPiZndDs8QlI+Jmd0OyBJIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0 aGUgTDNWUE4vVlBONERDIGFnZW5kYSB3aGljaCBpbmNsdWRlcyB0aGUgbmFtZXMgb2YgdGhlIHBl b3BsZSB3aG8gd2lsbCBsZWFkIGVhY2ggdG9waWMuIFlvdSBjYW4gZmluZCBpdCBoZXJlOjxCUj4m Z3Q7PEJSPiZndDsgPEEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Mi9h Z2VuZGEvbDN2cG4udHh0IiB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvODIvYWdlbmRhL2wzdnBuLnR4dDwvQT48QlI+Jmd0OzxCUj4mZ3Q7IFRoZSBhZ2VuZGEg aXMgbm90IGFycmFuZ2VkIGFyb3VuZCBzcGVjaWZpYyBkcmFmdHMgcGVyLXNlIGJ1dCBNYXJzaGFs bCAmYW1wOyBJIGhhdmUgYXNrZWQgdGhlIHBlcnNvbiBsZWFkaW5nIGVhY2ggdG9waWMgdG8gY28t b3JkaW5hdGUgd2l0aCB0aGUgdmFyaW91cyBkcmFmdCBhdXRob3JzIHRvIHByb2R1Y2UgYSBjb25z b2xpZGF0ZWQgdmlldy9wcmVzZW50YXRpb24gd2hpY2ggdGhleSB3aWxsIHByZXNlbnQgb24gYmVo YWxmIG9mIHRoZSBudW1lcm91cyBhdXRob3JzL2NvbnRyaWJ1dG9ycy48QlI+Jmd0OzxCUj4mZ3Q7 IEFzIGEgcmVtaW5kZXI6IFdlIGhhdmUgcHVycG9zZWx5IG5vdCBwdXQgdGltZSBvbiB0aGUgYWdl bmRhIHRvIHByZXNlbnQvZGlzY3VzcyBzcGVjaWZpYyBzb2x1dGlvbiBkcmFmdHMgYXMgd2Ugd291 bGQgbGlrZSB0aGUgZGlzY3Vzc2lvbiB0byBiZSBmb2N1c3NlZCBvbiB0aGUgcHJvYmxlbS9yZXF1 aXJlbWVudHMgcG9zZWQgYnkgVlBONERDIGFuZCBpdHMgYXBwbGljYWJpbGl0eSB0byBJRVRGIChp bmNsdWRpbmcgTDNWUE4pLiBEaXNjdXNzaW9uIG9mIHNwZWNpZmljIHNvbHV0aW9uIHByb3Bvc2Fs cyBjYW4gaGFwcGVuIGF0IGZ1dHVyZSBtZWV0aW5ncyBpZiB0aGUgVlBONERDIHdvcmsgaXMgYWRv cHRlZC48QlI+Jmd0OzxCUj4mZ3Q7IEJlbjxCUj4mZ3Q7PEJSPjxCUj48L0ZPTlQ+PC9QPjwvRElW PjwvRElWPjwvRElWPg== ------=_NextPart_000_D57E_01CCA497.3A82A840-- From DanielC@orckit.com Wed Nov 16 02:40: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 2DC5321F95CF for ; Wed, 16 Nov 2011 02:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVs8caXP7LS7 for ; Wed, 16 Nov 2011 02:40:12 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2050721F94D4 for ; Wed, 16 Nov 2011 02:40:11 -0800 (PST) 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: Last Call: (OSPFv3 as a PE-CErouting protocol) to Proposed Standard Date: Wed, 16 Nov 2011 12:38:37 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA081307304A3D@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (OSPFv3 as a PE-CErouting protocol) to Proposed Standard Thread-Index: AcyhlS+NCBpzPBJ6Tkei7ECg9CiK4wAoehAgAAArE5AAhOf9EA== References: <20111112234223.20827.13913.idtracker@ietfa.amsl.com> From: "Daniel Cohn" To: 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, 16 Nov 2011 10:40:16 -0000 Hi, (Belated) question to the authors: Doesn't the following statement in the draft: "However, since a PE interface can be associated with only one VRF, all OSPFv3 instances running on the same interface MUST be associated with the same VRF." contradict the following statement in RFC 4364, section 3.2? " In some cases, a particular site may be divided by the customer into several "virtual sites"... Another way to accomplish this is to use IP source addresses. In this case, the PE uses the IP source address in a packet received from the CE, along with the interface over which the packet is received, to assign the packet to a particular VRF" In other words, RFC 4364 allows assigning a single PE interface to several VRFs. So shouldn't the statement in the draft at least be qualified? Regards, Daniel -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of The IESG Sent: Sunday, November 13, 2011 1:42 AM To: IETF-Announce Cc: l3vpn@ietf.org Subject: Last Call: (OSPFv3 as a PE-CErouting protocol) to Proposed Standard The IESG has received a request from the Layer 3 Virtual Private Networks WG (l3vpn) to consider the following document: - 'OSPFv3 as a PE-CE routing protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ No IPR declarations have been submitted directly on this I-D. From acee.lindem@ericsson.com Wed Nov 16 06:58: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 324CF21F95FE for ; Wed, 16 Nov 2011 06:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEAs8jPA0RmN for ; Wed, 16 Nov 2011 06:58:51 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6E05921F95F0 for ; Wed, 16 Nov 2011 06:58:51 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAGEwk1M003478; Wed, 16 Nov 2011 08:58:49 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.218]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 16 Nov 2011 09:58:43 -0500 From: Acee Lindem To: Daniel Cohn Date: Wed, 16 Nov 2011 09:58:40 -0500 Subject: Re: Last Call: (OSPFv3 as a PE-CErouting protocol) to Proposed Standard Thread-Topic: Last Call: (OSPFv3 as a PE-CErouting protocol) to Proposed Standard Thread-Index: AcykcDtYMzLRX1W1RzW7w6Ku/VaR2A== Message-ID: <28D36026-7B5E-4ECB-8394-9679B9A66AE4@ericsson.com> References: <20111112234223.20827.13913.idtracker@ietfa.amsl.com> <44F4E579A764584EA9BDFD07D0CA081307304A3D@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081307304A3D@tlvmail1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-84--449062673"; protocol="application/pkcs7-signature"; micalg=sha1 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: Wed, 16 Nov 2011 14:58:56 -0000 --Apple-Mail-84--449062673 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Daniel, I'm not an author but I'll comment.=20 On Nov 16, 2011, at 5:38 AM, Daniel Cohn wrote: > Hi, >=20 > (Belated) question to the authors: >=20 > Doesn't the following statement in the draft: >=20 > "However, since a PE interface can be associated with only one VRF, = all > OSPFv3 instances running on the same interface MUST be associated with > the same VRF." >=20 > contradict the following statement in RFC 4364, section 3.2? >=20 > " In some cases, a particular site may be divided by the customer into > several "virtual sites"... Another way to accomplish this is to use IP > source addresses. In this case, the PE uses the IP source address in = a > packet received from the CE, along with the interface over which the > packet is received, to assign the packet to a particular VRF" To the best of my knowledge, nobody has implemented the ability to put = different subnets on the same interface in different VRFs. The way this = problem is typically solved is with some layer 2 encapsulation, e.g., = different VLANs in different VRFs.=20 To complicate things, OSPFv3 runs on a link as opposed to a subnet. = Hence the demuxing described in RFC 4364 would not work. Conceivably, = one could use the OSPFv3 interface instance ID for this demuxing but I = don't think it makes any sense to try and solve this problem when no one = is putting a single interface in multiple VRFs.=20 Thanks, Acee=20 >=20 > In other words, RFC 4364 allows assigning a single PE interface to > several VRFs. So shouldn't the statement in the draft at least be > qualified? >=20 > Regards, >=20 > Daniel >=20 > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of The IESG > Sent: Sunday, November 13, 2011 1:42 AM > To: IETF-Announce > Cc: l3vpn@ietf.org > Subject: Last Call: (OSPFv3 as a > PE-CErouting protocol) to Proposed Standard >=20 >=20 > The IESG has received a request from the Layer 3 Virtual Private > Networks WG (l3vpn) to consider the following document: > - 'OSPFv3 as a PE-CE routing protocol' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-12-04. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Many Service Providers (SPs) offer Virtual Private Network (VPN) > services to their customers using a technique in which Customer Edge > (CE) routers are routing peers of Provider Edge (PE) routers. The > Border Gateway Protocol (BGP) is used to distribute the customer's > routes across the provider's IP backbone network, and Multiprotocol > Label Switching (MPLS) is used to tunnel customer packets across the > provider's backbone. This is known as a "BGP/MPLS IP VPN". > Originally only IPv4 was supported and it was later extended to > support IPv6 VPNs as well. Extensions were later added for the > support of the Open Shortest Path First protocol version 2 (OSPFv2) > as a PE-CE routing protocol for the IPv4 VPNs. This document = extends > those specifications to support OSPF version 3 (OSPFv3) as a PE-CE > routing protocol. The OSPFv3 PE-CE functionality is identical to > that of OSPFv2 except for the differences described in this = document. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 --Apple-Mail-84--449062673 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTExNjE0NTg0MVowIwYJKoZI hvcNAQkEMRYEFCtfhnUSWY7Apht2RoUVPw7lPusCMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgIyHDqoo84drhfOG7TqoWdtyLVCW3cuoYjkVyj/EWS15OaXHqN6u9YW3N33AbmuR auYjQK+SrXEmKWKlw8kPpU2Fs1AZt51LvqGAK24zMfxPc+sp/hKE4uwgf/NeKS0hKy4yvXnCxgIG ZysqXdTnTC0zKEE9Ny+9jKtGdWGjfEbSAAAAAAAA --Apple-Mail-84--449062673-- From pedro.r.marques@gmail.com Wed Nov 16 08:55: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 49C7E11E80CF for ; Wed, 16 Nov 2011 08:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.057, 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 CEVZZsmz6Vpe for ; Wed, 16 Nov 2011 08:55:04 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 485A111E808F for ; Wed, 16 Nov 2011 08:55:04 -0800 (PST) Received: by yenq4 with SMTP id q4so6823464yen.31 for ; Wed, 16 Nov 2011 08:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wQFd7sfVLAC4YpraLPUWuP2a/7ujGh6zshquNICgt6s=; b=PUHyOYHotdOvRSAT3CHWLJu/gyK884fXkm3pZzhFkVbbv+sIWUGhenPB74Ai7haVAg 7LxDO8WbyL+i0OuBUPr5CyEZK+OYmFZlgmMTAvwTPfLVRs65aBHYqWQjs0APEy0M12Gr uvEzjs9bYTNuvgo2JrFlWOEPTYnM4icWNuRh0= MIME-Version: 1.0 Received: by 10.50.184.202 with SMTP id ew10mr33203146igc.48.1321462503446; Wed, 16 Nov 2011 08:55:03 -0800 (PST) Received: by 10.231.12.2 with HTTP; Wed, 16 Nov 2011 08:55:03 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFB8@szxeml525-mbs.china.huawei.com> References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFB8@szxeml525-mbs.china.huawei.com> Date: Wed, 16 Nov 2011 08:55:03 -0800 Message-ID: Subject: Re: Slides for L3VPN agenda @ IETF82 From: Pedro Marques To: Xuxiaohu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org mailing list" 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, 16 Nov 2011 16:55:05 -0000 Xuxiaohu, 2011/11/15 Xuxiaohu : > Pedro, > ________________________________________ > There are two, largely independent, problems under which to evaluate > these statements: > =A0A - l3vpn Interconnection between a service provider and a DC. > =A0B - network virtualization solution within a data-center. > > In terms of problem A, the current l3vpn approach is the set of > inter-as solutions (option a, b, c). They seem to be at the very least > the necessary starting point for any future development. > > In terms of problem B, it is unclear what one could consider to be the > "current L3VPN approach". I would consider draft-l3vpn-end-system to > be the current l3vpn approach applied to a slightly different > environment. I'm not sure however if that view is generally shared... > > Thanks a lot for this clarification. If I understand your points co= rrectly, the problem A is outside of the VPN4DC scope since it doesn't requ= ire any further development. That is a strong statement that i wouldn't want to make. It is quite possible that it may benefit from incremental improvements. But i believe that Ben's original question of what are the problems with the "current l3vpn approach" is quite pertinent in this case. > =A0As for problem B which seems to be within the scope, the VPN4DC is int= ended to focus on the approach that the L3VPN PE functions are performed on= hosts (e.g.,draft-l3vpn-end-system), rather than on routers. Please correc= t me if my understanding is wrong. The desire to perform the VPN forwarding function on end-systems doesn't come out of the vacuum. It comes from a combination of factors that where being discussed in a parallel thread: - cost / complexity of operating the DC "fabric" network. - The fact that it is undesirable to have an L2/L3 boundary anywhere within the DC. - Scaling requirements for the number of potential routes available to a single VM. - Need to be efficient in terms of traffic fowarding (packets should cross the fabric once). - Need to support multiple isolation domains. I'm not attempting to claim that this is the only way to address the problem; but it is, imho, a reasonable approach given the trade-offs in this space. I would expect several other alternatives to be presented. thank you, Pedro. From marshall.eubanks@gmail.com Wed Nov 16 14:40: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 B0AAE21F90A7 for ; Wed, 16 Nov 2011 14:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=-0.501, 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 HpvZPeVQQLfc for ; Wed, 16 Nov 2011 14:40:59 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA7521F90A6 for ; Wed, 16 Nov 2011 14:40:56 -0800 (PST) Received: by faap16 with SMTP id p16so2635607faa.31 for ; Wed, 16 Nov 2011 14:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=4dOU1YJ49ujwgBT+yJuV1pmJVS2PEmU5yNuEgsjp9/o=; b=stYIp9iEO8K/tFv4PO9yJ9CZyb0VMyGVwIhoGIqesaond2k00oKNGOiR7SOIh7lXsj GcAkuZP99dWNWW0oIcbrAg1Txosjsqz91udEXvfNR6BM83++Ws8GU+FeZHt0CMnPWbr/ eTxOwrW/3sGwCQZW3a5EII1YI74B9nG9v67nQ= MIME-Version: 1.0 Received: by 10.182.124.33 with SMTP id mf1mr5466108obb.24.1321483255628; Wed, 16 Nov 2011 14:40:55 -0800 (PST) Received: by 10.182.159.73 with HTTP; Wed, 16 Nov 2011 14:40:55 -0800 (PST) Date: Wed, 16 Nov 2011 17:40:55 -0500 Message-ID: Subject: VPN4DC attendees - check out L2VPN today From: Marshall Eubanks To: L3VPN 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, 16 Nov 2011 22:40:59 -0000 People who attended our L3VPN session on VPN4DC yesterday might want to attend L2VPN this morning as it has a related session. I only found out about this yesterday in the L3VPN session, so it seems that some cross-notification would be good. Also note that the full title of the first draft is Problem Statement: Using L3 Overlays for Network Virtualization Regards Marshall Session Two - Thursday November 17th 2011, 0900-1130 ==================================================== 1) Administrivia 2) Problem Statement: Overlays for Network Virtualization https://tools.ietf.org/html/draft-narten-nvo3-overlay-problem-statement-01 Thomas Narten (narten@us.ibm.com) 45 minutes 3) Cloud Networking: Framework and VPN Applicability http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 Nabil Bitar (nabil.n.bitar@verizon.com) 30 minutes 4) Open Mic on NVO3 work 75 minutes From lucy.yong@huawei.com Wed Nov 16 18:40:14 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 29EC61F0C53 for ; Wed, 16 Nov 2011 18:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=-2.313, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJi8IHcusljR for ; Wed, 16 Nov 2011 18:40:13 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC4D1F0C54 for ; Wed, 16 Nov 2011 18:40:13 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS00FBPA2TB1@usaga04-in.huawei.com> for l3vpn@ietf.org; Wed, 16 Nov 2011 20:40:05 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS005W5A2SQU@usaga04-in.huawei.com> for l3vpn@ietf.org; Wed, 16 Nov 2011 20:40:05 -0600 (CST) 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; Wed, 16 Nov 2011 18:39:59 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 16 Nov 2011 18:39:39 -0800 Date: Thu, 17 Nov 2011 02:39:38 +0000 From: Lucy yong Subject: RE: Slides for L3VPN agenda @ IETF82 In-reply-to: X-Originating-IP: [10.47.134.168] To: Pedro Marques , Xuxiaohu Message-id: <2691CE0099834E4A9C5044EEC662BB9D118E35D6@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: Slides for L3VPN agenda @ IETF82 Thread-index: AQHMpCFnZuPTalaD/UyJGk33HGg/lpWwWQCQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> Cc: "l3vpn@ietf.org mailing list" 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, 17 Nov 2011 02:40:14 -0000 DQoNClNuaXANCg0KVGhlcmUgYXJlIHR3bywgbGFyZ2VseSBpbmRlcGVuZGVudCwgcHJvYmxlbXMg dW5kZXIgd2hpY2ggdG8gZXZhbHVhdGUNCnRoZXNlIHN0YXRlbWVudHM6DQogIEEgLSBsM3ZwbiBJ bnRlcmNvbm5lY3Rpb24gYmV0d2VlbiBhIHNlcnZpY2UgcHJvdmlkZXIgYW5kIGEgREMuDQogIEIg LSBuZXR3b3JrIHZpcnR1YWxpemF0aW9uIHNvbHV0aW9uIHdpdGhpbiBhIGRhdGEtY2VudGVyLg0K DQpJbiB0ZXJtcyBvZiBwcm9ibGVtIEEsIHRoZSBjdXJyZW50IGwzdnBuIGFwcHJvYWNoIGlzIHRo ZSBzZXQgb2YNCmludGVyLWFzIHNvbHV0aW9ucyAob3B0aW9uIGEsIGIsIGMpLiBUaGV5IHNlZW0g dG8gYmUgYXQgdGhlIHZlcnkgbGVhc3QNCnRoZSBuZWNlc3Nhcnkgc3RhcnRpbmcgcG9pbnQgZm9y IGFueSBmdXR1cmUgZGV2ZWxvcG1lbnQuDQoNCkluIHRlcm1zIG9mIHByb2JsZW0gQiwgaXQgaXMg dW5jbGVhciB3aGF0IG9uZSBjb3VsZCBjb25zaWRlciB0byBiZSB0aGUNCiJjdXJyZW50IEwzVlBO IGFwcHJvYWNoIi4gSSB3b3VsZCBjb25zaWRlciBkcmFmdC1sM3Zwbi1lbmQtc3lzdGVtIHRvDQpi ZSB0aGUgY3VycmVudCBsM3ZwbiBhcHByb2FjaCBhcHBsaWVkIHRvIGEgc2xpZ2h0bHkgZGlmZmVy ZW50DQplbnZpcm9ubWVudC4gSSdtIG5vdCBzdXJlIGhvd2V2ZXIgaWYgdGhhdCB2aWV3IGlzIGdl bmVyYWxseSBzaGFyZWQuLi4NCg0KV2hlbiBkaXNjdXNzaW5nICJtYW5hZ2VtZW50IHRvb2xzIiBp dCBpcyBhbHNvIHVuY2xlYXIgd2hhdCAidGhlDQpjdXJyZW50IGFwcHJvYWNoIiBpcy4NCg0KW1tM WV1dIEl0IGlzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCBwcm9ibGVtIEEgaXMgYWxzbyBpbiB0aGUg c2NvcGUgb2YgVlBONERDLiBTUCBjbGVhcmx5IHN0YXRlcyB0aGF0IG1hbmFnZW1lbnQgcGxhbmUg c29sdXRpb24gaXMgbm90IHN1ZmZpY2llbnQgdG8gc3VwcG9ydCB0aGUgY2xvdWQgc2VydmljZXMg YW5kIHNlZWtzIHNvbWUgcHJvdG9jb2wgZW5oYW5jZW1lbnQgZm9yIHN1cHBvcnRpbmcgbXVsdGkt dGVuYW50IG92ZXIgYSBzaGFyZWQgREMgaW5mcmEsIG1vYmlsaXR5LCBhbmQgc2VjdXJpdHkuDQoN Ckl0IGlzIG5vdCByZWFzb25hYmxlIHRvIGFzc3VtZSBTUCBtYW5hZ2VtZW50IHN5c3RlbSB0byBp bnRlcndvcmsgd2l0aCBtYW55IGRpZmZlcmVudCBEQyBwcm92aWRlcnMgd2hvIG1heSBoYXZlIHRo ZWlyIG93biBtYW5hZ2VtZW50IHN5c3RlbXMgdG8gYWNoaWV2ZSB0aGlzLg0KDQpSZWdhcmRzLA0K THVjeSANCg0KDQogDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gt6K8/sjLOiBsM3Zwbi1ib3VuY2Vz QGlldGYub3JnIFtsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJlbiBOaXZlbi1KZW5raW5z IFtiZW5Abml2ZW4tamVua2lucy5jby51a10NCj4gt6LLzcqxvOQ6IDIwMTHE6jEx1MIxNsjVIDk6 MzcNCj4gtb06IGwzdnBuQGlldGYub3JnIG1haWxpbmcgbGlzdA0KPiDW98ziOiBTbGlkZXMgZm9y IEwzVlBOIGFnZW5kYSBAIElFVEY4Mg0KPg0KPiBDb2xsZWFndWVzLA0KPg0KPiBUaGUgc2xpZGVz IHRoYXQgd2lsbCBiZSB1c2VkIGluIHRoZSBMM1ZQTiBzZXNzaW9uIHRoaXMgYWZ0ZXJub29uIGFy ZSBub3cgYXZhaWxhYmxlIGZyb20gdGhlIG1lZXRpbmcgbWF0ZXJpYWwgcGFnZSwgaS5lLiBoZXJl Og0KPg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvODIvbWF0ZXJpYWxz Lmh0bWwNCj4NCj4gQmVuDQo+DQo+IE9uIDE0IE5vdiAyMDExLCBhdCAxMTo1MCwgQmVuIE5pdmVu LUplbmtpbnMgd3JvdGU6DQo+DQo+PiBDb2xsZWFndWVzLA0KPj4NCj4+IEkgaGF2ZSB1cGxvYWRl ZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBMM1ZQTi9WUE40REMgYWdlbmRhIHdoaWNoIGluY2x1ZGVz IHRoZSBuYW1lcyBvZiB0aGUgcGVvcGxlIHdobyB3aWxsIGxlYWQgZWFjaCB0b3BpYy4gWW91IGNh biBmaW5kIGl0IGhlcmU6DQo+Pg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84 Mi9hZ2VuZGEvbDN2cG4udHh0DQo+Pg0KPj4gVGhlIGFnZW5kYSBpcyBub3QgYXJyYW5nZWQgYXJv dW5kIHNwZWNpZmljIGRyYWZ0cyBwZXItc2UgYnV0IE1hcnNoYWxsICYgSSBoYXZlIGFza2VkIHRo ZSBwZXJzb24gbGVhZGluZyBlYWNoIHRvcGljIHRvIGNvLW9yZGluYXRlIHdpdGggdGhlIHZhcmlv dXMgZHJhZnQgYXV0aG9ycyB0byBwcm9kdWNlIGEgY29uc29saWRhdGVkIHZpZXcvcHJlc2VudGF0 aW9uIHdoaWNoIHRoZXkgd2lsbCBwcmVzZW50IG9uIGJlaGFsZiBvZiB0aGUgbnVtZXJvdXMgYXV0 aG9ycy9jb250cmlidXRvcnMuDQo+Pg0KPj4gQXMgYSByZW1pbmRlcjogV2UgaGF2ZSBwdXJwb3Nl bHkgbm90IHB1dCB0aW1lIG9uIHRoZSBhZ2VuZGEgdG8gcHJlc2VudC9kaXNjdXNzIHNwZWNpZmlj IHNvbHV0aW9uIGRyYWZ0cyBhcyB3ZSB3b3VsZCBsaWtlIHRoZSBkaXNjdXNzaW9uIHRvIGJlIGZv Y3Vzc2VkIG9uIHRoZSBwcm9ibGVtL3JlcXVpcmVtZW50cyBwb3NlZCBieSBWUE40REMgYW5kIGl0 cyBhcHBsaWNhYmlsaXR5IHRvIElFVEYgKGluY2x1ZGluZyBMM1ZQTikuIERpc2N1c3Npb24gb2Yg c3BlY2lmaWMgc29sdXRpb24gcHJvcG9zYWxzIGNhbiBoYXBwZW4gYXQgZnV0dXJlIG1lZXRpbmdz IGlmIHRoZSBWUE40REMgd29yayBpcyBhZG9wdGVkLg0KPj4NCj4+IEJlbg0KPj4NCj4NCj4NCg== From lucy.yong@huawei.com Wed Nov 16 18:51:17 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 7FC401F0C96 for ; Wed, 16 Nov 2011 18:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.482 X-Spam-Level: X-Spam-Status: No, score=-5.482 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 JGxsrw04ewO0 for ; Wed, 16 Nov 2011 18:51:17 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id E81731F0C81 for ; Wed, 16 Nov 2011 18:51:16 -0800 (PST) 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 <0LUS00CWNALG5U@usaga02-in.huawei.com> for l3vpn@ietf.org; Wed, 16 Nov 2011 20:51:16 -0600 (CST) Received: from dfweml202-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 <0LUS00COJALGT4@usaga02-in.huawei.com> for l3vpn@ietf.org; Wed, 16 Nov 2011 20:51:16 -0600 (CST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 16 Nov 2011 18:51:17 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 16 Nov 2011 18:51:08 -0800 Date: Thu, 17 Nov 2011 02:51:07 +0000 From: Lucy yong Subject: RE: Slides for L3VPN agenda @ IETF82 In-reply-to: X-Originating-IP: [10.47.134.168] To: Pedro Marques , Xuxiaohu Message-id: <2691CE0099834E4A9C5044EEC662BB9D118E35FD@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: Slides for L3VPN agenda @ IETF82 Thread-index: AQHMpIB0ZuPTalaD/UyJGk33HGg/lpWwXX3A X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: jDI= Abg7 De9q GZny G3gn I0+w JPhC LAXf Nk8R PN6z PPal U0Rv VW1C WUyt WZUX XjX3; 2; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAcABlAGQAcgBvAC4AcgAuAG0AYQByAHEAdQBlAHMAQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {F1D069D7-DC0B-43BE-9238-34C3855B8558}; bAB1AGMAeQAuAHkAbwBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 17 Nov 2011 02:51:02 GMT; UgBFADoAIABTAGwAaQBkAGUAcwAgAGYAbwByACAATAAzAFYAUABOACAAYQBnAGUAbgBkAGEAIABAACAASQBFAFQARgA4ADIA x-cr-puzzleid: {F1D069D7-DC0B-43BE-9238-34C3855B8558} References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFB8@szxeml525-mbs.china.huawei.com> Cc: "l3vpn@ietf.org mailing list" 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, 17 Nov 2011 02:51:17 -0000 It is better for us to think of the problems in terms of: -Mechanism for cloud resource mapping to the customer VPN -Security authentication for VM to VPN mapping I don't think problem A and B (below) is the good way to clarify the proble= ms. Lucy -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of P= edro Marques Sent: Wednesday, November 16, 2011 10:55 AM To: Xuxiaohu Cc: l3vpn@ietf.org mailing list Subject: Re: Slides for L3VPN agenda @ IETF82 Xuxiaohu, 2011/11/15 Xuxiaohu : > Pedro, > ________________________________________ > There are two, largely independent, problems under which to evaluate > these statements: > =A0A - l3vpn Interconnection between a service provider and a DC. > =A0B - network virtualization solution within a data-center. > > In terms of problem A, the current l3vpn approach is the set of > inter-as solutions (option a, b, c). They seem to be at the very least > the necessary starting point for any future development. > > In terms of problem B, it is unclear what one could consider to be the > "current L3VPN approach". I would consider draft-l3vpn-end-system to > be the current l3vpn approach applied to a slightly different > environment. I'm not sure however if that view is generally shared... > > Thanks a lot for this clarification. If I understand your points co= rrectly, the problem A is outside of the VPN4DC scope since it doesn't requ= ire any further development. That is a strong statement that i wouldn't want to make. It is quite possible that it may benefit from incremental improvements. But i believe that Ben's original question of what are the problems with the "current l3vpn approach" is quite pertinent in this case. > =A0As for problem B which seems to be within the scope, the VPN4DC is int= ended to focus on the approach that the L3VPN PE functions are performed on= hosts (e.g.,draft-l3vpn-end-system), rather than on routers. Please correc= t me if my understanding is wrong. The desire to perform the VPN forwarding function on end-systems doesn't come out of the vacuum. It comes from a combination of factors that where being discussed in a parallel thread: - cost / complexity of operating the DC "fabric" network. - The fact that it is undesirable to have an L2/L3 boundary anywhere within the DC. - Scaling requirements for the number of potential routes available to a single VM. - Need to be efficient in terms of traffic fowarding (packets should cross the fabric once). - Need to support multiple isolation domains. I'm not attempting to claim that this is the only way to address the problem; but it is, imho, a reasonable approach given the trade-offs in this space. I would expect several other alternatives to be presented. thank you, Pedro. From DanielC@orckit.com Wed Nov 16 23:29: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 0C24411E8136 for ; Wed, 16 Nov 2011 23:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrVTZw0vY3A5 for ; Wed, 16 Nov 2011 23:29:36 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7121411E8132 for ; Wed, 16 Nov 2011 23:29:34 -0800 (PST) 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: Last Call: (OSPFv3 as aPE-CErouting protocol) to Proposed Standard Date: Thu, 17 Nov 2011 09:29:36 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA081307304B91@tlvmail1> In-Reply-To: <28D36026-7B5E-4ECB-8394-9679B9A66AE4@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (OSPFv3 as aPE-CErouting protocol) to Proposed Standard Thread-Index: AcykcDtYMzLRX1W1RzW7w6Ku/VaR2AAiDEgg References: <20111112234223.20827.13913.idtracker@ietfa.amsl.com> <44F4E579A764584EA9BDFD07D0CA081307304A3D@tlvmail1> <28D36026-7B5E-4ECB-8394-9679B9A66AE4@ericsson.com> From: "Daniel Cohn" To: "Acee Lindem" 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: Thu, 17 Nov 2011 07:29:37 -0000 Hi Acee, thanks for your reply.=20 I don't agree with your comment regarding lack of implementations associating a single interface to multiple VRFs. By way of example, the following links show major vendor implementation of this feature: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/vrfselec.html http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id- 11185557.html But this is not of the essence - the main issue IMO is that RFC 4364 framework does allow this configuration, so the draft statement is factually incorrect. Now, I do agree that we lack clear definitions on how OSPF (or any other PE-CE protocol) should be used in this scenario. That's why I wrote that the statement should be qualified, not deleted. Something like "Configurations where a PE interface is associated with multiple VRFs are out of the scope of this document". What do you think? Regards, Daniel -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Wednesday, November 16, 2011 4:59 PM To: Daniel Cohn Cc: l3vpn@ietf.org Subject: Re: Last Call: (OSPFv3 as aPE-CErouting protocol) to Proposed Standard Hi Daniel, I'm not an author but I'll comment.=20 On Nov 16, 2011, at 5:38 AM, Daniel Cohn wrote: > Hi, >=20 > (Belated) question to the authors: >=20 > Doesn't the following statement in the draft: >=20 > "However, since a PE interface can be associated with only one VRF, all > OSPFv3 instances running on the same interface MUST be associated with > the same VRF." >=20 > contradict the following statement in RFC 4364, section 3.2? >=20 > " In some cases, a particular site may be divided by the customer into > several "virtual sites"... Another way to accomplish this is to use IP > source addresses. In this case, the PE uses the IP source address in a > packet received from the CE, along with the interface over which the > packet is received, to assign the packet to a particular VRF" To the best of my knowledge, nobody has implemented the ability to put different subnets on the same interface in different VRFs. The way this problem is typically solved is with some layer 2 encapsulation, e.g., different VLANs in different VRFs.=20 To complicate things, OSPFv3 runs on a link as opposed to a subnet. Hence the demuxing described in RFC 4364 would not work. Conceivably, one could use the OSPFv3 interface instance ID for this demuxing but I don't think it makes any sense to try and solve this problem when no one is putting a single interface in multiple VRFs.=20 Thanks, Acee=20 >=20 > In other words, RFC 4364 allows assigning a single PE interface to > several VRFs. So shouldn't the statement in the draft at least be > qualified? >=20 > Regards, >=20 > Daniel >=20 > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of The IESG > Sent: Sunday, November 13, 2011 1:42 AM > To: IETF-Announce > Cc: l3vpn@ietf.org > Subject: Last Call: (OSPFv3 as a > PE-CErouting protocol) to Proposed Standard >=20 >=20 > The IESG has received a request from the Layer 3 Virtual Private > Networks WG (l3vpn) to consider the following document: > - 'OSPFv3 as a PE-CE routing protocol' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-12-04. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Many Service Providers (SPs) offer Virtual Private Network (VPN) > services to their customers using a technique in which Customer Edge > (CE) routers are routing peers of Provider Edge (PE) routers. The > Border Gateway Protocol (BGP) is used to distribute the customer's > routes across the provider's IP backbone network, and Multiprotocol > Label Switching (MPLS) is used to tunnel customer packets across the > provider's backbone. This is known as a "BGP/MPLS IP VPN". > Originally only IPv4 was supported and it was later extended to > support IPv6 VPNs as well. Extensions were later added for the > support of the Open Shortest Path First protocol version 2 (OSPFv2) > as a PE-CE routing protocol for the IPv4 VPNs. This document extends > those specifications to support OSPF version 3 (OSPFv3) as a PE-CE > routing protocol. The OSPFv3 PE-CE functionality is identical to > that of OSPFv2 except for the differences described in this document. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 From acee.lindem@ericsson.com Thu Nov 17 03:10: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 BB2DB21F9B43 for ; Thu, 17 Nov 2011 03:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5sav+nEbqZW for ; Thu, 17 Nov 2011 03:10:10 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id C444221F8C15 for ; Thu, 17 Nov 2011 03:10:07 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAHBA6ct022507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Nov 2011 05:10:07 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.218]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 17 Nov 2011 06:10:06 -0500 From: Acee Lindem To: Daniel Cohn Date: Thu, 17 Nov 2011 06:09:59 -0500 Subject: Re: Last Call: (OSPFv3 as aPE-CErouting protocol) to Proposed Standard Thread-Topic: Last Call: (OSPFv3 as aPE-CErouting protocol) to Proposed Standard Thread-Index: AcylGXWVBvPVPYm+Q+CcI0xK3WxuWA== Message-ID: References: <20111112234223.20827.13913.idtracker@ietfa.amsl.com> <44F4E579A764584EA9BDFD07D0CA081307304A3D@tlvmail1> <28D36026-7B5E-4ECB-8394-9679B9A66AE4@ericsson.com> <44F4E579A764584EA9BDFD07D0CA081307304B91@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081307304B91@tlvmail1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-101--376383728"; protocol="application/pkcs7-signature"; micalg=sha1 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: Thu, 17 Nov 2011 11:10:12 -0000 --Apple-Mail-101--376383728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Daniel,=20 On Nov 17, 2011, at 2:29 AM, Daniel Cohn wrote: > Hi Acee, thanks for your reply.=20 > I don't agree with your comment regarding lack of implementations > associating a single interface to multiple VRFs. By way of example, = the > following links show major vendor implementation of this feature: >=20 > http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/vrfselec.html > = http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id- > 11185557.html This is interesting - I didn't know this capability existed. I see the = two approaches have some differences and both are limited to static = routing.=20 >=20 > But this is not of the essence - the main issue IMO is that RFC 4364 > framework does allow this configuration, so the draft statement is > factually incorrect. >=20 > Now, I do agree that we lack clear definitions on how OSPF (or any = other > PE-CE protocol) should be used in this scenario. That's why I wrote = that > the statement should be qualified, not deleted. Something like > "Configurations where a PE interface is associated with multiple VRFs > are out of the scope of this document". >=20 > What do you think? I'd be fine with this statement.=20 Thanks, Acee=20 >=20 > Regards, >=20 > Daniel >=20 > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Wednesday, November 16, 2011 4:59 PM > To: Daniel Cohn > Cc: l3vpn@ietf.org > Subject: Re: Last Call: (OSPFv3 = as > aPE-CErouting protocol) to Proposed Standard >=20 > Hi Daniel, > I'm not an author but I'll comment.=20 >=20 > On Nov 16, 2011, at 5:38 AM, Daniel Cohn wrote: >=20 >> Hi, >>=20 >> (Belated) question to the authors: >>=20 >> Doesn't the following statement in the draft: >>=20 >> "However, since a PE interface can be associated with only one VRF, > all >> OSPFv3 instances running on the same interface MUST be associated = with >> the same VRF." >>=20 >> contradict the following statement in RFC 4364, section 3.2? >>=20 >> " In some cases, a particular site may be divided by the customer = into >> several "virtual sites"... Another way to accomplish this is to use = IP >> source addresses. In this case, the PE uses the IP source address in > a >> packet received from the CE, along with the interface over which the >> packet is received, to assign the packet to a particular VRF" >=20 > To the best of my knowledge, nobody has implemented the ability to put > different subnets on the same interface in different VRFs. The way = this > problem is typically solved is with some layer 2 encapsulation, e.g., > different VLANs in different VRFs.=20 > To complicate things, OSPFv3 runs on a link as opposed to a subnet. > Hence the demuxing described in RFC 4364 would not work. Conceivably, > one could use the OSPFv3 interface instance ID for this demuxing but I > don't think it makes any sense to try and solve this problem when no = one > is putting a single interface in multiple VRFs.=20 >=20 > Thanks, > Acee=20 >=20 >=20 >>=20 >> In other words, RFC 4364 allows assigning a single PE interface to >> several VRFs. So shouldn't the statement in the draft at least be >> qualified? >>=20 >> Regards, >>=20 >> Daniel >>=20 >> -----Original Message----- >> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On = Behalf >> Of The IESG >> Sent: Sunday, November 13, 2011 1:42 AM >> To: IETF-Announce >> Cc: l3vpn@ietf.org >> Subject: Last Call: (OSPFv3 as = a >> PE-CErouting protocol) to Proposed Standard >>=20 >>=20 >> The IESG has received a request from the Layer 3 Virtual Private >> Networks WG (l3vpn) to consider the following document: >> - 'OSPFv3 as a PE-CE routing protocol' >> as a Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2011-12-04. Exceptionally, comments = may >> be sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> Many Service Providers (SPs) offer Virtual Private Network (VPN) >> services to their customers using a technique in which Customer Edge >> (CE) routers are routing peers of Provider Edge (PE) routers. The >> Border Gateway Protocol (BGP) is used to distribute the customer's >> routes across the provider's IP backbone network, and Multiprotocol >> Label Switching (MPLS) is used to tunnel customer packets across the >> provider's backbone. This is known as a "BGP/MPLS IP VPN". >> Originally only IPv4 was supported and it was later extended to >> support IPv6 VPNs as well. Extensions were later added for the >> support of the Open Shortest Path First protocol version 2 (OSPFv2) >> as a PE-CE routing protocol for the IPv4 VPNs. This document > extends >> those specifications to support OSPF version 3 (OSPFv3) as a PE-CE >> routing protocol. The OSPFv3 PE-CE functionality is identical to >> that of OSPFv2 except for the differences described in this > document. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ >>=20 >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >=20 --Apple-Mail-101--376383728 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTExNzExMDk2MFowIwYJKoZI hvcNAQkEMRYEFE9Cs2HwVBoKNhr3WsFESNWubGabMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgE6oIStQLccHTskVegZigzJlkBOWA7NEHcT6spMFtaQ7PMk7G+aPiSc1KY1kr7Bu Azha98pCgWn7RqNqe4siAslhrlkpywwY2Bhbc05DNmmt5rbqB3VkRC0r1rKZqiBNBly6wrchYHcd 7lPD2N6X/I+ejwK9OYz0jQbyzPn2/TZGAAAAAAAA --Apple-Mail-101--376383728-- From michaellundberg.ietf@gmail.com Thu Nov 17 07:26:47 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 CB02811E814A for ; Thu, 17 Nov 2011 07:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqTdCqy-EEDG for ; Thu, 17 Nov 2011 07:26:46 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A63211E8144 for ; Thu, 17 Nov 2011 07:26:46 -0800 (PST) Received: by ywt34 with SMTP id 34so1430553ywt.31 for ; Thu, 17 Nov 2011 07:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0/zlW9tgvAKClJq56nhzspgG1yCuSb7k4eu1hV+9nMA=; b=sjw/FxmvG6cHTmZT0mEgSmhelDiAxAiaMsI9xhqb1WyJ5oLrMJPyY2YEOF78cy4ony cHyDR1EntTF4ovb3NVQQpIjtHpXiHpNgg5M+FjhlLrnCPRCpeKGyX+tKEdx/VnvHeEQj g+H6/ezslVkWOX8QEtHiRvizxpBivxtlCrRSo= MIME-Version: 1.0 Received: by 10.236.197.99 with SMTP id s63mr10199416yhn.14.1321543606006; Thu, 17 Nov 2011 07:26:46 -0800 (PST) Received: by 10.236.108.171 with HTTP; Thu, 17 Nov 2011 07:26:45 -0800 (PST) In-Reply-To: References: <20111112234223.20827.13913.idtracker@ietfa.amsl.com> <44F4E579A764584EA9BDFD07D0CA081307304A3D@tlvmail1> <28D36026-7B5E-4ECB-8394-9679B9A66AE4@ericsson.com> <44F4E579A764584EA9BDFD07D0CA081307304B91@tlvmail1> Date: Thu, 17 Nov 2011 10:26:45 -0500 Message-ID: Subject: Re: Last Call: (OSPFv3 as aPE-CErouting protocol) to Proposed Standard From: Michael Lundberg To: Acee Lindem , Daniel Cohn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Thu, 17 Nov 2011 15:26:47 -0000 Daniel, Thanks for the comment, and Acee thanks for providing your input as well! Given that there are implementations that allow selection of the VRF based on IP address, I agree we need to add and/or modify the text Dan pointed out below. I am ok with adding the suggested text, and also removing the words "However, since" to the beginning of the sentence, so it reads... "A PE interface can be associated with only one VRF, and all OSPFv3 instances running on the same interface MUST be associated with the same VRF. Configurations where a PE interface is associated with multiple VRFs are out of scope for this document" Let us know if this works. Regards, Michael On Thu, Nov 17, 2011 at 6:09 AM, Acee Lindem wro= te: > Hi Daniel, > > On Nov 17, 2011, at 2:29 AM, Daniel Cohn wrote: > >> Hi Acee, thanks for your reply. >> I don't agree with your comment regarding lack of implementations >> associating a single interface to multiple VRFs. By way of example, the >> following links show major vendor implementation of this feature: >> >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/vrfselec.html >> http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id- >> 11185557.html > > This is interesting - I didn't know this capability existed. I see the tw= o approaches have some differences and both are limited to static routing. > > >> >> But this is not of the essence - the main issue IMO is that RFC 4364 >> framework does allow this configuration, so the draft statement is >> factually incorrect. >> >> Now, I do agree that we lack clear definitions on how OSPF (or any other >> PE-CE protocol) should be used in this scenario. That's why I wrote that >> the statement should be qualified, not deleted. Something like >> "Configurations where a PE interface is associated with multiple VRFs >> are out of the scope of this document". >> >> What do you think? > > I'd be fine with this statement. > > Thanks, > Acee > > > >> >> Regards, >> >> Daniel >> >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Wednesday, November 16, 2011 4:59 PM >> To: Daniel Cohn >> Cc: l3vpn@ietf.org >> Subject: Re: Last Call: (OSPFv3 as >> aPE-CErouting protocol) to Proposed Standard >> >> Hi Daniel, >> I'm not an author but I'll comment. >> >> On Nov 16, 2011, at 5:38 AM, Daniel Cohn wrote: >> >>> Hi, >>> >>> (Belated) question to the authors: >>> >>> Doesn't the following statement in the draft: >>> >>> "However, since a PE interface can be associated with only one VRF, >> all >>> OSPFv3 instances running on the same interface MUST be associated with >>> the same VRF." >>> >>> contradict the following statement in RFC 4364, section 3.2? >>> >>> " In some cases, a particular site may be divided by the customer into >>> several "virtual sites"... Another way to accomplish this is to use IP >>> source addresses. =A0In this case, the PE uses the IP source address in >> a >>> packet received from the CE, along with the interface over which the >>> packet is received, to assign the packet to a particular VRF" >> >> To the best of my knowledge, nobody has implemented the ability to put >> different subnets on the same interface in different VRFs. The way this >> problem is typically solved is with some layer 2 encapsulation, e.g., >> different VLANs in different VRFs. >> To complicate things, OSPFv3 runs on a link as opposed to a subnet. >> Hence the demuxing described in RFC 4364 would not work. Conceivably, >> one could use the OSPFv3 interface instance ID for this demuxing but I >> don't think it makes any sense to try and solve this problem when no one >> is putting a single interface in multiple VRFs. >> >> Thanks, >> Acee >> >> >>> >>> In other words, RFC 4364 allows assigning a single PE interface to >>> several VRFs. So shouldn't the statement in the draft at least be >>> qualified? >>> >>> Regards, >>> >>> Daniel >>> >>> -----Original Message----- >>> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf >>> Of The IESG >>> Sent: Sunday, November 13, 2011 1:42 AM >>> To: IETF-Announce >>> Cc: l3vpn@ietf.org >>> Subject: Last Call: (OSPFv3 as a >>> PE-CErouting protocol) to Proposed Standard >>> >>> >>> The IESG has received a request from the Layer 3 Virtual Private >>> Networks WG (l3vpn) to consider the following document: >>> - 'OSPFv3 as a PE-CE routing protocol' >>> as a Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2011-12-04. Exceptionally, comments may >>> be sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> =A0Many Service Providers (SPs) offer Virtual Private Network (VPN) >>> =A0services to their customers using a technique in which Customer Edge >>> =A0(CE) routers are routing peers of Provider Edge (PE) routers. =A0The >>> =A0Border Gateway Protocol (BGP) is used to distribute the customer's >>> =A0routes across the provider's IP backbone network, and Multiprotocol >>> =A0Label Switching (MPLS) is used to tunnel customer packets across the >>> =A0provider's backbone. =A0This is known as a "BGP/MPLS IP VPN". >>> =A0Originally only IPv4 was supported and it was later extended to >>> =A0support IPv6 VPNs as well. =A0Extensions were later added for the >>> =A0support of the Open Shortest Path First protocol version 2 (OSPFv2) >>> =A0as a PE-CE routing protocol for the IPv4 VPNs. =A0This document >> extends >>> =A0those specifications to support OSPF version 3 (OSPFv3) as a PE-CE >>> =A0routing protocol. =A0The OSPFv3 PE-CE functionality is identical to >>> =A0that of OSPFv2 except for the differences described in this >> document. >>> >>> >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >> > > From pedro.r.marques@gmail.com Thu Nov 17 09:13:53 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 6B8A211E80D4 for ; Thu, 17 Nov 2011 09:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.005, 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 FcB6KPWLFf09 for ; Thu, 17 Nov 2011 09:13:48 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05C7C11E80CD for ; Thu, 17 Nov 2011 09:13:47 -0800 (PST) Received: by ggnr5 with SMTP id r5so1604179ggn.31 for ; Thu, 17 Nov 2011 09:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SJYcQCduiYQsstSfZKTdsLJyGHO9lOrzwUu8e9kW8nk=; b=BC93b4W7qTIGq8kTQBoaal+B0J6t31dPEQWjHXu+dTwguAPX2GZKC1TrU6t/s6l0GM SsvZc/27dCXUkELRoiBM76XDczaB9WhDycYFwDVLSfjzYFPQAdMO/FL61DGCJUQ8lyJt MyP57BhY1rliXCFgsooji3MerqeszeAJA8HsI= MIME-Version: 1.0 Received: by 10.50.184.202 with SMTP id ew10mr44392690igc.48.1321550027339; Thu, 17 Nov 2011 09:13:47 -0800 (PST) Received: by 10.231.12.2 with HTTP; Thu, 17 Nov 2011 09:13:47 -0800 (PST) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D118E35FD@dfweml506-mbx> References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFB8@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D118E35FD@dfweml506-mbx> Date: Thu, 17 Nov 2011 09:13:47 -0800 Message-ID: Subject: Re: Slides for L3VPN agenda @ IETF82 From: Pedro Marques To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org mailing list" 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, 17 Nov 2011 17:13:53 -0000 Lucy, On Wed, Nov 16, 2011 at 6:51 PM, Lucy yong wrote: > It is better for us to think of the problems in terms of: > > -Mechanism for cloud resource mapping to the customer VPN I don't know what "cloud resource mapping" means. The energy necessary to transform water into vapor ? I believe that it would be much more productive to speak in terms of interconnecting networks: private enterprise networks and private DC networks. Standardization of APIs between Web clients and orchestration Web panels belongs in SDOs others than the IETF (e.g. OASIS) as it has nothing to do with networking. > -Security authentication for VM to VPN mapping VMs aren't created out of the blue and do not join the VPNs they want to join. VMs are created by an orchestration system that constraint them to one specific VPN network. That network may or not interconnect to the outside world. The VM to VPN mapping is decided at the time a VM is instantiated. This is the internal DC VPN which may or may not connect to an external VPN. > > I don't think problem A and B (below) is the good way to clarify the prob= lems. The issues you mention relate to the implementation and APIs of orchestration systems. Not to connectivity. They do not belong to the IETF. > > Lucy > > > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of= Pedro Marques > Sent: Wednesday, November 16, 2011 10:55 AM > To: Xuxiaohu > Cc: l3vpn@ietf.org mailing list > Subject: Re: Slides for L3VPN agenda @ IETF82 > > Xuxiaohu, > > 2011/11/15 Xuxiaohu : >> Pedro, >> ________________________________________ >> There are two, largely independent, problems under which to evaluate >> these statements: >> =A0A - l3vpn Interconnection between a service provider and a DC. >> =A0B - network virtualization solution within a data-center. >> >> In terms of problem A, the current l3vpn approach is the set of >> inter-as solutions (option a, b, c). They seem to be at the very least >> the necessary starting point for any future development. >> >> In terms of problem B, it is unclear what one could consider to be the >> "current L3VPN approach". I would consider draft-l3vpn-end-system to >> be the current l3vpn approach applied to a slightly different >> environment. I'm not sure however if that view is generally shared... >> >> Thanks a lot for this clarification. If I understand your points c= orrectly, the problem A is outside of the VPN4DC scope since it doesn't req= uire any further development. > > That is a strong statement that i wouldn't want to make. It is quite > possible that it may benefit from incremental improvements. But i > believe that Ben's original question of what are the problems with the > "current l3vpn approach" is quite pertinent in this case. > >> =A0As for problem B which seems to be within the scope, the VPN4DC is in= tended to focus on the approach that the L3VPN PE functions are performed o= n hosts (e.g.,draft-l3vpn-end-system), rather than on routers. Please corre= ct me if my understanding is wrong. > > The desire to perform the VPN forwarding function on end-systems > doesn't come out of the vacuum. It comes from a combination of factors > that where being discussed in a parallel thread: > =A0- cost / complexity of operating the DC "fabric" network. > =A0- The fact that it is undesirable to have an L2/L3 boundary anywhere > within the DC. > =A0- Scaling requirements for the number of potential routes available > to a single VM. > =A0- Need to be efficient in terms of traffic fowarding (packets should > cross the fabric once). > =A0- Need to support multiple isolation domains. > > I'm not attempting to claim that this is the only way to address the > problem; but it is, imho, a reasonable approach given the trade-offs > in this space. I would expect several other alternatives to be > presented. > > thank you, > =A0Pedro. > From lucy.yong@huawei.com Thu Nov 17 16:29:06 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 D2D4911E809C for ; Thu, 17 Nov 2011 16:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.478 X-Spam-Level: X-Spam-Status: No, score=-5.478 tagged_above=-999 required=5 tests=[AWL=-0.079, 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 5gdSaPVmDYDG for ; Thu, 17 Nov 2011 16:29:06 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id D825411E808B for ; Thu, 17 Nov 2011 16:29:02 -0800 (PST) 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 <0LUT00CEFYO9R9@usaga02-in.huawei.com> for l3vpn@ietf.org; Thu, 17 Nov 2011 18:28:58 -0600 (CST) 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 <0LUT00HN1YO9HA@usaga02-in.huawei.com> for l3vpn@ietf.org; Thu, 17 Nov 2011 18:28:57 -0600 (CST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 17 Nov 2011 16:28:51 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Thu, 17 Nov 2011 16:28:08 -0800 Date: Fri, 18 Nov 2011 00:28:47 +0000 From: Lucy yong Subject: RE: Slides for L3VPN agenda @ IETF82 In-reply-to: X-Originating-IP: [10.47.98.11] To: Pedro Marques Message-id: <2691CE0099834E4A9C5044EEC662BB9D19E7760B@dfweml505-mbx> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: Slides for L3VPN agenda @ IETF82 Thread-index: AQHMpIB0ZuPTalaD/UyJGk33HGg/lpWwXX3AgAF4J4D//+0r4A== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFB8@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D118E35FD@dfweml506-mbx> Cc: "l3vpn@ietf.org mailing list" 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, 18 Nov 2011 00:29:06 -0000 Petro, On Wed, Nov 16, 2011 at 6:51 PM, Lucy yong wrote: > It is better for us to think of the problems in terms of: > > -Mechanism for cloud resource mapping to the customer VPN I don't know what "cloud resource mapping" means. The energy necessary to transform water into vapor ? I believe that it would be much more productive to speak in terms of interconnecting networks: private enterprise networks and private DC networks. [[LY]] " " term is a bit confuse. Virtual resource in Provider DC is more c= lear. Standardization of APIs between Web clients and orchestration Web panels belongs in SDOs others than the IETF (e.g. OASIS) as it has nothing to do with networking. [[LY]] Here we talk about mapping within the network. Not in Web Aplication= . > -Security authentication for VM to VPN mapping VMs aren't created out of the blue and do not join the VPNs they want to join. VMs are created by an orchestration system that constraint them to one specific VPN network.=20 [[LY]] this is the tricky part. Can we limit to one orchestration system th= at is responsible to create VMs and select one specific VPN network? My und= erstanding, there are different orchestration systems for VM and networking= . Whether interworking between orchestration systems or interworking betwee= n networks and VMs to achieve this is the subject.=20 That network may or not interconnect to the outside world. [[LY]] Agree. The VM to VPN mapping is decided at the time a VM is instantiated. This is the internal DC VPN which may or may not connect to an external VPN. [[LY]] This implies that the VPN access at this DC only populates the route= s for the VMs that explicitly map to the VPN, and only forward the packets = from these VMs to the VPN.=20 > > I don't think problem A and B (below) is the good way to clarify the prob= lems. The issues you mention relate to the implementation and APIs of orchestration systems. Not to connectivity. They do not belong to the IETF. [[LY]] there are different ways to implement this. We here work on the netw= ork based solution, which belongs to IETF. Regards, Lucy > > Lucy > > > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of= Pedro Marques > Sent: Wednesday, November 16, 2011 10:55 AM > To: Xuxiaohu > Cc: l3vpn@ietf.org mailing list > Subject: Re: Slides for L3VPN agenda @ IETF82 > > Xuxiaohu, > > 2011/11/15 Xuxiaohu : >> Pedro, >> ________________________________________ >> There are two, largely independent, problems under which to evaluate >> these statements: >> =A0A - l3vpn Interconnection between a service provider and a DC. >> =A0B - network virtualization solution within a data-center. >> >> In terms of problem A, the current l3vpn approach is the set of >> inter-as solutions (option a, b, c). They seem to be at the very least >> the necessary starting point for any future development. >> >> In terms of problem B, it is unclear what one could consider to be the >> "current L3VPN approach". I would consider draft-l3vpn-end-system to >> be the current l3vpn approach applied to a slightly different >> environment. I'm not sure however if that view is generally shared... >> >> Thanks a lot for this clarification. If I understand your points c= orrectly, the problem A is outside of the VPN4DC scope since it doesn't req= uire any further development. > > That is a strong statement that i wouldn't want to make. It is quite > possible that it may benefit from incremental improvements. But i > believe that Ben's original question of what are the problems with the > "current l3vpn approach" is quite pertinent in this case. > >> =A0As for problem B which seems to be within the scope, the VPN4DC is in= tended to focus on the approach that the L3VPN PE functions are performed o= n hosts (e.g.,draft-l3vpn-end-system), rather than on routers. Please corre= ct me if my understanding is wrong. > > The desire to perform the VPN forwarding function on end-systems > doesn't come out of the vacuum. It comes from a combination of factors > that where being discussed in a parallel thread: > =A0- cost / complexity of operating the DC "fabric" network. > =A0- The fact that it is undesirable to have an L2/L3 boundary anywhere > within the DC. > =A0- Scaling requirements for the number of potential routes available > to a single VM. > =A0- Need to be efficient in terms of traffic fowarding (packets should > cross the fabric once). > =A0- Need to support multiple isolation domains. > > I'm not attempting to claim that this is the only way to address the > problem; but it is, imho, a reasonable approach given the trade-offs > in this space. I would expect several other alternatives to be > presented. > > thank you, > =A0Pedro. > From pedro.r.marques@gmail.com Thu Nov 17 17:43:40 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 2C96F11E8094 for ; Thu, 17 Nov 2011 17:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, 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 KvPqbcH-sEIp for ; Thu, 17 Nov 2011 17:43:39 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B64C711E808A for ; Thu, 17 Nov 2011 17:43:35 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so3116539vcb.31 for ; Thu, 17 Nov 2011 17:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8BQPNQKm9e99+/b1znn8EdHMo8eWJjkl5R5hqsO+PG4=; b=AeSeQ93rvZEuwOwXo271Sq0V3e4GKS00Z4sUJe2ZAWRrakO/VYfPiK/qpKbyMFCt6k 1XBZgK/Nk7On917ZMVqW26ze3/CRCyLr8oPhyO18UaN8mLmFKkLPaxyo93spEWuIWnjC Th0llacLq+TEeHVOYXgmIx6K6u9mCm2yNqe68= MIME-Version: 1.0 Received: by 10.52.36.109 with SMTP id p13mr1208211vdj.59.1321580614969; Thu, 17 Nov 2011 17:43:34 -0800 (PST) Received: by 10.52.18.174 with HTTP; Thu, 17 Nov 2011 17:43:34 -0800 (PST) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D19E7760B@dfweml505-mbx> References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BFB8@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D118E35FD@dfweml506-mbx> <2691CE0099834E4A9C5044EEC662BB9D19E7760B@dfweml505-mbx> Date: Thu, 17 Nov 2011 17:43:34 -0800 Message-ID: Subject: Re: Slides for L3VPN agenda @ IETF82 From: Pedro Marques To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org mailing list" 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, 18 Nov 2011 01:43:40 -0000 Lucy, > [[LY]] this is the tricky part. Can we limit to one orchestration system = that is responsible to create VMs and select one specific VPN network? My u= nderstanding, there are different orchestration systems for VM and networki= ng. Whether interworking between orchestration systems or interworking betw= een networks and VMs to achieve this is the subject. > Irrespective of how many systems are involved, the VM itself is not in control of its network assignment. When a VM is instantiated in a physical machine, its IP address and isolation domain (VLAN or VPN) must be know. In the SDNP mailing list we presented a proposal on how to enable for multiple orchestration system to interact with network signaling protocols (via an IF-MAP schema). If your concern is interacting with multiple orchestration system, i believe that proposal is a reasonable starting point. > The VM to VPN mapping is decided at the time a VM is instantiated. > This is the internal DC VPN which may or may not connect to an > external VPN. > [[LY]] This implies that the VPN access at this DC only populates the rou= tes for the VMs that explicitly map to the VPN, and only forward the packet= s from these VMs to the VPN. > I'm not sure how to interpret your statement. The DC networking solution must provide for isolation... within the DC, VMs of customer A are not allowed to communicate directly with VMs of customer B absent additional policies that explicitly allow for that communication to happen. > >> >> I don't think problem A and B (below) is the good way to clarify the pro= blems. > > The issues you mention relate to the implementation and APIs of > orchestration systems. Not to connectivity. They do not belong to the > IETF. > [[LY]] there are different ways to implement this. We here work on the ne= twork based solution, which belongs to IETF. If by "this" you mean provisioning of compute and storage resources, what does "a network based solution" mean in this context ? If your intent is to create communication protocols which exchange messages via network elements for functionality that can be achieved as well or better by end-systems, I personally, i'm very skeptic of its changes of success. Pedro. From DanielC@orckit.com Sat Nov 19 23:50:51 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 160A21F0C4D for ; Sat, 19 Nov 2011 23:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7hdjQLi6IOf for ; Sat, 19 Nov 2011 23:50:50 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1A01F0C34 for ; Sat, 19 Nov 2011 23:50:48 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: Last Call: (OSPFv3 as aPE-CErouting protocol) to Proposed Standard Date: Sun, 20 Nov 2011 09:50:51 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA081307304D6C@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (OSPFv3 as aPE-CErouting protocol) to Proposed Standard Thread-Index: AcylPcAnnaE6DEP2TSe82Juv4TqsPgCG1lSQ References: <20111112234223.20827.13913.idtracker@ietfa.amsl.com><44F4E579A764584EA9BDFD07D0CA081307304A3D@tlvmail1><28D36026-7B5E-4ECB-8394-9679B9A66AE4@ericsson.com><44F4E579A764584EA9BDFD07D0CA081307304B91@tlvmail1> From: "Daniel Cohn" To: "Michael Lundberg" , "Acee Lindem" 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: Sun, 20 Nov 2011 07:50:51 -0000 That=92s fine with me, thanks, DC -----Original Message----- From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com]=20 Sent: Thursday, November 17, 2011 5:27 PM To: Acee Lindem; Daniel Cohn Cc: l3vpn@ietf.org Subject: Re: Last Call: (OSPFv3 as = aPE-CErouting protocol) to Proposed Standard Daniel, Thanks for the comment, and Acee thanks for providing your input as well! Given that there are implementations that allow selection of the VRF based on IP address, I agree we need to add and/or modify the text Dan pointed out below. I am ok with adding the suggested text, and also removing the words "However, since" to the beginning of the sentence, so it reads... "A PE interface can be associated with only one VRF, and all OSPFv3 instances running on the same interface MUST be associated with the same VRF. Configurations where a PE interface is associated with multiple VRFs are out of scope for this document" Let us know if this works. Regards, Michael On Thu, Nov 17, 2011 at 6:09 AM, Acee Lindem = wrote: > Hi Daniel, > > On Nov 17, 2011, at 2:29 AM, Daniel Cohn wrote: > >> Hi Acee, thanks for your reply. >> I don't agree with your comment regarding lack of implementations >> associating a single interface to multiple VRFs. By way of example, = the >> following links show major vendor implementation of this feature: >> >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/vrfselec.html >> = http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id- >> 11185557.html > > This is interesting - I didn't know this capability existed. I see the = two approaches have some differences and both are limited to static = routing. > > >> >> But this is not of the essence - the main issue IMO is that RFC 4364 >> framework does allow this configuration, so the draft statement is >> factually incorrect. >> >> Now, I do agree that we lack clear definitions on how OSPF (or any = other >> PE-CE protocol) should be used in this scenario. That's why I wrote = that >> the statement should be qualified, not deleted. Something like >> "Configurations where a PE interface is associated with multiple VRFs >> are out of the scope of this document". >> >> What do you think? > > I'd be fine with this statement. > > Thanks, > Acee > > > >> >> Regards, >> >> Daniel >> >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Wednesday, November 16, 2011 4:59 PM >> To: Daniel Cohn >> Cc: l3vpn@ietf.org >> Subject: Re: Last Call: (OSPFv3 = as >> aPE-CErouting protocol) to Proposed Standard >> >> Hi Daniel, >> I'm not an author but I'll comment. >> >> On Nov 16, 2011, at 5:38 AM, Daniel Cohn wrote: >> >>> Hi, >>> >>> (Belated) question to the authors: >>> >>> Doesn't the following statement in the draft: >>> >>> "However, since a PE interface can be associated with only one VRF, >> all >>> OSPFv3 instances running on the same interface MUST be associated = with >>> the same VRF." >>> >>> contradict the following statement in RFC 4364, section 3.2? >>> >>> " In some cases, a particular site may be divided by the customer = into >>> several "virtual sites"... Another way to accomplish this is to use = IP >>> source addresses. =A0In this case, the PE uses the IP source address = in >> a >>> packet received from the CE, along with the interface over which the >>> packet is received, to assign the packet to a particular VRF" >> >> To the best of my knowledge, nobody has implemented the ability to = put >> different subnets on the same interface in different VRFs. The way = this >> problem is typically solved is with some layer 2 encapsulation, e.g., >> different VLANs in different VRFs. >> To complicate things, OSPFv3 runs on a link as opposed to a subnet. >> Hence the demuxing described in RFC 4364 would not work. Conceivably, >> one could use the OSPFv3 interface instance ID for this demuxing but = I >> don't think it makes any sense to try and solve this problem when no = one >> is putting a single interface in multiple VRFs. >> >> Thanks, >> Acee >> >> >>> >>> In other words, RFC 4364 allows assigning a single PE interface to >>> several VRFs. So shouldn't the statement in the draft at least be >>> qualified? >>> >>> Regards, >>> >>> Daniel >>> >>> -----Original Message----- >>> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On = Behalf >>> Of The IESG >>> Sent: Sunday, November 13, 2011 1:42 AM >>> To: IETF-Announce >>> Cc: l3vpn@ietf.org >>> Subject: Last Call: (OSPFv3 as = a >>> PE-CErouting protocol) to Proposed Standard >>> >>> >>> The IESG has received a request from the Layer 3 Virtual Private >>> Networks WG (l3vpn) to consider the following document: >>> - 'OSPFv3 as a PE-CE routing protocol' >>> as a Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and = solicits >>> final comments on this action. Please send substantive comments to = the >>> ietf@ietf.org mailing lists by 2011-12-04. Exceptionally, comments = may >>> be sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> =A0Many Service Providers (SPs) offer Virtual Private Network (VPN) >>> =A0services to their customers using a technique in which Customer = Edge >>> =A0(CE) routers are routing peers of Provider Edge (PE) routers. = =A0The >>> =A0Border Gateway Protocol (BGP) is used to distribute the = customer's >>> =A0routes across the provider's IP backbone network, and = Multiprotocol >>> =A0Label Switching (MPLS) is used to tunnel customer packets across = the >>> =A0provider's backbone. =A0This is known as a "BGP/MPLS IP VPN". >>> =A0Originally only IPv4 was supported and it was later extended to >>> =A0support IPv6 VPNs as well. =A0Extensions were later added for the >>> =A0support of the Open Shortest Path First protocol version 2 = (OSPFv2) >>> =A0as a PE-CE routing protocol for the IPv4 VPNs. =A0This document >> extends >>> =A0those specifications to support OSPF version 3 (OSPFv3) as a = PE-CE >>> =A0routing protocol. =A0The OSPFv3 PE-CE functionality is identical = to >>> =A0that of OSPFv2 except for the differences described in this >> document. >>> >>> >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >> > > From lufang@cisco.com Tue Nov 22 04:32: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 F1B5C21F8DAB for ; Tue, 22 Nov 2011 04:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.857 X-Spam-Level: X-Spam-Status: No, score=-3.857 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, 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 nlmRKCfrKgvd for ; Tue, 22 Nov 2011 04:32:19 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C5C5721F8B62 for ; Tue, 22 Nov 2011 04:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=6749; q=dns/txt; s=iport; t=1321965139; x=1323174739; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=bb+evkAfD/qmcODMDl/34TQiCdOy4gGzRGBl6o/pZG0=; b=IGcJ/XSLOGdTaYANlAXysEzQgssfefdBFHXW8WquIecUp7j9QOmHrq5N YHIcXeFvH7DlYdkRP8XUWz/o620chPDTmsjZPlQkISXpp4DYNLbEF77qi M9tMw8xXJBoJC90TU4qBNMLGqZTaWozhi5EXF6pewZ8i0uk72YnxHwVxp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwAAIiVy06tJXHB/2dsb2JhbABDhQGVNJAZgQWBcgEBAQQSAR08AggPBAIBBgIRAQMBAQEEBgYXAQQCAUUDBggCBAESCAEMBgeHa5YeAYxVCJF4gSyIHDdjBIgckW+MXw X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; d="scan'208";a="38134668" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 22 Nov 2011 12:32:17 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAMCWHOY021665; Tue, 22 Nov 2011 12:32:17 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, 22 Nov 2011 06:32:16 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: CVdM DCEi JABM JBuB JGTH JmdJ KYKO Lq2d N4b3 P3ZF Zw2c bEHM bYox d7e+ hX+6 h08u; 3; YgBlAG4AQABuAGkAdgBlAG4ALQBqAGUAbgBrAGkAbgBzAC4AYwBvAC4AdQBrADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAeAB1AHgAaQBhAG8AaAB1AEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Sosha1_v1; 7; {23BE7DF1-46B1-4002-844F-681109168627}; bAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Tue, 22 Nov 2011 12:32:04 GMT; UgBFADoAIABTAGwAaQBkAGUAcwAgAGYAbwByACAATAAzAFYAUABOACAAYQBnAGUAbgBkAGEAIABAACAASQBFAFQARgA4ADIA MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {23BE7DF1-46B1-4002-844F-681109168627} Content-class: urn:content-classes:message Subject: RE: Slides for L3VPN agenda @ IETF82 Date: Tue, 22 Nov 2011 06:32:04 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25075BA0EB@XMB-RCD-201.cisco.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides for L3VPN agenda @ IETF82 Thread-Index: AQHMpABi3hhbuKdOVE+mYh8wfPnXYpWuxW/BgAoCdOA= References: <66877CBF-2D37-4455-934D-4AD379BC54DE@niven-jenkins.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BE1F@szxeml525-mbs.china.huawei.com> From: "Luyuan Fang (lufang)" To: "Xuxiaohu" , "Ben Niven-Jenkins" , X-OriginalArrivalTime: 22 Nov 2011 12:32:16.0768 (UTC) FILETIME=[C511B800:01CCA912] 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, 22 Nov 2011 12:32:20 -0000 Xiaohu, Sorry for replying rather late. Before the vpn4dc session, I spent most = of my time talking with SP Cloud/DC operators to better understand their = challenges, needs, which were reflected in the slides, but only at the = very high level given the time we had. E.g. NTT folks who architect = their Cloud services provided very helpful input per today's reality. You posted a good question. We were asked by many in the last couple of = months on the similar.=20 The requests/needs for vpn4dc came from SPs, not from vendors.=20 Try to think why providers could not just use today's solution = everywhere, from network to DC, and be done with it. Why 'almost' no one = implemented it if it is practical?=20 I put the summarized answers in slide 5 of the vpn4dc deck presented = last week. It is not a complete list, but we were trying to recognize = the new problems. I have discussed/continuously modified the slides on = Problem portion and the Scope portion with most folks actively involved = to contribute the work, we had 20 some side meetings in the last few = weeks. What are the new DC related needs comparing with the existing provider = provisioned L3VPN solution environment (MPLS or IP)? - Multi-tenancy hosting in DC, provider offered cloud services through = shared infra. This does not exist before, SPs have been providing the network based = VPN, establishing the site connectivity for enterprises, that was good = enough. SP multi-tenancy cloud is new in cloud services, SPs' customers = demand for IP VPN into the public/private cloud, in addition in the VPN = for network. All segments need to be seamlessly connected end-to-end. - Scalability in the data center: large number of hosts, e.g. 100,000+ = hosts in single data center, each host supports 25 VMs. N* DC in single = provider. This kind of scale requirement was never before, may prevent one using = the existing technologies/solutions are they are.=20 - Cultural differences: DC operators mostly are not familiar with and = may not easily adopt the network protocols/solutions used by network = operators.=20 I removed this point in the final version try to focus on less points. = But this is the reality. Note DC operators here including the ones = within the SPs as well. - Mobility The regular VPNs do support remote access, but nothing close to this = level of dynamics/mobility, more work need to be done. - Security and authentication in the new environment We always support authentication as part of VPN solutions. This new = environment present new scenarios and new challenges to be addressed. You and Pedro, Lucy, and others had good discussions already, thanks.=20 I encourage everyone interested in working on the topic please talk to = the Cloud/DC operators as much as possible, including both SPs and other = Cloud providers. The problems exist, look like SPs and Content Providers = may have different focus. We need to support both. I'd prefer 1st = looking into individual real cases from the field to gain understanding; = 2nd, step back to see commonalities and differences from architecture = solution level among various end-users, technology solutions space = (l2/l3, vpn/non-vpn, management issues); 3rd, work on the solutions to = solve real problems, may well start with incremental enhancement, etc. = So 1st look into the woods, then pull back to look the forest, then go = back to woods again to work things out (w/ forest in mind).=20 Thanks to all for the contribution in every form, and thanks to all who = expressed their opinions in the lively session last week, especially = thanks to all who worked so hard in the last few months to get us here. I also encourage everyone to look into L2VPN/NOV3/SDNP lists, sessions, = in addition to VPN4DC (Marshall also sent reminder before L2VPN = session).=20 There are a lot of inter-connections, at both 'forest' and 'woods' = level. Thanks, Luyuan=20 > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Xuxiaohu > Sent: Tuesday, November 15, 2011 9:38 PM > To: Ben Niven-Jenkins; l3vpn@ietf.org mailing list > Subject: re: Slides for L3VPN agenda @ IETF82 >=20 > Hi, >=20 > I wonder whether the slides titled "VPN4DC slides" are the main slides > for discussion. >=20 > Yes, no one doubts that "layer 3 (IP or MPLS) VPN connectivity is in > IETF routing area". However, it seems to me that it's still not = clearly > explained in those slides why IP protocol extensions or new mechanism > for current solutions to DC is required. >=20 > If I remembered correctly, it is said in the BoF launch email that > there are at least two questions which need to be answered before > considering developing any new protocols. The first is whether the > current L3VPN approach can meet the requirement for DCN or DCI, and = the > second is wether the management tools are already enough to meet the > requirement. I think these two question will help us to explore more > deeply what the real problems are. >=20 > Best regards, > Xiaohu >=20 > ________________________________________ > =B7=A2=BC=FE=C8=CB: l3vpn-bounces@ietf.org [l3vpn-bounces@ietf.org] = =B4=FA=B1=ED Ben Niven- > Jenkins [ben@niven-jenkins.co.uk] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C216=C8=D5 9:37 > =B5=BD: l3vpn@ietf.org mailing list > =D6=F7=CC=E2: Slides for L3VPN agenda @ IETF82 >=20 > Colleagues, >=20 > The slides that will be used in the L3VPN session this afternoon are > now available from the meeting material page, i.e. here: >=20 > https://datatracker.ietf.org/meeting/82/materials.html >=20 > Ben >=20 > On 14 Nov 2011, at 11:50, Ben Niven-Jenkins wrote: >=20 > > Colleagues, > > > > I have uploaded a new version of the L3VPN/VPN4DC agenda which > includes the names of the people who will lead each topic. You can = find > it here: > > > > http://www.ietf.org/proceedings/82/agenda/l3vpn.txt > > > > The agenda is not arranged around specific drafts per-se but = Marshall > & I have asked the person leading each topic to co-ordinate with the > various draft authors to produce a consolidated view/presentation = which > they will present on behalf of the numerous authors/contributors. > > > > As a reminder: We have purposely not put time on the agenda to > present/discuss specific solution drafts as we would like the > discussion to be focussed on the problem/requirements posed by VPN4DC > and its applicability to IETF (including L3VPN). Discussion of = specific > solution proposals can happen at future meetings if the VPN4DC work is > adopted. > > > > Ben > > From ben@niven-jenkins.co.uk Wed Nov 23 09:23:09 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 8FEB521F8876 for ; Wed, 23 Nov 2011 09:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.111 X-Spam-Level: X-Spam-Status: No, score=-103.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_13=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 JVUFl37Iksld for ; Wed, 23 Nov 2011 09:23:09 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0958121F84B9 for ; Wed, 23 Nov 2011 09:23:09 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp65-239.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RTGXM-0001xV-2Z for l3vpn@ietf.org; Wed, 23 Nov 2011 17:23:08 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: IETF82 L3VPN minutes now available Date: Wed, 23 Nov 2011 17:23:07 +0000 Message-Id: To: "l3vpn@ietf.org 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: Wed, 23 Nov 2011 17:23:09 -0000 Colleagues, We just posted the draft minutes for the L3VPN/VPN4DC session at IETF = last week. You can view them here: http://www.ietf.org/proceedings/82/minutes/l3vpn.txt Thanks to Daniel King for scribing the session. Please send any corrections/omissions/etc to the chairs and/or the = mailing list. Thanks Ben From ccie15672@yahoo.com Fri Nov 25 03:00:49 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 C4F3E21F8B10 for ; Fri, 25 Nov 2011 03:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.733 X-Spam-Level: X-Spam-Status: No, score=0.733 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_50=0.001, 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 eRu1hacox4yz for ; Fri, 25 Nov 2011 03:00:49 -0800 (PST) Received: from nm32-vm6.bullet.mail.bf1.yahoo.com (nm32-vm6.bullet.mail.bf1.yahoo.com [72.30.239.142]) by ietfa.amsl.com (Postfix) with SMTP id BE8B221F86EC for ; Fri, 25 Nov 2011 03:00:48 -0800 (PST) Received: from [98.139.212.153] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 25 Nov 2011 11:00:43 -0000 Received: from [98.139.212.199] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 25 Nov 2011 11:00:43 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 25 Nov 2011 11:00:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 698384.66395.bm@omp1008.mail.bf1.yahoo.com Received: (qmail 13596 invoked by uid 60001); 25 Nov 2011 11:00:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1322218843; bh=TNYqmjFKje+qSr9Zdp/4b/eaA50bFU/mTXySqHL0Trk=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=pkTXZPJsI1bSBt08vA1HAUERv9D4aZyIGanlGoqG05p7W/YFKW3ujE9BDih3G6/pVH0Sw4gYdp0wtwG4q2yKO4M1Amfp7mO9weqer3gvkcOE3YWki13c2d2MoPb3oj5JajSFKVUvyIO8fXhr0/QQt9uSQ4VfUvPIuuzHcNHzTFs= 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=cRTf2Z59DuYj12rh40CKJ9WBweKoknZGwh0Fg6PtbdVrNBccUNfPEPpLg3MF5XlBWtlGnSKzc8o0VwWNsH+UPRhJJtuNE/GFI7lo8YR7KJ7QMhKgspvBmI4LdSAYcjGPPHqhBc7G4OVEqfv7elKC+cujVRAgfB7tCJV5029OMZw=; X-YMail-OSG: 9GV_KDgVM1nDy4xW424QijAw2CmnD1RRKqPYdB71nDkkr18 wsk8c1aC1UM.RyCpX9opA8YWcVwe.TACqv4O7LBU4hm0oY212RZYKtGu5ZQ2 UlAclg6evNlEWxSFhXRBkeR9rujmMB.kbmxI4jUX0QwZuviHBnsmuDFzy0K. q8pa3OPJWaEZdL2NNJgg.jTAQsAeP8yLJbMZFS7yTAwZTP_viJ673WJ34pRj iifKP3a8zFXdQVVsgoX0cDwqAG0KaZSX9FWNVMYRtHDms.7125uPIDnR88dW 7IjwASZCiOfUb1V2X.DNkyJZ8.D58uggJ9nTyzmGYqg.z8thnNBl4rC44whN GTwl.Ibdwf6SCWotHHi_LXKopBQJ6KwTl1D55HPD69UUn8ZwZJnqTP0Fdclm mzoeZIK_vvf8INaN.tudRn5_j2aGYoS5yW2AzVqSoVWqvND2TZHW6_shyRPk _ Received: from [76.194.43.66] by web161804.mail.bf1.yahoo.com via HTTP; Fri, 25 Nov 2011 03:00:43 PST X-Mailer: YahooMailWebService/0.8.115.325013 References: Message-ID: <1322218843.87049.YahooMailNeo@web161804.mail.bf1.yahoo.com> Date: Fri, 25 Nov 2011 03:00:43 -0800 (PST) From: Derick Winkworth Subject: Re: IETF82 L3VPN minutes now available To: Ben Niven-Jenkins , "l3vpn@ietf.org mailing list" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1565830678-556876183-1322218843=:87049" 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: Fri, 25 Nov 2011 11:00:49 -0000 --1565830678-556876183-1322218843=:87049 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All:=0A=0A(a) I understand that MPLS L3VPN is not used, favored, or even ap= proved of, by many folks. =A0=0A=0A=0AThis does not change the fact that MP= LS is a widely used technology that solves problems and generates revenue f= or organizations. =A0Its not unreasonable to seek to integrate MPLS VPNs wi= th virtual-server technologies. =A0It *is* unreasonable to say that MPLS sh= ouldn't be part of the discussion. =A0These networks aren't going away and = the driver behind the VPN4DC discussion is that many customers are asking f= or this type of integration (between VMs and MPLS VPN instances). =A0=0A=0A= (b) I also understand that some people have scale problems so great that it= amounts to a problem that 99% of the world does not have. =A0=0A=0ANot eve= ryone has 2 or 3 million VMs in a datacenter and the requirement to migrate= 200k of them at a time. =A0 I think that trying to come up with a one-size= -fits-all solution that scales this large for those cases is not reasonable= . =A0MPLS is perfectly acceptable for smaller numbers of VMs/tenants.=0A=0A= (c) Some people think that this amounts to something like private cloud and= this is the wrong direction (on principle, or philosophically) for the tec= hnology industry to go in. =A0We should be pushing towards public-cloud sol= utions that use IPSec VPN or vCider. =A0=0A=0AI don't think this objection = is relevant to this discussion. =A0I think this amounts to religion. =A0I t= hink also this objection might have something to do with the business some = people are in... the business of being a public cloud provider. =A0A standa= rdized protocol that would allow VMs to be automatically stitched up via so= me kind of path isolation to a VRF or VPLS instance would represent a compe= titive threat to existing public-cloud services.=0A=0A(d) Some people think= (on principle, or philosophically) that we should start solutioning everyt= hing with SDN. =A0=0A=0AI strongly disagree. =A0SDN is quite fascinating, b= ut things like OpenFlow and Openstack are tools. =A0They are not solutions.= =A0Some of us *have* used a collection of APIs already to automate the pro= visioning we are speaking of. =A0As soon as you change any vendor in the ch= ain, you have to start re-coding against a new API (assuming such an API is= even exposed). =A0It sure would be nice if there was some kind of standard= s body that we could work within the framework of to create some kind of st= andard. =A0These APIs do not directly address the problem we are trying to = solve.=0A=0A=0A----=0A=0A1. There are potentially [enterprise <-> SP] proto= cols that do things like signal for the creation of a VM or change operatin= g characteristics of the VM or storage associated with the VM. =A0These pro= tocols could be generalized and should probably be XML based.=0A=0A2. Then = there are protocols internal to the MPLS SP's DC that stitch up the VM to a= n L3VPN/L2VPN instance. =A0These exist further down the workflow from #1. = =A0I think this is a specific problem requiring specific mechanisms separat= e from the ones mentioned in the previous paragraph. =A0It could also be XM= L based, but I could see it being otherwise based on some of the drafts alr= eady submitted that address this.=0A=0APerhaps the scope of VPN4DC should b= e limited to #2 and exclude #1? =A0=0A=0ADerick=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A________________________________=0A From: Ben Niven= -Jenkins =0ATo: "l3vpn@ietf.org mailing list" =0ASent: Wednesday, November 23, 2011 11:23 AM=0ASubject: IETF= 82 L3VPN minutes now available=0A =0AColleagues,=0A=0AWe just posted the dr= aft minutes for the L3VPN/VPN4DC session at IETF last week.=0A=0AYou can vi= ew them here:=0A=0Ahttp://www.ietf.org/proceedings/82/minutes/l3vpn.txt=0A= =0AThanks to Daniel King for scribing the session.=0A=0APlease send any cor= rections/omissions/etc to the chairs and/or the mailing list.=0A=0A=0AThank= s=0ABen --1565830678-556876183-1322218843=:87049 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All:

(a) I understand that MPLS L3VPN is not used, = favored, or even approved of, by many folks.  

This does not change the fact that MPLS is a widely used technology t= hat solves problems and generates revenue for organizations.  Its not = unreasonable to seek to integrate MPLS VPNs with virtual-server technologie= s.  It *is* unreasonable to say that MPLS shouldn't be part of the dis= cussion.  These networks aren't going away and the driver behind the V= PN4DC discussion is that many customers are asking for this type of integra= tion (between VMs and MPLS VPN instances).  

= (b) I also understand that some people have scale problems so great that it= amounts to a problem that 99% of the world does not have.  

Not everyone has 2 or 3 million VMs in a d= atacenter and the requirement to migrate 200k of them at a time.   I t= hink that trying to come up with a one-size-fits-all solution that scales t= his large for those cases is not reasonable.  MPLS is perfectly accept= able for smaller numbers of VMs/tenants.

(c) Some = people think that this amounts to something like private cloud and this is = the wrong direction (on principle, or philosophically) for the technology i= ndustry to go in.  We should be pushing towards public-cloud solutions= that use IPSec VPN or vCider.  

I don't thin= k this objection is relevant to this discussion.  I think this amounts= to religion.  I think also this objection might have something to do = with the business some people are in... the business of being a public clou= d provider.  A standardized protocol that would allow VMs to be automatically stitched up via some kind of path isolation to a VRF or VPLS= instance would represent a competitive threat to existing public-cloud ser= vices.

(d) Some people think (on principle, or phi= losophically) that we should start solutioning everything with SDN.  <= /div>

I strongly disagree.  SDN is quite fascinatin= g, but things like OpenFlow and Openstack are tools.  They are not sol= utions.  Some of us *have* used a collection of APIs already to automa= te the provisioning we are speaking of.  As soon as you change any ven= dor in the chain, you have to start re-coding against a new API (assuming s= uch an API is even exposed).  It sure would be nice if there was some = kind of standards body that we could work within the framework of to create= some kind of standard.  These APIs do not directly address the proble= m we are trying to solve.


----

1. There are potentially [enterprise <-> SP] protocols that do thi= ngs like signal for the creation of a VM or change operating characteristic= s of the VM or storage associated with the VM.  These protocols could = be generalized and should probably be XML based.

2= . Then there are protocols internal to the MPLS SP's DC that stitch up the = VM to an L3VPN/L2VPN instance.  These exist further down the workflow = from #1.  I think this is a specific problem requiring specific mechan= isms separate from the ones mentioned in the previous paragraph.  It c= ould also be XML based, but I could see it being otherwise based on some of= the drafts already submitted that address this.

P= erhaps the scope of VPN4DC should be limited to #2 and exclude #1?  

Derick


=





=





=



From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
<= b>To: "l3vpn@ietf.org mailing= list" <l3vpn@ietf.org>
Se= nt: Wednesday, November 23, 2011 11:23 AM
Subject: IETF82 L3VPN minutes now available<= br>
=0AColleagues,

We just posted the draft minutes for = the L3VPN/VPN4DC session at IETF last week.

You can view them here:<= br>
http://www.ietf.org/proceedings/82/minutes/l3vpn.txt

Thanks t= o Daniel King for scribing the session.

Please send any corrections/= omissions/etc to the chairs and/or the mailing list.


Thanks
B= en



--1565830678-556876183-1322218843=:87049--