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

["Balus, Florin Stelian (Florin)" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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: [e-mail]
> Subject: RE: Call for Participation: Using IP Overlays to provide L2 Virtualization
> 
> 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

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.

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