Re: problems with dot1dStpPortDesignatedPort

"Les Bell" <[email protected]>
Newsgroups gmane.ietf.bridge
Message-ID <[email protected]>


Mike MacFaden wrote:

> In draft-ietf-bridge-bridgemib-smiv2-02.txt,
> the managed object:
>
>     dot1dStpPortDesignatedPort OBJECT-TYPE
>      SYNTAX      OCTET STRING (SIZE (2))
>      MAX-ACCESS  read-only
>      STATUS      current
>      DESCRIPTION
>       "The Port Identifier of
>        the port on the Designated
>        Bridge for this port's segment."
>      REFERENCE "IEEE 802.1D-1990: Section 4.5.5.7"
>     ::= { dot1dStpPortEntry 9 }
>
> has not been updated with text to
> say what one should do if the bridge
> has greater than 255 ports.
>
> I understand 802.1T has modified how these 16 bits are
> being divided up, however I don't think this
> object can be reused and must only report
> on the range it is capable of reporting on.
>
> A new object would have to be added to represent
> the new interpretation of the 16 bits in a port identifer.

The dot1dStpPortDesignatedPort object is defined as an opaque
octet string and it does not understand the priority and port
number fields embedded within it.  Therefore, it does not matter
(to this MIB object) that the boundary between them has changed.

> Testing with existing fielded products
> has shown that the priority bits often just
> get shifted out which strikes me as rather broken.

The products with this behaviour are broken, not the MIB.

> So is is possible that some prose be added to
> the front matter about what a conforming application
> should expect from a device implementing the BRIDGE-MIB
> when it device has > 255 ports?

I did not think this was necessary.
If you have some proposed text, we can discuss it.

> Thanks,
> Mike MacFaden

Les...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.