Carrier Ethernet

[Mark]

Hello,

they often say, for example http://en.wikipedia.org/wiki/Carrier_Ethernet
that such concepts as "bridge" or "spanning tree" don't scale well to large
networks. What exactly is meant here by "scale" ?

Thanks.

Mark

[Robert Wessel]

Quite simply that bridges and the spanning tree protocol won't work on
really large networks. For example, most bridges (switches) can only
learn a few tens of thousands of MAC addresses - and if there are more
devices than the bridges can learn, frames get broadcast to all
attached LANs. Further the way that addresses are propagated around
the network, and how the network organizes itself, also fairs poorly
in large networks.

Routing, OTOH, is much more hierarchical, and network interconnections
are managed much more explicitly, so it scales far better. Basically
the Internet is all routed (as opposed to bridged), with the obvious
exception of relatively local and small bridged networks (usually
smaller than a few thousand nodes).

[Barry Margolin]

In article <g2dv68dkuhkjv1q4d...@4ax.com>,

Robert Wessel <robert...@yahoo.com> wrote:

> On Fri, 5 Oct 2012 23:57:04 -0400, "Mark"
> <mark_cruz...@hotmail.com> wrote:
>
> >Hello,
> >
> >they often say, for example http://en.wikipedia.org/wiki/Carrier_Ethernet
> >that such concepts as "bridge" or "spanning tree" don't scale well to large
> >networks. What exactly is meant here by "scale" ?
>
>
> Quite simply that bridges and the spanning tree protocol won't work on
> really large networks. For example, most bridges (switches) can only
> learn a few tens of thousands of MAC addresses - and if there are more
> devices than the bridges can learn, frames get broadcast to all
> attached LANs. Further the way that addresses are propagated around
> the network, and how the network organizes itself, also fairs poorly
> in large networks.

Anyone remember back in the 80's when the telecoms thought that they
could build nationwide networks as a single (or maybe a few large) ATM
cloud?

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[alexd]

Mark (for it is he) wrote:

> they often say, for example http://en.wikipedia.org/wiki/Carrier_Ethernet
> that such concepts as "bridge" or "spanning tree" don't scale well to
> large networks.

From reading that article, it seems that Carrier Ethernet is just some
extensions to ethernet, not a fundamental change to how any of it works.
However, Light Peak and Firewire being described as competitors to ethernet
in the context of carrier networks seems somewhat suspect to me, and throws
the editing of the entire article into doubt in my opinion.

--
<http://ale.cx/> (AIM:troffasky) (UnSoEs...@ale.cx)
07:39:29 up 2 days, 10:52, 4 users, load average: 1.79, 1.88, 1.15
Qua illic est reprehendit, illic est a vindicatum

[Robert Wessel]

On Sat, 06 Oct 2012 02:13:16 -0400, Barry Margolin
<bar...@alum.mit.edu> wrote:

>In article <g2dv68dkuhkjv1q4d...@4ax.com>,
> Robert Wessel <robert...@yahoo.com> wrote:
>
>> On Fri, 5 Oct 2012 23:57:04 -0400, "Mark"
>> <mark_cruz...@hotmail.com> wrote:
>>
>> >Hello,
>> >
>> >they often say, for example http://en.wikipedia.org/wiki/Carrier_Ethernet
>> >that such concepts as "bridge" or "spanning tree" don't scale well to large
>> >networks. What exactly is meant here by "scale" ?
>>
>>
>> Quite simply that bridges and the spanning tree protocol won't work on
>> really large networks. For example, most bridges (switches) can only
>> learn a few tens of thousands of MAC addresses - and if there are more
>> devices than the bridges can learn, frames get broadcast to all
>> attached LANs. Further the way that addresses are propagated around
>> the network, and how the network organizes itself, also fairs poorly
>> in large networks.
>
>Anyone remember back in the 80's when the telecoms thought that they
>could build nationwide networks as a single (or maybe a few large) ATM
>cloud?

Sure, although I've always thought that the telecoms get a bit too
much grief for not realizing that packet switching was the wave of the
future.

In the early eighties, the (effectively) virtual circuit switched
phone network was orders of magnitude larger than the Internet. Even
IBM's *internal* SNA network (also effectively VC) was bigger than the
entire Internet until about 1985/86. Also, in that era, well before
the WWW, connections/sessions tended to have absurdly (by current
standards) long lifetimes, even on the Interne,. Think TELNET and FTP
type sessions dominating traffic. And on the local side, connections
between things like workstations and servers could also easily be
considered very long term. Even some of the interactive precursors to
the WWW, like NAPLPS/videotex/teletext, were oriented around long term
connections. In such an environment, a (virtual) circuit switched
approach, with the associated high circuit setup costs, is at least
reasonable.

Even today, large parts of the Internet run over telco provided
circuits, many of which are actually running ATM under the hood
(SONET/SDH links, and most DSL lines), although that is declining,
particularly at the higher end.

But having vast numbers of very short-lived connections makes the
circuit switched approach much less attractive. Although there are
ongoing and repeated efforts to bring some of the advantages of
circuit switching back to IP routing (IP Flows, for example).

And there's a bit of a terminology problem. A "switch" was the
traditional name of the device handling circuit switched connections,
and was really nothing like what we'd have called a "bridge" on
packet/frame oriented LANs. And as I mentioned some of the switching
systems had demonstrated far greater scalability than any packet
switching network at the time. The adoption of the term "switch" for
marketing Ethernet bridges just adds to the confusion.

[Doug McIntyre]

alexd <trof...@hotmail.com> writes:
>Mark (for it is he) wrote:

>> they often say, for example http://en.wikipedia.org/wiki/Carrier_Ethernet
>> that such concepts as "bridge" or "spanning tree" don't scale well to
>> large networks.

>From reading that article, it seems that Carrier Ethernet is just some
>extensions to ethernet, not a fundamental change to how any of it works.

Right. Typically the providers need to still provide network
separation, and utilize VLANs or tunnelling to do so. Most of the
carrier ethernet has to deal with doing vlans inside vlans, or mapping
customer vlans into the service provider network safely. Setting up EVCs
for an ethernet equivilent of the "PVC" that telcos understand well.

There is also some monitoring of far end (OAM) for end-to-end
connectivity monitoring.

>However, Light Peak and Firewire being described as competitors to ethernet
>in the context of carrier networks seems somewhat suspect to me, and throws
>the editing of the entire article into doubt in my opinion.

What, didn't they bring up bluetooth PAN as well? :)

[Michelot]

Hi, Mark

> they often say, for examplehttp://en.wikipedia.org/wiki/Carrier_Ethernet

> that such concepts as "bridge" or "spanning tree" don't scale well to large
> networks. What exactly is meant here by "scale" ?

Bridges are indeed used in network providers.

Spanning tree is generally not used. If the provider is adding a
bridge, STP would disrupt its network too long time, to converge.

In Ethernet WAN, we consider connectionless paths (CL) and oriented
connection paths (CO). With CO paths, address learning process is
useless.

Best regards,
Michelot

[Stephen]

On Fri, 05 Oct 2012 23:43:54 -0500, Robert Wessel
<robert...@yahoo.com> wrote:

>On Fri, 5 Oct 2012 23:57:04 -0400, "Mark"
><mark_cruz...@hotmail.com> wrote:
>
>>Hello,
>>
>>they often say, for example http://en.wikipedia.org/wiki/Carrier_Ethernet
>>that such concepts as "bridge" or "spanning tree" don't scale well to large
>>networks. What exactly is meant here by "scale" ?
>
>
>Quite simply that bridges and the spanning tree protocol won't work on
>really large networks. For example, most bridges (switches) can only
>learn a few tens of thousands of MAC addresses - and if there are more
>devices than the bridges can learn, frames get broadcast to all
>attached LANs. Further the way that addresses are propagated around
>the network, and how the network organizes itself, also fairs poorly
>in large networks.

Bridging has some tables and overheads that grow faster than linear
with the number of connections and devices across the entire set of
indirectly connected switches.

Every end point connected to a bridged system has at least 1 MAC
address, and any traffic to that device implies that MAC has entries
in some or all the devices that make up the network.

This means linear scaled up table space is needed, but the maintenance
overheads that occur grow more quickly as well.

The other practical problem is that a network needs to be stable to
operate well, and in practice that means that you need ways to limit
changes to parts of the system so their effect stay local.

in bridging a topology change can propagate across the system.

>
>Routing, OTOH, is much more hierarchical, and network interconnections
>are managed much more explicitly, so it scales far better. Basically
>the Internet is all routed (as opposed to bridged), with the obvious
>exception of relatively local and small bridged networks (usually
>smaller than a few thousand nodes).

Think of the hierarchy in routing as being selective information
hiding.

Instead of 1 entry per MAC address for 100,000 devices in table for a
big corporate network, you may need just 1 or a few routing entries
saying "xxx corp is that way".

This means any topology change in xxx corp stays within their system -
the rest of the system doesnt need to see it
--
Regards

stephe...@xyzworld.com - replace xyz with ntl

[Michelot]

Hi Stephen,

> Every end point connected to a bridged system has at least 1 MAC
> address, and any traffic to that device implies that MAC has entries
> in some or all the devices that make up the network.

In the user plane, a bridge is not a MAC end point.

Best regards,
Michelot

[Rick Jones]

In comp.dcom.lans.ethernet Robert Wessel <robert...@yahoo.com> wrote:
> Quite simply that bridges and the spanning tree protocol won't work
> on really large networks. For example, most bridges (switches) can
> only learn a few tens of thousands of MAC addresses - and if there
> are more devices than the bridges can learn, frames get broadcast to
> all attached LANs.

Wording quibble. Given the loaded nature of the word "broadcast" it
might be better to put that as "frames get transmitted out all
connected ports" or "frames get flooded out all connected ports" lest
some new folks think the frames get transformed into actaul broadcast
frames.

rick jones
--
web2.0 n, the dot.com reunion tour...
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[glen herrmannsfeldt]

The meaning of "scale" is in the sense of how one quantity must
change when you change another.

One can, for example, discuss the change in the size of the legs
of an animal with its weight. That is:

"How does an animal's leg scale with its weight?"

In many interesting and useful cases, the answer is an exponent.

How does a tree trunk diameter scale with tree height?

How does the speed of a transistor scale with its size?

How does the cost of a transistor scale with it speed or size?

Doesn't scale means that something else happens, such that
the scaling laws aren't useful anymore.

Transistors (and animals) don't scale well down to atomic size.
They also don't scale well up to planetary size.

-- glen