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

From: Dan Romascanu <[email-masked]>
Date: Sun, 26 Aug 2001 17:02:33 +0200

> 		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.

Because of the unhappy scheduling conflict of the Bridge MIB meeting with
another meeting, I could not attend the meeting in London, but I have at
least one strong reason in favor of supporting spanning tree per port
activation / de-activation. The source of the information is from our
Technical Support, who brought the requirement to the attention of our
software group. Some customers using Novell clients asked for Spanning Tree
to be disabled per port, because on some Novell clients, the blocking state
of a port with Spanning Tree enabled and no station connected prevented the
clients to connect to their servers. It appears that the timers for the
learning mechanism to learn the address and allow the propagation of the
client messages to the Novell severs are longer than the timers that allow
the client to reach the conclusion that there is no server around, and no
appropriate re-trial mechanism is available.

This may be enough taking into account the popularity of the Novell
environments. In any case, as the activation / de-activation of spanning
tree per port seems to be quite wide-spread in implementations, I would
suggest that we reverse the decision taken in the meeting.

Regards,

Dan

---

From: Dan Romascanu <[email-masked]>
Date: Sun, 26 Aug 2001 17:05:11 +0200

> 	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.
>

I support publishing the 802.1x as an Informational RFC, for the reason
mentioned by Mike A. in the meeting.

Regards,

Dan

---

From: "Maurice Goodfellow" <[email-masked]>
Date: Tue, 28 Aug 2001 11:26:29 +0100

My understanding is that Edge Ports are there in the specification to deal with
just this issue.

Maurice

Dan Romascanu <[email-masked]> on 26/08/2001 16:02:33

Sent by:  Dan Romascanu <[email-masked]>

To:   "'Ayers, Mike'" <[email-masked]>, "'bridge-mib @ietf.org'"
      <[email-masked]>
cc:    (Maurice Goodfellow/GB/3Com)
Subject:  [Bridge-mib] RE: [Bridge-mib] Meeting minutes for the 51st IETF

Regards,

Dan

---

From: "Ayers, Mike" <[email-masked]>
Date: Tue, 28 Aug 2001 16:39:08 -0500

> From: Michael MacFaden [mailto:[email-masked]] 
> Sent: Friday, August 24, 2001 04:19 PM
> 
> At 04:46 PM 8/24/2001 -0500, Ayers, Mike wrote:
> >                c.)  Is dot1dStdPortEnable redundant?
> >
> >                Mike A.:  No, a port may not have a unique ifIndex.
> >
> >                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,

	That's news to me.  I looked at one of our bridges, and it does seem
to create an internal VLAN, perhaps to this purpose, but I do not believe
that all equipment does this.

	In fact, when I was building a simulation network last year, I
discovered this to be (apparently) the minority case.  The two methods that
we confirmed as used in the field were:

	1.)  All ports bound to a single ifIndex, which represented the IP
address (and corresponding single ethernet address, realized on all ports)
of the bridge's management agent.

	2.)  A single listed ifIndex, the same as (1).  However, the
dot1dBasePortIfIndex objects would start at that object and increment,
pointing to nonexistent ifIndex entries.  This seemed (still seems) wierd,
but we saw it in use, apparently (I didn't personally confirm this one).

	Note: action item done!

> 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),

	Correction: the underlying port is fully operational, but no traffic
is being sent to it or received on it because the interface to it is shut
down.
  
> 2) When dot1dStpPort is set to disabled, what should 
> ifAdminStatus report?

	Up or down, whatever it is set to.  It will try and fail to pass
packets along and listen for packets that never arrive - the same thing
happens when you pull the cable.

>    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.

	I don't see bad implementations as a case for removing an object.  I
concede, however, that a critical mass of bad implementations can render an
object useless - so I see (but not necessarily concede) your point for
depracation.

>    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.

	I would expect the link to be shut down by dot1dStpPortEnable in all
cases.

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

	Yep - that's what I expect.

> 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.

	Ah, but we'd really need to confirm that applications are not using
- and that isn't really possible.

Unsolicited opinion:

	It seems that whenever we find ourselves deep in some muck or other
of confused, possibly incompatible implementations, we can look back and
find a lot of assumptions in our wake.  It can also be difficult, looking
back, to understand why we once felt that terms like "port", "interface",
and "enable" didn't need definitions.  Fun with myopia...

/|/|ike

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

---

From: "Les Bell" <[email-masked]>
Date: Wed, 29 Aug 2001 13:05:57 +0100

My preference is to publish this as an Informational RFC, but we must ensure
that the IEEE 802.1X document is referenced as the definitive source for this
MIB and to re-publish it if IEEE 802.1 update the MIB in future revisions of
that standard.

Les...

Dan Romascanu <[email-masked]> on 26/08/2001 16:05:11

cc:    (Les Bell/GB/3Com)

Regards,

Dan