+---------------------------------------------------------------------+
| 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.7.2, 11.2.1.3
     CLAUSE TITLE: Registrar Administrative Controls, Use of the PVID and VID Set


RATIONALE FOR REVISION:

The propagation of statically set VLANs is implied, but no mechanism 
is defined to actually propagate such information. 

Specifically, simply being in the "IN" state of the Registrar state 
machine does not trigger an indication to the MVRP Application.

Clause 11.2.1.3 states:

The initial state of the Permanent Database contains a Static VLAN 
Registration Entry for the Default PVID, in which the Port Map indicates 
Registration Fixed on all Ports. This ensures that in the default state, 
where the value of every PVID of each Port is the Default PVID and where
the VID Set of each Port is empty, membership of the Default PVID is 
propagated across the Bridged Local Area Network to all other MVRPaware
devices.

Clause 10.7.2 first paragraph states:
 
Associated with each instance of the Registrar state machines are 
Registrar Administrative Control parameters. These parameters allow
administrative control to be exercised over the registration state 
of each Attribute value, and hence, via the propagation mechanism 
provided by MAP, allow control to be exercised over the propagation 
of declarations.

Clause 10.7.2 third paragraph states:

If the value of this parameter is Registration Fixed or 
Registration Forbidden, In and JoinIn messages are
sent rather than Empty or JoinEmpty messages.


The Registrar state machine (Table 10-4) does not trigger an 
indication to the MRP Application simply by the state of the attribute, 
but rather through the MAD_Join.indication and MAD_Leave.indications, 
which occurs only when 'New', 'Join' or 'Lv' protocol actions occur 
(10.7.6.12-14 respectively)


PROPOSED REVISION TEXT:

(text surrounded by '' marks denotes italics) 
Replace the last paragraph of 10.7.2 which was: 

If the value of this parameter is 'Registration Fixed' or 
'Registration Forbidden', In and JoinIn messages are
sent rather than Empty or JoinEmpty messages.

Replace with: 

When an Attribute value is first set to 'Registration Fixed', a 
MAD_Join.indication primitive is issued to the MAD Service User, 
indicating the Attribute instance. When an Attribute value is first set to 
'Registration Forbidden', a MAD_Leave.indication primitive is issued to the 
MAD Service User, indicating the Attribute instance.  When an Attribute value 
is set back to 'Normal Registration', the associated Registrar and Applicant 
state machines act as though a rLv! (10.7.5.17) occurred.

If the value of this parameter is 'Registration Fixed' or 
'Registration Forbidden', In and JoinIn messages are
sent rather than Empty or JoinEmpty messages.

(OR ? Replace this last paragraph with the following?
If the value of this parameter is 'Registration Fixed', In and JoinIn messages
are sent.  If the value of this parameter is 'Registration Forbidden', Empty 
or JoinEmpty messages are sent.
)


IMPACT ON EXISTING NETWORKS:

Current behavior for Registration Fixed or Registration Forbidden is not 
completely specified, hence some existing implementations may not propagate
information that is statically sent, and others may not rapidly indicate
MAD_Join or MAD_Leave as proposed in this remedy. 

+---------------------------------------------------------------------+
| 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                                |             |
|            +------------------------------------------+             |
+---------------------------------------------------------------------+