Swissotel, Chicago, Illinois Monday, 27 March 2017. 15:20-16:50 Zurich B Room Chairs: Jon Hudson (self) Sue Hares (Hickory Hill Consulting) Secretary: Donald Eastlake (Huawei) Actual start time: 15:34 5 min. Administrativia (scribes), Agenda Bashing, Chairs Introductions, Note Well. Jon Hudson (co-Chair, self): Greetings. Please sign the blue sheets. Sue Hares (co-Chair, Hickory Hill Consulting): This will be more like a discussion. Please come up to the front of the room. The tables are convenient if you have a laptop. We can't make you move but I would love it if more of you were closer to the front on the room. Sue: This is the Note Well. How many of you have never seen a Note Well before? Good. It looks like all the others. You should read and understand. Sue: We are getting a lot of documents near the end of the process. I've been doing WG Last Calls and getting good comments. We have the active-active documents through. We are getting near the end of the directory assistance drafts and are going on to the multi-level and multi-topology drafts. Please read and review. Here is the agenda. ... [see Slides] 5 min. Status, Chairs Sue Hares: Document status. Sue: We have two drafts in the RFC Editor queue, two in publication requested, and two drafts returns to be revised. The ones returned are the ARP optimization and RBridge multilevel drafts. They will go through another brief WG Last Call. Please review them when they do. Sue: There are two drafts through WG Last Call that need revision: trill-over-ip and resilient-trees. Please revise them quickly after this IETF meeting. I expect to ping the authors about this. Sue: We have draft in WG Last Call. Please comments. We have drafts that need revision. Sue: We have done a lot of good work and need to push it towards RFC. We also have a bunch of drafts we have adopted. I'm gong to categorize them. We have sort of come to the end of operational issues. ... We are sort of to the end of several large pieces of work. This is a state where most WGs go into a hiatus. We have gotten to those shipping TRILL product what they needed. If not, please tell us. If there is something urgent, we can take care of it. Sue: We really want to get all the TRILL drafts into RFCs and then the WG will b going into hiatus. Please review including YANG documents. Milestones Sue: We are behind on some milestones because of documents being recycled. Current milestones show us going into hiatus in July. I don't think we will make that but perhaps by the end of the year. Let me give you an example of another WG that did this. The BGP WG did a lot of work, then went into hiatus for a while, and then came back to do a new batch of work. 8 min. YANG module draft development, Sue Hares Sue: Our YANG models got ahead of other people's YANG modules. So Tissa started up LIME WG to spread the TRILL OAM model but LIME is winding down. So we are faced with three options: 1. WG Last Call all three existing TRILL YANG modules and send to IESG even though consistent with LIME. These modules have been implemented. 2. Change TRILL PM and OAM YANG drafts to be LIME compatible. Implementers of 1 don't want this. 3. Do both. Yizhou Li (Huawei): I want option 1 also for our implementation. Sue: Cisco also wants that and I think it is reasonable. We will probably go with #1. Anyone wanting #3 should speak up THIS WEEK. If you don't want to come up to the microphone, speak to me after the meeting. Sue: ... some details of differences between LIME and TRILL OAM YANG models ... 14 min. FGL in TRILL Header, Mohammed Umair (Remote) [see Slides] Mohammed Umair (IPinfusion): This presentation covers three problems with the current TRILL FGL encoding (RFC 7172). ... We propose changes in the FGL packet structure. Mohammed: Current frame structure ... FGL is discontinuous. ... Wasted space with duplicated Ethertype. ... We propose to move the FGL inside the TRILL Header. ... Slide 6 shows this as adding an FGL Header after the TRILL Header. Also adds an Entropy Label to avoid deep packet inspection. ... Suggest indicating this with a new value of the TRILL Header version field. ... Priority field indicates where the priority comes from which indicates how many bits of priority / ToS / DSCP there are. ... Entropy Label ... Fine grained label ... reserved fields. Mohammed: These changes are based on customer requirements. Entropy label makes load distribution easier. Improves QoS in TRILL. Help to achieve different modes of service easily: VLAN-based, BLAN bundle, VLAN-aware, etc. Mohammed: Comments are welcome. Sue: You said you have customers that need this. Can you provide some information on the customer scenario? Mohammed: We don't have a specific customer right now but we can see that customers needing something like FGL have problems with putting the FGL inside the inner packet header. Also the entropy label will help with load distribution and decrease the need for deep packet inspection in the core switches. Currently, we are sometimes using outer VLAN label. ... Sue: Summarizing: you have some customers with data centers that need the ECMP and other outside data centers that need VPN with the fine grain labeling. Plus QoS requirements that were not completely clear. There was some sound problem on the Meetecho connection. ... Jon: How tightly bound is the benefit to your proposal? Do you have alternatives lined up if you can't get this achieved? What is your Plan B. Mohammed: I don't have any plan B as of now. ... Donald Eastlake (Huawei): The existing FGL standard has not been implemented in merchant silicon which is kind of a problem. This proposal by making the FGL field contiguous should make it easier for network processors to handle and make it easier to incorporate into merchant silicon. One other minor point: These slides propose changing the version number which is a big deal. There are other ways of doing it using some available critical flags in the TRILL Header. Setting any of those bits causes TRILL switches to reject the packet. Using one of those would avoid changing the version number. For example one bit in that area is used to indicate that the optional flags word it present so you could use another bit in that area to indicate that the FGL was present. Jon: Yes, there are no merchant silicon implementations. But there have been custom ASIC implementations. Margaret Cullen (Painless Security): What draft is this in? Mohammed: There isn't a draft. Margaret: OK. Looking at Slide 8 it sounds like we are going to have a new header version that says there is an FGL header but there is a bit in the FGL header that says it is a valid FGL header. What does it mean if that bit is not set? That it is an invalid FGL header? I don't quite understand... Sue: I'm not too upset about that as I have seen it in other routing drafts that are trying to create versions of headers. Mohammed: We can think about this. There are invalid FGL headers, such as an FGL of zero. Right now it just indicates that the frame needs to be dropped. Margaret: This I had a question about the two-bit priority field. Deciding what to do by looking at some bits and then a field seems computationally more expensive that just somehow encoding it into one field, which could be up to 10 bits. It would be nice if we could map these into one field. Maybe we can't do that... Mohammed: This is two fields to indicate where it was copied from which influences where to copy it back. Some customers want to do that when it leaves the TRILL campus. Margaret: So these fields might be modified in transit? Mohammed: Yes. ... indicates to the edge RBridge where to copy it back. Margaret: I'm pretty sure it isn't safe to modify all these... Donald: There seems to be enough space to copy these various priority/QoS fields there but at some level the current TRILL architecture assumes that there is always a 4-bit handling priority for a TRILL packet. The TRILL outgoing ports are bridge ports and have these queues... Having additional info is good but it would be nice to always have the 4-bit summary for handling. [3 bits of priority plus one bit of drop eligibility] Margaret: Attempts to calculate entropy works better if you have one way to do it. I would need to see actual text. You need to talk with security people to be sure what you do will result in an even distribution. Sue: Any other questions? Jon: There were things we wanted to do but didn't do because of fear of changing the TRILL Header. We were worried about it disrupting the market. But since there are no merchant silicon chips supporting this and the customer ASCICs are no longer shipping, as far as I know, we should maybe consider this now. Sue: A final questions: Is this proposal expected to be hardware or software? Mohammed: Hardware. Sue: Good information. Thanks for putting up with the remote presentation and getting up early. I think it is 5:30 or 6am for you. Mohammed: It is 2:53am here. Sue: Wow! 6 min. Fine Grained Labeling Backward Compatibility Donald Eastlake [see Slides] Donald Eastlake [Huawei]: ... I'm just presenting a few slides related to FGL backward compatibility. ... history of tag stacking ... If something like Umair's proposal was adopted, you might have different TRILL switch ports on the same like that supported different FGL encodings. So you would really need to indicate which was in use in the Port capabilities or possibly in the switch capabilities. Probably best to be per port. ... If every port on the link used the same format, its great. You could have a port that supported both formats. If you have incompatible ports, the safest thing would be to just not send any FGL traffic on that link. This should be a rare situation - in cases where the network is not well managed. But you do need to check because incompatibile formats could cause traffic to go to the wrong VLAN or wrong tenant, violating security policy. ... That's really all I wanted to add. Sue: Any comments? [there were none] Donald, what was your intent, to just work this out with Mohammed Umair. Donald: Yes, we need to produce a first draft which doesn't have to be totally complete but it would be good for it to mention all issues. 6 min. TRILL Parent Selection, Ramkumar Parameswaran [see Slides] Ramkumar Parameswaran (Brocade): ... This draft solves a known problem The parent selection rules in the TRILL standard can cause a parent to shift when it is not necessary. The draft presents two methods to fix this. ... Example of problem. ... Ramkumar: This causes problems by interrupting multicast traffic. There was a real financial customer that was having this problem. So we have been looking for a way to solve this. There are two solution we have come up with: Ramkumar: The first solution is to use the Affinity TLV, which is a sub-TLV of the Router Capabilities TLV. It is used in other scenarios in TRILL. It is published by the parent. ... Configured by the operator. ... Ramkumar: The second solution is a little harder to implement. You modify the Dijkstra algorithm so that it tries to match your previous tree construction. ... This might work and seems better suited to smaller networks. ... Approach 1 is preferred. It is guaranteed to work and uses facilities already in TRILL. But solution 2 is included as a back up. ... Ramkumar: I am requesting that this be adopted as a TRILL WG document. There are a few mistakes in the current draft, I plan to upload an improvement after the meeting. One question I have is should the second solution be fully worked out and carried through? ... Or perhaps approach 2 could be a separate draft. ... Currently the draft is Experimental. Can it be changed to Informational? Sue: The Affinity TLV you are using, is that a modified version or is it the currently standardized Affinity TLV. Ramkumar: It is unmodified. Sue: So are you changing how the Affinity TLV affects things? Ramkumar: No, really no change in semantics of Affinity TLV. Sue: So, it is not really changing anything and it sounds like Informational. If there are customers with problems, this sounds like an excellent solution. You should state these things to the list. ... Sue: Other questions? [none] Sue: Thank you for an interesting presentation. I've seen similar problems in other protocols. 8 min. Smart End Nodes, Fangwei, Hu Actually presented by Donald Eastlake. [see Slides] Sue: Fangwei Hu made some modifications to the draft. Donald Eastlake will be presenting the slides. Donald: Fangwei was not available to present and the changes in this draft are mostly due to my comments anyway. ... History ... Changes from -04 version of draft ... Do these changes put the draft in good enough shape to start a second WG Last Call? I think so. ... Sue: Any comments? The biggest change was in handling multicast. Donald: Yes, the previous draft just didn't cover all the cases. There is also another draft on directory assisted encapsulation which might be WG Last Called at the same time since there is some similarity. Sue: That sound reasonable. Sue: OK. That's about the end of this session. Thanks for your attention. Donald, can you post to the list asking if there are any further questions on the draft? We should be able to start a WG Last Call shortly if there are no further questions or they can be resolved. Ramkumar, could you post about the customer needs prompting your draft? Sue: Please sign the Blue Sheets if you have not done so. Thanks again.