Hi Mingui, Thanks for the careful read. Comments inline.
--David > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Mingui Zhang > Sent: Sunday, February 15, 2015 4:43 AM > To: [email protected] > Cc: [email protected] > Subject: [nvo3] Section 4.4 Multi-Homing of NVEs/draft-ietf-nvo3-arch > > 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. Yes, although whether to allow this is something that the WG should discuss further; if this is allowed, prevention of hybrid loop formation (loop via VN on nvo3 side of NVEs and non-nvo3 interconnect of NVEs on other side) will need to be considered. > 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_. Ok, the intent was "to support one-to-many mapping" and I understand the clarification that the table may not always need to do that. It looks like "mapping tables" -> "mapping functionality" would address this concern - is that sufficient? > 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. Please suggest a specific rewording for this concern. The complete sentence is: Having only a single physical path to an upstream NVE, or indeed, having all traffic flow through a single NVE would be considered unacceptable in highly-resilient deployment scenarios that seek to avoid single points of failure. In particular, the expected response to LAG link failure would cause the traffic involved to switch NVEs; prohibition of that response would result in a single point of failure. > Thanks, > Mingui > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
