Ethernet, the latest religion

dsiegel's picture

If you've been on the technical side of this industry even a short time, you've no doubt run across debates that are so monumental and so emotion-driven that they are labeled religious debates.  Perhaps the debates are not really so monumental, but each side of the issue often represents a fundamentally different philosophy.  Some favorites of mine? 

  • Mac vs. Windows
  • PC w/ Unix vs. Unix Workstation
  • BSD vs. SVR4
  • Emacs vs. vi (or any other editor, really)
  • EISA vs. VLB
  • USB vs. Firewire
  • VHS vs. Betamax?
From the realm of networking, who could forget the long running debate between ATM and IP?  There were many arguments used against IP that were just plain false, like the security concerns around IP and it being easier to hack (which I found silly because all ATM/FR network were running IP atop ATM/FR).

That's why it makes me chuckle a bit to see the same type of argument used in to promote Ethernet as a substitute for IP-VPN in this article about advertising.com switching out their IP-VPN.

Bavisi said that because VPLS is a L2 service there is no need for the firewalls the London office of Advertising.com previously had to manage at the remote sites. ?Both IPsec [a.k.a. DIY] VPNs and IP VPNs delivered by carriers over MPLS networks are at Layer 3, and thus face security issues,? he said.

The first sentence is fine.  It's true, Ethernet (or an MPLS-based IP-VPN solution) eliminates the need for firewalls at each site.  You can safely run in a closed network environment with no IPsec tunnels or other hassle.  The downside to that, however, is that each site now has to use the main corporate center for all Internet traffic, which puts more strain on the WAN...which is great for the backbone provider.  Ultimately it means more business for them.

The second sentence I quoted is the FUD factor coming into play.  There could not possibly a difference in the security risk between an Ethernet VPN running IP and a closed IP-VPN network running IP.  The security risks inherent with an IP network, especially one connected to the Internet somewhere, are not necessarily lessened by moving to an Ethernet network, and the process of centralizing Internet Access and firewalls into one or more main hubs is a common design element in layer 2 and layer 3 VPN's alike.

In a way, the recent development effort into Ethernet remind me of one of the Fundamental Truths of Networking, as cited in RFC 1925.

(11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.

Ethernet as a WAN protocol (and the use of VLAN's for logical seperation, QoS, and site identifiers) reminds me an awful lot of ATM and Frame Relay, and MPLS reminds me an awful lot of ATM too.  ATM had QoS and Traffic Engineering and IP didn't, so along came MPLS to give some traffic engineering function and they put CoS into IP.  Now that we're trying to use Ethernet in the WAN, we've got to add all that stuff to it as well, so we'll run it over MPLS and make 802.1p to give it QoS.  We're re-inventing the wheel!

Those of you involved in the creation of these new Ethernet standards should remember your your RFC's.  That way you'd know that the twelfth fundamental rule of networking is

In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

Technorati Tags: , , ,

Trackback URL for this post:

http://blogs.globalcrossing.com/trackback/308
dsiegel – Wed, 2007 – 03 – 07 19:46

How about Ethernet vs Token Ring?

David - coming across your blog and GC's uber-blog for the first time today thanks to Andy at Nyquist Capital. Really enjoyed this post and the others. Regarding your post, while many of the people in the industry are engineers and claim to focus only on objective facts, the truth is that engineers are humans and get emotionally involved with their work - and religious about their protocols - then defend them with 'facts'. Ethernet is a survivor - partly based on the excellence of the original work and partly based on 'marketecture'. Ethernet today is nothing like the original IEEE 802.3 10Base5 CSMA/CD approach, but it remains cheap, works well and is backward compatible with most everything. Cheers Mark

Mark Showalter (not verified) – Fri, 2007 – 03 – 09 17:28

Re: Ethernet vs. Token Ring

dsiegel's picture

Welcome, Mark!

That was definitely another good battle, and maybe suffered the outcome it did because Token Ring was IBM vs. the rest of the world. In the end, I really believe that it was the practicality of the physical installation and troubleshooting the technology (10baseT..not thinnet or thicknet) that won over so many converts. Token ring eventually become a star topology as well, but by then 10baseT was entrenched and 100BaseT was on the way. There were still quite a few people using Token Ring-like tech like FDDI/CDDI, but FE still won.

I think that a lot of times it comes down to purely what people are comfortable with. As you say, engineers are humans, and humans have a tendenancy to come up with the data points that support the conclusion they want, while sometimes forgetting or discounting data points that fly in the face of it.

Caveat Emptor applies to the buyer of network services just like anything else. Ask a lot of questions, and get a second or third design opinion.

dsiegel – Fri, 2007 – 03 – 09 18:51

Ethernet.. latest religion

Now, in steps Nortel and PBB/PBT.  The argument of reversing the trend of reinvented signaling protocols and forwarding schemas to return to a world of relative simplicity -- especially in the core :)  Who needs MPLS and all of its complexity, problems and headaches?!

I think the presence of large-scale Ethernet WAN infrastructures is inevitable in order to satisfy the demand reported by every analyst worth their salt.  But the larger questions are how will those Ethernet WANs be built (PBB/PBT, T-MPLS, IP/MPLS) and whether or not other infrastructures will be folded into them or converged.  Infonetics noted that the largest project being undertaken in 2007 by service providers surveyed was the convergence of networks to a single IP/MPLS infrastructure.  So with the added momentum of Ethernet, does this mean that it should get in line with ATM/FR, VOICE and eventually Sonet/SDH for integration to a single IP/MPLS infrastructure OR does this mean that we need to step back and rethink the premise of consolidating at the IP layer and possibly consolidate at the Ethernet layer??

Which brings me back to Nortel (and Ericsson, and Siemens.. ) and PBB/PBT.  I think the jury is still out, though I am still firmly in the camp of consolidation to IP/MPLS and not rebuilding a new common infrastructure.  I think there are still many unanswered questions that exist before I would suggest a change in course.  I don't discount Ottawa's arguments of simplicity and economics.   I think we just need a little more time to understand them better, along with the long-term implications.  We should also not require an all or nothing approach to answering these questions.  It may be that a combination of Layer-2 and Layer-3 in different areas of the network that may be a suitable path forward, even when providing a common service!  

In the end.. its the progression from fixed-channel to packet switching that matters to me most.  We'll see how the Road to Packet gets paved.. as its still a work in progress.



Dave Cooper (not verified) – Thu, 2007 – 03 – 08 12:31

Re: Don't forget

dsiegel's picture

Indeed, the religious debate is not only around Ethernet, but even within the context of Ethernet there are debates around the best way to do it, e.g. SONET vs. MPLS. Great point!

dsiegel – Thu, 2007 – 03 – 08 11:31

Don't forget

The layer 1 battle royale! SONET/SDH vs. Ethernet/Packet over fiber/insert your own moniker

Schmitt (not verified) – Wed, 2007 – 03 – 07 22:06

Post new comment

*
*


*

  • Easily link to terms in various wikis or other websites by typing [[prefix:term]]. Use the "|" character to create a "piped link," e.g., "[[w:public transport|public transportation]]" displays as "public transportation." For a full list of available prefixes and the websites to which they point, see interwiki.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <pre> <br> <p> <em> <img> <blockquote> <table> <tr> <td>
  • Lines and paragraphs break automatically.
Verify comment authorship
Captcha Image: you will need to recognize the text in it.
*
Please type in the letters/numbers that are shown in the image above.