Just wanted to add that the terms "NIC-teaming", NIC-bonding","port-channel" "LAG" "LACP" are all referring to case c) when combined with two physical links towards two different physical devices implementing the NVE side (potentially vendor dependant either one NVE distributed across 2 physical devices or two NVE. In any case, the single NVE or the both NVEs terminate the two physical links and hide the fact that they are two physical interfaces from their upper layers, by pretending they can be accessed like a single physical interface, due to the fact that a single MAC-Service Access Point is presented to the upper layers, which may switch locations when the active/passive sub-state changes.
Kind of magic, but I am aware of at least 3 or 4 different vendor implementations of such multi-chassis LAG behavior. And I like to note that some legacy OSS systems may have trouble coping with logical devices distributed across multiple physical devices, making the IT for provisioning and assurance quite expensive or suboptimal due to workarounds being applied, which complicate things over time. Please keep in mind that at the end of the day, operators need to map the NVE in their inventory systems, correlate alarms for assurance etc. It would be a nightmare, if different vendors implement the obviously required NVE redundancy in fundamentally different ways such as some vendors implementing an NVE in a way that his has one location, and another vendor where an NVE has multiple locations. This may even lead to vendor specific assurance processes - an absolute No-Go for carriers if they are not insane. Lothar -----Ursprüngliche Nachricht----- Von: nvo3 [mailto:[email protected]] Im Auftrag von Reith, Lothar Gesendet: Donnerstag, 21. November 2013 01:03 An: Dino Farinacci; Thomas Narten Cc: [email protected]; Linda Dunbar Betreff: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] Dear friends, are we sure everybody is on the same page? Please make sure we are all talking about use case a) below when we use the term "multi-homing", and not referring to use cases b),c) or even d). Two physical links from a bare metal server representing the equivalent of a single VM interfacing to two different physical devices can be implemented in the following use case scenarios: a). Layer 3 Multihoming with two different underlying layer 2 networks (i.e. the VM or bare metal server has two different TSIs each interfacing to a different Gateway IP) b). Layer 3 VRRP based Gateway redundancy with both physical links being part of the same layer 2 network, which has 3 endpoints, however 2 of them share the same MAC and IP address which floats between the two physical devices as virtual IP address and virtual MAC address of one virtual gateway that is redundant because it is distributed/split across two physical devices. In order not to be confused with the term distributed gateway, this redundant gateway can be one local portion of a distributed gateway in the previously discussed sense, where the portions of the distributed gateway may even be distributed across multiple autonomous systems (if I understand this correctly). c). Layer 2 bonding/Link aggregation based with LACP controlled active/passive mode or less likely also supporting active/active mode: Both Tenant system sided physical link endpoints are a member of a normal LAG (bonding group), while both corresponding NVE sided physical link endpoints are also bonded together to form a single MAC-Service Access Point using a potentially proprietary multichassis LAG implementation, where the control plane for cross-synchronization between both NVE sided endpoints may be via Layer3 or via Layer2, and where implementations may be vendor specific and differ with respect to whether the NVE is one logical device distributed across two physical devices, or two logical NVE devices (one per physical device). In any case both physical devices are cooperating somehow to pretend to the other side of the point to point layer 2 network that they implement a single aggregated layer 2 interface (most likely only supporting active/passive mode where only one of the two physical links is active carrying user plane traffic at any one time). d). For completeness: Layer 1 bonding is also possible, but might be neglected here. Lothar -----Ursprüngliche Nachricht----- Von: nvo3 [mailto:[email protected]] Im Auftrag von Dino Farinacci Gesendet: Mittwoch, 20. November 2013 19:11 An: Thomas Narten Cc: [email protected]; Linda Dunbar Betreff: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] "Dino, > >> Thomas, just be aware that in the physical case, a server is dual >> attached to multiple TORs. If each TOR is going to be an NVE, >> because you want to save state in the data center core layer, then >> you'll have to do multi-homing. > > I suspect we need to dive a bit deeper into this. i.e., what does > "dual attached" mean? A bare-metal server has 2 physical connections to different boxes (where a box is a swtich or a router). In some cases, the 2 connections are active/active, but mostly active/backup. There is some assumption from the server OSes that the upstream boxes are layer-2 switches. But it doesn't have to be the case, they can be layer-3 routers. > Do you mean the NVE has two physical connections to the ToR? If so, No, that would be the NVE being able to get ECMP support from the underlay. I am talking about the NVE in the TOR, as one example. > than the question presumably is about allowing/supporting multi-homed > NVEs. That is right Thomas. > If the question is about the TS having two attachements to the ToR, > wouldn't that be modeled (architecturally) as two distinct > interfaces/ports, in which case each one can connect to its own NVE, > in which case we are good? The questions is about the return traffic coming to the TS. Do you want it load-split across all the NVEs associated with the TS. The answer is a definite yes, as Joel stated for robustness and to take advantage of all cross-sectional cheap bandwidth in a data center. Dino > > Thomas _______________________________________________ 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
