Subject: FWD: Call for Participation: Using IP Overlays to provide L2 Virtualization

From: Thomas Narten <[email-masked]>
Date: Mon, 03 Oct 2011 16:26:32 -0400

FYI. It has been suggested that this work area overlaps with L2VPN's
charter. That was not my starting point, but I also haven't followed
this WG in recent years.

In any case, I'd welcome feedback and a sense for whether this is
in-scope for this WG.

Thomas

------- Forwarded Message

From: Thomas Narten <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 30 Sep 2011 20:03:34 -0400
Subject: Call for Participation: Using IP Overlays to provide L2 Virtualization

A new mailing list has been set up to explore possible IETF work in
the area of providing L2 network virtualization service over an L3
(IP) overlay network.

As background, there are a number of drafts that relate to this area,
including:

    http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-00
    http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-00
    http://tools.ietf.org/html/draft-wkumari-dcops-l3-vmmobility-00

I've put together a first-cut at a problem statement that focuses on
the issues and potential work areas, without getting into solution
specifics.  See:

    http://tools.ietf.org/html/draft-narten-nvo3-overlay-problem-statement-00.txt
    
There have also been some related vendor announcements and
presentations as well (these are ones I happen to know of, there are
surely others). For example:

     http://blogs.cisco.com/datacenter/introducing-vxlan/

     http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-685115.html

     http://blogs.vmware.com/console/2011/08/towards-virtualized-networking-for-the-cloud.html
     
     http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-442T

The list is called nvo3, for "Network Virtualization Over L3", aka
N-Vee-Oh-3 (we'll see how well that acronym sticks...).

I've put in a formal request to hold a BOF in Taipai, so we can
explore whether it makes sense to form a WG in this area.

Subscription information for the mailing list can be found at

     List address: [email-masked]
     Archive: http://www.ietf.org/mail-archive/web/nvo3/current/maillist.html
     To subscribe: https://www.ietf.org/mailman/listinfo/nvo3

I look forward to your participation!

Thomas

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

------- End of Forwarded Message

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 3 Oct 2011 16:51:05 -0500

Thomas,

The L2VPN charter was modified a few months ago to include work related to DC/Cloud networking. There were a number of proposed requirements and solution initiatives that prompted the change - see drafts on EVPN, PBB-EVPN (requirements, solutions) and VM mobility. 

The solution drafts you list below are about L2 over some sort of IP tunnels. IP PSN is in the charter for L2VPN and the working group has accumulated a lot of experience in my opinion dealing with all the VPN/multi-tenancy components, including L2/IP solution. Any DC related solutions need to also interoperate with existing VPNs as Cloud Provider want to deliver Cloud Services to VPN customers. 

So I think these initiatives are in L2VPN scope and should be discussed here to better understand what are the deltas from existing VPN technologies. 

Florin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Monday, October 03, 2011 1:27 PM
To: [email-masked]
Subject: FWD: Call for Participation: Using IP Overlays to provide L2 Virtualization

Thomas

    

     

Thomas

---

From: Benson Schliesser <[email-masked]>
Date: Mon, 3 Oct 2011 17:43:44 -0500

I don't disagree with Florin's comments, but I'm not certain the NVO3 initiative is best-served within L2VPN's scope. The L2VPN charter says that "Layer-2 VPNs comprise" an enumerated list of topics. While there may be overlap, it seems that NVO3 would deal with a somewhat new topic.  Whether this is best done through a re-charter of L2VPN or establishment of a new WG, is not clear to me - but for the sake of argument here are a couple considerations:

For starters, the current L2VPN charter focuses on "provider-provisioned" which may not apply to NVO3.  This is admittedly a vague line of division, but it may be useful in thinking about the distinction between these areas of work.

More specifically, while NVO3 solutions might emulate native L2 service, they may in fact be significantly different in capability and operation.  I'd suggest that, for example, the mechanisms by which address resolution happen might be very different - both within an overlay, as well as between the overlay and underlying PSN. This might constrain the types of traffic that can be carried by the overlay. Or maybe not. This is something that NVO3 would need to investigate.

Cheers,
-Benson

---

From: Thomas Narten <[email-masked]>
Date: Mon, 03 Oct 2011 19:58:47 -0400

"Balus, Florin Stelian (Florin)" <[email-masked]> writes:

> The L2VPN charter was modified a few months ago to include work
>  related to DC/Cloud networking. There were a number of proposed
>  requirements and solution initiatives that prompted the change -
>  see drafts on EVPN, PBB-EVPN (requirements, solutions) and VM
>  mobility.

Can you list which drafts these are?

For the EVPN, that would presumably be:

draft-raggarwa-sajassi-l2vpn-evpn-04.txt
draft-sajassi-l2vpn-evpn-segment-route-00.txt
draft-sajassi-l2vpn-pbb-evpn-02.txt
draft-sajassi-raggarwa-l2vpn-evpn-req-01.txt

What drafts relate to VM mobility?

> The solution drafts you list below are about L2 over some sort of IP
> tunnels. IP PSN is in the charter for L2VPN and the working group
> has accumulated a lot of experience in my opinion dealing with all
> the VPN/multi-tenancy components, including L2/IP solution. Any DC
> related solutions need to also interoperate with existing VPNs as
> Cloud Provider want to deliver Cloud Services to VPN customers.

Maybe, maybe not.

Let me be clear about one thing there. My impression is that the L2VPN
work has largely been about connecting L2 LANs together. That is, you
have existng L2 LANs (or VLANs, etc.) at multiple sites, and you want
to glue them together so they look like one big LAN (to the hosts that
connect to them). Hosts/servers interact with the network as before,
sending L2 frames over an Ethernet. At some point, the L2 frames are
picked up by an device that transports them over the WAN as
appropriate (using L2TPv3, MPLS, etc.).

That is not what overlays are about. Conceptually, an overlay can
reside entirely within one datacenter. They can extend outside the
data center, but that is not a requirement. So the assumption is they
are setup and managed by the datacenter operator, not a providor.

VMs on a server run on a hypervisor. The hypervisor itself is part of
the overlay. That is, the overlay extends everywhere within the
datacenter, including all the way up to the access switches and the
hypervisors.

Thus, an overlay will have lots of "simple" devices (i.e, switches and
virtual switches) that are part of the overlay. While they
conceptually may have tunnels to all the other switches in the
overlay, in practice they don't need much per-destination state. They
just tunnel on demand. In contrast, the existing L2VP approachs have a
lot more state per endpoint and are just not designed to go all the
way into switches and hypervisors.

Does this make sense?

Thomas

---

From: Paul Unbehagen <[email-masked]>
Date: Mon, 3 Oct 2011 18:03:41 -0600

I have to agree with Florin on this one. These are essentially L2VPNs. Whether or not they are over IP or not is irrelevant. VPLS could also be considered an overlay over IP. 

--
Paul Unbehagen

---

From: Thomas Narten <[email-masked]>
Date: Mon, 03 Oct 2011 20:10:48 -0400

So, let me try and separate this into two issues, so we don't mix
things.

1) Yes, L2VPNs are a form of overlays. Overlays are a broad
concept. So we can have a discussion as to whether the current charter
already allows for this kind of work to be discussed here, at least in
principle and based on what the charter allows. I gather at least some
people are saying yes.

2) The work that is being proposed here seems very different from what
the L2VPN WG has worked on in the past, or is actually working on
today (or planning on working on based on the recent recharter). Or am
I mistaken? What existing or planned work is this similar to?

Thomas

---

From: John E Drake <[email-masked]>
Date: Mon, 3 Oct 2011 17:16:48 -0700

Thomas,

I have trouble understanding your previous email but your BoF announcement listed a number of drafts and these drafts all clearly appear to be within the scope of the L2VPN charter.

Thanks,

John

> Sent: Monday, October 03, 2011 8:11 PM
> To: Paul Unbehagen
> Cc: [email-masked]
> Subject: Re: Call for Participation: Using IP Overlays to provide L2
> Virtualization
>

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 3 Oct 2011 21:52:05 -0500

Thomas,

The challenges described in the drafts are definitely in scope for L2VPN and based on that it makes sense to do the initial analysis in L2VPN to identify the overlap. If it looks like the work is diverging substantially from the L2VPN scope then a BoF creation is the logical way to go. 

See in-line for answers to your questions/comments...

> From: Thomas Narten [mailto:[email-masked]]
> Sent: Monday, October 03, 2011 4:59 PM
> To: Balus, Florin Stelian (Florin)
> Cc: [email-masked]
> Subject: Re: Call for Participation: Using IP Overlays to provide L2 Virtualization
> 

Yes...

> What drafts relate to VM mobility?

See http://datatracker.ietf.org/doc/draft-raggarwa-data-center-mobility/

> data center, but that is not a requirement. 

Is there another draft on requirements? From the drafts you mention in your initial nvo3 email it looks like connectivity across DCs is in scope for all. I believe the use case is expanded L2 domain for VM mobility - e.g. the use of Inter-DC resource pools for Disaster Prevention.

> So the assumption is they

DC requirements were added in the L2VPN charter but it looks like a clear definition is required for Provider wording. L2 multi-tenancy beyond 4K VLANs is one of the  major requirements in NVO3. That in my opinion clearly crosses the line between a regular DC operator serving a handful of tenants and a true Cloud Provider. 

> way into switches and hypervisors.

It is ok to define a requirement to support L2 overlay in these switches and hypervisors and L2VPN should get a chance to discuss it and eventually address it. But I believe it is way too  early to decide there is nothing good to be offered by L2VPN and re-start from zero the whole work. 

Thanks,
Florin

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 4 Oct 2011 05:07:54 +0200

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Unbehagen
Sent: dinsdag 4 oktober 2011 2:04
To: Thomas Narten
Cc: [email-masked]
Subject: Re: Call for Participation: Using IP Overlays to provide L2 Virtualization

--
Paul Unbehagen

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 3 Oct 2011 23:50:19 -0700

Hi Thomas,

> What drafts relate to VM mobility?

The solution drafts (1st and 3rd ones above) have consideration for VM
mobility. Basically, as part of an L2-solution, host movement needs to
be handled regardless of whether the host is physical or virtual.
Furthermore, the 1st draft has consideration for ARP
optimization/suppression and the 3rd draft will cover that in its next
version based on the input/comments received. 

> datacenter, including all the way up to the access switches and the

We can group the L2-solutions under L2VPN into two categories: a)
PE-based solutions and b) CE-based solutions. Although the primary
emphasis has been thus far on PE-based solutions, the CE-based solutions
doesn't need to be excluded. Having the encapsulation to be performed by
the hypervisors or the virtual switch, can fall into either of the two
categories depending whether you consider the virtual switch (or
hypervisor) as part of the DC network or not. So, although the
application is different (DC versus DCI versus Carrier Eth versus etc.),
the L2-solution over IP (or MPLS) seems to have a lot in common across
all these different applications and it would be good to see whether the
DC overlay requirements are being met within L2VPN or not before talking
about a new WG.  

> way into switches and hypervisors.

The number of states on the edge device is a function of the location of
the edge device - closer to the host requires fewer states and farther
from the host, it requires more state (n-PE requires lot more states
than u-PE). L2VPN solutions covers both end of the spectrum. 

Again, it would be good to start from the requirements and see whether
there are any new requirements that cannot be met within L2VPN new
charter/solutions.

Cheers,
Ali

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Tue, 4 Oct 2011 08:08:39 -0400

Thomas,
Thanks for forwarding. The L2vpn WG charter that has been recently
approved states: 

"The L2VPN working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned Layer-2
Virtual Private Networks (L2VPNs). It will also address requirements
driven by cloud computing services and data centers as they apply to
Layer-2 VPN services.

Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as
defined by the PWE3 WG or over IP or MPLS PSN tunnels. A L2VPN
emulates a "native" service over a PSN that is adequately faithful
to, but may not be entirely indistinguishable from the native
service itself."

The goal is to address the data center and cloud computing requirements as
they pertain to L2 services.
In addition, the packet switched network can be IP or MPLS as stated.
There have been individual drafts in the WG
Such E-VPN or PBB-EVPN for instance that are mainly driven by data centers
and data center interconnects. That is in addition to other RFCs on VPLS,
VPMS, and PBB-PE model etc.

So, I think from an objective opinion of addressing multi-tenant data
center and data center interconnect scale, resiliency, efficiency, etc.,
there is overlap between this work and the l2vpn WG.

The following is my personal opinion:

I looked briefly through the drafts you attached. I think there are two
components: (1) scaling the number of l2 domains with a 24-bit identifier
that is coincidently (or may not be) the same size as an I-SID in the IEEE
802.1ah PBB header, and (2) tunneling of the layer2 traffic over IP to
avoid STP (a goal in many existing drafts) and take advantage of the IP
layer for ECMP, multicast etc. The mapping to the 24-bit network
identifier or Tenant 24-bit network identifier is dine at the hypervisor
or at a gateway in the first two drafts. I think short of the actual
encoding, this is in a way similar to PBB where you can start the PBB
encap at the hypervisor if such support exists or at the TOR by mapping a
VLAN ID to the 24-bit I-SID. How you switch that traffic within the data
center, can be native layer2, it can be tunneled over IP or MPLS. That
tunneling at least is expected to happen across the WAN for data center
interconnect. There are things that are mentioned related to multicast
that can be used or have existing parallel mechanisms to address that. My
point in stating that is not necessarily to imply only one way that things
can be done or should be done. However, it is to say that there are
existing tools or tools in the work that address these problems and for
layer2 it capitalizes on work in the IEEE and IETF. If there are
additional things that need to be developed to address deficiencies/gaps
in these tools, then they should be defined. Thus, It seems to me what is
suggested here is a providing a Layer2 VPN service and as a result that
should be part of the l2vpn working group evolving work and the solution,
set of solution or solution options if warranted can be defined there so
that the problem space can be addressed in one place without
fragmentation. 

Thanks,
Nabil

On 10/3/11 4:26 PM, "Thomas Narten" <[email-masked]> wrote:

>     Archive: 
>http://www.ietf.org/mail-archive/web/nvo3/current/maillist.html

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 04 Oct 2011 16:04:56 +0000

Does it mean that L2VPN is about L2 network being tunneled by another network? If yes, I totally agree with Florin's opinion. 
Then TRILL is L2VPN as well based on this definition. 

Linda Dunbar 

> Sent: Monday, October 03, 2011 7:04 PM
> To: Thomas Narten
> Cc: [email-masked]
> I have to agree with Florin on this one. These are essentially L2VPNs.
> Whether or not they are over IP or not is irrelevant. VPLS could also
> be considered an overlay over IP.
> 
> --
> Paul Unbehagen
> 
>

---

From: Giles Heron <[email-masked]>
Date: Tue, 04 Oct 2011 17:48:42 +0100

I think the "other" network has to be IP or MPLS (i.e. Layer 3).

In the TRILL case it's L2 over L2, right?

Giles

On 04/10/2011 17:04, "Linda Dunbar" <[email-masked]> wrote:

> Does it mean that L2VPN is about L2 network being tunneled by another network?
> If yes, I totally agree with Florin's opinion.

---

From: David Allan I <[email-masked]>
Date: Tue, 4 Oct 2011 13:07:43 -0400

I thought it was L2 over TRILL over foo....

But in this particular portion of the thread we are discussing other networking overlay techniques interworking with this overlay implying some kind of hybrid network. I do not think that is the design intent of this exercise. This is a different technology set that those explored by L2VPN to date extended to a vanilla (v)UNI in a greenfield build. There is no other Ethernet networking or emulation in the equation.

N'est pas?

That being said, I still think it falls under purview of L2VPN. Provider provisioned L2VPNs are exactly the same class of problem as multi-tenancy cloud. Many of the issues discussed in the problem statement draft explicitly overlap the class of solutions being discussed in L2VPN, particularly w.r.t. multicast... The technologies have been changed to protect the innocent, that's all.

My 2 cents
D 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: Tuesday, October 04, 2011 9:49 AM
To: Linda Dunbar; Paul Unbehagen; Thomas Narten
Cc: [email-masked]
Subject: Re: Call for Participation: Using IP Overlays to provide L2 Virtualization

Giles

On 04/10/2011 17:04, "Linda Dunbar" <[email-masked]> wrote:

>>>> The solution drafts you list below are about L2 over some sort of 
>>>> IP tunnels. IP PSN is in the charter for L2VPN and the working 
>>>> group has accumulated a lot of experience in my opinion dealing 
>>>> with all the VPN/multi-tenancy components, including L2/IP 
>>>> solution. Any DC related solutions need to also interoperate with 
>>>> existing VPNs as Cloud Provider want to deliver Cloud Services to VPN customers.
>>> 
>>> Maybe, maybe not.
>>> 
>>> work has largely been about connecting L2 LANs together. That is, 
>>> you have existng L2 LANs (or VLANs, etc.) at multiple sites, and you 
>>> want to glue them together so they look like one big LAN (to the 
>>> hosts
>> that
>>> data center, but that is not a requirement. So the assumption is 
>>> they are setup and managed by the datacenter operator, not a providor.
>>> 
>>> VMs on a server run on a hypervisor. The hypervisor itself is part 
>>> of the overlay. That is, the overlay extends everywhere within the 
>>> overlay, in practice they don't need much per-destination state. 
>>> They just tunnel on demand. In contrast, the existing L2VP approachs 
>>> have
>> a

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 04 Oct 2011 17:13:53 +0000

Giles, 

Thank you for the clarification. Based on  your clarification, TRILL is not in the scope of L2VPN because TRILL is not IP or MPLS. 
Then MAC-in-MAC is not in the scope of L2VPN either, correct? 

Linda

> From: Giles Heron [mailto:[email-masked]]
> Sent: Tuesday, October 04, 2011 11:49 AM
> >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of Paul Unbehagen
> IP
> you
> they
> of
> They
> >>> just tunnel on demand. In contrast, the existing L2VP approachs
> have
> >> a

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Oct 2011 10:25:35 -0700

Here is my 2c:

There is certainly big overlap between data center networking and L2VPN. However there are also some data center requirements, which I am not sure is in the scope of L2VPN WG such as:

1) Private IP addresses are OK in data center, since it is confined to a close environment
2) Most likely no IPV6 is needed 
3) Scales are much higher than Service Provider networks. For example there can be tens of thousands of Top of Rack switches and millions of VPNs
4) connection Security is not a big concern 
5) OAM is not a big concern 
6) Advanced load balancing is required including L2-L7 
7) Efficient Multicast from multiple members of a multicast group is required
8) Network management does a lot of the control plane functions
9) Core of data center is not MPLS (just IP or Ethernet)
10) Interworking between Data centers is required (may require translation of VPN identifier from local to global)

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, October 04, 2011 10:08 AM
To: Giles Heron; Linda Dunbar; Paul Unbehagen; Thomas Narten
Cc: [email-masked]
Subject: RE: Call for Participation: Using IP Overlays to provide L2 Virtualization

N'est pas?

My 2 cents
D 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: Tuesday, October 04, 2011 9:49 AM
To: Linda Dunbar; Paul Unbehagen; Thomas Narten
Cc: [email-masked]
Subject: Re: Call for Participation: Using IP Overlays to provide L2 Virtualization

Giles

On 04/10/2011 17:04, "Linda Dunbar" <[email-masked]> wrote:

>> Behalf Of Paul Unbehagen

---

From: Giles Heron <[email-masked]>
Date: Tue, 04 Oct 2011 18:34:38 +0100

Right - MAC-in-MAC would be out of scope.

But MAC-in-MAC over IP is potentially in scope as it provides for
multi-tenant L2 over an IP PSN.

Giles

On 04/10/2011 18:13, "Linda Dunbar" <[email-masked]> wrote:

> Giles, 
> 
> Thank you for the clarification. Based on  your clarification, TRILL is not in
> the scope of L2VPN because TRILL is not IP or MPLS.

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Tue, 4 Oct 2011 13:48:06 -0500

Hi Shahram,
I think we need some requirements draft driven by Cloud Providers. Let me try to add to your considerations below - see in-line...

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shahram Davari
> Sent: Tuesday, October 04, 2011 10:26 AM
> To: David Allan I; Giles Heron; Linda Dunbar; Paul Unbehagen; Thomas Narten
> Cc: [email-masked]
> There is certainly big overlap between data center networking and L2VPN.
> However there are also some data center requirements, which I am not sure is in
> the scope of L2VPN WG such as:
> 

If you are talking about private IP addresses in the DC core, that was always in scope for all VPN technologies. IP/MPLS core networks use private addressing. If you are talking about the VPN IP addressing then the deployed VPNs are based on allowing this kind of addressing too. Actually that was one of the main VPN requirements from the beginning and to allow overlapping addressing between customers.

> 2) Most likely no IPV6 is needed

No IPv6 is mandated by existing VPNs although it is supported. I would not exclude IPv6 support though from the Cloud requirements unless there are good reasons behind it.

> 3) Scales are much higher than Service Provider networks. For example there can be tens of thousands of Top of Rack switches and millions of VPNs

There are actually Telco networks that have similar size or up to 100K if you consider also the access switches/DSLAMs. These are usually  Metro-WAN-Metro networks. As to millions of VPNs did you mean millions of VMs? We do have addressing fields that allow for millions of VPNs but in practical sense we are right now at or below 4K VLANs and a handful of VR contexts in existing DC networks. It will take a while to get to millions.. it will be good to understand what Cloud Providers expect in medium/long term.

> 4) connection Security is not a big concern
I thought people care about that everywhere. Do you mean IPSec is not required?

> 5) OAM is not a big concern
This is very surprising to me. I thought with more tenants being served by a Cloud Provider there will be a clear need for proper troubleshooting tools and SLA reporting. We did extensive work in IETF on that and I think it is extensively used by Telcos.

> 6) Advanced load balancing is required including L2-L7
We always had ECMP in the IP/MPLS core and also EVPN/PBB-EVPN work is addressing L2-L7 loadbalancing at service level.

> 7) Efficient Multicast from multiple members of a multicast group is required
See work on flood containment and Mcast handling in EVPN and PBB/SPB.

> 8) Network management does a lot of the control plane functions

I agree this is something we did not need up to now in L2VPN although individual vendor EMS did some control plane functions for VPNs before service Auto-discovery was introduced. But I don't believe there is anything in the charter preventing us from doing it.

> 9) Core of data center is not MPLS (just IP or Ethernet)

We have IP tunnels in scope in L2VPN. In L2VPN we had also PBB interop draft which defines interop between native Ethernet tunnels and PBB-VPLS. Same can be said about PBB-EVPN draft.

> VPN identifier from local to global)

You mean this is a good argument for keeping the work in L2VPN to make sure we provide easy mapping of Tenant - WAN VPN ID right?

Thanks,
Florin
> But in this particular portion of the thread we are discussing other networking
> overlay techniques interworking with this overlay implying some kind of hybrid
> network. I do not think that is the design intent of this exercise. This is a
> different technology set that those explored by L2VPN to date extended to a
> vanilla (v)UNI in a greenfield build. There is no other Ethernet networking or
> emulation in the equation.
> 
> N'est pas?
> 
> That being said, I still think it falls under purview of L2VPN. Provider provisioned
> L2VPNs are exactly the same class of problem as multi-tenancy cloud. Many of
> the issues discussed in the problem statement draft explicitly overlap the class
> of solutions being discussed in L2VPN, particularly w.r.t. multicast... The
> technologies have been changed to protect the innocent, that's all.
> 
> My 2 cents
> D
>

---

From: Ping Pan <[email-masked]>
Date: Tue, 4 Oct 2011 12:32:06 -0700

Hi,

I think this set of drafts are very interesting. They are defined with a set
of data center applications in mind (and not necessarily with PBB or other
Ethernet network operation in mind). Nevertheless  the data manipulation
defined in the drafts will likely interface with MPLS in many cases.

Maybe that's new work which deserves a BOF/WG, maybe that can be combined
into L2VPN. In any rate. I think that we should keep an open mind, and hear
it first. Personally, I think the work is overlapping with L2VPN's general
framework, but I could be wrong...

Regards,

Ping

On Tue, Oct 4, 2011 at 11:48 AM, Balus, Florin Stelian (Florin) <
[email-masked]> wrote:

>
> Hi Shahram,
> I think we need some requirements draft driven by Cloud Providers. Let me
> try to add to your considerations below - see in-line...
>
> > 1) Private IP addresses are OK in data center, since it is confined to a
> close
> > environment
>
> If you are talking about private IP addresses in the DC core, that was
> always in scope for all VPN technologies. IP/MPLS core networks use private
> addressing. If you are talking about the VPN IP addressing then the deployed
> VPNs are based on allowing this kind of addressing too. Actually that was
> one of the main VPN requirements from the beginning and to allow overlapping
> addressing between customers.
>
> No IPv6 is mandated by existing VPNs although it is supported. I would not
> exclude IPv6 support though from the Cloud requirements unless there are
> good reasons behind it.
>
> > 3) Scales are much higher than Service Provider networks. For example
> there can be tens of thousands of Top of Rack switches and millions of VPNs
>
> There are actually Telco networks that have similar size or up to 100K if
> you consider also the access switches/DSLAMs. These are usually
>  Metro-WAN-Metro networks. As to millions of VPNs did you mean millions of
> VMs? We do have addressing fields that allow for millions of VPNs but in
> practical sense we are right now at or below 4K VLANs and a handful of VR
> contexts in existing DC networks. It will take a while to get to millions..
> it will be good to understand what Cloud Providers expect in medium/long
> term.
>
> This is very surprising to me. I thought with more tenants being served by
> a Cloud Provider there will be a clear need for proper troubleshooting tools
> and SLA reporting. We did extensive work in IETF on that and I think it is
> extensively used by Telcos.
>
> We always had ECMP in the IP/MPLS core and also EVPN/PBB-EVPN work is
> addressing L2-L7 loadbalancing at service level.
>
> I agree this is something we did not need up to now in L2VPN although
> individual vendor EMS did some control plane functions for VPNs before
> service Auto-discovery was introduced. But I don't believe there is anything
> in the charter preventing us from doing it.
>
> We have IP tunnels in scope in L2VPN. In L2VPN we had also PBB interop
> draft which defines interop between native Ethernet tunnels and PBB-VPLS.
> Same can be said about PBB-EVPN draft.
>
> > 10) Interworking between Data centers is required (may require
> translation of
> > VPN identifier from local to global)
>
> You mean this is a good argument for keeping the work in L2VPN to make sure
> we provide easy mapping of Tenant - WAN VPN ID right?
>
> Thanks,
> Florin
> >
> >
> > Thx
> > Shahram
> >
> > David Allan I
> > Giles Heron
> > >>>> existing VPNs as Cloud Provider want to deliver Cloud Services to
> VPN
> > customers.
> > >>>
> > >>> Maybe, maybe not.
> > >>>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 4 Oct 2011 22:13:01 +0200

In-line with WH>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: dinsdag 4 oktober 2011 19:26
To: David Allan I; Giles Heron; Linda Dunbar; Paul Unbehagen; Thomas Narten
Cc: [email-masked]
Subject: RE: Call for Participation: Using IP Overlays to provide L2 Virtualization

Here is my 2c:

1) Private IP addresses are OK in data center, since it is confined to a close environment
WH> same for L2VPN
2) Most likely no IPV6 is needed 
3) Scales are much higher than Service Provider networks. For example there can be tens of thousands of Top of Rack switches and millions of VPNs
WH> L2VPN solutions support this scale
4) connection Security is not a big concern
5) OAM is not a big concern 
6) Advanced load balancing is required including L2-L7 
WH> addressed with some solution in L2VPN today like MAC-VPN/E-VPN and PBB E-VPN
7) Efficient Multicast from multiple members of a multicast group is required
WH> addressed with some solution in L2VPN today like MAC-VPN/E-VPN and PBB E-VPN
8) Network management does a lot of the control plane functions
WH> you can perform functions in network management also with the L2VPn solutions
9) Core of data center is not MPLS (just IP or Ethernet)
WH> IP or MPLS is support in L2VPn and they both run over Ethernet
10) Interworking between Data centers is required (may require translation of VPN identifier from local to global)
WH> also being addresses using Inter-AS options

WH> so from this list I still believe L2VPN is the right place to discuss this.

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, October 04, 2011 10:08 AM
To: Giles Heron; Linda Dunbar; Paul Unbehagen; Thomas Narten
Cc: [email-masked]
Subject: RE: Call for Participation: Using IP Overlays to provide L2 Virtualization

N'est pas?

My 2 cents
D 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: Tuesday, October 04, 2011 9:49 AM
To: Linda Dunbar; Paul Unbehagen; Thomas Narten
Cc: [email-masked]
Subject: Re: Call for Participation: Using IP Overlays to provide L2 Virtualization

Giles

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Tue, 4 Oct 2011 17:36:56 -0400

Hi Sharam,
Please see inline as a contributor opinion.

Thanks,
Nabil

On 10/4/11 1:25 PM, "Shahram Davari" <[email-masked]> wrote:

>However there are also some data center requirements, which I am not sure
>is in the scope of L2VPN WG such as:
<NB> Maybe, but I think what is not in scope or cannot be in scope would
need to be identified.
>close environment
<NB> I am not sure whose IP addresses are being referred to. However, that
is assumed in all cases. If a customer connects to an L2VPN, they may be
using private or public IP addresses. There is nothing that restricts this
addressing one way or the other.
>2) Most likely no IPV6 is needed
<NB> Why would that assumption be made? I think it is safe to assume that
if the data center will be serving public customers or serving
enterprises, it would need to support IPv6.
>there can be tens of thousands of Top of Rack switches and millions of
<NB> Data center driven requirements from scale aspect, resiliency or
network efficiency and solutions to address them are in scope of the l2vpn
WG.
>4) connection Security is not a big concern
<NB> ?
>5) OAM is not a big concern
<NB> why would one think so, and OAM for what is not a concern.
>6) Advanced load balancing is required including L2-L7
<NB> Load-balancing is factored in as far ECMP etc., but I am not sure for
data path perspective, why you would be concerned about application layer
load-balancing
>7) Efficient Multicast from multiple members of a multicast group is
<NB> This pertains to both L2 and L3 and L2VPN and L3VPN address that and
if something is identified as lacking, then it should be addressed
>9) Core of data center is not MPLS (just IP or Ethernet)
<NB> IP-only PSN is within scope
>translation of VPN identifier from local to global)
>
>
>Thx
>Shahram
>
>But in this particular portion of the thread we are discussing other
>networking overlay techniques interworking with this overlay implying
>some kind of hybrid network. I do not think that is the design intent of
>this exercise. This is a different technology set that those explored by
>L2VPN to date extended to a vanilla (v)UNI in a greenfield build. There
>is no other Ethernet networking or emulation in the equation.
>
>N'est pas?
>
>That being said, I still think it falls under purview of L2VPN. Provider
>provisioned L2VPNs are exactly the same class of problem as multi-tenancy
>cloud. Many of the issues discussed in the problem statement draft
>explicitly overlap the class of solutions being discussed in L2VPN,
>particularly w.r.t. multicast... The technologies have been changed to
>protect the innocent, that's all.
>
>My 2 cents
>D 
>
>>>>>VPN customers.

---

From: renier van tonder <[email-masked]>
Date: Wed, 5 Oct 2011 08:00:12 +0200

Gents and/or Ladies

I beg you please remove me from your mailing list. I have NO idea how I got
on to it in the first place!!

Thank you kindly

[email-masked]

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 5 Oct 2011 14:26:47 -0700

Hi,

I agree with Benson here. A big difference is L2VPN focuses on "provider
provisioned" which may not be what the NVO3 may be focussed on.

With that said however I guess because there are similarities, the way to
look at it would be, to see if there is interest in the group, the right
folks are part of the L2VPN group, the chair's/ AD's are willing to take up
the task and other similar questions.

Thanks,
Vishwas
On Mon, Oct 3, 2011 at 3:43 PM, Benson Schliesser <[email-masked]>wrote:

> I don't disagree with Florin's comments, but I'm not certain the NVO3
> initiative is best-served within L2VPN's scope. The L2VPN charter says that
> "Layer-2 VPNs comprise" an enumerated list of topics. While there may be
> overlap, it seems that NVO3 would deal with a somewhat new topic.  Whether
> this is best done through a re-charter of L2VPN or establishment of a new
> WG, is not clear to me - but for the sake of argument here are a couple
> considerations:
>
> For starters, the current L2VPN charter focuses on "provider-provisioned"
> which may not apply to NVO3.  This is admittedly a vague line of division,
> but it may be useful in thinking about the distinction between these areas
> of work.
>
> More specifically, while NVO3 solutions might emulate native L2 service,
> they may in fact be significantly different in capability and operation.
>  I'd suggest that, for example, the mechanisms by which address resolution
> happen might be very different - both within an overlay, as well as between
> the overlay and underlying PSN. This might constrain the types of traffic
> that can be carried by the overlay. Or maybe not. This is something that
> NVO3 would need to investigate.
>
> Cheers,
> -Benson
>
>
> > The L2VPN charter was modified a few months ago to include work related
> to DC/Cloud networking. There were a number of proposed requirements and
> solution initiatives that prompted the change - see drafts on EVPN, PBB-EVPN
> (requirements, solutions) and VM mobility.
> >
> tunnels. IP PSN is in the charter for L2VPN and the working group has
> accumulated a lot of experience in my opinion dealing with all the
> VPN/multi-tenancy components, including L2/IP solution. Any DC related
> solutions need to also interoperate with existing VPNs as Cloud Provider
> want to deliver Cloud Services to VPN customers.
> >
> > So I think these initiatives are in L2VPN scope and should be discussed
> here to better understand what are the deltas from existing VPN
> technologies.
> >
> > Florin
> >

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 7 Oct 2011 09:45:20 -0700

Hi Florin,

-----Original Message-----
From: Balus, Florin Stelian (Florin) [mailto:[email-masked]] 
Sent: Tuesday, October 04, 2011 11:48 AM
To: Shahram Davari; David Allan I; Giles Heron; Linda Dunbar; Paul Unbehagen; Thomas Narten
Cc: [email-masked]
Subject: RE: Call for Participation: Using IP Overlays to provide L2 Virtualization

Hi Shahram,

SD> I was talking about the private IP address for the routers in the DC core. I don't think private IP address is allowed for Service Provider core.

SD> Inside a data-center there is no need to have IPV6 address since the IP addresses are local to the Data center. Off course IPv6 may be needed when sending packets out of a data center, but that can be done via a Gateway router.

SD> I meant million VPN and more VMs. I am not aware of any SP network that requires a heterogeneous connectivity between so many PEs are VPNs. 

SD> Inside a DC there is no need to use IPSEC or MACSEC since it is a restricted area.

SD> Today there is no OAM inside a DC. I agree that adding OAM adds value.

SD> OK.

SD> OK.

I know that we have IP tunnels in scope of L2VPN but we have not seen any specific solution for IP-only cores (without MPLS and PW).

SD> I meant that some new functions that have never been considered in L2VPN group are required

Thanks
Shahram

Thanks,
Florin

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 7 Oct 2011 09:50:29 -0700

Hi Nabil,

Please see my comments inline.

Thanks
Shahram

-----Original Message-----
From: Bitar, Nabil N [mailto:[email-masked]] 
Sent: Tuesday, October 04, 2011 2:37 PM
To: Shahram Davari; David Allan I; Giles Heron; Linda Dunbar; Paul Unbehagen; Thomas Narten
Cc: [email-masked]
Subject: Re: Call for Participation: Using IP Overlays to provide L2 Virtualization

Hi Sharam,

Thanks,
Nabil

SD> I was referring to TOR switches and Core router addresses that are confined inside a DC

SD> Inside a DC, there is no need for IPv6 but as the packet gets out of DC IPV6 is needed.

<NB> ?

SD> I meant inside DC there is no need for IPSEC or MACSEC.

SD> I meant today no OAM is used in DC.

SD> ECMP load balancing mostly relies on L2 and L3 header. DC may require finer grain load balancing.

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Fri, 7 Oct 2011 15:34:46 -0500

Hi Shahram,
I believe a requirement draft is required from the DC Providers in order to evaluate the differences with the focus on the future architecture. See below for some more clarifications on selected items.

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Friday, October 07, 2011 9:45 AM
> To: Balus, Florin Stelian (Florin); David Allan I; Giles Heron; Linda Dunbar; Paul
> Unbehagen; Thomas Narten
> Cc: [email-masked]
> I think we need some requirements draft driven by Cloud Providers. Let me try
> to add to your considerations below - see in-line...
> 
> If you are talking about private IP addresses in the DC core, that was always in
> scope for all VPN technologies. IP/MPLS core networks use private addressing. If
> you are talking about the VPN IP addressing then the deployed VPNs are based
> on allowing this kind of addressing too. Actually that was one of the main VPN
> requirements from the beginning and to allow overlapping addressing between
> customers.
> 
> SD> I was talking about the private IP address for the routers in the DC core. I
> don't think private IP address is allowed for Service Provider core.

When it comes to VPN deployments there are no restrictions like this on the Service Provider core: they may use (and some actually do) private addressing inside their IP/MPLS core used for VPN transport. 

[clipped] 
 
> We have IP tunnels in scope in L2VPN. In L2VPN we had also PBB interop draft
> which defines interop between native Ethernet tunnels and PBB-VPLS. Same can
> be said about PBB-EVPN draft.
> 
> I know that we have IP tunnels in scope of L2VPN but we have not seen any
> specific solution for IP-only cores (without MPLS and PW).

L2TP based solutions were developed initially in PWE3 and then I believe in L2TP WG. They are applicable and actually deployed in a number of VPLS and VPWS networks. I am also aware of vendor solutions using GRE tunneling for VPLS and VPWS that may be re-considered in L2VPN if needed.

Thanks,
Florin
 
> provisioned