Hi, Can you if a VM needs to know that far end VM MAC, aside from the other cases? I believe your basic assumption is that the only need is to get the IP packet from one VM to another and the applications running in the VMs are communicating over IP only. That is aside from the other cases mentioned.
Thanks, Nabil On 9/28/12 3:24 PM, "NAPIERALA, MARIA H" <[email protected]> wrote: >> > Maria, there is since a customer/enterprise will demand a L2 >> > communication or L3 communication for certain Apps/VMs. As such the >> > cloud provider needs to accommodate it. You cannot transport a >> > broadcast packet via L3, >> >> Yes, you can. >> >> WH> How? > >RFC 6513 - "Announcing the Presence of Unsolicited Flooded Data". > > >> > neither can you route a packet in the same >> > subnet as you would change the TTL and if it is 1 it will be dropped. >> > As such they care since apps break. >> >> > EVPN allows to provide a L2/L3 communication. >> > L3VPN does not since you do not transport the MAC address. >> >> Yes. >> But why would you need to transport MAC addresses? Applications do not >> send or receive Ethernet frames directly, they are restricted to IP >> services. >> The requirement is to provide an "IP subnet" and traffic exchange >> between "IP subnets". IP service is: unicast, subnet broadcast, >> multicast. >> Are you saying that the requirement for layer 2 service is to address >> the interaction with IEEE bridging? >> >> WH> yes you need to do IEEE bridging and this is what customers want > >Are you referring to your customers? > >> > You could also solve this by doing both EVPN and L3VPN. >> >> Yes. And IMO, it is better to keep layer 2 and layer 3 solutions >> separate - cleaner, less complex, no virtualized IRB. >> I would rather design around the inter-subnet traffic exchange first >> (as it is majority of traffic), and then address intra-subnet, and >> whether interaction with bridging is required (because this is where >> complexity "lives"..) >> >> WH> you can but you need to do some interaction which can be a local >> implementation matter. >> >> Maria >> >> > -----Original Message----- >> > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> lucent.com] >> > Sent: Friday, September 28, 2012 2:19 PM >> > To: NAPIERALA, MARIA H; Luyuan Fang (lufang); Bitar, Nabil N; Fedyk, >> > Donald (Don); [email protected] >> > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane >> > >> > Maria, there is since a customer/enterprise will demand a L2 >> > communication or L3 communication for certain Apps/VMs. As such the >> > cloud provider needs to accommodate it. You cannot transport a >> > broadcast packet via L3, neither can you route a packet in the same >> > subnet as you would change the TTL and if it is 1 it will be dropped. >> > As such they care since apps break. >> > >> > EVPN allows to provide a L2/L3 communication. >> > L3VPN does not since you do not transport the MAC address. >> > You could also solve this by doing both EVPN and L3VPN. >> > >> > These are the options you have so far. >> > WIm >> > >> > -----Original Message----- >> > From: NAPIERALA, MARIA H [mailto:[email protected]] >> > Sent: vrijdag 28 september 2012 20:12 >> > To: Henderickx, Wim (Wim); Luyuan Fang (lufang); Bitar, Nabil N; >> Fedyk, >> > Donald (Don); [email protected] >> > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane >> > >> > Wim, >> > >> > > Maria, there are applications in enterprise that require L2 >> > > communication between hosts, same IP subnet, etc. As such the >> > solution >> > > needs to accommodate this. Don't get me wrong I also want to make >> it >> > as >> > > simple as possible, but this is what people are looking to do and I >> > > believe we cannot ignore it. Enterprise customers will demand to >> > enable >> > > this in the Public Cloud. >> > >> > Why would a customer care how a *Public* Cloud delivers IP traffic >> > between VMs/appliances, as long as the traffic is delivered >> > successfully? If this is just IP-subnet issue then this no issue >> since >> > the traffic is handled the same way by a VM whether >> > one implements EVPN or L3VPN. There is no visible difference. >> > >> > Maria >> > >> > > >> > > -----Original Message----- >> > > From: NAPIERALA, MARIA H [mailto:[email protected]] >> > > Sent: vrijdag 28 september 2012 18:54 >> > > To: Henderickx, Wim (Wim); Luyuan Fang (lufang); Bitar, Nabil N; >> > Fedyk, >> > > Donald (Don); [email protected] >> > > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane >> > > >> > > Since layer 3 can address both intra-subnet and inter-subnet IP >> > > communication by a uniform forwarding (i.e., there is no difference >> > in >> > > forwarding between those two), the question is why to introduce a >> > > complication of mixing L2 and L3 forwarding in the *same* solution. >> > > As Kireeti wrote, with which I agree: "mixing L2 and L3 for a >> tenant >> > > (either as VNs or between DC and WAN) is fraught with complications >> > > (basically, IRB in a virtualized setting)." >> > > IRB was always intended to be used to solve specific and narrowly >> > > defined problems, not to build the entire network on IRB. >> > > >> > > Maria >> > > >> > > >> > > > -----Original Message----- >> > > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> > > lucent.com] >> > > > Sent: Friday, September 28, 2012 12:58 AM >> > > > To: Luyuan Fang (lufang); Bitar, Nabil N; NAPIERALA, MARIA H; >> > Fedyk, >> > > > Donald (Don); [email protected] >> > > > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane >> > > > >> > > > Luyuan, mixing L2 and L3 is very common for IAAS. >> > > > People will have different groups of networking: >> > > > - L2 domains connected via L3 >> > > > - Something like this: >> > > > >> > > > VM11 ---+ +-- VM21 >> > > > | | >> > > > L2 CUG1 + -- L3 -- + L2 CUG2 >> > > > | | >> > > > VM12 ---+ +-- VM22 >> > > > >> > > > L2 CUG1 is a web tier >> > > > And L3 CUG2 is the business tier >> > > > >> > > > A very common use case which I have seen so far. >> > > > >> > > > -----Original Message----- >> > > > From: Luyuan Fang (lufang) [mailto:[email protected]] >> > > > Sent: vrijdag 28 september 2012 0:26 >> > > > To: Bitar, Nabil N; Henderickx, Wim (Wim); NAPIERALA, MARIA H; >> > Fedyk, >> > > > Donald (Don); [email protected] >> > > > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane >> > > > >> > > > Nabil, >> > > > >> > > > We talked this earlier this week while your mail was sent but >> > > "napping" >> > > > in the system somewhere. :-). >> > > > >> > > > I did not mean that interworking a Layer 2 service having access >> to >> > > an >> > > > IP routing service, that is done today... >> > > > I meant to say, e.g., today we don't establish a single VPN with >> > some >> > > > sites being l3vpn and others being vpls. >> > > > >> > > > I think we are generally in agreement. >> > > > >> > > > - both L2 and L3 support are needed >> > > > - both L2 and L3 can be supported in the same network and on the >> > same >> > > > device (it is done today) >> > > > - What we need to be more careful is wither we should mix >> different >> > > > sites with l2 and l3 into the same vpn. It could create >> > complication >> > > > than its worth. Study/work need to be done if reality really >> calls >> > > for >> > > > the case. >> > > > >> > > > Luyuan >> > > > >> > > > > -----Original Message----- >> > > > > From: Bitar, Nabil N [mailto:[email protected]] >> > > > > Sent: Thursday, September 27, 2012 7:58 AM >> > > > > To: Luyuan Fang (lufang); Henderickx, Wim (Wim); Bitar, Nabil >> N; >> > > > > NAPIERALA, MARIA H; Fedyk, Donald (Don); [email protected] >> > > > > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane >> > > > > >> > > > > Do you mean by interworking a Layer2 service having access to >> an >> > IP >> > > > > routing service as commonly done today? I wouldn't compare >> that >> > to >> > > > > FR/ATM >> > > > > interworking. >> > > > > >> > > > > There are applications that require operation over Ethernet and >> > > have >> > > > > MAC >> > > > > awareness. There are also dependencies on the other end of the >> > > > > communication operations and capabilities. >> > > > > >> > > > > There are other applications, legacy or not, that are not IP >> > aware >> > > > and >> > > > > will require Layer2 connectivity. Storage, depending on the >> > storage >> > > > > networking technology, is an example and I think there was an >> > email >> > > > > from >> > > > > Dave Black about that some time back. There are probably other >> > > apps, >> > > > > proprietary or commercial that rely on Ethernet only. I am >> > raising >> > > > that >> > > > > not because of E-VPN or not but the general notion being >> debated >> > by >> > > > > some >> > > > > that we need to take a hard-line saying only IP service needs >> to >> > be >> > > > > supported, as much as I would like that to be the case. >> > > > > >> > > > > While one can argue that if an application is not IP-based, it >> > can >> > > be >> > > > > migrated to one that is or you can tunnel to the application >> > > > depending >> > > > > on >> > > > > the application or ..,, it seems to me it is a hardline to say >> > that >> > > > an >> > > > > L2 >> > > > > service is not >> > > > > needed in the DC at the functional level of NVE and gateways as >> > it >> > > > can >> > > > > be >> > > > > disruptive in certain cases or create hurdles. >> > > > > >> > > > > The net is that the DC fabric (underlay) can be IP only >> although >> > > for >> > > > > some >> > > > > Ethernet can still be a choice. The service overlaid on that >> can >> > be >> > > > IP >> > > > > or >> > > > > bridged Ethernet and that is a choice for people to do based on >> > > > several >> > > > > constraints including applications they want to support. Today >> > > > Ethernet >> > > > > and IP services are realities and need to be addressed. IP will >> > be >> > > > > always >> > > > > needed, no doubt. If one can live with IP only they would have >> > the >> > > > > tool, >> > > > > if they need a mix of IP of Ethernet bridge services, they >> should >> > > > also >> > > > > have the tools. Id people are only interested in IP services, >> > they >> > > > can >> > > > > only work on that, and if people have the need for the mix or >> > want >> > > to >> > > > > work >> > > > > on the mix or or one or the other, they can also do that. >> > > > > >> > > > > Thanks, >> > > > > Nabil >> > > > > >> > > > > >> > > > > >> > > > > On 9/24/12 5:40 PM, "Luyuan Fang (lufang)" <[email protected]> >> > > wrote: >> > > > > >> > > > > >Wim, >> > > > > > >> > > > > >Agree. >> > > > > >I tried not to go into the mix case :-). Need to better >> > understand >> > > > the >> > > > > >real needs, its implication, and various (prefer simplified) >> > > > potential >> > > > > >solutions. >> > > > > > >> > > > > >Mix could mean people deploy L2 and L3 separately in the >> shared >> > > > > >infrastructure, or it could mean inter-working if you are >> > thinking >> > > > > some >> > > > > >sites are L2, some are L3 within one VPN, or inter-connecting >> LX >> > > DC >> > > > > with >> > > > > >LY VPN network... >> > > > > > >> > > > > >Technically, these can all be done. Practically, we need to >> ask >> > > > > operators >> > > > > >what are the objectives, how much complication they are >> willing >> > to >> > > > get >> > > > > >into, and the benefits, trade-offs. >> > > > > > >> > > > > >Do we see a lot of mixed case for L2/L3 VPNs in today's >> network >> > > VPN >> > > > > >deployment after all these years? If not so, why do DC >> operators >> > > > want >> > > > > to >> > > > > >make it more complex? >> > > > > > >> > > > > >In my past experience on the operator side, inter-working >> (e.g. >> > > > > FR/ATM, >> > > > > >ATM/Ethernet, MPLS/Ethernet...) were good on papers, but >> always >> > > too >> > > > > >complicated for operation, never that successful. >> > > > > > >> > > > > >I can see sometimes we are dealing with some existing and the >> > new >> > > > > >environment, the mix may or may not be avoidable. >> > > > > >But I want to see if many operators really want to mix things, >> > and >> > > > to >> > > > > >what level. >> > > > > > >> > > > > >Thanks, >> > > > > >Luyuan >> > > > > > >> > > > > >> -----Original Message----- >> > > > > >> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> > > > > lucent.com] >> > > > > >> Sent: Monday, September 24, 2012 11:09 PM >> > > > > >> To: Luyuan Fang (lufang); Bitar, Nabil N; NAPIERALA, MARIA >> H; >> > > > Fedyk, >> > > > > >> Donald (Don); [email protected] >> > > > > >> Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane >> > > > > >> >> > > > > >> Luyuan, >> > > > > >> >> > > > > >> While I understand there are customers for L3, there are >> > equally >> > > > > >> customers for L2 as you said, but also for a mix when >> > > application >> > > > > >> tiering is required. >> > > > > >> We need to address all 3 use cases. >> > > > > >> >> > > > > >> Cheers, >> > > > > >> Wim >> > > > > >> >> > > > > >> -----Original Message----- >> > > > > >> From: [email protected] [mailto:[email protected]] >> On >> > > > Behalf >> > > > > Of >> > > > > >> Luyuan Fang (lufang) >> > > > > >> Sent: maandag 24 september 2012 22:57 >> > > > > >> To: Bitar, Nabil N; NAPIERALA, MARIA H; Fedyk, Donald (Don); >> > > > > >> [email protected] >> > > > > >> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane >> > > > > >> >> > > > > >> Nabil, >> > > > > >> >> > > > > >> See in-line. >> > > > > >> >> > > > > >> > -----Original Message----- >> > > > > >> > From: Bitar, Nabil N [mailto:[email protected]] >> > > > > >> > Sent: Monday, September 24, 2012 9:45 PM >> > > > > >> > To: Luyuan Fang (lufang); NAPIERALA, MARIA H; Fedyk, >> Donald >> > > > (Don); >> > > > > >> > [email protected] >> > > > > >> > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane >> > > > > >> > >> > > > > >> > Luyuan, >> > > > > >> > Well put. >> > > > > >> >> > > > > >> Thx. >> > > > > >> >> > > > > >> I am presuming that you are also saying that both need to >> > > > > >> > co-exist (E-VPN and RFC4364) and get interconnected in >> > > > > environments >> > > > > >> > that >> > > > > >> > need that. >> > > > > >> >> > > > > >> Yes. Interconnected with the matching environment is a good >> > > > > >> description. >> > > > > >> >> > > > > >> Personally, I see L3 (in general sense) is becoming the >> trend >> > > for >> > > > > >> scaling, the move from L2 to L3 happened already in some >> > largest >> > > > DCs >> > > > > >> deployed today. >> > > > > >> On the other hand, there are networks must support certain >> > > legacy >> > > > L2 >> > > > > >> services, and some DC operators may be more familiar with L2 >> > > > > >> environment so prefer l2 solutions, or there is need to >> inter- >> > > > > connect >> > > > > >> to the matching environment as you mentioned. Besides, not >> > > > everyone >> > > > > >> needs the scale like FB, MS, Amazon... >> > > > > >> So both L2 and L3 need to be supported. >> > > > > >> >> > > > > >> >Is that so? Interconnection may happen in different ways to >> > > > > >> > allow bridging when traffic is among endpoints on on same >> > > subnet >> > > > > and >> > > > > >> > routing when crossing subnets in the same vpn. >> > > > > >> >> > > > > >> Yes, particularly true as with today's typical l2 solutions. >> > > > > >> In all L3 case, there would be no bridging. >> > > > > >> >> > > > > >> > >> > > > > >> > Thanks, >> > > > > >> > Nabil >> > > > > >> > >> > > > > >> Thanks, >> > > > > >> Luyuan >> > > > > >> >> > > > > >> >> > > > > >> > On 9/24/12 3:12 PM, "Luyuan Fang (lufang)" >> > <[email protected]> >> > > > > wrote: >> > > > > >> > >> > > > > >> > >Don, >> > > > > >> > > >> > > > > >> > >I'm ok with what you said people need both L2 and L3 >> > > > > capabilities... >> > > > > >> > but >> > > > > >> > >have trouble with >> > > > > >> > >> IP VPNs and EVPNs are well suited as one solution for >> > > > extending >> > > > > >> the >> > > > > >> > L2 >> > > > > >> > >>and L3 connectivity for large and physically disperse >> data >> > > > > centers. >> > > > > >> > > >> > > > > >> > >What do you mean by "one solution"? They are two >> solutions >> > to >> > > > me. >> > > > > I >> > > > > >> > want >> > > > > >> > >to make sure that we are not redefining BGP L3VPN (RFC >> > 4364, >> > > > aka >> > > > > >> > 2547). >> > > > > >> > > >> > > > > >> > >Though E-VPN is leveraging many fundamental building >> blocks >> > > of >> > > > > BGP >> > > > > >> L3 >> > > > > >> > >VPN, it is essentially developed for people who must >> > support >> > > > > certain >> > > > > >> > >existing L2 services and prefer L2 solutions with E-VPN. >> If >> > > one >> > > > > >> wants >> > > > > >> > to >> > > > > >> > >have BGP L3 VPN solution only in the DC and inter- >> > connecting >> > > DC >> > > > > to >> > > > > >> the >> > > > > >> > >existing network l3vpn, or inter-connecting DCs, they can >> > use >> > > > BGP >> > > > > >> > L3VPN >> > > > > >> > >as its original form (if practical), or extend it to make >> > > more >> > > > DC >> > > > > >> > >friendly (e.g. draft-marques-l3vpn-end-system, as many >> > > pointed >> > > > to >> > > > > in >> > > > > >> > >their mails). >> > > > > >> > > >> > > > > >> > >L3 VPN has huge deployment base, mostly in SP network >> space >> > > > over >> > > > > the >> > > > > >> > last >> > > > > >> > >14 years or so, and some recent development in DC space. >> I >> > > > don't >> > > > > >> > assume >> > > > > >> > >you are implying to ask operators to change their L3VPN >> > from >> > > > 4364 >> > > > > >> > format >> > > > > >> > >into this so called "IP VPNs and EVPNs... as one >> solution", >> > > or >> > > > > ask >> > > > > >> > them >> > > > > >> > >to inter-work between existing L3VPN with this new "IP >> VPN >> > > and >> > > > > EVPN >> > > > > >> > ... >> > > > > >> > >as one solution" in DC, which would introduce complexity >> > for >> > > > > nothing >> > > > > >> > if >> > > > > >> > >they simply need the L3VPN from network to DC. I hope >> this >> > is >> > > > not >> > > > > >> the >> > > > > >> > >case. >> > > > > >> > > >> > > > > >> > >My point is, leave BGP L3VPN and EVPN as two separate >> > > solutions >> > > > > as >> > > > > >> > they >> > > > > >> > >are. >> > > > > >> > > >> > > > > >> > >Thanks, >> > > > > >> > >Luyuan >> > > > > >> > > >> > > > > >> > >> -----Original Message----- >> > > > > >> > >> From: [email protected] [mailto:nvo3- >> > [email protected]] >> > > On >> > > > > >> Behalf >> > > > > >> > Of >> > > > > >> > >> NAPIERALA, MARIA H >> > > > > >> > >> Sent: Monday, September 24, 2012 8:01 PM >> > > > > >> > >> To: Fedyk, Donald (Don); [email protected] >> > > > > >> > >> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane >> > > > > >> > >> >> > > > > >> > >> Don, >> > > > > >> > >> >> > > > > >> > >> > The complexity comes from the date center >> environment, >> > > but >> > > > > >> > >> > is seems better to provide both L2 and L3 >> capabilities >> > > and >> > > > > let >> > > > > >> > >> > deployments choose the mix. >> > > > > >> > >> >> > > > > >> > >> I am afraid that once you mix those capabilities in one >> > > > > >> > implementation >> > > > > >> > >> there is no choice. As a result, inter-subnet IP >> > forwarding >> > > > > which >> > > > > >> is >> > > > > >> > >> trivial in L3VPN (as is intra-subnet forwarding, btw) >> > > becomes >> > > > > all >> > > > > >> of >> > > > > >> > a >> > > > > >> > >> sudden complex under such construct. >> > > > > >> > >> >> > > > > >> > >> Maria >> > > > > >> > >> >> > > > > >> > >> > The nice property of BGP based IPVPN and EVPN is the >> > > > ability >> > > > > to >> > > > > >> > >> > partition the information such that the both L2 and >> L3 >> > > VPNs >> > > > > can >> > > > > >> > scale >> > > > > >> > >> > independently, each in context (for example VLANs, IP >> > > > VPNs). >> > > > > In >> > > > > >> > that >> > > > > >> > >> > sense IP VPNs and EVPNs are well suited as one >> solution >> > > for >> > > > > >> > extending >> > > > > >> > >> > the L2 and L3 connectivity for large and physically >> > > > disperse >> > > > > >> data >> > > > > >> > >> > centers. >> > > > > >> > >> > >> > > > > >> > >> > Don >> > > > > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > -----Original Message----- >> > > > > >> > >> > From: NAPIERALA, MARIA H [mailto:[email protected]] >> > > > > >> > >> > Sent: Monday, September 24, 2012 12:49 PM >> > > > > >> > >> > To: Fedyk, Donald (Don); [email protected] >> > > > > >> > >> > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control- >> plane >> > > > > >> > >> > >> > > > > >> > >> > Don, >> > > > > >> > >> > >> > > > > >> > >> > > Perhaps I'm missing something but I thought EVPN >> was >> > > > built >> > > > > >> using >> > > > > >> > >> many >> > > > > >> > >> > > of the same building blocks as RFC4364 so that it >> > could >> > > > be >> > > > > >> used >> > > > > >> > in >> > > > > >> > >> > > combination with EVPN. In other words IP VPN + >> EVPN. >> > > > > >> > >> > >> > > > > >> > >> > It needs to be explained why/what are the >> requirements >> > > that >> > > > > you >> > > > > >> > need >> > > > > >> > >> > both (IPVPN and EVPN) in the same solution because >> this >> > > is >> > > > > not a >> > > > > >> > >> > trivial complication. >> > > > > >> > >> > The complexity of the solution depends on the >> > > requirements. >> > > > > If >> > > > > >> > >> > majority of traffic in a (significant class of) data >> > > center >> > > > > is >> > > > > >> > inter- >> > > > > >> > >> > subnet, a solution should be optimized for such >> traffic >> > > > and, >> > > > > >> > hence, >> > > > > >> > >> > solving the forwarding of such traffic should be the >> > > > starting >> > > > > >> > point. >> > > > > >> > >> > >> > > > > >> > >> > Maria >> > > > > >> > >> > >> > > > > >> > >> > > -----Original Message----- >> > > > > >> > >> > > From: [email protected] [mailto:nvo3- >> > > > [email protected]] >> > > > > On >> > > > > >> > >> Behalf >> > > > > >> > >> > Of >> > > > > >> > >> > > NAPIERALA, MARIA H >> > > > > >> > >> > > Sent: Monday, September 24, 2012 10:09 AM >> > > > > >> > >> > > To: [email protected] >> > > > > >> > >> > > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control- >> > plane >> > > > > >> > >> > > >> > > > > >> > >> > > I think we should try to clarify what problems or >> > what >> > > > type >> > > > > of >> > > > > >> > data >> > > > > >> > >> > > centers specific solutions are addressing. >> > > > > >> > >> > > Specifically, EVPN can only address traffic bridged >> > in >> > > > the >> > > > > >> same >> > > > > >> > >> VLAN. >> > > > > >> > >> > > In data centers where most traffic is inter-VLAN, >> > i.e., >> > > > > >> packets >> > > > > >> > are >> > > > > >> > >> > > routed, the EVPN doesn't achieve much as an overall >> > > > > solution. >> > > > > >> > >> > > I tried to make this point on the webex during the >> > nvo3 >> > > > > >> interim >> > > > > >> > >> > session >> > > > > >> > >> > > when draft-drake-nvo3-evpn-control-plane was >> > discussed >> > > > but >> > > > > I >> > > > > >> am >> > > > > >> > not >> > > > > >> > >> > > sure if my message went through. >> > > > > >> > >> > > >> > > > > >> > >> > > Maria >> > > > > >> > >> > > >> > > > > >> > >> > > > -----Original Message----- >> > > > > >> > >> > > > From: [email protected] [mailto:nvo3- >> > > > > [email protected]] >> > > > > >> On >> > > > > >> > >> > Behalf >> > > > > >> > >> > > Of >> > > > > >> > >> > > > Thomas Nadeau >> > > > > >> > >> > > > Sent: Monday, September 17, 2012 11:55 AM >> > > > > >> > >> > > > To: [email protected] >> > > > > >> > >> > > > Subject: [nvo3] draft-drake-nvo3-evpn-control- >> plane >> > > > > >> > >> > > > >> > > > > >> > >> > > > >> > > > > >> > >> > > > A number of us just published this draft and >> > > wanted >> > > > to >> > > > > >> > >> bring it >> > > > > >> > >> > > > to the NVO3 WG's attention. We will be >> > > > > >> presenting/discussing >> > > > > >> > >> this >> > > > > >> > >> > > > draft at the interim meeting this week as well, >> but >> > > > > please >> > > > > >> > >> discuss >> > > > > >> > >> > > here >> > > > > >> > >> > > > on the list as well. >> > > > > >> > >> > > > >> > > > > >> > >> > > > Thanks, >> > > > > >> > >> > > > >> > > > > >> > >> > > > Tom, John, et al >> > > > > >> > >> > > > >> > > > > >> > >> > > > >> > > > > >> > >> > > > A new version of I-D, draft-drake-nvo3-evpn- >> > control- >> > > > > plane- >> > > > > >> > 00.txt >> > > > > >> > >> > > > has been successfully submitted by Thomas D. >> Nadeau >> > > and >> > > > > >> posted >> > > > > >> > to >> > > > > >> > >> > the >> > > > > >> > >> > > > IETF repository. >> > > > > >> > >> > > > >> > > > > >> > >> > > > Filename: draft-drake-nvo3-evpn-control-plane >> > > > > >> > >> > > > Revision: 00 >> > > > > >> > >> > > > Title: A Control Plane for Network >> > > > > Virtualized >> > > > > >> > >> Overlays >> > > > > >> > >> > > > Creation date: 2012-09-16 >> > > > > >> > >> > > > WG ID: Individual Submission >> > > > > >> > >> > > > Number of pages: 12 >> > > > > >> > >> > > > URL: http://www.ietf.org/internet- >> > > > > drafts/draft- >> > > > > >> > drake- >> > > > > >> > >> > > nvo3- >> > > > > >> > >> > > > evpn-control-plane-00.txt >> > > > > >> > >> > > > Status: >> > > http://datatracker.ietf.org/doc/draft- >> > > > > >> drake- >> > > > > >> > >> nvo3- >> > > > > >> > >> > > evpn- >> > > > > >> > >> > > > control-plane >> > > > > >> > >> > > > Htmlized: >> http://tools.ietf.org/html/draft- >> > > > drake- >> > > > > >> nvo3- >> > > > > >> > >> evpn- >> > > > > >> > >> > > > control-plane-00 >> > > > > >> > >> > > > >> > > > > >> > >> > > > >> > > > > >> > >> > > > Abstract: >> > > > > >> > >> > > > The purpose of this document is to >> describe >> > > how >> > > > > >> > Ethernet >> > > > > >> > >> > > Virtual >> > > > > >> > >> > > > Private Network (E-VPN) can be used as the >> > > > control >> > > > > >> > plane >> > > > > >> > >> for >> > > > > >> > >> > > > Network Virtual Overlays. Currently this >> > > > protocol >> > > > > is >> > > > > >> > >> > defined >> > > > > >> > >> > > to >> > > > > >> > >> > > > act as the control plane for Virtual >> > > Extensible >> > > > > Local >> > > > > >> > Area >> > > > > >> > >> > > > Network (VXLAN), Network Virtualization >> > using >> > > > > Generic >> > > > > >> > >> > Routing >> > > > > >> > >> > > > Encapsulation (NVGRE), MPLS or VLANs while >> > > > > >> maintaining >> > > > > >> > >> their >> > > > > >> > >> > > > existing data plane encapsulations. The >> > intent >> > > > is >> > > > > >> that >> > > > > >> > >> this >> > > > > >> > >> > > > protocol will be capable of extensions in >> > the >> > > > > future >> > > > > >> to >> > > > > >> > >> > handle >> > > > > >> > >> > > > additinal data plane encapsulations and >> > > > functions >> > > > > as >> > > > > >> > >> needed. >> > > > > >> > >> > > > >> > > > > >> > >> > > > >> > > > > >> > >> > > > _______________________________________________ >> > > > > >> > >> > > > nvo3 mailing list >> > > > > >> > >> > > > [email protected] >> > > > > >> > >> > > > https://www.ietf.org/mailman/listinfo/nvo3 >> > > > > >> > >> > > _______________________________________________ >> > > > > >> > >> > > nvo3 mailing list >> > > > > >> > >> > > [email protected] >> > > > > >> > >> > > https://www.ietf.org/mailman/listinfo/nvo3 >> > > > > >> > >> _______________________________________________ >> > > > > >> > >> nvo3 mailing list >> > > > > >> > >> [email protected] >> > > > > >> > >> https://www.ietf.org/mailman/listinfo/nvo3 >> > > > > >> > >_______________________________________________ >> > > > > >> > >nvo3 mailing list >> > > > > >> > >[email protected] >> > > > > >> > >https://www.ietf.org/mailman/listinfo/nvo3 >> > > > > >> >> > > > > >> _______________________________________________ >> > > > > >> nvo3 mailing list >> > > > > >> [email protected] >> > > > > >> https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
