Subject: Final L3VPN agenda @ IETF82

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 14 Nov 2011 11:50:13 +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 <[email-masked]>
Date: Mon, 14 Nov 2011 14:46:03 +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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ben Niven-Jenkins
> Sent: Monday, November 14, 2011 7:50 PM
> To: [email-masked] 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:
> 
> 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 <[email-masked]>
Date: Wed, 16 Nov 2011 01:37:43 +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

---

From: Giles Heron <[email-masked]>
Date: Wed, 16 Nov 2011 02:10:54 +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" <[email-masked]> 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:
> 
>> 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:
>> 
>> 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.
>> 
>> 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 <[email-masked]>
Date: Wed, 16 Nov 2011 02:37:53 +0000

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. I think these two question will help us to explore more deeply what the real problems are.

Best regards,
Xiaohu

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Ben Niven-Jenkins [[email-masked]]
发送时间: 2011年11月16日 9:37
到: [email-masked] mailing list
主题: Slides for L3VPN agenda @ IETF82

Colleagues,

Ben

---

From: Pedro Marques <[email-masked]>
Date: Tue, 15 Nov 2011 21:33:03 -0800

Xuxiaohu,

2011/11/15 Xuxiaohu <[email-masked]>:
> 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...

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

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 16 Nov 2011 05:56:57 +0000

Pedro,
________________________________________
发件人: Pedro Marques [[email-masked]]
发送时间: 2011年11月16日 13:33
到: Xuxiaohu
Cc: Ben Niven-Jenkins; [email-masked] mailing list
主题: Re: Slides for L3VPN agenda @ IETF82

Xuxiaohu,

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 Nov 2011 07:05:06 +0100

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.

> 2011/11/15 Xuxiaohu<[email-masked]>:
>> Hi,
>>
>>> 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.
>>>

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 16 Nov 2011 06:12:37 +0000

Robert,

It's absolutely OK that a single solution could address two problems. I just want to identify which is the problem that still has no corresponding solution.

Best regards,
Xiaohu
________________________________________
发件人: Robert Raszuk [[email-masked]]
发送时间: 2011年11月16日 14:05
到: Xuxiaohu
Cc: Pedro Marques; [email-masked] mailing list
主题: Re: Slides for L3VPN agenda @ IETF82

Xuxiaohu,

Rgs,
R.

---

From: Pedro Marques <[email-masked]>
Date: Wed, 16 Nov 2011 08:55:03 -0800

Xuxiaohu,

2011/11/15 Xuxiaohu <[email-masked]>:
> <XXH> 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.

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.

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

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: Lucy yong <[email-masked]>
Date: Thu, 17 Nov 2011 02:39:38 +0000

Snip

[[LY]] It is my understanding that problem A is also in the scope of VPN4DC. SP clearly states that management plane solution is not sufficient to support the cloud services and seeks some protocol enhancement for supporting multi-tenant over a shared DC infra, mobility, and security.

It is not reasonable to assume SP management system to interwork with many different DC providers who may have their own management systems to achieve this.

Regards,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Thu, 17 Nov 2011 02:51:07 +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 problems.

Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pedro Marques
Sent: Wednesday, November 16, 2011 10:55 AM
To: Xuxiaohu
Cc: [email-masked] mailing list
Subject: Re: Slides for L3VPN agenda @ IETF82

Xuxiaohu,

thank you,
  Pedro.

---

From: Pedro Marques <[email-masked]>
Date: Thu, 17 Nov 2011 09:13:47 -0800

Lucy,

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

The issues you mention relate to the implementation and APIs of
orchestration systems. Not to connectivity. They do not belong to the
IETF.

---

From: Lucy yong <[email-masked]>
Date: Fri, 18 Nov 2011 00:28:47 +0000

Petro,

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

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.

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. 
[[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 understanding, there are different orchestration systems for VM and networking. Whether interworking between orchestration systems or interworking between networks and VMs to achieve this is the subject. 

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 routes for the VMs that explicitly map to the VPN, and only forward the packets from these VMs to the VPN. 

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 network based solution, which belongs to IETF.

Regards,
Lucy

---

From: Pedro Marques <[email-masked]>
Date: Thu, 17 Nov 2011 17:43:34 -0800

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 understanding, there are different orchestration s…

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.

> [[LY]] This implies that the VPN access at this DC only populates the routes for the VMs that explicitly map to the VPN, and only forward the packets 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.

> [[LY]] there are different ways to implement this. We here work on the network 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: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 22 Nov 2011 06:32:04 -0600

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. 
The requests/needs for vpn4dc came from SPs, not from vendors. 
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? 

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. 
- Cultural differences: DC operators mostly are not familiar with and may not easily adopt the network protocols/solutions used by network operators. 
	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. 

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

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). 
There are a lot of inter-connections, at both 'forest' and 'woods' level.

Thanks,
Luyuan 

> Of Xuxiaohu
> Sent: Tuesday, November 15, 2011 9:38 PM
> To: Ben Niven-Jenkins; [email-masked] mailing list
> Subject: re: Slides for L3VPN agenda @ IETF82
> 
> Hi,
> 
> 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. I think these two question will help us to explore more
> deeply what the real problems are.
> 
> Best regards,
> Xiaohu
> 
> The slides that will be used in the L3VPN session this afternoon are
> now available from the meeting material page, i.e. here:
> 
> > 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:
> >
> > 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