Raffles City Convention Center, Singapore TRILL WG Meeting Minutes Monday, 13 November 2017. 17:40-18:40 VIP A Room Chairs: Sue Hares (Hickory Hill Consulting) Jon Hudson (self) Secretary: Donald Eastlake (Huawei) Times given are as originally scheduled, not actual. 5 min. Administrativia (scribes), Agenda Bashing, Chairs --------------------------------------------------------- 5 min. Status, Chairs ---------------------- Sue Hares (co-Chair, Hickory Hill Consulting): Should we start or wait for a bit? ... Welcome to TRILL. Say hello to Jon [Jon Hudson, co-Chair attending remotely]. Document status - we have a whole bunch of documents to push through before the next meeting. (see "Agenda and Status" slides) Sue: Hello guys [a bunch of people come in], it is hard to find this room isn't it? We have two new RFC published since last meeting: "Alternatives for Multilevel TRILL" and "TRILL MTU Negotiation". the ARP Optimization draft went to the RFC Editor's queue today! We have two drafts in publication requested state for Alia. And we have four that need Shepherd reports to be completed. Wasn't a new version posted today of the p2mp draft? Donald Eastlake (Secretary, Huawei): That was just to stop it from expiring and incorporate some simple fixes that had been agreed to by the authors and the RTGDIR reviewer. Need to get the reviewer to sign off on the changes. Sue: [reviewed other WG drafts] ... TRILL Over IP draft has been respun. Alia, we plan to take NAT out since it is a lot of work. Is that OK? Alia Atlas (AD, Juniper): OK. Donald: We can just say NAT is out of scope. Someone can work on it later if they want. Sue: YANG drafts will come through later with the revised datastore. The idr-ls-trill draft is in WG Last Call so please comment/support on the IDR mailing list. Donald: Just so you know, this draft is so that you can transmit TRILL link state in BGP. Useful for SDN and the like. Sue: Then there are some drafts for possible adoption. We decided to drop the trill-link-security draft but there are two others. Donald: Right, the other two are relatively mature. The trill-vendor-channel is just an easy was for vendors to specify their own RBridge channel messages by using an OUI. If the WG isn't continued, it may be harder to get things through the standards process and this would provide an escape valve. The trill-rbridge-data-encoding is a bit more complicated. It provides a more efficient encoding on the wire. It is quite mature. Of the two, the trill-vendor-channel is simpler and easier. The data encoding draft started a long time ago and at the time chip vendors said they wanted to hold off on implementing it to see how TRILL went. As far as I know, it has not been implemented in hardware. Alia: I understand you motivations for vendor-channel. That one makes a lot of sense to me. But the data-encoding draft seems like more of a stretch. So unless there is serious interest, I suggest we drop it. Sue: OK, we will go back and see if there is serious interest. Alia: I want to close down TRILL before or at the next IETF meeting [March 2018] and I do not have agreement from any of my co-ADs to AD sponsor anything in TRILL. Sue: So we need to get this stuff through. Best would be to have it through by the end of December so we can work it through the IESG in January / February. We have to push these WG Last Calls. Alia: Some TRILL documents I reviewed in the past just sat for months without my comments being responded to for a long time. Going forward, that is NOT going to work. If it takes a month to respond to my comments, the document is not going to progress. ... 12 min. Smart Endnodes, Hu Fangwei ----------------------------------- draft-ietf-smart-endnodes-06.txt Fangwei Hu (ZTE): (see "Smart Endnodes" slides) Draft updated to version -06. Motivation ... History ... Current status is "Waiting for Write-Up". Changes since last presentation: Clarified that smart-hello is a type of TRILL ES-IS [RFC 8171] message... Clarified that only the pull directory method is available and push directory (ESADI) is not supported... Clearly specify the multiple-entries solution to solve the MAC flip-flop issue in multi-homing... Add TRILL ES-IS to the terminology section... Ready for publication? Sue: Good clarifications and additions that were requested by the reviewer. I think we are ready. Let me ask some questions: Have you responded to the reviewer's comments? Fangwei: Yes, we changed the draft. Sue: I know you changed the draft but have you gone back to the original commenter and ask them to verify the fix? Fangwei: OK. I have sent them email... Sue: I'll double check on it... Thanks for doing what we asked last time. I'll push for publication. Alia, another one for you. 12 min. Group Keying for TRILL Update, Donald Eastlake ------------------------------------------------------- draft-ietf-trill-group-keying-00.txt Donald Eastlake (Huawei): (see "Group Keying for TRILL Update" slides) I'm going to talk about this WG draft and what needs to be done to finish it up. Some TRILL protocols need security, authentication and encryption, and for that to work you need to get keys distributed. To meet modern security criterion, you need some way to dynamically negotiate and update keys. You can also support fixed configured keys but if that is all you support, you don't meet modern criterion. Donald: All existing TRILL security is unicast, that is, point-to-point. TRILL over IP uses IPsec with IKEv2 key negotiation and RBridge Channel messages use DTLS. Which is fine but these messages could be multicast... You can always just use serial unicast but to get the efficiency advantages of multicast, you need to distribute keys to the recipients somehow. There are various approaches. ... The idea in this draft is to use approach 2, shared secret keys. ... The existing draft specifies a generic way to distribute and manage group keys and assumes that generic way will be profiled for any particularly use. The draft includes two profiles, one for TRILL over IP and one for RBridge Channel messages. ... Donald: I'm proposing to split this into two draft. One with the generic group keying specification and one with the two TRILL specific profiles. Only change to the group keying specification would be to add algorithm agility for the key wrap algorithm part of the specification. On the profiles, the RBridge Channel profile is complete, the TRILL over IP profile needs a bit more work. ... I propose posting a message asking if there is any objection to doing this and if no one objects, go ahead and do it. Sue: Can you send off that request today? Donald: Yup. [see https://www.ietf.org/mail-archive/web/trill/current/msg07962.html] Alia: To clarify, I'm happy to push these drafts through. I want to get this stuff through now because I feel that the WG does not have the energy for a prolonged effort. More time will probably not help. It has nothing to do with the quality of the documents. They have been excellent, so I usually have few AD comments on them. It's good work but if just needs to get finished... 5 min. Wrap-Up, Chairs ----------------------- Sue: OK, I think that's the end of things for this meeting. We could really use help pushing these documents through. Thanks for all the hard work.