Clause 10.7.6.1 states "MRPDU transmission as a result of the operation
of a state machine in a Bridge occurs only through the Port associated
with that state machine, and only if that Port is in the Forwarding
state."
This requirement (regardless of interpretation) is in conflict with
10.3.(e), which states "If a port is removed from the set [of Ports in
the Forwarding state for a given MAP Context], and that Port has declared
one or more attributes, then this Port transmits a Leave message (see
10.6)
for every attribute that it has declared."
10.3.(e) specifically requires that a port, which is no longer in the
Forwarding
state, transmits a Leave message.
Further, beyond the conflict with 10.3, interpretation of 10.7.6.1 is
unclear
with respect to spanning tree contexts.
In an SST environment, the behavior identified here is interpretted clearly:
Ports which are not in the Forwarding state do not transmit MRPDUs.
However, correct behavior is not clear in an MST environment. In an MST
environment, a port may be in the set of Forwarding ports in some spanning
tree instances, but not in the Forwarding set in other spanning tree
instances, and because this sub-clause is governing transmission of
MRPDUs as a whole, rather than individual attributes, no specific
spanning tree context is readily identifiable.
One might take a step beyond what is actually indicated in this
subclause, and interpret it to mean that MRPDUs transmitted on a port
do not include events for Attributes associated with spanning tree
instances for which this port is not in the Forwarding state. This,
however, leaves 4 problems:
-What if an AttributeEvent is only being encoded for the sake of
efficiency?
-LeaveAll events are not defined to be associated with any Spanning Tree
context.
-Domain attributes are not defined to be associated with any Spanning
Tree
context. Further here, it is undesirable to ever block Domain declarations
unless the port is not Forwarding in ANY Spanning Tree Instance. (Because
streams for the associated SR Class may be transmitted on any VLAN.)
-This still leaves a conflict with 10.3.(e), which indicates that
Leave events
are transmitted when an attribute becomes blocking.
The intent of the prohibition from transmitting MRPDUs on blocked ports
is unclear. The only (marginally) desirable effect it seems to produce
is that of slightly reducing the bandwidth used on the link (which, in the
point-to-point case is effectively blocked anyways). It may have been
intended to avoid propagating declarations along pathways through the
network which are at least partially blocking (which also would prevent
information loops), however, this is already accomplished by the MAP
function for each MRP application, which (for all currently defined
applications) does not propagate declarations to or from blocking ports.
Therefore, the proposed solution is simply to omit the requirement that
blocking ports do not transmit MRPDUs. This solution avoids the conflict
with 10.3.(e), avoids confusion over which Spanning Tree instance is
considered in the case of LeaveAll events or Domain messages, and also
avoids the undesirable consequences associated with blocking Domain
messages (which do not propagate).