TRILL Working Group Minutes Hilton Atlanta, Atlanta, Georgia Chairs: Erik Nordmark, Donald E. Eastlake 3rd ======================================================== Tuesday 6 November 2012. 0900-1130, Salon C ======================================================== Minutes take by Jon Hudson, edited by the chairs. [Times given for items are the originally scheduled amount of time, not the amount of time actually taken.] Blue sheets sent around. Note Well shown. Donald Eastlake [Huawei, Co-Chair): This meeting will be covered by Meetecho [Meet Echo]. Erik Nordmark, my co-chair, will be unable to attend in person but will try to attend remotely. The meeting will start in a few minutes. We are having some technical problems. [8 to 9 minutes of delay] Donald: I'm going to go ahead and call the meeting to order. This is the TRILL WG. If you want the IDR WG, they are in Ballroom C, not Salon C. There may still be some technical problems with Meetecho but, then again, the first few minutes of the meeting are not that interesting. I'm Donald Eastlake of Huawei. My Co-Chair, Erik Nordmark of Cisco, will be trying to participate remotely. [Agenda Presentation, see slides] Donald: Note the Note Well. It primarily relates to the requirement to report IPR and gives the RFCs with more information on that. Is someone willing to be scribe? [Jon Hudson volunteers] By the way, Erik Nordmark's inability to attend this meeting is entirely due to the US State Department. Is anyone willing to be jabber scribe? [no volunteers] Well, anyone in the room who is on Jabber should relay any questions or comments from Jabber for the meeting, if possible. Donald: Agenda reviewed. Main topics: TRILL OAM, Fine Grained Labeling, and Directory Assisted Edge. Then there are some topics that are potential new work. All three of the main topics have at least one WG draft. No changes to the agenda requested. Donald: RFC status given... Drafts in RFC Editor?s queue listed... One draft in the IESG, the MIB draft. Two drafts in or through WG Last Call. draft-ietf-trill-directory-framework-01.txt is in WG Last Call while draft-ietf-trill-oam-req-02.txt has passed WG Last Call but the paperwork to forward it to our Area Director has not been completed. Other WG drafts listed. Olen Stokes (Extreme): What is the status of the CMT Draft? [Coordinated Multicast Trees, draft-ietf-trill-cmt-00.txt] Donald: Erik Nordmark posted a query as to how much more work people thought the draft needed. There was a strong positive response that, in my personal opinion, was a consensus that the draft was ready for WG Last Call. There is a mostly editorial revision that has not yet been posted. Related to this there is some work going on to revise our Charter. Many people think this draft, which relates to active-active at the edge, is very important, although not as important as some other things we are working on. So we are in discussion with our Area Director as to whether we can advance this document under our current Charter. Olen: So when will we know? Donald: I would expect to learn something by the end of this week. Thomas Narten (IBM): There are several drafts listed here that are not on the agenda for this week. I would like a status update for those drafts and why they are not on the agenda. Also I think that for the CMT draft, there were some substantive questions posted back in August. It is not a good sign when a draft sits for months like that. Donald: Sure, those are great questions. I'll go over each of the drafts on this slide [slide 7] in the order listed. Donald: CMT [Coordinated Multicast Trees, draft-ietf-trill-cmt]: there is a revision which is primarily editorial, in the works. There were some technical objections. There is a presentation on the agenda of "Pseudo Node Nickname", although if you look at the slides it says "An Approach to Unified LAN Edge", which relates very strongly to CMT. The CMT draft provides a way that RBridges at the edge can affect the structure of specific multicast trees at the edge. There is also an example use in the CMT draft and I believe all the technical questions related to that example use and the pseudo node nickname draft clarifies that a lot. Perhaps these two drafts will end up being advanced simultaneous. Unless there are further specific questions, that is my view of the status. ESADI [End Station Address Distribution Information, draft-ietf-trill-esadi]: ESADI is a facility in the base specification but there are problems with the description in the base spec. It can be used as a building block for the Directory Assisted Edge work. This draft is an ESADI update. I believe it is getting close to being ready to advance but is too complex. We need the WG to resolve whether it should be simplified or otherwise changed. Fine Grain Labeling: This will be discussed today. RBridge Options [draft-ietf-trill-rbridge-options]: This is a description of how to extend the TRILL Header. It has been adopted as a WG draft. One extension has progressed further and is in the RFC Editor's queue. This is somewhat controversial: some people think it is a great way to extend TRILL and some think it is a terrible way. Some say that no silicon to support it will ever be implemented. And so on. So it is somewhat questionable. VLAN Mapping [draft-ietf-trill-rbridge-vlan-mapping]: This is a rather older effort that has to do with the mapping of VLAN IDs. The idea was you might have two TRILL campuses that you want to connect to form one campus but, for example, the same VLAN might mean different things in the two area. There does not seem to have been much demand for advancing this recently. OAM Framework: This draft is in call for adoption as a WG draft. Feedback has been positive so far. We will be discussing this today. Donald: By the way, the sum of the times for the agenda items is less than our session time, so we do have some extra time. But that doesn't mean that items can take more or even exactly the amount they are allocated. It is fine for items to take less time than scheduled. Donald: There are TRILL related drafts that are WG documents in other WGs. In the ISIS WG, there is draft-ietf-isis-rfc6326bis that updates the TRILL Use of IS-IS RFC. And there is a draft in the L2VPN WG on TRILL over EVPN. People interested should consider joining those WG mailing list and/or participating in those WGs. Donald: There is also an individual submission, draft-mme-trill-fcoe-04.txt. This was presented to the TRILL WG some time ago and at that time people said that, since this doesn't change the TRILL standard, there is no reason for the TRILL WG to spend any time on it. So it was submitted directly to the RFC Editor as an Independent Submission. There is an Area Director who wants to see further discussion of whether this draft might conflict with something the TRILL WG wants to do. I posted a request for such discussion on the TRILL WG mailing list and so far all responses on the list agree that this draft does not need to be a TRILL WG draft and will not conflict with the TRILL WG. If anyone wants to come up to the microphone and say anything about whether this draft should be a working group draft or will conflict with the TRILL WG. So, I'll wait a while to see if anyone wants to comment. [silent pause] Thomas Narten (IBM): Well, since you obviously want someone to comment. Donald: That's up to you. I can't force anyone to come up to the microphone. Thomas: I think this is a no brainer. There is no conflict with the WG. It is harmless. There is no reason for this draft not to just go forward. Ralph Droms (Cisco, TRILL AD): Just so the process is clear, there was another Area Director that thought we had not adequately explored what the response to the Independent Submissions Editor should be. The next step is for Donald to gather the WG's response and communicate it to that AD. Pat Thaler (Broadcom, IEEE 802 Co-Chair): There is one thing I don't agree with in previous comments. The draft is not harmless since, as T11 has pointed out, it has some things in it that are misleading and that the author and the Independent Submission Editor need to deal with. But I agree that it does not impact this group. Donald: Well, one of the authors is in the room so you might want to speak with them after the meeting. Ralph: Just a process comment: I know that you know this Pat, but technical comments on the draft should go to the Independent Submissions Editor or the authors or both. What the IESG does is determine if there is a conflict with other IETF work. Radia Perlman (Intel): I object to the wording that the TRILL WG does not care about this draft. But I agree that we have no objections to the draft's publication. Donald: This is great! We have had discussion, as I requested. On to Milestones. Completed and Current Milestones shown. Donald: Actually all the "current" milestones are in the past, a problem. To solve this a list of updates milestones has been posted to the list. It marks a couple milestones as Done, move the dates of others into the future, and breaks the previous "Submit OAM to the IESG" milestone down into five milestones with dates in the future. Changing milestones is relatively easy. So they are not set in stone. We should probably have updated these before. Comments now would be welcome but these can also be discussed on the mailing list. The next slide is on the Charter. The milestone updates assume an unchanged Charter. Sam Aldrin (Huawei): On the topic of recharter, when do we expect this to happen? Donald: There has been a call on the mailing list for input to the Charter update and it is planned to do so, but just when that would happen I can't say. The WG has input to the Charter but the WG doesn't get to decide on its own Charter. I hope the WG Charter update is fairly soon. Donald: There are two items in the current Charter on which, as far as I know, no work has been done. These items are an Implementation Report and a study on the application of IS-IS security to TRILL. Ralph Droms (AD): Can we get a raise of hands of who might want to contribute to a implementation report to meet the stated milestone. [Show of hand by: Jon Hudson, Tissa Senevirathne, Linda Dunbar, and Donald Eastlake] Ralph: Thank you. Donald: Should I ask the same question on the security Item? Ralph: Sure. Radia: I am baffled by the wording on the security goal, it's lack of clarity is mystifying. Donald: Yes, it sounds like it's about data plane security but IS-IS security is about control plane security. Radia: I'd be happy to work on it in theory but I'm still mystified. Donald: Perhaps this can be fixed as part of the Charter update. There has been a call on the WG mailing list in connection with the Charter update. Presumably people can suggest changes to existing items as well as additions or deletions. Donald: Next item is OAM. The oam-req draft is a WG draft. The oam-framework draft is in call to be made a WG draft. And there is a related personal draft (OAM Fault Management) which I believe is a bit incomplete. 20 min. OAM, Tissa Senevirathne =========draft-ietf-trill-oam-req-02.txt, =========draft-samer-trill-oam-framework-02.txt =========draft-tissa-trill-oam-fm-00.txt Tissa Senevirathne (Cisco): [Presentation, see sides] Talk about status, updates, and next steps. Updates from Santa Cruz to Atlanta. We presented the proposal to IEEE 802.1 in Santa Cruz. We had planned to use different Op Codes, etc., but the feedback was to use the same Op Codes. Thomas: Your statement implies specific feedback, can you characterize or qualify the nature of this feedback? Are there written minutes? Donald: I think this was the unanimous feedback of all the individuals at that meeting who spoke on this topic. But only some spoke, some didn't, some spoke of other things. Thomas: Thanks. Tissa: Correction to slides at last IETF meeting. "Reviewed" by IEEE participant volunteers is more accurate than "Approved". Also, Stephen Haddock, had opted out of the IEEE participant volunteer group due to lack of time. Tissa: ... framework draft details ... layers of OAM ... Donald: One minor note: In the bottom right of most slides in this presentation is the name of the draft to which that slides primarily applies. Tissa: Frame structure ... following user data path ... identifying TRILL OAM packets ... multicast ... unicast ... OAM Ethertype at a fixed offset from TRILL Header ... unified OAM framework utilizing, where possible, the 802.1ag ... re-use Link Trace Message [LTM] and Connectivity and Continuity Monitoring [CCM], TRILL specific Path Trace and Multicast Tree Verification ... nested OAM ... Anoop Ghanwani (Dell): Conceptually it sounds ok, but it makes me nervous because in 802.1 you are required to filter by the MD [Maintenance Domain] level and that level appears early in the packet. Because of what we are doing, the MD level will be after the 128 bytes, so you will have to look well after 128 bytes into the frame. So you are requiring silicon to do rather deep inspection. That should be called out in the document. Tissa: We can do that. It also depend on which addressing model you are using. It is not like an 802.1ag maintenance point in a port but we use the shared addressing model. It is not a bump in the wire but a bump in the stack, if you understand me. Anoop: There will be OAM messages that have to pass through an RBridge. If you are using MD levels at that point, you will have to filter based on MD levels. Tissa: I'm not 100% sure what you mean, can we discuss this on the list? Anoop: Yes. Thomas Narten (IBM): I agree to some extent with Anoop. We have not yet agreed on 128 bytes. There are various factors and we may need a discussion on this. Tissa: We are currently proposing 128 bytes. Thomas: In what document? Donald: In the Fault Management draft. The 128 bytes size in not in the OAM Framework draft. Tissa: The framework document is flexible and the fault management document says it is 128. The fault management document is just a personal draft and we can adjust it. Thomas: OK. I'm not sure if 128 or something smaller or something bigger is the right value. I'm also sympathetic to the need to filter in terms of what the domain is and I'm not sure how we are going to do that. Needs to be efficient. Olen Stokes (Extreme): I would like to see some ASIC [Application Specific Integrated Circuit] providers comment as to if they are on board with this. Tissa: OK. ... How can we re-use 802.1 without re-doing the ASICs. ... CFM PDUs ... Maintenance Association not in LTM but is in CCM ... compare opaque structures ... no changes required to CCM except addition of some TRILL specific information ... default MA ... MD levels ... Tissa: Next steps, move Requirements draft to IESG, move Framework draft to WG draft. Socialize proposal to reuse 802.1ag to the 802.1 participant volunteer and in the upcoming [IEEE 802] San Antonio meeting. Donald: How many people have read the framework document? [over a dozen] Are there any objections to making the OAM framework draft ta working group draft? [Silence] So I guess we will go ahead and do that. Tissa: OK. As I said, one of the 802.1 participant volunteers will be presenting on the framework in San Antonio and we will update the Fault Management draft based on comments and feedback. Eric Grey (Ericsson, IETF Liaison to 802.1): Sort of speaking as the IEEE liaison to IETF: A couple of things were said earlier in the presentation that we have to be careful about. There are differences between IEEE and 802. That's why Stephen Haddock removed himself from the group of 802.1 participant volunteers. A big difference between IEEE and IETF is that silence in IEEE is not thought to be agreement. So the assumption that because no one commented everyone agreed was just because they didn't have the time to read or comment. The other thing is that if we really want to know that the IEEE 802.1 thinks about this, we have to do a formal liaison. Donald: One quick comment. It is clear that a number of the volunteers did read the documents because they specifically commented. In fact, I think that almost all the volunteers posted at least some comment, except Stephen Haddock. He was very busy, was quite reluctant to join, and I think just didn't have the time but the others did. Ralph Droms (AD): I agree that an official liaison is needed, but at an appropriate time, when the document is mature. It is good to get informal feedback is at this point when it is a WG document. Pat Thaler (Broadcom): Just on representation. Normally in IEEE we don't put people's names on a presentation unless they have agreed to it. If you want to be productive instead of fanning flames, you would not have a slide saying people had agreed to something. Commenting is not agreeing. And singling out Stephen Haddocks name is not going to help you. Let the presentation stand on its own. If you want to give the names of active supporters in the slides, that's OK. And I'm just trying to help here, not be judgmental. Tissa: I'm not very familiar with IEEE 802.1 process. I have been sending these slides to 802.1 people asking them if the slides are OK and they won't even respond to my emails. I have no way to see if this slide is right or wrong. I don't have a crystal ball. Donald, you know how hard I have tried to get feedback and I don't get anything! I do my best. Pat: I apologize if people are not responding but, of course, it is there choice whether to respond or not. Tissa: I'm talking about repeated reminders, asking if you can just please look at these two slides, not all of them, just two. So I don't know what to do. Someone has to help me. Ralph: I think one thing you can do is only put things on the slides for which you have gotten positive responses. Tissa: OK, we can leave out names in the future. Donald: We can follow these guidelines in the future but it is a bit hard to amend the past. Thomas Narten: You cannot assume consent through silence. It is asking for trouble. At some point we have to do things more formally. It's the right thing to do things informally now but if we mess up the informal stuff, it will make it harder when we get more formal. Tissa: I need someone to help me. I don't know what exact words to use. So I ask for opinions. If silence is being used as a defense for lack of response, we are not making progress. If that is going to continue, we have to do one of two things, either make everything formal or drop the idea of any cooperation with 802.1ag and go with something else. We have been spending too much time on this. Donald: Well, I'd like to make a point. You certainly can't use someone's name just because they haven't commented on something. Neither Barack Obama nor Mitt Romney has comment on this and if we listed them as approving this, that would be an error. But if someone agrees to be a member of a specific enumerated group, they are sent lots of copies of the document and lots of requests for comment, and everyone in the group who speaks up is of a particular opinion, then it is not unreasonable to say that the group is of that opinion. It is just the way everything works. When IEEE 802.1 votes on something, those who are in the minority do not have to resign from 802.1 just because the position of 802.1 does not reflect their view. But we can be more careful about this in the future. Thomas: My experience with human nature is that if you say some group agreed to something you had better be damn sure no one in that group will object to your saying that. Pat: At least saying it was "reviewed" is not saying it was "agreed". There have been discussions off line as to why this is so hard and why this relationship has been more combative than ideal. And I think one of the feelings is that to talk about whether something is a good idea, first you need requirements to be set. IEEE can't evaluate things without knowing what the requires are. Donald: The requirements document has passed TRILL WG Last Call. The position of the TRILL WG is that draft-ietf-trill-oam-req-04.txt is the requirements. Pat: I was not aware of it. Tissa: And it has been shared with IEEE. Thomas: We are at different point on this than we were even two weeks ago. Pat: The conversation happened before that. Tissa: I need help. I am trying as hard as I can to make it as friendly as possible and as fair as possible and I'm getting no where. I will tell you what I need or we will give up on this completely. I don't attend IEEE on a regular basis. I need one person to look at my slides and say this is OK from an IEEE standpoint or not because I do not have a crystal ball. I need at least one person to provide feedback. Pat: I understood that Norm Finn was working with you. Tissa: Norm is only looking at the technical slides and he is not an IETF person. Thomas: I'll look at slides. Pat: I'm willing to look at slides from the point of view of messaging. Go to the first body slide. I think it is a problem that it mentions Stephen Haddock. Donald: Given that a slide was publicly presented at the previous IETF meeting listing Stephen Haddock as a member of the group, we have to state publicly that he is no longer one. Tissa: Steve suggested that it be made public. Pat: I think you are not helping yourself. Donald: I think it is misleading not to do this. Tissa: We need to talk off line. I am not going to apologize because I have done what I can to get comments and feedback before this presentation. Eric Gray: As I have just been discussing with Ralph Droms, there is an appropriate time for a liaison. There are points at which the work direction is beginning to jell. This is convenient because next week there is an IEEE 802.1 meeting in San Antonio. So, if we were thinking of sending a note to Tony Jeffree [Chair of IEEE 802.1] saying that the framework draft is being adopted as a WG draft, this is a good time. Tissa: That would be from Ralph or Donald. [multiple faint speakers in discussion for a while, hard to decipher] Donald: It is easy for an IETF WG to send a liaison but it requires WG consensus which requires a process on the mailing list which typically takes two weeks. So, if we started this a while ago, we could send a liaison. But we can't do it based on a show of hands in this room because that is not the consensus of the WG. Eric Gray: No, a liaison from this WG to 802.1 comes from you. Donald: Read the RFC. Thomas: I think there is some wiggle room here. You are on pretty safe ground making factual statements. Let's try to do this instead of arguing why we can't. Donald: Ralph can certainly send a liaison. But I can't send a liaison in the name of the WG without WG consensus. I could maybe send it individually. Eric Nordmark (Cisco, TRILL Co-Chair, remotely): This may be a good time to say we are adopting this as a WG document. We need to make it very clear what that means. The bar is not very high in the IETF to be a WG document. The time when we feel the WG has consensus on a document is when it passes WG Last Call. I don't object to sending something now but we must make it very clear what the status of the document is in a way that 802 people will understand. [murmurs of approval] Donald: OK. There seems to be general agreement in the room on that. We have spent twice the scheduled time on this topic, although I think the time was well spent. X: Can you review the document status again? Donald: We are talking about adopting the Framework draft as a WG draft. The Fault Management draft is just a personal draft and there is no intent to adopt that as a WG draft at this time. But I think it would be useful for people to look at it and make comments. 20 min. Fine Grained Labeling, Donald Eastlake =========draft-ietf-trill-fine-labeling-02.txt Donald Eastlake (Huawei): [presentation, see slides] Donald: Not many slides. ... current format of TRILL data ... need for 24-bit label ... split into two parts as detailed in the draft ... necessarily incompatible with old RBridges ... old RBridges isolated ... compatible with some existing hardware and with earlier drafts ... Thomas Narten (IBM): If we are no longer using two different Ethertypes and backwards compatibility is gone, why not just define the fine-grained label as a new 24-bit field? Maybe the draft should give the reasons for this. We don't have to discuss this here. I'd really like to see it in writing. Donald: There is a list of goals in the draft one of which is compatibility with existing silicon. And there is a description there of the extent to which this is compatible with existing silicon which, while not perfect compatibility, is significant compatibility. That's the reason, I think. Thomas: I'd like to have the silicon manufacturers say that using a 24-bit field would be a problem. Conversations I have had have indicated that it isn't any harder than extracting two 12-bit fields and concatenating them. Donald: I'm not arguing that there is a big inherent different in the complexity of the silicon, I just saying there is a difference in what is supported by the silicon that is there right now. Thomas: I'd like the silicon vendors to say that. Donald: Well, I've received email from some of them saying that. Radia Perlman (Intel): What happens with existing RBridges if there is no VLAN tag? Donald: Depends on the implementation. I know some implementations check for the 0x8100. The specification says that 0x8100 has to be there but doesn't explicitly say you have to nuke the frame if it isn't there but some do. Radia: Right, but if you are a transit RBridge you don't have to care about the VLAN. Donald: Unless it is a multi-destination frame. Radia: So, in that case it just says "I can't do any optimization on the distribution". Donald: There are a lot of different implementations but the few on which I have information will all discard the frame because they actually check and if it isn't 0x8100, they discard the frame. Olen Stokes (Extreme): I wasn't involved earlier but was consideration given to just going with Q-in-Q and putting an s-tag on the front of it? Donald: Kind of, but that was something that didn't seem to be favored. Pat Thaler (Broadcom, Chair of the IEEE 802.1 DCB Task Group): The issue is that an s-tag has a specific meaning. To say that what's in there isn't really an S-VLAN but part of a longer ID wasn't acceptable. IEEE didn't want the Ethertype used that way and it's our Ethertype. Speaking for 802.1. Donald: OK, you're an 802.1 Officer. Olen: Let my rephrase. Was there consideration given to extending TRILL to support S-VLANs. Donald: There has never been much support in the WG for having what you might call Provider TRILL with S-VLAN in it and the like. It has been brought up but wasn't supported. But that is actually not related to the issue of fine grained labels. Hierarchical VLAN tags is, I think, an orthogonal issue. Eric Gray (Ericsson): Initial versions of the specification just said Q-tag. When it was pointed out that there isn't any such thing any more but there are C-tags and S-tags, based on our Charter which targeted enterprise, it was decided to use C-tags. As far as I know there isn't anything that actually prevents using S-tags other than the specification. But there are implications. So I think that lead to your decision to use C-tags. Donald: Well, it was the working group's decision but, as I say, I think it is orthogonal to the issue of fine-grained labels. Pat: Right, it is orthogonal because using S-tags or C-tags in any permutation doesn't get you a 24-bit label. If you want a 24-bit label using an 802 tag, you would need to use an i-tag and that has other implications. So the question is how to get a 24-bit label. And you are using your own Ethertype so, from an 802 point of view, it is your business how you handle that Ethertype. Donald: OK. How many people have read the -01 or -02 version of this draft? About a dozen people. Of those how many people are OK with this form for fine grained labeling. [Most] And how many people don't like this form. [2 hands raised including Thomas] Thomas: I object to the question. It's not that I have an issue with this format or think that some other format is better. I just don't think we have done the due diligence. I don't feel that I have the information in front of me to make the decision. Donald: Well, I think that appropriate due diligence and discussion is likely to happen on this during WG Last Call, so WG Last Call on this draft starts today. [brief pause] Donald: There appears to be no further discussion. We were a little under the allocated time for that item. 20 min. Directory Assisted Edge, Linda Dunbar =========draft-ietf-trill-directory-framework-01.txt, =========draft-dunbar-trill-scheme-for-directory-assist-03.txt Donald Eastlake (Huawei, co-Chair): There are two relevant draft, the directory-framework draft, which is in WG Last Call ending later this week, and the scheme draft that goes into more specifics on mechanisms. This presentation is more on the scheme draft. Linda Dunbar (Huawei): [presentation, see slides] Linda: Good morning. This is an update on the detailed mechanisms. It reflects the latest thinking so the presentation is a bit different from the draft. An updated draft should be uploaded next week. Goal is basically to reduce flooding by using central information to exchange information and thus avoid the flooding. Both flooding due to unknown MAC addresses and flooding of ARP and ND ... TRILL DIR (directory) ... several models possible ... framework draft covers push model and pull model, advantages and disadvantages ... use ESADI with some minor changes for push ... There are bits you can set in your LSP to say you are a push directory and/or that you are a pull directory. Anoop Ghanwani (Dell): Does ESADI already support using both IPv4 & IPv6 addresses to send around with a MAC? Donald: Current ESADI is specified to use the MAC Reachability TLV [RFC 6165] and just announces MAC addresses. For Directory you want to advertise more information to association one or more IPv4 and/or IPv6 addresses with a MAC address. There is an ISIS draft, draft-eastlake-isis-ia-00.txt, Interface Addresses, which is designed to announce these address sets that all designate an interface [port]. So the current ESADI just advertises MACs but there is a proposal. Anoop: OK. Why does it need to be called ESADI? Donald: ESADI is just a convenient VLAN scoped flooding mechanism. So if you are pushing information, it is easy to use. Linda: ... details of changes ... Sam Aldrin (Huawei): How do you insure backward compatibility? Donald: The current specifications say that these flag bits are sent as zero and ignored on receipt. So some RBridge that does not understand them will just ignore them. ... It is backward compatible, I believe. Sam: How do you know whether an RBridge supports these enhancements? Donald: Because you are the network manager. The idea behind Directory is that there is an orchestrator that knows where everything is, knows what everyone's MAC address is, knows the capabilities of the devices, knows where every IP address is, ... because you are God. Sam: Well, the assumption is that you know everything. What do you do if you don't and things are not responding? Donald: Well, it is optional for all RBridges whether or not they learn from the data plane. If you are using a pure Directory strategy, you would inhibit that. But, you could turn it on. If you are a Data Center and have suddenly lost track of where everything is, you are in deep trouble. You can have multiple redundant directories. Sam: I'm just wondering how you recover from that. Donald: Well, if you think there should be a disaster recovery section of the draft, I'd be interested in knowing what you think it should say. The draft doesn't necessarily assume the directory knows where everything is, you could have a mixed strategy. But the thrust of the draft is that the directory knows, and if you have lost that, you no longer know where any virtual machines are. I don't know what you do. ... You can always go back to data plane learning. Sam: I was just wondering if there is something in this draft that could help. Linda: You mean you want it to say that if the directory does not respond, you go back to data plane learning? Sam: Yes, something like that. Donald: By the way, one of the concepts in the pull directory mode is that you could ask the directory and it could tell you, sorry, you can't talk to that person because you are administratively prohibited. So the directory could answer negatively. Linda: ... If there are multiple push directories, you have a designated directory and it is the only one that sends information to be flooded. ... in pull model, you can ask any of the pull directories (for your VLAN) ... can query for a target address family ... pull response can include a validity time period ... could run with some VLANs as push and some as pull, hybrid mode ... Radia Perlman (Intel): There are some customers that want a discard to occur for an unknown address. Can we make the choice to flood or drop unknown destination MAC configurable? Linda: I'll add that to draft. It's applicable to both push and pull models. Radia: Another interesting type of hybrid would be to subscribe to push just to tell if something has changed but mostly use pull or data plane learning. 5 min. Aware Spanning Tree Topology Change on Rbridges, Yizhou Li =========draft-yizhous-trill-tc-awareness-01.txt Yizhou Li (Huawei): [presentation, see slides] Yizhou: I will give an update. First a quick re-cap. ... Two approaches in the base protocol: Appointed forwarder, and, in Appendix C, "Ethernet LAN Partition" approach. ... benefits of LAN partition approach ... problems with LAN partition approach ... local topology change propagation ... remote address purge ... solutions ... changes since last version of draft ... Any comments or questions? [none] Could I have a show of hands as to who has read this draft? Donald Eastlake (Huawei, co-Chair): Looks like about 7. Donald: We have exactly as much time left as is allocated for the remaining items. No, I'm wrong. We have eleven minutes less than the time allocated for the remaining items. The remaining items total 39 minutes and we have 28 so people should try to take less than their scheduled time. 15 min. TRILL Resilient Distribution Trees, Mingui Zhang =========draft-zhang-trill-resilient-trees-01.txt Mingui Zhang (Huawei): [presentation, see slides) Mingui: ... We presented on this last time. ... This time we present based on the comments we received. ... The back up tree should have the same root as the tree it backs up. The root RBridge must have more than one nickname. ... other options ... algorithm to minimize configuration ... maximally disjoint to primary tree, can be determined independently by each RBridge ... timer for switch back from backup distribution tree to primary distribution tree ... we welcome further comments and propose adoption of this draft. Donald Eastlake (Huawei, co-Chair): OK how many people have read this draft? That's a pretty small number so I suggest a message to the list urging people to read this draft. Thomas Narten (IBM): I have a high level question. How important is this document to the core of what we have to do as a WG? Seems like this assumes you have a distribution tree, which we have now, and the model is that if something goes wrong you just re-build the tree. Maybe there is a brief period during which things don't work. What we are doing here is building up a stand-by path. How important is this? Do we know that convergence is too slow? It seems to me to be pre-mature to work on this. Donald: I agree that that is the relevant question. How important is this draft? Perhaps you should post that question to the list. Donald: Next presentation on pseudo-node nickname. I guess there are about 12 minutes left. 15 min. An approach for unified LAN edge =========Zhai Hongjun, Tissa Senevirathne =========draft-hu-trill-pseudonode-nickname-03.txt Tissa Senevirathne (Cisco): [presentation, see slides] Tissa: I will try to go quickly. Hopefully there will not be too many questions. I will talk on an approach for unified LAN edge. This is in the CMT draft context. What we did, starting about a year and a half ago, is that Radia and I and Hongjun and other people came up with the pseudo node nickname idea and drafts. We have tried to combine these into a unified approach for shared LAN as well as the multi-point edge. The CMT draft solves the RPF problem. This draft solves various scenarios and errors and configuration problems at the edge. They complete each other. ... active-active forwarding, which is very popular in data centers ... failure scenarios ... avoids MAC - MAC flip-flop ... uses CMT draft and ESADI ... use Hellos in this draft ... ESADI will synchronize the addresses ... answers to questions from mailing list ... link failures ... advertise LAG IDs ... discussion points. Propose to move this to WG status. Donald Eastlake (Huawei, co-Chair): How many people have read pseudo node nickname draft? Six or seven which seems kind of marginal. But this fits with CMT and the WG did previously decide to make CMT a WG draft so there is a previous expression of interest in these issues. So it seems likely that the group might support this but I don't feel comfortable without further discussion. 12 min. AF Fair Share, Kesava Vijay Krupakaran, Anoop Ghanwanti =========draft-kvk-trill-fair-share-af-load-share-02.txt Donald Eastlake (Huawei, co-Chair): This is the last presentation. Anoop Ghanwanti (Dell): [presentation, see slides] Anoop: This presentation is about fair share appointed forwarder load sharing in a TRILL network. This is not my presentation. Two of my colleagues did this. Appointed Forwarders are responsible for ingressing and egressing native frames. ... No algorithm specified in TRILL for load sharing. ... you can do round robin or configure shares which are like weighted round robin. ... examples ... number of VLANs ... amount of traffic ... VLAN affinity set ... Any discussion on this, we can probably have it on the mailing list. Donald: One possible problem I see with this is that it adds information to the Hello message which some people consider to already be crowded. But there are other possible ways to handle it. Radia Perlman (Intel): Is it easier to configure each RBridge with just its information, which then has to be communicated, or is it easier to configure each RBridge with the information for all the RBridges on the link? Anoop: I don't know. I would lean towards each RBridge having the information for itself. But is transferring the information to the DRB really seen as a problem? Donald: Yes, some people see it as a problem. Yizhou Li (Huawei): It may be a problem if you change the appointed forwarder for a VLAN very often. Maybe we need some protection. If there is high traffic for a VLAN so we switch the appointed forwarder, then we switch back, there may be some temporary traffic loss. So maybe we need some protection against such flip-flop? Anoop: Right. Unless something is actually changing, I don't think anything changes. Yizhou: Maybe I don't understand. You have the VLAN affinity but if there is sudden traffic in a VLAN, I think you would change the appointed forwarder. Anoop: No, the VLAN affinity is statically configured. It is not dynamically done. The operator configures it based on what they know. Yizhou: So it is all static? Anoop: It is dynamic as to what RBridge is up, obviously, but other than that it is static. Donald: We can continue to discuss this on the list. We are basically out of time. Thank you for the presentation. This presentation is new. How many people have read this draft. Not hardly very many. That is not a good sign. People should read it and comment on the list. 5 min. Wrap-Up, Chairs ======================= Donald: Anything else people want to bring up for this meeting? I don't see anything. So thank you for attending and see you on the mailing list and the next IETF. Anyone who has not signed the blue sheets, they are up front so you should come up and sign them now.