2.3.23 Transparent Interconnection of Lots of Links (trill)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-07


Erik Nordmark <erik.nordmark@sun.com>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: rbridge@postel.org
To Subscribe: http://www.postel.org/mailman/listinfo/rbridge
Archive: http://www.postel.org/pipermail/rbridge

Description of Working Group:

While IEEE 802 bridges are attractive due to not needing explicit
configuration and allowing hosts to move within the bridged topology,
they are more limited than IP routers since bridges only support IEEE
802 technologies, and the most common layer 2 interconnection method
(dynamically created spanning tree formation using bridges) is not as
flexible and robust as layer 3 routing.

The WG will design a hybrid solution that combines the simplicity of
configuration while taking full advantage of complex topologies.

The design should have the following properties:
- zero configuration of the hybrid devices
- ability for hosts to move without changing their IP address
- it should be possible to forward packets using pair-wise shortest
  paths, and exploit the redundant paths through the network for
  increased aggregate bandwidth
- possible optimizations for ARP and Neighbor Discovery packets
  (potentially avoid flooding all the time)
- support Secure Neighbor Discovery
- the packet header should have a hop count for robustness in the
  presence of temporary routing loops
- nodes should be able to have multiple attachments to the network
- no delay when a new node is attached to the network
- multicast should work (and after a re-charter it might make sense to
  look at optimizations for IP multicast)
- be no less secure than existing bridges (and explore whether the
  protocol can make "L2 address theft" harder or easier to detect)

A required piece of the solution is an IP routing protocol which is
extended to carry L2 address reachability, handle broadcast, and is
friendly to zero-configuration. Likely candidate are the link-state
routing protocols since they can easily be extended to provide for
broadcast, which is believed to be difficult for distance vector

This working group will define the requirements on such routing
protocol(s), and select the routing protocol(s) to be used. The intent
is that the actual extensions to the routing protocol(s) be performed
in the WGs with expertise in the routing protocol(s).

The working group will look into solutions that can interconnect
different layer 2 technologies, and also look at providing support for
non-IP protocols, even though one can not combine those two features
together; the interconnection of different layer 2 technologies (with
different layer 2 address formats) will most likely only work for the
IP family of protocols.

Whether the same or different address formats are used, there might be
a need to handle different MTUs.

The WG will design a protocol that combines the benefits of bridges
and routers in a way that will co-exist with existing hosts, IP routers
and bridges. The design must support both IPv4 and IPv6

The working group will not work any layer 3 aspects except to provide
- Possible optimizations for ARP and ND packets (not always flooded
- Being able to carry IP broadcast and multicast packets (which might
  just fall out from supporting L2 multicast)
- Defining the L3 operations needed to interconnect different L2

The work consists of several, separable pieces:
- Defining the requirement on the routing protocol(s), and select one
  or more routing protocols. The detailed specification of the
  extensions to a particular routing protocol will be left as an
  action item for the specific routing protocol WG.
- Defining what information must be carried in an encapsulation header
  for data packets, and how to map that information to various link
  types (e.g., IEEE LAN, Fibrechannel, MPLS)
- Defining how address resolution (ARP and Neighbor Discovery) is
  performed, taking into account the desire to be compatible with
  Secure Neighbor Discovery.
- Defining how the solution extends to the case when multiple layer 2
  technologies, that have different address format/length, are

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

BoF Chair Erik Nordmark <erik.nordmark@sun.com>

1. Welcome and Administrivia, Erik Nordmark

Scribe: Donald Eastlake, ...

2. Problem statement discussion, Erik Nordmark

Including the "service" that a cloud of hybrid devices will provide, whether it is equivalent to IEEE 802.1D devices, or handles IP packets differently.
When is it ok to reorder packets? MTU considerations?

L2 solutions have many benefits. Will use IEEE 802 networks as an example but can apply to Fibrechannel, MPLS, etc.
We also have L3 technology which may provide benefits in terms of robustness, etc.
There is a desire to combine the above to create best of both worlds for a LAN (where a LAN is approximately a broadcast domain). Motivations: better robustness, better aggregate bandwidth than L2 bridges, better latency, user of shortest path, ability to interconnect different L2 types?, bigger LANs?

zero configuration,
hosts can move without changing IP address,
use best pair-wise paths and be able to load split,
maybe optimise ARP / ND (don't always flood), secure ND,
hop count to reduce damage from loops,
multiple external attachment point support,
no delay for new host attachment,
support for multicast,
to be no less secure than existing bridges,
no changes to hosts, routers, or L2 bridges,
support non-IP protocols,
handle IPv4&6,
maybe interconnect different L2 technologies.
There are lots of questions about mobility, which goals are high level, etc.
LAN Service is:
broadcast domain,
small probability of reordering and duplication (basically only when topology changes),
MTU (most LANs have uniform MTUs).
Question of fitting L2 info into current size caches...
Q: What about wireless?
Nordmark: TRILL is independent of whether links are wireless.
Which LAN service does IP need?
Some special cases for IPv4/IPv6 ARP may improve service but perhaps it is better if ARP doesn't need special treatment.

3. Threats and security considerations, Marcelo Bagnulo.

Security goals: minimum is same as current bridges.
New features may enable usage beyond the capabilities of classic bridges.
Examples of attacks presented for bridges and Rbridges.
Q: Does this security analysis take into account all of the ongoing and proposed security and QoS work in IEEE 802.1?
Nordmark: No.
Q: Why are we considering these details presuming a solution?
Nordmark: It is good to start considering security from the beginning.
Mark Townsley: This is a little deep for this stage although some good things came out of it. Let's move on.

4. ARP/ND and Broadcast/Multicast Issues

Joe Touch and Yu-Shun Wang (presented by Yu-Shun Wang as Joe Touch had a conflict)
Various questions of exact size of network, what a campus means, what a bridge is, what the goals are, ... DAD ... DNA ... Real networks all have VLANs.
Q: How can you detect a device if it's moving and not connected and someone takes its MAC address?
Wang: Not worried about MAC addresses, I was talking about IPv4/6 addresses.
Q: Are you trying to solve duplicate MAC address problem?
Wang: No.

5. Requirements on routing protocols, Alex Zinin, zinin@psg.com

Alex presented considerable material on scalability functions for different types of overhead.
Paul Congdon: Do you consider dynamic VLAN formation in the core?
Zinin: No, only static VLAN in my analysis so far.
Margaret Wasserman: Do you have a comparison with RSTP?
Zinin: Not in this presentation.
Reachability is less volatile than activity.
Advantages of reachability. "CNLS(?)" announces all hosts and works.
The built in protocol limits on update rates are not enough to assure stability.
Recommend using a single routing instance over all VLANs but restricted flooding of information only to nodes that need that information.
Q: Are you assuming station number scales with VLANs?
A: No, but there are typically more stations in systems with many VLANs.

6. TRILL issue: VLANs, Radia Perlman

Presented a modified design, where the "egress RBridge" is included in the
header (between the outer header, which bridges would see, and the inner
frame which is exactly as transmitted by the endnode). Forwarding is to the
egress RBridge.
This enables the core to forward solely based on egress RBridge, and not need
to have endnode addresses in forwarding tables. It also means that only
RBridges attached to a particular VLAN need to know about the endnodes in
that VLAN.

Margaret Wasserman: Would Rbridge flooding zones be IP subnets?
Radia Perlman: No. [Later Radia posted an email saying that different Rbridge VLANs would be separate IP subnets.]
Wasserman: What would happen with mobility?
Perlman: You can keep same IP if you move.
Comment: All this should be compared with what's in 802.1, 802.1ah, MAC in MAC encapsulation, etc.
Q: GVRPN MAC tunnelling... Is there parallel work in L2VPN?
Daly: Reminds me of similar aspects of RFC 2357(?) Like MPLS.
Q: What is the scope? Looks like BGPv3, ..., in same enterprise.
Nordmark: This is not being proposed for the Internet backbone.
Q: Is there a conflict with L2VPN? Both seem to be used for aggregation.

7. Connecting different L2 types, Radia Perlman

Forwarding between different link types works for IP but probably too hard in general for incompatible link types. This presentation of mine is to try to convince people NOT to include Rbridging different types of links in the scope of the proposed WG.
Comments: All comments made opposed doing this between different types of links.

8. Discussion

Nordmark: The intended network scope where this would be applied is not "provider" but "local".
Comment: "Provider" is not the same as "wide area".
Comment: We should figure out what has been done elsewhere.
Nordmark: I've been looking for that. No one else is doing shortest path.
Comment: Big overlap with L2VPN. VPLS area in L2VPN. Shortest path for unicast. GMPLS. Issues with packet re-ordering and MAC address. The alternative of encapsulating in IP header means you can then just use IP on intermediate nodes so only edge devices need to learn MAC addresses.
Nordmark: But IP does not autoconfigure.
Paul Congdon: There seems to be more awareness of what 802.1 is doing. Original list of goals included shortest path. That is not addressed by IEEE 802.1 but I think the other goals are addressed by 802.1.
Nordmark: Link state with limited flooding would solve scalability. That technique might also fit into L2VPN.
Bob Hinden: Haven't heard clear case as to why this is better than alternatives.
Nordmark: shortest path, nothing else provides it.
Hinden: You can do a lot of things with routers, can you do something better with them?
Nordmark: We've tried that with the ZROUTER BoF. I was there. But you still have to change address when you move.
Hinden to Radia: Why didn't you invent this when you invented STP (the spanning tree protocol)?
Radia Perlman: I wasn't provided with the whole problem, just told to develop a spanning protocol. At that point in time they would never have considered adding an encapsulation header. It would have made the devices too complex, and there were hard limits on frame sizes.
Zinin: Big difference between this and L2VPN is that L2VPN uses IP while this defines forwarding and routing in L2. X does solve the problem with state in core devices but that's not the problem. Critical problem is edge bridge problem. Would rather try to solve problem with IP.
Nordmark: We tried that and gave up.
Margaret Wasserman: How many in the room are on the rbridge mailing list and read it? (Many hand go up.)
Wasserman: How many have support from their management to work on this? Quite a few indicate they do.)
Wasserman: Three choice poll:
(1) ready to work on this,
(2) interesting think but we need to look further,
(3) no work should be done on this in the IETF.
(1) ~10.
(2) Many
(3) ~12.
Wasserman: The rough consensus is to look into this further.


TRILL problem statement, service and architecture
Threat analysis for routing-bridges
ARP/ND and Broadcast/multicast Issues
TRILL Routing Scalability Considerations
TRILL issue: VLANs
TRILL issue: Mixed links