One comment inline. > >> > >> For IP traffic, whether intra and inter-subnet, IP VPNs suffice. > > > > <NB> Please, see my other emamil and interested in your opinion. If > we > > always route when the Ethernet payload is an IP packet, then there is > no > > meaning for a suvnet at least it seeems to me. In another words, why > not > > say every subnet is 32 in case of IPv4, and /128 in case of IPv6. > > <TB> I would say the subnet becomes abstracted. That's the beauty to it. > Subnet now does not define broadcast domain, but rather host limit. [Lucy] Does it imply that an IP host should not send broadcast traffic? Will it a beauty or reduce the network capability. Of cause, if no such need in nvo3, removing it means simplification, which is good.'
Lucy > > >> > >> The solution is simple: route if IP, bridge if not. > > > > <NB> While I see good reasons and maybe the desire to do that, I am > not > > sure that the rule applies always and as it may be dependent on the > > application. > > > >> Yes, one could do IRB, but why? IRB brings in complications, > especially > >> for multicast. I'm sure someone suggested this already, so put me > down > >> as supporting this view. > > > > <NB> So, just for clarity, for unicast, implementation wise it canbe > done > > at least with not much complication as documented elsewhere. For > instance > > when you support such a mode, the VM can send inter-subnet traffic to > a > > secial MAC address that triggers IP lookup in a VRF (e.g., similar to > be > > being a default GW for a subnet).What is wrong with that? > > For multicast, there could be multiple options, including using IP > > multicast only when the application is IP multicast. Again, > interested in > > the complicated parts and options looked at as the note seems to > indicate. > > > >> > >> A NVE that supports both E-VPN and IP VPN for a given tenant simply > sends > >> IP traffic to the IP VPN and sends the rest to E-VPN. How this > happens > >> is implementation specific. Note that this assumes that the NVE > >> intercepts ARPs and responds to them with the same MAC. Does anyone > see > >> a problem with this? > > <NB> Wouldn't that ARP interception and responding with own MAC > prevents > > the first what is implied in the first sentence unless you are > implying > > that traffic from a VM can be either sent on e-VPN or an IP-VPN but > not > > both depending on where the traffic is destined which bring us to the > > above discussion. > > To the last statement, in E-VPN case the NVE should reply with the IP > > destination MAC learned vua BGP and not with it own MAC, right? > > > > > >> > >> If there is a case for _only_ intra-subnet traffic, one may create > an > >> E-VPN to handle both IP and non-IP; but I suspect this is a rare > case. > > <NB> SO, there may be a thread on that and I know that was discussion > in > > other contexts. I cannot see how this cane in E-VPN unless we carry > IP > > routes that belong to an IP VPN in BGP advertisements, which is not > pure > > E-VPN. E-VPN today carries ARP entries for the Vms that are connected > to > > the same E-VPN, but not other routes. Multiple E-VPN instances can > belong > > to the same IP VPN. FIBs would have to be appropriately built as well. > I > > am not sure of the work involved here. I can see logically though how > what > > is suggested above and elsewhere to bridge and route can work. > > > >> > >> From that point of view, I would like to see E-VPNs in the data > center > >> *always* coupled with IP VPNs, and only dealing with non-IP traffic. > > <NB> Pleas,e see above on assuming that whenever the Ethernet payload > is > > IP you route. > >> > >> This may appear drastic, but I think operationally, this is will > simplify > >> things. As always, I am open to alternate suggestions, provided > they are > >> presented without religion or politics. I'm especially keen to hear > from > >> those deploying. > >> > >> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
