Subject: Re: [Bridge-mib] problems with dot1dStpPortDesignatedPort

From: "Les Bell" <[email-masked]>
Date: Wed, 3 Apr 2002 09:35:11 +0100

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

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

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 3 Apr 2002 16:06:09 -0800

>(to this MIB object) that the boundary between them has changed.

How did you reach that conclusion?
What I see is an object that is clearly a 'Port Identifier' 
which is well defined in the base 802.1D 1990 spec. 

If dot1dStpPortDesignatedPort is opaque, 
how can it be used at all in an interoperable
fashion?

>I did not think this was necessary.

I agree if as you say, the octet string is opaque.

>If you have some proposed text, we can discuss it.

If the octet string is not opaque, then something
like this would lead to well defined behavior that
enahances interoperability.

99.99 Special cases: dot1dStpPortDesignatedPort 

If a device has greater than 255 ports, the 
Port Identifier encoding can not be done
with the bit allocations as defined prior 
to IEEE 802.1T. dot1dStpPortDesignatedPort object 
instances greater than 255 are not visible 
to management queries.

Mike MacFaden