Re: [RPRWG] .17 b multicast learning simplification

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

Gary,

I checked the results file and on Q4 a) and b) 
were unacceptable to 6 people. I am not sure where
you got your numbers and I apologize if I make a publishing
or communications mistake.

That being said, it's a good question to ask
and see what people think.

Given that we are close to consensus on Q4 and Q6
my preference is still to try to close on those.

If one considered the normal down-select process used
in other groups, the other results would fall off
the table in preference to the selections that have
the most support.

I continue to talk to people to see if there are people
willing to switch their votes in the interest of 
achieving concesus. I hope to get this done this
week so that next week we can close in Denver.

If we don't close by then, you have given us a good
thing to start thinking about.

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 

> -----Original Message-----
> From: Turner, Gary (Gary) [mailto:gturner@LUCENT.COM] 
> Sent: Monday, February 27, 2006 11:37 AM
> To: STDS-802-17@listserv.ieee.org
> Subject: [RPRWG] .17 b multicast learning simplification
> 
> RPRWG,
> 
> We haven't yet reached consensus over the variety of methods 
> proposed for controlling whether or when multicast frames 
> should be learnable.
> 
> It seems to me the whole thing has become a lot more complex 
> than it needs to be for standardization.
> 
> I also noticed that the poll shows that for Q4 (whether MC 
> frames should be learnable) only two thought both a) and b) 
> were unacceptable. That could mean that another choice,
> "a) or b)," meaning the SAS transmit could be set to either 
> always enable learning, or never, might be acceptable.
> 
> This simplification makes sense to me. The other options, 
> controlling frame by frame either by client control or a bit 
> in the MC address table, or both, are enhancements that 
> vendors can implement for added-value differentiation. They 
> are good candidates for that because they don't require 
> special action from other nodes to interwork. 
> 
> So I would like to propose Q4 choice d) = "a) or b)" as a 
> compromise that will help get .17b done and maybe help 
> alleviate the perception of excess complexity in the standard. 
> 
> Comments?
> 
> Gary
>