Hi Vishwas, I do not disagree with what you said. A lot of applications do need a centralized gateway, especially a VN interconnecting with WAN and Internet. The nvo3-nve draft gives the recommendations on the choice between a gateway and distributed gateway. VN within DC can benefit a lot from a distributed gateway. Some vender already implement these.
Lucy From: [email protected] [mailto:[email protected]] On Behalf Of Vishwas Manral Sent: Thursday, November 14, 2013 5:07 PM To: Linda Dunbar Cc: Bocci, Matthew (Matthew); [email protected] Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Hi folks, In my view the distributed Gateway cannot do a lot of the centralized functions required. We need a single place to terminate/ start IPsec connections - the most common way to connect to a cloud. A lot of the control plane to talk to the external world also needs to be centralized. Thanks, Vishwas On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: 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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Bocci, Matthew (Matthew) Sent: Wednesday, November 13, 2013 7:58 AM To: [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
