RE: Call for Participation: Using IP Overlays to provide L2 Virtualization
"Shahram Davari" <davari@broadcom.com> Fri, 07 October 2011 16:47 UTC
Return-Path: <davari@broadcom.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF7C21F8C2D for <l2vpn@ietfa.amsl.com>; Fri, 7 Oct 2011 09:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.229
X-Spam-Level:
X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[AWL=1.455, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUrIK3rAh5G2 for <l2vpn@ietfa.amsl.com>; Fri, 7 Oct 2011 09:47:25 -0700 (PDT)
Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id A851B21F8BF9 for <l2vpn@ietf.org>; Fri, 7 Oct 2011 09:47:25 -0700 (PDT)
Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 Oct 2011 09:57:31 -0700
X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A
Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Fri, 7 Oct 2011 09:50:31 -0700
From: Shahram Davari <davari@broadcom.com>
To: "Bitar, Nabil N" <nabil.n.bitar@verizon.com>, David Allan I <david.i.allan@ericsson.com>, Giles Heron <giles.heron@gmail.com>, Linda Dunbar <linda.dunbar@huawei.com>, Paul Unbehagen <paul@unbehagen.net>, Thomas Narten <narten@us.ibm.com>
Date: Fri, 07 Oct 2011 09:50:29 -0700
Subject: RE: Call for Participation: Using IP Overlays to provide L2 Virtualization
Thread-Topic: Call for Participation: Using IP Overlays to provide L2 Virtualization
Thread-Index: AcyC3cFxHqY5dmcXTqOcPuKNTPtCPwCMubEA
Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBA9583D13@SJEXCHCCR02.corp.ad.broadcom.com>
References: <2C2F1EBA8050E74EA81502D5740B4BD6BBA94D13CD@SJEXCHCCR02.corp.ad.broadcom.com> <CAB0F132.1B7D0%nabil.n.bitar@verizon.com>
In-Reply-To: <CAB0F132.1B7D0%nabil.n.bitar@verizon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 6291F0F13JW2440329-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2011 16:47:27 -0000
Hi Nabil, Please see my comments inline. Thanks Shahram -----Original Message----- From: Bitar, Nabil N [mailto:nabil.n.bitar@verizon.com] Sent: Tuesday, October 04, 2011 2:37 PM To: Shahram Davari; David Allan I; Giles Heron; Linda Dunbar; Paul Unbehagen; Thomas Narten Cc: l2vpn@ietf.org Subject: Re: Call for Participation: Using IP Overlays to provide L2 Virtualization Hi Sharam, Please see inline as a contributor opinion. Thanks, Nabil On 10/4/11 1:25 PM, "Shahram Davari" <davari@broadcom.com> 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. SD> I was referring to TOR switches and Core router addresses that are confined inside a DC >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. SD> Inside a DC, there is no need for IPv6 but as the packet gets out of DC IPV6 is needed. > >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> ? SD> I meant inside DC there is no need for IPSEC or MACSEC. > >5) OAM is not a big concern <NB> why would one think so, and OAM for what is not a concern. > SD> I meant today no OAM is used in DC. >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 SD> ECMP load balancing mostly relies on L2 and L3 header. DC may require finer grain 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: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >David Allan I >Sent: Tuesday, October 04, 2011 10:08 AM >To: Giles Heron; Linda Dunbar; Paul Unbehagen; Thomas Narten >Cc: l2vpn@ietf.org >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: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Giles Heron >Sent: Tuesday, October 04, 2011 9:49 AM >To: Linda Dunbar; Paul Unbehagen; Thomas Narten >Cc: l2vpn@ietf.org >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" <linda.dunbar@huawei.com> 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: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf Of Paul Unbehagen >>> Sent: Monday, October 03, 2011 7:04 PM >>> To: Thomas Narten >>> Cc: l2vpn@ietf.org >>> 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 <narten@us.ibm.com> wrote: >>> >>>> "Balus, Florin Stelian (Florin)" <florin.balus@alcatel-lucent.com> >>> 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 > > > >
- FWD: Call for Participation: Using IP Overlays to… Thomas Narten
- RE: Call for Participation: Using IP Overlays to … Balus, Florin Stelian (Florin)
- Re: Call for Participation: Using IP Overlays to … Benson Schliesser
- Re: Call for Participation: Using IP Overlays to … Thomas Narten
- Re: Call for Participation: Using IP Overlays to … Paul Unbehagen
- Re: Call for Participation: Using IP Overlays to … Thomas Narten
- RE: Call for Participation: Using IP Overlays to … John E Drake
- RE: Call for Participation: Using IP Overlays to … Balus, Florin Stelian (Florin)
- RE: Call for Participation: Using IP Overlays to … Henderickx, Wim (Wim)
- RE: Call for Participation: Using IP Overlays to … Ali Sajassi (sajassi)
- Re: Call for Participation: Using IP Overlays to … Bitar, Nabil N
- RE: Call for Participation: Using IP Overlays to … Linda Dunbar
- Re: Call for Participation: Using IP Overlays to … Giles Heron
- RE: Call for Participation: Using IP Overlays to … David Allan I
- RE: Call for Participation: Using IP Overlays to … Linda Dunbar
- RE: Call for Participation: Using IP Overlays to … Shahram Davari
- Re: Call for Participation: Using IP Overlays to … Giles Heron
- RE: Call for Participation: Using IP Overlays to … Balus, Florin Stelian (Florin)
- Re: Call for Participation: Using IP Overlays to … Ping Pan
- RE: Call for Participation: Using IP Overlays to … Henderickx, Wim (Wim)
- Re: Call for Participation: Using IP Overlays to … Bitar, Nabil N
- Re: Call for Participation: Using IP Overlays to … renier van tonder
- Re: Call for Participation: Using IP Overlays to … Vishwas Manral
- RE: Call for Participation: Using IP Overlays to … Shahram Davari
- RE: Call for Participation: Using IP Overlays to … Shahram Davari
- RE: Call for Participation: Using IP Overlays to … Balus, Florin Stelian (Florin)