PS issues	   J. Touch	12-08-2005 4:07pm

If you want to discuss an issue, please post a note with the following
subject (e.g.):

	PS issue #3

That'll help us track things until (and if) we use a proper issues tracker.

PLEASE POST ANY ISSUES MISSED as "PS issue NEW" 
Joe T. will assign numbers to them and post the master list at
www.postel.org/rbridge

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

#1 which version of ethernet is the baseline?
   STP, RSTP, VLAN, provider bridges, wireless,
   shortest path bridging, etc.
   (this will help us determine what terminology to use)

#2 should the solution apply to current ethernet scales or not?
   and if so, what are current ethernet scales?
   Harald proposed as a starting point:
   * 1000 end-hosts in a single bridged LAN of 100 bridges
   * 100.000 end-hosts inside 1000 VLANs served by 10.000 bridges

#3 IF size is an issue...
   what limits the size? STP/RSTP or broadcast traffic, or both?

#4 delivery requirements:
   a) is in-order required?
   b) is no-duplication required?

#6 address MSTP regions (esp sec 2.2)
   as a way to limit STP scale/reconfiguration
   IEEE 802.1Q  Multiple Spanning Tree Protocol. 
   Tutorial available : "Understanding Multiple Spanning Tree Protocol" 
   at www.cisco.com

#7 differentiate between host reattachment effects
   and bridge reattachment effects; the latter impact the STP more

#8 discuss broadcast vs. subnet broadcast vs. multicast support
   who gets a copy of multicast? all ports, or just subscribed?

#9 which addresses are not forwarded? (related to ARCH #1)
   Bridge Group Address 01-80-C2-00-00-00, 
   used for frames transporting BPDUs
   Pause Frame address 01-80-C2-00-00-01.
   ?addresses 01-80-C2-00-00-00 to 01-80-C2-00-00-0F

#10 use campus (seemed to be agreement at the meeting)
    or use "pool" or "set"

#11 internal/external, inside/outside terminology
CLOSED - moved to ARCH issues 12/08/2005

#12 address VLAN configuration requirements

#13 need configuration time examples
    e.g. references to published research and a summary that shows how
    small changes can have large effects

#14 add risks of TRANSPARENT (larger trees, slower to converge, etc.)

#15 sec 2.3 should be more clear about referring to computing backups to 
    use in case of failure - not that extra links makes routing easier.

#16 clarify difference between ARP replay (a desired performance optimization)
    and Proxy ARP (not desired)
	(this was agreed on the mailing list)

--- end.