Hi Nabil, > On 12/17/12 1:57 PM, "Kireeti Kompella" <[email protected]> > wrote: > > >On Dec 17, 2012, at 10:18 , "NAPIERALA, MARIA H" <[email protected]> > wrote: > > > >> Intra-subnet traffic can be also handled by a layer 3 overlay. > > > >Let me expand. > > > >I see the need for E-VPN for non-IP traffic. This is real, and is not > >met by IP VPNs (news flash!) > > <NB> Agreed. > > > >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.
This is about VM configuration models. The guest VM IPv4 configuration could be: A) local /32 IP address + /32 point-to-point route to a default gateway + default route. B) local /32 IP address + /24 to local Ethernet interface + default route to an address on that /24. Both those models are supported by draft-ietf-l3vpn-end-system-00. In the model B) a set of VMs are configured to belong to the same IP subnet (which is still often the case how the VM are being configured). Both models can be supported. In the case of B), the NVE implements proxy ARP for all the addresses on the /24. With proxy ARP, there is no difference between B) and A) with respect to forwarding. It is just that the virtual subnet has no locality across a data-center. > > > >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. Which IP applications (i.e., actual applications running in VMs) require bridging? > >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
