If you "route if IP, bridge otherwise", the Ethernet header for IP packets is pretty much just framing; the DA shouldn't matter. To avoid confusion, have the NVE be the gateway router, and also respond to all ARPs with its own MAC. Then all IP frames will have a DA of the NVE. That keeps things clean, and "route if IP, bridge otherwise" falls out naturally.
Kireeti On Dec 27, 2012, at 1:02, "Vivek Kumar" <[email protected]> wrote: > Hi Kireeti, > One clarification . When you say "route if IP, bridge otherwise" , did you > mean that all IP packets should be routed even if they come without router > MAC address ( MAC-DA doesn't match the router address) ? > > Regards, > Vivek > > > Date: Wed, 26 Dec 2012 18:48:59 -0800 > From: Kireeti Kompella <[email protected]> > To: Lucy yong <[email protected]> > Cc: Thomas Narten <[email protected]>, "[email protected]" > <[email protected]>, Aldrin Isaac <[email protected]>, "NAPIERALA, > MARIA H" <[email protected]> > Subject: Re: [nvo3] Multi-subnet VNs [was Re: FW: New Version > Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt] > Message-ID: > <CABRz93VCm57rc59SdWNuDZuQRfbv_0=ko99mnttrfocysmh...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Lucy, > > On Wed, Dec 26, 2012 at 8:33 AM, Lucy yong <[email protected]> wrote: > >> Kireeti,**** >> >> ** ** >> >> It seems that you make EVPN and IPVPN orthogonal now: If IP, use IPVPN, if >> not, EVPN.**** >> >> ** ** >> >> Do you also see that the end system can be distinguished this way?**** >> >> ** ** >> >> Using IP VPN for all the IP applications is good in one way, but it >> requires the substantial changes on all the hosts/hypervisor and require >> the behavior changes on the VM/physical server. Giving millions VM/servers >> are there, will this realistic? Why do we ask all the tenant systems to >> change behavior in order to use of IPVPN? > > The only change needed is on the NVE. If this resides in the > host/hypervisor, so be it. The NVE has to change to implement IP VPN/EVPN. > The additional change to "route if IP, bridge otherwise" is minor. > > No change is needed on the VM/tenant system. > > BTW, as an example, IRB (if my MAC, then route else bridge) is completely > transparent to the end host (VM, tenant system). > > Kireeti. > > IMO, IPVPN is very useful for many applications and it is also necessary >> to support multi-tenancy in DC without changing tenant system behavior.*** >> * >> >> ** ** >> >> Thanks,**** >> >> Lucy **** >> >> ** ** >> >> *From:* [email protected] [mailto:[email protected]] *On Behalf >> Of *Kireeti Kompella >> *Sent:* Friday, December 21, 2012 10:21 PM >> *To:* NAPIERALA, MARIA H >> *Cc:* Thomas Narten; [email protected]; Aldrin Isaac >> *Subject:* Re: [nvo3] Multi-subnet VNs [was Re: FW: New Version >> Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt]**** >> >> ** ** >> >> Hi Maria,**** >> >> ** ** >> >> On Dec 20, 2012, at 13:36, "NAPIERALA, MARIA H" <[email protected]> wrote:*** >> * >> >> The question is what problem does EVPN solve? **** >> >> Pure layer 2 traffic. Yes, it does exist, and needs to be dealt with >> properly. But just that. **** >> >> In the context of DC, EVPN can only address packets bridged in the same >> VLAN. If most packets are routed then EVPN, even if all the complexity >> problems are addressed, doesn't achieve anything for the traffic that is >> routed. I believe it is the wrong tradeoff to design a solution around EVPN >> (i.e., around bridging).**** >> >> Agreed.**** >> >> ** ** >> >> Kireeti. **** >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > > > -- > Kireeti > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
