+---------------------------------------------------------------------+
| IEEE 802.1 REVISION REQUEST XXXX                                    |
+------------------===================================----------------+

DATE: July 6, 2012
NAME: Aaron Stewart, Bob Noseworthy
COMPANY/AFFILIATION: University of New Hamsphire's InterOperability Lab with support from the AVnu Alliance
E-MAIL: astewart@iol.unh.edu; ren@iol.unh.edu


REQUESTED REVISION:
     STANDARD: 802.1Q-2011
     CLAUSE NUMBER: 10.3(a)
     CLAUSE TITLE: MRP Attribute Propagation


RATIONALE FOR REVISION:

10.3(a) states:

Any MAD_Join.indication, or any MAD_Join.request issued by the MRP 
application, received by MAP from a given Port in the set is propagated as a 
MAD_Join.request to the instance(s) of MAD associated with each other Port in 
the set. If the value of tcDetected (13.23) for the Port and MAP Context is 
nonzero, then the value of the new parameter in the propagated MAD_Join.request 
is set TRUE, regardless of the value of this parameter in the indication or 
request that is being propagated.


The existing text is unclear as to which "Port" is referenced in the statement 
above "If the value of tcDetected for the Port..." as it could refer to either:
"received by MAP from a given Port" (the ingress Port)
 or 
"each other Port" (egress Ports)
in the preceding text of 10.3(a).


It has been suggested that the Port refers to other Port (the egress port). 

However, if it refers to the ingress port, it would seem to be more consonant 
with the purpose of 'new'.
Specifically:
If a bridge has some attribute registered on a port, and that bridge is 
connected to another bridge, when the ports begin forwarding, 10.3.d is 
invoked, causing the newly-forwarding port to transmit a declaration
If  the Port is the egress port, the declaration will not be signaled as a 
new declaration (10.3.d says nothing about propagating as new). However, if 
the Port is the ingress port, the neighboring bridge would propagate a 
received JoinMt or JoinIn as New, thus informing the bridged LAN of the 
topology change


PROPOSED REVISION TEXT:

Clarify the text of 10.3(a) as follows (add "given" before third occurance 
of the word 'Port'):


Any MAD_Join.indication, or any MAD_Join.request issued by the MRP 
application, received by MAP from a given Port in the set is propagated as a 
MAD_Join.request to the instance(s) of MAD associated with each other Port in 
the set. If the value of tcDetected (13.23) for the given Port and MAP 
Context is nonzero, then the value of the new parameter in the propagated 
MAD_Join.request is set TRUE, regardless of the value of this parameter in 
the indication or request that is being propagated.



IMPACT ON EXISTING NETWORKS:

This clarification will assist in the proper attribute propagation in a 
bridged environment following a topology change.

+---------------------------------------------------------------------+
| Please attach supporting material, if any                           |
| Submit to:- Tony Jeffree, Chair IEEE 802.1                          |
|  and copy:- Paul Congdon, Vice-Chair IEEE 802.1                     |
|    E-Mail: stds-802-1-maint-req@ieee.org                            |
|                                                                     |
|            +------- For official 802.1 use -----------+             |
|            | REV REQ NUMBER:                          |             |
|            | DATE RECEIVED:                           |             |
|            | EDITORIAL/TECHNICAL                      |             |
|            | ACCEPTED/DENIED                          |             |
|            | BALLOT REQ'D YES/NO                      |             |
|            | Status: X                                |             |
|            +------------------------------------------+             |
+---------------------------------------------------------------------+