Hi, Please, see inline. Thanks, 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. > >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
