[nsp] MSTP provisioning queries

[Andrew Fort]

Excuse the rambling..

Hands up who uses the cisco implementation of 802.1s, multiple instance 
spanning tree, with more than about 2 bridges in a region?

Now, hands up those who're comfortable changing your 'spanning-tree mst 
configuration' on a live network?

Do boundary ports give you gas?

If you raised your hand and it's still raised, please speak up!

 From this rather green viewpoint, it appears to boil down to making the 
changes (doing moves/adds/changes on vlan->instance mappings) on all 
switches in the given MSTP region at the same time (i.e., having lots of 
vty sessions open), then (preferably) verifying all pending configs 
match ('show pending') and then sending 'exit'/^z/^c/etc to all devices 
at close enough to the same time so that you hopefully don't change your 
L2 forwarding paths away from the desired for too long.

Alternatively you could load all the new configs via 'copy ftp run' or 
similar (triggered via the RW MIB or in our case via a vty interactive 
script), and hope they go in without one mussing up and leaving your 
network in a somewhat inconsistent state.

To make matters more complex, if you've tied any VLANs up for say, OSPF 
sessions between just two multilayer switches, you have to be extra 
careful since a topology change caused by the boundary ports going up 
will tear down at least one OSPF session (hopefully not the redundant 
path, too).

The configuration (on switch IOS) and the .1s spec refer to a Revision 
number combined with the MSTP vlan to instance mapping hashtable, but 
this doesn't appear to be implemented (or the .1s spec cover the concept 
in much detail).  What  would be nice is if it behaved like the OSPF MD5 
key, i.e., once configured, bridges agree on the lowest common 
denominator of revision number and only make a change when they all 
agree there's a new revision configured.  This doesn't appear to be the 
case.  Is this the intent of this revision value?

So, is anyone here using MSTP on a largish scale and has a better answer 
to the mechanics of building such a network than "pre-provision large 
numbers of VLANs" and/or "Perl Net::Telnet/Expect to multiple bridges at 
once"?

(Oh, and please leave the "large spanning tree domains are evil" 
arguments at the door, since I dont argue with you there :).

-afort