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

From: Dan Romascanu <[email-masked]>
Date: Tue, 28 Aug 2001 14:19:34 +0200

Maurice,

The current definition of the edge ports is by two objects in the
dot1dStpExtPortTable which contains port-specific Rapid Spanning Tree
information. The issue that I am raising is not specific for Rapid Spanning
Tree environments. Do you suggest to take the objects referring to Edge
ports out of rtspConformance? This might work only if we place the objects
in a separate table, and actually it might be the right thing to do because
edge ports are defined in 802.1t, and not in 802.1w. 

Regards,

Dan

> -----Original Message-----
> From: Maurice Goodfellow [mailto:[email-masked]]
> Sent: Tuesday, August 28, 2001 12:26 PM
> To: Dan Romascanu
> Cc: 'Ayers, Mike'; [email-masked]'
> Subject: Re: [Bridge-mib] RE: [Bridge-mib] Meeting minutes 
> for the 51st IETF
> 
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> >         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: "Ayers, Mike" <[email-masked]>
Date: Tue, 28 Aug 2001 11:22:45 -0500

> From: Dan Romascanu [mailto:[email-masked]] 
> Sent: Sunday, August 26, 2001 08:03 AM

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

	Why can't this be done with dot1dStpPortEnable?

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

	I don't know that it was a decision as such that we made, but we
failed to find a champion for the idea.  Tag - you're it!

/|/|ike

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