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

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

Hi Shahram,
I believe a requirement draft is required from the DC Providers in order to evaluate the differences with the focus on the future architecture. See below for some more clarifications on selected items.

> -----Original Message-----
> From: Shahram Davari [mailto:[e-mail]]
> Sent: Friday, October 07, 2011 9:45 AM
> To: Balus, Florin Stelian (Florin); 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
> 
> Hi Florin,
> 
> -----Original Message-----
> From: Balus, Florin Stelian (Florin) [mailto:[e-mail]]
> Sent: Tuesday, October 04, 2011 11:48 AM
> To: Shahram Davari; 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
> 
> 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.
> 
> SD> I was talking about the private IP address for the routers in the DC core. I
> don't think private IP address is allowed for Service Provider core.

When it comes to VPN deployments there are no restrictions like this on the Service Provider core: they may use (and some actually do) private addressing inside their IP/MPLS core used for VPN transport. 

[clipped] 
 
> > 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.
> 
> I know that we have IP tunnels in scope of L2VPN but we have not seen any
> specific solution for IP-only cores (without MPLS and PW).

L2TP based solutions were developed initially in PWE3 and then I believe in L2TP WG. They are applicable and actually deployed in a number of VPLS and VPWS networks. I am also aware of vendor solutions using GRE tunneling for VPLS and VPWS that may be re-considered in L2VPN if needed.

Thanks,
Florin
 
> > 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?
> 
> SD> I meant that some new functions that have never been considered in L2VPN
> group are required
> 
> 
> Thanks
> Shahram
> 
> 
> 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
> >
> >
> >
> 
>