[Bridge-mib] dot1dTpPortInFrames issue

["David B Harrington" <[e-mail]>]

Hi,

An issue has been raised concerning dot1dTpPortInFrames and
dot1dTpPortOutFrames.

As noted, this is an issue "left over from RFC 1493".

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

The wording used in the dot1dTpPortInFrames and dot1dTpPortOutFrames
DESCRIPTION clauses has existed in substantially the same form since
before RFC1286 was published in December 1991. The wording has
apparently not been a burden to the industry, since no changes were
made between RFC12865 and RFC1493, and no complaints on the wording
were received during the development of RFC4188, either from the
members of the Bridge WG or the IEEE 802.1 WG, whose review was
deliberately sought prior to publication of RFC4188, or during WG and
IETF Last Calls. 

Therefore, I suggest we take no action on the recommendation to change
the wording of these objects.

David Harrington
[e-mail]
co-chair, IETF Bridge WG

> >(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: [phone], Fax: 
> -18         |
> >| D-71254  Ditzingen     |  E-Mail:  [e-mail]            
>          |
> >+------------------------+-----------------------------------
> ---------+
> 
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
> 



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