Subject: Preliminary L3VPN/VPN4DC agenda @ IETF82

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 2 Nov 2011 18:01:21 +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 <[email-masked]>
Date: Wed, 02 Nov 2011 18:51:27 +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: [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,

Ben

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 03 Nov 2011 02:55:45 +0000

Who will lead the talk for each topic? 

Linda

> 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: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 2 Nov 2011 23:41:21 -0500

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

> 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
> 
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Ben Niven-Jenkins
> > Marshall & I have uploaded a preliminary L3VPN/VPN4DC agenda for
IETF
> > 82 in Taipei. You can find it here:
> >

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 03 Nov 2011 16:30:16 +0000

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

> 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

---

From: Pedro Marques <[email-masked]>
Date: Thu, 3 Nov 2011 10:22:52 -0700

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 <[email-masked]> wrote:
> 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.
>
>
> 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
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 03 Nov 2011 18:42:53 +0100

Linda,

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

> 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
>> 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
>>>
>>>> -----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
>>>> At the moment the agenda is a little vague because we are
>>>> still
>>> working
>>>> 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

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 03 Nov 2011 19:17:40 +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 

> From: Robert Raszuk [mailto:[email-masked]]
> 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,
> 
>  > for the following reasons:
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 03 Nov 2011 19:04:58 +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

> From: Pedro Marques [mailto:[email-masked]]
> Sent: Thursday, November 03, 2011 12:23 PM
> To: Linda Dunbar
> hosts in
> valuable
> in

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 03 Nov 2011 20:22:17 +0100

> 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: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 3 Nov 2011 14:25:17 -0500

Your definition of L3VPN here?

- BGP/MPLS VPN (RFC 4364)?
- The current L3VPN WG scope?
- any ip (layer 3) VPN technologies?

Luyuan

> From: Linda Dunbar [mailto:[email-masked]]
> Sent: Thursday, November 03, 2011 3:05 PM
> To: Pedro Marques
> 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.
> 
> > On Thu, Nov 3, 2011 at 9:30 AM, Linda Dunbar
> <[email-masked]>
> > wrote:
> > > public data centers" which clients choose. If a VPN client has
> leased
> > some
> > > Today Amazon already allows any hosts to be connected to their
> chosen
> > sites
> other
> discuss
> present/discuss
> > >> > > specific solution drafts as we would like the discussion to
be

---

From: Pedro Marques <[email-masked]>
Date: Thu, 3 Nov 2011 13:13:00 -0700

Linda,

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

> 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 <[email-masked]>
Date: Thu, 03 Nov 2011 20:28:18 +0000

I mean RFC4364 based L3VPN. 

For VLAN based VPN, I would categorize it to L2 based solution. 

Linda

> Sent: Thursday, November 03, 2011 2:25 PM
> To: Linda Dunbar; Pedro Marques
> Cc: Ben Niven-Jenkins; L3VPN WG mailing list
> > > > any public data centers (e.g. Amazon' EC2) to hosts'
> corresponding
> > > VPNs? Or
> > > >
> > > >> gather feedback/input from the list, as the first step of
> meeting
> > > prep.
> > > >>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 03 Nov 2011 21:15:39 +0000

What do you mean by getting rid of PEs? PE represents the ownership, e.g. VPN provider owns the PE device. 

Linda

> Sent: Thursday, November 03, 2011 2:22 PM
> To: Linda Dunbar
> Cc: L3VPN WG mailing list

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 03 Nov 2011 23:20:07 +0100

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.

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 3 Nov 2011 17:32:26 -0500

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

> Sent: Thursday, November 03, 2011 4:28 PM
> To: Luyuan Fang (lufang); Pedro Marques
> > > 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
> > >
> > > > assumes that there are multiple enterprise VPN networks
> connecting
> > to
> > > > datacenter. Otherwise we are talking of a CE attachment circuit
> and
> > > it
> > > > > extend their VPN with computing service? In this model,
> customers
> > > > (i.e. VPN
> > > > > clients) see their computing resources being offloaded to
their
> > > VPN.
> > > > > 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
> > > > > computing resource from a data center, the easiest way to
> connect
> > > > them
> > > > >> problem statement drafts to come up with a combined view to
be
> > > > >> presented
> > > > >> in Taipei meeting. The requirements drafts would be treated
in
> > the
> > > > >> Though there would be no individual vpn4dc drafts
> presentations
> > as
> > > > in
> > > > >> normal WG meetings, we welcome input on all three subjects
> from
> > > > authors
> > > > >> soon, prefer we meet when Ning is back to office in a couple
> of
> > > days.
> > > > >> > From: [email-masked]
[mailto:[email-masked]]
> > On
> > > > >> > > From: [email-masked] [mailto:l3vpn-
> [email-masked]]
> > > On
> > > > >> > Behalf
> > > > >> > > Of Ben Niven-Jenkins
> > > > >> > > Marshall & I have uploaded a preliminary L3VPN/VPN4DC
> agenda
> > > for
> > > > >> IETF

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 03 Nov 2011 22:50:26 +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 

> Sent: Thursday, November 03, 2011 5:32 PM
> > > > > network interconnects with a public data-center. Irrespective
> of
> > > the
> > > > > >> In fact, the intent of vpn4dc Q&A I sent a couple of days
> ago
> > > was
> > > > to

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 3 Nov 2011 18:07:49 -0500

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. 
I'll stop this mail for now.

Luyuan

> Sent: Thursday, November 03, 2011 6:50 PM
> 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
> 
> 
> 
> 
> > > > > 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
> > > > > > Cc: Luyuan Fang (lufang); Ben Niven-Jenkins; L3VPN WG
mailing
> > > list
> > > > > > It appears to me that you are discussing business models
> rather
> > > > than
> > > > > > the underlying technology. At least from my view point, when
> it
> > > > comes
> > > > > > The issue only becomes relevant to the l3vpn working group
if
> > one
> > > > > > > 1. Is VPN4DC to create mechanisms which make it possible
to
> > > > > > > Model #2 gives VPN service providers an unique advantage
of
> > > > binding
> > > > > > valuable
> > > > > > > VPN services with virtual computing services, making it
> more
> > > > > > difficult for
> > > > > > >> Ben suggested that Ning and myself to work with
co-authors
> > > > > > >> similar fashion. I plan to put gap analysis together with
> pb
> > > > > > statement
> > > > > > >> drafts.
> > > > > > >>
> > > > > > >> > > specific solution drafts as we would like the
> discussion
> > > to
> > > > be
> > > > > > >> > focussed

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 04 Nov 2011 03:54:18 +0000

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

> 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

---

From: Pedro Marques <[email-masked]>
Date: Thu, 3 Nov 2011 21:13:44 -0700

Xiaohu,

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

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: "Luyuan Fang (lufang)" <[email-masked]>
Date: Fri, 4 Nov 2011 00:20:40 -0500

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

> Of Pedro Marques
> Sent: Friday, November 04, 2011 12:14 AM
> To: Xuxiaohu
> Subject: Re: Application of L3VPN for DCI//re: Preliminary
L3VPN/VPN4DC
> agenda@ IETF82
> > 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.
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 04 Nov 2011 06:00:47 +0000

Luyuan,

> -----邮件原件-----
> 发件人: Luyuan Fang (lufang) [mailto:[email-masked]]
> 发送时间: 2011年11月4日 13:21
> 收件人: Pedro Marques; Xuxiaohu
> 抄送: L3VPN WG mailing list
> 主题: RE: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC
> agenda@ IETF82
> 
> Xiaohu,
> 

Oh, sorry, it's my misunderstanding:)

> Assume your draft is with l2vpn WG, as you called out "IP only L2VPN

Virtual Subnet is an approach for subnet extension by the use of L3VPN or ARP proxy technologies. To some extension, subnet extension could be understood as an IP-only L2VPN service due to the following two reasons:1) from the perspective of CE hosts, subnet extension makes them act as if they are located within the same L2VPN instance:2) only IP traffic is allowed to be transported in Virtual Subnet.
 
Since it's an application of L3VPN protocol as a data center interconnection solution, I think it should be talked at L3VPN WG. 

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 04 Nov 2011 06:37:39 +0000

Hi Pedro,

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Pedro
> Marques
> 发送时间: 2011年11月4日 12:14
> 收件人: Xuxiaohu
> 主题: Re: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC agenda
> @ IETF82
> 
> Xiaohu,
> 
> > 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.
> 

It's really a subnet which is extended across data centers from the hosts' points of view. Virtual Subnet is an DCI approach which is based on the pre-requirement that it should be transparent to the hosts(i.e., servers/VMs) and the data center network, in other words, it doesn't require any change to these data center internal elements, especially hosts. Of course, if you want to extend the L3VPN PE functions to the hosts within the cloud data centers, it's another thing.

> of subnets is not helpful, the concept is just not applicable.

I think your approach works. However, each approach either host-based or network-based has its own pros and cons. 

> suffering. There is no reason to care about the mac address of the

In fact, in the Virtual Subnet, VMs in one data center don't care about the real MAC addresses of the remote VMs in other data center due to the usage of ARP proxy:) 

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 04 Nov 2011 07:06:06 +0000

> 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 both l3vpn-end-system proposal and Virtual Subnet proposal are using L3VPN to exchange host routes while the major difference is that your proposal expects to extend the PE functions to the hosts and my proposal intends to retain the PE functions on the routers. It's interesting:)

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 04 Nov 2011 08:37:08 +0000

Pedro,

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Xuxiaohu
> 发送时间: 2011年11月4日 15:06
> 收件人: Pedro Marques
> 主题: 答复: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC
> agenda @ IETF82
> 
> 
> > -----邮件原件-----
> After reading your l3vpn-end-system proposal at a glance, I felt that both
> l3vpn-end-system proposal and Virtual Subnet proposal are using L3VPN to
> exchange host routes while the major difference is that your proposal expects
> to extend the PE functions to the hosts and my proposal intends to retain the
> PE functions on the routers. It's interesting:)

By the way, have you considered the scenario where servers in one data center site are upgraded to support l3vpn-end-system proposal while servers in the other data center site (e.g., Layer2 data center) are not? How to support VM mobility across these two data centers?

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 04 Nov 2011 09:12:04 +0000

> 发件人: Xuxiaohu
> 发送时间: 2011年11月4日 15:20
> 收件人: 'Pedro Marques'
> Pedro

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 these two proposals from the perspective of effect. 

Best regards,
Xiaohu

---

From: Pedro Marques <[email-masked]>
Date: Fri, 4 Nov 2011 09:15:09 -0700

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.

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Fri, 4 Nov 2011 14:16:19 -0400

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: Derick Winkworth <[email-masked]>
Date: Fri, 4 Nov 2011 19:08:04 -0700 (PDT)

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" <[email-masked]>
To: "[email-masked]" <[email-masked]>; Linda Dunbar <[email-masked]>
Cc: L3VPN WG mailing list <[email-masked]>
Sent: Friday, November 4, 2011 1:16 PM
Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82

Hi,

Thanks,
Nabil

---

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

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

> Of Bitar, Nabil N
> Sent: Friday, November 04, 2011 2:16 PM
> To: [email-masked]; Linda Dunbar

---

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

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

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

 

To: "[email-masked]" <[email-masked]>; Linda Dunbar

Hi,
same, but it is over-restrictive to assume that they are and if one
makes

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: "Luyuan Fang (lufang)" <[email-masked]>
Date: Sat, 5 Nov 2011 01:26:35 -0500

Sorry about my typo, Nabil.

> Of Luyuan Fang (lufang)
> Sent: Saturday, November 05, 2011 1:34 AM
> > >toolkit of choice could be triggered to add/delete a site, a user
or
> a

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Mon, 7 Nov 2011 08:31:18 -0500

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 concluded at all.

Thanks,
Nabil

From: Derick Winkworth <[email-masked]<mailto:[email-masked]>>
Reply-To: Derick Winkworth <[email-masked]<mailto:[email-masked]>>
Date: Fri, 4 Nov 2011 22:08:04 -0400
To: "Bitar, Nabil N" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: L3VPN WG mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82

________________________________
From: "Bitar, Nabil N" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: L3VPN WG mailing list <[email-masked]<mailto:[email-masked]>>
Sent: Friday, November 4, 2011 1:16 PM
Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82

Hi,

Thanks,
Nabil

On 11/3/11 1:42 PM, "Robert Raszuk" <[email-masked]<mailto:[email-masked]>> wrote:

>>> [mailto:[email-masked]<mailto:[email-masked]>] Sent: Wednesday, November 02, 2011 11:41
>>>> -----Original Message----- From: [email-masked]<mailto:[email-masked]>
>>>> [mailto:[email-masked]<mailto:[email-masked]>] On
>>> Behalf
>>>>> -----Original Message----- From: [email-masked]<mailto:[email-masked]>
>>>>> [mailto:[email-masked]<mailto:[email-masked]>] On
>>>> Behalf

---

From: Derick Winkworth <[email-masked]>
Date: Mon, 7 Nov 2011 05:42:19 -0800 (PST)

I hit reply on the wrong e-mail.  Sorry, Nabil.

________________________________
From: "Bitar, Nabil N" <[email-masked]>
To: Derick Winkworth <[email-masked]>; "Bitar, Nabil N" <[email-masked]>; "[email-masked]" <[email-masked]>; Linda Dunbar <[email-masked]>
Cc: L3VPN WG mailing list <[email-masked]>
Sent: Monday, November 7, 2011 7:31 AM
Subject: Re: Preliminary L3VPN/VPN4DC agenda @ IETF82

Derick,

Thanks,
Nabil 
From:  Derick Winkworth <[email-masked]>
Reply-To:  Derick Winkworth <[email-masked]>
Date:  Fri, 4 Nov 2011 22:08:04 -0400
To:  "Bitar, Nabil N" <[email-masked]>, "[email-masked]" <[email-masked]>, Linda Dunbar <[email-masked]>
Cc:  L3VPN WG mailing list <[email-masked]>
Subject:  Re: Preliminary L3VPN/VPN4DC agenda @ IETF82

Hi,

connectivity within the data
 center can also be a BGP-MPLS VPN or an IPsec

Thanks,
Nabil

On 11/3/11 1:42 PM, "Robert Raszuk" <[email-masked]> wrote:

>> to extend
 their VPN with computing service? In this model, customers
>> valuable VPN services
 with virtual computing services,  making it
>>>>> Of Ben
 Niven-Jenkins Sent: Wednesday, November 02, 2011 1:01

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 08 Nov 2011 03:58:40 +0000

> -----邮件原件-----
> 发件人: Pedro Marques [mailto:[email-masked]]
> 发送时间: 2011年11月5日 0:15
> 收件人: Xuxiaohu
> 主题: Re: 答复: Application of L3VPN for DCI//re: Preliminary L3VPN/VPN4DC
> agenda @ IETF82
> 
> Xiaohu,

Pedro,

I agree that scalability is a much important requirement for data center interconnect and I believe host route based L3VPN solution is a good option for data center interconnection especially when we are considering path optimization for inter-subnet traffic. However, I wonder whether it is practical to assume all data centers to be connected, especially those existing enterprise data centers, are ready to support the L3VPN PE functions on end systems. 

Hence I believe we also need a host route based L3VPN solution which doesn't require extending the PE functions to end-systems (e.g., virtual subnet) in order to allow those existing enterprise data centers which use layer2 network technologies (e.g., STP, SPB and VPLS etc.) to be connected to the provider's cloud data centers. In this way, those enterprise data centers could be connected to the network-based L3VPN PE routers without requiring upgrading their servers, while the provider's data centers are able to support the l3vpn-end-system.

Best regards,
Xiaohu
 
> > 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 these
> two proposals from the perspective of effect.
> >
> > Best regards,
> > Xiaohu
> >>