Re: [Bridge-mib] FW: RFC 4188

[Alfred Hönes <[e-mail]>]

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

This is one possible solution.

Or, as proposed originally (see above):
>>> The easiest way to remedy this inconsistency would be to modify
>>> the OBJECTS list of the OBJECT-GROUP dot1dStpPortGroup2 by
>>> replacing 'dot1dStpPortPathCost32' by 'dot1dStpPortPathCost'.
Surely, this would result in a certain amount of redundancy as well
(both OBJECT-GROUPS become identical).

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

The primary intent of my proposal was to get rid or the wording
  "it is for a protocol being processed by the local bridging function"
	 ^^^^^^^^^^^^^^
in the context of _outgoing_ frames.

Since the _total_ count of outgoing frames can be found in the
ifTable, a definition that offers additional information -- and
hence does not strictly conform to IEEE802.1D -- would be desirable.

The system supporting the bridge function might perform (IP)
routing functions as well (the distinction might be made by
considering L-SAPs, SNAP headers, and/or VLAN IDs). Frames
containing IP packets should be counted in the IP Forwarding
MIB and hence SHOULD be excluded from the counts in the Bridge
MIB. Such behaviour was perhaps intended since RFC 1493.
Frames with IP packets destined to / originating from local IP
based services, e.g. SNMP,  will be counted in the IP MIB (and
in upper layer protocol MIBs); I would prefer to _not_ count
such frames as "being processed by the local bridging function".

Therefore the decision should be made if we would like to count
the bridged frames, or both the bridged frames and the BPDUs here.

The natural way would be to have BPDU counters in the
dot1dStpPortTable and to only count bridged frames in the
dot1dTpPortTable -- but, unfortunately, appropriate objects
in the former table do not exist (yet).

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

Yes, indeed!


Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+


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