Conrad Seoul Hotel, Seoul, Korea Wednesday, 16 November 2016. 11:10-12:10 Studio 2 Room Chairs: Jon Hudson (Individual) Sue Hares (Hickory Hill Consulting) Secretary: Donald Eastlake (Huawei) (Times are as originally scheduled, not time actually taken. Jon Hudson, co-Chair, was unable to attend but participated remotely. There were some technical problems which delayed the start of the meeting.) 5 min. Administrativia (scribes), Agenda Bashing, Chairs ========================================================== https://www.ietf.org/proceedings/97/slides/slides-97-trill-agenda- status-05.pdf Donald Eastlake (Huawei, Secretary): We are having some technical problems so there may be a little delay. ... [Some back and forth between Donald and Sue Hares - originally Donald's machine was going to be used to project but switched to using Sue's.] Donald: Hi there, this is the TRILL Working Group and we are going to get underway. I'm Donald Eastlake from Huawei and this is Sue Hares, co-Chair, from Hickory Hill Consulting. I'm the Secretary and Jon Hudson, the other co-Chair was unable to be here. Alia Atlas is our AD. Here is the Note Well, which you have probably seen before. It gives the IPR rules or pointers to them. You should study that. Donald: The quality of the documents that we and other groups in the IETF produce depends on review. If you want people to review your documents, you should review other people's documents. That way everyone's documents will be better, most likely. Donald: This is our agenda. I'm going to present on group keying, then Sue will present on the proposed new Charter, then we have a remote presentation on Parent Node Shifts in Tree Constructions. Donald: News since last meeting. 4 RFCs published. ... 2 drafts have passed WG Last Call. ... There are 3 drafts in WG Last Call including ARP/ND Optimization, which was sent back by the IESG and has been substantially modified. ... And we have adopted the ECN Support draft. And here are a few more slides showing all the other WG or related drafts. Sue Hares (Hickory Hill Consulting, co-Chair): One of the things we are looking at next is the Data Center stuff for TRILL as it is deployed. 12 min. Group Keying, Donald Eastlake ====================================== draft-eastlake-trill-group-keying https://www.ietf.org/proceedings/97/slides/slides-97-trill-group- keying-01.pdf Donald: I'm Donald Eastlake with Huawei Technologies. TRILL has some communications protocols that it standardizes. For these protocols you don't, in general, know how secure the connections between the ends are, whether or not they are in a controlled environment. So you want to be able to secure them and there are two aspects to that. One is the format of the packets and encryption algorithms. The other is keying. You can't be sure without good keys at the end points. And modern standards, as very strongly encouraged by the Security Area of the IETF, requires key negotiation. You can have manual keying also available, but you need a way to generate new session keys and the like. Donald: Two area where TRILL has keying needs are RBridge Channel messages and TRILL over IP. There are other types of links besides IP that TRILL supports. For example Ethernet, but Ethernet has its own security specified. We are mostly concerned with link types that TRILL has specified. So, unicast is pretty easy -- you just need to get the key to the end points and how to do this is usually already specified. So, for example, the RBridge Channel RFC just says use DTLS and DTLS already has modern key negotiation. Similarly, the IP draft says just use IKEv2 for key negotiation but this is point-to-point. Donald: Under may circumstances, multi-destination traffic can be more efficient, reducing link utilization, but is trickier for security. RBridge Channel has multicast built in and IP has multicast specified although it is not already supports. There are different ways to do multicast security ... This draft supports using a shared key which is efficient but means you can not authenticate the originator of a packet. What it specifies is somewhat generic and builds on unicast security, which it assumes is already in place. In effect the group key is serially unicast to the group members. This is similar to how group security is done in Wi-Fi. ... draft-eastlake-trill-group-keying specifies that one member of the group serially unicasts the key to the group members with provisions for key rollover. Here are some details of the messages. ... Gives an example of a group with 5 members. Any questions? Yizhou Li (Huawei): Is this group keying protocol hooked to the membership update. For example a new member joins or there is leaving. Donald: Yes, there is material on that in the draft. If a new member joins the group, that is not usually a problem. As soon as it has secure communication to the designated group member, the designated members can send it the current group key and perhaps any future keys it wants. ... When a member of the group leaves, in general what you should do is rekey all the remaining group members. And the draft says you should do that but, since it is intended to be a fairly general draft, it says that sometimes, if you have very dynamic group with members joining and leaving frequently, it may be impractical to rekey that often. So you have to apply some judgment based on the application. Yizhou: OK, I see. Donald: Any comments on the draft would be welcome. Sue: For this draft, it would be useful to take a look. Rekeying is important because if you are in the middle of a data center or deployment, data can get attacked and it is good be to able to rekey quickly. Donald: Perhaps I should have arranged to present this to SAAG this meeting. I can try to do that next meeting. Depending. I could see if they have any time, they usually meet Thursday afternoon. 12 min. Review of draft revised Charter, Chairs ================================================ https://www.ietf.org/proceedings/97/slides/slides-97-trill-charter- update-00.pdf Sue: I'm going to go over the Charter changes. The focus has been from the AD to try to get things that support TRILL deployment. What's missing [that might be slowing down that deployment]? We are down to the ARP/ND draft for the second time and the directory assist mechanisms has been reviewed. The pseudo-wires is done. We have done some work on the multi-level and multi-topology. ... We've been adding ECN support and transparent mode to provide better input inside data centers. It would be good to see if this really matters to deployments you are working on so feedback would be good. We plan to do a last call on the Charter within a few weeks. ... transparent mode ... other payloads such as IP. We'll post this new Charter in a couple of weeks. Some things a stuck with the AD right now but she is a bit overloaded as she was ill for a while. So that's about it. Sue: I'm going to have to ask for your indulgence. I have to appear elsewhere so I will go out for a bit and leave Donald with it to take care of our remote presenter. Donald: Thanks, he is on line. ... One moment... [a bit of delay in getting the remote presenter on] 12 min. Parent node Shifts in Tree Construction, Mitigation ============================================================ Ramkumar Parameswaran (Brocade) draft-rp-trill-parent-selection https://www.ietf.org/proceedings/97/slides/slides-97-trill-parent- node-shifts-in-tree-construction-mitigation-00.pptx Ramkumar Parameswaran (Brocade): OK, can you hear me? Donald: Yes, we can hear you now. Ramkumar: OK, I can get started. This talk deals with the default TRILL tree construction rules where they change the parent of a node. I am Ramkumar Parameswaran from Brocade. Ramkumar: The subsequent slides will show what the problem is. The TRILL rules can shift the parent node of switches even if there is no shift in the links or the availability of the parent. This draft proposes two different solutions to that and we can go through the reasons for them. I am aware of cases where customers have been impacted by this. If this is important enough, we can request adoption of this draft. ... [reviews existing tree construction rules including RFC 7780 and base RFC 6325] Slides how a spine-leaf network topology. Assume equal cost links. ... [reviews detailed example of the problem in slides] Ramkumar: There are two solutions proposed. One uses the Affinity TLV. The Affinity TLV can be used to fix the children of a switch. Can have a CLI option on a node that it should be sticky in holding on to its children. The way I envision it, you would not necessarily configure what those children were, just that the parent is sticky. I think the draft talks about the first tree construction using the TRILL rules and subsequent ones using the Affinity TLV but you could do it in various ways. ... The node would retract an Affinity TLV if the children are no longer connected or the like. Ramkumar: The second approach uses a modified version of the SPF algorithm. If a node you are pulling into the tree can be pulled by multiple parents, at the same cost, this solution allows you to insert a policy filter that chooses the node. This helps by having the policy filter favor the parent you have in the previous iteration of tree construction. ... [reviews example with the 2nd solution] The challenge with the approach is that you are using a time latch in a distributed system and everyone has to agree on what the previous tree was, which can be a bit of a problem. But you should be able to make this work in small or medium size networks. ... So the Affinity TLV seems more predictable -- only problem is if someone has a patent on the first approach. Neither of these approaches has any IPR at Brocade. Any questions? Donald: I think this is an important problem. I understand the first solution. The second, I'm not sure just what policies you might want... But the only question I have concerns another draft called draft-ietf-trill-resilient-trees that answers a slightly different problem, not the stability but rapid establishment of a new tree after a failure. The resilient tree draft is fairly far along. The question I have is if it can be used to help the problem you are talking about. It might be good to look at that draft. Ramkumar: I have gone through that draft. I believe they use a different tree algorithm altogether and you come out with two trees, right? This is more oriented to using the traditional Dijkstra algorithm. Donald: Yes. At least it would be good to be sure that if we adopt the first approach you present there was no conflict. If there was, you would have to say something about that. Ramkumar: OK, I will take a look at it and get back on the list. Donald: OK, this would be good thing to discuss on the list. Donald: I guess I'm Chairing. [Sue had not returned] Any other comments on this presentation? Donald: Thanks for the presentation. I'm not sure how to get back to the agenda since I'm not used to this machine. But I think it only had one more slide. Donald: [reviewed the milestones] We have an increasing number of milestones overdue so perhaps we should adjust them with the adoption of the new Charter. 5 min. Wrap-Up, Chairs ======================== Donald: That's the last item we have in the agenda. Anyone want to bring up any other topic? [no response] OK, thanks for being here. The next meeting is in Chicago. So see you on the list and at the Chicago meeting. =====================================================================