TRILL Working Group Meeting, 70th IETF, Vancouver, BC -------------------------------------------------------- TUESDAY, 0900-1130, Salon D/E Room Administrativia (scribe etc), Agenda Bashing, Chairs -------------------------------------------------------- Chairs: Erik Nordmark, Donald Eastlake 3rd The scribe will be Dinesh Dutt. Erik Nordmark also took notes. Minutes edit by Donald Eastlake. Items marked as "Tentative Consensus" were judged by the co-chairs to be the consensus of the room but will, in accordance with IETF process, be checked on the mailing list. Review of Existing Charter and Milestones, Chairs -------------------------------------------------------- As decided at the last meeting, the Routing Requirements document has been dropped from the Charter and Milestones. The Working Group consensus is to use IS-IS. The current milestones call for us to submit the base protocol specification to IEEE/IETF expert review by December 2007 and to the IESG for publication as a Proposed Std RFC, Mar 2008. We are currently scheduled to recharter or shut down the WG Dec 2008. Eric Gray: Do we have a charter requirement to do a formal review by IEEE 802.1? Donald Eastlake: I don't think it has to be as formal as a document with cover letter and an official written response from IEEE. ***** Action: Chairs to check with Mark Townsley on what level of formality is required for 802.1 review. Donald Eastlake: At this meeting, Erik Nordmark or I will talk with the L2VPN Working Group about handling multiple attachments to compare notes. Our charter requires us to "work with" them. Joe Touch: Problem statement document needs to be updated with new changes. We can't do last call this month, let's push it out to Feb 08. It has some open questions in it but those could be closed and I could revise the document (removing discussion items and checking that there aren't inconsistencies with other documents) by Jan/Feb. Input from the working group is requested and incorporating that might delay the document until March. The architecture document would generally have to be after the problem statement document to assure consistency. Radia Perlman: Could we extract the open items from the problem statement document and post them on the mailing list to get comments? Radia Perlman: It's awkward to have three docs that talk about the same thing. Now that we know the problem, do we need to put effort into this document? Joe Touch: The architecture document is supposed to be a higher level than base protocol specification. Dinesh Dutt: I support Radia's position. We don't need multiple documents that talk about the same thing. Eric Gray: A single document cannot cover all topics intended to be covered by all three documents without becoming too large or vague. It's a problem of this WG that we pushed the protocol specification to be the main document instead of working over the problem statement, architecture etc. We have not resolved many open issues in those documents. Erik Nordmark: Let's get rid of any overlap between the documents. ***** Tentative Consensus: Move milestones to March 2008 for Problem Statement and Architecture document. Joe Touch: Request that people "send text". The Architecture of an RBridge Solution to TRILL -------------------------------------------------------- draft-ietf-trill-rbridge-arch-04.txt, Eric Gray Biggest change from previous version is common terminology with other documents. It also now explicitly says we are using IS-IS. A bit less than a page of material that was previously in the base protocol document has been moved to the architecture. Should the Architecture document just assume IS-IS or be more generic? Joe Touch: Architecture documents says what needs to be done, not how it is done. General opinion seemed to be that the architecture document should pull in some condensed routing requirements information and then have text saying "looks like we are using IS-IS" or the like. Should be such as to permit other protocols than IS-IS in the future. Designated RBridge (DRB) text in architecture document doesn't follow the protocol document in providing for DRB to assign encaps/decaps role. It should describe the constraint - that the protocol must have a mechanism so that a native frame is not encaps by more than one RB. Eric Gray: I'll change that. Rbridges: Base Protocol Specification ----------------------------------------- draft-ietf-trill-rbridge-protocol-06.txt, Radia Perlman, Donald Eastlake, Silvano Gai, Dinesh Dutt TRILL issue: VLANs, Radia Perlman ----------------------------------------- Dinesh Dutt: Should there be only one common VLAN for all non-DRB RBridges to send on? Can there be a different VLAN for other RBs? Radia Perlman: Different VLAN for different RBridges on one link makes it complicated. Eric Gray: Does reporting reachability on a different VLAN than the one on which they're encap/decap data cause orphaning of end nodes? Radia Perlman: Yes, that can happen, but I think it is better than the alternatives. Eric Gray: There is an issue with silent orphans/blackholes. I will send a message with a diagram to the list. TRILL issue: Pseudonodes, Radia Perlman --------------------------------------- Joe Touch: Why did you worry about this optimization? Is it the size of the messages or something else? Dino Farinacci: The cost in dispensing with pseudonodes and having lots of adjacencies is not so much in the size of the messages, although that is a factor, but in CPU used for the shortest path first calculations. Dinesh Dutt: Should this proposal be made part of the IS-IS WG instead of within TRILL? Radia Perlman: I don't want to slow down the TRILL protocol specification because of this. I have discussed this on the IS-IS WG mailing list. Abhay Roy: I'm the OSPF WG Co-chair. I suggest you do this in the IS-IS WG since OSPF may be interested in it as well. Erik Nordmark: Seems to me that we should move all the highly specific IS-IS stuff into a separate document and not delay the protocol specification. Radia Perlman: I'm willing to work on a separate ID on this for IS-IS WG. Donald Eastlake: I'm pretty sure there is a pseudo-node suppression feature, but for p2p links only, in one of the IS-IS WG specifications... Also I have stared a more specific draft on TRILL use of IS-IS, details like sub-TLV formats. It goes between the TRILL base protocol specification and the draft-ward-l2isis draft. That Ward draft is generic to any layer 2 use of IS-IS, not TRILL specific. MUST/MAY discussion... Eric Gray: I support it being a MAY, but it should be solved in IS-IS and the default should be to do the simple thing of doing pseudo-node always. Will IS-IS WG actually do something about this? Unclear. Daniel ?: Is there a simulation or some data to prove that there is a real advantage to this proposal? Radia Perlman: I've spoken to someone who said they did some simulations and there was. It's useful to do a formal process of evaluation. ***** Tentative Consensus: Move the Pseudonode suppression provisions out of the TRILL base protocol specification into a document closer to IS-IS. Changes from -05 to -06, Donald Eastlake --------------------------------------- Section 6 of the base protocol draft now notes that bridges can hide slow links and make it harder for RBridges to determine the cost of an Rbridge to RBridge hop. Joe Touch: Other routers/bridges already have this problem so it is not new and not unique to RBridges. Donald Eastlake: I'll note that in the next revision. There were no significant comments on the rest of this presentation. Changes from -06 to -07, Donald Eastlake --------------------------------------- Donald Eastlake: Tentative plan is to produce -07, take -07 to WG last call and review by IEEE 802.1 and L2VPN WG, incorporate the comments to produce -08 and take that to IETF last call. The pseudo-code will be improved and Anoop Gandwani will be added as a co-author in -07. In a modern all-RBridged wired network, you would have only RBridge to end station and RBridge to RBridge links. Egressing any native data frames on the RBridge to RBridge links would waste bandwidth. But, as pointed out in the Architecture draft, several types of multidestination frames would be send on all such links under the current protocol draft. ***** Tentative Consensus: Currently broadcast, unknown unicast, and non-IP-derived multicast frames are output to all links. This is wasteful if there are no end stations on the link. Provide that a port can be configured so as to be disabled for end station traffic. Discussion then turned to a second configuration proposal as follows: Provide for a port to be configured as leading to a point-to-point link directly to another Rbridge. Such a port would be disabled on receipt of a native data frame or a Hello from a different Rbridge. TRILL frames sent on such a port MAY use the All-Rbridges multicast address as their fixed outer destination and source addresses. Joe Touch: This doesn't seem worth-while - misconfiguration is an issue and benefits are little. Let's not do this level of optimization of configuring p2p links and defining what that means. Joe Touch: A meta-comment: we should look for positive comments on a change before adding it instead of just a lack of negative comment. Radia Perlman: If proposals are controversial, we should not make them. We need to take a stand and push out the specification or we'll never finish. Donald Eastlake: There are only four changes listed in this presentation so it's not that there are lot of changes. ***** Tentative Consensus: Against the proposal presented at IETF-70 for p2p link configuration permitting a fixed source and destination address. Eric Gray: We could use the MVRP compressed format to report VLANs in our IS-IS PDUs. Radia Perlman: Could you send the format? We could use this everywhere we say "send list of VLANs". It might be useful for the IS-IS WG. Erik Nordmark: Just remove the explicit text prohibit GVRP/MVRP. Don't add any text saying "MAY" support. Draft -06 contains verbiage asserting that RBridges do not support GVRP. This seems like a bad idea as support of GVRP, or its successor MVRP, might help in RBridge VLAN configuration. ***** Tentative Consensus: Remove any text prohibiting implementation of GVRP or MVRP on RBridges. Additional TRILL Work/Documents, Donald Eastlake -------------------------------------------------------- Presentation of possible future work/documents. Volunteers are needed for all of these. IS-IS Details Document: Need details of (sub-)TLVs. ---------------------- Donald Eastlake: I have a start on this draft. Dinesh Dutt: I volunteer to work on the IS-IS details draft. Management/MIB Document: ----------------------- Radia Perlman: Does this mean we need to write a MIB? Donald Eastlake: I hope that most of the RBridge MIB can be formed by referring to the existing Bridge and IS-IS MIBs but, yes, at least some small amount of additional MIB will need to be written. No one is working on this right now. Radia Perlman: That seems like a potential problem. TRILL Header Options: -------------------- Dinesh Dutt: Should we at least specify in the base protocol document enough to support options in the fast path even if those options are not supported by all RBridges? Erik Nordmark: Can't we use the control protocol to determine if we can stick in options or not? Dinesh Dutt: That doesn't work for transit Rbridge handling of e2e options since the path a frame will follow can't be fully predicted. There was some discussion to the effect that a single bit to indicate the presence of hop-by-hop critical options would be useful to define. This topic was taken to the mailing list. IP Optimizations Document: ARP/ND... ------------------------- Provider RBridges: ----------------- Dinesh Dutt: This would be useful but we should finish up the base protocol assuming customer RBridges before we work on this. Connectivity Fault Management: ------------------------------ Dinesh Dutt: IEEE CFM (802.1ag) defines ping and traceroute but requires symmetric paths which doesn't work with TRILL. We will need equivalent facilities in RBridges Congestion Management: --------------------- This (IEEE 802.1Qau) is progressing slowly in 802.1. Supporting it in RBridges will need some work as, for example, a backwards congestion notification (BCN) message generated by a bridge between RBridges needs to be recognized by RBridges and gotten to the end station that originated the traffic. --- Chairs asked if there were any further announcements. Eric Gray mentioned draft-gray-rbridge-scaling-01.txt. Adjourned