[rbridge] (no subject)

[Margaret Wasserman]

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 
domains?

(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 
extensions?

(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 
IEEE work?

Thanks,
Margaret