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. 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. > > 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. > 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". 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
