Thomas, Since there are quite a few people stating that NVE-NVE control plane is needed for NVO3, the architecture document should at least have a sub-section describing the trade-off of having NVE-NVE protocol.
Even with one TS being connected to one NVE, there are people saying that one NVE could have two different uplink ports to underlay network, therefore might have two different IP addresses. My counter-argument is that NVE should use its loopback IP address and can have different MAC addresses for its different uplink ports or use NIC-Teaming for its multiple ports. I think that my suggested subsection is necessary to describe the trade-off and to make WG feel that their comments are well addressed. Granted that NVE-NVE protocol does provide some value, like notifying each other the directed attached TSes when NVA is not reachable, etc. NVO3 architecture doesn't have to "require this protocol", but doesn't have to " explicitly exclude this protocol " either. Again here is my suggested new subsection (with minor change to address Pankaj's comments: ----------------------------------- 4.4 The trade-off of Inter-NVE control plane protocol (Suggested new sub-section) There could be various reasons, link failure, node failure, or others, causing egress NVEs (or even NVA) 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 value provided by NVE-NVE control plane protocol is not significant compared to the extra cost added to NVE. When one NVE has multiple uplink ports to the underlay network, it is recommended to use NVE's loopback address instead of port addresses to avoid the complication on ingress node in determining which address to use. 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 or high chance of connection failure between NVE & NVA, 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: Thomas Narten [mailto:[email protected]] > Sent: Wednesday, November 20, 2013 11:07 AM > To: Linda Dunbar > Cc: [email protected] > Subject: TS conects to VN through one NVE [was 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] > > Linda, > > > 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. > > I want to flag the first part of the sentence above because this > question has been raised before. It suggests that a TS might connect > to more than one NVE at a time. > > From an architectural perpsective, I think we should say "no". Life is > much simpler if a TS connects to a VN through exactly one NVE. More > precisely, a TSI always connects to one NVE. If we allowed connections > to multple NVEs simultaneously, it would raise all sorts of questions > as to when to use one over the other, etc. > > I don't think I'm actually saying anything new with this... I've > always assumed this, documents are written with this in mind, and it > hasn't come up (other than in passing) on the list. > > A TS can still connect to multiple different VNs through different > network interfaces, and hence different TSIs, but I think we should > have a TSI always connect to exactly one NVE. > > Any other opinions? > > Thomas >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
