[RPRWG] Concensus on 802.17b Multi-cast issues

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

RPRWGers, 

I have received enough vote modifications from
the WG members balloting the 802.17b D1.2 Multicast 
ballot and declare a concensus position.

The xls file with people's votes have been uploaded to

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

and I request that if anyone believes I have misinterpreted
or mis-transcribed their vote to contact me and we will 
review the ballot concensus.

My interpretation of the final result of this ballot is that
a table will be configured with multicast addresses, their scope
as well as an flag for whether a frame should be sent with
the SAS multicast address (so it gets learned) or not.

See you all in denver!

cheers,

mike

---------------------------------------------------------
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 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} is acceptable to 75% and is accepted.

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

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

Two voters changed their decision on c), one switching away from
c) and one switching to c). 

Option C continued to receive 81% approval 

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 b) has increased its support to 81% with 1 negative 
vote. Therefore option b) is selected.

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

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