[RPRWG] P802.17b D1.2_Multicast ballot results

["Mike Takefman (tak)" <tak@xxxxxxxxx>]

Dear RPRWGers, 

this ballot is a bit more complicated to summarize but
I will attempt to do so here. I expect that there 
needs to be discussion during the teleconferences
this week and/or before the March session in order
to drive consensus on a few of the issues.

http://www.ieee802.org/17/member/802_17b/d1_2_multi/index.htm

provides the ballot document and will have a summary
file and response comment files later tonight.

In all cases the required return rate and abstain
rate was met. 

Chicago rules voting was allowed for multiple choice
questions and the options with the highest approval
rates are given.

Question 1: 
Bi-directional, balanced flooding (i.e., the 
mlt_flood_01.pdf proposal) should be supported.

Approved 100% and is therefore accepted
---------------------------------------------------------

Question 2:
2)	Bi-directional, balanced flooding should be 
a.	The only form of flooding supported
b.	Turned on only when configured by the user
c.	Communicated around the ring via ATT frames

Option b. received 75% approval and only 2 negative votes 
Option c. had 66% approval and 4 negative votes

Therefore option b is accepted
----------------------------------------------------------

Question 3:
3)	Multicast scoping should have the following 
features. [Note: a, b, and c get a 2-address frame 
from the client (as compared to d).]

a.	Scope basic frames without SAS learning
b.	Scope extended frames without SAS learning
c.	Scope extended frames with SAS learning
d.	Scope client frames with 4 addresses without SAS learning

The set of {a,b,c,d} was acceptable to 45% of voters but had between
2 and 5 negative votes depending on interpretation of results

The set of {a,b,c} or just {c} was acceptable to 36% of voters
but had 2 and 3 negative votes respectively.

Therefore no decision can be taken.
------------------------------------------------------------

Question 4:
4)	Multicast frames should be subject to SAS learning. 
[Note that there was >75% support for option c) at the November 
interim meeting.]
a.	Always
b.	Never
c.	On a frame by frame basis

Option C received 81% approval but 2 negative votes
Option A received 35% approval but 6 negative votes

Therefore Option C is selected.
------------------------------------------------------------------

Question 5:

In considering the client supplied request parameter(s), the 
consensus was that the following 4 ordinal values were acceptable 
for the sas_request variable. This is effectively an encoding of 
two control bits {multicastScope, sasLearn}:
-	OFF, 		(no sasLearn , no multicastScope)
-	UNICAST, 	(yes sasLearn, no multicastScope)
-	MULTICAST, 	(no sasLearn, yes multicastScope)
-	ANY, 		(yes sasLearn, yes multicastScope)


Assuming that client supplied control parameters are accepted, is this
encoding acceptable? 

Approval of 90% with 1 negative vote
-------------------------------------------------------------------

Question 6:

6)	Assuming it is done frame by frame, control over how a 
frame is processed is via:

a.	Client supplied request parameter(s)
b.	Configuration of the Multicast Table
c.	Both, client request takes priority
d.	Both, table takes priority

Option C has 63% support but 3 negative votes
Option B has 45% support but 3 negative votes

Therefore, no decision is taken

--------------------------------------------------------------------

cheers, 

mike

-------------------------------------------

Michael Takefman              tak@cisco.com
Distinguished Engineer,       Cisco Systems
Chair IEEE 802.17 Stds WG
3000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399       cell:613-220-6991