Hi Lucy, I see the VPC as a branch of a bigger Infrastructure (in many cases), and the gateway that connects the same as an edge device.
We need to connect this VPC securely - and IPsec as the technology when connecting over the internet. I dont know if you can distribute IPsec functionality. I know you need tecnologies like firewalls etc too, which I know can be centrally managed yet be enforced in a distributed manner (not the general way to do it however). Same with the control plane that connects to the peers in the Enterprise (we need a single control plane). I guess I am missing the point. Thanks, Vishwas On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong <[email protected]> wrote: > 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]> > 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]] *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 > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
