Subject: [rbridge] (no subject)

From: margaret at thingmagic.com (Margaret Wasserman)
Date: Thu, 28 Apr 2005 10:20:48 -0400

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 28 Apr 2005 08:14:49 -0700

> decrementing a TTL or making any header changes on through traffic 

An update to the rbridge I-D will be available very shortly; Radia,
Alper, and I have been doing last-minute checks on it this week.

The protocol does not modify the incoming packet - L2 or L3. It thus
supports incremental deployment and upgrade, though benefit of those
upgrades depends on linking the upgraded systems together as a 'campus'.
 The way a campus works may limit which upgraded systems can be linked
together - i.e., it *may* limit non-upgraded bridges to connect to only
one campus bridge, etc. So such upgrades may have impact only after
enough of a topology is available to make an appropriate campus.

I'm not as familiar with VLAN issues as Radia is, so she might speak to
these issues:

> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050428/26196ba5/signature.bin

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri, 29 Apr 2005 18:01:36 -0700

> decrementing a TTL or making any header changes on through traffic 

My personal take is that there are some key properties of TRILL that 
we'd want to preserve:
  - using a link state routing protocol
  - using encapsulation to carry packets between the trill devices
  - including a TTL in the encapsulation header as a "safety" should
    there be temporary routing loops

For instance, it would not make sense to me to change the TRILL approach 
to not have a ttl even if this provided a way to reuse some hardware, 
because it would change some rather fundamental architectural properties 
of TRILL.

Thus for somebody to build a trill device they'd need hardware that can 
insert and remove the encapsulation header and decrement ttl.

But if there are other issues that relate to hardware capability or 
ease, such as details of the encapsulation header (alignment, order of 
fields, etc), I suspect there is a lot of flexibility.

> mechanisms on network traffic, route thrashing, etc.

I guess there are two related issues here. One is the protocol mechanism 
used to do station discovery, and the other is the degree of churn 
caused by this mechanism and whether or not this requires special 
considerations to avoid scaling issues.

In terms of the protocol mechanism, TRILL would need to support stations 
behind bridges, in which case it can't do much better than the existing 
bridge learning techniques (look at the source L2 address of received 
packets). But in such a case it might make sense to use holddown 
techniques to not cause routing updates due to station inactivity, yet 
be able to react quickly when the station moves to another rbridge.

For other types of attachments, for instance 802.11 or other protocols 
with a notion of associations, there is the option to integrate the 
rbridge functionality in the access point. In such a case the 
propagation of the L2 address into the rbridge routing can be driven 
directly by the host completing the association with the AP. This would 
offer a slight improvement over the AP/bridge interaction today, where 
the host has to send a broadcast packet to cause the bridges in the 
network to be updated with its new location.

I guess it is too early to understand the performance tradeoffs between 
the different possible approaches for how the information is learned, 
how it is timed out or updated, and when this information is added and 
removed from the trill routing information.

> VLANs, ARP, ND, SEND, EAP methods, DNA...)?

For the rest of the list: The IESG and IEEE 802 had some discussions 
about this and the notes are at 
<http://www.drizzle.com/~aboba/IEEE/minutes0408.txt>

My take is that TRILL needs to document the service mode it provides.

My understanding is that IEEE 802.1 changed the service model when they 
developed RSTP, so that packet reordering and duplication is acceptable 
when there is a topology change (i.e., some bridge, port or link failing 
or being brought up).

AFAIK one has to pay to access the IEEE 802.1 standards documents, and 
googling for the relevant terms seem to find mostly things about some 
TRILL BoF :-)

> accomplished with current routing protocols, perhaps with limited 

I'll let Radia answer this one.

> does TRILL bring that make it worth doing in addition to the planned 

For those that haven't see the new PAR, it is at
<http://www.ieee802.org/1/files/public/docs2005/new-seaman-shortest-path-0305-02.pdf>

I'd be interested in what other folks think of the relationship between 
this proposed work in IEEE 802.1 and the TRILL work.

 From a quick look, the PAR doesn't seem to address the 
zero-configuration goal we've talked about for TRILL. The shortest path 
bridges need to be configured with the VLAN ID they use for their 
"personal" shortest path tree.

The fact that the PAR overloads the VLAN ID as an identifier for each 
shortest path tree, seems to mean that the product of the number of 
VLANs and the number of (shortest path) bridges might be limited to a 
total of 4096. Thus if somebody is currently using 1024 VLANs, they can 
only have 4 shortest path bridges, which seems very limiting. This seems 
quite counter to the requests we had from Alex Zinin to think about 
scalability to reasonably large networks in the context of TRILL.

    Erik

---

From: Cheng-Yin.Lee at alcatel.com (Cheng-Yin Lee)
Date: Sat, 30 Apr 2005 01:04:03 -0400

Margaret,

> does TRILL bring that make it worth doing in addition to the planned

My personal opinion is Shortest Path Bridging and TRILL will serve different
types of networks and markets.

My understanding of Shortest Path Bridging is that it is effectively like
distance vector [ although it assumes the same costs from source/root of tree
to destination and in the reverse path (symmetric routes), otherwise it is
reverse shortest path]. Hence, link state based TRILL should converge faster
in a richly connected, large network in the event of link/router node state
(not considering MAC addresses learning or updating, assuming a more scalable
way will be developed for this) changes.

In any case, if we may use this analogy,  both RIP and link state protocols
(OSPF/IS-IS ) are used today.
Perhaps in future, some networks may use Shortest Path Bridging while others
may use link state based TRILL.

Thanks
Cheng-Yin