RE: Call for Participation: Using IP Overlays to provide L2 Virtualization

["Shahram Davari" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of David Allan I
Sent: Tuesday, October 04, 2011 10:08 AM
To: Giles Heron; Linda Dunbar; Paul Unbehagen; Thomas Narten
Cc: [e-mail]
Subject: RE: Call for Participation: Using IP Overlays to provide L2 Virtualization

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: [e-mail] [mailto:[e-mail]] On Behalf Of Giles Heron
Sent: Tuesday, October 04, 2011 9:49 AM
To: Linda Dunbar; Paul Unbehagen; Thomas Narten
Cc: [e-mail]
Subject: Re: Call for Participation: Using IP Overlays to provide L2 Virtualization

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" <[e-mail]> wrote:

> 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
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Paul Unbehagen
>> Sent: Monday, October 03, 2011 7:04 PM
>> To: Thomas Narten
>> Cc: [e-mail]
>> Subject: Re: Call for Participation: Using IP Overlays to provide L2 
>> Virtualization
>> 
>> 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
>> 
>> 
>> On Oct 3, 2011, at 5:58 PM, Thomas Narten <[e-mail]> wrote:
>> 
>>> "Balus, Florin Stelian (Florin)" <[e-mail]>
>> 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