TRILL WG Meeting, March 21, 2007, Prague, Czech Republic Chairs: Erik Nordmark, Donald Eastlake Minutes taken by Dinesh Dutt, augmented and edited by the chairs. Despite repeated requests, no volunteer to be jabber scribe could be found. The Agenda actually followed by the meeting was: Administrativia (scribe etc), Agenda Bashing, Chairs Charter milestones, Chairs Interaction of RBridges and 802 Protocols draft-eastlake-trill-802-protocols-00.txt, Donald Eastlake The Architecture of an RBridge Solution to TRILL draft-ietf-trill-rbridge-arch-02.txt, Eric Gray Rbridges: Base Protocol Specification draft-ietf-trill-rbridge-protocol-03.txt, Radia Perlman, Silvano Gai, Dinesh Dutt Changes from -02 to -03, Silvano Gai, Dinesh Dutt Getting from -03 to -04, Silvano Gai, Dinesh Dutt Multicast Input Link Filtering, Radia Perlman VLAN Learning, Radia Perlman RBridge Protocol Extensions, Donald Eastlake - Our charter required us to submit the architecture document and later the base protocol spec to IEEE/IETF expert review. - Silvano wants to have the current architectural document revised heavily before submitting to IEEE 802.1 for review. - Donald says that we don't necessarily have to review the specification that heavily and are only required to get comments from the IEEE in specific areas. - Donald presented a brief summary presentation on his draft draft-eastlake-trill-802-protocols-00.txt on 802.1 and 802.3 protocols and how they relate to TRILL + Dinesh commented that we should define a model about how we related to 802.1/802. and not have to specify for each 802 standard + Radia agrees + Joe Touch suggests talking about classes of standards and take a stab at each class + Silvano suggests using EISS as the model from 802.1Q but pointed out that would include BPDUs + Donald agrees that we standardize RBRidge forwarding and nothing else but for example, we might, give some informative guidance as to what RBridges should say in 802.1AB (local discovery) frames they emit if they happen to support that standard - Eric Gray spoke about the current Architecture Draft draft-ietf-trill-rbridge-arch-02.txt + IEEE's reaction to Eric's presentation wasn't adverse. They were critical of some points in the documents that were provocative. Those should be easy to fix. + Eric's been to a few IEEE meetings and thinks that IEEE's attitude is essentially "we don't care". + Silvano comments that he's going to post a detailed review of the arch doc. He states that the arch doc has an implementation model and doesn't need to do that. There's too much description according to him. + Eric asks Joe Touch's opinion of heeding Silvano's points since, for example the table names in the architecture draft came from the earlier document by Joe. + Joe states that it is intended as advice by example, not a requirement. Joe provided an example of TCP protocol spec having a control block description. + William Jensen from U Wisc states that they did a lot of work on ethernet switches that specified a lot of detail. We have to make sure that we don't forget what switches do. + Margaret Wasserman says she has read the two documents and finds them confusing together. She states that not only should the documentss be consistent with each other but also should use concepts in the same way. + Silvano suggested that he and Eric start to drive more consistency by taking the top 10 (approximate) terms in the architecture and protocol documents and come up with terms that will be used in both documents. That seemed to be a reasonable way forward. + Radia says that there are 2 docs and that is confusing and is not sure why we need a separate architecture document. + Mark Townsley states that the protocol specification is what is important. He says that he doesn't care if the requirements/architecture documents doesn't become an RFC as long as the protocol specification is what is defined. + Dino wants 4 docs: the forwarding, the IS-IS routing, interaction with 802.1D, and a architecture specification that ties these three together. - Silvano's presentation: Changes from -02 to -03 (version of protocol specification) + Dino wants to know if we'll define the TRILL header to be 64-bit aligned. + Silvano responds that it isn't now but would be if you add some bytes as Donald will suggest later. + Joe asks if we've captured some of the design decisions in a document somewhere and state why some decisions were made. + Radia says that she has tried to do this on the mailing list + Some adjustments were made to some of the slides. Removed "SHOULD" in connection with computing one distribution tree for every RBridge. There was a dispute over the right RFC 2119 word to use for defaults. Dino says that if this is the default, then it should be MUST. Erik says that it should be explicit what the default is and whether the system MUST/SHOULD/MAY have a knob to change the default. + It was pointed out that the 16 bit fields use to refer to RBridges were referred to as both "TRILL addresses" and "RBridge addresses" in the specification. Radia suggested they should continue to be called nicknames because they are a new thing and that is a single simple word that correctly connotes that they are short stand-ins for longer fields. Silvano says he wants to use "address". Radia replies that this is confusing because there are so many different addresses. So you have to qualify it and say something like "TRILL address". ID was suggested but that refers to the 48-bit identity of IS-IS nodes. The chairs did a poll of the room which showed 7 for "nickname" and 2 for "address". The chairs will confirm the rough consensus for "nickname" on the mailing list. (During the poll some participants didn't like either term, but they couldn't offer any better suggestion either.) + Silvano commented on ARP/ND optimization being SHOULD. Eric responds that this could be an incredibly important optimisation as it may eliminate broadcast. + Dinesh says that we can't forget non-IP traffic. + Erik says that ND is quite complicated with SEND and such. Maybe it should be in a separate document. Silvano wants to pick only one implementation out of the three possible behaviors for ARP/ND in the current specification. + Radia does not like hop limit although that is the term used in IPv6. She recommends "hop count" which is what is used in the Algorhym v2 poem. There is no objection to this. + Silvano says he is happy to go along with whatever the group decides on the terminology issues. - Dinesh's presentation: Changes from -03 to -04 (version of protocol specification) + There was a discussion of IVL versus SVL (independent VLAN learning and shared VLAN learning) and those in the room appeared to lean towards just doing IVL in RBridges; however, the consensus was to investigate SVL further. Similarly, those in the room appears to lean against supporting GARP or any of it derivates in RBridge. + There was a discussion of which version of spanning tree to support or recommend (STP, RSTP, or MSTP) in the "leaf" bridges currently spec'ed to be at RBridge ports. Using STP may cause bridges to downgrade from RSTP to STP. MSTP can be configured to isolate STP only bridges. Radia said that it didn't really matter between STP and RSTP as they are compatible and basically the same protocol but she wasn't sure about MSTP. This may require some further investigation. - Radia's presentation on Multicast Input Link Filtering + Silvano asks the question whether this will fix all loops. Radia responds that, in a distributed protocol such as IS-IS or RSTP, it is always possible to have transient loops due to a repeater coming up or dropped frames, etc. Of course we should try to make the probability extremely small. + Dino mentions that there is a performance impact of doing the "reverse path filtering" based on a 48 bit system ID. A response was that the filtering could be on the (16-bit) nickname. - Radia's presentation on VLAN Learning + Eric raises the question of how SVL interacts with per-VLAN STP + Radia also raised the issue of whether we need a per-VLAN Designated Rbridge election + Eric says that you cannot simply dismiss SVL by saying it's too complex to discuss - Donald's presentation on Extensions and Q-tag Information Location + Silvano said extensions should be fixed length and indicated by an Ethertype + (note: there was very little time for discussion or questions as we had run into the end of the session)