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

[Ping Pan <[e-mail]>]

Hi,

I think this set of drafts are very interesting. They are defined with a set
of data center applications in mind (and not necessarily with PBB or other
Ethernet network operation in mind). Nevertheless  the data manipulation
defined in the drafts will likely interface with MPLS in many cases.

Maybe that's new work which deserves a BOF/WG, maybe that can be combined
into L2VPN. In any rate. I think that we should keep an open mind, and hear
it first. Personally, I think the work is overlapping with L2VPN's general
framework, but I could be wrong...

Regards,

Ping



On Tue, Oct 4, 2011 at 11:48 AM, Balus, Florin Stelian (Florin) <
[e-mail]> wrote:

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