Hi authors, Multi-homing of NVEs means one Tenant System (TS) is attached to multiple NVEs or a single NVE which has more than one underlay IP addresses. When this TS communicates with a TS attached to a remote NVE, this remote NVE will see one TS address being mapped to multiple NVE IP addresses.
When I read the text of Section 4.4, I find there are several places where the description might not be accurate. 1. "That is, an NVE may have more than one IP address associated with it on the underlay network." >From your second multi-homing scenario we know that even one NVE has only one >IP address, it is also possible for it to offer multi-homing when this NVE is >one of the multiple NVEs to which a TS is connected. 2. "In both cases, the NVE address mapping tables need to support one-to-many mappings..." This is inaccurate because there are ways to avoid installing multiple (TS-Addr->NVE-Addr) mapping per TS-Addr into mapping tables. For example, the NVE can keep the one-to-many mapping at the control plane or management plane while installs an one-to-one mapping into the mapping table. In other words, the NVE need to support one-to-many mapping but it does not have to support it using its _mapping tables_. 3. "...or indeed, having all traffic flow through a single NVE would be considered unacceptable..." The bare metal server may have multiple uplink connections to this NVE and these connections are implemented using LAG. Hence, we know that even it *is* all traffic flow through a single NVE, it can still be acceptable (desirable). I suggest we reword the text to fix above issues. Thanks, Mingui _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
