Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/bridge/bridge-minutes-91mar.txt

Text File | 1993-02-17 | 15KB | 458 lines

CURRENT_MEETING_REPORT_



Reported by Fred Baker/ACC

BRIDGE Minutes

The Bridge MIB Working Group convened for two sessions on Tuesday, March
12, 1991.
The Bridge MIB under review had been posted to the bridge-mib discussion
group on February 16, 1991, as Working Document Bridge MIB, Draft 6, by
Decker, Langille, Rijsinghani, and McCloghrie.

Chair Fred Baker opened the meeting with a review of the proposed
Agenda, which had been posted to the discussion group earlier.  All
present agreed to the Agenda, which follows:


   o Static Table (dot1dStatic)
     Four objects in the entry
   o Window Table (dot1dWindow)
     Two objects in the entry
   o Base Group/Port Table (dot1dBase)
     Three objects in the group
     Three objects in the port entry
   o STP Group/Port Table (dot1dStp)
     Fourteen objects in the group
     Eleven objects in the entry
   o SR Group/Port Table (dot1dSr)
     Sixteen objects
   o Transparent Group/FDB and Port Tables (dot1dTp)
     Two objects in the group
     Three objects in the FDB Entry
     Five objects in the Port Entry


Anil Rijsinghani presented the dot1dStatic table.  He gave a review of
how Forwarding Database entries come to be and how entries in the static
Table are made.  The SNMP concept of entries with a status of
``invalid'' was also discussed.

Jim Kinder initiated a lengthy discussion of the relationship of table
entries with a dot1dStaticReceivePort of value zero to other entries.
Various hypothetical scenarios were discussed and the resulting decision
was that an entry with a dot1dStaticReceivePort can coexist along with
other entries for the same address.

                                   1






The discussion of the dot1dStatic table was suspended when the Working
Group was addressed by Phill Gross, IETF Chair.  He talked about the
interaction between the IETF and the IEEE 802.1d Committee.  Last year a
letter was received from the IEEE expressing concern about a possible
duplication of efforts by the IETF Bridge MIB Working Group and the IEEE
802.1d Committee.

Phill reviewed the IETF philosophy for using the work of a standards
body in conjunction with its own work.  The IETF will use the reference
work as a starting point, while being free to subset it, and within the
confines of sound engineering principles, to augment it.

A draft of a response letter to the IEEE was presented (see below) and
the group approved of sending it along with a copy of the Bridge MIB.

Jeff Case pointed out that we need to be sensitive to the fact that a
reference document that is used for a starting point may change as work
is done within the IETF and that an incompatibility may result between
the final reference document and the final IETF work.

After the break, talk resumed on the the dot1dStatic table.  The
agreement was that an entry in the table with dot1dStaticReceivePort=0
is the default value to use if a specific dot1dStaticReceivePort is not
specified.

The hierarchy of the Forwarding Database is this, then.


   o Static information for a specific receive port
     (dot1dStaticReceivePort>0).
   o Static information for all ports (dot1dStaticReceivePort=0).
   o Learned information.


The dot1dStatic table was approved with wording to accomplish the above
changes.

Keith McCloghrie presented the dot1dTpFdbWindowTable, starting with an
overview of the design considerations

The Problem:  To provide an efficient means of retrieving the whole or a
significant portion of a transparent bridge's Forwarding Database.



Alternatives:

                                   2






   o Get-Next Sweep - 1 Powerful Get Next per Conceptual Row
     1 Conceptual Row per Round Trip
   o Bulk Algorithm (RFC 1187)
     either - 1+ Powerful Get Next per Conceptual Row
     say, 3 Conceptual Rows per Round Trip
   o or say, 1 Powerful Get Next per 2 Conceptual Rows +
     1 Get Request per 10 Conceptual Rows
   o say, 4 Conceptual Rows per Round Trip
   o Window Table:  1 Powerful Get Next per 40 Conceptual Rows
     40 Conceptual Rows per Round Trip


Advantages:


   o Less ASN.1 encoding/decoding (size and performance)
   o Can access starting in the middle of a table (e.g., all DECNET
     addresses)

Disadvantages:


   o Have to look into data to get address for next Powerful Get Next
   o DUMB MIB sweepers will retrieve redundant information.  (but in the
     same number of requests)


Why 40?


   o A round number
   o PDU size  < 576
   o Benefit of  >40  not considered worth the effort


Keith then compared the dot1dTpFdbTable and the dot1dTpFdbWindowTable,
noting that they contain the same number of entries.



     Window Table                         FDB Table

          _______________                     _______________
          |      N      |                     |      N      |
         _|_____________|                    _|_____________|
         |  (N-1),N    ||                    |     N-1     ||
         |             |                     |             |

                                   3






        .             .                     .             .
       .             .                     .             .
      .             .                     .             .
     _______________                     _______________
     |    2-41     |                     |      2      |
    _|_____________|                    _|_____________|
    |    1-40     ||                    |      1      ||
    |             |                     |             |
    |_____________|                     |_____________|



A discussion of the dot1dTpFdbWindowTable followed Keith's presentation.

Bob Stewart argued for including 42 entries from the FDB in each
dot1dTpFdbWindowTable.  He presented a sound engineering underpinning
for his argument but the group decided to leave the number at 40.

A corollary discussion took place about the viability of having a
variable length window.  Jeff Case pointed out that the SNMP Protocol
Specification says in part:

``An implementation of this protocol need not accept messages whose
length exceeds 484 octets.''

He recommended that the Bridge MIB should not allow arbitrarily large
PDUs.  The Working Group agreed to leave the number at 40.

A question was raised about the dot1dTpFdbWindowTable being in the
spirit of SNMP vis a vis, not supporting aggregate objects.  Jeff Case
spoke once again and indicated that although the dot1dTpFdbWindowTable
did not particularly excite him, he had no philosophical objection to
it.

Various optimization ideas were presented for Powerful Get Next walks
and although no consensus was reached, four options were discussed for
the disposition of this table.


  1. Delete it.
  2. Leave it in the MIB as is (Status Optional).
  3. Port it to another document to be developed in the Experimental
     tree.
  4. Leave it in the MIB, but change the status to Mandatory.



                                   4






No consensus was reached and the dot1dTpFDBWindow group discussion was
tabled.

After the break, Chair Fred Baker led a review of the document section
by section.

Keith McCloghrie clarified that the wording ``protocols that are
bridged'' is used to differentiate between those PDUs that are bridged
versus those that are not.

Bill Anderson spoke from a user's perspective.  He presented a need for
the Bridge MIB FDB to cover all addresses, bridged and otherwise.
Various members of the group pointed out that the Remote LAN Monitoring
group was addressing this issue, and in fact had specified this
functionality.

Two IEEE 802.1d managed objects were left out of the ``not included''
group on page 8.  These are SpanningTreeProtocolPort objects
DiscardLackOfBuffers and DiscardErrorDetails.  These will be added.

The discussion moved to the dot1dBase group.

Bob Stewart noted that bit ordering for the ``Bridge ID'' was not
specified, and it was necessary here and other places in the document.

The discussion moved to the dot1dStp group.

The incompatibility between IEEE 802.1d specification of time in
1/256ths of a second and the Bridge MIB of 1/100ths of a second was
brought up.  A challenge was issued by Fred Baker to name a chip that
gave 1/256ths granularity for its clock, and the issued died.  A side
issue of the syntax of dot1dStoMaxAge was brought up.  After a
discussion of the correct use of TimeTicks vs INTEGER, no change was
recommended.

A change was made to dot1dStpPriority description to uniquely identify
two octets within the Bridge ID.

Maurice Turcotte pointed out that dot1dStpPortMulticastAddress should
not be on a per port basis and that this address can be determined from
the variables dot1dStpProtocolSpecification and ifType.  This variable
was included at the request of Eric Decker and since he was not present,
the group decided to delete this variable, and allow Eric to comment.

In the afternoon session, the broken(6) dot1dStpPortState was discussed

                                   5






at great length.  No agreement was reached and the issue was tabled.

Steve Sherry requested that new TCN counters be added.  The consensus of
the group was that these counters would present information available
elsewhere and were most useful for debugging code rather than networks.
No variables were added for TCN counters.

A discussion of BridgeID vs.  (Priority - Address) with respect to
dot1dStpPortDesignatedPort.  The broad issue was whether to represent
BridgeID variables as one variable or separated into BridgePriority and
BridgeAddress.  The decision was to leave the variables as they are in
the document.

The range of dot1dStpPortPathCost should have been (1-65535)

The dot1dSr group passed without comment.

The dot1dTp group passed without comment.



After a brief recess the broken(6) dot1dStpPortState was revisited.

The two major points raised in favor of keeping this state were:


  1. We need to know when the Spanning Tree Protocol cannot bridge
     through a port because it is dysfunctional and it would be nice to
     know that from one variable and,
  2. It is possible for the Spanning Tree Protocol to have the port in
     forwarding state and the port be non-operational.


The two major points against this state were:


  1. There is no broken(6) state in the Spanning Tree Protocol and,
  2. This information is already available from the combination of
     ifAdminStatus, ifOperStatus, and dot1dStpPortState.


After more intense discussion, the group reached consensus and removed
the broken(6) value from the dot1dStpPortState.

Next the dot1dFdbWindow group was reopened for discussion.  After a

                                   6






brief discussion, the consensus was reached that we separate the
dot1dFdbWindow group into a separate document and develop it further in
the Experimental branch of the MIB.

Next the traps were reviewed and agreement was reached after some
discussion to let the traps stand.  A slight modification was made to
the newRoot trap description, with a view to ensuring (to the extent
possible) that the Network Management Station would be able to receive
the trap.

The Bridge MIB Working Group agreed to forward the Bridge MIB Draft 6,
with the above modifications, to the IETF for acceptance as a Proposed
Standard.

LETTER TO IEEE 802.1



     William P. Lidinsky
     Chairman, IEEE 802.1
     Institute of Electrical and Electronics Engineers



Dear Mr.  Lidinsky:

Enclosed with this letter, please find the current working draft of the
SNMP Bridge MIB, produced by the IETF Bridge MIB Working Group.

The Bridge MIB Working Group was organized under the IETF's Network
Management Directorate in May 1990, and has studied the semantics of
802.1(d) with a goal of representing it in an SNMP SMI-compliant MIB.

The IETF wishes to cooperate with, and coordinate its MIB development
efforts with, other ongoing MIB development activities in other
standards organizations.  In cases where the IETF wishes to develop an
SNMP MIB for technology already being considered by another standards
group, we have established the following policy:

1) The IETF will always utilize the current effort of another group as
the starting point for its own MIB development activities.  Therefore, a
major portion of the IETF effort may simply be translating the other MIB
into the SNMP SMI idiom.

2) Because the requirements of other organizations may not be precisely
the same as those of the IETF, we may choose initially to include only a
subset of the other MIB. In such a case, we would reserve the

                                   7






opportunity to consider adding the remaining objects to the SNMP MIB in
the future.

3) In some cases, we may wish to propose additional objects based on
operational experience.  It is not expected that this would be a very
common occurrence, and in such cases we would make every effort to
communicate the IETF proposed objects back to the appropriate group for
their consideration.

A comparison of 802.1(d) and the current IETF draft should show that, in
fact, there are few significant differences.

I hope your group will have the opportunity to review the IETF SNMP
Bridge MIB. We would appreciate hearing any comments or suggestions you
may have.

We look forward to working together with you in the future.

Thank you,



IAB Chair

IETF Chair

IETF NM Area Director

IETF Bridge MIB Working Group Chair



Attendees

William Anderson         [e-mail]
Fred Baker               [e-mail]
Steve Bostock            [e-mail]
Howard Brown             [e-mail]
Theodore Brunner         [e-mail]
Jeffrey Case             [e-mail]
John Casey
Chris Chiotasso          [e-mail]
Bill Durham              [e-mail]
Nadya El-Afandi          [e-mail]
Richard Fox              [e-mail]

                                   8






Shawn Gallagher          [e-mail]
Martin Gray              [e-mail]
Jeremy Greene            [e-mail]
B.V. Jagadeesh           [e-mail]
Frank Kastenholz         [e-mail]
Manu Kaycee              [e-mail]
Kenneth Key              [e-mail]
Jim Kinder               [e-mail]
Cheryl Krupczak          [e-mail]
Then Liu
Keith McCloghrie         [e-mail]
John Morrison            [e-mail]
Robert Peglar            [e-mail]
David Perkins            [e-mail]
Anil Rijsinghani         [e-mail]
Mark Schaefer            [e-mail]
Dror Shindelman          [e-mail]
Bob Stewart              [e-mail]
Maurice Turcotte         [e-mail]



                                   9