IETF 86 TRILL Working Group Meeting Chairs: Erik Nordmark (Cisco), Donald Eastlake 3rd (Huawei) Secretary: Jon Hudson (Brocade) Facility: Caribe Royale Hotel, Orlando, Florida Date: Tuesday, March 12, 2013 Room: Caribbean 3 Time: 15:20 - 18:30 [Minutes by WG Secretary edited by the Chair. Times given for items are the amount of time originally scheduled, not the amount of time actually taken.] Meeting called to order at 15:34. 5 min. Administrativia (scribes etc.), Agenda Bashing, Chairs ============================================== [presentation, see slides] Erik Nordmark (Cisco) [Co-Chair]: Welcome to the TRILL meeting. Donald Eastlake (Huawei) [Co-Chair]: The Blue sheets are going around. Note the Note Well and be sure to make any required IPR disclosures. Ralph Droms (Cisco) [Outgoing TRILL AD]: Welcome to TRILL. This is my last TRILL meeting as Area Director. Ted Lemon has been selected as your new AD. And personally I do not think a better person could have been chosen. In the future please, when directing poison darts, rocks, cows, etc., aim at Ted, instead of me. He is you new target. Good Hunting. The smiley face I am wearing is because this is my final week as AD. Ralph: The initial arrangement is that TRILL will be one of Ted's working groups, that may change in the future, but for the time being that is how we will arrange things. I am very happy with the NomCom's choice in Ted. I have worked with him for a long time. You are in good hands with Ted. Thanks. Margaret Wasserman (Painless Security): I would like to thank Ralph for his hard work over the years. Donald Eastlake: OK. Jon Hudson is our Secretary and is taking notes. We could use a jabber scribe, any volunteers? No volunteers but I encourage people to monitor the jabber room. Donald: Agenda Review. I didn't ask for as much time as we got. We have two adjacent slots with a break between so I've preserved that. We are at the start reviewing the agenda. - The first item is document status, milestones, and the proposed new Charter that was posted to the WG mailing list. - Second is on TRILL OAM but Tissa Senevirathne of Cisco was unable to make this meeting so he has asked me to present. - Next is TRILL over pseudowires. Lucy Yong cannot be here for the later part of the meeting so that presentation is moved up nearer the front. - Next Directory Assisted Edge stuff. Actually, I'm going to speak on the scheme [specific mechanisms] for directory assistance draft and Linda Dunbar will present the encapsulation draft. The first draft [framework] is actually in WG last call and has been there a while. I believe all comments have been resolved. - Then a break. - Then another presentation on TRILL OAM performance. I would have put that up front with the other OAM presentation but the speaker, Tal Mizrahi, can't make it to the first part of the meeting due to a conflict. - Then a presentation on smart end nodes by Radia Perlman. - Then a presentation on Active-Active problem statement. This had been requested at our last meeting. - I have a short presentation on Vendor Channel. - Last, a presentation on edge group state synchronization, which relates to active-active edge. Donald: Does this agenda meet with the group's approval. Any changes? I guess not. 20 min. Document Status, Review of Milestones, Charter Revision ======================================================= [presentation, see slides] Donald Eastlake (Huawei) [Co-Chair]: Here is the list of TRILL RFCs that have issued, including a couple of recent ones. Donald: We have 5 Drafts in the Editor's Queue. Two drafts in/through WG Last Call: for the Fine Grained Labeling draft, WG Last Call has ended. For the Directory Assisted edge framework draft, I posted a message about a week ago asking for any further comments. None have been posted and I believe all previous comments have been resolved. I do have a slide later on about this framework draft. Donald: Here are the other TRILL WG drafts: CMT - Coordinated Multicast Trees. This draft relates to active-active at the edge. I believe it current has comments unresolved, needs to be worked on. But these comments don't require technical change. ESADI - End Station Address Distribution Information. Enables VLAN or FGL scoped address attachment information to be sent through TRILL. Some changes have been made, posted to the list and discussed. I hope for last call soon. OAM Requirements - In the RFC Editor's Queue. The next step is: OAM Framework - Reviewers need to be found and work is needed. RBridge VLAN Mapping - A draft describing how to have different regions of a TRILL campus where the same VLAN means different things in different regions or different VLANs means the same thing. Donald: No drafts are currently looking for working group adoption. In terms of TRILL related drafts in other WGs there is the RFC6326bis draft in the ISIS WG, which I hope can be advanced soon. Here is a slide on the Directory Assisted Edge framework draft. That draft was subject to an IPR disclosure when it was a personal draft. That disclosure is still applicable now that it is an IETF draft. That was not mentioned when the WG Last Call was issued. A message noting this has been posted to the WG list. The IPR disclosure has been re-filed against the IETF draft but the Secretariat has not processed that yet so the new filing, which is just the same as the old one just against the IETF draft, hasn't appeared in the IPR disclosure database yet. Since it is a WG draft, when that happens a notice will be posted to the WG mailing list automatically. [This has happened.] People should be aware of this. Erik Nordmark (Cisco) [Co-Chair]: Does everyone understand or does anyone have any questions about the IPR or IPR process or this disclosure. If people want to discuss this or don't understand it, we should talk about it. But this is not the first time we have had an IPR disclosure in the WG. [There were no questions.] Donald: Moving on to discuss the milestones. They were updated recently. ... updates ... some have been done, some are past due. ... Future milestones ... Those are the current milestones and their status. Erik: It has been a while since we have updated the Charter, years in fact. We have updated the milestones. A proposed Charter has been sent out to the WG and ADs. We have not gotten much in the way of comments. There are two kinds of comments that I think are important: 1.) Are there features missing, things that are critical, that are needed to get more TRILL products out there and get more deployment, or are their items on the charter that are not needed and should be addressed later after more deployment? 2.) Second, who in the room or on the mailing list is willing to work on this, either by writing drafts or by reviewing them? Erik: First there is some introductory text... Jumping on to the actual work items. There are two slides, eight deliverables, listed. - First is OAM, where we actually have four draft. We seem to have a fair amount of interest and push to move the draft forward. Who thinks this is important? A fair number. Looks like not too many people are just reading email. - Second is something that has changed name over time a couple of times: What happens when you want to connect a TRILL cloud to an existing access network at the edge, using multi-chassis LAG or the like, calling this "active-active" at the edge. We have the CMT and pseudonode nickname draft and another draft that will be presented. Do people understand what this is? Thomas Narten (IBM): I think there is work that needs to be done here but I don't understand the scope of it. I just would like more clarity as to what the problem space is and where the line is between TRILL and regular Ethernet like multi-chassis LAG. Erik: OK. Is there interest in the WG? Raise your hand. Ten plus. Margaret Wasserman (Painless Security): I agree with Thomas that this needs to be worked on and that I would like to see it clarified better. I think I am interested. I think we need a few more sentences to scope this. Erik: OK. We're not going to write the entire problem statement in the Charter but can add some more. - Three [multi-destination frame reduction]: This is something that has been in the Charter for a while. Now we have some drafts in this area on the Directory Assisted Edge. There could be other drafts. Is this an area that people think is important to getting TRILL products deployed and are people willing to work in this area? I see some hands. Thomas: On this point I don't have an opinion, but what I would like to see is have this motivated by real operational experience. Because a lesson is that until you get real deployment, you don't know that your real problems are. Erik: Have people seen real problem here? Even though I work at Cisco I'm not that close to the product people. - Four is supporting IP links between TRILL switches. We have had a draft on this. Margaret had such a draft. We have had some other more informational material on how this might fit into work being done in the L2VPN WG where we might have to specify some glue to fit things together ... Is this an area where people would be willing to do some work? Please raise your hand. Six or seven. Sam Aldrin (Huawei): Why just IP? Erik: It's just an example. Donald: The bullet item currently just says "IP" but it could say something about "other link types". When TRILL over PPP was done it was done in the PPPEXT working group. So if there is some other WG it is usually reasonable to do it there. I might anticipate things a little bit: There is a presentation later on TRILL over pseudowire that Lucy Yong gave in the pseudowire WG [PWE3] earlier today and the opinion of the Chairs and AD was that the work should be done in the TRILL WG because it didn't actually change the pseudowire standard. So maybe this should say IP and pseudowire. Erik: Maybe for EVPN we would deal with some informational documents here as well. They seem to be doing all that in the L2VPN WG. Sam: I think that is about how to extend TRILL between centers across WAN links so, if the wording is changed to cover that, I think it is better. So is it public Internet or is it TRILL campus? Donald: Something that does IP. It doesn't really matter that much. Sam: So it could be Internet too? Donald: Internet two? Sure. Erik: From the Charter point of view we have to be careful what falls into other groups where people are specifying how to run things over the Internet. Sam: One last thing. Some of the work involves extensions to the TRILL protocol and some things involve the work of other WGs. Should it come to TRILL first? Erik: I think it depends on a case-by-case basis. When a need comes up, the Chairs and ADs should figure it out. If it is just an informational document, it may not make much difference. If it actually makes a change in a protocol, then it would usually be in the WG for that protocol, right? Thomas: The wording is perhaps not ideal: "IP links". Don't you mean "tunneling over IP"? Donald: How is that different? Is TRILL over PPP "tunneling over PPP"? Is TRILL over Ethernet "tunneling TRILL over Ethernet"? Erik: This follows the wording we have used in the TRILL spec that talks about running TRILL over PPP links and Ethernet links. Thomas: PPP is a link. I don't think of IP as a link. Donald: It's a multi-access link and the global Internet is a very large multi-access link... Thomas: For all practical purposes we are talking about running TRILL over IP, we are talking about running TRILL over a tunnel, an IP tunnel. You are going to have to have an encap on there... Erik: It is a terminology question because we do have a tunneling header where we are running [TRILL] over Ethernet as well. Pat Thaler (Broadcom): I think when we pop up or repeat a layer to go through something we typically call it tunnel. So when you are putting layer 2 over layer 3. Erik: But also when your are doing layer 2 over layer 2 or layer 3 over layer 3, you call those tunnels as well. Pat: Yes, but ... if we're putting layer 3 over layer 2 or an upper part of layer 2 over a lower part of layer 2, we don't typically call that tunneling. We don't call [IEEE] 802.1 bridges over [IEEE] 802.3 tunneling even though the MAC is lower than layer 2. We only call it tunneling when we repeat a layer or above. Donald: I don't actually care that much but in the current draft the idea is to treat this tunnel or whatever as much like a link as you can conveniently. Thomas: Are we talking about the general topic or the specific [TRILL over IP] draft proposal? I assume we should be talking about the Charter item which, I assume, is some sort of tunneling over IP either point-to-point or, if you really want to treat it as a broadcast network are you going to say you are going to have a network with N nodes on it and TRILL is going to make use of all N nodes... When you say IP link you are being pretty broad. We are usually talking about point-to-point with tunneling. Donald: If it is on a local internet, it could easily be that multi-cast works and you can really just do a simple mapping... Thomas: I can imagine a very wide problem space here, and would prefer a more specific narrow scope unless it is driven by a compelling use case... Erik: We should probably go back and look at what use cases are in the draft. Five and Six we haven't talked much about. Seven and Eight are in the current Charter. - Five is about leveraging IS-IS multi-level to scale up TRILL and multi-topology. We have had discussion about various aspects of this, more on multi-level than multi-topology. Do people think this is something we should work on? Who thinks it should be in the Charter? About seven. - Six is newer but there have been discussion about it where you want to contain the scope of IS-IS interaction but you still need to pass nicknames between those parts of the network. So that if you have some fault, it wouldn't propagate across the whole network. Is this something that people think we should work on, where they are going to write drafts? Please raise you hand. The numbers are dwindling. Three or four. Maybe the arms are getting tired but you need this after the cookies to get some exercise. - Seven, analyze IS-IS security application to TRILL. Do we need some additional security beyond the ability to secure IS-IS messages? Is this something people are willing to work on, write drafts, review drafts, please raise you hand? Six or so. Since we have this in our current Charter, I'd like work to start on this. Is there someone willing to pick up the ball and run with it? Thomas: I don't know what this is. Does this say we a security problem in TRILL that needs fixing? Erik: No. This item originally came from the ADs. Donald: Yes. The ADs thought we should have something like this. It says analyze so one possible result would be that everything is fine. Thomas: What do you mean? A threat analysis? Donald: Probably. This Charter item may not be sufficiently specific but it is more specifically worded than the version in the current Charter that it replaces. I think a threat analysis is appropriate. Erik: At some level. For the control plane by and large, we believe we get security from IS-IS but that's hand waving. And how does it interact with TRILL specific things? Is there any place we need to do anything different. You can phrase it as go ahead and check. And hopefully we don't find anything. Margaret: The continued existence of this Charter item is somewhat frightening given that we have published the spec that this should be done for. I need to check with a few people but probably I can do something in this space. If no one has looked at it, that, in itself, is a problem in my opinion. Erik: We do have a Security Consideration section in the TRILL base spec and other RFCs. In part it refers to the ability to secure IS-IS message. But a larger analysis has not been done. Thomas: I'm worried that this sounds like a fine thing to do. Who would be opposed to some security work? But this group does not seem to have an excess of cycles. It's been in the Charter for a while with no work. It does not seem to be in the critical path for anything. Why are we continuing to support it? Erik: We'll see if Margaret finds others or is willing to do work on this for us and I can have a discussion with the ADs as to whether our Security Considerations sections are an adequate answer. - Eight [interoperability and implementation report]: I don't think this remains in the Charter due to lack of interest. There have been efforts at UNH to have interoperability event. I think this is capturing what came out of those event, what needs to be clarified, ... Donald: I might mention there was an interoperability event last November and there is one planned for later this month, and there was one earlier. [The planned March event has been postponed to May.] That would be three and I think it would be useful to write up the results. There has been some documentation of what happened from UNH. Thomas: If there happen to be representative of UNH who are willing to come to the microphone and explain just where they think this is and whether they could provide some input to the WG. UNH Guy: Yes. Right now we have been writing white papers but we would be more than happy to put them in informational RFCs. We have dealt with different WGs on this sort of thing. ... Thomas: That would be great. Erik: Both issues that came up and what has been tested. It would be useful to know both to progress on the standards track. UNH Guy: I can post a pointer to the white paper from November to the list and do the same thing for the next event. Usually you see a lot of mail to the list during one of these events. Those are questions from people trying to figure something out. Erik: It sounds like we have a way of getting started here. Is there anyone who would be willing to work on a draft starting with some UNH material? Please raise you hand. Donald: I've actually put together a skeleton for such a document and sent it to a few people but it isn't much of a draft. I saw about a half dozen volunteers. Ralph Droms [outgoing AD]: What I'm interested in, for each item, is are there people in the WG willing to make a commitment to work on this item. It is useful to know if people are interested but it might be helpful to get actual names of people that you can guilt into doing real work. Donald: In most cases, there exists a personal draft or drafts. I think there is an implication that the authors of those drafts would be wiling to continue to work. Erik: We can ask explicitly: are you going to work on number five, that is put in cycles to write and review drafts. About six. Item six, same question. About 3. Item seven, assuming we do that: about six hands but not being held as high. And number eight: at least five. Going through them all for completeness, are you willing to work on number one? About eight. Number two, who's going to work on this? A bit less than ten. Number three: six - eight - ten. As I count the number of hands keeps going up. Number four, different links that we will re-word: About ten also. OK. Sam: What is the purpose of number 8? Erik: if we want to make this a draft standard, we need to have an interoperability report that all the features have at least two interoperable implementations developed independently. ... Sam: Where do you stop? Many things are being worked on right now. Erik: I think this is with reference to the base spec. We can, at least test everything people have implemented. But if we are saying we want the base to be a draft standard, we need to move this way. Sam: Have all the vendors been participating in interops? That is something the IETF cannot mandate. Donald: Sure. I would say that relatively few vendors so far. The first interop had three participants and the second had four participants. So that's not all the people that claim to be vendors. Thomas: My suggestion for 8 is to take out the requirement for a public RFC. This is important, but an RFC is overkill. Yes, doing an interop should be in scope for this or any WG. But we are getting ahead of ourselves. There are optional things that have not been implemented and would have to be to advance the base spec. Donald: Understand, but this Charter item doesn't say anything about advancing the base spec. So if we just remove the need for an RFC and maybe make if "reports" rather than "report' would that be acceptable? Thomas: The IETF does not publish many interoperability reports. I don't think anything about publishing is necessary. Donald: I don't know. Some people don't want the WG to do anything that isn't in the Charter. Erik: Even if it isn't in Charter, we could ask our AD down the road if we could do this informational RFC. Ted Lemon (Nominum) [incoming TRILL AD]: I wouldn't object to that. Ted: I would just like to note that you did a bunch of shows of hand. And for some show of hands of people to work on the document, there was a good deal of diversity and those documents will probably happen. And for some, it was exactly the same people who had raised there hand for something else. My concern is are you going to work on those in parallel or should you try to prioritization. And if the answer is that you should prioritize then one thing I would suggest is to hold that out of your Charter. I not suggesting you must, just that you might. And if you do follow that, I would be very happy to see that the item gets back into the Charter when you are ready to work on it. Donald: I appreciate it but a Charter revision is basically a pain. I would also say that, vaguely, these eight items are intended to be in order of decreasing urgency. Erik: OK. Maybe we should ask people to send mail with priorities. Then if there is something people think we should work on but everyone give it lower priority, then realistically, it is less likely to happen until we have taken care of higher priorities. I don't know if people think that would be useful or not. Erik: There is one more page with the end of the Charter which just says we are going to work nicely with other groups in the IETF and 802.1. Just a bit of improvement in the wording for the current text. That's it for the Charter discussion. 20 min. TRILL OAM 1, Tissa Senevirathne, Donald Eastlake =========== draft-ietf-trill-oam-framework-01 (ready for WGLC?) draft-tissa-trill-oam-fm-01 (ready for WG draft?) Donald Eastlake (Huawei): [presentation, see slides] If people don't mind, I'll just sit here and give the slides trying to channel Tissa. The requirements draft has been approved and is in the RFC Editor's queue. The framework draft is a WG draft. The fault management draft has recently been updated and is now draft-tissa-trill-oam-fm-01.txt and there is now a performance management draft posted. Donald: Next steps suggested by Tissa on the framework draft: Get volunteers to review by end of month. Update draft based on their comments, and then WG Last Call. ... Are there volunteers? Maybe I should go through the slides first and we can come back? I see people nodding their heads yes... Fault management document similar then move to WG document. If we followed those steps than we would have the framework approved by the WG and the fault management draft a WG draft and which point it might be appropriate to have the fault management draft reviewed more formally by 802.1. ... Uses the framework of 802.1ag and the messages where applicable ... nested OAM ... frame structure ... network, service, and flow OAM ... addressing model ... Donald: Going back to next steps. Are there any questions? I think some people in this room have been helping on these drafts. How many people have looked at the framework draft? Nine or ten. How many have looked at the latest fault management draft? Fewer but more than half a dozen. Are there comments or questions? Do people think the next steps are reasonable? If there are no comments, I'll go ahead and try to get volunteers. Erik Nordmark: Can we get 5 volunteers or so to go over the framework document carefully as we move towards Last Call? If we don't know your name you should give it to us so we can come bug you later. Looks like six volunteers. [The volunteers recorded were: Sue Hares, Ali Karimi, Thomas Narten, Dan Romascanu, and Olen Stokes.] Erik: The other question, it didn't seem like there were that many people who had read the fault management draft. Should we just make it a WG draft or should we get volunteers to review that now before making it a WG draft? The milestone says January of this year to make it a WG document because people wanted an aggressive date. What really matters is getting a quality document to the IESG. Thomas Narten: The priority should be to get the framework out the door, out of the WG. I think the other document should be just behind it in the pipeline but not much overlap. People should review the fault management document to see if it is ready to be a WG document. I don't think we have any competing draft. Erik: Right, we have a single fault management draft and a single performance management draft. Let's plan to ask this on the list for the fault management. We have volunteers in place to review the framework and after that we will WG Last Call it. But before the next IETF meeting, we should get review of fault and performance management drafts. Thomas: If you want the [fault] document out by July that really means 2 or 3 revisions. Maybe you need 2 or 3 people to review and then 2 or 3 other people to review, and it will become clear when it is done. Maybe a revision every 4 to 6 weeks. Erik: For the fault management document we will at some point, before July, ask whether it is ready for WG document. But let's get people reviewing it somewhat in parallel with the framework draft. Donald: OK, we need to move along on the agenda. 10 min. TRILL over PWE3, Lucy Yong =============== draft-yong-pwe3-trill-o-pw-00 (for information) Lucy Yong (Huawei): [presentation, see slides] A new draft on TRILL over pseudowire. Sometimes parts of a TRILL campus can be at significance distance so may want to go over MPLS pseudowire. ... We suggest PPP pseudowire or Ethernet pseudowire. Many benefits. Do not need a new pseudowire type and do not change TRILL. These are common pseudowire types in the market. The draft discusses how to use them and talks about auto configuration and security. ... We presented this draft in pseudowire [PWE3] WG this morning and the comment was that this doesn't change pseudowires so, since the draft just specifies the process on the TRILL switch, it belongs in the TRILL WG. So we plan to change this draft to this working group. Any question? Erik Nordmark: So you say do this encapsulation or that encapsulation. I haven't look at the draft. What is mandatory to implement? Is one mandatory and the other optional? Lucy: Oh. We specify both options but in the draft the default is the PPP pseudowire. We talk about how to synch up if one device implements only one or both. Donald Eastlake: Currently neither one is mandatory. It is designed so that it will automatically default to PPP if implemented by both of them. If not, it will try Ethernet. And if they mismatch and there is no overlap, you can't talk. Erik: It is undesirable to have an RFC where both people can claim to conform to the RFC and they can't interop because there is no one mandatory way they both have to implement. Lucy: That is a fair comment. We will address that. That's it. Donald: How many people have read this currently PWE3 draft? A few. Donald: We have 16 minutes before the scheduled break. Maybe we can do part of the Directory Assistance item and then break and finish it after the break. We spent quite a while on the Charter, which I think was time well spent... 20 min. Directory Assist Mechanisms, Linda Dunbar, Donald Eastlake =========================== (draft-ietf-trill-directory-framework-04 (in WGLC)) draft-dunbar-trill-scheme-for-directory-assist-04 (to WG draft?) draft-dunbar-trill-directory-assisted-encap-03 (to WG draft?) Donald Eastlake: [presentation, see slides] There is a directory assistance framework draft that has been adopted by the WG. This [scheme draft] is about what mechanisms you would use to actually implement it. Donald: The goal is to reduce multi-destination traffic. You can just answer ARP and ND from directory information and it should reduce the number of unknown unicast MAC packets. If you have complete directory information, you can eliminate unknown unicast because either you know where it is or you know it isn't anywhere and can discard it because there is no use flooding it. Two kinds: push directories and pull directories. ... Push uses ESADI mechanism ... Push and Pull use a new Interface Addresses structure that lists address which refer to the same port. For example a MAC address, an IPv6 address, and an IPv4 address. ... Pull directory uses queries ... Pull replies can be negative including that the address is unknown or that you are not permitted to get the information. ... The draft covers cache consistency. ... Pull directory can push out updates if unexpired earlier answers have changed. ... Draft has a section on client modes of operation. ... Covers conflicts in data. ... The draft is still a bit rough and there are things that could be added. For example, the granularity of directory completeness is currently a data label but you might have a directory which was complete for all MACs in a data label under an OUI being use by some orchestration system's virtual machines but also had information on other MACs that might not be complete. ... So I think the authors should do another revision of the draft and then maybe ask for acceptance as a WG draft. As made clear at the time, the acceptance of the Directory Assistance framework draft as a WG draft was an indication by the WG that it wanted to pursue this direction. Erik Nordmark: I have a clarifying question as to the push directory. I just assumed we would use ESADI. How does that data get into the directory? Say you have your green VLAN from your slide and you have all those RBridges participating in the green VLAN. They can all advertise who is attached locally in ESADI advertisements and that is all you need to know. They all have MAC and IP addresses. Donald: In the current base spec, the RBridges learn MAC addresses and if you use ESADI with that you can learn what all the RBridges in a particular VLAN think are attached MAC addresses. But there is nothing in the base spec about IP addresses. And that would just give you global knowledge of what the local knowledge was but wouldn't tell you if some local station had gone away or moved. The Directory idea is mostly based on their being an orchestrator that can tell you, at least, where everything is supposed to be in a data center including IP and MAC addresses. Erik: That's one idea, I have some database. But the ingress RBridge could snoop packets to learn both MAC and IP addresses and in some environments you wouldn't need separate directory servers. Sure, as you scale that up you might want a dedicated directory infrastructure. Donald: Sure. Maybe we need more discussion of that. Snooping on IP is just one way. ... The idea of leaning IPs from snooping was in the earliest RBridge paper from 2004. But it isn't in the framework document, for example. Erik: The other question I didn't see is, if you are doing a pull, how you get notified of changes. Donald: There is actually a section in there that mandates tracking by the pull directory, at some level of granularity, about who has pulled what information from it so it can notify them of changes if that data has not yet expired. There is a way to send asynchronous "responses". The pull directory gives you a time and assumes, if that time has past, you have thrown it away so it doesn't need to update you. Donald: It is approximately the break time between the two sessions. So we will recess for ten minutes. It has been asserted that there is coffee.... 10 min. Break [There was a ten minute recess] ===== Donald Eastlake: called meeting back to order (cont.) Directory Assist Mechanisms, Linda Dunbar =========================== draft-dunbar-trill-directory-assisted-encap-03 (to WG draft?) Linda Dunbar (Huawei): [presentation see slides] This is a continuation of the directory assistance. This draft was originally included in one directory assistance draft but people wanted it split out. Motivation for this draft is to reduce the number of addresses the TRILL edge has to learn. ... RBridge end nodes can be configured to accept pre-encapsulated frames. RBridge edge nodes do not have to do anything different from now, they still decapsulate. ... More comments are welcome. Erik Nordmark (Cisco) [Co-Chair]: You said you don't have to have an Appointed Forwarder. That assumes there are no bridges in between the end station and the RBridge. If there are bridges between, you still need the AF right? Linda: No. Native Ethernet frames just stay locally. Edge RBridges can discard them. Erik: Oh, because you have the TRILL Header from the beginning. Linda: Right. Erik: OK. Radia Perlman: That's assuming all of the end nodes on the link are this kind of smart end nodes. But if you had a mixture of smart and dumb end nodes, the Appointed Forwarder still has to encapsulate the native frames from the dumb right. Linda: Right. ... The benefit of having only some smart end nodes is to still reduce the number of broadcast frames. Radia: Also if the RBridge is not aware of the end node being smart, while the end station is looking things up in the directory, on the return traffic, the edge RBridge still has to look up the destination address. Linda: Right. Radia: So it is really in the case where you get rid of the dumb guys that you have the advantage. Erik: How many people have read this draft? About five. We seem to have lost some people to the cookie break. I think we have a presentation by Radia later with more on smart end nodes. Erik: In my mind, not speaking as chair, would we do this with active-active edge? How would the pieces fit together. In some cases you might only use one but I haven't figured it all out. Radia: Yeah, I'll talk a little bit about that later. 20 min. TRILL OAM 2, Tal Mizrahi ========= draft-mizrahi-trill-loss-delay-00 (to WG draft?) Donald Eastlake (Huawei) [Co-Chair]: This is the first time I've used this physical laptop for presentations and the next one is the only one that is a PDF, not Power Point. ... [short technical delay, one complaint from the back that they couldn't hear, an explanation from the front that just the mechanics of presenting were being discussed...] Tal Mizrahi (Marvell): [presentation, see slides] Loss and Delay management in TRILL. A key aspect of OAM. Used to verify service level agreement and for trouble shooting where the problem is degradation rather than a fault. ... Fault management presented earlier is based on 802.1ag. Performance management to be based on Y.1731. ... enables common tools ... loss/delivery rate ... delay/jitter ... each has a one-way and a two-way variant. ... Another aspect is proactive versus on-demand. Also point-to-point and point-to-multi-point. ... Forward and reverse paths may be different and may have different flow entropy. We have a TLV to set the return entropy. ... Radia Perlman: What I think you mean by entropy is a field in the header that determines the path. Are you saying that if A sends a packet to B with some entropy, the path will be the same if B send to A with that entropy? Tal: Not necessarily. Tal: First draft posted about a month ago. Comments welcome. Some comments about minor inconsistencies with Y.1731 have been received. ... We would like to get many comments and would suggest this be adopted as a WG draft. Sam Aldrin: Most of the things/mechanisms have been done in IPPM for IP. Do we really need to do this at every layer? Tal: So you are saying you would like something like BFD for loss/delay monitoring? Sam: Yes. Because one-way and two-way delay is very generic. It is not specific to TRILL but could apply to TRILL. Tal: Strategically, that might be a good way to got but tactically, for TRILL, we are going in the right direction to base OAM on Ethernet OAM. Sam: Sure, that's in the requirements. I did not understand from the draft how Multicast is done? Maybe you could provide more ... Tal: This works as is for measuring multi-cast, but the response will be unicast. Sam: Do you plan on specifying exactly how you are going to do things like, for example, how to cover all the paths. How can you use the entropy to monitor them? Tal: That sounds like a problem that is common to fault management as well as performance monitoring. So, I think there should be a common solution but I don't think that this draft is going to include it. We should work on that as a group and solve it for both FM [Fault Management] and PM [Performance Management]. X (Fujitsu): For slide 12, forward and reverse, is this a single maintenance entity or different maintenance entities? Tal: It is one maintenance entity. X: Criteria for using proactive or on-demand. ... Tal: That is a valid question but we haven't looked into that yet. Donald: Any further comments or questions? I don't see any. Read the draft. We did have some slack in the schedule but at this point it looks like we have just enough time for the remaining items. 15 min. Smart End Nodes, Radia Perlman =============== draft-perlman-trill-smart-endnodes-01 (to WG draft?) Radia Perlman (Intel): [presentation, see slides] The reason for smart end nodes it to save table space in the edge RBridge. So it does not have to learn all the destinations a smart end node is talking to. The smart end node only has to keep track of who it is talking to. So it seems fairer for the end node to do it. Also, if you have a black hole because a destination has moved, the end node is more likely to notice that the connection is not working and flush it from cache than the RBridge which will just keep sending. Radia: Another concept is what I call a dumb RBridge which is an end node that pretends to be an RBridge. It is visible to the campus and originates an LSP but it doesn't want to do any routing. It sets its overload bit so no one will calculate paths through it. It has to obtain a nickname, so it has to look through LSPs for that. The only downside for dumb RBridges is that they consume nicknames. But this is significant and is why we are thinking of doing smart end nodes instead. Radia: A smart end node is invisible to the rest of the network, does not originate an LSP or have a nickname. But it learns addresses and it does the encapsulation and decapsulation. It has to do the decapsulation to learn remote addresses from data packets. As opposed to what Linda presented where the end node did not need to learn, just use a directory so it did not need to do decapsulation. And when a smart end node encapsulates, it uses its attached RBridge's nickname. Radia: The Appointed Forwarder says "I can handle smart end nodes" and the node says "I am a smart end nodes and here is the set of MAC addresses I speak for." Then all data is encapsulated between the end station and the RBridge. ... Radia: The current draft had some complexity due to allowing both smart and dumb end nodes on the same link and maybe we could get that to work but, based on some discussion, it may be better to limit the link to smart end nodes. With a mix, you may have to double send multi-destination packets. So, probably the Appointed Forwarder will actually announce to the link that it will only service smart end nodes. A dumb end node on the link can still talk to other dumb end nodes but will be ignored by the edge RBridge. ... Radia: Of course an edge RBridge can have some links with smart end nodes and some links with dumb end nodes. ... It will always know what ports the smart end nodes MAC addresses are on because they announce themselves. ... Radia: Multi-homing ... have to be careful about load splitting ... can have address flip-flop. If you try to use a pseudo-node nickname for ingress, there are other complications. Erik Nordmark: Another constraint is that if you are sending multi destination packets, the ingress nickname has to be on the right tree chosen ... to avoid pruning. Radia: Correct, this is why we have the CMT. Yes ... active-active ... Erik: Also questions about which tree to chose. Radia: Well, CMT assumes a pseudonode. ... People should think about different solutions ... Also, using a pseudonode, all the end nodes using that pseudonode have to be connected to exactly the same set of RBridges. ... interesting comparison to the smart end nodes Linda was talking about ... ... eliminate RPF check complexity ... Thomas Narten: Why would the end node want to do this. I see why the RBridge would want to, but why would the end node want to. You are pushing the problem out to something else. Radia: Well, if your local RBridge has limited table size, you can guarantee the your learning gets priority. Thomas: Yes but as an end station vendor, why would I do all this work and debugging just because the local RBridge doesn't have enough memory? Radia: It's not just that, it is also the freshness of the information. An RBridge might send into a black hole and not notice. Thomas: But the high level argument is that the network should do this for me. Why should I bother? Radia: Well, it is an option. Les Ginsberg (Cisco): In the draft, you say the reachability information from the smart end node is going to be send in Hellos. Radia: Oh, I don't really care. Somehow it has to be communicated. It could be a Hello or something else. I don't care about syntax. It is only on a per link basis. It is not in LSPs. Les: The current draft says Hellos. What if it doesn't fit? Radia: Then you cycle through them. Donald: Les, if you recall I discussed with you the possibility of a flooding scope that included end nodes. Les: Well, it was a leading question. There is a draft for ISIS about flooding scopes for LSPs that may be helpful here. Radia: Yes, Donald mentioned that to me and it sounds really promising. Linda Dunbar: ... [example from Open Flow of virtual switches adding headers] ... Donald: We need to cut this off to keep on schedule. Erik: ... This gives the end node more control over its destiny. They can choose which RBridge to send traffic through if more than one are available. Radia: Also, if an end station wants to use fine-grained labels, they are only defined in terms of an TRILL Data packet, so this is the only way an end station can do that. 15 min. Active-Active Edge Problem Statement, Mingui Zhang ==================================== draft-zhang-trill-aggregation-03 (to WG draft?) Mingui Zhang (Huawei): [presentation, see slides] ... Recently this problem has been discussed on the mailing list ... MC-LAG used to connect end stations to multiple RBridges ... represented by a virtual RBridge, RBv, to avoid address flip-flop at remote RBridges. ... ... ... Erik Nordmark (Cisco): Two comments. One, yes, we need a problem statement. But this draft is really a single solution. Isn't a high level statement that people currently do these things with MC-LAG and other ways and want to continue to be able to do that when the core of the network is TRILL? Second, you seem to assume we assign a nickname per edge device. I think that is what we are trying to avoid. We should talk on the mailing list and try to crisp up the problem statement. Olen Stokes (Extreme Networks): I agree with that. What is the relationship of this to other active-active drafts. If this document is going to go through first we need a simple problem statement that can go through fairly quickly to avoid holding up the other documents. Donald Eastlake: How many people have read the draft associated with this presentation? Few. Two or three. Thomas Narten: I'll agree with what other people have said. The problem statement can be one or two pages of text. This doesn't have to be long, it just needs to be clear. 10 min. Vendor Channel Protocol, Donald Eastlake ======================= draft-eastlake-trill-vendor-channel-00 (to WG draft?) Donald Eastlake (Huawei): [presentation, see slides] I hope this will be fairly quick. In TRILL there is an RBridge Channel facility which is just a way to send typed messages between two RBridges in the same campus or between an RBridge and an end station on the same link. It's been approved and is in the RFC Editor's queue. For example, it is used as the envelope for BFD in TRILL ... It looks like this ... The idea here is to have a way for vendor's to send messages between RBridges that are typed for the vendor. If RBridges were IP devices or Ethernet devices, it would already be easy for vendors to do that. But RBridges are not required to have any IP or Ethernet links. For example, a transit RBridge could have only PPP links connected to it. The native way to address an RBridge in TRILL is by its nickname ... This is a way ... to have an OUI in the message to specify the vendor. ... And that's really all there is to it. It does not have any effect on routing or anything like that. Just a way, if a vendor has more than one RBridge in a campus, they can send messages to each other, the way the could easily if RBridges were required to have IP or MAC addresses. Erik Nordmark: How many people have read this draft? About five. Probably we should discuss this on the list. It might be interesting to talk about use cases. Thomas Narten: I guess this is inevitable but my standard fear is that this is an escape clause that lets vendors do whatever they want. On the other hand, if there is something that needs to be done, you want a standard way to do it. There isn't any easy answer to balancing this. 10 min. RBridge Edge Group State Synchronization, Weiguo Hao ======================================== draft-hao-trill-rb-syn-00 (to WG draft?) Weiguo Hao (Huawei): [presentation, see slides] ... Talks about multi-homing scenarios in TRILL. One is TRILL edge, the other is active-active. In base protocol TRILL edge, end stations are attached to a LAN segment with one RBridge for a VLAN to avoid loops. In Active-Active, connection is usually configured as a Multi-Chassis Link Aggregation Group. TRILL Hello protocol cannot run over MC-LAG. Two drafts are pseudonode nickname and CMT. ... There are other problems beside RPF check and address flip-flop. ... Multi-chassis LACP state ... RBv membership configuration and state synchronization ... CMT configuration and state synchronization ... link and node failures need to be detected quickly ... MAC table synchronization ... Radia Perlman: That is a nice example of where it would be better if the end node was doing the encapsulation. Weiguo: Yes. ... MAC synchronization between members of the edge group. A protocol needs to be provided. Summary ... protocol between RBridges needs to be multi-hope and satisfy the following requirements ... ... Questions? Donald Eastlake: We have unfortunately run out of time for this session. How many people have read the draft? Not very many. People should bring up questions on the list. 5 min. Wrap-Up, Chairs ======= Erik Nordmark: Yes. Thanks and see you on the list and in Berlin. == end ==