Subject: [dc] DC Work Plan

From: Ronald Bonica <[email-masked]>
Date: Fri, 6 Jan 2012 13:50:39 -0500

Folks,

The goal of this mailing list and the interim meeting which it supports is to articulate data center requirements. While there has been a lively exchange on the mailing list, we are not significantly closer to our goal than we were a month ago. Therefore, I would like to recommend the following work plan:

1. adopt draft-dalela-dc-requirements as a very rough baseline

2. Rework Section 4
2.1 Rename Section 4 to "Data Center Characteristics"
2.2 Initiate a mailing list thread (Subject: DCREQ Section 4 Outline) to determine whether Sections 4.1, 4.2 and 4.3 represent the salient characteristics of the data center. Should section headers be added, changed or deleted?
2.3 Form a design team (or design teams) that will present proposed content for each subsection

3. Rework Section 5
3.1 Initiate a mailing list thread (Subject: DCREQ Section 5 Outline) to determine whether Sections 5.1 - 5.10 represent the salient components of the data center problem space. Should section headers be added, changed or deleted?
3.2 Form a design team (or design teams) that will present proposed content for each subsection

4. Discuss the presentations / form consensus

5. Generate new text for Sections 4 and 5

6. Submit to IESG for publication as INFORMATIONAL

Please comment on this work plan ASAP.

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Sat, 7 Jan 2012 00:34:26 +0530

Ron,

I was working on modifying the current draft to incorporate the several
comments received over the email. But, that can wait if you want to
start a more structured approach right away. On the other hand, I could
incorporate the various comments / clarifications already received,
submit version 01 and then take it forward through the steps already
mentioned below. I am fine with either approach.

Thanks, Ashish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ronald Bonica
Sent: Saturday, January 07, 2012 12:21 AM
To: [email-masked]
Subject: [dc] DC Work Plan

Folks,

The goal of this mailing list and the interim meeting which it supports
is to articulate data center requirements. While there has been a lively
exchange on the mailing list, we are not significantly closer to our
goal than we were a month ago. Therefore, I would like to recommend the
following work plan:

2. Rework Section 4
2.1 Rename Section 4 to "Data Center Characteristics"
2.2 Initiate a mailing list thread (Subject: DCREQ Section 4 Outline) to
determine whether Sections 4.1, 4.2 and 4.3 represent the salient
characteristics of the data center. Should section headers be added,
changed or deleted?
2.3 Form a design team (or design teams) that will present proposed
content for each subsection

3. Rework Section 5
3.1 Initiate a mailing list thread (Subject: DCREQ Section 5 Outline) to
determine whether Sections 5.1 - 5.10 represent the salient components
of the data center problem space. Should section headers be added,
changed or deleted?
3.2 Form a design team (or design teams) that will present proposed
content for each subsection

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 06 Jan 2012 20:16:30 +0100

Ron,

I don't see what is there to adopt if you recommend to rework section 4 
and section 5 which is pretty much are 90% of this document.

IMHO adoption should be considered after section 4 and section 5 are 
reworked.

Thx,
R.

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 6 Jan 2012 15:06:26 -0500

Robert,

draft-dalela-dc-requirements provides scaffolding from which we can work. Specifically, we can adopt its approach of dedicating one section to a description of data center characteristics and another section to problem space components. All other discussion is out of bounds.

Considering how unstructured our discussion has been to date, a little scaffolding might be helpful.

                                                     Ron

> Robert Raszuk
> Sent: Friday, January 06, 2012 2:17 PM
> To: [email-masked]
> Subject: Re: [dc] DC Work Plan
> 
> Ron,
> 
> > The goal of this mailing list and the interim meeting which it
> supports is to articulate data center requirements. While there has
> been a lively exchange on the mailing list, we are not significantly
> closer to our goal than we were a month ago. Therefore, I would like to
> recommend the following work plan:
> >
> > 2.2 Initiate a mailing list thread (Subject: DCREQ Section 4 Outline)
> to determine whether Sections 4.1, 4.2 and 4.3 represent the salient
> > 3.1 Initiate a mailing list thread (Subject: DCREQ Section 5 Outline)
> to determine whether Sections 5.1 - 5.10 represent the salient
> components of the data center problem space. Should section headers be
> added, changed or deleted?

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 6 Jan 2012 21:48:21 +0000

Ron,

It is a good idea to have a baseline to start with.

Section 4: "Data Center Characteristics" should at least add the following sub-sections:
*       A section on how location of load-balancing, firewall, and other middleware boxes determine where VMs/hosts in different segments can be aggregated/exchanged.
*       A section on how applications are instantiated in data center. Applications servers (e.g. Oracle's middleware WebLogicServer) instantiate multiple instances of one application, assign them the IP addresses, and VM/server managers place them onto a server rack.
*       A section to describe how backend data/storage are separated from the front end service networks.

Section 5 of  draft-dalela-dc-requirements needs a lot of changes.

*       Many statements in Section 5.1 "Basic Forwarding Problem"  are not accurate. E.g. "the need to massively scale virtualized hosts" may break the FDB (or FIB) on switches/routers, but it doesn't really break the L2/L3 technologies traditionally used in data center. L3 networks can't support host mobility is not true either. Host based routing can support mobility.
*       Section 5.1 is really about "basic forwarding for segmented networks".
*       Section 5.2 (DC Inter-connectivity problem) is loaded. Should be broken into multiple (sub)sections:
o       Problems associated with various networks in interconnecting data centers (VPN, straight IP, or straight optical)
o       Multi-data center Service interconnection, Layer 4-7 load balancing issues:  i.e. the description on how service needs to be closer to clients, mapping services to location of data centers, etc.
o       Middleware function association in Multi-data center scenario
*       Section 5.3 "Multi-tenancy Problem" should at least include issues associated with non-VLAN partition (e.g. IEEE802.1ah's ISID)
*       New sub-section in Section 5 on traffic pattern dictated by policy and middleware boxes location.

Linda Dunbar

> Sent: Friday, January 06, 2012 12:51 PM
> To: [email-masked]
> is to articulate data center requirements. While there has been a
> lively exchange on the mailing list, we are not significantly closer to
> our goal than we were a month ago. Therefore, I would like to recommend
> the following work plan:
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 Jan 2012 17:00:59 -0500

Hi Ron.

>  little scaffolding might be helpful.

I agree.

But let me posit the following. Normally in the IETF, we have meetings
to discuss concrete work. I.e., you have to have existing documents to
justify the face-to-face meeting. And there has to be agreement that
there is enough "meat" in those documents, and that having a
face-to-face meeting will move the discussion forward. Think about the
requirements before a BOF is approved, for example.

Right now, we just don't have such a document (or documents). We have
a lot of documents, but no real agreement, even on general
areas. (Note: I'm specifically excluding NVO3 and SDN when I say this,
because I think both efforts can easily continue on their own as
separate efforts to create WGs -- but outside of those efforts, I'm
really struggling to understand what additional work the IETF is being
asked to do in the "DC area".)

There is real work to iterating on the problem areas that just hasn't
been done yet.

Can such work happen before the interim? Sure. Maybe. But there are no
guarantees, and based on the discussions in the last month, there is
room for doubt.

The proposed dates previously mentioned were Feb 22-23. That is a mere
4 1/2 weeks from the Paris IETF. Assuming we had a successful interim
meeting, that wouldn't allow much time to revise documents and prep
for the Paris meeting.

So, given the work plan, and doubts on whether we can deliver on it
prior to an interim meeting, the timing of the proposed meeting
relative to the next IETF, do we really need to have an interim
meeting at all?

Wouldn't it be good enough to attempt to execute on the plan, with an
expectation that there will be some sort of session in Paris (if
justified)?

What do others think?

Thomas

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 06 Jan 2012 22:45:14 +0000

Thomas

 > (Note: I'm specifically excluding NVO3 and SDN when I say this,
 > really struggling to understand what additional work the IETF is
 > being asked to do in the "DC area".)

I think that SDN has wider applicability than DC and thus has a
life (or death) of its own.

NVO3 is a candidate solution to the DC problem, but from the
discussion on the list I am yet to be convinced that we have either
the right problem statement to endorse it as the approach for L2,
let alone to determine whether we need a L2 solution, a L3
solution or a mixed solution.

- Stewart

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 Jan 2012 18:05:43 -0500

Hi Stewart.

> life (or death) of its own.

It's not just that it has wider applicability, it's that that effort
seems somewhat self-contained and I can see how one might carve out an
effort in this space.

> NVO3 is a candidate solution to the DC problem,

This is probably just quick typing, but I think it is worth saying
that we are not helping ourselves by thinking there is *one* DC
problem.

There are a number of possible problems. Some relate to each others,
some more so, some less so. But I think it is not helpful to try and
view this area as having *one* problem that needs sorting out.

I think it's much more helpful (and IETF tradition!) to try and
identify individual problems and where possible, solve problems
individually (i.e., divide and conquer). Of course, there can be
interdependencies between problem and solution spaces, but we are
likely going to flail if we try to view this as one big problem
needing one overall solution approach. Or that we can't work on sub
problems unless we understand the entire problem space.

> but from the discussion on the list I am yet to be convinced that we
> have either the right problem statement to endorse it as the
> approach for L2, let alone to determine whether we need a L2
> solution, a L3 solution or a mixed solution.

NVO3 is aimed at a subset of the DC "problem area". The bullet point
summary is that it's different way of providing multi-tenancy in the
DC. It is not the *only* way. But I think the Taipai session showed
there was significant support for this approach.

Thomas

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 07 Jan 2012 00:49:10 +0100

Thomas,

 > individually (i.e., divide and conquer).

My personal observation leads me to believe that in the IETF DC effort 
we are facing three main issues ....

#1 - Today DC consists of hosts/VMs, orchestration part and network 
part. However IETF traditionally were not about defining how to run 
operating systems or how to manage them - it was about engineering 
network protocols part. But let's notice that number of solutions 
already proposed do enter space how to manage hypervisors or host kernel 
space. It is highly unclear to me that no matter what IETF will come up 
with it will be accepted in the industry. Leave architecture how to run 
appliances (firewall/loadbalancers/etc) alone.

#2 - Second thought is to observe that perhaps some problems could be 
(are) solved already in existing working groups. Considering NVO3, 
L2VPNs, L3VPNs, LISP as examples of areas where especially in inter-dc 
communication could be used to work on them. Even L2 over L3 seems 
already happening in mentioned WGs.

#3 - There is also another spin to this. The solutions proposed should 
be compatible and in symbiosis with overall industry trends. Those are 
happening outside of IETF and I rather see not much interaction so far, 
but rather a bit of "not invented here" syndrome.

Best regards,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 07 Jan 2012 01:29:18 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Thomas
> Narten
> 发送时间: 2012年1月7日 6:01
> 收件人: Ronald Bonica
> 抄送: [email-masked]; [email-masked]
> 主题: Re: [dc] DC Work Plan
> 
> Hi Ron.
> 

I agree with Thomas's points as above. Let's continue the discussion about the problems and further evaluate whether the already existing VPN solutions could address them fully or partially in the mailing-list according to the "Elevator Pitch" principle, if we could get enough time-slots for face-to-face talk at the forthcoming Paris IETF meeting.

Best regards,
Xiaohu

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Sat, 7 Jan 2012 11:08:37 +0530

Thomas,

It is indeed IETF tradition to solve individual problems individually.
What makes it different in this case is that a customer spans multiple
datacenters. That means VM mobility, segmentation, broadcast, multicast,
unicast, policy (e.g. bandwidth) are spanning across both intra and
inter-DC. 

If we follow the IETF tradition here, it will mean that mobility,
segmentation, broadcast, multicast, policy will potentially all be done
in two sets of ways across and between datacenters, because these can
indeed be stated as separate problems. Now, you have a huge issue in
mapping one type of scheme into another, given the many possible ways to
do each of mobility, segmentation, broadcast, multicast, policy,
themselves.

Added to the above is the fact that there are divergent approaches - L2
vs. L3, host-based vs. network-based, overlay vs. flat. Just to solve
address resolution, there is more than one approach - e.g. directory
based or control plane based. 

The total number of permutations and combinations arising from these
many alternatives will eventually mean that things don't work together. 
	
If intra-dc is directory based, then it doesn't help inter-dc to be
control plane based. If intra-dc uses VLAN for segmentation then it
doesn't help inter-dc to use GRE. If the unicast is multi-path then it
doesn't help if multicast and broadcast are static trees. If one DC is
L2 encap then it doesn't help if another DC is L3 encap. Note that this
is already discounting the fact that this has to interoperate with
classic L2/L3 networks. That may mean a L3 OSPF routing table entry into
a L2 IS-IS forwarding entry. Proliferation of divergent approaches just
worsens interoperability. 

I understand your concern, and that it is different than IETF tradition.
But we need to choose between tradition and interoperability.

Thanks, Ashish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Narten
Sent: Saturday, January 07, 2012 4:36 AM
To: Stewart Bryant (stbryant)
Cc: Ronald Bonica; [email-masked]; [email-masked]
Subject: Re: [dc] DC Work Plan

Hi Stewart.

Thomas

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 07 Jan 2012 07:52:00 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Ashish
> Dalela (adalela)
> 发送时间: 2012年1月7日 13:39
> 收件人: Thomas Narten; Stewart Bryant (stbryant)
> 抄送: Ronald Bonica; [email-masked]; [email-masked]

Hi Ashish,

I agree that it is not a much efficient way to solve the problems individually. Taken the spanning-tree protocol as an example, it has several problems including slow convergence, sub-optimal bandwidth utilization due to the lack of ECMP and shortest path forwarding, 4k VLAN limit... It is not reasonable to set up individual WGs for solving these problems individually. In fact, L2VPN and L3VPN technologies could already solve most of the problems as mentioned above. It's efficient for us to evaluate what problems these existing VPN technologies could already addresses, what problems else not. In this way, we can quickly identify what the IETF needs to do.

However, I don’t agree that the reason for comprehensively considering all of the problems is due to the fact you described. In contrast, I believe there are some obvious differences between DCI requirements and DCN requirements. Taken the L2VPN solution (e.g., VPLS) as an example, its associated features such as full-mesh of PW, ingress replication and peer configure are not much big concerns when considering VPLS as a DCI solution, since there would not be too many DC sites to be connected together. However, when you consider to deploy VPLS in a data center, especially performing PE functions at hundreds even thousands of ToR switches, the above features will become much serious problems. In addition, path optimization for both VPN access and Internet access is a very important requirement which is specific to DCI, rather than to DCN, IMHO. In a word, I suggest It'd better not to completely mix the requirements for DCN and those for DCI although there exist some overlapping parts between them.

Best regards,
Xiaohu

---

From: Thomas Narten <[email-masked]>
Date: Sat, 07 Jan 2012 08:34:25 -0500

Hi Ashish.

> unicast, policy (e.g. bandwidth) are spanning across both intra and

Sorry, but I do not believe that things are different in this
case. The IETF always grapples between problem areas whose impacts
potentially span everything vs. scoping a problem down into one or
more manageable units, where it can be worked on in a more standalone
fashion vs. trying to boil the ocean.

Indeed, any large project works that way. You have to have an overall
architecture/vision of how things fit together, and then individual
components that fit into the overall architecture.

I have not seen evidence that the current "DC" problem area is any
different.

Indeed, I believe that the reason why the various "problem statements"
have gotten so little traction is because they come across as too big,
too high-level and aren't scoped into small enough pieces (or
sub-pieces) so that folk can look at a particular part (or sub-part)
and say "yes, I understand what is being proposed, I agree that this
is a problem that would be useful to solve and I think that we can
solve it".

> indeed be stated as separate problems.

They already are being done in different ways, to some extent, and
this is for reasons well outside of the lack of "one unifying
standard". E.g., some DCs are L2 based. Some are more L3 based. That
is not going to change. There are valid (local) reasons for choosing a
particular approach in a given DC. Likewise, there are multiple ways
of gluing DCs together across the WAN (L2VPN, L3VPN, IPsec,
etc.). That is not going to change anytime soon either.

> Now, you have a huge issue in mapping one type of scheme into
> another, given the many possible ways to do each of mobility,
> segmentation, broadcast, multicast, policy, themselves.

The above is a great example of how the "problem space" we are talking
about sounds (to me) like boiling the ocean.

Do you believe that what this group needs to do is come up with one
set of protocols/standards for doing all of the above that can be used
everywhere, so that one standard is used everywhere across the
Internet?

> based or control plane based.

Are you saying you think this group can and should come up with a
one-size-fits all approach that applies everywhere, including data
centers and across the WAN?

> many alternatives will eventually mean that things don't work

We are dreaming if we think we will not have permutations and
variations. They exist already today for local business and other
reasons and will not magically disappear anytime soon. And having lots
of permutations is not necessarily a problem if the interfaces between
components (e.g., like between the DC and the WAN) are clean and well
defined, so that each "permutation" fits in with the existing model,
so that interfacing between the two systems is straightforward and
routine.

As one example, today many DCs use VLANs for multi-tenancy internally,
but use VPLS when going across the WAN. At the boundary between VLANs
and L2VPN, you have to map VLAN identifiers into the VPLS
equivalent. This is the well-defined interface between the two
systems.

If instead of VLANs, the DC used something like NVO3/VXLAN/NVGRE,
you'd have to do the same: map from the NVO3/VXLAN/NVGRE tenant
identifier into the corresponding L2VPN identifier. Have we added some
new complexity here? Not really. We've just added a new mapping, that
is conceptuatlly the same as the one already being used today with
VLANs. We have not made the "mapping problem" any more complex than it
already was.

> worsens interoperability.

Sounds to me like you think we can somehow magically wave away
diversity that already exists today, and replace it with one overall
standard. Is that what you think this group needs to do?

Thomas

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Sat, 7 Jan 2012 19:12:41 +0530

Thomas,

>> You have to have an overall architecture/vision of how things fit
together, and then individual components that fit into the overall
architecture.

Yes, that's what should happen. Can you say where that
architecture/vision is described, vs. the individual components? Once
that architecture has been agreed, then people can go into "smaller"
problems and their solutions. 

Thanks, Ashish

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Saturday, January 07, 2012 7:04 PM
To: Ashish Dalela (adalela)
Cc: Stewart Bryant (stbryant); Ronald Bonica; [email-masked];
[email-masked]

Hi Ashish.

Thomas

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Sat, 7 Jan 2012 19:14:39 +0530

Hi Xuxiaohu,

Obviously, DCI will have a different forwarding plane. But, DCI could use the same control plane as DCN.

Thanks, Ashish

-----Original Message-----
From: Xuxiaohu [mailto:[email-masked]] 
Sent: Saturday, January 07, 2012 1:22 PM
To: Ashish Dalela (adalela); Thomas Narten; Stewart Bryant (stbryant)
Cc: Ronald Bonica; [email-masked]; [email-masked]
Subject: re: [dc] DC Work Plan

Hi Ashish,

Best regards,
Xiaohu

---

From: Melinda Shore <[email-masked]>
Date: Sat, 07 Jan 2012 10:43:29 -0900

> problems and their solutions.

I think that this has really not been a very common approach in
the IETF in the past, although you do see it a lot in other standards
bodies.  My personal comfort level with the way the "data center"/
cloud set of stuff has been approached is not that high because it
doesn't appear to have been driven by real-world problems but rather
by a vague sense that the IETF ought to be doing something in this
problem space (and "problem space" is overly vague, as well).
It appears reasonably clear to me that there's at least some small
set of specific problems that fall into this space and that can
be framed in a way that the IETF knows how to tackle.  Regardless
of the value of a very, very high-level architectural approach I
don't think that it could be done very well in this body and I would
be reluctant to try.

I also expect that if we told operators what we think their data
centers should look like we'd be putting ourselves on the path to
irrelevance.  They're going to do what they're going to do - I
think we have to be responsive to their needs.  They care about
service differentiation and competitive advantages, and if our
work can't support that (because we've got a high-level architecture
that must be conformed to for our individual technologies to be
useful) we've got a problem.

So, a good, short list of clearly-defined problems seems like a good
place to start, to me.  See how they relate to each other, if they
do, and how they relate to other work in the IETF.

Melinda

---

From: Bhumip Khasnabish <[email-masked]>
Date: Sat, 7 Jan 2012 16:52:30 -0500

Hello Ashish,

We have done some work on Cloud/DataCenter reference architecture
(http://tools.ietf.org/id/draft-khasnabish-cloud-reference-framework-02.txt)

and had some discussion along the line you are talking about during

IETF-81 (pls see the slides at
http://www.ietf.org/proceedings/81/slides/opsawg-3.pdf )

Thanks.

Best.

Bhumip

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 09 Jan 2012 15:29:04 +0100

Hi Ashish,

I'd like to see a couple of additions to the document on requirements.

First, section 4 should introduce what it is discussed later on under 5.9 (cloud control) as the "deep control", from the application layer down to L2 properties is a characteristic rather specific of cloud datacenter infrastructures.

Second, section 5 should add a discussion on AAA aspects, and how identity is mapped down the protocol stack from the requesting user authentication and authorization data, and conversely accounting records are marked and aggregated up the protocol stack to provide appropriate information and, eventually, match them against SLA requirements. I think this would deserve a separate subsection, but it could be included under 5.9 as well.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: <[email-masked]>
Date: Tue, 10 Jan 2012 01:17:13 -0500

Ashish,

I need to find the time to seriously take a look at your requirements draft,
but Linda's already pointed out a number of things that need attention.

> unicast, policy (e.g. bandwidth) are spanning across both intra and

For the L2 networking service usually used for VM mobility, that service
has to be provided consistently in the data centers and across the
network that interconnects.

> indeed be stated as separate problems. 

That's a fine exercise in strawman demolition, but it's beside the point,
because it ignores layering of network services.  Nobody is proposing
decomposing the L2 networking service used by the VMs into the functional
sub-components listed above.  The L2 service used by the VMs has to be
consistent, but it can be run over a variety of underlying infrastructure.

> Now, you have a huge issue in

I think this comment is seriously off-course, as I think the mapping problem
among the intra-dc and inter-dc technologies is important.

For the sake of argument, assume that this mapping problem is intractable
and one solution should be selected, starting with the data planes.  For
the L2 networking service that is currently expected for VM mobility,
there are at least 4 interesting data planes for the data center - IEEE
SPB/PBB, TRILL, and the two new NVO3 planes (VxLAN and NVGRE).  Framing
the "problem" as picking one of those data planes as the "winner" requires
deciding which 3 of those 4 proverbial "oxen" to gore.  The "oxen" tend
to win that sort of battle :-(.

As Robert (and others) have pointed out, there's an interesting opportunity
here, in that all four of these data planes are converging on a 24-bit
network identifier for isolation purposes.  For these technologies, VM
mobility and segmentation basically work, so there's an opportunity to
develop some commonality among the other aspects by attacking the

> many alternatives will eventually mean that things don't work together.

We may not be able to map everything to everything, but there's enough
of an opportunity here to do something interesting and useful.  A common
interface between the L2 service in the data center and VPNs that carry
that L2 service across data centers is one productive "place to dig".

As for the cited examples, I really wonder ...
 
> control plane based.

The reverse is much more likely.  Use of gratuitous ARPs predates VM
mobility by many years.  They are a fact of life that need to work in
data centers.

> If intra-dc uses VLAN for segmentation then it
> doesn't help inter-dc to use GRE.
 
That's wrong, sorry.  See draft-hasmit-otv-03 for a counterexample.
OTV happens to use UDP instead of GRE, but it's the same basic idea.

> If the unicast is multi-path then it
> doesn't help if multicast and broadcast are static trees.

Bad idea - don't do that ... thereby reducing the interesting portion
of the problem space.

> If one DC is L2 encap then it doesn't help if another DC is L3 encap. 

Really?  http://www.ietf.org/proceedings/82/slides/l2vpn-8.pdf from
the Taipei proceedings strongly suggests otherwise.

> Note that this
> a L2 IS-IS forwarding entry.

That's also wrong - the L2 IS-IS functionality is encapsulated in a
fashion that the L3 routing can't see - OSPF at L3 has no idea that
IS-IS is running at L2.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ashish Dalela (adalela)
> Sent: Saturday, January 07, 2012 12:39 AM
> To: Thomas Narten; Stewart Bryant (stbryant)

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Tue, 10 Jan 2012 16:02:01 +0530

Hi Diego,

Could you please provide the text for these sections? I agree that a single mgmt/control plane that controlled from application to L2 hasn't existed so far. Right now that is managed through "cloud APIs" which cross these layers, although information across layers is not always integrated.

Thanks, Ashish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Monday, January 09, 2012 7:59 PM
To: [email-masked]
Subject: Re: [dc] DC Work Plan

Hi Ashish,

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
Mobile: +34 682 051 091

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 11 Jan 2012 11:30:46 +0100

Hi Ashish,

> Could you please provide the text for these sections? I agree that a single mgmt/control plane that controlled from application to L2 hasn't existed so far. Right now that is managed through "cloud…

What about this?

8<--------------
4.4. Holistic Control

   Users in a multi-tenant model require a deep control of the whole
   infrastructure on which their applications run. In contrast with the
   traditional management models in which separate entities took care
   of separate aspects of the infrastructure (the network layer, the
   operating system environment, the security mechanims, the application
   environment, etc), the cloud paradigm assumes it will interface with
   a single entity defining and monitoring all aspects of the infrastructure.

   In what relates to the network aspects, this implies the need for
   coherent management interfaces accross the different layers, from
   the application down to the link and even physical layers. These
   interfaces must, on the one hand, translate between the top-level
   APIs users employ to configure the infrastructure down to the actual
   protocols and APIs deployed, and on the other, be able to present
   abstractions suitable to be applied at each point. An example of this
   could be the availability of virtual firewall rules for users to define,
   translated into ACLs or forwarding rules at routers, switches, or
   hypervisors themselves.

   Two key properties of these interfaces are information consistency
   accross layers, so abstractions do not hide relevant details, and
   bi-directionality: it is about the network knowing about the applications
   as much as the applications knowing about the network.

8<--------------
(It is proposed that this goes between the current 5.9 and 5.10 subsections, so
the one entitled "The Forwarding Plane Scale Problem" becomes 5.11)

5.10. The AAA Problem

   Alll the control mechanisms outlined above require appropriate methods
   for establishing the identity and rights of both the controlling and the
   controlled entities, as well as for collecting information about their effects
   and the performance of the infrastructure. In other words, Authentication,
   Authorization and Accounting (AAA) methods.

   User identities and rights are usually established via the cloud API
   authentication and authorization procedures, based on common Web
   Services protocols and data representations. Conversely, users refer to
   virtual resources when interacting with the infrastructure, defining the
   rules under which sensitive data can be used and processed. These
   identities and rights data must be appropriately progressed down to the
   network infrastructure, maintaning their semantics.

   Some solutions to map the refined user authentication and
   authorization procedures available at the application layer into network
   infrastructure protocols are being discussed, though their application
   in the concrete aspects of cloud APIs and the protocols being discussed
   here remains obviously open. Furthermore, the mechanisms for
   mapping virtual resource identities to their actual realizations constitute
   an open challenge.

   Accounting requires to work in the opposite direction: Actual accounting
   happens at the real infrastructure components and need to be marked
   and aggregated up the virtualization layer stack to provide appropriate
   information, eventually suitable to be matched against SLA requirements.
   In this process resource identity mappings play a key role on what to
   be aggregated and how, and user identity mappings define where this
   aggregates must be collected

8<--------------

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
Mobile: +34 682 051 091

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 11 Jan 2012 11:42:07 +0100

Hi again,

>> Could you please provide the text for these sections? I agree that a single mgmt/control plane that controlled from application to L2 hasn't existed so far. Right now that is managed through "clou…

In what relates to this common management plane I'd like to draw your attention to the ideas around Crosss-Stratum Optimization, a work area proposed as WG to IETF/IRTF. There was a BoF in Taipei and the issue is ongoing. You have a couple of introductory drafts on this here:

http://tools.ietf.org/html/draft-contreras-cso-functional-architecture-00
http://tools.ietf.org/html/draft-tovar-cso-path-computation-requirements-00

And there is a workshop on this matter arranged for this summer:

http://cccso.net/

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
Mobile: +34 682 051 091

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 11 Jan 2012 14:36:18 +0000

On Jan 11, 2012, at 11:42, DIEGO LOPEZ GARCIA wrote:
> In what relates to this common management plane I'd like to draw your attention to the ideas around Crosss-Stratum Optimization, a work area proposed as WG to IETF/IRTF. There was a BoF in Taipei and the issue is ongoing. 

There was *NOT* an IETF BOF in Taipei. There was a side meeting with the intent to propose an IRTF research group. (Which I decided to not charter.)

Lars