[c-nsp] Maximum spannig tree instances

[Geoffrey Pendery]

"The point of MST is to realize that there's never going to be more
than two possible forwarding topologies, and computing more is a total
waste."

But that statement is specific to your network design and your
topology.  Surely you're not claiming that it's never possible to
build a network with more than two topologies?  Surely you mean to say
that "the place where MST is useful is in scenarios where there's
never going to be more than two possible forwarding topologies, and
computing more is a total waste."

I believe the consensus here is that yes, MST works just great, for a
certain specific scenario.  I called it a car vs a boat earlier, but
we can go to a toolbox metaphor if that works better.  MST is a lovely
hammer, but when I've got screws to screw in, I don't want a hammer.
Nor do I want the screwdriver when it comes time to drive in nails.  I
want both tools in my toolbox, and I'll use the appropriate one at the
appropriate time.

I'm not trying to say "MST is never useful and always terrible", but rather:
"MST doesn't fit all scenarios.  For many scenarios, RPVST is much
better, and it's a shame that we've only got an open standard MST,
rather than two open standards to cover both scenarios."

When you're given the mandate/requirement/strong-preference of using
open standard protocols rather than Cisco proprietary ones (not an
unreasonable goal) it leads to great frustration, because you end up
having to hammer in screws.  This frustration apparently leads to some
ranting on email lists.


-Geoff


On Fri, Jul 17, 2009 at 8:05 AM, Ross Vandegrift<ross at kallisti.us> wrote:
> On Thu, Jul 16, 2009 at 08:51:47AM +0200, Gert Doering wrote:
>> On Wed, Jul 15, 2009 at 11:27:12PM -0400, Ross Vandegrift wrote:
>> > On Tue, Jul 14, 2009 at 05:00:36PM +0200, Gert Doering wrote:
>> > > <rant>
>> > > MST is what comes out if vendor committees get together, and agree to
>> > > implement the least common determinator in the most complicated way.
>> > > </rant>
>> >
>> > I completely disagree - it's what comes out of solving problems
>> > related to the LAN - the LOCAL area network.  In virtualized LANs,
>> > there's typically only a few possible physical topologies that can
>> > exist.  MST seeks to exploit this to lower the amount of processing
>> > power that is required.
>>
>> Since MST was standardized long before the "virtualized LAN" environments
>> were common, this is a nice after-the-fact explanation - but the fact
>> that *years after protocol design*, networks have emerged that make MST
>> actually work doesn't make it a better protocol.
>
> I think you've misunderstood me - by "virtualized LAN" I meant VLAN,
> not VPLS.  It didn't take years for these designs to come up - the
> datacenter we run is a bog-standard, utterly uninteresting case of a few
> thousand servers, in a few thousands VLANs, with a pair of HSRP
> routers.
>
> The point of MST is to realize that there's never going to be more
> than two possible forwarding topologies, and computing more is a total
> waste.  It's a perfectly fine protocol at acheiving that goal.  I
> realize you might not care about that goal, and that's okay.
>
> I'll go a step further - I doubt that there's a substantially more
> optimal way to compute only the valid topologies.
>
> --
> Ross Vandegrift
> ross at kallisti.us
>
> "If the fight gets hot, the songs get hotter.  If the going gets tough,
> the songs get tougher."
>        --Woody Guthrie
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>