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

From: Thomas Narten <[email-masked]>
Date: Wed, 04 Jan 2012 12:59:05 -0500

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

---

From: David Allan I <[email-masked]>
Date: Wed, 4 Jan 2012 13:56:26 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Wednesday, January 04, 2012 9:59 AM
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.

>    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.

>    more points in the path and that is an approach that can't be 

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.

>    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?

>    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?

>    network is as dynamic as the hosts themselves.

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

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?

...

>    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

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 5 Jan 2012 12:18:45 +0530

Going by the number of map-encap approaches out there that don't scale
at the network boundaries (access, interconnect, etc.) it would *seem*
that we did not give adequate attention to scale. It might be that the
alternatives haven't been present. I'm ok to modify this statement as
follows: "Scalability is a primary consideration to be kept in mind,
because without the intended scale, any solution will work". Does that
sound right?

>> I suspect there is general agreement that the above is a general
"problem".

Yes, so we have restated the obvious to a lot of people in IETF. When
collecting the problem statement, I believe the starting point should be
from what is very well deployed today, and that is STP and OSPF. 

You perhaps missed the following problem statement:

<snip>
   treating inter and intra datacenter
   as entirely independent leads to new issues at the edge that arise
   from trying to map one forwarding approach within datacenter to
   another forwarding approach between datacenters. In some cases, both
   L2 and L3 approaches may be needed to connect two datacenters.
   Further, ideally, customer segmentation in the internet needs to be
   done similar to the segmentation in the datacenter. This simplifies
   the identification of a customer's packets in the Internet as in the
   datacenter. Common QoS and Security policies can be applied, in both
   the domains if there is a common way to identify packets
</snip>

The key problem is still that datacenter inter-connectivity is not
necessarily about connecting DC between the same provider. It is also
about connecting them between private and public domains. We could use
an approach that makes the provider DC edge scale very high, but you
can't do that for a customer who has a smaller datacenter - you will be
pushing the complexity to the customer edge, and their devices aren't
designed to scale. In other words, if I have a large public cloud
connected to a small private cloud, should the small cloud bear the
burden of the large cloud? That needs better stating, I agree.

>> 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?

There are many approaches out there, and the discussion of approaches is
in the separate draft.
tools.ietf.org/html/draft-dalela-dc-approaches-00. We understand that
many of these problems may have been stated in other places. But, we
can't avoid that.

>> Isn't this already possible, and indeed, happening today? What IETF
work is needed? What standards gap needs filling?

Not necessarily. Take the example of two architectures - scale-up vs.
scale-out and compare them for map-encap. The scale-up model requires
less switch-to-switch map-encaps but a lot more internal mapping. So,
from a technology perspective, there is no problem at all if you look at
this from the outside. I can claim that I have one huge switch in which
everything is connected. The problem is just abstracted from view, and
it may be inside the huge switch. Contrast this with the scale-out model
where there are many smaller switches and the map-encap is externalized.
The problem is more visible. The technology you devise has to be such
that I can do both scale-up and scale-out. 

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

If you have looked at the other thread which talked about number of
routes, a 1M VM datacenter can require several million host-routes. That
implies slow convergence. There have been other discussions on
convergence as well that talked about pulling out a route on-demand when
packets arrived.

No it is not overtly. Internally, this is also tied to the flow mgmt
problem.

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.

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.

...

Thomas

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 5 Jan 2012 12:28:01 +0530

David,

A total of 1 sentence was dedicated to the L2 problem - "L2 networks
can't be made to scale because of high number of broadcasts." And Linda
has commented on this that the scaling issue is also due to MAC
summarization, modification to be done. There is absolutely no
discussion about pre-VLAN days, and I would like to know where you see
it. Broadcast is contained by VLAN, and we are talking of that. 

L2VPN is another story - because there was VPLS, and then there are lots
of new things. There are problems to be solved, and then problems to be
solved given some solution. So, the problem boundary shifts from the
time you take something as a "given". People generally take OSPF (or
some L3 routing protocol) and VLAN as a given in the datacenter. Rest is
not a "given". So, we have to start from what is given.

I'm fine, if we want to change the given to something else. Let me know
what we think is the given today.

Thanks, Ashish

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: Thursday, January 05, 2012 12:26 AM
To: Thomas Narten; Ashish Dalela (adalela)
Cc: [email-masked]
Subject: RE: [dc] draft-dalela-dc-requirements-00.txt

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-----

Hi Ashish.

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.

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.

>    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.

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.

...

Thomas

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 05 Jan 2012 09:59:46 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Ashish
> Dalela (adalela)
> 发送时间: 2012年1月5日 14:58
> 收件人: David Allan I; Thomas Narten
> 抄送: [email-masked]
> 主题: Re: [dc] draft-dalela-dc-requirements-00.txt
> 
> David,
> 

To help understanding whether there is any specific IETF work that needs to be done, it's worthwhile to evaluate whether the existing and proven VPN technologies could be used in the data center to solve the problems faced by "the given solutions" as you mentioned. For instance, could the VPLS solution address the scaling issue associated with the VLAN+STP solution, or could the host route based L3VPN solution could solve the problem associated with the host route based OSPF solution... if not, what's missing?

Best regards,
Xiaohu

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 5 Jan 2012 16:48:46 +0530

Hi Xuxiaohu,

I think there is some confusion about the purpose of these drafts.

dc-requirements - defines the problems that need to be solved for datacenter users. Doesn't yet imply anything to be done by the DC IETF WG, as these problems *may* have been solved. Ideally, if this was the case, we won't have the draft and the discussion. So, then the next one.

dc-approaches - analyzes current approaches to solve dc-requirements, and identifies their problems (these are second order problems, that arise when you try to solve the original problem). That takes us to the problem statement for the DC WG, because current solutions are not optimal.

So - you have two tiers of problems 

- First, the ones that we originally need to solve - the GOAL.
- Second, the issues that you need to fix, in trying to solve the original problem - the ISSUES.

Can we just describe ISSUES, and not GOALS? Well, it's important to keep the GOALS in mind, in trying to address ISSUES, because we might address one of the ISSUES in a way that misses the overall GOALS. Discussions on this alias have been both about GOALS and ISSUES.
	
Hope this is helpful. Look forward to your comments. I believe both GOALS and ISSUES can be clarified further.

Thanks, Ashish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, January 05, 2012 3:30 PM
To: Ashish Dalela (adalela); David Allan I; Thomas Narten
Cc: [email-masked]
Subject: Re: [dc] draft-dalela-dc-requirements-00.txt

Best regards,
Xiaohu

---

From: Thomas Narten <[email-masked]>
Date: Thu, 05 Jan 2012 11:10:47 -0500

> because without the intended scale, any solution will work". Does that

I don't want to nitpick on this wording, but I wouldn't use wording
like "any solution will work". But I did want to point out that
implying or saying that the IETF doesn't care about scaling is just
not true (and not helpful).

> burden of the large cloud? That needs better stating, I agree.

Sorry, I don't understand how this leads to a concrete, specific
problem that the IETF needs to work on.

This is just too high-level, general stuff. We can argue forever about
whether it's true, what it means, etc. But I don't think that sort of
discussion is productive or useful.

Please identify a specific problem with (say) a specific protocol or
deployment where what we have today doesn't work adequately and needs
a better approach. We need more details of a real problem experienced
by operators out in the field.

> many of these problems may have been stated in other places. But, we

The purpose of this list (presumably) is to focus on new problems or
problems that aren't being discussed elsewhere already.

What are the problems for which there isn't a potential home yet?
Those are the ones we should be trying to tease out here.

> that I can do both scale-up and scale-out.

Again, this is too high-level. We need to talk more specificically
about protocols and IETF documents that are insufficient or need to be
developed.

> convergence as well that talked about pulling out a route on-demand when

"slow convergence" in a general sense is not an IETF problem.

Which specific protocol is being used today (i.e., in real
deployments) that doesn't converge adequately? Do others agree that
there are problems with that protocol that require solutions?

> No it is not overtly. Internally, this is also tied to the flow mgmt
nn

> isn't true for cloud at least.

Sounds to me like the topic of SLAs could be standalone and result
(potentially) in its own work group (or additional work in existing
WGs). But to get there, a problem statement document that focused
specifically on SLA issues would seem to be a good starting point.

I.e., what is done today, what protocols are used, why they are
inadequate, what sort of IETF work is needed to close those gaps. But
you need to drill down and provide more details about what is needed
and why.

Do others agree with this? What are some of the perceived gaps?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 05 Jan 2012 11:16:18 -0500

David,

> An absolutely flat L2 network does not scale...duh!

Indeed! :-)

>  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.

Just how widely deployed are 24-bit VLAN tags these days? Presumably
you are referring to PBB/SPB?

What are the deployment trends for 24-bit VLAN tags in data centers?
Is this starting to happen? Does it look like there will be
significant deployments? Or will there be lots of deployments that
choose not go use them (for whatever reason)?

It would be useful to hear from operators what they are doing or
thinking of doing w.r.t. to 24-bit VLAN tags.

Thomas

---

From: David Allan I <[email-masked]>
Date: Thu, 5 Jan 2012 12:48:03 -0500

Hi Thomas:
 
<snipped>

> Just how widely deployed are 24-bit VLAN tags these days? Presumably you are referring to PBB/SPB?

Well 802.1ah PBB has the 24 bit I-tag....which is also used by 802.1aq SPBM, but that is only one example.

I believe (but do not quote me) that the VmWare vCDNI port group is a 24 bit identifier....(analogous concept)....

The VxLAN VNI is 24 bits.

The OTV Overlay ID is 24 bits...

Etc.

So just about every currently proposed solution I know of seems to be aligned...

> Is this starting to happen? Does it look like there will be significant deployments? Or will there be lots of deployments that choose not go use them 
> (for whatever reason)?

> It would be useful to hear from operators what they are doing or thinking of doing w.r.t. to 24-bit VLAN tags.

Not being an operator, I can't comment on deployment. I agree operators chiming in would be useful...

Cheers
D

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 5 Jan 2012 23:27:55 +0530

Thomas,

You are confusing the nature of two drafts. As I said on the other
email, one is about GOALS and the other is about ISSUES. You are looking
for the second type of thing in the first one. We have many examples of
how to solve issues without addressing all goals.

Thanks, Ashish

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, January 05, 2012 9:41 PM
To: Ashish Dalela (adalela)
Cc: [email-masked]
Subject: Re: [dc] draft-dalela-dc-requirements-00.txt

nn

Thomas

---

From: David Allan I <[email-masked]>
Date: Thu, 5 Jan 2012 13:26:02 -0500

HI Ashish:

Well as I indicated, for many the scale problem simplifies to virtualizing large numbers of broadcast domains. IMO that is one "criteria of goodness".

We COULD postulate that scaling the size of individual virtualized broadcast domains is also a problem, but IMO that is simply a network/application design BCP, not an issue.

My observation actually applies to a number of drafts in both DC and ARMD....this thread simply prompted me.

Cheers
D

-----Original Message-----
From: Ashish Dalela (adalela) [mailto:[email-masked]] 
Sent: Wednesday, January 04, 2012 10:58 PM
To: David Allan I; Thomas Narten
Cc: [email-masked]
Subject: RE: [dc] draft-dalela-dc-requirements-00.txt

David,

A total of 1 sentence was dedicated to the L2 problem - "L2 networks can't be made to scale because of high number of broadcasts." And Linda has commented on this that the scaling issue is also due to MAC summarization, modification to be done. There is absolutely no discussion about pre-VLAN days, and I would like to know where you see it. Broadcast is contained by VLAN, and we are talking of that. 

L2VPN is another story - because there was VPLS, and then there are lots of new things. There are problems to be solved, and then problems to be solved given some solution. So, the problem boundary shifts from the time you take something as a "given". People generally take OSPF (or some L3 routing protocol) and VLAN as a given in the datacenter. Rest is not a "given". So, we have to start from what is given.

I'm fine, if we want to change the given to something else. Let me know what we think is the given today.

Thanks, Ashish

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: Thursday, January 05, 2012 12:26 AM
To: Thomas Narten; Ashish Dalela (adalela)
Cc: [email-masked]
Subject: RE: [dc] draft-dalela-dc-requirements-00.txt

;-)
Dave

-----Original Message-----

Hi Ashish.

...

Thomas

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 5 Jan 2012 19:49:48 +0100

David, before we say broadcast domains is not an issue we should understand how many we will be expecting. Also multicast state has its limits btw.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: donderdag 5 januari 2012 19:26
To: Ashish Dalela (adalela); Thomas Narten
Cc: [email-masked]
Subject: Re: [dc] draft-dalela-dc-requirements-00.txt

HI Ashish:

Cheers
D

-----Original Message-----
From: Ashish Dalela (adalela) [mailto:[email-masked]] 
Sent: Wednesday, January 04, 2012 10:58 PM
To: David Allan I; Thomas Narten
Cc: [email-masked]
Subject: RE: [dc] draft-dalela-dc-requirements-00.txt

David,

Thanks, Ashish

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: Thursday, January 05, 2012 12:26 AM
To: Thomas Narten; Ashish Dalela (adalela)
Cc: [email-masked]
Subject: RE: [dc] draft-dalela-dc-requirements-00.txt

;-)
Dave

-----Original Message-----

Hi Ashish.

...

Thomas

---

From: David Allan I <[email-masked]>
Date: Thu, 5 Jan 2012 13:55:57 -0500

HI Wim:

Perhaps I should have been more precise. I did not mean it was not an issue, it was that I take the requirement to virtualize large numbers of them as a given, and scaling that is the issue.

I hope that's clearer...and we're in wild agreement ;-)
Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: donderdag 5 januari 2012 19:26
To: Ashish Dalela (adalela); Thomas Narten
Cc: [email-masked]
Subject: Re: [dc] draft-dalela-dc-requirements-00.txt

HI Ashish:

Cheers
D

-----Original Message-----
From: Ashish Dalela (adalela) [mailto:[email-masked]]
Sent: Wednesday, January 04, 2012 10:58 PM
To: David Allan I; Thomas Narten
Cc: [email-masked]
Subject: RE: [dc] draft-dalela-dc-requirements-00.txt

David,

Thanks, Ashish

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: Thursday, January 05, 2012 12:26 AM
To: Thomas Narten; Ashish Dalela (adalela)
Cc: [email-masked]
Subject: RE: [dc] draft-dalela-dc-requirements-00.txt

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.

;-)
Dave

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

Hi Ashish.

...

Thomas

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 5 Jan 2012 20:50:45 +0100

Dave, yes we are. It would be good to get some perspective on the required scale from the people pushing the overlay solution. There are some options to aggregate flooding domains but it will depends on the scale if we would need such mechanism in the overlay solution or not.

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: donderdag 5 januari 2012 19:56
To: Henderickx, Wim (Wim); Ashish Dalela (adalela); Thomas Narten
Cc: [email-masked]
Subject: RE: [dc] draft-dalela-dc-requirements-00.txt

HI Wim:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: donderdag 5 januari 2012 19:26
To: Ashish Dalela (adalela); Thomas Narten
Cc: [email-masked]
Subject: Re: [dc] draft-dalela-dc-requirements-00.txt

HI Ashish:

Cheers
D

-----Original Message-----
From: Ashish Dalela (adalela) [mailto:[email-masked]]
Sent: Wednesday, January 04, 2012 10:58 PM
To: David Allan I; Thomas Narten
Cc: [email-masked]
Subject: RE: [dc] draft-dalela-dc-requirements-00.txt

David,

Thanks, Ashish

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: Thursday, January 05, 2012 12:26 AM
To: Thomas Narten; Ashish Dalela (adalela)
Cc: [email-masked]
Subject: RE: [dc] draft-dalela-dc-requirements-00.txt

;-)
Dave

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

Hi Ashish.

...

Thomas