Subject: Re: [dc] Elevator Pitch (was: Scoping the Interim meeting)

From: "Mcdysan, David E" <[email-masked]>
Date: Tue, 3 Jan 2012 09:03:53 -0500

Hi Tom,

Catching up on Email after vacation. Some (hopefully clarifying) responses
in line below.

Dave

On Friday12/23/11 7:23 PM, "Thomas Narten" <[email-masked]> wrote:

>Hi Dave.
>
>Thanks for this. Let me see if I can summarize and further tease this
>out.
>
>"Mcdysan, David E" <[email-masked]> writes:
>
>> Pitch on an Elevator in a shorter building. ;)
>
>> Support an infrastructure for multiple tenants, each with computing
>> applications and associated resources ranging from a single VM to a very
>> large tenant with a complex, multi-site computing application. An
>> important case is supporting a very large single tenant computing
>> application.
>
>I think you are stating that a key requirement is support for
>multi-tenancy.  (And I would assume pretty much everyone agrees this
>is a requirement...)
>
>> Ensure that each tenant is securely separated from others and that only
>> tenants who mutually agree to communicate and/or share resources can
>> do so.
>
>This sounds like sub-bullets under the definition of multi-tenancy.

Agreed, but the key word is "security," which may merit a separate
category with sub-bullets for privacy, authentication, access attempts.

>
>> Orchestrate all of the virtual and real appliances (e.g., firewalls.
>>load
>> balancers, security, etc.) needed for a complex computing application
>> distributed across multiple sites.
>
>This sounds like something very different and potential very big. By
>"orchestration" do you mean the system by which you can place or move VMs
>and
>all their associated dependent devices (FWs, LBs, etc.) around?
>How
>you place them, how you move components around?

Yes, and not only placement but reachability and forwarding rules. For
example, all packets to/from a set of machines for a particular matching
tuple must go through a specific function (e.g., a FW, or an LB).

>
>If so, this seems to me to be a combination of a (possibly)
>centralized controller (of sorts), with a lot of individual components
>distributed around the DC that provide necessary hooks/mechanisms for
>the orchestrator to do its job. I.e., moving a VM (and a FW) requires
>a number of steps. The orchestrator (at a high level) initiates those
>steps, but there are other network components that also play a role
>(the hypervisor, switches, etc.)

This is one form of a solution to the above requirement. Others may be
possible.
>
>Where do you see the standardization gaps in the above? What would be
>some example areas where IETF (or some other SDO) work is needed?

Some form of a schema and/or meta-data model for these functions (VMs,
devices through which all packets matching a tuple must pass (e.g., FW,
LB)) would be one example area.

Another would be a description of a rule set for how these functions and
resources would be composed. This rule set should include what happens in
response to changes in load and failures.
>
>> Provide methods to optimize the placement and interconnection of
>> computing, storage, appliance and networking resources.
>
>What would the standardization angle of this be? (FWIW, I don't see
>one right off, but I probably just don't understand what is
>meant/needed here).

One example being discussed in the alto wg is extending the model to have
multiple cost attributes. These could be used as inputs to a
multi-commodity optimization engine. IMO, defining the inputs and their
semantics/syntax is what should be standardized, and not the algorithms.
>
>> Work across a diverse set of networking technologies and architectures,
>> ranging from dedicated special-purpose networks (e.g., Ethernet/PBB
>>L2/L3
>> VPNs) to access over the Inernet.
>
>This is a sub-bullet of the orchestration requirements?

Could be. What I had in mind is a high-level statement of reachability for
VMs and functions (e.g., FW, LB). All major networking environments must
be supported. 

>
>> Be scalable on the high end to support hundreds of millions of Virtual
>> Machines -- think one VM pre wireless subscriber.
>
>Is this a sub-requirement of orchestration? or multi-tenancy? or both?

Both. Dynamic orchestration is important because different classes of
users have different Time of Day, Day of Week and Day of Year needs for
computing, storage, networking and other resources.

>
>> Be capable of meeting the quality objectives across a range of
>>performance
>> profiles corresponding to classes of tenants.
>
>Could you elaborate on this? Is this about meeting SLAs?

Meeting SLAs is an important part of this. Availability of resources is a
very important SLA objective for which I believe more standards work is
needed. For example, a user who reserves resources in advance should have
a much higher likelihood of his/her needs being served as compared with a
user who requests resources on demand just before the resources are needed.

Many network SLA parameters (e.g., latency, loss, delay variation) are
already mostly described in existing IETF and other standards body
standards.

Standards for things such as computing power, virtual memory, disk
allocation (and access rate), other function throughput and capacities
(e.g., FW, LB) would be needed so that the resource request could be
completely specified. This may be best done in other standards bodies, but
I cannot point to a specific SDO.

>What is the
>standardization angle (i.e., where work is needed, where there is a
>gap today).

Some of the orchestration schema/meta-data standards work mentioned above
could be used as a means to communicate information about the resources
being requested. Additional semantics and syntax would be needed to
communicate the status of the resource request as well as the status of
such requests.

>Thomas