Last Modified: 2005-06-29
|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|
TRILL WG Minutes August 4, 2005
Minutes taken by Alia Atlas.
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.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.
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.
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)
Radia Perlman: (see presentation)
How many spanning trees?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.
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.
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.
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.
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.
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.