Hi David, Inline below with [Mingui].
>-----Original Message----- >From: Black, David [mailto:[email protected]] >Sent: Tuesday, February 17, 2015 10:13 AM >To: Mingui Zhang; [email protected] >Cc: [email protected]; Black, David >Subject: RE: Section 4.4 Multi-Homing of NVEs/draft-ietf-nvo3-arch > >Inline ... --David > >> -----Original Message----- >> From: nvo3 [mailto:[email protected]] On Behalf Of Mingui Zhang >> Sent: Monday, February 16, 2015 9:00 PM >> To: Black, David; [email protected] >> Cc: [email protected] >> Subject: Re: [nvo3] Section 4.4 Multi-Homing of NVEs/draft-ietf-nvo3-arch >> >> 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. > >I don't agree - if any TS is only connected to one NVE, then this sort of loop >prevention can be accomplished by ensuring that traffic received at an NVE >from another NVE is always forwarded to the non-nvo3 side of the NVE and >never >onward to another NVE. The number of IP addresses is irrelevant. [Mingui] OK. They are the same to part of the issues (e.g., the MAC flip-flop issue). For the loop issue they do have some difference in detail. [Mingui] For the scenario that one TS is connected to multiple NVEs, the counter measure is quite similar as you described above. We also ensure that traffic received at an NVE from another NVE (in a multi-homing group) always forwarding to the non-nvo3 side of the NVE and never onward to another NVE. Moreover, traffic from received at an NVE1 from another NVE2 (these two NVEs are in the same group) MUST NOT be forwarded to the non-nvo3 side of the NVE1 since the traffic has already been forwarded by NVE2. > >> 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. > >And I think the WG gets to decide whether to take on this set of issues. [Mingui] If multi-homing is what we need, then I suggest we take on these issues:). > >> >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. > >Ok, one down ... > >> >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, > >I don't understand how this would address the concern, because each VAP is >bound to a single NVE - see Section 4.5. One could have multiple VAPs on >the same NVE, but the sentence is concerned with NVE failure, not just VAP >failure. [Mingui] Well, the TS may only concern with the VAP. It is the service point the TS is attached to. We should concern the issue from the angle of TS or from the angle of the network? [Mingui] NVE failure will definitely lead to VAP failure (s). That means the cases of VAP failures can cover the cases of NVE failures from the angle of TS. > >> >> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
