Subject: [Bridge-mib] FW: RFC 4188

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 19 Oct 2005 14:11:43 +0200

WG please check and comment.

Bert

-----Original Message-----
From: Bob Braden [mailto:[email-masked]]
Sent: Monday, October 17, 2005 11:59
To: [email-masked]
Subject: FYI

>From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
>Subject: RFC 4188
>To: [email-masked], [email-masked]
>Date: Mon, 17 Oct 2005 12:12:30 +0200 (MESZ)
>Cc: [email-masked], [email-masked]
>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:  [email-masked]                     |
>+------------------------+--------------------------------------------+

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Oct 2005 16:15:15 +0200

> >errata note to the RFC editor.

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

       GROUP   dot1dStpPortGroup2
       DESCRIPTION

with

       GROUP   dot1dStpPortGroup
       DESCRIPTION

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.

> >to that 802.1D clause might be considered inappropriate as well,

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

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 20 Oct 2005 13:45:34 +0200 (MESZ)

> This makes sense to me as far as I understand the issue.

This is one possible solution.

>>> replacing 'dot1dStpPortPathCost32' by 'dot1dStpPortPathCost'.
Surely, this would result in a certain amount of redundancy as well
(both OBJECT-GROUPS become identical).

> included or excluded in these counters may be more helpful than the

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.

--

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 24 Oct 2005 11:54:48 -0400

Hi,

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

In the process of making this change, we ran across one object that
had been modeled in the MIB with a range. During an update of the
underlying technology, the IEEE managed variable changed the
permissible range. SMI rules prevent us from simply changing the range
to match the IEEE change.

bridgeCompliance1493 should contain dot1dStpPortGroup, with
dot1dStpPortPathCost with its range of (1..65535). 

bridgeCompliance4188 should contain dot1dStpPortGroup2, with
dot1dStpPortPathCost32 with its range of (1..200000000).

We added some text to the definition of dot1dStpPortPathCost in
RFC4188: 
"          New implementations should support dot1dStpPortPathCost32.
           If the port path costs exceeds the maximum value of this
           object then this object should report the maximum value,
           namely 65535.  Applications should try to read the
           dot1dStpPortPathCost32 object if this object reports
           the maximum value."

Unfortunately, we did not state whether new implementions should
continue to support the dot1dStpPortPathCost, and we did not deprecate
it, although we defined how to handle the interaction between the two
objects.

My interpretation of the two compliance clauses is:

If you want to be compliant with RFC1493 (to be interoperable with
implementations of 802.1D-1998 with RFC1493 MIB support), then you
should support dot1dStpPortPathCost.

If you want to be compliant with RFC4188 (to be interoperable with
implementations of 802.1D-1998 with 802.1t with RFC4188 MIB support),
then you should support dot1dStpPortPathCost32.

If you want to be compliant with devices that support 802.1D-1998 with
RFC1493 support, AND devices that support 802.1D-1998 with 802.1t with
RFC4188 MIB support, then you should implement BOTH
dot1dStpPortPathCost and dot1dStpPortPathCost32. If you support both
objects, then you should implement the logic in the description of
dot1dStpPortPathCost. If you support both, you may be able to claim
compliance to both bridgeCompliance1493 and bridgeCompliance4188.
 
We should recognize that NMSs that only understand RFC1493 logic for
dot1dStpPortPathCost may have problems if the value is set to 65535. 

Conclusions:
I don't think that dot1dStpPortGroup and dot1dStpPortGroup2 need to be
changed. dot1dStpPortGroup3 can be eliminated.

bridgeCompliance1493 is fine as is.
bridgeCompliance4188 MANDATORY-GROUPS should be changed to include
dot1dBasePortGroup2 rather than dot1dBasePortGroup.

My $.02
David Harrington
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wijnen, Bert
(Bert)
> Sent: Wednesday, October 19, 2005 8:12 AM
> To: Bridge-Mib (E-mail)
> Subject: [Bridge-mib] FW: RFC 4188
>

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 24 Oct 2005 12:25:15 -0400

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
[email-masked]
co-chair, IETF Bridge WG