Subject: [Bridge-mib] Meeting minutes for the 51st IETF

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 24 Aug 2001 16:46:38 -0500

Here's the first pass of the minutes for the IETF meeting.  Please
review carefully - in some places my notes were a little unintelligible.

/|/|ike

Meeting minutes for the Bridge MIB WG, 51st IETF

Tuesday August 7, 2001, 1700

1.)  Overview

	There are three drafts in progress.

	Bert W.:  Currently the chair is authoring documents.  Can we
	get co-editors?

	John Flick & K.C. Norseth volunteered.

	RFCs 1493, 1525, & 2674 need to progress.  RFCs 1493 & 1525
	are being updated to SMIv2.

	There are some new 802.1 MIBs

	Implementation reports are needed for RFCs:
		1493 - currently draft
		1525 - currently proposed
		2674 - currently proposed
	Please submit implkementation reports!  If you do not wish to
	submit your report to the group at large, you may submit
	privately to Les or Bert (addresses?)

2.)  SMIv2 Bridge MIB Draft

	draft-ietf-bridge-bridgemib-smiv2.txt

	This is a direct translation of RFC1493 into SMIv2.  However,
	a few issues have arisen:

		a.)  The object dot1dBasePortIfIndex should be of type
		InterfaceIndex, but is currently Integer32.

		Bert W.:  We can progress the IF MIB and use
		InterfaceIndex.

		Les:  We should also change "traps" to "notifications"
		in a comment.

		All: OK

		b.)  There are still problems with logical link
		aggregation.

		c.)  Is dot1dStdPortEnable redundant?

		Mike A.:  No, a port may not have a unique ifIndex.

		dot1dStdPortEnable remains.

		d.)  Some (many?) implementations permit spanning tree
		to be turned off an a per-port basis.  Should we
		standardize this?

		Many questions were raised about why this would be done
		and what the default behavior could be.  The group
		sought a rationale for doing this, but could not find
		one.  Therefore no action will be taken.

		e.)  Should we add an object to give the time of last
		change for dot1dBasePortTable?

		Mike A.:  Why make a change like this now?

		Bert W.:  We would have to recycle.

		Les:  Does anyone think that we should do this?

		(silence).

		f.)  Smilint complained about some notification
		definitions.

3.)  SMIv2 Source Routing Bridge MIB Draft

	Another direct translation of an SMIv1 MIB.

	No comments have been received yet.  Is anyone using the
	source routing bridge MIB anymore?

	Bert W.:  Why advance what nobody is currently implementing?

	(name?):  This is like the FDDI MIB, which needs no
	advancement.

4.)  802.1 Standards

	802.1w - Rapid reconfiguration
	802.1t - Update to 802.1d
	802.1u - Update to 802.1q
	802.1v - VLAN classification by port/protocol

	802.1 documents are available at
	http://grouper.ieee.org/groups/802/1/index.html,
	username: p8021
	password: go_wildcats

5.)  New MIBs

	Rapid Spanning Tree Protocol MIB (RSTPMIB):

		Involves changes to the bridge MIB.  We don't need to
		change the syntax, but there may be interoperability
		issues.

	U-bridge MIB:

		Only one new item.  This can be merged with 2674.

		John F.:  Can we merge all new MIBs with 2674?

		Mike A.:  If we merge them, will we just split them out
		again?

6.)  802.1 Standards, part 2

	Updates on 802.1t, 802.1w, 802.1u, 802.1v, and 802.1s (per-
	VLAN spanning trees)

	For 802.1x, IEEE wrote their own MIB - should we publish it as
	an informational RFC?

	Bert W.:  Do we want to?

	Mike A.:  We would then have all the bridge docs in one place.

	Les:  802.1x is not just a bridge.

	Bert W.:  Then we'd best take this to the mailing list.

7.)  Close

A.)  Action Items

	Mike A.:  Write up explanation of the port/ifIndex issue for
	the list.

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

---

From: Michael MacFaden <[email-masked]>
Date: Fri, 24 Aug 2001 16:19:06 -0700

>                dot1dStdPortEnable remains.

Due to the rather poor scheduling of the bridge and entity working groups,
I wasn't able to discuss this in London.

Since most modern ethernet switches as opposed to old repeaters have
a one for one mapping from dot1d to ifIndex, the following situations arise
which I think lead to  implementation/interoperability problems:
 
Consider these two case:
     a) port both bridges and routes
     b) port bridges only

1) When ifAdminStatus is set to down, what should dot1dStpPortEnable? 
   Probably up (bridging could occur, but underlying port is shut down),
   
2) When dot1dStpPort is set to disabled, what should ifAdminStatus report?
   In case a), I can see this object as a means to only stop bridging on a port
   w/out affecting routing or ifAdminStatus. Yet most devices I've tested have this object
   shut down the entire port like ifAdminStatus for both bridging and routing
   and if I recall some of them set ifAdminStatus to down.

   In case b), the behavior I susepect is to only shut down bridging but not
   shut the link off as in the case of ethernet.

   Almost any implementation I can find, even old ones, make dot1dStpPortEnable      
   basically shut off the port (ethernet link led goes off).

My point is, I don't think this object has been either implemented properly
or described properly which is why I asked for it to be deprecated. I'm not
sure if any applications are using it either.

Comments welcome.

Regards,
Mike MacFaden

---

From: Michael MacFaden <[email-masked]>
Date: Fri, 24 Aug 2001 16:23:41 -0700

>                one.  Therefore no action will be taken.

I agree that any new features would recycle the MIB module and
in the interest of moving 1493 up in the standards process, no new
objects should be added in the SMIv2 rewrite. (Maybe an BRIDGE2-MIB)...

The simple rational is that many devices support this feature. 
Can't we just look at the many existing implementations and
compare them to see if they all behave the same way? Should be an
easy report to create, maybe Tolly or Meir has one already.

Mike