2002Oct03 16:46 RPR meeting
Comments on Marc Hollness bridging comments.

1) The type field has been moved to the payload, which I prefer
   but this has been voted down by the working group.
2) The broadcast stationID has been defined as 0xFFFF, although
   this is a 48-bit value. This also seems to outlaw bidirectional
   flooding, which is inconsistent with other portions of the
   writeup.
3) The processing of a multicast frame has not been specified.
   This should be clearly identified as a remote-address format,
   where the multicast address is included in the payload.
4) This proposal requires that the timeToLive be different on
   a frame-type basis. A preferred proposal would be to always
   start the timeToLive at 255, and used timeToLive base to
   determine how long the frame should live, because:
   a) Everything is processed in the same way.
   b) TTL=>0 can then be uniformly interpreted as a error.
5) This proposal doesn't decrement timeToLive on the return path,
   which is inconsistent in that this could live indefinitely
   when placed on the wrong ring. (there is no topology-dependent
   discards currently defined).
6) Bidirectional1. Don't make this excessively complex.
   One should be allowed to send to both sides of the same station,
   which avoids possible concerns with adjacent-neighbor consistency
   in the decisions. It also reduces the implementation costs.
7) Unidirectional2. Don't make one consume 2x bandwidth on a
   two-station topology. Since one has to handle bidirectional
   or limited steered/protection anyway, this should be allowed.
8) There is a far less destructive mechanism of removing duplicates
   when protection occurs. One can simply discard frames that come
   from beyond the end-point, as measured in hops.
9) Page #64 number (3), there is a statement of discarding wrong-ringlet
   stuff after a restoration event. However, a restoration event is not
   easily defined and/or observed, and may not be reliably observed.
   This needs better definition. Also, holding off of the restoration
   event is a preferred solution, as this solves the problem without
   loss.
10) Page #68. Solution: Pass-thru is illegal.
   1) This is a significant restriction, which is beyond the scope
      our control, since it can happen anyway and has been requested
      by a NAVY proposal. Also, pass-thru improves robustness, which
      is a key value for RPR.
   2) This frame deletion rules support this function anyway, so the
      comment is irrelevant.
11) Page #68. The proposed solution is too expensive, as the requirement
   for supporting "(TTL_Base-TTL)!=hops[SA]" is too expensive and
   requires a 256-entry fully associated miniCAM. This type of
   proposal was rejected in Vancouver, due to its cost, complexity,
   and impact on current designs.
12) Page #68. This expensive solution should not be required for
   steering-only stations. However, the optionality of this for
   steering-only stations is not well documented.
13) Page #59. The extended-frame bit is unacceptable. This would
   make all existing formats incompatible, since they would assume
   the header-HEC (and/or FCS) is located at a different place.  


DVJ 2002Oct03