Pankaj, Of course, NVE-NVE protocol can add benefits, but it also adds cost. A good design is not about if there is nothing to add, but about if there is nothing that can be removed. If most TSes are only attached to a single NVE and traffic to NVEs are not aggregated flows, then the NVE-NVE control plane protocol doesn’t provide much benefits. Under this environment, the difference between having “NVE-NVE control protocol" is whether the packets being dropped at the Ingress NVE or somewhere in the underlay network when egress NVE is not reachable. In data center environment where most communications are among applications, most likely a source will not send more packets without acknowledgment from the destination. Then the impact of where the packet is dropped is not that big. Therefore, I think it is worthwhile to have a subsection in the architecture document to describe this trade-off. It is not clear-cut "must have" or "must not have". Here is my suggested subsection: --------------------------------------------------
4.4 Is it necessary to have Inter-NVE control plane protocol? (Suggested new sub-section) There could be various reasons, link failure, node failure, or others, causing egress NVEs not reachable. Without any NVE<->NVE control plane protocol, the ingress NVE is not aware of the reachability of egress NVE causing encapsulated packets to dropped somewhere in the underlay network. If most TSes are only attached to a single NVE and traffic to NVEs are not aggregated flows, then the NVE-NVE control plane protocol doesn’t provide much benefits. Under this environment, the difference between having “NVE-NVE control protocol" is whether the packets being dropped at the Ingress NVE or somewhere in the underlay network when egress NVE is not reachable. In data center environment where most communications are among applications, most likely a source will not send more packets without acknowledgment from the destination. Then the impact of where the packet is dropped is not that big. However, in an environment where TSes are connected to multiple NVEs, then it might be worthwhile to consider the Inter-NVE control plane protocol, so that ingress NVE can choose different egress NVE for a given target. Linda > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Pankaj Garg > Sent: Tuesday, November 19, 2013 6:37 AM > To: Ken Gray; LASSERRE, MARC (MARC); Thomas Narten; Yves Hertoghs > (yhertogh) > Cc: [email protected]; Lucy yong > Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for > WG adoption and IPR check for draft-narten-nvo3-arch-01.txt > > NVE-NVE control plane is needed for operations that don't necessarily > need NVA interaction or where NVE-NVE interaction can provide better > performance. > > For example, if the "mappings" are stale on an NVE, then the receiver > NVE can send a control plane message to the sender NVE to update its > mappings. This can happen due to events where the VM live migrated from > one host to another but the sender NVE has stale mappings due to delay > in getting those mappings updated via NVA. Think of this as a hint for > cache flush from the receiver NVE to the sender NVE. > > The control plane between NVE-NVE can also be used for protocol > negotiation in case of multi-protocol support at NVE. > > Pankaj > > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Ken Gray > Sent: Tuesday, November 19, 2013 12:55 AM > To: LASSERRE, MARC (MARC); Thomas Narten; Yves Hertoghs (yhertogh) > Cc: [email protected]; Lucy yong > Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for > WG adoption and IPR check for draft-narten-nvo3-arch-01.txt > > I don't think the logical association of the NVA with an NVE negates > Thomas basic point. The key word you use here is "appears" ... in the > end, it's not the NVE that other NVEs are exchanging mapping > information with, it is the NVA that is co-located. > > +1 for Thomas proposal. YES, you can make it more explicit in the > architecture that "mapping" is what you are talking about instead of > the generic "control". > > We can beat NVE-NVE liveliness to death with other truncheons. > ________________________________________ > From: [email protected] <[email protected]> on behalf of > LASSERRE, MARC (MARC) <[email protected]> > Sent: Monday, November 18, 2013 6:58 AM > To: Thomas Narten; Yves Hertoghs (yhertogh) > Cc: [email protected]; Lucy yong > Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for > WG adoption and IPR check for draft-narten-nvo3-arch-01.txt > > Thomas, > > The way that you have phrased this sentence is confusing and needs > clarification. > > Various control protocols can be used between NVEs, as you indicated. > > If you meant to say that there is no need for NVEs to exchange address > mapping information between themselves, this is also debatable. > An external NVA for such a function is not always required in nvo3. > When the NVA address mapping function is colocated with an NVE, NVEs > appear as exchanging address mapping information (just looking at the > wire). IGPs within NVEs also exchange topological/address mapping > information. > > Marc > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Thomas Narten > > Sent: Friday, November 15, 2013 11:19 PM > > To: Yves Hertoghs (yhertogh) > > Cc: [email protected]; Lucy yong > > Subject: [nvo3] No need for NVE-NVE control plane [was Re: > > Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt > > > > NVO3 does not need an NVE to NVE control protocol. > > > > Calling this out explicitly, as it is consistent with the current > > architecture document. There is no need for an NVE to NVE control > > protocol, for the purpose of maintaining/populating the mapping > > tables. There may well be interactions between NVEs, such as setting > > up tunnels, creating security associations for protecting data plane > > traffic, or providing error indications (e.g., equivalent of ICMP "TS > > unreachable" responses). > > > > If folk disagree, now would be a good time to have that conversation. > > > > "Yves Hertoghs (yhertogh)" <[email protected]> writes: > > > > > >> I disagree with the need for an NVE to NVE control plane. > > > > > > > [Lucy] do you think we need NVE-NVE control plane? I > > don’t think > > > > this is what you mean from the following statement. > > > > > > No we dont need an NVE to NVE control plane. > > > > > > >> That doesn't mean that you can't colocate a portion of the > > > >> distributed NVA with every NVE, which is the model that e.g. > > > >> BGP/L3VPN or ISIS/TRILL uses. > > > > > > > [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). > > > > > > And as a result there is only a need for a control plane > > between the > > > NVE function and the NVA function. > > > > Thomas > > > > > _______________________________________________ > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
