2.3.24 Transparent Interconnection of Lots of Links (trill)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-29

Chair(s):

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:

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
protocols.

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
  everywhere)
- 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
  technologies

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
  interconnected.

Goals and Milestones:

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

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

TRILL WG Minutes August 4, 2005

Minutes taken by Alia Atlas.

Agenda:

Deliverables:

Erik Nordmark: "Some fairly tight dates on getting at least the problem statement and architecture document. This is something the IETF wants to see. There was a proposed outline sent around that we can share with the list.
Requirements for a TRILL-capable routing protocol & select existing protocols. Work with appropriate routing wg on suitability/extensions.

Produce a set of TRILL specs for standards track. draft-perlman-rbridge is the start."
Russ White: The extensions to the routing protocols is already a work in progress - just not published yet.

Erik Nordmark: When that gets published as a draft, will go to the list so people can have a look at it.

====================
Coordination with IEEE 802.1:

Donald Eastlake: Quick overview on 802.1 liaison. IEEE 802.1 is custodian of the 802 Architecture & defines what it is. (See presentation slides)
Bernard Aboba is the overall liaison but there's plenty of room for more specific liaisons.

Paul Congdon: Vice chair for IEEE 802.1. There is a big difference in IEEE as well & 802.1 operates more informally than many 802 groups. Don't vote on each little thing & operate on consensus. While we do have a formal voting process, we do typically accept comments from people who aren't part of the WG & I've never seen outside comments not processed. 802.1 is much more informal and a relationship with TRILL should be straightforward. My questions is when you talk about the liaison relationship, it wasn't clear what you'd want 802.1 to be doing explicitly. Obviously, we'll have people attending anyway as IETF participants.

Donald: First, I want to agree with what you said about 802.1 being more open about comments from outside the WG. In 802.11, which is more formal, if there are technical questions, the chair can submit them as his own. For the question, the liaisons at a minimum would report what was happening & report

Paul: Dorothy is the liaison for most of the wireless, but I've been serving as liaison for the 802.1 related work & will continue to do so.

Steve Trowbridge: One of the co-authors on the new IETF liaison process. Part involves the IAB appointing an individual to look after the liaison. Liaison relationship actually means something in the IETF context.

====================
Problem statement and architecture

Erik: Editor for this draft should be here, but person is still TBD. Put this up to encourage people on it. Looking for a volunteer author/editor.
(See presentation)

Richard Spencer: You put a list of what could be considered requirements. Can you tell us where those requirements have come from? What enterprise customers have said these meet their requirements? Have they said that these are the problems that they want to be solved & this is the solutions? Are there any enterprise customers here that have these problems that need to be solved?

Erik: These things have made it into the charter based on people saying they've had these requirements. I think it's hard to pinpoint the origin of all of these requirements.

Richard: It seems to me that we have a solution & are looking requirements.

Erik: We have a charter saying that the rbridge is a start & we discussed this during the BOF.

Richard: Are you intending to create a new market for this solution.

Erik: Yes. Whatever it said on the first page, shortest-path frame routing in multi-hop 802 network.

Richard: If we don't have requirements, how do we know this is the best solution?

Erik: I think this is out of scope.

Joe Touch: There are several docs. I've seen WG have as many as 8 or 10 docs that lead up to the solution; shouldn't do that. The doc that we have to date is a combo of a problem statement and architecture. The problem statement should include the applicability. The architecture should also list the requirements. Some of those listed are architectural requirements, not problem statements. Shouldn't be that hard to take a first stab at that. Easier to see it from the docs; it's hard to do that on the fly.

Erik: If we can get that clarity, I agree. I'm not sure how we're going to work on moving forward on describing the problem statement and the architecture.

Christian Huitema: I really think we need to work on the requirements. When I read these slides, what's missing is the ref to the wireless networks. I don't know if that was deliberate, but it is a large area of campus networks.

Erik: Had question in BOF if targeted explicitly at wireless & answer was no, but could be useful there.

Christian: I agree but I'm talking about the wireless networks. Taking the differences into account makes it likely that the solution won't be applicable.

Erik: Popping up, during the charter discussion, decided that we didn't need a requirements doc first. This is fairly solutions driven from an architecture perspective. Having a solution in the rbridge means that we don't need a year or 2 to write a requirements doc.

Christian: Agree not to spend 2 years arguing about requirements first. However, the requirements (or architecture) draft should consider the wireless as well.

??? Jenkins: Share some concerns about the requirements. The problem statement isn't a problem statement that is to be solved. Until I can see that, architecture seems a bit premature.

Russ White: The IETF typically doesn't take requirements from customers, but from vendors. The vendors I know (Cisco for one) has customers who are interested. We have people interested in working on this & vendors interested in implementing this so we move ahead. On 802.11, I think that this will be useful there, but it might be good to limit the discussion scope architecture about how this works & then look at the wireless as we know this is coming next & commit to looking at that and working on it, but let's solve what's on the table first.

Vach Kompella: Speaking as chair of L2VPN, I don't think that there's enough in the charter that distinguishes this from L2VPN. I think that a requirements doc is more necessary than you imagine & then make that discussion here. We did have a scope discussion about work here versus L2VPN. I agree with Joe that this could be useful. I don't want to get hung up on bureaucracy, but in L2VPN, L3VPN, etc. we have the customers write the requirements - so I disagree with Russ. Of course, we have a smaller set of clueful service providers, so I'm not saying that we need to go find clueful enterprises. There should be some people who will sign on and say that this is a problem & we see the issues.

Joe Touch: Usually when you include a problem statement, it's bundled with the applicability.

Mark Townsley: Could we focus on the problem statement & applicability & if this isn't sufficient, then we'll think about a requirements doc. They're useful, but not always necessary. Let's focus just on the problem statement & applicability inside that, which might help satisfy Vach's concerns.

Joe: It might also help address the question of who wants this problem.

Erik: We did have the question about how this compares to L2VPN. We did have this in the charter, but took out. I think it makes sense in explaining this as part of the

Eric Gray: I think a lot of people are missing the obvious, if we did a survey about how many enterprise customers are in here, well everyone in here are enterprise customers.

Erik: But if they're building equipment to serve the SP network, are they thinking of those or of their own networks? It's good b/c this helps clarify some of what I've been missing in terms of what the problem statement and applicability should talk about.

(More presentation)

Joe Touch: There's a bunch of threats that don't come to mind, such as misconfiguration. There's a lot longer list of things under the "do no harm".

Erik: Right, there's a lot of robustness concerns that could be exploited.

Joe: Even not considered as attackers but rather accidentally.

Erik: Traditionally, we think about active attackers.

Joe: In the architecture, go through both active attackers & misconfigurations.

Erik: I'm not sure if the security ADs would agree with calling them threats.

Joe: Right, but the first do no harm is a lot broader than the text.

Alex Zinin: On scalability, one thing to keep in mind is the frequency of updates, such as start of the day when things are coming on-line & hosts moving around.

Erik: That would be in the applicability.

Alex: Yes, you'd need to define what is the scalability range that you're optimizing for.

Erik: I'd like to see this as a concise document? What's missing? Looking for volunteers..


====================
Requirements on routing protocols

Erik: Again, this is a TBD author. Trill will provide a requirements doc for the routing protocols & then select which to use. Any extensions needed to the routing protocol. There's been some work & an ISIS extensions draft is already underway.
Want to enable 0-touch, so can operate without manual configuration. (See presentation)

====================
Protocol document:

Radia Perlman: (see presentation)
How many spanning trees?
How to learn endnode information?
How to handle multicast
  • IP multicast
  • non-IP multicast
Vach Kompella: How do you know which VLANs belong to which RBridges?

Radia: That would have to be configured. It would be in the link-state protocol. Not just "hi I'm Radia, but also these are my VLANs".

Alex Zinin: From my understanding, the bridges that announce their VLAN membership is just the RBridges connected to the end-hosts.

Radia: All the RBridges support traffic transport.

Alex: So how do you decide where to forward?

Radia: Calculate a spanning tree (assume one) & you're not in any VLANs. Look downstream to see which VLANs are connected to the RBridges. (Continuing presentation showing why one might want separate spanning trees per VLAN).

Dino Farinacci: Might want to say what a per-VLAN spanning tree would be used versus a global spanning tree.

(More presentation)

Erik: A question on the dynamic nature of this, through 802.11x, this might attach to a particular access point. Hosts could move & VLANs might come & go on RBridges.

Radia: yeah

Alex: One comment on spanning tree calculation. Suggested just selecting the lowest router ID. One problem is that that router might be momentarily unavailable or frequently.

Radia: If we're doing a tree per RBridge, not a problem.

Alex: Yes, but for a single spanning tree, it would be. The draft has some words for ECMP-tie breakers. You really need to worry about bundles between nodes.

Radia: It depends if those links are transparent to the rest of the world. If not, we'd need a deterministic tie-breaker, so would need to include the port ID as well as the router ID.

(Second presentation)

Michael Smith: Quick question. The recommendation is to still pass the MAC addresses

Radia: Yes, but just passing around & not need to store them if not part of the same VLAN.

Michael: I was quite encouraged by the second approach where you do the learning.

Radia: Yes, this is something which is better suited to discussion on the mailing list.

Erik: It would be useful to write up an email to see the pros and cons on the possibilities.

Radia: Yes, and if sufficiently long, might be a draft.

Alex: Before we start discussing the pros and cons, having the possible solutions fully described would help.

(Third presentation)

Tim Shepherd: Are we concerned about defending against denial of service attacks?

Radia: We certainly could say that there's a certain percentage of traffic that's available to multicast - but that's orthogonal.

Tim: But earlier, for unicast, if one hasn't heard of the address, then it is broadcast.

Radia: That's the case today...

Tim: If this tech allows larger domains without routers, could DoS whole domain...

Erik: Would be interesting to understand what happens to non-IP multicast packets when IGMP snooping switches are used.

Dino: They default to dropping, if IGMP snooping is configured on all switches, if the MAC is IP-derived.

Erik: So there are 2 different behaviors depending on if the MAC is IP-derived.

(presentation continues)

Dino: IGMP forwarding doesn't happen for that case. Existing snooping IGMP bridges don't have this problem.

Radia: We need to make sure they don't. We haven't written down the design yet, so just need to make sure that we don't break that. It could be that we just copy the design for IGMP snooping bridges, or we may need to do more.

Radia: Should we allow cross-VLAN delivery of IP multicast?

Alex Zinin: That's a router function; I'd leave it alone. I think we should preserve the functionality that is there.

Radia: This is something else we should discuss on the list.

Erik: What happens when you have a mixture of bridges and RBridges? What happens when some bridges do IGMP snooping & some don't?

Dino: There's nothing standardized, but MAGMA has something written down talking about how not to break it.

Dino: If the RBridges don't do the IGMP snooping & the existing bridges do, how does that work?

Erik: On the cross-VLAN thing, people may deploy VLANs for different reasons. Some may be for security & some may be to limit the broadcast domain. This

???: When we talk about non-IP multicast, we need to consider MPLS multicast.

Erik: They're specifying how to carry IP multicast over MPLS, but I'm not aware of case when MPLS would run over IP/Ethernet multicast.

Alex: As a general response, let's leave MPLS multicast for later. It's not yet a done deal & it won't be as easy as IP multicast.

Dino: I think we'll have a struggle between management isolation & optimization. Then, do you want to support both or just make a decision?

Alex: We could limit it to L2 as part of this & then some nodes could do it as part of their L3 functionality.

Vishwas Manral: Are you considering something like MSTP like multiple spanning trees per VLANs.

Radia: If you're doing per-RBridge spanning trees, then don't need for per-VLAN. Then which VLAN it is is only filtering information per port.

Vishwas: Assume a bridge that is doing IGMP snooping, how will the bridge in the middle be able to interoperate since we're adding a header.

Radia: That's a question. Since this isn't written down, we need to get the design correct. It'd be good if we had people on the list who really understood how IGMP bridge snooping really worked.

Vishwas: What about MTU issues? Have we thought about those?

Radia: For a few years, I always assumed that adding a few bytes would be fatal, but now they're doing VLAN tags and MAC-in-MAC so apparently it's not a problem.

Erik: So at end of the agenda, should we accept this rbridge doc as a WG doc... Are we ready to answer the question?

Loa: This doc is actually mentioned as the starting point in the charter, so is there a question.

Joe Touch: It might be more productive to offer to start with breaking the document into two pieces. One that looks more like an applicability and one that looks like an architecture...

Erik: The only reason to ask the question now is to rename the doc so it's easier to find. Second step is figuring out which docs we need.

Paul: It does seem a bit odd to adopt a protocol doc before you even have other docs written or even outlined. It makes sense that it would be a WG doc at some point, but not sure whether the WG will consider other approaches.

Erik: The IESG re-wrote it into the charter. The document will definitely evolve; it's a starting point.

?????: What we have here is a doc that we clearly think will be broken up. 2 revs down the road, it'll clearly go away. Sounds to me like at least 3 (apps, arch, protocol). Once those are spun out, then we can talk about adopting them.

Vach Kompella: It also seems odd to have this in the charter... You need at least one rev of the charter now, to take this out.

---

Slides

Agenda
IETF TRILL <-> IEEE 802.1
Problem statement and architecture
Requirements on routing protocols
Issues
Issue: How many spanning
Issue: How to do endnode
Issue: Optimizing Multicast