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

[Giles Heron <[e-mail]>]

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" <[e-mail]> 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.
> Then MAC-in-MAC is not in the scope of L2VPN either, correct?
> 
> Linda
> 
>> -----Original Message-----
>> From: Giles Heron [mailto:[e-mail]]
>> Sent: Tuesday, October 04, 2011 11: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
>> 
>