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

From: "PAULING, JOEL (JOEL)" <[email-masked]>
Date: Tue, 4 Oct 2011 05:14:16 +0200

Has anyone looked at the l2vde codebase. It is mature and features a lot of what seems to being discussed here.

--sent from an android handset--

 -----Original Message-----
From: 	Henderickx, Wim (Wim) [mailto:[email-masked]]
Sent:	Monday, October 03, 2011 10:08 PM Central Standard Time
To:	Paul Unbehagen; Thomas Narten
Cc:	[email-masked]
Subject:	RE: Call for Participation: Using IP Overlays to provide L2	Virtualization

+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

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

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