Hi David, >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.
According to my envision, the first (single NVE multiple IPs) and second scenarios (multiple NVEs and each with its IP) are just the same to the hybrid loop formation you mentioned. That is, the "non-nvo3 interconnect of NVEs on the other side" will see the one-to-many mapping of TS-Addr->NVE-IP-Addr and it is required to handle this kind of mapping correctly. Actually, the first issue comes into my mind is the MAC flip-flop issue though there may be other kinds of issues, such as duplication, loop, black-hole, etc. But I believe we can design solutions to solve all these issues, as long as the remote NVE can sense all NVEs in a multi-homing group. >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? Yes, I think that is sufficient. Thanks. >Please suggest a specific rewording for this concern. The complete >sentence is: <snip> How about we just replace the NVE with VAP in the sentence? That is, OLD 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. NEW Having only a single physical path to an upstream VAP, or indeed, having all traffic flow through a single VAP would be considered unacceptable in highly-resilient deployment scenarios that seek to avoid single points of failure. Of course, we may need update some other sentences if we take this. >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. The VAPs connected to one end of the LAG may reside in one NVE or multiple NVEs. In either way, the single failure of a VAP will not fail the whole LAG. Thanks, Mingui >-----Original Message----- >From: Black, David [mailto:[email protected]] >Sent: Tuesday, February 17, 2015 7:14 AM >To: Mingui Zhang; [email protected] >Cc: [email protected]; Black, David >Subject: RE: Section 4.4 Multi-Homing of NVEs/draft-ietf-nvo3-arch > >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
