The I-D for "Multi-homing of NVEs" was uploaded. You may want to take a look at it.
http://tools.ietf.org/html/draft-zhang-nvo3-active-active-nve-00 Thanks, Mingui >-----Original Message----- >From: Black, David [mailto:[email protected]] >Sent: Tuesday, February 17, 2015 11:15 AM >To: Mingui Zhang; [email protected] >Cc: [email protected]; Black, David >Subject: RE: Section 4.4 Multi-Homing of NVEs/draft-ietf-nvo3-arch > >> >> 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? > >This is an architecture draft, so (IMHO) the answer is "yes, both" and the >network >perspective is definitely important. > >Thanks, >--David > > >> -----Original Message----- >> From: Mingui Zhang [mailto:[email protected]] >> Sent: Monday, February 16, 2015 9:47 PM >> To: Black, David; [email protected] >> Cc: [email protected] >> Subject: RE: Section 4.4 Multi-Homing of NVEs/draft-ietf-nvo3-arch >> >> 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
