Hi Kireeti, Thank you to make it clear.
You can implement this way for "route if IP". However, this prohibits some other use cases. For some heavy policy enforced inter-subnet routing, operator may want to place gateway router in few places for easier management, i.e. not on every NVE, and use L2 overlay to bridge TSes and gateway router. In this scenario, the gateway router does not have the way to control ARP protocol behavior in L2 overlay. To make it work, the gateway router has to control its own ARP message reply. IMO: this is also a useful use case, and use bridge and route for IP. Furthermore, to implement this way, essentially you have p2p virtual link between a TS and NVE, which may be applicable for some use cases but not other. Regards, Lucy > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Kireeti Kompella > Sent: Thursday, December 27, 2012 9:10 PM > To: Vivek Kumar > Cc: [email protected] > Subject: Re: [nvo3] Multi-subnet VNs [was Re: FW: New Version > Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt] > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
