IETF 94 TRILL Working Group Meeting MINUTES Pacifico Yokohama, Yokohama, Japan Chairs: Sue Hares (Hickory Hill Consulting), Jon Hudson (Brocade) Secretary: Donald Eastlake (Huawei) Notes by Donald Eastlake, edited by the Co-Chairs. Times given are those originally scheduled. Session 1 of 2 Agenda ===================== Date: 2015-11-03 Room: 411/412 Time: 15:20-16:50 ================================================== [Since Jon Hudson (Co-Chair, Brocade) was unable to attend the meeting in person due to Jon and his wife having a few week old baby, Donald Eastlake (Huawei, Secretary) sat at the head table and acted as a Co-Chair.] Meeting Called to order. [Sue Hares (Co-Hickory Hill Consulting) and Donald Eastlake tried to persuade people to sit closer to the front to make it easier for them to participate.] Donald: Note the Note Well. Agenda bashing [15:20-15:25] ------------------------------------------- Donald: Here is the agenda. We have two sessions, one today and one Thursday afternoon, the last slot Thursday. The one today is 1 1/2 hours. The one Thursday is 1 hour. ... We will also review proposed updated milestones. Anyone have any suggested changes or additions or deletion? [pause] I guess not. We can alwys make changes later if desired. Status [15:25-15:35] ------------------------------------------- [Donald reviewed the state of the existing TRILL RFCs.] Donald: Here are the drafts in the RFC Editor's queue. Three are the active-active drafts. ... Also the OAM MIB draft and the RFC7180bis draft giving the latest TRILL Clarifications, Corrections, and Updates. Then we have drafts that have passed WG Last Call and need a bit of tweaking and paperwork before publicaiton is requested. I'll talk about the ones related to Directory Assistance later. There is also trill-irb and the tree selection draft. ... Sue: I'm Shepherd for many of these drafts. Some of these drafts have English that is not up to par. We have been taking the English polishing after WG Last Call since this isn't technical, just English polishing. Alia Atlas (Juniper, TRILL AD): I would actually prefer that the language be fixed before WG Last Call because confusing language can make it harder to undertand the technology issues in the draft. The drafts that have come to me have been in good shape. Sue: Donald and I have been cycling the documents after Working Group Last Call and before IESG but we can do it before WG LC if you like. Alia: I would be more comfortable with that. Sue: OK, we will the do an editing pass before WG LC. Donald: [inaudible] Sue: On the YANG drafts, I will be trying to talk to the YANG co-ordinators this week. Donald: There is also a draft in the IDR WG on transporting TRILL IS-IS information in BGP. And there is a draft in call for WG adoption which is an updated of RFC 6439 about the Appointed Forwarder mechanism. TRILL OAM is almost all through. The Active-Active area is in good shape. The next major, that is multi-document, efforts in our charter are the Directory Assistance and Multi-Level / Multi-Topology. And there are some other single draft efforts. Donald: Here is a list that Sue and I came up with for adjusted TRILL WG miltesones. The ones in black have just had their date adjusted while the two in blue are new. It is not necessary that everything the WG does have a milestone. ... Most of these, actually all, are based on the Charter. I think the thing to do is to post this to the mailing list and discuss further on Thursday after people have had a chance to look at them. Alis: One question, what is the purpose of the TRILL implementation draft milestone? Donald: Well, it is an item in our Charter. Sue: This comes from when we were in the INT area. They wanted to know. They wanted us to write a draft. Alia: I really like wikis. Then you can just keep it up to date. When you go for Internet Standard, then we will need an implementation report. If the WG has a strong sense this is necessary... Sue: This was pushed down, not bottom up. We will put it in a Wiki. Donald: That's easy. Directory Assisted Edge Status [15:35-15:45] -------------------------------------------- draft-ietf-trill-directory-assist-mechanisms-03 draft-ietf-trill-ia-appsubtlv-05 draft-ietf-trill-directory-assisted-encap-01 draft-ietf-trill-arp-optimization-01 Donald Eastlake (Huawei) [see Slides]: The directory idea is to have the edge RBridges know where MAC addresses are so they can route to them without having to do data plane learing and so they can discard forged source addresses because they know where things are supposed to be. It is intended primarily for Data Center things where you have an Orchestrator that knows where everything is. The existing problem statement and high level solution RFC describes push directories that push the information out to the edge RBridges and pull directories where the edge RBridges can ask for the information they need. Donald: What is in the directory is basically information on an end station interface [port] such as its MAC address, its IP address, which edge switch it is connected to, optionally which edge bridge port it is connected to, and the like. ... [described what is in each draft] There is also the TRILL Channel draft which is related because it is used for security of pull directory messages. ... Here are the depencies of this drafts on each other. ... Here are pointers to the slide sets for the most recent presentations on each of these drafts. Smart End Nodes [15:45-16:00] ------------------------------------------- draft-ietf-trill-smart-endnodes-02 Fangwei Hu (ZTE) [see slides]: Three motivates: save on the edge RBridge MAC table by moving it to smart end stations, quickly refresh table in smart end node, and lastly, because smart end station can do TRILL encapsulation / decapsulation it supports fine grained label aware end stations. Edge RBridge received TRILL encapsulated packets from smart end node and send them to smart end node. ... Changes from -01 to the -02 drafts: figure added to show things more clearly, second, clarified tha the Smart Hello is carried in a native RBridge Channel message, third added figue for the muti-homing scenario. Finally, some editorial improvements. Fangwei: Next Step, ready for WG Last Call? Sue: Thank you Fangwei. Based on Alia's comment, the Shepherd will go through the English, which may take another revision. Any questions? [none] OK, then I expect we will be doing the Last Call soon. Watch your mailbox for editorials. DCI using TRILL [16:00-16:20] ------------------------------------------- draft-muks-trill-dci-00 draft-muks-trill-transport-over-mpls-00 Kingston Smiler (IPinfusion) [see slides]: This is a proposal for Data Center Interconnect [DCI] using TRILL. Some background: At the last IETF we gave a presentation on TRILL over MPLS. We introduced some concepts like VPTS [Virtual Private TRILL Service] and TRILL over VPLS. We will use these concepts in this presentation. ... This draft concentrates on using TRILL for DCI using these concepts. ... We give some used cases and benefits. Kingston: Introducing terminology: VTSD is like a TRILL RBridge inside the DCI layer which can be a peer router thats provides the connectivity from your Data Center to the provider network that acts as a transporter. This is a logical virtual RBridge that runs at all your sites where you want to provide DCI connectivity. It eliminates the need for split horizon since TRILL can eliminat loops. Kingston: Three main benefits of VTSD: Multiple parallel links ..., Active-Active forwarding ..., and Support for Ring topology ... Kingston: More details on VPTS ... Other toplogies require hub-and-spoke and make it very difficult to provide a ring. TRILL supports all topologies. Main reason a ring is hard with other technologies is that they use split horizon but you don't need that with TRILL. TRILL works well with ring, or hub and spoke, or mesh, any topology. ... Kingston: We have this example topology from a customer. ... Data Centers connected by a ring ... In this case, until four links fail, you have Data Center connectivity. Sue Hares (Co-Chair): This ring topology was something set up by your customer, by the deloyment you are working on, not inherent to the technology. Could you talk about that a bit more? Kingston: OK. This is basically the requirement we have received from our customer. He has named this the DCI layer. We have received this directly from the customer. Sue: Have you heard this from multiple customers? Kingston: Just from one so far but I anticipate other cusotmers will want this. Many are going with a leaf and spine model but then they get into layer 2 interconnect, I think they will want this. Sue: OK, thanks. Kingston: Actually, to complete the requirements, it should be all active-active. No link is a stand-by. It is all active-active. And it is a ring and has redundancy across the Data Center. So how will we do this? We run a VTSD in each Data Center. This handles redundance and active-acive very well. And supports a ring topology. ... A bit more on how the BUM [broadcast, unknown unicast, multicast] traffic is handled. ... It takes the shortest path. ... In this case we see running layer 2 in your Data Center. Kingston: The next use case is where you are running TRILL in your complete Data Center. Since we are introducing TRILL in the provider network you are getting a complete TRILL solution. You are running TRILL edge-to-edge. The other advantage is OAM services. You don't need different OAM for different layers, just TRILL. Your OAM will work very well. Kingston: Here is a table of the requirements and how TRILL meets them. ... ... ... Any missing pieces are marked. Autodiscovery of Data Center nodes may be missing, we may need to work on this. ... Any comments? Sue: Can you comment more on MAC mobility? Kingston: With VM mobility, you may need to flush the MAC addresses and re-learn. We need to think a little to see if there is any way we can use ESADI for this purpose. Sue: Is there timing that is critic in this? Kingston: Yes, when you move from one server to another, you need to be sure to update the MAC immediately or you may end up black holing traffic. Weiguo Hao (Huawei): I have a question on load balancing in TRILL over MPLS. Only one MPLS label is added at ingress, not an entropy lable, so the transit nodes do not have enough entropy. Would you consider also adding an entropy label? Kingston: Yes, what we are providing if you want active-acive is that you have two PEs and two pseudo-wires running in parallel to those PEs. ... With respect to VTSD, you have multiple pseudo-wires between Data Centers. If you need more bandwidth, you add more psuedo-wires. Your question is how do you load balance inside each flow. If the path supports entropy, the VTSD can insert that. Weiguo: So you want to use the current MPLS entropy mechanism. Kingston: Yes, exactly. Any more questions? Sue: Could you go back to the requirements and talk a bit more about the autodiscovery? Kingston: Each DC needs to discover the other DCs. If they are using VPLS, that uses a mesh. To avoid having to configure each DC with all the others, people use an autodiscovery mechanism, for easy provisioning. So we may need such a mechanism for TRILL. Sue: Have you thought about using something like the push/pull directory mechanisms or are you just starting to think about this? Kingston: We are just starting to look into it. TRILL over IP [16:20-16:35] ------------------------------------------- draft-ietf-trill-over-ip-05 Margaret Cullen (Painless Security) [see slides]: We have talked about this at previous meetings and have been working on this for a while. TRILL over IP treats an IP network as a link connecting TRILL switch ports. That enables you to connect multiple TRILL sites into a single TRILL campus. There are two scenarios in the draft. ... Margaret: There are only a few changes from the last draft. We added IKEv2 [Internet Key Exchange version 2], which came up in discussion of the previous draft to add key negotiation. Also added some material covering middleboxes -- not a change but how to work with middlboxes. A conflict with entropy and NAT / NAT-PT boxes has come up. Do we propose a solution for that, Donald? Donald: The draft just says you may have to reduce the amount of entropy if you are going through some middlboxes. In the worst case, to a single source address, if that is your situation. Margaret: We improved the QoS material. ... We encourage the use of IPv6 to avoid the fragmentation issues of IPv4 if you may have MTU problems requiring fragmentation. There has also been a major re-organization of the material in the draft without technical change. Previously the draft had just grown so you had material on the same topic split into different parts of the draft. Margaret: We specify IPSEC ESP in tunnel mode for security, now with IKEv2. If there is IS-IS keying in place, we can derive shared keys from that. If there isn't IS-IS keying in place, they we use a different way to derive keys. ... We have a proposal for multicast TRILL keying; since there is a designated RBridge on the link, it can generate and distribute a shared key for multicast. ... Margaret: We have a little bit of work remaining but I think it is coming to the end. We have a little work to do on the security section, to finish up multicast keying. Also, we need to finish the section of TRILL IP port configuration -- for example for security configuration it just says TBD right now. Margaret: Any questions or issues? Donald: On the QoS stuff, a minor item: there are 6 bits of DSCP code points, 64 of them. It currently specifies in the draft how to map three bits of priority to DSCP, because there are 8 values of DSCP specified for that. But really, these days, there are the 3 bits of priority plus a drop eligibility bit for a total of four bits. So it might be nice to map to 16 DSCP values but there don't seem to be such DSCP values specified currently. ... I think what is there in the draft is OK. It might have been better if someone had defined another set of 8 DSCP code points which was the priorities plus drop eligibility. Then you could do a slightly better job of mapping. But I don't think we want to get into the business of defining new DSCP code point in this WG. ... Sue: You might check the TSV draft on this. I'll look it up and send it to you. Donald: It is kind of odd because there are some additional DSCP code points but not enough. Margaret: But the mapping is the best we can do with currently defined codes points. Donald: Right. Sue: Two questions: When do you think it will be done? Margaret: Looking at the last two pieces, I'm not sure. But I think we should be able to go to WG Last Call well before the next IETF meeting. Sue: Second question: We went to IPSEC ESP based on vendor feedback, have we received further feedback from vendors? Margaret: Lots of things in the draft are based on feedback from vendors but I don't think we have gotten anything further on that particular point. TRILL ECN Proposal [16:35-16:45] ------------------------------------------- Donald Eastlake (Huawei Technologies) [see slides]: This last item for today is a proposal for implementing ECN, Explicit Congestion Notification, in TRILL. That provides forward congestion notification, primariy for use in connection with schemes for active queue management [AQM]. The current RFC which most closley addresses this is RFC 3168 that talks about adding ECN to IP. ... If you think of what TRILL does from ingress to egress as a tunnel, then you sort of want to do ECN for tunnels as specified in RFC 6040. Donald: The idea is to take a couple of bits in the TRILL Header extension word. The TRILL Header was origially variable length but that wasn't very popular. So this has been changed so now there is just one bit in the fixed header which says whether this extension word is present. ... The two bits suggested for ECN are bits in the extension word that were pre-designated as hop-by-hop and non-critical. That means they can change every hop and nothing bad happens if you just ignore them. So you could have some RBridges that support ECN and some that don't and this will not cause any big problem. ... Donald: So, at engress, any TRILL ECN indication would be combined with tunneled ECN indicaions, at leat for IP. ... ... ... Any Questions: Lucy Yong (Huawei): This works in transit routers also? Donald: Well, every RBridge that supports this would mark for congestion but ones that don't would just forward it unchanged. So you might miss some. But, realistically, in a Data Center, probably all your equipment has the same capabilities. Lucy: So just RBridges are doing the marking. Donald: Yes. But from the TRILL point of view, IP routers are end stations. So if traffic is coming from an IP router, it might have added ECN marking in IP. Then TRILL could mark ECN in the TRILL Header. And they get combined at the TRILL egress. Typically, if it had experienced earlier congestion or congestion is experienced in TRILL it would be indicated in traffic exiting TRILL to the next IP router. Weiguo: I think your solution could be applied to all overlay networks. The transit node indicates congestion and this can be returned to the ingress node. Donald: Well, there is no explicit return of the congestion to the ingress in this. There are other schemes involved with active queue manageent that get a signal back to the ingress. ECN just sends it forward. You need something else to get it back to the origin. Weiguo: I think current VXLAN networks have a similar problem. Donald: Yes. ... It is available for all kinds of tunneling. Weiguo: Good solution. Lucy: I see it a little different. With VXLAN, transit does not know the payload so it can't do the marking. With TRILL you have a transit RBridge that can do the marking. Weiguo: I think transit VXLAN routers should be VXLAN aware. ... Donald: Any further comments or questions? I'll hang around a bit if people want to talk further after this session. Sue: Looks like we can end 12 minutes early. Donald: OK. And we have a second session Thursday at 5:40pm. Session 2 of 2 Agenda ===================== Date: 2015-11-05 Room: 303 Time: 17:40-18:40 ============================================== [some delay in starting due to AV techncial problems] Sue Hares (Co-Chair, Hickory Hill Consulting): Call meeting to order. Here is the Note Well. This is the agenda for today. Does anyone want to change it? No? OK, then we will go to the first presentation. Link Security [17:40-17:45] ------------------------------------------- draft-eastlake-trill-link-security-02 Donald Eastlake (Huawei) [see slides]: This is similar to previous presentations. ... There is a partial draft out there. The goals of the draft are three things: Eastablish a strong security policy, specify the link scurity for various link types where this was not specified before, and to specify edge-to-edge security. Donald: The proposed policies are that if a TRILL port is capable of encrypting at line speed then it must default to doing encryption. And if you can't do authenticated encryption, then you should do opportunistic encryption. Even if the port is not capable of encrypting at line speed, you are still required to implement encryption. ... There are three link types specified so far: Ethernet, PPP, and pseudowire and there is some security specified for the RFCs for those TRILL link types but this draft extends that with the new policies and provides more details. There is also a fourth link type coming along in the TRILL over IP draft, but it is expected to cover link security so that isn't included in this draft. ... Donald: End-to-end security is always good, that is between the end stations, but that is outside of the scope of TRILL. You can also have security between end stations and edge RBridges -- but that is really out of scope for TRILL also. ... Donald: For link security the idea is to use natural security for that link, so MACSEC [IEEE Std 802.1AE] for Ethernet links. One problem with MACSEC is that if there is an intervening customer bridge, then MACSEC would work from a TRILL port to the bridge post. ... How do you get security between TRILL ports if there is one or more intervening bridges? Maybe OK if it is all under unified management. I may be able to talk to some MACSEC people next week. ... The MACSEC is currently defined as being the very first tag so it encrypts any VLAN tag. ... Weiguo: Is the MACSEC tag security key... Donald: Well, the MACSEC tag specifies a security association. 802.1AE specifies how to do the encryption and authentication but assumes you already have keys. Well, you could manually configure them but you normally use IEEE Std 802.1X which has been extended to do key negotiation. 802.1X would typically be intercepted by a customer bridge so you end up negotiating a key with the nearest bridge port if you have a customer bridge between RBridges. Weiguo: The key negotiation is a TRILL protocol or other protocol? Donald: If it is on an Ethernet link, you just use the normal Ethernet stuff. Actually, MACSEC and the key negotiation don't have much to do with TRILL. You might start with a TRILL key but the 802.1X messages and MACSEC tag would just be how 802.1 defines them for Ethernet. ... Donald: Edge-to-edge encryption would be between ingress and egress and would need some more TRILL sauce. ... You need to leave the TRILL Header in the clear so all the TRILL switches in the path can see forward the packet appropriately. And you also have to leave the VLAN or Fine Grained Label visible for pruning. But you only have to do this at the ingress and the egress. So if the path is 4 or 5 hops, all the transit RBridges don't have to worry about this. ... All the crypto work is at the edges. ... I would think that most people would prefer to do edge-to-edge encryption. ... What possible ways to do this are there? The three big protocols out there are IPSEC, MACSEC, and DTLS. MACSEC and IPSEC have better hardware support and for various reasons MACSEC may have better market acceptance. ... So this draft currently says MACSEC for edge-to-edge but doesn't actually say how it would be done. ... ... Donald: I think the draft needs more work but hopefully after another revision, we could adopt it and get better link security and edge-to-edge security into TRILL. Any questions? Weiguo: How would the MACSEC key be generated...? Donald: 802.1AE just talks abou the format. It doesn't talk about how to generate the key. So how do you do that? If you were using MACSEC for edge-to-edge, you would probaby try to run 802.1X from edge-to-edge. You could probably put 802.1X messages inside an RBridge Channel message. ... So the ingress and egress would negotiate a key. ... Weiguo: So the key is agnostic to the data plane. It is a control plane negotiation. Donald: Right. The key negotiation is really spearate. ... Weiguo: And the TRILL trailer will assume the key ... Donald: Well, assuming it is an Ethernet link, which is by far the most common, the trailer is just a hop by hop FCS and is not affected by the key. ... Weiguo: OK. Multi-Level / Multi-Topology [17:45-18:00] ------------------------------------------- Multi-Level TRILL draft-ietf-trill-rbridge-multilevel draft-ietf-trill-multilevel-single-nickname Multi-Topology TRILL draft-ietf-trill-multi-topology Donald (Huawei): This is a status update on what is going on with multi-level and multi-topology from my point of view. Donald: draft-ietf-trill-rbridge-multilevel is Informational and surveys different approaches. If was adopted since the last meeting. ... One big question is unique versus aggregaed nicknames. The draft recommends a hybrid approach because the unique nickname method is simpler, needs only software changes at the boarder RBridges. Good for a small campus, say making a campus of 1000 RBridges into one with 20 areas of 50 RBridges each. It is no problem having 1000 nicknames. But with a bigger campus, say 50,000 nodes, it is more of a problem. and if you have 100,000 nodes, there aren't 100,000 different nicknames available. ... So you need an aggregated nickname scheme to handle that. ... ... Donald: draft-ietf-multilevel-single-nickname is a draft using aggregated nicknames. It was also adopted since the last meeting. We don't have an active WG draft on unique nicknames right now. ... ... Donald: The other relevant draft is draft-ietf-trill-multi-topology was also adopted since the July meeting. I think we could just go ahead and WG LC the rbridge-multi-level draft and probably the multi-topolgy draft ... Donald: The question is what to do about the multi-level draft. I think it would be good to have a way to do it with unique nicknames. ... And I think we should have an aggregated nickname draft for a complete solution. We could re-activate an old unique nickname draft or combine that into the aggregated draft. Mingui Zhang (Huawei): I think we should have spearate drafts for unique and aggregated nicknames. ... we can talk about how to combine unique nickname areas and aggregated nickname areas. Do you think that is workable. Donald: Sure, but I think it wouldn't be that hard to combine them. The unique nickname case is simpler. I don't think there is that much interaction. They can just be in separate drafts. Mingui: I think it is the responsibility of unique nickname operatore to make sure that a nickname is not duplicated. Donald: Sure, there needs to be some stuff about nickname allocation. Some way to be sure that an RBridget that just came up in a Level 1 Area doesn't use a nickname in use in Level 2 or in some other unique nickname Level 1 Area. So probably you have to announce a block of available nicknames. ... Mingui: Yes, I think it requires some software changes. Weiguo: If the nickname is dynamically generated, have to be sure that nickname is different in different campuses. Have to assure no conflict. ... Have to configure range in different campuses. Donald: Well, really might just be one big campus. But you do have to be sure they don't conflict. This is discussed in the Informational draft. Basically you need to announce in an Area what nicknames are available in different Areas. ... You need to do something like that. Remote MAC Address Flush [18:00-18:15] ------------------------------------------- draft-hao-trill-address-flush-00 Weiguo Hao (Huawei) [see slides]: Remote MAC address flush. Currently TRILL RBridge have five ways to learn MAC addresses. ... different for ingress and egress RBridge ... Weiguo: For data plane learning, relies on timeout for forgetting. ... For ESADI learning, MAC addresses can be withdrawn through normal ESADI control plane mechanism. ... ... ... Weiguo: Proposal is to define an RBridge Channel message to flush MAC addresses learned from data plane at remote RBridge. ... Message would be sent by the ingress RBridge where the MAC is attached because it has better local knowledge. ... Variations to flush a single entry or entries for a Data Label or for a set of Data Labels. Mingui: You are suggesting a new RBridge Channel protocol message but can we achieve this by extending the ESADI protocol? Weiguo: If ESADI is deployed, you don't need this message because ESADI can withdraw information fron entire TRILL network. It is intended for data plane learning. Mingui: But ESADI messages are send in the data plane. Weiguo: Yes but ESDAI messages provide control plane address learning and forgetting. Fangwei: I have the same thought as Mingui. I think we can do this with ESADI protocol. Why not have a new message in ESADI. ... Weiguo: If we use ESADI, we have to use control plane MAC learning mechanism. But currently, for most TRILL deployments, only the data plane learning is used, so how to rapidly withdraw MAC. Fangwei: But ESADI is also based on the data plane. I think there are various scenarios... I don't know the benefit of this proposal compared with ESADI. Weiguo: If ESADI is extended for a MAC flush function, it will be very heavy. ... This is a very simple RBridge Channel message. If we have to install the entire ESADI components for the MAC flush function, it will be too heavy. Fangwei: I have another question. What is the destination address for the RBridge Channel message? Weiguo: We can use the multicast RBridge Channel message. A multicast address. Fangwei: That is like the multicast address in ESADI. ... All-edge-RBridges. ... Weiguo: The transport layer may be the same. ... Fangwei: I think you can solve this very well with ESADI. Weiguo: But we don't want to use the ESADI mechanism. Sue: This can be discussed furthe on the mailing list. We are a bit over time. Is there anything else for this meeting. [no response] OK, thank you and this meeting is adjourned. == end ==