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

["Bitar, Nabil N" <[e-mail]>]

Hi Sharam,
Please see inline as a contributor opinion.

Thanks,
Nabil

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

>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:
<NB> Maybe, but I think what is not in scope or cannot be in scope would
need to be identified.
>
>1) Private IP addresses are OK in data center, since it is confined to a
>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.
> 
>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
<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
>required
<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
>8) Network management does a lot of the control plane functions
>9) Core of data center is not MPLS (just IP or Ethernet)
<NB> IP-only PSN is within scope
>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
>
>
>
>