It's important to note that PVST/PVST+ is Cisco proprietary.
They do support one instance of STP per VLAN, and it is enabled by default. You can enable/disable STP on the following levels (taken from the NetIron config docs):
- Globally - Affects all VLANs
- Individual VLAN - Affects all ports within the specified VLAN. When you enable or disable STP within a VLAN, the setting overrides the global setting. Thus, you can enable STP for the ports within a VLAN even when STP is globally disabled, or disable the ports within a port-based VLAN when STP is globally enabled.
- Individual Port - Affects only the individual port. However, if you change the STP state of the primary port in a LAG group, the change affects all ports in the LAG group.
Depending on your code rev, you can enter config mode for the VLAN and either do:
[no] spanning-tree
or
[no] rstp
[no] spanning-tree 802-1w (used on older versions of code)
I know that newer NetIron gear has PVST/PVST+ compatibility modes which you can turn on at the interface level with:
pvst-mode
But this also implies that you're going to be running MST, which you said you're not going to do.
I recently went through a similar migration that eradicated proprietary protocols (i.e., PVST+, HSRP, etc.); our transition was focused on posturing us for a 'vendor neutral' network. Since you're running Cisco devices, you're likely running PVST+.
Cisco covers this in more detail, but the crux of it is fairly simple: establish a hierarchy and, contrary to what common sense would tell you, start from the core and move outward.
Set your priorities in a manner that cascades down. Base this hierarchy on what is closest to a central node. All nodes participating in this STP setup should be on a common structure, so for simplicities sake, manually set one root bridge with the spanning-tree vlan xx,xx root primary.
Once you're ready for the migration to begin, start with the core. The reason for this is because MST is backwards compatible with PVST, not the other way around. A PVST core won't be able to communicate with BPDUs from MST nodes; those trunk links will drop. If everything is going right, you'll see a small drop while the new STP protocol comes online and figures out the current lay of the land.
Then just trickle these protocol changes down all the way to your furthest nodes.
End-users might not even notice the small blip while MST elects a root bridge.
Best Answer
The short answer is that MSTP actually uses a special instance in addition to the user defined ones to handle all MSTP control traffic, called the Internal Spanning Tree instance (IST0).
From: http://blog.ine.com/2010/02/22/understanding-mstp/
You should definitely check out the rest of that white paper, it's a great resource.