2.3.24 Transparent Interconnection of Lots of Links (trill)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-03


Erik Nordmark <erik.nordmark@sun.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Mark Townsley <townsley@cisco.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:

The TRILL WG will design a solution for shortest-path frame routing in
multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
topologies, using an existing link-state routing protocol technology.

This work will initially be based on draft-perlman-rbridge-03.txt.

The design should have the following properties:

- Minimal or no configuration required
- Load-splitting among multiple paths
- Routing loop mitigation (possibly through a TTL field)
- Support of multiple points of attachment
- Support for broadcast and multicast
- No significant service delay after attachment
- No less secure than existing bridged solutions

Any changes introduced to the Ethernet service model should be
analyzed and clearly documented. To ensure compatibility with IEEE
VLANs and the Ethernet service model, the WG will request an IEEE
liaison relationship with IEEE 802.1, and IEEE 802.1 will be asked to
review the architecture document and specification(s) before they are
submitted to the IESG.

It is not an explicit requirement that the solution should be able to
run on existing IP routers or IEEE 802 switches as a software upgrade.
However, the working group should take deployment considerations into
account, to ensure that the solution can interwork with bridges in a
flexible manner (e.g., to allow incremental deployment into LANs that
currently use 802.1D bridges).

The TRILL working will work with the L2VPN WG to develop interworking
between TRILL and 802.1D bridges at the edge, such that a bridged
sub-cloud could be attached to TRILL devices in more than one place
for redundancy.

The solution must not interfere with the end-to-end transparency of
the Internet architecture or with end-to-end congestion control and
QOS mechanisms.

The WG will work on the following items:

(1) Develop a problem statement and architecture document that
describes the high-level TRILL architecture, discusses the
scalability of that architecture, describes the threat model
and security impacts of the TRILL solution, and describes the
expected impacts (if any) of the TRILL solution on the Ethernet
service model.

(2) Define the requirements for a TRILL-capable routing protocol, and
select one or more existing routing protocols that could meet
those requirements.

(3) Work with the appropriate Routing area working group to extend an
existing routing protocol to meet the TRILL working group

Note: The TRILL working group is not chartered to develop a new
routing protocol or to make substantial modifications to an
existing routing protocol. If, during the requirements definition
and selection phase, the TRILL working group discovers that no
existing routing protocol will meet their needs, we will need to
re-assess the TRILL WG charter to determine how/if this work
should proceed.

(4) Produce a (set of) TRILL specification(s) for standards track
publication that define(s) what information must be carried in an
encapsulation header for data packets. Although this work will
initially be undertaken only for 802.1-compliant links, it
may later be expanded to non-802.1 links, so the design should be
link-layer agnostic to whatever extent possible.

The TRILL working group is chartered to undertake all of the above
tasks and may begin work on more than one of these tasks in parallel.
However, the problem statement and architecture document should be
completed before the details of the base protocol are finalized, while
there is still time to consider changes to the architecture without
major impacts on established specifications.

Goals and Milestones:

Aug 2005  Accept architecture document as a WG work item
Sep 2005  Accept base protocol specification as a WG document
Oct 2005  Accept routing protocol requirements as a WG work item
Nov 2005  Submit architecture document to IEEE/IETF expert review
Jan 2006  Submit architecture document to the IESG for publication as an Informational RFC
Mar 2006  Submit routing protocol requirements to the IESG for publication as an Informational RFC
Mar 2006  Choose routing protocol(s) that can meet the requirements
Apr 2006  Start work with routing area WG(s) to undertake TRILL extensions
Aug 2006  Submit base protocol specification to IEEE/IETF expert review
Oct 2006  Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC
Feb 2007  Re-charter or shut down the WG

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

 Transparent interconnection of Lots of Links 
WG WEDNESDAY, November 9, 2005 
1300-1500 Afternoon Session I 

Notes taken by Don Eastlake and Spencer Dawkins. Merged by Erik Nordmark.

	Agenda Bashing
	Base specification
	Routing Requirement in Support of RBridges
	Multicast Link State for RBridges
	TRILL Using Pseudo-Wire Emulation (PWE) Encapsulation


Erik Nordmark:
  a.. We forgot a milestone for the problem statement
  b.. We need to catch up on a couple of deliverables and make our 
milestones reasonable.
	Nov 05 submit arch to IEEE/IETF expert review.
	Jan 06 submit to IESG for RFC.


Joe Touch: TRILL Core IDs
	Current versions are pre-drafts, not yet submitted to ID queue (will submit ASAP when posting re-opens after this meeting)
	The editor list for these documents may change.
	The text is new. But the documents are definitely a cut and paste in terms of ideas.
	Other people involved get to decide if they want to be listed as co-editors.
	Purpose of this talk is to discuss the split.
		I will talk about content AFTER talking about structure.
	Three CORE documents:
		Problem and Applicability (Informational)
			Defines the problem with few assumptions about architecture and protocol.
			Must allow for alternative solutions.
			But needs to refer to existing/proposed solutions
		RBridge Architecture (Informational)
			Describes the structure of proposed solution.
			Allows for alternative implementations (protocols).
		RBridge protocol (Standards Track)
	Other documents
		Routing protocol(s)
		Tunneling protocol(s)

	A considerable amount of new text (this is not just dividing up the protocol draft text)

	Don't seem to have picked a name between TRILL and Rbridge yet - do we need to?

		Inefficient paths, convergence of routing, robustness
			(NOT scale, node motion, data/control security)
		Zero configuration, loop free, ST management, VLAN
		? Multiple attachments
		Optimizations, equivalence
		Internet support
		Better describe limits / caveats
		RBridge device
			CFT, CTT tables
		Functional description
			Autoconfiguration, node discovery, tunneling, ingress/egress, forwarding, broadcast, 
			Two tables are part of the architecture (Rbridge topology and MAC addresses: CFT, CTT)
			External protocols (BPDU in/out)
		Case in favor -802.1D, D++, etc., needs to define a problem to be solved; problem should be "timeless"
		How much of the solution to include in P&AS? Now limited to properties, applicability...
		Convergence of Spanning Tree Protocol (STP), encapsulation enough, splitting edge STPs required?
		How much to discuss other solutions...
		Node discovery
		Protocols for CFT/CTT, one or two protocols, how to limit size of CTT
		BPDU interaction (three cases)
		Need for participation, "I'm just the editor", need supporting text, figs, refs where you agree, can remove what is not desired

"I may put in something just because someone said it... the documents need refs...  please send contributions."

	IANA Issues
		P&AS document: none
Architecture document: none
Protocol document: could have some

Eric Grey: We should decide on "TRILL" versus "RBridge". Currently the WG and mailing list names disagree.
We need to clearly specify the encapsulation, discovery peering etc. But we don't want the IS-IS WG to have to review encapsulation Joe Touch: The protocol document will point to these two documents.
Several people: We need to add these documents to the milestones.
Eric Grey: What should be in the problem/applicability statement? Applicability describes the application of a solution. Our WG charter limits us to things reasonably similar to Radia's initial draft. 
Erik Nordmark: Usually a detailed applicability statement can't really be done until after implementations exist. Can we put down real performance numbers now?
Eric Grey: We are looking for a document that says what problem we are going to try to solve.

Spencer Dawkins: On naming of draft, the IETF tools group has tools that look for the WG acronym in the file name. So we should make that true for all our drafts.
Russ White: There already is an IS-IS draft on extensions to that protocol for TRILL support. It has expired but will be revived.
I also promised to write a "Why IS-IS" document. It is being widely reviewed. I'll post a notice to the TRILL WG mailing list.

X: Discussion about "campus".
Erik Nordmark: Do we need a terminology discussion?
X: Yes but Guillermo is not here.
Joe Touch: I fear that, for too many people, "campus" means what people in industry mean by the term.
Paul Congdon: People should look at the 802.1 terminology: "bridged LAN".
Joe Touch: I have looked at 802.1 terminology and I think we mean "Ethernet segment". 
Paul Congdon: Another term commonly used is "Broadcast domain". Many people map an Ethernet segment onto a "bridged LAN".
Erik Nordmark: We should avoid terms that confuse 802.1 people.
Eric Grey: Using "Bridged LAN" was confusing because you are separating that into islands from the STP (Spanning Tree Protocol) point of view. We should use different terms.
Joe: This is why I'm nervous. Both vendors and 802.1 have their own terminology. Maybe we need to pick something different.

Erik Nordmark: We need to put "trill" in our draft file names. But we don't necessarily need to put trill in their subject lines. Should we?
Spencer Dawkins: There is precedent for a different name in the subjects.
Eric Grey: In fact is can cause confusion to sue the same name (PCE) everywhere for the group, the protocol, the device, etc. RBridge is the name of the box. TRILL is the name of the overall solution.
Joe Touch: I understand TRILL as the problem name and RBridge as the device and protocol name.
Erik Nordmark: Perhaps TRILL as the name of whole campus? Do components need to have TRILL related names?
Eric Grey: I suggest short pronounceable names. It will be easiest to continue using current name Joe Touch: We do need to name things like broadcast domain, etc.


TRILL Routing Requirements
	Rbridge architectural model remains as in draft-perlman-rbridge-03
	Allow for zero configuration
Content and Structure
	From perlman draft
	Has link-state requirements
	Interactions and Conclusion sections of the draft are currently empty
Recent input
	Lots of mail on STP and spanning tree forwarding interactions
	Specific wording suggestions
	Dialog on possible changes to the model
	Additional references to include
Seeking Further Input/Guidance
To do
	Null IANA considerations
	Rev with input
	Need to add to Acknowledgements and Reference sections
	When a WG doc? (not yet due to empty sections?)

Erik Nordmark: Does this document all the requirements on routing protocol? Should we separate out edge bridging interaction into a separate document?
Eric Grey: Should there be two docs?
Erik Nordmark: Perhaps requirements on routing protocols for interactions at boundary can be in the protocol document. Maybe we have Link State routing plus some legacy stuff at the edge.
People should read document and comment on the list. Should this document have requirements on the whole solution or just on link state protocol?


Multicast Link State for TRILL
Susan Hares
Why Tuned multicast?
	Initial plan to send multicast to all RBridges is too inefficient.
Draft Describes:
	MAC FIB table changes
	3 algorithms to generate multicast distribution (based on 802.11s)
	Knob / Features for improved performance
		Paths selection weight to select 1 path
		Use of link bundles.
		Negotiating of reduced flooding between RBridges
3 Algorithms
FIB tables for multicast
Multicast FIB generation takes: Input / Output Basic Concept
	Extend ISIS along the lines of MOSPF
		Multicast FIB (per VLAN, AFI/SAFI)
		Multicast weights...
		Use one of 3 algorithms

Dino Farinacci: Don't use flooding. There has to be explicit join paths.
Sue Hares: Sure, but I was working off a base spec.
Dino Farinacci: *,G implies shared tree, implies a root. Really means a group based tree.
Sue Hares: Yes, but what should I use?
Dino Farinacci: ...trees...

Dino Farinacci: Broadcast per VLAN is hard for multicast. Membership needs to be across all VLANs. Otherwise it multiplies packets.
Paul Congdon: Understand the concern. But leaky VLANs are not VLANs. The goal of VLANs is to isolate traffic. Of course, you could have a unique multicast VLAN used for multicast traffic.
Dino Farinacci: No one said anything about leaking.
Dave Mayer(?): This is a layer 2 mechanism. Don't you still have layer 3? A trill link can be used as transit by, for example, PIM.
Sue Hares: But you have IGMP and PIM snooping at layer 2.
Dave Mayer: But in context, you could have routers using a RBridged network.
Sue Hares: Yes.
Dave Mayer: Use just (S, G), It should always work but less efficient... Sue Hares: It has to work both with and without layer 3.
Dave Mayer: Could decide to just have (S, G) or could decide to have something more efficient.
Sue Hares: That's why we have 2 algs and, Dino, I'll also show why we have 3rd.
X: Snooping was brought up. Should have no snooping... Has to transit IGMP traffic.

(S, G) Multicast Tree Calculation rooted at S MAC
	Flooding via Link State
	Sorting S, G, RBridge info
	Calculate a multicast forwarding tree based in the source for

Dino/Sue: No data driven SPF (Shortest Path First). Instead, we should have control driven SPF.
Sue: Reduce trees before doing SPF.

TLVs for Multicast from RBridge
Sue Hares: No solution for multiple IP multicast groups which map to the same MAC address.
S- with Multicast TLVs
Discussion: base Source on the switch, not the original MAC.
Should Source address be included?
Reduced Flooding

Sue Hares: I appreciate the comments and will spin a new draft.
Erik Nordmark: Is this currently being discussed in the IS-IS WG?
Many: No.

Sue Hare: The draft has TLVs but does not specify where they live in a protocol.
I would like this to be a WG document.
Erik Nordmark: Many to few in favor so we will make this a WG document.
Mark Townsley: Note that the charter says to state requirements. Then to pick one or more routing protocols.

Joe Touch: We have to have flooding for broadcast even if don't have it for multicast.
X: No, that's not flooding, no multicast address flooding.
Sue Hares: Not flooding multicast packets by some definitions of flooding.
Erik Nordmark: Few have seen this document 
Michael Smith: I am concerned about generalizing layer 2 multicast. (Layer 3 multicast is OK.) 
Sue Hares: My point is just to not flood all multicast data to all RBridges.
Paul Congdon: The only protocol for joining layer 2 multicast is GMRP but is not deployed any more widely that RBridges right now.

IS-IS is rechartering now - if you want them to add these TLVs, etc, please tell them so it's in their new charter
Mark Townsley - must look at requirements before we choose a routing protocol, so we haven't chosen IS-IS yet...
Joe - need to support broadcast or we'll break Internet protocols, right? 


TRILL using Pseudo-Wire Emulation (PWE) (for encapsulation) draft-bryant-perlman-trill-pwe-encap-00.txt, Stewart Bryant Motivation Requires TTL, RBridge ID Four encapsulation mechanisms possible
	Could design our own from scratch
Forwarding Compatibility
	Adding/removing is a time critical operation in a forwarder, requires hardware support.
	New encapsulation would need new hardware.
	Therefore avoid a TRILL specific encapsulation.
Ethernet Encapsulation
	Well understood. 802.x tags
	But absence of TTL means traditional convergence mechanisms will create loops.
IP Encapsulation
	Too much overhead
	Potential fragmentation.
RFC3032 encapsulation
	Not the intent to use MPLS
	Instead, reuse MPLS Label Stack Entry mechanism
		19 bit Source/Destination address (which we call a "nickname")
		1 bit address type (unicast/other)
		QoS indicator
	Supports approximately 500K addresses
	May be extensible by stacking.
Unicast Traffic
	When an RBridge X learns a new egress nickname, form the 20-bit label field.
	Set extra bit 1 in nickname.
Egress Filtering
Dynamic Nickname Selection
	Each RBridge has a unique MAC system ID.
	An RBridge learns the topology and nicknames before picking its own 19 bit nickname and ensures that it is unique by using system ID to arbitrate.
	Selection algorithm is a local matter.
	RFC 3032 encapsulation provides TTL, QoS, nicknames.
	No forwarding path changes required
	Minor forwarding path changes for load-balancing or to improve efficiency of multicast/broadcast filtering
	Minimal overhead

Dino Farinacci: Suggestion: when you come up you have a System ID (MAC address), reassign your own until bottom 19 bits are unique..
Author: I'm open to suggestions
Pekka - does this work well with graceful restart?
Darren - business reasons to not go ahead with a new header - are there some TECHNICAL reasons for this?
X: As long as the mapping to nicknames, etc., is in the link state database, we should be fine.
Don O'Conner: Why do this instead of having a network of PW switches?
Author: The fundamental design decision of RBridges is to use IETF routing expertise on MACs. 
Don: This all seems to be about saving existing hardware. Just do PW switching.
Erik Nordmark: We have a different control plane. RBridges can be zero configuration, forward packets out of the box.
We haven't actually stated whether preserving hardware is a goal.
Mark Townsley: We had a detailed discussion of whether this is different from MPLS/VPLS/PWE and yes, it is due to autoconfiguration. MPLS/VPLS/PWE assume you have a configured network. TRILL assumes no such thing and this is fairly clear in the charter.
X: Economic arguments are pretty compelling; if routing and switching vendors have to spin hardware, that affects the economic model

Stewart Bryant:
There is an alternative approach: Loop Free convergence: PWE approach eliminates the need for TTL. Suggest looking at loop free convergence methods and Ethernet encapsulation.
Joe Touch: Core aspect of Rbridge is to preserve key aspects of existing network equipment. You're saying that all we need to do, in order to preserve the forwarding plane investment, is to come up with a routing protocol we don't have with properties we can't guarantee. It's great that we have been studying LFC, but what if you lose packets, etc? Not saying there are no solutions that include TTL-free version, but we need to have methods that are provably well-behaved in malicious cases, etc.

Stewart Bryant: No, really would use IS-IS tweaked to converge in controlled way



Trill core specifications
Routing Protocol Requirements
Trill Multicast
TRILL using PWE encapsulation
TRILL using PWE encapsulation - addendum