Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] 802.17 Follow On Projects - Results of 7/22 Ad Hoc Meeting




Bob,

The process of figuring out what the next set of addition to
dot17 must be rationalized with two crucial issues.

First, additions/enhancements must be such that these are not major
modifications to the current draft proposal. A.k.a., this should
not be a Trojan horse to bring back ideas that failed to gain traction
during the process of putting together the current draft. So, having
*a* champion is less desirable than having a large group of companies
coalesce behind a few of these based on the business and market place
potential. This requires the champions to work together in putting
the collective reasoning and justification for the next phase by
getting wide spread support. As suggested by you the one pager may
be a singular view for now.

Second, I suggest that we limit the number of concurrent threads moving
forward to avoid infant mortality of ideas and negative press. This may 
require us to focus on one or two distinct set of ideas. Also, given 
the diminishing membership in the working group, this will assure a 
diverse and well represented working group.

Thanks for taking the leadership in getting things started for the next
phase.

raj

> -----Original Message-----
> From: Robert Love [mailto:rd_love@xxxxxxxxxxx]
> Sent: Tuesday, July 22, 2003 7:30 PM
> To: stds-802-17@xxxxxxxx
> Subject: [RPRWG] 802.17 Follow On Projects - Results of 7/22 Ad Hoc
> Meeting
> 
> 
> 
> All,
> We have just finished our Ad Hoc meeting to determine what 
> the potential 
> follow-on projects may be.  The session began with 
> brainstorming for ideas, 
> followed by a vote of those that were strongly in support of 
> or strongly 
> against the ideas(First number is FOR, second number is 
> AGAINST).  The 
> following list is the result of the brain-storming session 
> and the voting:  
> Where there is a name next to an item it means that person 
> has volunteered 
> to "champion" it and will bring a one or two slide 
> presentation to the WG on 
> Thursday, outlining what the project should include and why 
> we should do it. 
>   Ideas without champions cannot progress.  Note that some of 
> the ideas will 
> be combined by the "champion" for presentation on Thursday.
> 
> The objective of this exercise is to initiate one or more 
> study groups that 
> will run from the close of this meeting until the close of 
> the November 
> plenary.
> 
> If anyone reading this note wants to champion any of the 
> ideas not presently 
> supported, they are requested to develop a short (one or two 
> slides, or more 
> if desired) presentation, fleshing out the idea and 
> supporting it.  They 
> will then have the opportunity to make their presentation to 
> the working 
> group on Thursday.
> 
> Best regards.
> 
> Robert D. Love
> rdlove@xxxxxxxx
> 
> 
> 1.	Mixed speeds on one ring		14	1	Nader
> 2.	Different PHY layers			10	0
> 3.	Trunking (Link Aggregation	7	1
> 4.	Enhanced bridging			7	1
> 5.	Enhanced OAM Support - 			8	2 Leon
> 6.	RPR on a single ringlet			7	1
> 7.	Incorporate ideas from X.msr into RPR	5	1
> 8.	Wireless PHY for RPR 	9	2
> 9.	Hetrogeneous rings (not limited to speed change alone)	
> 8	5	Nader (tied to 
> Mixed Speeds on one ring)
> 10.	Smooth migration for increased bandwidth	7	1
> 11.	Virtual RPR Rings 	5	2
> 12.	Pure Class Based transit path (more than 2 queues)	
> 7	5
> 13.	N+ ringlets, N not necessarily even.	6	6
> 14.	Simplified RPR		6	4
> 15.	Alternative Fairness schemes	9	7 Li Mo
> 16.	Fractional protection	6	3
> 17.	Multicast Spatial Reuse	4	4
> 18.	Spatial Aware Classes A and B allocations	8	
> 6 David James (Including 
> Alternative Fairness Schemes, Spatially aware source destination and 
> multi-choke support in the MAC
> 19.	*Spatially aware or source destination based fairness 5	7
> 20.	Increased number of stations per ring.	3	9
> 21.	*Resilient Packet Networks (Topologies not limited to 
> rings)		3	6
> 22.	Lossy MAC 	3	7
> 23.	Protection mixed protection technique.	3	7
> 24.	Security		4	7
> 25.	*Multi-Choke support in the MAC		3	4
> 26.	Multi Choke Support in the MAC Client	1	6
> 27.	*Link Protection		3	4
> 28.	Adaptive MAC Layer for different communication data	
> 1	7
> 
> 
> * The ideas with asterics were ones that had poor support, 
> but at least one 
> person that strongly believed we should move forward with them.
> 
> _________________________________________________________________
> Add photos to your messages with MSN 8. Get 2 months FREE*.  
> http://join.msn.com/?page=features/featuredemail
> 
>