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

From: Lizhong Jin<[email-masked]>
Date: Thu, 5 Jan 2012 23:47:22 +0800

See inline below. Thank you.

Lizhong

> 
> >> Can this not be done today? What specific IETF work would be needed
> to
> support the enforcement of SLAs?
> 
> No there is no work in IETF done to define SLAs. For service provider
> environments, you can define a SLA at access for a given user. When you
> have 10 VM talking to each other, and you want to guarantee a bandwidth
> SLA on a VLAN, there is nothing out there. The other fact is that in a
> multi-tenant environment, there is no guarantee that you will get 1G
> bandwidth because you have a 1G interface on the VM. Typical network
> planning too into account the "whole" network design including what
> applications you are going to run and what bandwidths they need. That
> isn't true for cloud at least.
[Lizhong] I also agree SLA is very important and not solved yet currently. 
If we use overlay technology (xxx over IP), and the encapsulated tunnel 
would span the WAN network where BW is severely oversubscribed. How to 
ensure the BW for some high priority tenant?

> 
> After we are done discussing these, we can discuss what specific
> modifications we need to clarify the problem statement further, since it
> is obvious from the email that not all things may be obvious.
> 
> Thanks, Ashish
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Narten
> Sent: Wednesday, January 04, 2012 11:29 PM
> To: Ashish Dalela (adalela)
> Cc: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dc
> 
> _______________________________________________
> dc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dc

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.