Re: [nvo3] inter-CUG traffic [was Re: call for adoption: draft-narten-nvo3-overlay-problem-statement-02]

["Stiliadis, Dimitrios (Dimitri)" <[e-mail]>]

> 
> Still take the 3-tier app as an example, if the app servers each could be
> configured with two interfaces with one located in the VLAN/subnet of the web
> servers while the another located in the VLAN/subnet of the DB servers, the
> network only needs to care about the optimization for intra-subnet traffic
> (e.g., web<->app intra-subnet traffic and app<->DB intra-subnet traffic).


This would violate several security best practices. It would make the VM 
an easy entry point to the sensitive business logic and/or DB networks.
A vulnerability in the VM OS and/or apps would allow anyone to gain access
to the VM and through there the internal network. That's why people
are using DMZs. 

A router/firewall has a much lower code footprint and most likely
is more resilient to such vulnerabilities. So, not only does one 
need L3 isolation, but most often a real firewall in 
between the web-servers and the rest of the applications.

> 
> Of course, if the above demand can't be met due to some reason, the network
> should consider the optimization for inter-subnet traffic, and as had been
> pointed out by someone before, one practical solution is to deploy the default
> gateway functions as close as possible to the servers, e.g., inside the NVEs.
> 
> Best regards,
> Xiaohu
> 
> > -----邮件原件-----
> > 发件人: [e-mail] [mailto:[e-mail]] 代表 Pedro
> > Roque Marques
> > 发送时间: 2012年6月30日 9:41
> > 收件人: Joel M. Halpern
> > 抄送: [e-mail]; [e-mail]; [e-mail]
> > 主题: Re: [nvo3] inter-CUG traffic [was Re: call for adoption:
> > draft-narten-nvo3-overlay-problem-statement-02]
> >
> > Joel,
> > A very common model currently is to have a 3 tier app where each tier is in
> its
> > VLAN. You will find that web-servers for instance don't actually talk much
> to
> > each other… although they are on the same VLAN 100% of their traffic goes
> > outside VLAN. Very similar story applies to app logic tier. The database
> tier may
> > have some replication traffic within its VLAN but hopefully than is less
> than the
> > requests that it serves.
> >
> > There isn't a whole lot of intra-CUG/subnet traffic under that deployment
> > model. A problem statement that assumes (implicitly) that most or a
> significant
> > part of the traffic stays local to a VLAN/subnet/CUG is not a good match for
> the
> > common 3-tier application model. Even if you assume that web and app tiers
> > use a  VLAN/subnet/CUG per tenant (which really is an application in
> > enterprise) the database is typically common for a large number of
> > apps/tenants.
> >
> >   Pedro.
> >
> > On Jun 29, 2012, at 5:26 PM, Joel M. Halpern wrote:
> >
> > > Depending upon what portion of the traffic needs inter-region handling
> (inter
> > vpn, inter-vlan, ...) it is not obvious that "optimal" is an important goal.
> As a
> > general rule, perfect is the enemy of good.
> > >
> > > Yours,
> > > Joel
> > >
> > > On 6/29/2012 7:54 PM, [e-mail] wrote:
> > >> Pedro,
> > >>
> > >>> Can you please describe an example of how you could set up such
> > >>> straightforward routing, assuming two Hosts belong to different "CUGs"
> > such
> > >>> that these can be randomly spread across the DC  ? My question is where
> > is the
> > >>> "gateway", how is it provisioned and  how can traffic paths be
> > guaranteed to
> > >>> be optimal.
> > >>
> > >> Ok, I see your point - the routing functionality is straightforward to
> move
> > over,
> > >> but ensuring optimal pathing is significantly more work, as noted in
> another
> > one
> > >> of your messages:
> > >>
> > >>> Conceptually, that means that the functionality of the "gateway" should
> be
> > >>> implemented at the overlay ingress and egress points, rather than
> > requiring
> > >>> a mid-box.
> > >>
> > >> Thanks,
> > >> --David
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Pedro Roque Marques [mailto:[e-mail]]
> > >>> Sent: Friday, June 29, 2012 7:38 PM
> > >>> To: Black, David
> > >>> Cc: [e-mail]; [e-mail]
> > >>> Subject: Re: [nvo3] inter-CUG traffic [was Re: call for adoption: draft-
> > >>> narten-nvo3-overlay-problem-statement-02]
> > >>>
> > >>>
> > >>> On Jun 29, 2012, at 4:02 PM, <[e-mail]> wrote:
> > >>>
> > >>>>> There is an underlying assumption in NVO3 that isolating tenants from
> > >>>>> each other is a key reason to use overlays. If 90% of the traffic is
> > >>>>> actually between different tenants, it is not immediately clear to me
> > >>>>> why one has set up a system with a lot of "inter tenant" traffic. Is
> > >>>>> this is a case we need to focus on optimizing?
> > >>>>
> > >>>> A single tenant may have multiple virtual networks with routing used to
> > >>>> provide/control access among them.  The crucial thing is to avoid
> > assuming
> > >>>> that a tenant or other administrative entity has a single virtual
> network
> > >>>> (or CUG in Pedro's email).  For example, consider moving a portion of
> > >>>> a single data center that uses multiple VLANs and routers to
> selectively
> > >>>> connect them into an nvo3 environment - each VLAN gets turned into a
> > virtual
> > >>>> network, and the routers now route among virtual networks instead of
> > VLANs.
> > >>>>
> > >>>> One of the things that's been pointed out to me in private is that the
> level
> > >>>> of importance that one places on routing across virtual networks may
> > depend
> > >>>> on one's background.  If one is familiar with VLANs and views nvo3
> > overlays
> > >>>> providing VLAN-like functionality, IP routing among virtual networks is
> a
> > >>>> straightforward application of IP routing among VLANs (e.g., the
> previous
> > >>>> mention of L2/L3 IRB functionality that is common in data center
> network
> > >>>> switches).
> > >>>
> > >>> Can you please describe an example of how you could set up such
> > >>> straightforward routing, assuming two Hosts belong to different "CUGs"
> > such
> > >>> that these can be randomly spread across the DC  ? My question is where
> > is the
> > >>> "gateway", how is it provisioned and  how can traffic paths be
> > guaranteed to
> > >>> be optimal.
> > >>>
> > >>>>  OTOH, if one is familiar with VPNs where access among
> > >>>> otherwise-closed groups has to be explicitly configured, particularly
> > >>>> L3 VPNs where one cannot look to L2 to help with grouping the end
> > systems,
> > >>>> this sort of cross-group access can be a significant area of
> functionality.
> > >>>
> > >>> Considering that in a VPN one can achieve inter-CUG traffic exchange
> > without
> > >>> an gateway in the middle via policy, it is unclear why you suggest that
> "look
> > >>> to L2" would help.
> > >>>
> > >>>>
> > >>>> Thanks,
> > >>>> --David
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of
> > >>> Thomas
> > >>>>> Narten
> > >>>>> Sent: Friday, June 29, 2012 5:56 PM
> > >>>>> To: Pedro Roque Marques
> > >>>>> Cc: [e-mail]
> > >>>>> Subject: [nvo3] inter-CUG traffic [was Re: call for adoption: draft-
> narten-
> > >>>>> nvo3-overlay-problem-statement-02]
> > >>>>>
> > >>>>> Pedro Roque Marques <[e-mail]> writes:
> > >>>>>
> > >>>>>> I object to the document on the following points:
> > >>>>>>
> > >>>>>> 3) Does not discuss the requirements for inter-CUG traffic.
> > >>>>>
> > >>>>> Given that the problem statement is not supposed to be the
> > >>>>> requirements document,, what exactly should the problem statement
> > say
> > >>>>> about this topic?
> > >>>>>
> > >>>>> <[e-mail]> writes:
> > >>>>>
> > >>>>>> Inter-VN traffic (what you refer to as inter-CUG traffic) is handled
> > >>>>>> by a straightforward application of IP routing to the inner IP
> > >>>>>> headers; this is similar to the well-understood application of IP
> > >>>>>> routing to forward traffic across VLANs.  We should talk about VRFs
> > >>>>>> as something other than a limitation of current approaches - for
> > >>>>>> VLANs, VRFs (separate instances of routing) are definitely a
> > >>>>>> feature, and I expect this to carry forward to nvo3 VNs.  In
> > >>>>>> addition, we need to make changes to address Dimitri's comments
> > >>>>>> about problems with the current VRF text.
> > >>>>>
> > >>>>> Pedro Roque Marques <[e-mail]> writes:
> > >>>>>
> > >>>>>> That is where again the differences between different types of
> > >>>>>> data-centers do play in. If for instance 90% of a VMs traffic
> > >>>>>> happens to be between the Host OS and a network attached storage
> > >>>>>> file system run as-a-Service (with the appropriate multi-tenent
> > >>>>>> support) then the question of where are the routers becomes a very
> > >>>>>> important issue. In a large scale data-center where the Host VM and
> > >>>>>> the CPU that hosts the filesystem block can be randomly spread
> > >>>>>> where is the router ?
> > >>>>>
> > >>>>> Where is what router? Are you assuming the Host OS and NAS are in the
> > >>>>> different VNs? And hence, traffic has to (at least conceptually) exit
> > >>>>> one VN and reenter another whenever there is HostOS - NAS traffic?
> > >>>>>
> > >>>>>> Is every switch a router ? Does it have all the CUGs present ?
> > >>>>>
> > >>>>> The underlay can be a mixture of switches and routers... that is not
> > >>>>> our concern. So long as the underlay delivers traffic sourced by an
> > >>>>> ingress NVE to the appropriate egress NVE, we are good.
> > >>>>>
> > >>>>> If there are issues with the actual path taken being suboptimal in
> > >>>>> some sense, that is an underlay problem to solve, not for the overlay.
> > >>>>>
> > >>>>>> In some DC designs the problem to solve is the inter-CUG
> > >>>>>> traffic. With L2 headers being totally irrelevant.
> > >>>>>
> > >>>>> There is an underlying assumption in NVO3 that isolating tenants from
> > >>>>> each other is a key reason to use overlays. If 90% of the traffic is
> > >>>>> actually between different tenants, it is not immediately clear to me
> > >>>>> why one has set up a system with a lot of "inter tenant" traffic. Is
> > >>>>> this is a case we need to focus on optimizing?
> > >>>>>
> > >>>>> But in any case, if one does have inter-VN traffic, that will have to
> > >>>>> get funneled through a "gateway" between VNs, at least conceptually, I
> > >>>>> would assume that an implementation of overlays would provide at least
> > >>>>> one, and likely more such gateways on each VN. How many and where
> > to
> > >>>>> place them will presumably depend on many factors but would be done
> > >>>>> based on traffic patterns and network layout. I would not think every
> > >>>>> NVE has to provide such functionality.
> > >>>>>
> > >>>>> What do you propose needs saying in the problem statement about
> > that?
> > >>>>>
> > >>>>> Thomas
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> nvo3 mailing list
> > >>>>> [e-mail]
> > >>>>> https://www.ietf.org/mailman/listinfo/nvo3
> > >>>>
> > >>>
> > >>
> > >> _______________________________________________
> > >> nvo3 mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/nvo3
> > >>
> > >
> >
> > _______________________________________________
> > nvo3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nvo3
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3