802.1 Maintenance Database | MRP Attribute Propagation

Requested revision

Standard:	802.1Q-2011	Clause:	10.3
Clause title:	MRP Attribute Propagation

Rationale for revision

One intention for 10.3 is clear:
Propagation of an attribute through the network follows the active
 topology of the Spanning Tree Instance associated with that attribute.

However, the wording of 10.3, if strictly followed, does not necessarily
 achieve this goal. One result is that it could allow for declarations to
 be propagated from blocked ports.

It is clear from the wording that the set of ports that is being dealt
 with are only those which are in the Forwarding state for the relevant
 MAP context. It is not made explicitly clear that the relevant set of
 attribute values are only those which are associated with that same
 MAP context.

2 Examples follow.

First:
10.3.(a) says, "Any MAD_Join.indication ... received by MAP from a given
 Port in the set is propagated as a MAD_Join.request to the instances(s)
 of MAD associated with each other Port in the set."

The intention here seems to be that propagation only occurs if the
 MAD_Join.indication is for an attribute value which is associated
 with this same MAP Context, but this intention is not stated.

And so if a port which is blocked in MSTI1, but forwarding in MSTI2,
 and if a MAD_Join.indication is received for an attribute associated
 with MSTI1, 10.3.(a) can be interpretted as saying that when the MAP
 function is run for MSTI2, the attribute associated with MSTI1 is
 propagated to other ports in the forwarding set for MSTI2.

Second:
10.3.(e) says, "If a Port is removed from the set, and that Port has
 registered an attribute and no other Port has, then MAD_Leave.requests
 are propagated to the MAD instances for each of the other Ports in
 the set."

The intention is clearly that "an attribute" only refers to attributes
 associated with the MAP Context that "the set" is associated with. But,
 as worded, if a port leaves the forwarding set on one MSTI, then
 MAD_Leave.requests are propagated to the other ports (but only ports
 which are Forwarding in the current MAP Context) for attributes associated
 with ANY MAP Context.

The proposed revision would have 10.3 explicitly state the independence
 of MAP Contexts which is implied.

Proposed text

"
For a given MRP application and MAP Context (10.3.1), and for the set of
 Ports that are in a Forwarding state as defined by that MAP Context:
"

becomes

"
For a given MRP application and MAP Context (10.3.1), and for the set of
 Ports that are in a Forwarding state as defined by that MAP Context, and
 for the set of attributes associated with that MAP Context:
"

Impact on existing networks

Any existing implementations which interpret 10.3 strictly in this sense will likely already have interoperability issues. Most existing devices likely have implemented it as is implied, however. So the proposed change would likely be only one of modifying the language to more closely match the intention (and existing implementations).

Originator

Name:	Aaron Stewart, Bob Noseworthy	Email:	astewart@iol.unh.edu; ren@iol.unh.edu
Affiliation:	University of New Hamsphire's InterOperability Lab
Submitted:	2012-08-23