Re: dot1dStpPortPriority

On Wed, Aug 07, 2002 at 08:55:03AM +0100, Les Bell wrote:
>> 2) dot1dStpPortPriority
>>    The wording could be more specific as to what the issue is.
>>    It currently reads:
>>
>>     "The value of the priority field which is contained in
>>      the first (in network byte order) octet of the (2 octet long) Port ID.
>>      The other octet of the Port ID is given by the value of
>>      dot1dStpPort.  On newer bridges, permissible values are 0-240, in
>>      steps of 16."
>>
>> I don't believe this change is backward compatible at all.  You can't
>> simply change the values one can use.  This entirely new semantic requires
>> a new object.  I simply can't see IESG MIB module reviewers accepting
>> this a change. And exactly what is a "newer bridge" anyway?
>
>The IEEE 802.1 WG chose the new implementation of the Port Priority to allow it
>to be backward compatible with the currently deployed implementations, with the
>intention that existing SNMP applications could still use the same object to
>manage it.  The caveat is that, in a new agent implementation, i.e. an agent
>that implements 802.1t/802.1w , some values may be rejected with a "bad value"
>error, if it cannot accept the value given.
>
>Perhaps one way to address this issue is to leave the DESCRIPTION of
>dot1dStpPortPriority unchanged from RFC1493 and to define the more limited set
>of values in a conformance clause for agents that support 802.1t/802.w.

I still feel the correct "SNMP" solution is to create a new
object and deprecate the old. However this approach may be acceptable
if everyone thinks the following impact would be reasonable
on the operator community. 

Test:

for (i = 0; i <= 255; i++)
   set dot1dStpPortPriority.X = i; 

Expected Results:

Device mode   | Mgmt App  | result
802.1D          802.1D       ok   
802.1D          802.1t/w     ok  (new apps can know the semantic changes) 
802.1t/w        802.1D       bad value returned for values  241-255

This appears surprising and I am not sure exactly how inocuous 
the impact would be using an old 802.1D app against 802.1t/w bridges.
 
I would support a semantic change to dot1dStpPortPriority.X if we 
had had the convention of using capabilities bits as found in
rfc2674 / dot1dDeviceCapabilities such that a
1493 based app whould query a specific bit to know exactly what mode
the bridge was in before performing any such set operation.

Regards,
Mike