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.
Routing Requirement in Support of RBridges
Multicast Link State for RBridges
TRILL Using Pseudo-Wire Emulation (PWE) Encapsulation
a.. We forgot a milestone for the problem statement
b.. We need to catch up on a couple of deliverables and make our
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)
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
Better describe limits / caveats
CFT, CTT tables
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...
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."
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
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
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
Why Tuned multicast?
Initial plan to send multicast to all RBridges is too inefficient.
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
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)
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?
Sue Hares: I appreciate the comments and will spin a new draft.
Erik Nordmark: Is this currently being discussed in the IS-IS WG?
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
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.
Well understood. 802.x tags
But absence of TTL means traditional convergence mechanisms will create loops.
Too much overhead
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)
Supports approximately 500K addresses
May be extensible by stacking.
When an RBridge X learns a new egress nickname, form the 20-bit label field.
Set extra bit 1 in nickname.
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
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
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