Re: [Bridge-mib] FW: RFC 4188

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Oct 19, 2005 at 02:11:43PM +0200, Wijnen, Bert (Bert) wrote:
> >(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.

If I understand you right, you are proposing to replace:

       GROUP   dot1dStpPortGroup2
       DESCRIPTION
           "Implementation of this group is mandatory for
           bridges that support the Spanning Tree Protocol."

with

       GROUP   dot1dStpPortGroup
       DESCRIPTION
           "Implementation of this group is mandatory for
           bridges that support the Spanning Tree Protocol."

As a side effect, dot1dStpPortGroup2 would not be referenced anymore
(which may look a bit odd but surely is legal and does not harm).
This makes sense to me as far as I understand the issue.

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

This boils down to the meaning of the phrase

	"if it is for a protocol being processed by the local bridging
	 function" 
versus

	"if it is consumed by the local bridging function".

I am not sure the difference is that clear. I am not an expert in
bridge implementations so I can't really judge what actually has been
implemented on bridges claiming to support RFC 1493. If it turns out
that there is a need for a clarification (means there are different
implementations), I would prefer more concrete wordings. If the issue
is SNMP traffic, then a clear statement whether SNMP traffic is
included or excluded in these counters may be more helpful than the
proposed rewording.

Bridge MIB implementors and 802.1D experts are really needed to sort
this out.

/js	

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

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