Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82

From: Lizhong Jin <[email-masked]>
Date: Sat, 5 Nov 2011 11:03:50 +0800

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" <[email-masked]>
> To: "[email-masked]" <[email-masked]>, Linda Dunbar
>        <[email-masked]>
> Cc: L3VPN WG mailing list <[email-masked]>
> Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82
> Message-ID: <[email-masked]>
> 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" <[email-masked]> 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:[email-masked]] 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: [email-masked]
> >>>> [mailto:[email-masked]] 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: [email-masked]
> >>>>> [mailto:[email-masked]] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l3vpn
>
>
> End of L3VPN Digest, Vol 89, Issue 17
> *************************************
>

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Sat, 5 Nov 2011 00:38:01 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Lizhong Jin
Sent: Friday, November 04, 2011 11:04 PM
To: [email-masked]
Cc: [email-masked]
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" <[email-masked]>
	To: "[email-masked]" <[email-masked]>, Linda Dunbar
	       <[email-masked]>
	Cc: L3VPN WG mailing list <[email-masked]>
	Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82
	Message-ID: <[email-masked]
<mailto:[email-masked]> >
	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

---

From: Lizhong Jin <[email-masked]>
Date: Sat, 5 Nov 2011 21:51:03 +0800

Luyuan,
Yes, agree with the VPN4DC scope, to focus only on L3VPN.

Regards
Lizhong

2011/11/5 Luyuan Fang (lufang) <[email-masked]>

>  Lizhong,****
> ** **
> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Lizhong Jin
> *Sent:* Friday, November 04, 2011 11:04 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
>
> *Subject:* Re: Preliminary L3VPN/VPN4DC agenda @ IETF82****
>
>   ** **
>
> Could anyone from cloud provider give some information?****
>
>  ****
>
> Thanks****
>
> Lizhong****
>
>  ****
>
>  ****
>
> *****************************************
>
> ** **
>