Comments on: STP is not the problem, but FabricPath will fix it!

By: Francois Tallet

Francois Tallet — Mon, 31 Oct 2011 16:27:32 +0000

Hi Guillermo,
The post only describes basic FabricPath operation which is exactly identical in TRILL.
Our hardware can do TRILL, we plan on providing a “TRILL mode” for FabricPath.
Right now, FabricPath includes some few enhancements that are in fact out of the scope of TRILL (distributed port channel, multiple active default gateways, multiple topologies etc…). We’re trying to get those into TRILL too.
Regards,
Francois

0 likes

By: Guillermo Ravera

Guillermo Ravera — Sat, 29 Oct 2011 18:45:24 +0000

Hi, it’s quite easy to understand your point of view but I suposed that you are always speaking about Fabricpath as the title suggest.

But, what about TRILL (RFC 6325) which was proposed as standard on july 2011, cisco was in the process but will it be supported by nexus platforms? or cisco will add some changes to fabricpath and have one unique protocol?

I think this is important to ease the interoperability between platforms

0 likes

By: Francois Tallet

Francois Tallet — Fri, 21 Oct 2011 15:59:49 +0000

Hi Paul,
I think I’ve elaborated enough on why SPB-M requires new hardware.
Now I’d like you to elaborate on how you reached the conclusion that most chips support 802.1ah. That looks to me like a blanket statement that confuses the reader and hides the truth;-)
Cisco has maintained a 70%-80% market share in data center switching over the period of time you mentioned, and our ASICs do TRILL, not 802.1ah. Even in the remaining 20%-30% remaining, I’d be surprised if there was a significant percentage of switches .1ah capable (especially if, again, you consider the devices that are at the price point for a top of rack/end of row position in the network.)
Regards,
Francois

0 likes

By: A nice article … « Up-Arrow or Ctrl-P

A nice article … « Up-Arrow or Ctrl-P — Fri, 21 Oct 2011 12:43:21 +0000

[...] http://blogs.cisco.com/datacenter/stp-is-not-the-problem-but-fabricpath-will-fix-it/ Like this:LikeBe the first to like this post. [...]

0 likes

By: Paul Unbehagen

Paul Unbehagen — Fri, 21 Oct 2011 03:53:50 +0000

Not necessarily true, as that blanket statement confuses the reader and hides the truth. If you are running SPBm for the 802.1ah encapsulation then you only need to support the mix/demux function of 802.1ah on the edge devices only. Core nodes are simply switching on the outer regular ethernet header.

Most chips shipping for the last several years support the 802.1ah header too so if you’ve bought a switch in the last 4 years then you most likely can run SPBm at the edge and the core nodes that aren’t participating in the the edge function don’t need new chips either if they aren’t a NPU of some kind that can be reprogrammed, as they just need a new control plane update for managing the SPB paths.

0 likes

By: Francois Tallet

Francois Tallet — Wed, 19 Oct 2011 18:25:37 +0000

Just put a loopback cable between two ports of the root bridge;-)

0 likes

By: Francois Tallet

Francois Tallet — Wed, 19 Oct 2011 18:24:33 +0000

Hi Dave,
The funny part is that I’m rather your mother STP’s fanboy;-) Except for the pathological case of the loss of the root bridge (and when customers complain about STP, it’s not because of that) there is no reason why STP would not converge in 50ms. STP is pretty good on paper, but the platforms inefficiencies (mainly in changing the state of the vlans) make this kind of performance impossible to reach. STP is also pretty good at loop prevention on paper, but it’s again not what customers are remembering about it.
SPB-V is only the promise that this time, we did things right in the control plane. As I didn’t see anything wrong in the STP control plane, I don’t see either why SPB-V would add any value.
But in the end, this is post is more about a marketing message than a technical one. You can claim that SPB runs on existing hardware. Then you’re talking about SPB-V and good luck with your new STP. You can claim that SPB has an efficient routed data plane, but then go and replace your hardware. You can’t have it both ways.
Regards,
Francois

0 likes

By: Francois Tallet

Francois Tallet — Wed, 19 Oct 2011 18:23:30 +0000

Hi Nigel,
I think we’re clear on the suspenders. The whole article is about the limitation of the “belt” approach. Go ahead and introduce IS-IS as a control protocol, I will not trust the resulting SPB-V technology more than I trust the current STP.
Thanks and regards,
Francois

0 likes

By: Francois Tallet

Francois Tallet — Wed, 19 Oct 2011 17:46:12 +0000

Hi Peter,
I remember the same kind of argument when we introduced 802.1ah. Only the edge devices need support for the new data plane, the core can remain 802.1ad bridges. This is true, but the reality of a data center is that you commonly get a ratio 2 spine bridges for 50 leaf bridges. So there’s not a lot you can recycle from your previous generation of switches.
Furthermore, unless you have a non-blocking network, the port density at the access is way higher than in the core, and the devices supporting 802.1ah are typically high-end SP oriented switches. The cost of using them at the access is just not realistic. I don’t need to elaborate too much on that, customers will notice anyway.

So in my opinion, the idea of recycling hardware is good from the marketing standpoint, but it’s not going to happen in reality. SPB-M (the only relevant one) requires new hardware.

Thanks and regards,
Francois

0 likes

By: Dave Allan

Dave Allan — Wed, 19 Oct 2011 13:43:10 +0000

Hi Francois

Thanks for replying, a few points to ponder…

1) SPB can use the multicast capability for LSA flooding, so “nimble convergence” is not really severly impaired for multicast, unaffected for unicast as Nigel Bragg observed.

2) You have to contrive topologies (long daisy chains of two connected nodes) for digest exchange to really emerge as a problem. And yes examples were trotted in front of 802.1 and considered during the deliberations…

3) Densely meshed multipath deployments would need a coordinated attack on the fabric before distances to roots started changing for the set of multicast sources we are worried about…so digest exchange would be a very rarely used “safety valve”…if at all.

So this “ain’t your mother’s spanning tree” so to speak. It is link state shortest path mesh…and cogniscence of all paths exists.

cheers
D

0 likes