Re: [dc] draft-dalela-dc-requirements-00.txt

[David Allan I <[e-mail]>]

If the goal is to describe the generalized characteristics of what is needed:
An absolutely flat broadcast domain does not scale...duh!
An absolutely flat L2 network does not scale...duh!
Partitioning the network into a large number of virtual broadcast domains or L2VPNs/VLANs is what works for many adopters as it supports PMO. This is what numerous existing standardized and proprietary solutions offer with various shades of grey attribute wise (e.g. scaling, ordering guarantees, properties when failures occur, broadcast containment etc.). The one observation is that a 24 bit VLAN tag seems to be the current gold standard, both with the IEEE and with proprietary or proposed approaches.

It would be doing to group a service if the issues with Ethernet were not presented based on a view stuck in perhaps the 2004-2005 timeframe, or perhaps even before the standardization of the original 12 bit VLAN tag, let alone what has come since.

;-)
Dave

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Thomas Narten
Sent: Wednesday, January 04, 2012 9:59 AM
To: Ashish Dalela (adalela)
Cc: [e-mail]
Subject: [dc] draft-dalela-dc-requirements-00.txt

Hi Ashish.

I had  look at this document as it is focused on requirements. Thanks for doing this.

One starting comment, as the document says:

>    Scalability hasn't generally been a standards consideration and the
>    problems of scaling are left to implementation. But, in the case of
>    cloud datacenters, scaling is the basic requirement, and all problems
>    of cloud datacenters arise due to scaling. The solution development
>    can't therefore ignore the scaling and optimality problem.

I disagree with the above. Scalability has always been one (of many) factors that goes into development of a standard. Let's just take it as a given that any solution has to scale adequately for the environment in which it is to be deployed. Saying more than that (in general terms) is probably not a useful discussion. To talk about scalability, one has to talk about a specific technology and where it is or will be deployed.

Looking at Section 5, where the main requirements are listed:

>    5.1. The Basic Forwarding Problem
> 
>    Traditionally, datacenter networks have used L2 or L3 technologies.
>    The need to massively scale virtualized hosts breaks both these
>    approaches. L2 networks can't be made to scale because of high number
>    of broadcasts. L3 networks can't support host mobility, since routing
>    uses subnets and an IP cannot be moved out of that subnet. Moving IP
>    in a natively L3 network requires installing host routes at one or
>    more points in the path and that is an approach that can't be 
> scaled.

I suspect there is general agreement that the above is a general "problem". Having one big flat L2 in a data center is great for VM migration and placement of services "any place, anytime", but can raise scaling and other concerns. Pushing L3 all the way out to the edges (e..g, ToR or Hypervisor) makes it hard to place (or move) services/VMs arbitrarily.

The above is one of the motivations behind the NVO3 work.

> 5.2. The Datacenter Inter-Connectivity Problem
> 
>    There are limits to how much a datacenter would be scaled. Workloads
>    need to be placed closer to the clients to reduce latency and
>    bandwidth. Hence, datacenters need to be split into geographical
>    locations and connected over the Internet. Some of these datacenters
>    may be owned by different administrators, as in the case of private
>    and public cloud interconnectivity. Workloads can move between these
>    datacenters, similar to how they move within the datacenter.

In this section, my take away is that there will be multiple, geographically separated data centers. And that they will need to be connected together. I suspect everyone agrees with that.

But I don't see how this implies there is any specific IETF work that needs doing. We already have geographically separated data centers, and there are, e.g., plenty of VPN technologies available for connecting them together.

What specifically is missing that prevents the above from being done today? What is it that you think needs doing that can't be done with existing standards?

> 5.3. The Multi-Tenancy Problem
> 
>    Datacenters thus far have been wholly used by single tenant. To
>    separate departments within a tenant, VLANs have been used. This
>    seemed sufficient for the number of segments an enterprise would
>    need. But, this approach can't be extended to cloud datacenters.

I suspect you'll get a lot of agreement on this. And one of the key aims of NVO3 is to address this.

Is the existing NVO3 approach not adequate for the above? If so why not?

> 5.4. The Technology-Topology Separation Problem
> 
>    While large datacenters are becoming common, medium and small
>    datacenters will continue to exist. These may include a branch office
>    connected to a central office, or a small enterprise datacenter that
>    is connected to a huge public cloud. To move workloads across these
>    networks, the technologies used in the datacenter must be agnostic of
>    the topology employed in the various sized datacenters.

>    A small datacenter may use a mesh topology. A medium datacenter may
>    use a three-tier topology. And a large datacenter may use a two-tier
>    multi-path architecture. It has to be recognized that all these
>    datacenters of various sizes need to interoperate. In particular, it
>    should be possible to use a common technology to connect large and
>    small datacenters, two large datacenters, or two small datacenters.

Isn't this already possible, and indeed, happening today?

What IETF work is needed? What standards gap needs filling?

>    5.5. The Network Convergence Problem
> 
>    Cloud datacenters will be characterized by elasticity. That means
>    that virtual resources are constantly created and destroyed. Typical
>    hardware and software reliabilities of today mean that failures at
>    scale will be fairly common, and automated recovery mechanisms will
>    need to be put in place. When combined with workload mobility for the
>    sake of resource optimization and improving utilization, the churn in
>    the network forwarding tables can be very significant.

WHat work does the above imply that the IETF needs to do ?

>    Mobility also affects virtualized network devices, such as virtual
>    switches, firewalls, load-balancers, etc. For instance, when a server
>    fails and all the VMs are relocated, the associated virtual switch
>    and firewall must also be relocated. This means that any assumption
>    in mobility that the network is a static firmament on which hosts are
>    dynamically attached becomes false. We have to assume that the
>    network is as dynamic as the hosts themselves.

This here is interesting. The implication is that when moving a VM, either

a) a FW or LB (or both) may also have to be moved, or

b) some sort of path enforcement is needed that insures traffic from the (now moved) VM continues to go through the same LB or FW as before.

Do I understand that correctly? And if so, what is the IETF work that needs to be done to make all this happen?

>  5.6. The East-West Traffic Problem

Is this section saying anything more than there is a need for multipathing for East West traffic?

> 5.7. The Network SLA Problem
> 
>    Multi-tenant networks need to protect all tenants from overusing
>    network resources. For example, high-traffic load from one tenant
>    should not starve another tenant of bandwidth. Note that in a multi-
>    tenant environment, no tenant has full control or visibility of what
>    other tenants are doing, and how problems can be fixed. A real-time
>    debugging of such problems is very hard for a provider.

...

>    Second, mechanisms to measure and guarantee network SLAs will have to
>    employ active flow management to guarantee bandwidth to all tenants
>    and keep the network provisioned only to the level required. Flow
>    management can be integrated as part of existing forwarding
>    techniques or may need new techniques. Network SLAs can play an
>    important role in determining if sufficient bandwidth is available
>    before a VM is moved to a new location.

Can this not be done today? What specific IETF work would be needed to support the enforcement of SLAs?

Thomas

_______________________________________________
dc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dc