TRILL WG minutes 21 May 2006 Taken by Alia Atlas, edited by Donald Eastlake 3rd and Erik Nordmark The IETF Note Well text was displayed. There were no suggested changes in the agenda as posted in advance. The author load has been redistributed. Joe Touch is working on the Problem and Applicability Statement. Eric Gray is working on the Architecture and on the Protocol Requirements. Radia Perlman is working on the Protocol. Joe Touch presents on http://www.postel.org/rbridge/draft-touch-trill-rbridge-prob-00.txt. Issues 1: Which version of Ethernet is baseline? 2: Scale - apply to current vs. larger scales. 3: IF size is an issue, what limits the size? 4: Delivery requirements: is in-order required? is non-duplication required? etc. (See presentation) Request to approve as a WG doc. Revise & restart issues resolution. Erik: Any comments in the room? Anyone opposed to accepting this as a WG item? (pause) No opposition; We'll confirm the acceptance on the mailing list and continue to work on the details. Eric Gray presents on http://www.ietf.org/internet-drafts/draft-gray-trill-rbridge-arch-00.txt Goals in this Iteration: * Nail down terms and definitions * Eliminate complex interactions with other protocols and technologies and make a few choices. * Step forward in defining what must be defined in solution docs. etc. (See Presentation) [Discussion whether PS or Informational makes more sense for the architecture document.] Erik Nordmark: A clarification - our charter says this document should be Informational. Eric Gray: The only thing I'd do is remove the 2119 language and there are no MUST/SHOULDs in the doc. Erik Nordmark: Has anyone read the doc? Any comments? I have one. (move to general mike) What I understand we're doing here is figuring out techniques that can have the same sort of auto-configuration benefits as bridge spanning tree from the edges. Bernard Aboba first brought up that if the edges are participating, like IEEE 802.11 Access Points and stations, then they could do better than the learning from examining frames. Could they explicitly inject routes? Should we include that in the architecture, even if it's not initially supported? Eric Gray: I think that's there by the separation of the Bridge / rbridge functionality. Learning can come from anywhere. We couldn't preclude this - not learning by configuration, for instance. Eric Gray: Did anyone read the doc? (A few hands) Erik Nordmark: So we'll take it to the list with a deadline for people to read the doc and become involved - and then discuss whether it should be a WG document. Radia Perlman: For what it's worth, I definitely agree that we should say learning can be done from packets or whatever. Radia Perlman presents on http://www.ietf.org/internet-drafts/draft-perlman-trill-rbridge-protocol-00.txt Changes: * Separated out architecture, problem statement * Changed to 4-byte, MPLS-like shim header (with details still in another document) * More explicit specification of filtering rules for IGMP snooping, VLANs * Removed discussion of resolved issues (See Presentation) Radia: Filtering on VLANs and multicast group can be optional. If nodes are lazy, it will still interoperate and work correctly. Mark Townsley: What if everybody is lazy? Radia: Then it reaches the final rbridge & that rbridge says "gee, I don't have anyone on this VLAN" and drops it. Mark: So you don't get the optimization. Dino Farinacci: I think it's a non-starter to allow non-filtering for multicast - because you'd have too much traffic. The case for mandatory VLAN filtering is not as strong. Russ White: I agree with Dino - we should require filtering in the multicast case at least. Bill Fenner: I was going to say it the other way. It is a product differentiation feature. The linksys rbridge for the home won't do this and the cisco one for the office will. Dino: People want you to do the standard. Bill: I thought this would specify this is what you SHOULD do, but then clarify that if you're really a lazy shirker is that then you don't have to... Mark Townsley: One thing I'm concerned about is that the lazy guy isn't paying the price - the network is paying the price. There's a motivation issue. It's the other guys who will have to buy the more expensive docs. Russ: If you put into the doc that you SHOULD do this & put in a implementation report, then the buyer can know... the problem is they might not understand (as Joe's going to say). Joe Saloway: If you didn't play the right game from the edge, if this is optional, either you say "I'll keep my mouth shut and try" or able to say "I don't know how to handle this packet" Radia: Oh, there's no problem with other rbridges knowing how to handle it. Dino: Most vendors implement MUSTs as 1st priority & then SHOULDs as second (so they never happen) - so think it should be a MUST. Russ: There's a case where the home rbridge may need this too (video multicast stream). Eric Gray: I'll turn Dino's argument around. The fact that people can opt out on a SHOULD means that there can be an evolution strategy. There are cases in a deployment where this may not matter. An implementation where someone does or doesn't want to do it may make a difference in whether it gets deployed. Erik Nordmark: One thing is this MUST vs SHOULD thing. Originally, it was avoid broadcast storms. There's nothing in the protocol that says you MUST send an ARP request, b/c it's obvious that if you don't send a request, then you won't get a response. Is the criteria for non-obvious stuff or for network dangers where MUST is important. Joe Touch: I thought RFC 2119 describes when you should use MUST. I think the MUST is used when there's a protocol failure if the MUST isn't followed, either network melts down, required for protocol implementation, or otherwise protocol wouldn't be working right. Erik Nordmark: But that seems like the obvious case... Joe Touch: Those aren't as clear for signaling protocols as connections. Is this a soft error or hard error? Radia: There's no error if you don't filter - you just waste bandwidth. Don Eastlake: A MUST is for things required for interoperability, security, or if the network would melt down, but here, if you don't need it in some case, it wouldn't matter. It leans towards being a SHOULD (a really strong SHOULD). Bill Fenner: A SHOUST? You were talking about IGMP snooping. Are you aware of the work being done in MAGMA to specify IGMP snooping? Radia: No - and I should. The stuff I put into the doc about IGMP snooping is prelim because I thought someone else would be clarifying it. Bill Fenner: Maybe you should refer to the MAGMA document because it covers many of the different cases and gives examples. Radia: Ok - I'll look at it. Mark Townsley: Remind WG while discussing between SHOULDs and MUSTs is that a motivation for TRILL is to be a plug-and-play, just works. Everytime you make a trade-off, you take away from this "it just works" view. I understand about it just being the bandwidth. Radia: I think it would still just work together. Support for filtering would be in the product selection phase, not a configuration knob. Mark Townsley: The knob is before you type at the keyboard - it's when you purchase. But, in a large campus, one group could buy a cheap one & plug it in & make a problem for another group. Radia: You'd notice the extra traffic and call over to them to get them to upgrade... Mark: Right, but that takes away from the - "it just works - or it just works well". Eric Gray: If you add some cheap rbridges that don't do the filtering at the edges, the section of the campus that does do it wouldn't be affected because it would filter the traffic; worst case is the LAN's worth of traffic. Radia Perlman: I'd be curious about how much cheaper it would be... Eric Gray: Can't really talk about how much cheaper at IETF... Caitlin Bestler: One thing is to think about simulating bridges in various virtualizations, or the bridge that connects Ethernet to blades in a chassis - and those specialized scenarios might have strong reasons to leave out these filtering features. Radia: Right, there are cases - but the work might not be too bad to do, in which case having this optional might not be useful. Mark Townsley: The term cheaper goes to the engineering complexity really. How much work is it to implement? We have to consider the work involved in the protocol. Erik Nordmark: One reason we're looking at the PWE/MPLS encapsulation is so that people could use existing hardware with firmware changes. It may be easier to implement without these features. Whether existing hardware is capable of supporting it, so it can be implemented easily and then get rapid deployment is important. Radia: I can see without the optimization it may be a significant (whatever word).... Mark: Right, but if the capability is there... Radia: Getting back to the draft, I hate for the thought-process of the decision-making and reason different design options were selected to get lost. We did remove the discussion of the contentious issues from the draft to avoid confusion. It'd be good to have it documented somewhere other than the mailing list - maybe a tutorial thing. (discussion about MPLS header & how Rbridges picking 19 bit nicknames for themselves to use instead of their 48-bit MAC addresses) Russ White: I'd vote for moving the description of that mechanism into the protocol document. Erik Nordmark: I agree; the existing separate document only has about 6 pages of meat. (more presentation) Radia: Is it necessary to distinguish the multicast groups in different VLANS? Should something sent to group 7 on VLAN A be also delivered to group 7 on VLAN B? Dino: Great question - which one is the dominant? Turns out the multicast people want the most efficient transmission which means unifying the groups in different VLANs. The layer-2 people want VLAN fault isolation which requires strict separation of traffic. So you may need to do both solutions. Radia: No - I don't want to choose one. That adds complexity and configuration and problems. Dino: So if you have to choose one, you should pick for fault isolation. It's an L2 engine even though the IP multicast group information is from L3. Radia: So, the way you see it, the multicast packet is constrained to its VLAN unless there is an IP router on that and one or more other VLANS... Tim Shephard: My understanding of the reason people use VLANs in a campus is to achieve some security. Just because a packet shows up on one VLAN doesn't mean it should appear on another without going through a router with its security rules. Radia: Ok - if it's a per-VLAN thing... Should we do it where the rbridge is snooping IGMPs everywhere vs. when the first rbridge sees the IGMP and adds the data to the flooded link-state information. Eric Gray: I'll volunteer to bring this up on the mailing list. I think this is part of a discussion that we'd had. I'll also bring to the list the discussion about the SHOULD behavior associated with the multicast and how that interacts with all rbridges needing to parse. Radia: But the rbridge wouldn't do anything with the information... Eric Gray: But you're suggesting as an option to put this group information into the routing protocol... Radia: So, I'm starting to think that may not be the way to go. Erik Nordmark: The VLAN filtering is actually a level down [layer-2]. The IGMP snooping is a level up [layer-3] and needs to be done per-VLAN. You could have two VLANs both running and doing IGMP-snooping on one VLAN and not the other. The IGMP stuff is a filter that's per-VLAN. Dino: When a packet comes in with a VLAN tag, you look up the MAC address in the VLAN table. For the IGMP, you build an egress table per VLAN. What you do for IGMP snooping is at the second half of the forwarding. Radia: Right, first you filter on the VLAN and then you can do the IGMP-based filtering. Erik Nordmark: Who's read this document? (few hands) Anyone think we should take this as a WG doc? (few hands) Anyone opposed? (no hands) Eric Gray: Let's do the same thing as with the architecture document and set a deadline for reading it and then decide on the list. Erik Nordmark: Slightly different, because more people have read this and the problem statement. We'll ask on list for confirmation indicating the working group meeting was ok with accepting it. Eric Gray presents on http://www.ietf.org/internet-drafts/draft-gray-trill-routing-reqs-00.txt (See presentation) Dino: Technical question - have you decided if IS-IS will run on a different MAC addresses, NLPID or such so it won't interact with an L3 IS-IS? Eric Gray: It hasn't been decided. We're using IS-IS because it's easier to auto-configure than OSPF. Russ White: I don't think it's addressed yet. We need to. Eric Gray: So should we put this in or check on it? Dino: We need to monitor the IS-IS work and make sure they specify it. [I think Russ said that L2 IS-IS would specify how this is handled.] Erik Nordmark: Asking for how many people have read this document... very few hands. Better to read it while it's short now. We'll have to send this to the list too with a deadline and ask on the list whether it should be a WG document. Erik Nordmark, discussing about WG charter/deliverables: Erik Nordmark: We need to update the dates & the deliverables, talk about an architecture document, a base protocol document and a routing protocol document. We need to add the problem statement and AS as WG work items. I've updated some dates... but I'm not sure how far out to push some of the later items. Russ White: The "start work with routing area WG" is already done. I know that Dave's working on them as the co-chair for IS-IS. You could set that date fairly soon, maybe two IETFs out. We might want to hang on that until the architecture and protocol stuff is done, but the work is started. Erik Nordmark: Any other comments? If not, you've got over an hour to read the documents... We'll check at the door if you've read the docs & if not, then you don't get to go to lunch... [This was intended as a joke but apparently at least one person came up to the head table later to check after reading the draft...]