TRILL Working Group Meeting Minutes Monday, July 25, 2011, 13:00-15:00, Room 206 B, Quebec City Convention Centre, Quebec Chairs: Erik Nordmark (Cisco), Donald Eastlake (Huawei) Notes by Jon Hudson and Erik Nordmark and Jabber scribbing by Michael Richardson, edited by the Chairs. Donald Eastlake (co-chair): Attention drawn to "Note Well" notice. Blue Sheets distributed. Agenda bashing: no changes requested. Jon Hudson (Brocade) volunteered to be scribe. Completed, Overdue, and Future milestones were reviewed. One milestone related to support of DCB. It was suggested the people might want to look at draft-eastlake-trill-rbridge-dcb although it is not on the agenda for this meeting. It may be time to do a milestone update. TRILL document status was reviewed: On Friday, July 22nd, the base set of TRILL protocol RFCs issued: RFCs 6325, Base Protocol specification 6326, TRILL Use of IS-IS 6327, RBridge Adjacency Also, RFC 6328, which specifies the Network Layer Protocol Identifier (NLPID) for TRILL and for IEEE 802.1aq. The TRILL over PPP draft is in the RFC Editor queue. The RBridge MIB draft is awaiting AD review. Stewart Bryant: Is there a jabber scribe? Chairs: No, sorry, we should get one. Any volunteers? Michael Richardson (Sandelman Software Works): I'll do it. There are three OAM related WG drafts: RBridge Channel (draft-ietf-trill-rbridge-channel-01.txt) RBridge BFD (draft-ietf-trill-rbridge-bfd-00.txt) RBridge OAM (draft-ietf-trill-rbridge-oam-00.txt) The RBridge Channel draft has been through WG Last Call with objection only to the IANA Considerations, particularly the use of an IS-IS GENAPP code point. Erik Nordmark (co-chair): Please read the OAM drafts. We have had presentations on them in the past. Please discuss on the mailing list. Donald: The Appointed Forwarders draft (draft-ietf-trill-ietf-af-04.txt) is currently in WG Last Call. This is a three week last call because it extends over IETF meeting week. IEEE IPR Disclosures noticed: #439, #1567, #1579. IEEE Code points: Ethertypes have been allocated for TRILL and L2-IS-IS and a block of multicast addresses for TRILL use. Also an NLPID has been assigned for TRILL. ============================= RBridges: Fine Grained Labeling, Radia Perlman (Intel Labs) draft-eastlake-trill-rbridge-fine-labeling-01.txt Radia: ... slides ... X (Alcatel-Lucent): There are two Ethertypes, on each for C-tags and S-tags. There has been much work on these tags over the years. Simply using C-tags does not guarantee working with existing silicon. There is the I-tag Ethertype, used in PBB [Provider Backbone Bridging] with 24-bit service identifier, that exists and could be used. This is characteristics of providers so I don't know why you are using C-tags which are more characteristics of the enterprise. Radia: This should be discussed on the mailing list. Erik: When you say this is more characteristic of providers, it sounds like carriers. I was thinking this was for cloud computing. X: Yes, I probably used the wrong word. I meant providers of multi-tenant computer services, not metro-Ethernet providers. Linda Dunbar (Huawei): Are both tags added at the same time? Radia: Yes, one 24-bit quantity is written in two 12-bit pieces at once. Linda: In many cases a user C-tag is added early and it is not enough to scale so then later another tag is added. I don't understand why you are adding two. In IEEE you can add an S-tag and the C-tag is locally significant. Radia: Yes, in some cases you already have one tag. Then you have to map that to two tags. But there aren't enough bits to make it nicely hierarchical. Linda: In some cases, VLAN 10 attached to one RBridge may not mean the same as VLAN 10 attached to a different RBridge, so have to map the VLAN and the RBridge nickname. Radia: Right, it would be nicer if you didn't have to map and it was just hierarchical but that should probably be discussed on the list. I'm a bit afraid of running out of time... Anoop Ghanwani (Brocade): What really bothers me is that you don't care about the Ethertypes. If you don't care, please use two different Ethertypes. Radia: I just want to start the discussion. People who care about what types are used, please explain why you care. Unkown: Is this a hardware limitation? Anoop: No, I have security concerns with possible use of multiple tags with the same Ethertype. Currently bridges are not required to check for more than one tag. Ilya Varlashkin (Easynet) (via Jabber): Is this a software change or is a chip change needed? Dinesh Dutt (Cisco): Cisco, and I believe others, can do this with existing silicon. There is a software change also but almost all existing silicon can handle this. Ilya: If two datacenters using TRILL are connected via a carrier, can added tags cause issues. Donald: We are talking about the inner tags, after the TRILL Header, not the outer tags in the outer Ethernet header. Carriers can use whatever tags they need in the outer Ethernet header. They should not look past the TRILL Header. Michael Richardson: I deal with two carriers they just use C-tags. S-Tags are not as used as often as you might think. Whatever you use will break for somebody. Just do what is pretty. Dinesh: Agreeing that usage is not all even and consistently used. The original implementation was Cisco that used two C-tags. I don't see why anything will break. We are talking about this working with RBridges, not bridges. Yakov Stein (RAD Data Communications): In a formalistic way, the difference between C and S tags in the IEEE is the format. There is a 1 bit tag difference between c-tags and s-tags, drop eligibility or CFI. But taking two tag to represent a 24-bit quantity is a change in format. There is the I-tag but that is only valid for MAC-in-MAC. You need to get a new Ethertype. Q-David Allen (Erikson): Why are you trying to solves this in Ethernet and not doing this purely in the TRILL Header? You risk breaking things like MTU which is basically still limited to 1500 bytes although there is the concept of a jumbo frame. TRILL had the concept of mixing the UNI and NNI on a link and now your are confusing tags. You are going down the wrong path. Erik: Do you have a suggestion for a better path that would work with merchant silicon? David: If you are talking about non-standard merchant silicon, you are talking about a solution this isn't ubiquitous anyway. Dinesh: (hard to hear, not using microphone) ... There are many things, like jumbo frames, that IEEE refuses to include in standards that everyone implements. ... Just because it isn't in the standards doesn't mean that people won't do it or mean it is not common practice. As long as nothing breaks, I think it's OK. ... David: There was an IEEE Liaison on this topic and it should be read. Dinesh: I agree that Liaison should be checked. My point is that there are things everyone does that are not exactly standard but are de facto if not de jure. That's all I was saying. For example, everyone I know, today, looks past the double Q tag to do better load balancing. So, all these points should be considered. Erik: How many people have read the draft? 15 hands. Should we work on this problem and take this draft as a working group document to use as a starting point? About 12 hands. How many people think we should not take this document as a WG document? 4 hands. ============================= Directory Assisted TRILL Edge, Linda Dunbar (Huawei) draft-dunbar-trill-directory-assisted-edge-00.txt Linda Dubar (Huawei): This a continuation of the work I presented at the last IETF. Then it was called Server assisted but it is really Directory assisted. Linda: ... (see slides) ... Dinesh Dutt (Cisco): If flooding is done by Top of Rack switch, then multiple RBridges will get the frame according to your diagram. Linda: Yes, but with Directory Assistance frame gets encapsulated to a specific RBridge. Dinesh: Oh, you are assuming changes to the ToR IEEE 802.1 switches. Linda: Yes, we call them simplified RBridges. They do Directory assisted encapsulation but do not participate in routing. Dinesh: This is the first time I've heard of simplified RBridges. Not that I'm opposing it... Paul Ubehagen (Avaya): Can you elaborate on that a bit more? Does the host do the directory look up? Linda: No, the ToR switches. Paul: From what you said, sounded like the hosts could do it. This sounded like the work being done in the IEEE Qbg EVB group. Linda: Qbg is about virtual machines talking to the first physical switch. There isn't much relationship. Paul: It's about moving processing up into the first physical switch that can do all the policies. A lot of work was done on EVB requirements. Be careful you don't conflict with Qbg. Linda: I am quite aware of what's going on in Qbg. It is orthogonal. This is pushing down the RBridge function. Donald: We are getting further behind schedule. No one else can join the line at the microphone. Erik Nordmark (Cisco): I understand what you are doing. But how do you discover what the nickname is for the Directory or whatever to remember, and how is that shared? You are caching the nicknames for the egress RBridges and need to be able to detect changes in that. Linda: Those are some of the details. May need a protocol from the edge real RBridge to the simplified RBridges to tell them what nicknames they can use. Puneet Agarwal (Broadcom): If we take out control plane, why not just run the data over IP? Why do you need TRILL any more? Linda: You still need to discover the topology and you need a control plane between the aggregation switches. Puneet: But you could just use IP routing. Linda: Yes but Data Centers want to expand their Layer 2. If you use IP routing and move a Virtual Machine from here to there, you have to reconfigure the routers or it will be in a different subnet. Puneet: I'm talking about encapsulation into an IP tunnel. Linda: Yes, you could to IP encapsulation but the amount of Layer 2 to Layer 3 mapping information is very large. In any case, I'm talking to the TRILL WG here. You could also do MAC-in-MAC encapsulation, but that's something to be discussed in the IEEE. Puneet: So, what are you asking the group? Linda: I want to introduce the simplified RBridge that can do encapsulation but does not interact with routing. Dinesh: This started as a simple statement: Use a directory, there is a directory so you can do some interesting things. But now it is moving to be about a simplified RBridge. It sounds like a solution looking for a problem. I think that should be split off. I'm sure lots of people can come up with interesting things to do if there is a directory. Presumably you are here to see if the working group is interested in the proposal. What is the proposal? A directory and a simplified RBridge and a bunch of other stuff? It seems to be 15 ideas or however many. Focus the draft on the Directory. I've not heard of simplified RBridge before. I'm against adopting this. Donald: Linda, do you have more slides? Linda: Just one. It shows that you can use a phantom nickname to avoid an RBridge getting a frame with its own nickname as the source. But on the points in the draft, there are two: A simplified RBridge that does encapsulation but does not participate in routing. A Directory that is necessary to make that work. Linda: Those are the two ideas I am proposing. Anoop Ghanwani (Brocade): Essentially you are addressing scaling by having static routing at edge and dynamic routing in the core. Linda: Yes. Anoop: One thing I should point out is that it is odd that no one has thought of this in the IP world. I think you will find that if you run something like ES-IS at the edge and then add failure detection for these top of rack switches and have some way to propagate the failures then I think the "simplified" edge will be like IS-IS in complexity. Linda: The edge topology is very simple. You could run a little IS-IS instance at the edge. But it is very simple. Anoop: I don't know that it will end up so simple. Everything will have to be at least dual connected. ============================= Pseudonode Nickname, Hongjun Zhai (ZTE), Fangwei Hu (ZTE) daft-hu-trill-pseudonode-nickname-00.txt ... slides ... Donald Eastlake (Huawei): Recommend that people read the draft. Anoop Ghanwani (Brocade): All of your examples show a link attached to just two RBridges. What happens if you have multiple RBridges with different links connected to different sub-sets of them. Say I have a link between RB1 and RB2 and a link between RB2 and RB3. How do the pseudo-nodes work? Donald: Those are two different pseudo-nodes. They are different links. Anoop: What does this do to nickname proliferation? Donald: Good point. ============================= TRILL Header Extension Simplifications, Donald Eastlake 3rd (Huawei) draft-ietf-trill-rbridge-options-05.txt ... slides ... Thomas Narten (IBM): How much is here is motivated by a real concrete proposal even if it is not fleshed out yet? Hop-by-hop for example, we have mostly dispensed with that in IP. It might be a very hard sell to implementers. Donald Eastlake (Huawei): I think the main use of hop-by-hop might be in connection with OAM or for something like record route or source routing an OAM message. Thomas: So it would me used for control, not data? Donald: My opinion is that that would be more likely. Thomas: I thought the FlowID was the most interesting thing. You would want to define it early and have it in an easily locatable place or it might never get implemented. I don't like pushing it out. Thomas: A third comment. On the Alert bit I think this is horrible. It should be an implementation decision, not an architectural decision, whether it goes to the slow path. People should feel free to implement this as efficiently they want. Donald: But OAM frames, according the current design, just look like TRILL data frames so they can zip right through. Without some obvious indication, you would be requiring all transit RBridges to look deeper into the frame of all multi-hop TRILL Data frames. Thomas: Well, if it is restricted to the OAM case, that might be OK. Donald: Alert was originally restricted to OAM, or at least the RBridge Channel facility. Wording could be added to restore that. Erik Nordmark: Does it have some specific semantics for OAM? If someone wants to implement OAM, they should be able to do that in hardware. Donald: If this was re-named the OAM Alert. Thomas: I would look at it differently in that case. Thomas: Perhaps to repeat myself, is there motivation for this stuff? Donald: There is the draft-eastlake-trill-rbridge-more-options draft that list a number of proposed options. Includes a data security option. Thomas: Should concentrate on things likely to be implemented. The more complex the options facility the less like it is to be implemented. Donald: One attempt to improve the usability was to design the options feature so that a transit RBridge need examine only one bit to determine that there are no critical hop-by-hop options in a frame, that is if it is safe to forward. So if would be easy to implement so that you could tunnel options between ingress and egress efficiently even if transit RBridges implement no options. Erik Nordmark: Suggestion: Maybe just call the Multilevel bits "reserved" since multi-level isn't being standardized now. Donald: Sure, I think I just labeled them multi-level so as to provide motivation for reserving them. They might never get used for that. Erik: How many people have read this draft: quite a few hands. Donald: I think it needs some more discussion on the list because of these points that have been brought up. Erik: OK, lets do that. ============================= Adaptive VLAN Assignment for Data Center RBridges, Mingui Zhang (Huawei) draft-zhang-trill-vlan-assign-01.txt ... slides ... Florin Balus(?) (Alcatel-Lucent): How do you avoid duplicate packets. How do you avoid duplicates with flooded frames. This was solved before, check BGP L2VPN. You might want to look at that. Mingui Zhang (Huawei): Only one node can send a multicast or broadcast frame. If another gets it due to the hashing function, it will just discard that. Donald: We have two items left on the agenda but not enough time... I'll stop the ESDAI presentation early enough that there will be a few minutes for the last presentation. But apparently there is no other WG meeting in this room after ours. ============================= The ESADI Protocol, Hongjun Zhai (ZTE), Fangwei Hu (ZTE) draft-hu-trill-rbridge-esadi-00.txt ... slides ... Donald: People should look at this draft. I think ESADI is an important protocol but the draft needs a little more work. Donald: At the beginning of the meeting I asked people to look at draft-eastlake-trill-rbridge-dcb. How many people have looked at that draft? About 4. Should be discussed on the list. ============================= FCoE over TRILL, David Melman (Marvell), Tal Mizrahi (Marvell) draft-mme-trill-fcoe-00.txt (very limited time because earlier presentations and discussion ran over) Tal Mizrahi (Marvell): This draft is intended for informational. ... selected slides ... Anoop Ghanwani: Are you changing the TRILL header hop-by-hop. Donald: The frame is being TRILL encapsulated and decapsulated at each hop. Anoop: So the TRILL Header isn't doing anything. The whole path is computed by FCSP. If you are running both control planes, why have the TRILL Header at all. Tal: There is a slide on that: not all RBridges are FCRBs. In that case, you still want the TRILL clouds to do optimal routing. Puneet Agarwal (Broadcom): I don't see what this does other than state the obvious. FCoE is running over TRILL. Why do you need a draft for that? Tal: We are just showing how they work together. Puneet: So, should I do a draft on IP routing over TRILL? Donald: It is a little different because you would normally have the routers at the edge but here you have the Fiber Channel devices distributed throughout the TRILL cloud with a savings in cabling and cabinetry. If the FC is external to the TRILL cloud, then typically you have to transit the TRILL cloud twice. So, it is a way of doing it. If you think this draft has no value, so be it. If the WG thinks that way, then it shouldn't be a working group draft. Puneet: OK. I don't think it should be a working group draft. Donald: Well, we are out of time. Thanks everyone and see you in Taiwan. [Meeting Ends]