[LinkSec] Re: [802.1] Proposed 802.1 response to Naveen Chandra's Interpretation Request
I have had no objections to the attached Interpretation, and have
therefore forwarded it to the IEEE office as our official
response.
Neil - I guess this needs to be added to our interpretations
page.
Regards,
Tony
At 17:47 17/03/2003 +0000, Tony Jeffree wrote:
Attached is Naveen Chandra's
Interpretation Request, and the text of the proposed 802.1 response. This
is being circulated for a 30-day default ballot; if no comments or
objections to this proposed response are received, I will forward it to
the IEEE as the official 802.1 response, in line with the motion approved
in our closing 802.1 plenary. The closing date for comment/objection
is:
18th April
2003
Regards,
Tony
=======================================================
Naveen Chandra's Interpretation Request:
----------------------------------------
Regarding link failure in bridge
--------------------------------
I saw the question regarding link failure in Interpretation #1.
Also the
response. Finally response says how to set macOperational flag. But
still
it does'nt say whether link failure is a topology change.
In 1998 802.1D, 8.8.3
disable_port(port_no)
{
root = root_bridge
--
--
if( root_bridge & !root)
{
detected topology change
}
}
This will not work for root bridge. So if the root bridge has
multiple
ports , removing one link will not generate any topology change. If
I
remote the !root, then topology change will be generated. Can you
guys
please let us know, is it the correct way of solving it?
========================================================
Proposed 802.1 Interpretation:
------------------------------
If the bridged local area network being considered is exclusively
operating
RSTP (802.1w Clause 17) rather than STP (802.1D Clause 8):
(1) Loss of a link does not directly give rise to a spanning tree
topology
change.
(2) Loss of a link may or may not cause a spanning tree topology
change
depending on the subsequent action of RSTP once the link loss has
been
detected.
(3) Link loss may be detected by RSTP either by expiry of the
infoWhile
timer at a Bridge Port following a period of cessation of reception of
BPDUs
from the Designated Bridge for a LAN/link or by detection of a change in
the
MAC Operational status of the Bridge Port's MAC (attached to the
LAN/link)
link to FALSE. (The MAC Operational parameter in specified in clause
6.4.2
of 802.1t)
(4) A change in the MAC Operational status of a Bridge Port's MAC to
FALSE
results RSTP's portEnabled variable for the port being set to
FALSE. (This
is described in the definition of the portEnabled variable in
802.1w-2001
17.18.15).
(5) Which ever way link loss is detected by RSTP, a topology change
will
only be detected and communicated to other bridges if the operation of
RSTP
in determining the active topology of the bridged local area network
results
in another Bridge Port that was previously not forwarding
transitioning to
the Forwarding state.
If a bridge attached to a link that is lost is operating STP:
(6) Loss of the link may be detected either by expiry of the BPDU
last
received by the port attached to the link, or by the bridge port
becoming
disabled.
(7) If the bridge port has become Disabled and was previously in
the
Forwarding state, a topology change will be detected and communicated
to
other bridges (assuming sufficient connectivity exists for this to be
done).
(8) If the loss of the link is only detected by expiry of a BPDU
received,
and the port was not previously Forwarding but becomes Forwarding due to
the
STP protocol selecting it as the Designated Port for the LAN/link, then
a
topology change will be detected and communicated.
(9) There are circumstances where loss of a LAN/link will not result in
STP
detecting or communicating a topology change. If the loss of the link is
not
internally communicated by the MAC Enabled status , whatever the
implementation reason, to a port that is already Forwarding there will be
no
topology change detected. If the loss of the link occurs on a port that
is
not Forwarding (an Alternate or Backup port) there will be no
topology
change. In both these circumstances there is no effective change to
the
active topology of the network, so the failure to detect is
unimportant
unless it is though that topology change detection can be used as a
general
purpose method for determining the future availability of LANs/links
rather
than their present use. There is no intent that the topology change
mechanism be used as such a general purpose method.
Regards,
Tony