FW: RFC 4188

WG please check and comment.

Bert

-----Original Message-----
From: Bob Braden [mailto:braden <at> ISI.EDU]
Sent: Monday, October 17, 2005 11:59
To: bwijnen <at> lucent.com
Subject: FYI

>From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah <at> tr-sys.de>
>Subject: RFC 4188
>To: kenyon.c.norseth <at> L-3com.com, elbell <at> ntlworld.com
>Date: Mon, 17 Oct 2005 12:12:30 +0200 (MESZ)
>Cc: j.schoenwaelder <at> iu-bremen.de, rfc-editor <at> rfc-editor.org
>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:  ah <at> TR-Sys.de                     |
>+------------------------+--------------------------------------------+