[Bridge-mib] Re: dot1dStpPortPriority

Michael MacFaden <mrm@riverstonenet.com> Wed, 07 August 2002 17:55 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01283 for <bridge-archive@odin.ietf.org>; Wed, 7 Aug 2002 13:55:38 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26604 for bridge-archive@odin.ietf.org; Wed, 7 Aug 2002 13:56:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26592; Wed, 7 Aug 2002 13:56:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26561 for <bridge-mib@optimus.ietf.org>; Wed, 7 Aug 2002 13:56:48 -0400 (EDT)
Received: from agile.yagosys.com (host60.riverstonenet.com [64.95.122.60] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01280 for <bridge-mib@ietf.org>; Wed, 7 Aug 2002 13:55:35 -0400 (EDT)
Received: (qmail 2385 invoked by uid 10041); 7 Aug 2002 17:56:17 -0000
Date: Wed, 7 Aug 2002 10:56:17 -0700
From: Michael MacFaden <mrm@riverstonenet.com>
To: Les Bell <Les_Bell@eur.3com.com>
Cc: bridge-mib@ietf.org
Message-ID: <20020807175617.GB1897@riverstonenet.com>
References: <80256C0E.002C8935.00@notesmta.eur.3com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <80256C0E.002C8935.00@notesmta.eur.3com.com>
User-Agent: Mutt/1.4i
X-Operating-System: GNU/Linux 2.4.18
Subject: [Bridge-mib] Re: dot1dStpPortPriority
Sender: bridge-mib-admin@ietf.org
Errors-To: bridge-mib-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <bridge-mib.ietf.org>
X-BeenThere: bridge-mib@ietf.org

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


_______________________________________________
Bridge-mib mailing list
Bridge-mib@ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib