Rant: Why SPB Doesn’t Get Any Attention

Someone made a comment that Packet Pushers hasn’t discussed SPB.

Trusting the IEEE ?

I don’t trust the IEEE to transparently develop and deliver a standard. It’s closed forums, secret meetings, and lack of transparency are a major concern.

Add that to very poor results for delivering standards in timely fashion e.g. IEEE 802.11 and you have a secret cabal run by organisations with significant vested interests who have to work together and produce something that everyone want ? Evidence says this isn’t working well and hasn’t worked well for the last twenty years. Ethernet is success in spite of the IEEE, not because of it.

Capability ?

In my view, SPB has little to offer data centre architecture. While it may eventually work, after ten years of development so far & more to go, offer a solution for carriers in the MAN/WAN space, it sacrifices function in the name of legacy capability. Moreover, TRILL and other Fabric solutions will have long since bypassed SPB by the time the IEEE process spits out it’s final papers.

Corporate Funding

SPB certainly suits the business models of Avaya and Huawei / HP because it doesn’t require investment in new silicon. You can just hack the existing silicon and make do. It’s a cheap, and ultimately short term business decision to support second rate technology in my view.

Supporters are Bit Players

Avaya isn’t a global player, nor is Huawei. While locally significant in certain geographies, I don’t see that either company will be able to create a leadership position in the ethernet marketplace. The decision by Avaya / Huawei to use SPB is based on internal cost because cash flows are tight not because it’s a better choice.

If HP makes a significant launch (hasn’t happened yet), then it probably won’t change much. My guess is that It’ll be too late.

Poor Outreach and Information Support

As evidence for “bit players”, I have never received any information regarding Avaya or Huawei, nor am I able to find any meaningful technical information on the product, technology or strategy. Aside from a few briefings from Ashwood-Smith of Huawei from public events, there is no information available.

Despite attempting to contact people involved with SPB a few months ago, no one has bothered to make the time to set a time to speak and record on the topic. Given the the Packet Pushers audience and reach into the Enterprise is much larger than UKNOF, or NANOG conferences, this suggests that no one really cares.

No Demand

I haven’t had a single listener or person ever ask me about SPB. While I have done _some_ research, it’s obviously not a topic of interest to anyone in my audience.

The Etherealmind View

So, if anyone cares about SPB, here is your chance. Speak up in the comments and I’ll take your views on board. If anyone cares, then we can put them on Packet Pushers and see what they have to say.

For or against. Happy to hear from people who don’t care, as well as those who do.

  • http://geoffarnold.com Geoff Arnold

    I know this is just a rant, and therefore fact-checking doesn’t apply, but anyone who dismisses Huawei as a bit player of only local significance is clearly out of touch. They’re the world’s second largest telecommunications supplier, and the fastest growing, and their innovation in R&D is generally rated ahead of Cisco. (Check out FastCompany’s rankings.) My guess* as to why they don’t show up on your radar is because the most important application of Ethernet for Huawei is in backhaul for wireless networks. But that’s this year. Next year, Cisco and Juniper should be worried.

    * Disclaimer: I used to work for Huawei, but was never involved in their Ethernet business.

    Suggested reading: http://preview.tinyurl.com/ydfmtm9

    • http://geoffarnold.com Geoff Arnold

      Sorry, I meant “data center fabrics” instead of Ethernet. Autosuggestion after reading your – very apposite – comments about the IEEE and Ethernet.

    • http://etherealmind.com Greg Ferro

      In the last three years and several companies, I haven’t seen Huawei once. Moreover, it never comes up in conversation. Flogging a a warehouse full of kit on the cheap to a couple of large telcos who think they can reduce costs, does not make a market leader. And those same telcos who are paying substantially increased operational costs to keep it running.

      Re R&D, 1) Huawei needs to invest to catch up, and would expect no less. 2) It’s not necessarily a metric of success – it could also be dodgy accounting practices or badly organised labs that needs lot of cash as much as a lot of results. 3) but good on them for getting on with it.

      Re Wireless backhaul. As I clearly said, SPB is a solution for the MAN/WAN space who can patiently wait for the IEEE to get it’s act together. But more importantly the Telcos can avoid spending money and keep their underfunded, undersized and poorly featured networks in place because the Ethernet frame is unchanged. Which does not add value to their customers.

      As such, I regard Huawei as a rising player but I’m keeping an eye on their progress. Compare this with Avaya who I regard as a sunset player steadily moving into irrelevance by failing to invest. (note: the Avaya ERS8600/8800 product is popular with carriers because it was a cheap ethernet edge a few years back. And most carriers aren’t too pleased with this decision five or ten years later).

      Thanks for your feedback. Nice to know someone cares about Huawei.

      • Jonathan Hurtt

        As regards to Avaya investing… Avaya is investing into the Data Portfolio… We have launched at new WLAN portfolio as well as a new chassis switch focused to the Data Centre and Large Campus Cores (the VSP 9000) for 10G and future 40/100G (which competes with the Nexus 7000) along with refreshing many of our products on a regular schedule including enhancing the ERS 8600 to make the ERS 8800.. Also look for new products at Interop and later this year that show Avaya is investing.

  • http://etherealmind.com/members/networkjanitor/ Kurt Bales

    Ok, Im going to stick my hand up here! Im actually quite interested in SPB, if *only* because it builds on existing technologies – namely PBB. I think there will be a strong case for this in Service Provider networks (possibly less so in Enterprise DCs though).

    One thing that surprised me though was Brocade jumping solely into the (pseudo) TRILL camp when they already had a reasonably strong PBB solution in their service provider product range. A little bit of control plane magic and they would be there!

  • Jonathan Hurtt

    Thanks for the rant… just to comment on your rant…

    1. Can you go into detail of the capabilities that SPBm lacks that TRILL encompasses… still havenít seen how TRILL addresses the needs of the Data Centre better than SPBm… I have yet to find any things TRILL can do that SPBm cannot.

    2. Also the reason Avaya chose SPBm is because it is based off PSLB/PBB which is a technology that Nortel developed over 5 years ago… so it only made sense for them to continue. So I guess you are correct about “cash flow”… what company in their right mind would abandon a technology they spent 5 years developing to jump on board with an unproven, not ratified technology, now that would be a poor business decision

    3. And not sure why you would degrade a technology if it builds on existing technology like SPB does on Ethernet and promote an unproven technology that is new to the industry and requires a forklift to implement. Can you run TRILL on a 6500?

    Sorry you arenít getting love from “802.1aq/SPB Gurus”, but seems like Peter provided a good overview in your post in November… The one thing we have not heard from you is why TRILL is a better solution… maybe a podcast or blog on thatÖ Also Ivan’s comparison (including the comments) of these two technologies is very good article…

    Your Nov. Post: http://etherealmind.com/trill-introduction-review-overview-why-what-how/
    Ivanís Post: http://blog.ioshints.info/2010/08/trill-and-8021aq-are-like-apples-and.html

  • Dmitri Kalintsev

    Greg, there’s one more player in the SPB camp you didn’t mention – Alcatel-Lucent.

  • Bart Bylemans

    I’d also like to have a technical comparison between TRILL and SPB on the show sometimes! In that regard it would be great if some techie from Avaya/Huawei/… could join in.

    As a sidenote: we’re currently running a 99% Avaya/Nortel network (wired) and it has been working great for us, although we’re probably not big enough (approximately 130 networknodes) to have any immediate benefits from any of the new technology like SPB or TRILL maybe in the future some of it might find it’s way into the campus.

  • Salander

    Remember that good enough and cheap always win. Don t you think it applies here also?

  • Francois

    Nobody here can dispute that 801.1aq (SPBm) is marketed squarely at the MAN/WAN deployments. It currently does not address the virtualized data center needs, IMHO.
    There is a principle that seems to be forgotten. KISS. SPBm is very elegant in that it rides directly over IS-IS and re-uses existing ethernet processing engines. It permits decentralized processing on the edge with a simple core. No forklift upgrade. And many other great aspects. Reducing risk for large enterprise customers and carriers is a priority.
    Anyone who thinks implementing cutting edge protocols with centralized backplanes (Ex. Qfabric) is a road to success forgets that the poor engineer who will implement and support this will get catastrophic failures when the “central” processor fails, yeah it happens.

    It is too bad Juniper does not wish to support both 801.aq and their new fangled Qfabric from the datacenter up to the MAN.

    As for Cisco’s Fabricpath and Brocades fabric, they are TRILL implementations. They address datacenter needs just as well as SPBm, in that they need proprietary extensions. TRILL and SPBm, are at their root the same thing. So, I don’t see why packetpushers and friends shouldn’t talk about it both SPBm and TRILL. Now does the comment about SPBm being only about the MAN/WAN still stand!
    The easy win is at the MAN/WAN, but there is no reason SPBm cannot go down in the datacenter.
    Disclosure: I am a LAN/MAN engineer waiting for SPBm to mature and IS-IS fast-reroute to be implemented. Nothing else at this point meets the KISS approach for an ethernet MAN.

  • Peter Ashwood-Smith

    I’m happy to engage in technical discussions about the pros and cons of different technologies. However incorrect blanket statements are not something I can easily address and simply point interested parties to Google to look at market sizes, investment amounts, chip design etc. capabilities.

    I do agree that the IEEE is too slow and I also wish it was faster. Having said that the IETF is not that rapid either as the never ending MPLS-TP OA&M saga demonstrates. This actually is something to be concerned about. Any protocol which introduces new OA&M requirements could be in for a long ride. As a result, building on something that exists, i.e. 802.1ag and Y.1731 would seem like reasonable decisions and infact show up in many RFQs. Now you could certainly argue that those systems suck and sure they have their detractors .. but they have the decided advantage of existing, working properly and being built into ASICs where necessary already. Its a case of somebody elses slides are better than an existing solutions .. hard to argue with that really.

    The datapath is another concern. We know very well that 4K vlans is inadequate, and thats been addressed in .1ah. We know that small addresses are a problem and that has been addressed .. so it really seems silly to go back on both of those advancements and its likely that new hardware will be required (on every hop) to do this if we don’t use Ethernet.

    In my view what we need is a bit of a hybrid between the behavior of these two standards. I.e. the 48 bit addresses, with a large service identifier and the ability to do either symmetric routing or the IP style hash and forward and to be able to select on a service by service basis. Obviously one OA&M system.

    • http://etherealmind.com Greg Ferro


      Get in contact with me – myetherealmind a-t gmail dot com and I would be happy to setup a podcast to talk about this in detail and publish into http://packetpushers.net for everyone to hear. Probably a much better forum to cover all the topics.


  • Peter Ashwood-Smith

    “based on internal cost because cash flows are tight”

    Oh, I know I said I’d discuss technical stuff only but you may want to edit the above sentence as it is easily demonstrated to be wrong and detracts rather significantly from the post.

    • http://etherealmind.com Greg Ferro


      I disagree quite definitively. All discussions around SPB have emphasised the value of retaining existing assets so as to save costs for future upgrades, hence SPB’s key value is being perceived as cheap.

      Discussions around the relative investment in R&D are mostly hyperbole and deeper investigation always shows significant accounting tricks to make the numbers significantly larger than it is in practice. So while Huawei (your employer, please disclose in future) may well be investing heavily in new technology I don’t regard that as a leading indicator of technology leadership since they don’t have products in many spaces and they need to develop them anyway

      Happy to see indications to the contrary but no reason to think it’s anything but a start-up developing new products to enter a market place


      • Peter Ashwood-Smith

        Greg, my point was that cash flows are most certainly not tight at my employer (Huawei). I was taking exception to that incorrect blanket statement. It may well be true of the other companies that you mentioned. You also use the term start-up in a later post which I think you may also want to revisit in the context of Huawei 😉

        Its certainly true that I emphasize that using Ethernet is a lower cost solution than something brand new. I don’t say cheap because that implies low quality, which is definitely not an attribute of Ethernet. Telling customers you have a brand new more expensive technology requires considerable justification to sell and I imagine that network planners reading these debates probably want to see this kind of comparison as opposed to what is new/cool/old etc.

  • Peter Ashwood-Smith

    “1. Can you go into detail of the cap≠ab≠il≠it≠ies that SPBm lacks that TRILL encom≠passesÖ still havenít seen how TRILL addresses the needs of the Data Centre bet≠ter than SPBmÖ I have yet to find any things TRILL can do that SPBm cannot. ”

    Actually in the interests of technical neutrality let me take a quick crack at this. TRILL’s hop by hop hash based forwarding will allow use of more shortest paths when the network is deep/dense at the expense of control. This is because the number of shortest paths in a network grows exponentially with the diameter of the network. SPBM assigns traffic at the head end (like MPLS) and therefore requires more state to be created when diameters are large but it gives you more control. I refer to this as shotgun forwarding v.s. rifle forwarding and often make the comment that we really need both depending on the traffic type. Its somewhat analogous to why we have MPLS and IP co-existing today.

    Most DC fabrics are aiming to be 2 hops, i.e. TOR to spine and down. This low number of hops means there is no exponential growth in shortest paths and you really only need one path per spine connection so a head end assignment meets the scale requirements without problem. The spin nodes are then just normal Ethernet doing existing DA/VLAN forwarding behavior without modifying the frame, its FCS etc. as it passes through. This means the plethora of existing 10 and new 40/100Gig cards can participate at their current power cost points on existing ASIC’s.

  • David Allan

    If you want an idea of what goes on in the “secret meetings” all the inputs are available to the public, edit for year if you want to do forensics….


    BTW, I’m rather pro SPB, IMO it has a lot of interesting technology in it, it is just not necessarily aligned with conventional wisdom!

    • http://etherealmind.com Greg Ferro

      Hi David

      I’ve regularly looked in on the details are contained there and come to the conclusion that various corporate companies are taking positions that suit their organisations and actively, blocking, preventing, denying, failing to participate effectively in the process.

      However because the meetings are held in secret and hidden behind cabals like agreements not to talk about what happened I can get no feedback or transparency about what actually happens.

      Given that the IEEE continually fails to deliver on time, or indeed at all, it seems that there is little reason to trust the process and feel confident that will deliver something that customers want or need. I am confident however that manufacturers are abusing the process to seek their own ends but without transparency I can’t see that


      • David Allan

        Greg, there is an element of that in all SDOs, and I have long experience in several. Commerical agendas are always present.

        I cannot comment on IEEE timliness, but note that the same issues exist in IETF, ITU and BBF in various degrees of blatancy.

        What I do like about IEEE is the PAR process where a proposed project needs to meet a set of well elucidated criteria in order to be approved. This includes solving a unique problem, broad market potential, technical feasabilty, backwards compatibility etc.

        So what happens in other SDOs and technical marketing forums after the plurality of standards are done usually is done at IEEE before….as it got to one solution

      • Don Fedyk

        Hi Greg

        The meetings are not secret and the organization is not closed. See


        Speaking for 802.1 attendance where SPB id developed. There is a mailing list which is free to join and a private area which can be accessed by simply asking for the password (it is freely given).

        Having attended IETF and IEEE and even several ITU-T Study Group 15 Q9 meetings. The attendees mostly come from the same groups of companies. Mostly vendors. The detail of what is discussed and the ways of tracking it are different. In IEEE for each document such as SPB there is a lot work and balloting that is all public record. You would be hard pressed to find any more detail in the IETF or ITU.

        As far as SPB I am the editor so naturally I think it is a good technology. It is a large project and rather more ambitious than I originally thought. The fact that the project will seamlessly bridge between Spanning Tree deployments and SPB in various combinations of VLAN, Provider S-VLANs and Provider Backbone VLANs has added material that goes a long way and I’ve had a lot of help over the past few years. When finished SPB will have a complete control plane, data plane, OAM and a MIB and it will finally be integrated in a single document 802.1Q. (in fact SPB is primarily a control plane project with only minor tweaks to forwarding etc.) From a IEEE project point it is the right way to build the standard. From a solution standpoint where many are interested in a pure IS-IS SPBM deployment it is larger and slower to specify. In fact there will be a divide no doubt between stand alone IS-IS SPB deployments and spanning tree but the foundation and data plane is laid out the right way. It is the next-gen Ethernet control plane.

        There are many places you could deploy SPB, just as there are many places you could use LANs, VLANs and L2 VPNs. SPBM offers a highly integrated control plane and data plane for Ethernet. In my view, it extends the current IP-Ethernet technologies allow both to continue. As far as data centers go SPB has only recently started to be proposed where large seamless highly connected VLANs could be leveraged.


  • Pingback: Packet Pushers Podcast Show 44 - Introduction to Shortest Path Bridigng 802.1aq()

  • Uu2

    Avaya has released these documents:

    As you know the founder of this standard IEEE 802.1aq Shortest Path Bridging (SPB) are
    Nortel engineers and Now it’s Avaya and they have demonstrate it in their future plan.

  • Fernando Rivas Plata

    I disagree with your position, i think SPB is a good option enough than 
    TRILL or QFabric. SPB come from IEEE, TRILL come from IETF and QFabric come from Junipper but all of this network technology does the same with 
    differents approachs. 

    May be you can show some technical reason to sustain this commentary, if so please share with us that information.

    • http://etherealmind.com Etherealmind

      Because the IEEE is too slow to develop new technology. SPB is too complex as a protocol. But most importantly, only Avaya and Huawei are offering it. This makes it a niche technology.

      Oh, and Radia Perlman is way more popular than the IEEE – the market will follow her lead.

  • Iawef

    A stupid person

  • Cgray

    I bet you wish you had not opened your mouth now, don’t you.

    • http://etherealmind.com Etherealmind

      Nope. One year later and SPB still isn’t making much of an impact. And with OpenFlow/SDN arriving, it would appear even less relevant or likely to make an impact. 

      It’s not a bad protocol. Lots of careful research and consideration are contained in it’s design. But my opinion remains it’s too late, too little to make an impact. 

      It’s possible that something might change, but it certainly hasn’t crossed the adoption gap. 

  • Guillermo Ibañez

    I agree with you on that SPB is a solution for carrier networks, not for data center or campus as nobody seems interested on SPBV.
    I think the problems of TRILL are:
    – Being standardized at IETF instead of IEEE 802.1 , compatibility issues with 802.1Q are now visible.
    – lack of criticism to the TRILL approach in the first stages of development due to the important leadership of R.Perlman in the proposal.
    – Making mandatory the requirement of complete miscibility interoperability of standard bridges and TRILL Rbridges leads to huge complexity in frame encapsulation and forwarding (RBridge next-hop destination address must be replaced at every hop!)

    I am also a fan of the book “Interconnections”, plenty of network experience and clear explanations, but for me TRILL is an example of how NOT to make a standard in layer two technologies.
    -Both SPB and TRILL rely on link state routing, newer ideas exist for layer two routing, like ARP-path (aka All-path). The advantage of simultaneous path discovery is that you get native load balancing and low latency. There is life beyond link state routing in layer two, specially for data centers, where the known topology gives advantage to specific protocols like Portland and derivatives (see also ToriiHLMAC protocol).
    Guillermo Ibañez

  • Pietje_Precies

    By the way….where is TRILL now in 2012… I see SPB being deployed in enterprise today, but have not seen a single TRILL implementation. It is a redo of STP, it is flawed, Oh, and it is not yet standardised,IEEE apparently beat IETF!?!?! Other virtualisation endeavours out there are all proprietary to cover up for TRILL flaws.

    BTW crazy stance of “not trusting IEEE to develop a standard”. Our whole world is built on the foundations of IEEE…..

    SPB is great for enterprises. It delivers and e2e fabric capability that allows you to create services e2e in minutes across a campus. please also check out SPB and VXLAN integration. I would say this is a TYPICAL DC application

    Sorry, but your Cisco hat is all over your eyes and ears.

    • http://etherealmind.com Etherealmind

      In fact, SPB is nowhere. The only vendor support is from Huawei and Avaya whi have limited market penetration. TRILL is widely deployed by Brocade and Cisco customers although Cisco uses FabricPath (TRILL with proprietary extensions) and Brocade uses VCS (TRILL with interim enhancement and software)

      THe IEEE continues to fail to deliver. The 802.1Qbh/bg fiasco damaged the industry badly and the lack of progress on 400Gb/s is embarassing. Further, the pace of IEEE wireless standards and their appalling lack of decision making and poor focus has left wireless in limbo with 802.1ac.

      With regards to my Cisco hat, I regularly write about all vendors which you would know if you follow my blog or podcast. But since you only have one eye for what you want to believe, I guess is doesn’t matter.

      SPB remains, in my opinion, a poor technology for enterprises.

      BTW, it’s good manners to disclose your vendor affiliation.

  • http://etherealmind.com Etherealmind

    At the time this article was written, AlcaLu wasn’t a company that I knew anything about. Today I’m engaged with ALU and becoming aware of their products and features. Mostly I do not come across the products in day to day working so my perspective is different to yours.

  • Romel Lolo

    will Avaya SPB enhancement (specifically L2 VSN) work over any WAN infra (Ethernet WAN, ATM, frame relay, MPLS)?

    • http://etherealmind.com Etherealmind

      I think so, provided it supports jumbo Ethernet frame sizes since the PB encapsulation increases the size of the Ethernet frame.

  • http://etherealmind.com Etherealmind

    Yep. SPB does have a number of good features that are especially suited for carriers. Notwithstanding, it has been consistently proven that L2 doesn’t scale and ultimately leads to complexity.

    I would certainly use SPB for specific use case but overall I can’t see how the market will widely adopt it. SDN/NFV doesn’t help either.

  • Sam Stickland

    I’m looking at a network right now at an industrial site. For the first time I see a good use for SPB in this type of scenario. As well as a couple of main buildings it’s a network of various small switches connected into multiple buildings around the site. Oten a switch may only have a eight ports – some of these buildings aren’t huge. Topology follows the physical constraints. Many buildings are connected only via single fibre runs. Often a number of buildings are connected back to a single building, itself with only a single connected back to the core.

    This network is all L2. Different VLANs for different purposes span out to almost every switch and the L3 switches providing the routed component are in the central building. Various ACLs segment different VLANs for security reasons.

    The L2 topology, as I’m sure you can imagine, is a nightmare. It’s never clear which ports spanning-tree will block. If this was a routed topology it wouldn’t matter that, for example, two bits of the network consist of two conjoined rings, and that this bit over here follows a more typical hierarchical design. ISIS would be just fine with that. But with STP this is a problem.

    It’s not practical to make the majority of this strange topology routed. Not only would there be a large cost increase there’s a significant increase in maintenance. There will be many more routers to maintain, often in small buildings with hardly any users. VLAN ACLs in a central local will no longer work – VRFs will be necessary!

    It’s also not practical to redesign the logical topology. There are physical constraints and cost considerations with all the additional cabling runs that would be needed.

    If SPB was available on low-end (and some rugged) switches things would be much easier. We could add in additional redundancy along the most practical lines and not worry that STP will struggle. We could keep the central L3 gateway. We would not need to worry so much, if as is likely, more little switches are added in strange new buildings and outhouses.

    It seems to me that this is where SPB should shine. It uses a backwards compatible encapsulation and it was designed to be able to run on cheap ASICs.

    This scenario is repeated in many organisations. Our answer so far has always been to shoe-horn in a hierarchical design to keep the L2 topology simple and add routers where the topology is not. This huges increases cost. I would hope that there is a better way, and from my perspective, a more widely implemented ubiquitous SPB would solve this. I remember an episode of PacketPushers where the IEEE SPB representatives were talking about just this use case – SPB on everything from the lowest to highest switches.

    This isn’t a discussion about giant high capacity datacentres networks. This is relatively low-end, small, but important networks but the need is still there. From my current point of view treating SPB as a high-end datacentre technology is not helpful!

  • Mark

    Avaya SPB solution is looking like one of the best solutions for stealth Networks and Multicast. If anyone knows something to the contrary please let me know.