RE: Preliminary L3VPN/VPN4DC agenda @ IETF82

["Luyuan Fang (lufang)" <[e-mail]>]

Derick,

 

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. 

 

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Derick Winkworth
Sent: Friday, November 04, 2011 10:08 PM
To: Bitar, Nabil N; [e-mail]; 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...

 

 

 

 

 

________________________________

From: "Bitar, Nabil N" <[e-mail]>
To: "[e-mail]" <[e-mail]>; Linda Dunbar
<[e-mail]>
Cc: L3VPN WG mailing list <[e-mail]>
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" <[e-mail]> 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:[e-mail]] 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: [e-mail]
>>>> [mailto:[e-mail]] 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: [e-mail]
>>>>> [mailto:[e-mail]] 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
>>>>>
>>
>>
>>