> Dino Farinacci <[email protected]> writes: > >>> Scenario 1: Bare metal server has 2 separate connections to two >>> different boxes. How are these two connections presented to the >>> (bare-metal) TS? > >> I am going to fail at describing this with the NVO3 terminology. A >> TS to me is a site, that has lots of hosts, switches, routers in >> it. They are addressable. I call those addresses EIDs. So we are >> talking about a single EID. An IP address assigned to a bare-metal >> server that has two connections, one to each physical NVE. > > A TS is Tenant System. E.g., a VM on virtualized host, or the bare > metal server in your original example. > > 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. > >>> 1A) two different interfaces are visible to the TS, both with their >>> own separate IP addresses. This is not an issue for NVO3, since this >>> is modeled as two interfaces to two separate VNs. (Right?) > >> I can't answer this because I am not sure you and I agree on what a >> TS is. I am not disagreeing how NVO3 defines a TS but I think it is >> not specific enough for this context. > > 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. > >>> B) TS sees only one interface, the CNA hides the details of two >>> physical uplinks from TS. Links could be active/active or >>> active/backup. In this case, the TS has one IP adddress (I presume) >>> with the CNA hiding the details of multiple uplinks from the TS. >>> >>> This is a messier case... Do both uplinks have to connect to the same >>> NVE? In the standard L2 case, don't both L2 uplinks have to connect to >>> the "same L2 network"? That only means that both ToRs would need to >>> support the same VLANs and connect to the same LAN domains. (Right?) > >> Yes, they have to connect to the same L2 network. > > The difference is in the L2 case, you can send a packet up either > uplink and things generally work (you may still have to deal with MAC > flapping concerns). In the NVO3 case, if the two upstream NVEs are > different, they will have their own IP addresses and the tunnel source > for packets they send to remote NVEs will be different depending on > which NVE is the sender. 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. > >>> If above we allow the two uplinks to go to two different NVEs, the >>> implication is that from an NVO3 perspective, a given TS mapping is >>> reachable through different NVE addresses. That raises all sorts of >>> interesting questions. :-) > >> This called multi-homing. ;-) That is equivalent to a LISP EID that >> has a locator-set. The reason there is a locator-set is because >> there can be multiple RLOCs (read: NVEs) used reach the EID. > > Right. > > The WG just hasn't had much discussion about whether NVEs need to be > multi-homed. So we don't really have a position yet. Yes, right, why we are bringing it up now. > >>> 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. Dino _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
