TRILL Working Group Agenda Hyatt Regency, Vancouver, Canada Chairs: Erik Nordmark, Donald E. Eastlake 3rd [Times given for items are the originally scheduled amount of time, not the amount of time actually taken.] ======================================================== SESSION 1, Thursday 2 August 2012. 1300-1500, Regency F ======================================================== Minutes take by Jon Hudson, edited by the chairs. Blue sheets sent around. Note Well shown. Introductions of co-Chairs. Agenda reviewed. No changes requested. Milestones reviewed, completed and un-completed. Document status reviewed: 6 RFCs 1 WG drafts in the RFC Editors queue 4 WG drafts in IESG consideration People should read the other WG drafts and those presented at this meeting. 35 min. OAM, Tissa Senevirathne ================================ Tissa Senevirathne (Cisco): [Presentation, see slides] Change in OAM direction at last session in Paris. Will give update on progress since then, including discussions with IEEE 802.1. This resulted in some changes in frame format. I will also talk about how TRILL fits into the 802.1 OAM model and different layers of the network. Tissa: TRILL OAM Requirements Doc published. Feedback incorporated, document revised, and now has been moved to being a WG document. TRILL OAM Framework Doc published. Feedback incorporated and document revised. If you haven't read these, please do and comment. Erik Nordmark (Cisco, Co-Chair): I think what you are trying to do with the framework document is to describe things in a way that can be understood by both IETF and 802.1 people. Perhaps the terms used will be a little different but the document should aid understanding and cooperation. Tissa: Yes. We also published a "802.1ag OAM and Messaging for TRILL" document which is much more technical. It's just a -00 draft so I'm sure a lot of work in needed. So, that's the documents and their status since the Paris meeting. Tissa: Small group of TRILL People trekked to San Diego to present TRILL OAM ideas to IEEE with goal to align OAM Strategies. The idea was well received. There were some complaints that we should have been there earlier. The outcome was to identify a team of volunteers to work with us, all very versed on OAM. The frame structure was reviewed and they suggested two modifications: 1.) Move Ethertype to front of OAM channel part of the frame. 2.) Use a single header bit to identify OAM frames. The reviews by the team are not complete. Two items we want to look at right after this IETF meeting are: The TRILL MP Model (Maintenance Point). The exact TLVs and Ops we will use. When completed we will publish a pointer to the results to both the TRILL and 802.1 mailing list. We will then go and present the results to 802.1 at their Santa Cruz meeting in September. The TRILL maintenance association model is in line with the 802.1 model. TRILL MP will act like an Up MP. Unlike 802.1, in TRILL the RBridge as a whole will be addressed by TRILL OAM frames. The framework draft is recommended to read to understand these issues and the different layers. ... On next steps: we have proposed a document suite: requirement, framework, solution document. Milestone for IEEE cooperation: complete reviews before the 802.1 Santa Cruz meeting in September. Also going back to IEEE in November. Dave Allen (Ericson): You are discussing agreements. Who are the agreeing parties? Tissa: Between individuals. Eric Gray (Ericson): I think this is a picture of cooperation between the IEEE and IETF. You keep saying "IEEE". I assume that is just for economy of words and in each case you mean IEEE 802.1. Tissa: Yes. Thomas Narten (IBM): I am concerned that this work is going to be presented to the IEEE 802.1 before it's a working group document. That saying this work is representative of the will of the WG when it's only been seen and/or worked on by a small group. I don't think anything should be presented to an IEEE group unless it has been accepted by the TRILL working group. Tissa: These are not presented as individual documents but as the result of the team working on this. Donald: I think the solutions document may end up being more than one document but, leaving that aside, the presentations were made by Tissa, who is not a working group officer, and I think the document status was made clear. By moving the documents to working group draft status first, it makes things more official but I don't think it lubricates anything. Thomas: I'm not suggesting anything is improper is going on. But you have to be very careful when going between standards groups to distinguish between representing the standards body and being individuals. Erik Nordmark: We certainly have to be careful but making it a working group document does not mean the working group agrees with the document. We don't judge that until working group last call. It just means the working group agrees to work on the document. It gives the documents more weight if adopted and we have to be careful but we need flexibility. Ali Sajassi (Cisco): As a member of the design team I don't think it makes any difference whether the documents are working group documents or not. What is important is getting everyone in the collaboration and making sure the design team is on board. Once everyone is one board, it is going to move very smoothly in both the IETF and in IEEE. Some of the members of the design team, Steven [Haddock] and Ben [Mack-Crane], have not had a chance to get fully involved yet. Dave Allen: My question is for Ali. Could you define what proceeding in IEEE is? Ali: I said that once we get the members of the joint design team between the IETF and IEEE... Dave: It's not between the IETF and IEEE. It's individuals. Ali: Once we get everyone in that design team in synch then it will progress very smoothly. Donald: I'm sort of speaking for Ali so he should listen and correct me if I'm wrong but I think what Ali was referring to was that he believes there are similar OAM problems in [IEEE] 802.1Qbp and it might be that similar solutions could be applied. Dave: As the F-tag encodes the entropy in the layer, I'm not aware of what common problems there would be. And I've been working in data plane OAM for ten years. The characterization of "progressing in IEEE"... I'm not aware on any IEEE document that would be published, any PAR that has been approved. My understanding is that it is just some individuals that attend 802.1 who happen to be on this design team. I want to be sure it is not misrepresented. Ali: The goal here is to come up with common OAM across what IEEE and IETF are doing. If you look at the Qbp and TRILL requirements, these is a lot of overlap. Donald: I'm not sure how far we should go into discussing details on 802.1 OAM here. x (Extreme Networks): Are we looking for something formal from IEEE. Is this being liaisoned? Donald: Not currently. Tissa: It could happen that something more formal could come out of the 802.1 meeting. Erik Nordmark: We haven't discussed this with the ADs yet but maybe there should be something more formal when we get to the IETF Last Call stage. But that's to be determined. Dan Romascanu (Avaya, Liaison from IETF to IEEE SA): Do you have in mind any changes to IEEE standards? If so, you need to become part of the IEEE process. To send a document to the IEEE, and I think you should do that more formally with a liaison to get a response, is one side. But it sounds like you want to do more and may need to become part of the IEEE process. Tissa: Dan, after all these reviews, we should have a better idea of any changes we would require. So, it seems like not much. Pat Thaler (Broadcom, 802 Vice Chair): I have been working on improving IEEE-IETF relations. I am very please with the work that is being done and commend the authors for reaching out to the IEEE so early. Informal is often the way these thing start. Frankly, Last Call would be very late to bring it to the attention of 802.1. I think this is on a good path and a good way to progress. If things come in too late, it is very difficult to change. Erik Nordmark: My comment on IETF Last Call was that maybe we should do formal liaisons then but I don't think that makes sense now and the informal communications are good and we should let these people work this out. Shahram (Broadcom): TRILL is going to support layer 2 VPN, right? The routers or switches at the edge can run layer 2 VPN? Donald: What do you mean layer 2 VPN? Shahram: It provides a Ethernet service. You can connect different networks or virtual machines... Donald: Yes, you can do that with TRILL. Shahram: You said the TRILL OAM end point model was an up MEP. That won't work. Donald: I think this is getting way too detailed. You are more than welcome to read the documents and provide comments or questions. Donald: So, us two co-chairs up here have just noticed something that no one else seems to have noticed. We never actually asked for a scribe... One of the things you should do at the start of the meeting? OK, Jon Hudson will take notes. How about Jabber? Anyone on Jabber? [no response] Well, if anyone noticed something in the Jabber room we should know about, please ask for attention and bring it up in the meeting. 10 min. Fine Grained Labeling, Donald Eastlake =========draft-ietf-trill-fine-labeling-01.txt Donald Eastlake (Huawei, Co-Chair): [presentation, see slides] ... The existing draft has a structure that provides a 24-bit label but is compatible with existing RBridge transit switches. However, last week at the joint IETF and IEEE 802 Leadership Meeting it was identified that 0x8100 is an 802.1 Ethertype used in a way not acceptable to 802.1 so the method in the draft is not allowed. So, we have to use something different than 0x8100. Two possibilities are shown in my slides. We will be changing the draft. Ali Sajassi (Cisco): If you are use the second model, an Ethertype followed by a 24-bit field, there is one already defined. Have you considered using that? Donald: Yes, I have. My personal comments on that are it just doesn't work with the way TRILL does things, whether you consider that encapsulation or prefixing. You end up with 12 bytes that are intended for the MAC-in-MAC being unused. That doesn't make it broken, it just means 12 wasted bytes. Erik/Ali: ... that's the [IEEE] 802.1ah tag we are talking about ... Ali: At one point there was interest, for some application, in separating out the MAC address and having a tag with just the label. I could see if there is still interest in that in IEEE. Donald: If there was one tag format that was agreeable to both IEEE and TRILL, that would seem like a good thing. Pat Thaler: I don't think we said you could use any value there [to replace 8100]. If you are portraying it as an Ethertype, it had better be an Ethertype assigned to you. Donald: Yes, the value shown is an Ethertype belonging to TRILL. We might violate a rule by not having a version number. Anoop Ghanwani (Dell): So there would be some reserved area? Donald: As shown here, there are zero reserved bits. Perhaps that violates the rule that you need a version field. Thomas Narten (IBM): What rule? Donald: I believe there is a rule in the IEEE Registry that you are supposed to have a version field so once you get an Ethertype you won't need another one if you make a change. Pat: That's not the exact rule. It's not quite a version requirement but people are encouraged to have some sort of sub-type field so they don't keep coming back for Ethertype after Ethertype. However, this does not seem to have been enforced for tags for standards. There are many examples without such a field. Anoop: So it is just missing the reserved area. Donald: All the bits are used and these is none. If you are saying there should be a reserved are, that is an interesting comment but right now there isn't one. Anoop: The previous format was chosen for backwards compatibility. What does this new format do? Donald: Neither of the two new formats maintains exactly backwards compatibility because hardware might look for the 0x8100 and discard the frame if it finds anything else. Erik: There are actually two kinds of backward compatibility. From a standards perspective, there is whether an RBridge the implements the current standard can handle the format because the 0x8100 is gone. Neither of these maintains that level of backwards compatibility. Then there is the question of whether existing hardware can handle the format. Anoop: But in most hardware, the Ethertype values is programmable. Donald: I have been told there is some hardware where, even if other Ethertypes are programmed, 0x8100 is hardwired. Anoop: Then the question is, if you can't be backwards compatible, could you use something different from this model, such as options? Donald: This is potentially solvable with TRILL Header options. I'm not sure we should go too far into all possible solutions. I was just informing people that the draft will change to eliminate 0x8100 and I gave two examples of how it might change. Maybe I should have given other examples, including a header option. Erik: I think it would be good for people to think about how hard the different possibilities are, including those not show here, so we can figure out the path forward. Tissa: I understand we have to change it, but can we please choose something like option 1 as it requires minimal changes. Naveen Nimmu (Broadcom): Can we look at other work going on in the TRILL WG to use a common Ethertype. Ali Sajassi: If the objective is minimum changes, then it seems like option 1 will do the job. If we are not concerned with minimum changes, I would suggest moving this 24-bits to right after the TRILL Header and use the 802.1ah tag. But that involves a lot more changes. Dave Allen: Why are you trying to solve a TRILL problem with an Ethernet header. Donald: Because that is just the way the information is encoded. Dave: No. You are trying to produce a 24-bit identifier and I don't understand why it is not in the TRILL Header but in a modified Ethernet payload. Donald: It's actually a matter of how the TRILL Header is defined and the current fine-grained labeling draft re-defines the end boundary of the TRILL Header so as to encompass this information. Dave: So you are no longer discussing encapsulation so it is no longer an Ethernet header you are carrying. You are carrying a TRILL header and re-constructing an Ethernet header on egress from the network. Erik: The way the current TRILL specification works, it actually looks into this information for pruning multi-destination frames so you can't just put anything there. Dave: So instead of viewing this as a layer violation, you have changed the semantics of what you are doing. Donald: Yes, this can be viewed that way. Donald: Can we move on to the next presentation? Thomas: Fine-grained labeling is important to get done. What we had here was a presentation not on the original agenda with no updated draft. What are the next steps? Erik: Part of the reason it's on the agenda because you complained on Monday that it wasn't. So don't beat me up about adding it late. Donald: A next step should be discussion on the list. Thomas: Can a small group be formed to come up with a solution quickly so we can move forward? Erik: How many people would want to participate in such a group? Somewhere between 5 and 10. Donald: Such people should contact me. We really need to move on to the next presentation or we will get way behind schedule. 15 min. LSP Extension for Tree Distribution Optimization Across Sites =========Hao Weiguo, Qin Weu, draft-wu-trill-lsp-ext-tree-distr-opt Qin Weu (Huawei): [presentation, see slides] ... extension to more tenants by distinguishing local and global VLANs where global VLANs are not connected across some links for distribution trees ... Erik Nordmark (Cisco, Co-Chair): How many people have read this draft? A few. It would be good if more people could read this draft to see if the WG is interested in working on it. 15 min. TRILL MT Encoding, Naveen Nimmu, Tissa Senevirathne =========draft-tissa-trill-mt-encode-01.txt Tissa Senevirathne (Cisco): [presentation, see slides] The object is to support multi-topology and extended nicknames without making major changes in the TRILL Header as currently defined and to be able to work with RBridges that have not been extended. We also want to minimize control plane changes. ... Methodology is very simple. Define an additional Ethertype that says what follows in a topology ID or nickname extension. You can selectively include or exclude depending on whether another RBridge supports this. ... For multi-topology, you can isolate RBridges that do not support it into a local area that is single topology. ... For RBridges that do not support extended nicknames, you can put then into one topology and do the mapping at a higher level is a router or gateway. ... Thomas Narten (IBM): If it's always the case that this is only used between two RBridges that both support this, then why not just use a new bigger header between them? Since it is only between consenting RBridges. ... Tissa: This is a fast method because it will not require new TRILL Header development work. Thomas: So basically you want to extend the TRILL Header, but you don't want to change it. So instead you are doing things that you argue do not change the TRILL Header, but in fact you are. Erik Nordmark (Cisco, Co-Chair): You are making the TRILL nickname bigger. The fact that you sprinkle those bits in different places... conceptually it is still the same thing. Tissa: So if I change the header how do I communicate with an old RBridge? Thomas: You send the old header to old RBridges and the new header to new ones. Naveen Nimmu (Broadcom): This way you save space if you are communicating with new RBridges but don't need the extension. Thomas: Maybe I'm old fashioned but in the IETF, if you need more information in your header, you just change your header, not go through all this to try to not change your header. It is going to take code changes in either case. Erik: I think the idea is that one behavior is of a different difficulty than another because hardware may be adapted to processing a sequence of headers. On the other hand, if you have different headers that take different parsing, it takes different hardware. ... Pat Thaler (Broadcom): Any hardware I know of, bits are bits. I don't think it makes a difference. Tissa: I would disagree. If the format is different, then you have to re-generate the entire header. Donald: I think the argument is that if you are coming from an area with one topology to an area with multiple topologies, all you have to do is insert this little header rather than re-construct a different TRILL Header. Maybe that is important, maybe it is not... Tissa: Pushing or popping a tag is much easier due to MPLS like hardware. Constructing a new header is much harder. Pat: I don't think so. It depends on your hardware. ... Ralph Droms (Cisco, Area Director): What is the disposition of the document we just heard about? Donald: This work is not currently in the Charter so this was an informational presentation to see if people were interested in this sort of work. Erik: I suspect that at some time we should have a Charter discussion. If people are interested in solving multi-topology problems, this is one data plane encoding. How many people are interested in solving multi-topology problems in TRILL? About 10. How many people think we should not do that? Zero. Everyone things we should do more work. 15 min. Trill Traffic Engineering, Fangwei Hu, Donald Eastlake =========draft-hu-traill-traffic-engineering-01.txt Donald Eastlake (Huawei): [presentation, see slides] This presentation is on one way to do engineered paths in TRILL, perhaps for performance or policy reasons. ... Current draft covers only unicast traffic. ... Uses existing fast path forwarding hardware logic. ... differences from multi-topology. Generally cannot do very many topologies, rarely more than 8 or so, while you can have hundred of engineered paths. ... very simple, no signaling protocol. ... Need some way to give properties of nicknames, a feature which would also have other uses. ... Erik Nordmark (Cisco, Co-Chair): How does this interact with ESADI? Current, an ingress RBridge learns that a particular MAC address goes to a particular egress RBridge based on data plane or ESADI learning. It sounds like you have to provide a way to over-ride this, how do you decide that a particular MAC and VLAN will use this? Donald: That's sort of the same as the question of how you decide that a particular frame is going to use a particular topology. In both cases, there is a magic box before everything else that decides which topology to use or whether to use an engineered path. There can be multiple engineered paths to the same destination with different characteristics. Erik: But in the MT [multi-topology] you can potentially learn from return traffic. Donald: Agreed, they are not the same. You can argue that the magic box is smaller for multi-topology but there is still a decision before everything else. That decision is not described in this draft or in the multi-topology draft. Anoop Ghanwani (Dell): Just to clarify, do you have a separate nickname for every traffic engineered path? Donald: For every destination. The paths can converge. You can have an extra nickname for traffic engineering for RBridge X and multiple paths to X. As long as two of those paths don't converge and then diverge again, you only need one destination. It just uses the same forwarding logic. Anoop: So if you didn't want to worry about whether paths converged or diverged, you could just allocate one nickname per path. Donald: Yes, you could allocate lots of nicknames. But, if all your RBridges are traffic engineering aware, they will not do least cost routing computations for these nicknames, so the cost of have having many nicknames is less. Pat Thaler (Broadcom): In this and the previous presentation, I see talk about what can be done and how but not why. It seems to me that that is not the usual foot to start out on. It is usual to start with the requirements and use cases. Erik: Yes. But in fairness, multi-topology and traffic engineering are things that exist in other protocol suites in the IETF and have been found useful. But I agree that understanding a bit more whether the WG will work on these or not and whether they overlaps, having a problem statement, would be good. 15 min. TRILL Resilient Distribution Trees, Mingui Zhang =========draft-zhang-trill-resilient-trees-00.txt Mingui Zhang (Huawei): [presentation, see slides] Repair of broken distribution tree. Can happen with global re-convergance but that can be disruptive and slow. Need protection. ... Use affinity TLV. ... Way to manipulate the distribution tree calculation. ... Use affinity to achieve protection. ... backup trees ... Can set up maximally disjoint main tree and backup tree. ... can switch on link failure ... examples ... Erik Nordmark (Cisco, Co-Chair): On that last slide, can you tell from IS-IS when you have finished converging? Your view sitting in one RBridge might not be the view of other RBridges because you don't know if things have propagated, if everyone has finished Dijkstra. Mingui: Distributed through LSP ... don't know when other RBridge have calculated their new trees. Anoop Ghanwani (Dell): How can we automate this. Are you asking the users to input affinity TLVs for each tree root? Mingui: Yes, I want them to do that. Anoop: OK. There may be easier ways to agree to globally calculate maximally disjoint trees. Mingui: I wanted to keep it simple but developers can implement their own algorithm. Anoop: Well, actually everyone has to agree on the tree that is computed. So if we decide as a group that it is interesting to compute maximally redundant trees, then we should agree on how, unless we use the affinity TLV but that is messy... Mingui: Are you talking about backwards compatibility? Anoop: More about minimizing configuration. Erik: It is an interesting problem to minimize the effects of a distribution tree having a problem. If we can tell the ingress RBridges that there is a problem, they can just switch to a new tree, right? That might be simpler and accomplish the same thing. ... Anoop: I think from a switching point of view you can switch to a new tree when you get an LSP showing a problem. Figuring out when to switch back is harder. Donald: How many have looked at the draft? 5 or 6. People should read the draft. Erik: Sounds like a potentially interesting problem, recovering from such failures, to go after. 10 min. Milestone Updates, Erik Nordmark ========================================= Erik Nordmark (Cisco, Co-Chair): [presentation, see slides] Our milestones are quite out of date. According to them, we should not exist. We have done a bunch of these things, which can just be marked done. There are some questions, particularly about ARP and ND optimization. We put these on a while ago in connection with reducing multi-destination frames. There is no draft currently in this area. Is the group still interested in working on this? If so we should keep it in the list. inaudible: ...directory assist... Erik: Yes, the directory assistance drafts are about reducing ARP/ND. So we could highjack this milestone to say that the directory assisted stuff is how we are addressing this and move on. There is also a milestone on DCB. Donald has had a personal draft on this which is just about the minimal things an RBridge needs to do to participate in DCB, carrying congestion signals. I think we just need to update this milestone and get some review of that draft. Finally, there is an OAM one. I will propose a more concrete date here after reviewing Tissa's slides. Any comments on ARP/ND optimization? There is a potential to add milestones. We have not consulted with the ADs but maybe that should be in conjunction with rechartering. Maybe we should be more explicit about the directory framework. We also have opportunities for volunteers. There are things in the charter with no milestones currently: Getting an implementation report together. An interoperability event at UNH would be a good opportunity. An analysis of IS-IS security is also in the Charter. Thomas Narten (IBM): A high level comment. I would like to split this WG into two areas: First, getting the core out the door and getting experience with it. Second, this future stuff that looks interesting but won't make much difference unless we get deployment. Erik: Yes. A question is how much do you need to get deployment. We are assuming we need at least some fine grained labeling support to get deployment. Are there other scaling things we need? Sam Aldrin (Huawei): I have a question. We have discussed in the last meeting about interconnecting datacenters. I haven't seen the conclusion. What fits into the TRILL Charter and what does not? There is some work to be done on the TRILL side that does not fit into the DCI [Data Center Interconnect] protocol. Erik: I haven't looked into this but Ali Sajassi was presenting a TRILL interconnect draft in L2VPN but said that some TRILL work was needed. If so, do we add it in this Charter? Anoop: So, should that be listed on this slide. Erik: Probably. Ali Sajassi (Cisco): I would say that whatever work impacts the TRILL control plane should be done here. If it does not impact the TRILL control plane, then it does not need to be here. Dan Romascanu (Avaya): Following up on Thomas's comment. Did you look at what was needed to complete the core protocol? By the way, if you know me, you will know that I think OAM should be part of the core. Donald Eastlake (Huawei, Co-Chair): We did some polls in the past and there was pretty much of a consensus in the working group that OAM and fine-grained labeling were the two highest priority items. Dan: Complete the core, declare victory, and leave the rest for TRILL extensions. Erik: There is a step in between where people can report what they have observed running TRILL networks, which I think would always be welcome. [Adjourn until the second TRILL Session] ======================================================== Session 2, Thursday 1730-1830, Regency F ======================================================== Donald Eastlake: Please read the Note Well notice. Blue sheets are going around. Radia Perlman: Should you sign the blue sheets even if you did during the first session? Erik Nordmark: Sure. I don't know what the algorithm is for room size... Donald: Got through things a bit faster than we thought we would during the first session. 15 min. Aware Spanning Tree Topology Change on Rbridges, Yizhou Li ========= draft-yizhous-trill-tc-awareness-00.txt Yizhou Li (Huawei Technologies): [presentation, see slides] Present the two methods in RFC 6325, Appointed Forwarder and STP partition. ... focus on 2nd one. ... motivations for STP based ... MAC table purging ... TCP [topology change] PDU tunneling. Root bridge groups can be found through the Interested VLAN and Spanning Tree TLV... Use RBridge Channel for the tunneling with unicast. Multiple unicast if needed. Also want to purge MAC address to nickname on remote RBridges. ... Easiest way to update remote RBridges is with a data frame but we cannot assume that traffic is always bi-directional. If MSTP is being used, can get the VLANs from the MSTP instance ID... No changes to STP. Only change is that STP can extend through RBridges but only between ports on the same link. We never build a spanning tree between ports on different links. ... Better support of spanning tree is very important. We got this requirement from customers who plan to continue to use spanning tree in part of their networks. Don Fedyk (Alcatel-Lucent): Have you looked at the work going on in the IEEE, Dual [Distributed] Resilient Network Interconnect? Yizhou: DRNI. No really look at all the details. Don Fedyk: You are doing a protocol so that two RBridges look like a single node and connect to multiple links. That seems like the same thing as DRNI. Anoop Ghanwani (Dell): This is different. The two nodes appear to be the same from the spanning tree point of view but not from the LACP point of view. Don Fedyk: So, if you were to support a DRNI interface on there, wouldn't that solve the same problem? Anoop: If you implemented a DRNI here you would not solve this problem. Donald Eastlake (Huawei, Co-Chair): Remote parts of the network would still learn a particular nickname associated with a MAC address. When the traffic switched to coming in through a different RBridge, whether due to spanning tree mechanisms or DRNI mechanisms or yet some other mechanism, there is still the question of how to get the remote learning updated. Anoop: DRNI would not apply here. ... inaudible ... Yizhou: The RBridges use different nicknames. They use the same identity for STP purposes. Sue Hares: I didn't think that DRNI wanted to solve this kind of problem. Don Fedyk: Well, DRNI wants two devices to appear to be one, but, yes, it is a LAG interface. But, if you could do a DRNI here, why wouldn't you? Donald Eastlake: If you did a DRNI here, then you get into questions of how to identify it by a single nickname that represents the LAG. Anoop: A DRNI will not work here. Donald Eastlake: Well, you could possible use DRNI or something like it but then you are trying to have a single device represent the interface rather than these two RBridges. This seems to lead to the psuedonode nickname area... These seem like different ideas. What we have here is two separate RBridges that attach to two separate links because the link has been forced to partition with spanning tree. Peter Ashwood-Smith (Huawei)?: [hard to hear] Yes, DRNI is not supposed to have actions on one side that propagate like this to the other. Don Fedyk: I'll think about it. Anoop: Actually, I came to the microphone to ask what happens if RB1 and RB2 lose connectivity? Yizhou: You mean there is a TRILL campus partition? If that happens, RB2 will know that it can't reach RB1. This problem is not introduced by the TCP tunneling or anything we are adding. Even with the AF [Appointed Forwarder] mechanism, if you lose connectivity, you have to go through certain processes to converge. Donald Eastlake: The situation on the right [root bridge group] has to be specifically configured or turned on or something. If RB1 and RB2 lose connectivity, then this link [and possibly similar parallel links] is the only connectivity between them. In that case you wouldn't want to configure this. And it shouldn't auto-configure either because RB1 and RB2 could not see each other. Neither could get link state from the other saying they are on the same link. In a typical situation, you would expect rich connectivity between them. To use this, you have to have connectivity between RB1 and RB2 not through the link. Tissa: Are you talking about a group of exactly two RBridges or possibly more? Yizhou: Two is just for illustration, could be three or four... Naveen Nimmu (Broadcom): What happens in a more than 2 node so it is more like a broadcast? Donald/Yizhou: All the nodes will get the TCP by serially unicast. 10 min. Linux TRILL Port, Ali Khayam ============== Presented by Sue Hares Sue Hares (Huawei): [presentation, see slides] ... port from Open Solaris to Linux ... if you have experience with this sort of port you will not be surprised. This looks like Quagga because it is derived from Quagga. ... If you have detailed, deep questions, send them to these guys. They would love to hear from you. ... standard way of doing things ... items still pending ... on github. Expect to have stuff out ... October ... Donald Eastlake (Huawei, Co-Chair): I just want to emphasize the last thing here. They are actively soliciting help. Anyone interested in helping should contact them. Tissa Senevirathne (Cisco): Is it the intention of the TRILL working group to use this as some sort of a benchmark to test suite? Donald: No, but I believe people are interested in this sort of thing. Tissa: Do they plan to participate in interoperability testing? Donald: I'm sure they would like to participate in such testing. The next thing they plan to do if they succeed in this initial port is to then port to Open Vswitch. ...: Do they want the WG members to do something other than look at the code? Erik Nordmark (Cisco, Co-Chair): I think they are looking for general assistance, perhaps including help in getting to an Interop. Interop testing is not officially sanctioned or supported by the IETF but it is certainly something we hope they will be able to do. 10 min. TRILL use of IS-IS, Donald Eastlake ========= draft-eastlake-isis-rfc6326bis-08.txt Donald Eastlake (Huawei): [presentation, see slides] Donald: This is not a TRILL WG item, this is an ISIS document, since they did not meet it is being presented here at the suggestion of the ISIS WG Chairs. ... Current RFC 6326 is getting old and additions are needed to support developments in TRILL. ... ... I hope this can be made an ISIS WG draft soon. Tissa Senevirathne: Anything holding up making this an ISIS WG draft. Donald: Not that I am aware of. ? min. Cloudlet, Hu Fangwei, Radia Perlman ========= draft-ietf-trill-cloudlet-00.txt Radia Perlman (Intel): [presentation, see slides] This idea of this is to save nicknames, save end node learning space, expands the scalability of TRILL. ... smart end nodes or dumb switches ... can use spanning tree nodes ... can have a small area, which I call a cloudlet, that adds a new level of hierarchy but looks like an RBridge to the rest of the network ... Tissa Senevirathne (Cisco): I did not completely understand. If you have two TRILL clouds, one looks like an RBridge to the other? Radia: Kind of... Tissa: So are these "E" nodes RBridges or end stations or ...? Radia: Could be either. Tissa: If it is just end stations, seems like the current situation. If it is RBridges, then are there OAM implications? You lose a lot of information. Radia Perlman (Intel): I am not claiming this is all worked out yet. Naveen Nimmu (Broadcom): Could you have multiple levels? Radia: As long as it looks like one RBridge to the campus, it should work. I don't know why you would want multiple levels inside one of these but I guess you could. ?1 (Huawei): If the node is a hypervisor, will we use VDP to notify the hypervisor of the nickname? Radia: Yes, a smart node has to warn R1 that it wants to do the encapsulation and R1 has to tell the smart now the nickname to use. ?1: How does R1 tell the nickname? Donald Eastlake (Huawei): There is a nickname in the TRILL Hello so if R1 is sending Hellos, the node will learn it that way. ?1: Can we use [IEEE] VDP to notice the nickname? Radia: Seem simplest to use a Hello but I'm sure there are other ways. Sam Aldrin (Huawei): I didn't really understand the answer to Naveen's question... Radia: Well, it is easy to understand with just spanning tree bridges but if it is easier, you could route on the TRILL header in the little area. Sam: OK, but from the OAM perspective it looks very tough... Donald: Blue sheets reminder. Thanks for coming, that's it. [Attendance from blue sheets appears to have been 42 at first session, 36 at second session.]