Subject: Re: [dc] Scoping the Interim meeting

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 22 Dec 2011 12:17:07 +0530

I'm new to this list and have been reading the archives. Wanted to make
a few comments.

First, issues of datacenter are mired in an "architecture" debate: flat
vs. hierarchical, dumb edge vs. dumb core, network-based vs.
server-based. If you go back in time, routing and switching protocols
were agnostic to the network architecture itself. This needs to be
revived. There should be effort in (a) recognizing architecture trends,
but (b) dissociate technology from network architecture. I.e. the
technology should work equally well with ANY architecture. Discussing
"typical" DC architectures and then tying the problem to them isn't a
very convincing way of going about this.

Second, to Ron's point about why datacenter problem is not widely
viewed, this is mainly because the origin of the problem is virtual host
scaling. L2 gives mobility but does not scale. L3 scales but does not
give mobility. So, classical approaches don't work. Now, a new approach
has to be devised, and there are many possible schemes, not all are
optimal. The issue is how to solve the virtual host scaling in an
optimal manner. And it is harder to recognize a problem that hinges on
optimality and scaling. If you take away scaling, there is no problem.
This group should recognize that the key problem is scaling, and the
answers are around optimality, not functionality. That should be
somewhere in the problem statement.

Third, there are multiple dimensions against which to evaluate
optimality. This is like a bubble under the carpet, and there many ways
you can push the bubble only to find that it is now somewhere else. To
find the optimal solution, it is important to list all the factors
against which to optimize. That makes this harder, but anything else
would fall short of expectation. Below are some of the dimensions
against which to optimize:

-    Massive address scaling

-    Address mobility 

-    Segmentation and security

-    Ease of managing 

-    Distributed cloud control - the end-user AND the provider

-    Measurements and SLAs

Thanks, Ashish

---

From: Aldrin Isaac <[email-masked]>
Date: Thu, 22 Dec 2011 12:12:38 -0500

Coming at it as an operator, the following are my own challenges with traditional LAN technology as well as some of my perspective that seem to ring true to what Ashish says.  Here's my elevator pitch.

Optimizing network resources (access ports, backbone, routing, VPN, VLAN, etc) and other resources (zone, rack, computer, storage, etc) with a high degree of efficiency on both ends requires significant coordination.  Optimizing resources through interdepartmental coordination is an operational "slow path" with high cost of operations, poor economies of scale and results that are often far from ideal.

It would be convenient to implement a fatter "dumb" core network (which seems to be a key assumption being made by the overlay and smart-edge drafts) where an end-station can be connected into any nearest available access switch port.  However since typical data center networks are segmented into tiers of physical and virtual network domains and subnets, to accomplish this would require a high degree of network virtualization to achieve the best physical network hardware utilization.  Virtualization of IP networks can be accomplished quite easily today using IPVPN technology, but the virtualization capability of IPVPN begins only at the IP router interface.  In order to enable the nearest (virtual or physical) access switch port to be a member of any network domain or subnet, the access switch port needs to have the ability to be a working member of any virtual LAN (subnet).  IPVPN and virtual LAN are then interworked to complete the end-to-end picture.  (Additionally, multicast bandwidth, replication and state optimization are important to many companies -- particularly those that deal with large and/or numerous multicast flows so this can't be neglected.)

Traditional virtual LAN technology does not scale well enough to be used in the manner I describe above.  A big part of why this problem exists to begin with is the side effects of data plane learning, both in the network (for which there are evolving solutions) and at the end-station interface to the network (as far as I can tell there is no effort to create a standardized UNI to exchange station MAC).  There are obviously other issues that have been raised such as ToR switch limitations, etc.

The operators involved in router (inter-networking) versus access switch (service attachment) deployment and provisioning in large data centers also tend to be different, which highlights an operational dimension that separates IPVPN from virtual LAN.  Decoupling the attachment role from the inter-networking role further cuts back on inter-role coordination reducing the number of "touch points" to actuate service.

I suppose we could move away from virtual LANs and go all-IP to the end station, but consider these:
1. The stability of an IP network depends heavily on statically configured subnets that act as a noise barrier from come-and-go end-stations.  IP networks extend into the Internet, business partners and customers which require degrees of route aggregation.
2. Use of Ethernet-layer solutions such as Ethernet-layer VRRP-like high availability, FCoE, RoCE, etc will not go away overnight.

Furthermore, some companies use server virtualization extensively while others do not (if the scope of this group is limited to optimizing VM environments, it should be made clear early).

A solution that creates new problems and does not have an intuitive and simple way to transition to it is a failure.  A solution that can achieve the goals by building on top of existing standards is ideal.  Solutions should be evaluated for how broadly they would be accepted.

On Dec 22, 2011, at 1:47 AM, Ashish Dalela (adalela) wrote:

> I’m new to this list and have been reading the archives. Wanted to make a few comments.
>  
> First, issues of datacenter are mired in an “architecture” debate: flat vs. hierarchical, dumb edge vs. dumb core, network-based vs. server-based. If you go back in time, routing and switching protocols were agnostic to the network architecture itself. This needs to be revived. There should be effort in (a) recognizing architecture trends, but (b) dissociate technology from network architecture. I.e. the technology should work equally well with ANY architecture. Discussing “typical” DC architectures and then tying the problem to them isn’t a very convincing way of going about this.
>  
> Second, to Ron’s point about why datacenter problem is not widely viewed, this is mainly because the origin of the problem is virtual host scaling. L2 gives mobility but does not scale. L3 scales but does not give mobility. So, classical approaches don’t work. Now, a new approach has to be devised, and there are many possible schemes, not all are optimal. The issue is how to solve the virtual host scaling in an optimal manner. And it is harder to recognize a problem that hinges on optimality and scaling. If you take away scaling, there is no problem. This group should recognize that the key problem is scaling, and the answers are around optimality, not functionality. That should be somewhere in the problem statement.
>  
> Third, there are multiple dimensions against which to evaluate optimality. This is like a bubble under the carpet, and there many ways you can push the bubble only to find that it is now somewhere else. To find the optimal solution, it is important to list all the factors against which to optimize. That makes this harder, but anything else would fall short of expectation. Below are some of the dimensions against which to optimize:
>  
> -    Distributed cloud control – the end-user AND the provider
> -    Measurements and SLAs
>  
> Thanks, Ashish
> _______________________________________________
> dc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dc