Hi, comments inline: Sent from my iPad
On Jan 4, 2013, at 1:13 PM, "Bitar, Nabil N" <[email protected]> wrote: > 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. <TB> True. There is also the case when IP NVE end points need to join a larger EVPN domain that is provided on traditional MPLS nodes. We might not want to stitch IPVPN to EVPN but rather have EVPN at the NVE to join these other services. >> >> 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. >> >> 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
