[rbridge] Comments to draft Touch- arch-00
gibanez at it.uc3m.es
Wed Nov 9 04:31:53 PST 2005
These are my comments to the second draft (architecture).
- 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.
" 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
- 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
- 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.
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).
add "rbridge" to "...of the egresss"
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.
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.
188.8.131.52 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.
More information about the rbridge