Subject: [Bridge-mib] Draft-ietf-bridge-bridgemib-smiv2 Issues Resolution

From: "David B Harrington" <[email-masked]>
Date: Wed, 5 Jan 2005 13:22:58 -0500

Hi,

I have reviewed the -08- revision to see which WG Last Call issues
were resolved. Here is a summary of the issues and their resolution.
These issues have been discussed on the mailing list, and I believe
the changes reflect consensus.
If nobody raises a serious objection to any change, I will close these
issues. 
We have only one issue remaining from the WG Last Call.

-----------------------
EDITORIAL ISSUES

#758: smiv2-07: Is the BridgeId description still correct? it is not
clear that the definition is wrong. The question has been posed
publicly and nobody, including the co-chair of 802.1, responded that
it was in fact wrong. I would only like to see corrected text
submitted if this is in fact WRONG. Issue closed.

#759: rstpMIB registration. This issue is purely editorial, and the
presence or non-presence of the comment in this document is
immaterial. Editor's choice. Issue closed.

#761 portPathCost32 description - The inaccuracy is editorial, and
immaterial to the functionality of the object. No improved text has
been provided. Issue closed. 

#762: smiv2-07: unit of dot1dTpPortMaxInfo; done. Issue closed

#764 add original authors in contact information. Publicly requested
updated addresses. Done where the info was available. I suggest we
simply submit with the **missing data here** comment in -08-; this way
the author is still credited, and we do not provide inaccurate contact
info for those persons. Purely editorial. Issue closed.  

Other editorial changes:
1) "group" was changed to "subtree" througout.

-----------------------
TECHNICAL ISSUES

#757 forward reference in MODULE-IDENTITY: two proposals; either
works; editor's choice. Issue closed.

#669: smiv2-07: compliance requirements for 32-bit pathcost; and
#760 smiv2-07 changing bridgeCompliance and bridgeCompliance2: 
The description in PathCost was changed in a way that maintains
compliance for existing implementations, and tweaks the semantics of
the value 65535 for those implementations that also support
PathCost32. It almost looks legal. Precedence for this approach is
found in IF-MIB. The bridgeCompliance was renamed to
bridgeCompliance1493 and made current, and a new compiance was added
for implementations that support PathCost32. Issues closed.

-----------------------
UNRESOLVED ISSUES:

#543: smiv2-06: semantic changes; the following objects changed
semantics of an existing object: dot1dPortPriority,
dot1dStpTimeSinceTopologyChange, and dot1dStaticAllowedToGoTo. These
objects were modified to support 802.1t semantics. Since 802.1t
implementations have been fielded before this mib becomes available,
the behavior of current agent implementations might be non-compliant
with the updated definitions. Even an implementation that claims
compliance to bridgeCompliance1493 will be impacted because the
semantics of objects from RFC 1493 have been changed. 

David Harrington
[email-masked]
co-chair, IETF Bridge WG

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Jan 2005 23:39:36 +0100

> semantics of objects from RFC 1493 have been changed. 

dot1dStpPriority:
dot1dStpPortPriority:

I think the change is really a clarification that only a subset of
the original value range is allowed for bridges that comply to IEEE
802.1t or IEEE 802.1w so I do not see a real problem here for _agent_
implementations. Bridges supporting IEEE 802.1t or IEEE 802.1w likely
reject values which are outside the set of legal values and I would
guess that this is exactly what is currently implemented and deployed.
Can someone confirm my guess?

dot1dStpTimeSinceTopologyChange:

Can't really judge the difference since I do not know enough about
RSTP and tcWhile timers. Can someone explain what the impact of this
change might be?

dot1dStaticAllowedToGoTo:

I am not sure what the issue here is. Did this semantically chance
at all?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 11 Jan 2005 16:17:28 -0500

Hi,

1) I agree with your analysis on the Priority objects.
2) I think the topologychange object has been changed in a way that
could break existing (non-RSTP-knowledgeable) applications that are
run against an RSTP-supporting agent, 
3) the range has been constrained in the revision. This is probably
not a problem, but it is a semantic change.

I think these changes are technically illegal, but if the WG accepts
them, I can live with that.
If nobody objects, I will close this issue, and submit the document
with these changes.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Thursday, January 06, 2005 5:40 PM
> To: David B Harrington
> Cc: [email-masked]
> Subject: Re: [Bridge-mib] Draft-ietf-bridge-bridgemib-smiv2 
> Issues Resolution
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Jan 2005 23:33:03 +0100

> not a problem, but it is a semantic change.

Does someone recall where the introduced size limit for ...AllowedToGoTo
object comes from?  The port index is restricted to 65535 and from that
perspective the upper boundary would be 8K and not 512 bytes (which 
is equivalent to a maximum of 4096 ports). Can some IEEE 802.1 expert
please explain this?

/js

---

From: John Flick <[email-masked]>
Date: Tue, 11 Jan 2005 16:15:24 -0800

The PortID used to identify a port in STP (or RSTP or MSTP...) is
16 bits.  Of that, the upper four bits is used for port priority,
and the lower 12 bits are used for the port number, which
effectively limits you to 4k ports per bridge. (This was where the
changes to port priority came from in .1t.  Originally the port
priority and port number were 8 bits each, which limited you to
256 ports per bridge.)  512 bytes can hold a bitmask representing
4k ports.

John

---

From: John Flick <[email-masked]>
Date: Tue, 11 Jan 2005 16:27:40 -0800

Dave,

The tcWhile timer is an internal state variable to indicate the
time remaining for the bridge to send configuration messages with
the topology change bit set.  The added text in the description of
the TimeSinceTopologyChange object just specifies from what point
in the RSTP topology change state machine the topology change
time is measured.  The "meaning" of the object is actually
unchanged.  I'm not sure how this would break an application.

John