Subject: [Bridge-mib] dot1dStpPortPriority

From: "Les Bell" <[email-masked]>
Date: Wed, 7 Aug 2002 08:55:03 +0100

Mike, in response to you second issue...

> 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.

Les...

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 7 Aug 2002 10:56:17 -0700

>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

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 7 Aug 2002 15:50:52 -0700

On Wed, Aug 07, 2002 at 10:56:17AM -0700, Michael MacFaden wrote:
>1493 based app would query a specific bit to know exactly what mode

Bert Wjinen pointed out the draft text says '..in steps of 16' 
so the range for bad values would actually include more than 
the listing I presented above. 

Mike