Re: dot1dStpPortPathCost32

On Tue, Nov 02, 2004 at 09:50:14AM +0000, Les Bell wrote:
 
> Use of the 32-bit path cost was defined in both 802.1w (RSTP) and 802.1t.
> 802.1t was a collection of enhacements to Bridges, including those that support
> legacy STP.  So the 32-bit path costs do not just apply to RSTP.
> 
> I think you are right that dot1dStpPortPathCost32 should be conditionally
> mandatory, but for any Spanning Tree implementation that supports 32-bit path
> costs, not just for RSTP.

OK, that language makes sense.
 
> Implementations that support 32-bit path costs should not use the 16-bit path
> cost object, dot1dStpPortPathCost, but I am not sure what is the best way to
> deal with this.  Are we allowed to allocate a special value to indicate it is
> not in use?  I think it would be safer to return an SNMP error indicating the
> old object is not supported.

I guess we need to discuss this next week. I know that this issue was
discussed before, but we have to make a real engineering decision here.
There are several issues involved as far as I can tell:

a) Formally, we are not expected (or even allowed?) to add objects while
   moving from Draft to Standard. So this needs careful consideration
   from the IETF procedures perspective and support by the AD.

b) According to the SMIv2 rules, we can't change the range of the
   original 16 bit object and have to introduce the new object as
   done in the current ID. Your question what implementations should
   do that support 32-bit path costs with the old object requires
   consideration. Not sure there is a path cost which can be used
   as a special value (and doing so would most likely change existing
   semantics) so the requirement might indeed be not to support that
   object (at least if the value is outside the range).

c) It would be nice to know what existing implementations do. I guess
   that implementation wise simply removing the range restriction is
   probably the easiest thing to do on the agent. It is hard to judge
   whether this seriously impacts real-world managers interoperability.
   If there are implementations which did follow this approach, then 
   this might be important information to consider.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany