Smooth Sailing for VLAN Standard

Would Light Reading cover a set of standards meetings that didn't end in a fistfight? We would. Check it out:

The 802.1ad working group in the Institute of Electrical and Electronics Engineers Inc. (IEEE) has all the makings of a good brawl, namely a vital network technology being discussed by competing vendors. But, alas, the fists weren't flying last week when the group met in San Francisco.

“So far there is no controversy to report,” says Tony Jeffree, chairman of the working group. “There are always some minor disagreements in the early stage of developing a standard, but there hasn’t been anything major.”

One of the reasons the group might be working so well is because it has a clearly defined a purpose and a problem it’s trying to solve. The 802.1ad group is working to define a common way to implement virtual LAN (VLAN) stacking in Ethernet switches. VLAN stacking is a technology that allows carriers to slap on a public VLAN tag onto packets, so that they can be transported over a metro network. The important thing about the technology is that it maintains the integrity of the traffic, and it keeps one customer’s traffic separated from another’s traffic.

Most Ethernet switch vendors are already using their own implementation of VLAN stacking, and that's making carriers reluctant to deploy metro Ethernet at all. Getting locked into one vendor can be expensive. But a standard could help spur deployments, because carriers will be able to benefit from dual sourcing. This allows them to play one switch vendor against another for the best deal.

“We had to buy all of our Ethernet switches from a single vendor,” says Bob Klessig, director of engineering at Cisco Systems Inc. (Nasdaq: CSCO), who founded Telseon Inc.. “We could make it work, but in the long run we would have preferred to have multiple vendors to choose from.”

Another key reason things have been going so smoothly could be because the proposed fixes are not rooted in hardware. In the end, for vendors to comply with the standard, they’ll simply have to upgrade their switches with a new revolution of software.

“It’s always much harder and more expensive to change hardware,” says Craig Easley, a director in the office of the CTO at Extreme Networks Inc. (Nasdaq: EXTR). “That’s what happened with RPR.”

Ah, yes. The Resilient Packet Ring (RPR) working group. Recall that the RPR group once split into two camps fighting over how best to implement the technology for almost two years. Cisco was on one side of the battle, while Nortel Networks Corp. (NYSE/Toronto: NT) was on the other (see RPR Divided). Those were the days.

While the RPR debate centered around technology, the heart of the disagreement had to do with the fact that Cisco and Nortel each had their own proprietary versions of hardware already deployed in customer networks. Neither group wanted to spend the time or the money to make the necessary changes. In the end, the two companies compromised, and a new standard was formed that resembled neither Cisco’s nor Nortel’s implementations (see Cisco in U-Turn on RPR and IEEE Approves RPR Working Ballot).

The disagreement made carrier customers even more hesitant to deploy new RPR gear for fear that the vendor they chose wouldn’t comply with the standard. It also forced some vendors to spend more time, effort, and money on parallel technology development.

This time around, however, vendors involved in the 802.1ad development have been very accepting of proposals from Cisco. “Instead of pushing to do things their way, they have already been compromising” says Easley. “I think that has made the other vendors involved more comfortable. They haven’t been trying to force anything down anyone’s throat to get a leg up.”

Rest assured, though, when the throat ramming and leg upping begins, we'll be there!

— Marguerite Reardon, Senior Editor, Light Reading

BobbyMax 12/4/2012 | 11:40:46 PM
re: Smooth Sailing for VLAN Standard Even since the beginning the companied implemented their own version of VLAN primary to achieve market share. Cisco was one of the companies that it invented its own definition of VLAN. THis diminished the acceptance of the Cisco version of VLAN.
ne66 12/4/2012 | 11:40:45 PM
re: Smooth Sailing for VLAN Standard RPR standard is much closer to the Nortel standard. None of the above issues stopped carriers or enterprise (you don't have to look very hard for carrier and enterprise deployments). Proof is in the pudding



Ah yes, stacked vlans the next big metro network technology that will save the world. Hey, Mister carrier keep on waiting to deploy ethernet services because an even better technology is coming stacked, stacked and wrapped vlans. It solves all the problems of the current standard which is not even standardized yet.

mr zippy 12/4/2012 | 11:40:44 PM
re: Smooth Sailing for VLAN Standard I'm no expert on MPLS, but if I understand things right, why not just plonk the customer's VLAN packet into an MPLS over Ethernet frame a al. MPLS layer 2 VPN.

Or possibly push the customer's Vlan ID info into an MPLS label, and stack it on top of the carrier's 802.1q VLAN fram or the carrier's MPLS over Ethernet frame.

Sounds to me like a new "pure" layer 2 solution, when a layer 2.5 solution already exists ...
sgamble 12/4/2012 | 11:40:23 PM
re: Smooth Sailing for VLAN Standard Hi Mr. Zippy,

Ill take a go on that one. Sunday afternoon in my PJs on my first coffee but here we go...

I work for a Metro provider running this non-standard of Q-in-Q. We use Foundry NetIrons running their proprietary version of this called 'Super Aggregated VLANS' or SAVs. You can have multiple layers running either 8500 or 9100 tag-types. Been using this for about a year and the more we look at it, based on our network and requirements, it's a handy technology.

There are some borked side-affects with running L2 only of course but we get through them on most days :) For example, running an RSTP instance for each SAV. There are other ways around this issue with like group STP etc. Other scenarios like MRP are there to address these issues.

Your question is sort of on the backwards lines of "why re-invent the wheel?" Running a Layer2 solution of SAVs makes my operational costs cheap. I can hire any kid off the street who has their CCNA and they will be able to understand the concept of SAVs and ethernet very easily. My operations costs of training and staff are cheap.

Now if I try to hire one of your 'layer 2.5' guys they want: 6 weeks vacation, 6 figure salary and a 6-pack on their desk at all times. Get it?

My point is my operations costs are lower. Heck my administrator who is an excel expert can provision and maintain my Layer2 network. Ask her: Setup and MPLS tunnel from point A to B with this QoS level and TE it through this part of the cloud - she would probably have a stroke. My point is, ethernet with SAVs is such an easy concept and the bonus is that it fits our needs today. My EVP can provision a customer today and diagnose my cloud with our current setup as long he has the port info...

That isnt the sole reason we dont run an MPLS solution today of course. If the network applications being used required it, we would migrate to MPLS. The actual migration would suck of course. But that's another issue for another day.

Now in our case, we have more bandwidth than we know what to do with. We just plugged in this City's MUSH sector at Gig. But we have more bandwidth than we know what to do with. If we need more juice, I just throw in another 10 Gig blade and trunk it. Fill your boots. The diving costs on optics and the use of Xenpak makes life easy here. Im not scraping every last bit on my links like some carriers are trying to do. I dont have this issue.

So why SAVs? Customers get 4096 VLANs each and if they want to use them they dont have to call us to provision them. Once a SAV is untagged on their port for their TLS, we can walk away. The customer is happy because the dependancies on us are not there other than as a transparent cloud. Of course MPLS, some implentations, can do this today as well.

What does MPLS solve? Is it needed? You bet! The concept of MPLS is fantastic and required depending on your services and network. MPLS is fantastic if your having issues with running separate networks today like the ATTs and Bells. I think of MPLS as a migration protocol to save costs in these scenarios. Tier 1 Carriers running ATM, FRAME, TDM and VPNs and trying to handoff customer data to other carriers need MPLS today I think.

I think you are comparing apples to oranges really. I have one guy I work with that does nothing but beat the MPLS-drum. "MPLS is the way of the future! You cant be profitable without MPLS and the services gaurantees!" What a load of BS. This is turning into more of a fashion statement than anything else. We dont need it yet and we are profitable so take a seat.

There is a need for both SAVs and MPLS. It depends on what services you run and the applications being used today and where you are going in the future. Since nobody else in this city has the bandwidth we do, including Bell, we are unique (for now) and our Layer2 solution is working great (minus our vendor bugs of course *grin*).

So I say - Give me both. If/When I need it I will use it. This is why I still read all the drafts coming out of the MPLS area. Just in case... But for now, fix my minor Layer2 issues which is what these folks are trying to do. I need solutions for both Layer2 and your 2.5. Fix 'em both and give me the option!

What do I need from the IEEE:
-A standard on Q-in-Q (SAVs) so I can use multi-vendor.
-A better way to do 802.1ad over diverse paths/switches (like nortel does i believe)
-Some kind of AOM function for diagnostics.

Timmy's run... than golf. Have a good weekend Lads (and Ladies).

dogmeat 12/4/2012 | 11:40:13 PM
re: Smooth Sailing for VLAN Standard
Except it isn't psychotically expensive and I don't have to chew my fingernails down to nubs worrying that the ONE person in my Telecomms operation that built and understands the MPLS infrastructure will be laid off in next downsizing.

The Russians have "big dumb boosters" (like layer 2 bridging technology) and US has "complex and elegant space shuttle" (like MPLS). I want the Russian solution since it's cheaper, more reliable, and more resilent since there's just a lot less complexity inherent in it. QoS/CoS and all the stuff that MPLS promises requires the "victims" (Telecomms and Customers who bought into it) to do some pretty complex engineering. All this from the same Telecomms who have a tough time with any kind of complex provisioning.

Sigh. MPLS marketing, ya' gotta love it. It's is, after all, the key to churning the installed base of equipment out there since VoIP has run out of momentum (no Return on Investment...).

mr zippy 12/4/2012 | 11:40:12 PM
re: Smooth Sailing for VLAN Standard My comment wasn't about MPLS technology verses stacked VLAN technology.

All I was trying to say was that the idear of stacking / inserting VLAN headers, containing a VLAN ID (a label if you will), sounded a lot like the stacking / inserting of MPLS headers containing LSP IDs or labels.

I'm just questioning why they don't re-use MPLS lable techniques for VLAN stacking, or use VLAN headers for MPLS (like they use F/R DLCIs or ATM VPI/VCI fields)

It seems to me like the VLAN stacking technique is about 80% of the MPLS label stacking technique, and maybe all that is required is the filling in of the last 20%, rather than complete re-invention.
Sign In