MINUTES of the TRILL WG Meeting at IETF 73, Minneapolis, Minnesota Monday, 17 November, 13:00 to 15:00 Hilton Minneapolis Downtown Chairs: Erik Nordmark, Donald Eastlake Minutes by Dinesh Dutt, edited by the Chairs. == Administrivia: Dinesh Dutt volunteered to take notes. == Agenda Bashing: There were no requested changes to the agenda. == Charter and Milestones: Completed, Overdue, and Upcoming milestones were reviewed by the Chairs. It's about time to revise the milestones. == WG Document Status: Status of the Problem and Applicability Statement document (in AD Review [now in IETF Last Call]), Architecture document (timed out waiting for chairs to summarize expert comments to the author), and Base Protocol Specification (in WG Last Call and IEEE 802.1 review) were presented. Dinesh Dutt: Should IS-IS WG be involved in reviewing the base protocol spec? Donald: Enough explicit reviews have already been scheduled. I'm sure people in IS-IS will review it also. Erik: Mail will be posted to the IS-IS WG list asking for review. == non-WG Related Documents: the statuses of the VLAN Mapping, RBridge Notes, RBridge use of IS-IS, and TRILL Header Options documents were briefly presented. == draft-ietf-trill-rbridge-protocol-10 == Presentation of changes in the Base Protocol Specification from version -07 to version -10 by Donald Eastlake. Donald: You should particularly note the change in encapsulation. This is the biggest technical change and, although it was discussed on the mailing list, there wasn't much discussion. Anyone objecting should speak up here or on the mailing list. [No one in the room objected.] == draft-perlman-trill-rbridge-vlan-mapping-00 == Presentation of VLAN Mapping Document by Radia Perlman Erik: Are there any changes in the base protocol spec for this? Radia Perlman: Three minor changes: 1) The protocol spec no longer says that transit RBriges "MUST NOT" change the inner VLAN tag but now says that's OK is VLAN mapping is being done. 2) The outer VLAN ID is included inside the Hello PDU to detect VLAN mapping by a link. 3) When a RBridge detects VLAN mapping inside a link, instead of just giving up, it set a flag in its Hellos and the DRB assures that there is only one Appointed Forwarder for the link. Erik: Will ask on mailing list if we want to make this a WG document. == Presentation on How many Multicast Trees by Radia Perlman. Eric Gray: How many priorities are possible ? Answer: 1 byte [That was incorrect. It's two bytes.] plus 6-byte system ID. Donald Eastlake: Suggest this as change to the base protocol specification be posted to the WG mailing list and, if no one objects, make the change to the next revision. There should be no new last call on the updated protocol draft unless the changes are so complex that there isn't WG consensus to advance the document. == draft-eastlake-trill-rbridge-notes-00 == Presentation of Rbridge Notes by Donald Eastlake Eric Gray: What's the point of this document? Donald: It serves as a place to put some material removed from the base protocol specification to shorten that document and some miscellaneous new material that needed a home. Eric: Wouldn't it be a good material to place in a "applicability draft"? Donald: Possibly. Donald: Assumptions for a general RBridge campus to be free of persistent loops: No persistent loops in bridged LANs. VLAN topology the same for Hellos and data frames. Chairs called for a show of hands as to how many had read this document and almost none went up except Donald's. Mark Townsley: There has not been enough reading of the draft and so let's not attempt to discuss the future of it right now. == draft-ward-l2isis-04 == Presentation of Carrying Attached Addresses in IS-IS by Ayan Banerjee Eric Gray: Why do you have a separate MCAST PDU? Is it because it uses a different forwarding for ISIS control plane? Dino Farinacci: Multicast attachment changes more rapidly than unicast. Eric Gray: Some procedural issues in transporting MAC addresses need to be clarified. Mark Townsley: We'll take care of it Mark Townsley: Where will this document be standardized? Donald: It'll be in the ISIS WG. The eastlake RBridge IS-IS draft will be merged into this. Radia: We should be sure that the merged draft clearly shows which SDO/WG requested which feature. == draft-eastlake-trill-rbridge-isis-02 == Presentation of Rbridge use of IS-IS by Donald Eastlake. Erik Nordmark: Some of the stuff in this document has tutorial value. Donald Eastlake: Especially with the merger of material from the Eastlake draft, the title of ward draft should be changed since it is not just carrying "attached addresses". Dino: Should the language of the protocol specification be generic enough that other routing protocols can be used in the future? Mark Townsley: Do what you can, but don't kill yourself to make it general. == Presentation on Future TRILL Work by Donald Eastlake. Donald Eastlake: MIB document should be added to our Charter. Eric Gray: We shouldn't be creating a new MIB by taking copies from different MIB documents. It's a sign of an ugly document. Donald Eastlake: I didn't mean to imply actual copying. The 802.1Q bridge stuff and the IS-IS stuff inside an RBridge should, at least in part, be manageable through an existing MIB that can be referenced. You still need some new RBridge specific MIB... Donald: 802.1Qaz and 802.1Qbb are under the EISS layer and we don't need to do anything special to support them in TRILL. Donald: 802.1ag Connectivity Fault Management (CFM) is also below the EISS layer. Dinesh: DFM assumes spanning tree and so won't work with TRILL. But it provides useful facilities we should consider adding to RBridges later. Donald: 802.1au, Congestion Notification, was talked about in TRILL earlier and will require changes in RBridges to support but it seems to be progressing slowly in 802.1. == Presentation on the UNH Interoperability Laboratory by Timothy Winters. ?: When will a TRILL Interoperability event happen? Donald Eastlake: I think it is reasonable to try and do something by end of 2009. ?: Exactly when? Donald: In 2009, that is, sometime before 31 December 2009. Timothy Winters: We have had enquires about TRILL interoperability checking from members of the UNH IOL Bridge Functions Consortium. When we polled our members, 3 members said that implementing TRILL was on their road map. Silvano Gai: Can you say who? Timothy: No, due to NDAs, number of companies is all I can say. Silvano: Any firm dates on when the companies want to do something? Timothy: No. Mark Townsley: How long before the event will the announcement be announced? Timothy: 90 days usually, but can be longer. The shortest has been 4 weeks but that is unlikely. Donald: My personal opinion is that it'll be in 3Q of 2009. The open source implementation by Sun Microsystems, according to the public information on their web site, should be done before that. Silvano: Can you just test the control plane, which can be done in software? Timothy: Yes, we can do that sort of thing. Erik Nordmark: Have you done anything like this? How do you know the control plane did something useful? Dino Farinacci: You can do software data forwarding so you have both a control and data plane. == Charter Update by the Chairs. Eric Gray: We need to decide what we are going to do with the Architecture document. Either finish it up or drop it. I've been waiting for some direction from the chairs. It's OK with me either way on dropping the document. Erik Nordmark: I did review the document and all the Expert comments in the early summers but haven't fully figured out how to move forwards. An architecture document could be useful as an introduction to the protocol. Mark Townsley: An architecture can be useful if folks are going to try to build on it and extend it. The architecture can set some constraints. This has occurred in PWE3. Silvano Gai: The Architecture document was useful in the early days of TRILL deciding on nomenclature and things like that. Now that the protocol specification is robust, it is much less useful. Various: An Architecture document can be a useful historic record. But it can be confusing is the protocol has moved on so the Architecture and Protocol documents are inconsistent. Mark Townsley: Architecture document is useful when there is a lot of chaos around work involved. During Last call or IESG review, if a specification draft lacks background information, then an architecture document would be useful. This case is different and the protocol document is the #1 deliverable. == Meeting adjourned