[rbridge] (no subject)
margaret at thingmagic.com
Thu Apr 28 07:20:48 PDT 2005
As most of you probably know, the IESG has been talking about
chartering a TRILL WG. There were some issues raised in response to
the initial charter announcement that we are working through, but in
the meantime, it would be great to continue the technical discussions
on this list and to document the results of our discussions, either
in a separate framework/architecture document and/or in an updated
version of the rbridge proposal.
I, personally, have a number of technical questions about TRILL. I
think it would be helpful to discuss and answer these questions
within the TRILL group:
(1) Is it (or is it not) a requirement/goal for the TRILL protocol to
be compatible with existing bridge/switch HW? There are some folks
who would like to see TRILL defined in a way that would allow it to
be implemented as a SW upgrade to existing bridges/switches, but that
has implication for the protocol itself -- in particular,
decrementing a TTL or making any header changes on through traffic
would preclude this.
(2) How will TRILL be compatible with existing (dynamic and
non-dynamic) VLANs? There are really a few questions here:
(a) Is TRILL expected to run entirely under, and be invisible to,
existing IEEE 802 VLANs (as a replacement for (R)STP, but not for
VLAN)? If so, how does TRILL address (or even pertain) to the subnet
limitations of current VLANs? Eliminating this limit was discussed
in Radia's talk on the benefits of TRILL, but maybe our thinking has
evolved to the point where that no longer applies?
(b) If it doesn't run entirely under existing IEEE 802 VLANs, how
does TRILL handle IP subnetting and limitation of broadcast/multicast
(c) If TRILL does run under existing IEEE 802 VLANs, is there any
means to avoid unnecessary duplication of broadcast/multicast traffic
across TRILL-connected "links". Is avoiding this traffic necessary
for the protocol? Or merely a nice-to-have?
(d) How will TRILL interoperate with dynamic VLANs? In particular,
how will TRILL work with dynamic VLANs when hosts move from one part
of a wireless network to another? Today, those hosts retain their IP
addresses and current connections by being detected at a new location
and attached to a dynamic VLAN in that location. Will this work over
TRILL-connected links? What will be the impact (if any) on the time
it takes to establish bridging to the new location? (I'm not sure
that there are any issues here, I just don't understand enough about
how dynamic VLANs work (yet) to know if there are any).
(3) What (types of) mechanisms are needed for end station discovery?
There was a discussion on this on the list in early March, with the
apparent conclusion that we could use link-state for discovery of
directly connected nodes, but might need other mechanisms (probing?)
for detection of hosts connected via a hub or non-TRILL-aware bridge.
What mechanisms would be needed? And what are the impacts of these
mechanisms on network traffic, route thrashing, etc.
(4) Which properties (if any) of the Ethernet service model may be
compromised or modified by TRILL. The Ethernet service model
includes properties such as in-order delivery of packets, no packet
duplication and timing limits (among other things? Bernard, is there
a definitive reference for this?). What changes for TRILL-connected
links? And, what effect would those changes have on protocols that
may depend on the existing Ethernet service model (such as (R)STP,
VLANs, ARP, ND, SEND, EAP methods, DNA...)?
(5) Will a new (or substantially modified) routing paradigm be
required to do scalable Ethernet routing? Or can this be
accomplished with current routing protocols, perhaps with limited
(6) How does this work relate to the new work in the IEEE on the
Shortest Path Bridging PAR? This is a proposal in the IEEE to use an
STP-based (or STP-like?) distance-vector-based protocol to allow for
shortest path bridging. Given the existence of this work in the
IEEE, is TRILL still needed? If so, why? What properties (if any)
does TRILL bring that make it worth doing in addition to the planned
More information about the rbridge