[Bridge-mib] FW: RFC 4188
"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Wed, 19 October 2005 12:11 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESCnX-000223-1o; Wed, 19 Oct 2005 08:11:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESCnV-00021y-ME for bridge-mib@megatron.ietf.org; Wed, 19 Oct 2005 08:11:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11466 for <bridge-mib@ietf.org>; Wed, 19 Oct 2005 08:11:48 -0400 (EDT)
Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESCzF-0001Ff-3y for bridge-mib@ietf.org; Wed, 19 Oct 2005 08:24:05 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9JCBk1e015815 for <bridge-mib@ietf.org>; Wed, 19 Oct 2005 07:11:46 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <SQW8Z4SK>; Wed, 19 Oct 2005 14:11:45 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550856886F@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Bridge-Mib (E-mail)" <bridge-mib@ietf.org>
Date: Wed, 19 Oct 2005 14:11:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail2.lucent.com id j9JCBk1e015815
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Content-Transfer-Encoding: quoted-printable
Subject: [Bridge-mib] FW: RFC 4188
X-BeenThere: bridge-mib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: bridge-mib.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:bridge-mib@ietf.org>
List-Help: <mailto:bridge-mib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=subscribe>
Sender: bridge-mib-bounces@ietf.org
Errors-To: bridge-mib-bounces@ietf.org
WG please check and comment. Bert -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: Monday, October 17, 2005 11:59 To: bwijnen@lucent.com Subject: FYI >From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@tr-sys.de> >Subject: RFC 4188 >To: kenyon.c.norseth@L-3com.com, elbell@ntlworld.com >Date: Mon, 17 Oct 2005 12:12:30 +0200 (MESZ) >Cc: j.schoenwaelder@iu-bremen.de, rfc-editor@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@TR-Sys.de | >+------------------------+--------------------------------------------+ _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib
- [Bridge-mib] FW: RFC 4188 Wijnen, Bert (Bert)
- Re: [Bridge-mib] FW: RFC 4188 Juergen Schoenwaelder
- Re: [Bridge-mib] FW: RFC 4188 Alfred Hönes
- [Bridge-mib] RFC 4188 compliance clauses David B Harrington
- [Bridge-mib] dot1dTpPortInFrames issue David B Harrington