Subject: [Bridge-mib] RFC 4188 compliance clauses
From: "David B Harrington" <[email-masked]>
To: "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "'Bridge-Mib \(E-mail\)'" <[email-masked]>
Date: Mon, 24 Oct 2005 11:54:48 -0400
List-Id: bridge-mib.ietf.org

Hi,

RFC4188 is supposed to be a translation of the SMIv1 MIB module in
RFC1493 into SMIv2 format.

In the process of making this change, we ran across one object that
had been modeled in the MIB with a range. During an update of the
underlying technology, the IEEE managed variable changed the
permissible range. SMI rules prevent us from simply changing the range
to match the IEEE change.

bridgeCompliance1493 should contain dot1dStpPortGroup, with
dot1dStpPortPathCost with its range of (1..65535). 

bridgeCompliance4188 should contain dot1dStpPortGroup2, with
dot1dStpPortPathCost32 with its range of (1..200000000).

We added some text to the definition of dot1dStpPortPathCost in
RFC4188: 
"          New implementations should support dot1dStpPortPathCost32.
           If the port path costs exceeds the maximum value of this
           object then this object should report the maximum value,
           namely 65535.  Applications should try to read the
           dot1dStpPortPathCost32 object if this object reports
           the maximum value."

Unfortunately, we did not state whether new implementions should
continue to support the dot1dStpPortPathCost, and we did not deprecate
it, although we defined how to handle the interaction between the two
objects.

My interpretation of the two compliance clauses is:

If you want to be compliant with RFC1493 (to be interoperable with
implementations of 802.1D-1998 with RFC1493 MIB support), then you
should support dot1dStpPortPathCost.

If you want to be compliant with RFC4188 (to be interoperable with
implementations of 802.1D-1998 with 802.1t with RFC4188 MIB support),
then you should support dot1dStpPortPathCost32.

If you want to be compliant with devices that support 802.1D-1998 with
RFC1493 support, AND devices that support 802.1D-1998 with 802.1t with
RFC4188 MIB support, then you should implement BOTH
dot1dStpPortPathCost and dot1dStpPortPathCost32. If you support both
objects, then you should implement the logic in the description of
dot1dStpPortPathCost. If you support both, you may be able to claim
compliance to both bridgeCompliance1493 and bridgeCompliance4188.
 
We should recognize that NMSs that only understand RFC1493 logic for
dot1dStpPortPathCost may have problems if the value is set to 65535. 

Conclusions:
I don't think that dot1dStpPortGroup and dot1dStpPortGroup2 need to be
changed. dot1dStpPortGroup3 can be eliminated.

bridgeCompliance1493 is fine as is.
bridgeCompliance4188 MANDATORY-GROUPS should be changed to include
dot1dBasePortGroup2 rather than dot1dBasePortGroup.

My $.02
David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wijnen, Bert
(Bert)
> Sent: Wednesday, October 19, 2005 8:12 AM
> To: Bridge-Mib (E-mail)
> Subject: [Bridge-mib] FW: RFC 4188
> 
> WG please check and comment.
> 
> Bert
> 
> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: Monday, October 17, 2005 11:59
> To: [email-masked]
> Subject: FYI
> 
> 
> 
> >From: Alfred Hönes <[email-masked]>
> >Subject: RFC 4188
> >To: [email-masked], [email-masked]
> >Date: Mon, 17 Oct 2005 12:12:30 +0200 (MESZ)
> >Cc: [email-masked], [email-masked]
> >X-Mailer: ELM [$Revision: 1.17.214.3 $]
> >X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
> >X-MailScanner-From: rfc-ed
> >X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on 
> boreas.isi.edu
> >X-Spam-Level:
> >X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 
> autolearn=ham
> >         version=2.64
> >
> >Hello,
> >
> >I'd like to mention some issues I've found reading the
> >recently published RFC 4188 authored by you.
> >
> >(Unfortunately, I've not been aware of the draft -- there
> >are just too many -- and thus did not comment earlier.)
> >
> >
> >(1)
> >
> >There is a significant inconsistency in the newly introduced
> >conformance information with respect to the new
> >'dot1dStpPortPathCost32' object:
> >
> >The  bridgeCompliance4188 MODULE-COMPLIANCE  macro
> >(at the bottom of page 37 and the top of page 38) says:
> >
> >     GROUP   dot1dStpPortGroup2
> >         DESCRIPTION
> >            "Implementation of this group is mandatory for
> >             bridges that support the Spanning Tree Protocol."
> >
> >     GROUP   dot1dStpPortGroup3
> >         DESCRIPTION
> >            "Implementation of this group is mandatory for bridges
> >             that support the Spanning Tree Protocol and 32-bit
path
> >             costs.  In particular, this includes devices
supporting
> >             IEEE 802.1t and IEEE 802.1w."
> >
> >Now (see upper half of page 34), both dot1dStpPortGroup2 and
> >dot1dStpPortGroup3 contain the object 'dot1dStpPortPathCost32'.
> >Thus the net result of the above text is that we have two
> >overlapping but different requirements for that object, and
> >that the object 'dot1dStpPortPathCost' is not covered by
> >the bridgeCompliance4188 statement at all.
> >
> >But, looking at the description clauses for dot1dStpPortPathCost
> >(on top of page 22) and dot1dStpPortPathCost32 (on page 23)
> >I conjecture that the original intent was to ALWAYS have
> >dot1dStpPortPathCost instantiated in rows of the
> >dot1dStpPortTable (as before, per RFC 1493), and to take
> >(the new semantics of) the special (max.) value 65535 for
> >that object as an indication that dot1dStpPortPathCost32 has
> >also been instantiated in the respective row; therefore, I
> >expect that dot1dStpPortPathCost should be included in the
> >conditionally mandatory groups named in bridgeCompliance4188.
> >
> >The easiest way to remedy this inconsistency would be to modify
> >the OBJECTS list of the OBJECT-GROUP dot1dStpPortGroup2 by
> >replacing 'dot1dStpPortPathCost32' by 'dot1dStpPortPathCost'.
> >But then the definition of dot1dStpPortGroup2 would-be-word
> >by word identical to the definition of dot1dStpPortGroup (!)
> >and it might be better to replace 'dot1dStpPortGroup' for
> >'dot1dStpPortGroup2' on the first line of the text fragment
> >cited above (bottom of page 37).
> >
> >Perhaps, an OBJECT clause mentioning the new semantics of the
> >max. value for dot1dStpPortPathCost in the past-RFC1493
> >context migth be appropriate as well.
> >
> >I think that a correction is needed for this issue and would
> >like to receive your comment before formally submitting an
> >errata note to the RFC editor.
> >
> >
> >(2)
> >
> >There is an issue (left over from RFC 1493) with the
> >DESCRIPTION clauses for the objects dot1dTpPortInFrames and
> >dot1dTpPortOutFrames on page 28 of RFC 4188.
> >The latter contains wording improper for outgoing frames
> >(obviously copied unchanged from the former), and both
> >descriptions contain a duplicate "only" within a phrase.
> >
> >I propose to clarify (and simplify the wording of) these
> >descriptions as follows.
> >
> >a) Replace:
> >
> >     dot1dTpPortInFrames OBJECT-TYPE
> >         ...
> >         DESCRIPTION
> >            "The number of frames that have been received by this
> >             port from its segment.  Note that a frame 
> received on the
> >             interface corresponding to this port is only counted
by
> >             this object if and only if it is for a protocol being
> >             processed by the local bridging function, including
> >             bridge management frames."
> >
> >    by:
> >
> >     dot1dTpPortInFrames OBJECT-TYPE
> >         ...
> >         DESCRIPTION
> >            "The number of frames that have been received by this
> >             port from its segment.  Note that a frame received on
> >             the interface corresponding to this port is counted by
> >             this object if and only if it is consumed by the local
> >             bridging function, including bridge management
frames."
> >
> >b) Replace:
> >
> >     dot1dTpPortOutFrames OBJECT-TYPE
> >         ...
> >         DESCRIPTION
> >            "The number of frames that have been transmitted by
this
> >             port to its segment.  Note that a frame transmitted on
> >             the interface corresponding to this port is only
counted
> >             by this object if and only if it is for a protocol
being
> >             processed by the local bridging function, including
> >             bridge management frames."
> >    by:
> >
> >     dot1dTpPortOutFrames OBJECT-TYPE
> >         ...
> >         DESCRIPTION
> >            "The number of frames that have been transmitted by
this
> >             port to its segment.  Note that a frame transmitted on
> >             the interface corresponding to this port is counted by
> >             this object if and only if it originates from a local
> >             bridging function, including bridge management
frames."
> >
> >Please correct me if this proposal does not match the original
> >intent of these DESCRIPTIONs.
> >(Concern: If the bridge is manageable, the management agent might
> >reside on the bridge that in this case would have an IP address and
> >perform the SNMP protocol stack and/or other IP protocols as well.
> >It might be the case that it was intended to include such locally
> >destined/originated packets of non-IEEE802.1D functions into the
> >above counters as well.
> >Important remark: IEEE802.1D clause 14.6.1.1.3, e.g., includes
> >"BPDUs, frames addressed to the Bridge as an end station, and
> >frames that were submitted to the forwarding process" into the
> >'Frames Received' count! Therefore, the REFERENCE clauses pointing
> >to that 802.1D clause might be considered inappropriate as well,
> >for both objects.)
> >
> >
> >Best regards,
> >   Alfred HÎnes.
> >
> >--
> >
> >+------------------------+-----------------------------------
> ---------+
> >| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., 
> Dipl.-Phys.  |
> >| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: 
> -18         |
> >| D-71254  Ditzingen     |  E-Mail:  [email-masked]            
>          |
> >+------------------------+-----------------------------------
> ---------+
> 
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
> 

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