TRILL WG Minutes, IETF 67, San Diego 09:00 Tuesday, 7 November 2006 Co-Chairs, Erik Nordmark, Donald Eastlake 3rd Notes from Ayan Banerjee, Erik Nordmark, and Donald Eastlake were merged and edited to produce these minutes. Blue sheets were distributed. Scribe: Ayan Banerjee Jabber Scribe: Jacob Stein Agenda Bashing / Milestones =========================== Erik Nordmark, Donald Eastlake It was agreed that the time estimates were probably way off, some too long and some too short, but there were no changes to the content or order of the following agenda: 05 min. Administrativia (scribe etc), Agenda Bashing, Chairs 10 min. Charter milestones, Chairs 15 min. Problem and Applicability Statement draft-ietf-trill-prob-01.txt, Joe Touch, Radia Perlman [in WG Last Call] 15 min. TRILL Routing Requirements in Support of Rbridges draft-ietf-trill-routing-reqs-00.txt, Eric Gray [in WG Last Call] 10 min. The Architecture of an RBridge Solution to TRILL draft-ietf-trill-rbridge-arch-01.txt, Eric Gray 55 min. An encapsulation for TRILL draft-gai-perlman-trill-encap-00.txt Silvano Gai 15 min. general presentation and justification 40 min. Discussion about F-tag, two Rbridge addresses, LIDs 30 min. Rbridges: Remaining Issues draft-ietf-trill-rbridge-protocol-00.txt, Radia Perlman If time permits: Rbridge extension framework Donald Eastlake The milestones were reviewed. Probably we can soon submit the Routing Requirements draft to the IESG and the chairs are arranging for the 802.1 review of the Architecture document required by our Charter. Other milestones need some date revisions and the chairs will send suggested new dates to the mailing list. It was suggested by the chairs that most of the detailed shim / protocol format discussion be postponed until after all but the last presentation. draft-ietf-trill-prob-01 ======================== Joe Touch There are a number of holes or questions in the current document (see square bracketed comments in the draft) Joe requested that people send text to fill-in the holes in the Problem and Applicability Statement and that if they have problems or criticisms of the draft, they send suggested added or replacement text with their complaint. It was requested that the problem statement include how TRILL is related to IEEE 802.1{a, d, h, q, v, s } etc. draft-ietf-trill-routing-reqs-00 ================================ Eric Gray The draft now incorporates comments from Donald. There have been a few additional minor comments on this list such as spelling. The more controversial comments, such as those related to "drop BPDU", do not need to be addressed in this high level document. The chairs indicated that this document is at or close to consensus. draft-ietf-trill-arch-01 ======================== Eric Gray The draft was updated to address comments on the list that appeared in mid-September. Also text has been added about the wiring-closed issue. The wiring closet problem ------------------------- The question is how to use both links. A Pseudo-RBridge, which is the root bridge, proposal was presented for the wiring closet problem. Comments: Erik Nordmark: When there are multiple pseudo-node RBridges and they are not part of the Topology, why not just call them "bridges"? Dino Farinacci: When the Pseudo-Rbridge has an issue, the underlying topology changes between P2P and MA, and this is a network management headache. non-cooperating rbridges ------------------------ For example, wrong IS-IS authentication password. Is it best to be transparent to other RBridges? Or let the network become partitioned? Resolution: make the network be partitioned TTL issues ---------- TTL is fairly straight forward to set for unicast. Less clear for non-unicast traffic? [Erik: I guess the issue is that the multicast tree might change while packets are forwarded using the tree.] CFT. CFT-IRT, how many trees ---------------------------- Silvano Gai: I believe the architecture draft needs clarification with respect to trees and who builds them (STP/IS-IS) Scalability, ECMP ----------------- Scalability: the basic principle is "do no harm" to scalability. Other than that, there is no specific scalability requirement. ECMP (Equal Cost Multi-Path). One person stated that ECMP is vitally important but they did not care very much whether TRILL implements ECMP or merely provided the information to support it. BCN --- Comment from floor: BCN (backwards congestions notification) is expected to be deployed in the datacenter. Should TRILL Support BCN? 802.1X? [Donald: 802.1X does not really seem relevant as it only related to access control at the network edge.] BCN (backwards congestion notification), size of CRED: Manoj: BCN is not limited to "small" networks, it can be used in large networks. Meant for enterprise networks with about one millisecond end-to-end latency. - Repeated Refrain: -- How much is Rbridge transparent to other IEEE protocols? -- On which ones does it do encapsulation? -- With which ones does it interact? Support large networks - replace routers? ----------------------------------------- This is not a goal of TRILL. Optimality vs. Orthogonality ---------------------------- Q: What is the design center? Should we optimize out every byte we can even if it reduces flexibility and unnecessarily entangles TRILL in other 802.1 protocols? Drop vs. process BPDUs ---------------------- Different models have been proposed. Discussion on whether this was part of architecture or protocol specification etc. RBridges may process BPDUs at their interfaces but BPDUs don't transit an RBridge. Should architecture documents have statements about no transient loops? Still to be done: ---------------- IEEE expert review; the chairs are working on this and the current plan is for Eric to attend 802.1 for one day next week and request expert review of the architecture document. Issues to solve or not? wiring closet interaction with non-cooperating rbridges TTL setting CFT - how many trees No transient loops between rbridges? No transient loops at boundary between rbridges and bridges? Outer VLAN and inner VLAN? Donald: I believe a discussion of VLANs and TRILL is clearly needed in one of our documents. Outer VLAN - should this result in one tree or multiple? Silvano Gai draft related presentation ====================================== draft-gai-perlman-trill-encap-00 Silvano indicated that he really didn't care that much whether Rbridge nicknames were 16, 18, 19, or 20 bits. If there isn't a separate multi-cast/broadcast bit, the nickname space is cut in half. 32K RBridges is sufficient for the foreseeable future. If they are assigned by picking a "random assignment and verify" technique, the space should probably be not more than 10% filled so 16 bits implies not much more than 6,000 RBridges. There was some confusion about the FCS is the diagrams in this presentation. It is not encapsulated. It is computed for the entire frame and there is only one FCS in a frame. As a matter of terminology, prefer to call the two RBridge designation in the shim "addresses" rather than "nicknames" and prefers "hop count" to "TTL". We need to be careful defining the hop-count/TTL=0 behavior in an egress RBridge. There appears to be increasing consensus for 2 RBridge designators in the shim: The ingress RBridge and the egress-or-F-tag RBridge. It is important to clarify how VLAN (Q) tags inside the encapsulated frame are handled. The current documents appear to be inconsistent on this. Multicast trees: we current have unidirectional IRT (Ingress RBridge Tree) trees. A suggestion was made with respect to tunneling frames to some other "root". However, bi-directional trees were said to be good. It means that at least some of the frames have shorter down-tree paths to follow. - Another suggestion was to have "signaling" between various multicast rooted trees for computation purposes. However, it was stated that IS-IS was already disseminating this information. Older refrain: Problem statement should have statements as to how RBridge interacts with other protocols. Statements should be like message processing SHOULD, MUST, PASS Transparently, DIALOGUE WITH IS-IS for these protocol sets. Radia ===== Radia Perlman presentation on issues remaining Radia reviewed the current proposal for handling IP multicast in TRILL multipathing for multicast -------------------------- Was originally expressed as different "metrics" but different tree roots seems to meet the requirement. To avoid calculating too many trees and exceeding computational capacity, for large networks of RBridges we could have each RBridge state how many tree it can support and its priority for being a root. A minimum number of trees should be computed, so that one Rbridge coming in and out does not create a lot of churn. - L3VPN/L2VPN have dealt with variety of trees, the group should look there for all the pros/cons LID announcements ----------------- Comment from audience that LID + Rbridge-ID = 32 bits, looks like IPv4 header format? Further comment that if we keep going that way we will re-invent IP routers :-) New format ---------- There is a new suggestion for a 16 byte shim header where the RBridge nicknames are encoded into the outer source and destination MAC addresses. (16 = 2*6 for MAC addresses incorporating RBridge nicknames + 2 for TRILL Ethertype + 2 for TTL and reserved) Q: Issue - if outer header has ingress/egress rbridge addresses. Bridges on inter-RBridge links will learn and as a result prune and/or misdirect frames. Perhaps use VLANs to avoid this? Joe Touch: Strongly against such additional complexity and over optimizations. Consensus? ========== LIDs? Not worth inclusion in fixed shim. F-TAG? Use "destination" nickname field to select tree as in Silvano's presentation for multicast/broadcast frames. Which multicast tree to use is selected by the ingress RBridge. Not all RBridges are a tree root. Open Issues: ------------ Revert to 6 byte header? Or 20? Optimize for point to point links or not? Joel Halpern: We need to decide on deployment cases before deciding what to optimize. 802.1ah header synergy? Comments from Don Fedyk, Ali Sajassi and Donald Oconnor that 802.1ah is going to be a standard encapsulation header. Minor issue: carefully define the semantics of the reserved bits (Joe has sent idea to list). TRILL Protocol Extensions ========================= There was insufficient time for Donald Eastlake's presentation of a proposal on how to extend TRILL so he suggested people download it from the Meeting Materials page and review it themselves.