I have not seen data to suggest "most". Do you have a source for that?
I have seen descriptions of data centers for which it is almost "all",
and other data centers for which it is negligible.
Yours,
Joel
On 7/9/2012 3:51 PM, Linda Dunbar wrote:
Joel,
I agree with you that VPN related WG (e.g. L2VPN, L3VPN) may not need to
address too much on across VN communications.
But most traffic in Data Center are across subnets. Given NVo3 is for
identifying issues associated with data centers, I think that cross Subnet
traffic should not be ignored.
Linda
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Joel M. Halpern
Sent: Friday, June 29, 2012 9:32 PM
To: Pedro Roque Marques
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [nvo3] inter-CUG traffic [was Re: call for adoption:
draft-narten-nvo3-overlay-problem-statement-02]
I would not be so bold as to insist that all deployments can safely
ignore inter-VPN intra-data-center traffic. But there are MANY cases
where that is not an important part of the traffic mix.
So I was urging that we not mandate optimal inter-subnet routing as
part
of the NVO3 requirements.
I would not want to prohibit it either, as there are definitely cases
where it matters, some along the lines you alude to.
Yours,
Joel
On 6/29/2012 9:40 PM, Pedro Roque Marques wrote:
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, [email protected] 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:[email protected]]
Sent: Friday, June 29, 2012 7:38 PM
To: Black, David
Cc: [email protected]; [email protected]
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, <[email protected]> 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: [email protected] [mailto:[email protected]] On
Behalf Of
Thomas
Narten
Sent: Friday, June 29, 2012 5:56 PM
To: Pedro Roque Marques
Cc: [email protected]
Subject: [nvo3] inter-CUG traffic [was Re: call for adoption:
draft-narten-
nvo3-overlay-problem-statement-02]
Pedro Roque Marques <[email protected]> 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?
<[email protected]> 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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
