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

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

The Rapid Spanning Tree Protocol (RSTP) with "Edge Port" configuration
enabled for the Novell client ports will solve this problem, while still
allowing detection of loops created by users 'accidently' plugging
another switch into the port instead of a host.  RSTP allows an Edge
Port to go to the forwarding state immediately, blocking it again, if
required, as indicated by any received BPDUs on that port.  Legacy STP
implementations could mimic this behaviour.  This allows the Novell
client on an Edge Port to get a timely response, while still protecting
the network against inadvertent loops.

The problem with disabling STP/RSTP on a per port basis is how to define
the behaviour of the port when it is disabled.

    Does the port still act as a Bridge port?
    Or does it act as a Repeater port?

If you flood the STP BPDUs received on that port, you cannot rely on
simple hardware flooding, as this will be limited to the VLAN defined by
the PVID for the port, as it is an untagged frame, and some loops will
not be detected.

If you filter the STP BPDUs received on that port, as a Bridge is
supposed to, loops will not be detected.

Some (third party) hardware architectures that I have come across do not
allow individual addresses from the Bridge reserved Address range to be
enabled (forwarded to the CPU only) and disabled (flooded, like user
data frames, within VLAN constraints) independently.  Thus disabling STP
blindly will cause problems for other protocols.
  * GVRP BPDUs, like STP and RSTP BPDUs would need to be flooded across
    all VLANs.
  * GMRP BPDUs would need to be flooded within the VLAN constraints.
  * If we flood LACPDUs we will make a full duplex port behave like a
    shared media, which will cause constant churning and LACP will not
    enable the port.
  * 802.3 Pause frames should never be flooded.
  * Port Access Entity (PAE) control frames for Network Login should
    never be flooded.

I guess there are other aspects of the Bridge behaviour that need to be
considered that I have not listed.

In conclusion, I would suggest the Edge Port behaviour defined in 802.1t
and 802.1w is a simple solution, which has fewer implications on other
aspects of Bridge behaviour.

Les...

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:    (Les Bell/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

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

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 29 Aug 2001 11:20:46 -0700

>   Or does it act as a Repeater port?

Can you be more specific? I assume these definitions:
A repeater is a physical  layer function that just amplifies a signal. 
A bridge port parses the frame and resends it either cut-through
or store/forward to one or more ports. 
I don't see how turning off stp would change this physical port behavior.

>supposed to, loops will not be detected.

Why not let the operator decide if that is going to be a problem or
not. Also, please consider these cases:

1) Take two physical ports that are bridging.
Next combine them into a Link Aggregation.
What should the effect be on the existing instances in the
dot1dBasePortTable? (Keep or remove?)

2) Take a port that bridges traffic within its assigned vlan.
Change it to protocol based vlan and possibly add an
ip interface to route to other vlans as is possible with
most l2/l3 switch routers.  The switch still bridges traffic
within the vlan but STP may or may not be running. Basic
frame inspection, learning, forwarding and flooding still work
without stp.

Should the port continue to exist in the dot1dBasePorTable
if it is capable of bridging but not currently running STP
even though it still bridges IP packets that transit (src/dest)
on the subnet/vlan set of ports found on that bridge?

Turning on/off  stp on a given port/interface should be
a standard feature just like all other control
protocols in use: ospf, isis, bgp. Even if it causes loops.

Mike