Dino Farinacci <[email protected]> writes: > >>> The NVE is normally very close to the TS, i.e., on the same server, or >>> offloaded to the ToR. > >> I know of deployments where the NVE equivalent is at the end-of-row >> router. > > But lets deal with the common/expected case. That starts with NVEs > co-located with the hypervisors.
Why is that an expected case? I guess host vendors or software-only vendors would appreciate that but I'm sure equipment vendors would not. > One important reason that NVEs tend to be close to the TS is that you > can deploy things that way with little or no change to the underlay. At the cost of lost aggregation. There are pros and cons either way. >> TS is a single host endpoint. It connects directly to a virtual >>> network through an NVE. > >> What do you call a multi-tenant rack? In deployments, a tenant is a >> customer of the provider where there are many 'systems' in the >> tenant, each with one or more IP addresses assigned to them. > > Different kind of tenant. If you have a tenant (say coke) that has a > virtual network with (say) 100 VMs on it that talk to each other, each > VM is a TS and connects to an NVE. It is is a VPN with say 10 sites, each with your 10 VMs, then each site could share an NVE. > Sending is not the interesting case and is a bit off topic. It is >> return packets and which (or both) NVEs is used as the target of >> encapsulation. > > Agree... > >>> >>>>> Is this something we need to support? I agree it has some >>>>> benefits. But it also adds some complications... >>>>> >>>>> Thomas >>> >>>> It depends how close topologically the NVE is to the endpoint. If >>>> the NVE was in the application, then for the same IP address there >>>> would be multiple NVEs. So the point could be taken to an extreme. >>> >>> In the virtualized case, the NVE is on the same server as the >>> VM/TS. In the bare metal case, the NVE is offloaded onto an adjacent >>> device (e.g., ToR), but is still quite close. >>> >>> Thomas > >> You are assuming a specific implementation of an NVE and where it >> resides. That should be be assumed in the architecture IMO. > > You presumably mean "should not be assumed". Yes, that was a typo. > Well, the truth is that NVEs have been assumed to be close to the TS > from day one... And one reason is that if you push the NVE out further > and further away from the TS, it adds complications. We shouldn't do > that unless necessary. > > Thomas You can see by now is that my point is that architecturally you shouldn't say where NVEs are or how they are implemented (in software, hardware or combo software/hardware). I will argue that if you push an NVE further out there are less of them to manage so you get OpEx benefits. Dino _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
