Support WG adoption if the following comments can be addressed: Issues with the current writing of Distributed Gateway (Section 5.4): As described in Section 5.3, a Gateway does many things. However, I don't think that a NVE, if taking on the responsibility of a distributed Gateway, will do all the things that a conventional Gateway does (or the list of items mentioned in the Section 5.3).
First, it might be too much to ask a NVE based gateway (especially Hypervisor based NVE) to * relay traffic off the virtual networks, i.e. perform gateway function to reach destinations outside the local VNs, * Interface with external VPN domain (i.e. out of Virtual Networks), * perform NAT on the source virtual addresses, or * relay traffic to a VN that doesn't have any hosts attached to the NVE (it is debatable if a NVE based distributed Gateway should take this responsibility) The real functions performed by NVE, if designated as "distributed gateway", is more like Inter-VN relay (instead of full blown Gateway function). Second, when host "a" in VN-1 sends traffic to "b" in VN-2, the data packet's Ethernet header has "MAC-DA = Gateway-MAC & MAC-SA= a-MAC & VLAN= VN-1". Most implementations (Microsoft Window 8 and VM NSX) allocate a "fake MAC" for all the NVE based distributed gateways to share, so that host "a" can use the same Gateway-MAC when moved to another NVE. This again is different from the conventional gateways. Third, the issue of conventional gateway (i.e. a->b traffic to be routed at gateway even if "a" & "b" are attached to the same NVE) is traffic "hairpinning", instead of triangular routing. Therefore, I suggest rewriting Section 5.4 as below: 5.4 Distributed Gateway (Re-write) The relaying of traffic from one VN to another, especially when Source and Destination are attached to the same NVE, deserves special consideration. With conventional Gateways, the traffic between TSes on different VNs has to be traversed to the gateway, even if the Source and Destination are attached to the save NVE, which causes traffic hairpinning and wasted bandwidth. As an optimization, it is desirable for individual NVEs to take over the inter-VN relay responsibilities that are traditionally done by conventional gateways to reduce or eliminate hairpinning issue. In order for NVEs to perform inter-VN relay, the NVEs must have access to the policy information needed to determine whether inter-VN communication is allowed. Those inter-VN communication policies are most likely to come from NVA. However, it is not practical for NVEs to take over all functions of conventional gateways. In particular, it might be too much to ask a NVE based gateway (especially Hypervisor based NVE) to * relay traffic off the virtual networks, i.e. perform gateway function to reach destinations outside the local VNs, * perform NAT on the source virtual addresses, or * relay traffic to a VN that doesn't have any hosts attached to the NVE. The NVEs that are capable of performing inter-VN replaying are called "Distributed Gateway" in this document. (Note: Inter-VN relaying capable NVE is a more accurate term). The NVO3 architecture should support distributed gateways, at least allowing some NVEs, if not all, supporting the inter-VN relaying function, especially when both source and destination are attached to the same NVE. Such support requires the NVO3 control protocols include mechanisms for the maintenance and distribution of the inter-VN policy information to the NVEs that are capable of performing inter-VN communications. ---------------------------------------- Thanks for considering my suggested text. Linda Dunbar From: [email protected] [mailto:[email protected]] On Behalf Of Bocci, Matthew (Matthew) Sent: Wednesday, November 13, 2013 7:58 AM To: [email protected] Subject: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt This email begins a two week poll to help the chairs judge if there is consensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working group draft. Please respond to this email on the list with 'support' or 'do not support'. Please also send any comments on the draft to the NVO3 list. Please consider whether this draft takes the right basic approach, and is a good basis for the work going forward (and potential future rechartering). It does not have to be perfect at this stage. Coincidentally, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor. If you are on the NVO3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll closes on Friday 29th November 2013. Regards Matthew and Benson
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
