[rbridge] Comments to draft Touch- arch-00

[Guillermo Ibáñez]

Joe,
     These are my comments to the second draft (architecture).
Guillermo

- Structure of document.
    Looks right overall.
    "4.9 External protocols" may be has category enough to be a separate 
section. Name suggested for that section  would be  "Interaction with 
802.D protocols" just to be more precise and avoid the 
"internal/external" terminology dispute.

Abstract
     " RBridges are link layer (L2) devices...
GI> this seems a too simple but "strong" statement. If RBridges were 
(only) L2 link
GI>  layer devices, should not they be standardized by IEEE ?.

2.1 Existing Terminology

- I would recommend as general criteria to align the terminology 
whenever possible with IEEE 802.1D terminology.
   So use STP (and RSTP) for Spanning (and Rapid) Spanning Tree 
Algorithm and Protocol instead of BSTP.
Bridge: as the term can be used sometimes with a very general meaning, 
an specific term for  802.1D bridge is needed. Perhaps SBridge.
- BST: as the newcomers are the rbridges spanning trees, I recommend to 
use explicitely rbridge spanning trees
- Node :  do not use terms "outside" (or inside RBridge campus).

2.2 RBridge Terminology
- Do not use the term campus, better use RBridge set, structure, pool or 
anotherm term.
- CFT: use FT
- CTH: use TH
- CTT: the name is not illustrative, I suggest  Node (or Host) Table
- Designated RBridge:  "... rbridge associated" add "...by the rbridge 
protocol"
- Edge: do not use outside/inside, ingress/eggress traffic instead.
- Inside/ Outside (also Internal/External)
- I agree with E. Nodmark in that it is applicable to traffic entering 
but to apply it  to topological view is confusing.

3.
     RBridge campus: 
3.1
    In conventional bridges the port learning is included and named as 
"filtering" like Filtering Database. Also Filtering ID term is used when 
there are several (multiple VLANs).
3.3
    add "rbridge" to "...of the egresss"

4.9
The term "Internal Spanning Tree" should also be avoided.
I suggest not to use spanning tree term for communication between  
Rbridges and use another term. Some where proposed already (you may add 
"SPF trees" to the proposed) . Besides the  "internal" issue, the  
rbridges spanning trees have only meaning for multicast across VLANs, 
so  only in multicast context should be used. 

4.9.2.1 Transparent-STP

If you look at the figure 2 and assume that rbridges work in 
transparent-STP mode, as hubs for STP BPDUs, all b3, r4, r5, h2, r6, r7, 
b8, r9 will be connected together for the BPDUs, b3 or b8 will be the 
root bridge. This seems to introduce uncontrollability in the network, 
as long as the rbridges behave like hubs, but  they are not (do not 
create real collisions, do not forward external traffic), and they 
create longer spanning trees that  are slower to converge, etc. This has 
been already discussed. At least some comment on the risks of this mode 
should be included.

4.9.2.3 Block STP
    Include the paragraph as agreed with Radia and Eric Gray mentioning  
B-RB-B implementations of rbridges that will allow real rbridges to act 
as prioritary root bridges of the external spanning tree whithout change 
of rbridge functionality.

____________________________