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.

	Administrivia
	Agenda Bashing
	Base specification
		Draft-touch-trill-rbridge-prob-00.txt
		Draft-touch-trill-rbridge-arch-00a.txt
	Routing Requirement in Support of RBridges
		Draft-gray-rbridge-routing-reqs-00.txt
	Multicast Link State for RBridges
		Draft-hares-trill-multicast-00.txt
	TRILL Using Pseudo-Wire Emulation (PWE) Encapsulation
		draft-bryant-perlman-trill-pwe-encap-00.txt
		draft-bryant-perlman-trill-encap-00.txt

---

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?

	Problem
		Inefficient paths, convergence of routing, robustness
			(NOT scale, node motion, data/control security)
	Properties
		Zero configuration, loop free, ST management, VLAN
		? Multiple attachments
		Optimizations, equivalence
		Internet support
	Applicability
		Better describe limits / caveats
	Architecture
		Terminology
		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)
	Issues
		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
Draft-grey-rbridge-routing-reqs-00
Assumptions
	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
	Discuss
	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
Draft-hares-trill-multicast-00.txt
Introduction.
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
		DataBase
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
	Ethernet
	IP
	MPLS
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
	Provides
		19 bit Source/Destination address (which we call a "nickname")
		1 bit address type (unicast/other)
		TTL
		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.
Multicast/Broadcast
	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.
Summary
	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

---