Infact even between tiers of an Application you need firewall etc. So direct access is allowed to the Web tier but not to the mid tier etc etc.
-Vishwas On Thu, Nov 14, 2013 at 3:40 PM, Vishwas Manral <[email protected]>wrote: > 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
