IETF 79 - TRILL Working Group Minutes ---- -- ----- ------- ----- ------- Monday, 1300-1500 hours, in Valley Ballroom A. Chairs: Erik Nordmark, Donald Eastlake 3rd Thanks to Bill Fenner and Radia Perlman who took minutes. The chairs edited those minutes. The occasional "Notes" in square brackets below were added during editing of the minutes. ============ Administrativia (scribes etc), Agenda Bashing, Chairs The "Note Well" slide was presented and attendees were reminded to read it, if they have not already done so. Bill Fenner and Radia Perlman to take notes. There were no suggested changes to the Agenda. ============ Review of Existing Milestones, Document Status, Code Point Allocations, Interoperability Testing, and New Charter Erik Nordmark presented. In reviewing WG documents, he gave particular emphasis to the MIB draft which is believed to be in good shape but needs reviewers. Erik asked for volunteers. - Bill Fenner volunteered to review the MIB draft. On the New Charter, Ralph Droms reported that it is in progress and should be out in not too long from now. ============ OAM and BFD Support for TRILL Vishwas Manral, David Bond, Donald Eastlake draft-eastlake-trill-rbridge-bfd-00.txt Vishwas Manral and David Bond unfortunately could not make it to the meeting, so Donald presented both drafts. (see second draft below) Stewart Bryant: Curious as to why you've got 2 different BFD channels. Done work in PWE space to carry BFD over non-IP channels, and we do it with one ID. Donald: Maybe you can do it will one channel. I don't claim to be a deep expert on BFD. Much of the BFD part of this draft was copied from the BFD for IP RFC. Dave Ward reviewed this draft. Stuart: Check if we really need two. Let's make sure that we try to align all of the non-IP uses of BFD. Puneet Agarwal (Broadcom): Do we use the BFD control channel for BFD bootstrapping? Himanshu Shah (Ciena): You're using a reserved unicast MAC address for this? Donald: Yes, to be able to detect unicast OAM frames at the egress RBridge, since the egress has to look at the destination MAC address anyway. Himanshu: Could it be a multicast address? Donald: That could trip consistency checks - we're TRILL-unicasting this and you might have a problem if a transit RBridge happens to check that the inner DA is unicast. We use a special inner unicast or multicast address as appropriate for unicast or multicast OAM. Proposal to split into two drafts: 1. OAM Channel 2. BFD over OAM Channel Erik Nordmark: Show of hands, who has read the draft? Very few: probably not enough who have read it. Are there people here who think we should make it a WG document? A few. Anyone who thinks making it a WG document doesn't make any sense? None. We will check on the WG mailing list, proposing making draft-eastlake-trill-rbridge-bfd a WG document. ============ RBridges: Operations, Administration, and Maintenance (OAM) Support, draft-bond-trill-rbridge-oam-00.txt, David Bond David Bond could not attend so Donald presented. Puneet Agarwal: How does the transit RBridge know that it needs to send a message back in response to a traceroute? Donald: If you use a TRILL Header option it's easy. If you do it in the OAM channel it's harder. Puneet: If it's in the data path you'd have to test for this type of packet all the time. Donald: It's an optional extension you don't have to implement it Puneet: You should use the Hop count. Donald Eastlake: Coming next in the presentation! Stewart Bryant: You should see what's happening in the MPLS world, we've had to generate a whole suite of OAM tools. Even if you choose to do it a different way, it's good to learn the lessons that MPLS has learned by defining these mechanisms. There's already MPLS traceroute, ping, and BFD. Erik Nordmark: What documents should we look at? Stewart: Look at MPLS-TP documents, which will point to IP-free core... ============ TRILL Header Options, Donald Eastlake, Vishwas Manral draft-ietf-trill-rbridge-options-03.txt Presentation on current options by Donald. Second presentation on proposed changes from Vishwas. 1. Flow ID option should really be in a fixed location in the frame. 2. Having more summary bits saying what kind of TLV options are present so an RBridge can avoid parsing the TLV area if there are no options present it is interested in. 3. TLV improvement - length in words instead of bytes resulting in bigger type field. 4. ECN improvement so it does what is done for IPsec tunnels... Radia Perlman: How can you have a fixed location for the flow ID option? Donald Eastlake: I'll cover that in a minute - the proposed changes have the flow ID in a fixed location in the optional bit encoded options area. Donald gave the rest of the presentation. Erik Nordmark: Any comments in the room? No. Let's discuss these changes on the list. ============ RBridges: VLAN and Priority Mapping, Radia Perlman draft-ietf-trill-rbridge-vlan-mapping-04.txt Has been presented before, but has been modified a little bit due to problems with asymmetric mappings. If, for example, you drop frames in a VLAN at a region boundary, then if a path were to cross the bondary twice, you could parition the VLAN within a single region. And, with distribution trees, it is hard to avoid such paths being followed sometimes. So the draft now requires symmetric mappings. Puneet Agarwal: Some of the RBridges may only talk to East or West. Radia Perlman: If you only talk to one region, then you are inside that region... It's explicitly configured whether or not you're doing VLAN mapping. Puneet: If you have more clouds, and they all need to talk to each other, within the RBridge domain, you may need to instead map to a global space inside the RBridge cloud. Donald Eastlake: That's an implementation issue. The draft says you can do a mapping directly or through a universal space. Radia: If you had 100 different clouds, instead of doing 100^2 mappings, go via a global space. Puneet: I'm not sure this is an implementation issue - you have to be sure that all of the RBridges are doing the right thing. Radia: When you're advertising what your mapping is, if you had this complicated mapping it would be hard to announce, and having a canonical mapping might be a cleaner representation of how to announce your mapping. Donald: VLAN mapping draft was previously WG Last Called. This new version reflects all of the comments received; any objection to doing a new WG Last Call? No objections to another WG Last Call. ============ Future Work 1, Donald Eastlake This presentation coverd two topics that are independent of the new TRILL Charter: - Abbreviated Encapsulation for point-to-point Ethernet links. - TRILL over IP Linda Dunbar (Huawei): Why would we do TRILL over IP? Donald: Hook parts of RBridge campus together when it's more convenient to use IP for a part of that. Linda: TRILL over IP is a strange idea, if you think about TRILL as something that was created targeting the data center ... Stewart Bryant: Why isn't TRILL over IP just asking for a new GRE type and then writing a two sentence RFC? Will TRILL over MPLS be a TRILL pseudowire? ============ Future Work 2, Radia Perlman, Donald Eastlake This presentation covered four topic that have some relation to specific items in the new TRILL Charter. - ARP/ND optimizations - Multi-level RBridge routing - Data Center Bridging - DCB draft. - Fine Grained Labeling == Donald preseneted on using TRILL ESADI for ARP/ND optimization. == Multilevel TRILL-IS-IS, Radia presented slides An idea not on the slides: introduce hierarchy in the nickname, e.g., 4-bit area number, 12-bit nickname. == Data Center Bridging draft-eastlake-trill-rbridge-dcb-00.txt Draft needs to be extended to announce DCB support in the LSP. Claudio deSanti: Why do you need to announce support in LSP? Donald: Useful for management ?: Congestion notification has potential for TRILL work. Puneet Agarwal: This defines how RBridge generates a CNM. [Congestion Notification Message] Linda Dunbar: Reaction point has to get back to originator. Donald Eastlake: Assuming the congestion point that is signaling is a port queue, almost always the case, you have to implement pretty much the same logic at the port whether it's a bridge, RBridge, router, or whatever port. Linda Dubnar: The RBridge can encounter congestion too, what if it's a reaction point? Erik Nordmark: If the 802.1Qau spec allows a bridge to be a reaction point, then an RBridge should be able to be a reaction point too. Linda Dunbar: It feels like we're making a simple protocol much more complex to include RBridges. Donald: You don't have to suport the DCB protocols, they're optional -- but if you want to be a good data center switch you have to do these. The logic is the same in a bridge port or an RBridge port. Puneet: I agree that if you want to support a data center this must be done. The Congestion point must have a MAC address for the congestion point identifier; we're talking about TRILL-over-IP, etc.; we need to think about this case where the congestion protocol needs a MAC address but what if you have an RBridge port that doesn't have an address? [Research indicates that the latest 802.1Qau draft (Draft 2.4) says the Congestion Point Identifier (CPID) in a Congestion Notification Message (CNM) is an opaque 64-bit quantity. There appears to be no requirement to use a MAC address in constructing a CPID although an example given in the 802.1Qau draft does.] Donald: Question: Since people think this is important to support DCB, should we make this a WG document? Erik: Does anyone have a problem making this a working group document? Linda Dunbar: I'm concerned about complexity. Erik: The complexity is in 802.1Qau; if you want to implement Qau with RBridges this is how; if you don't want the complexity, don't do 802.1Qau. Puneet: The argument is similarly when you talk about supporting ECN: if you want to support it here's how you have to do it. Linda: My concern is that I was through this 802.1Qau process in 802. It took 4-5 years to finish it. If TRILL wants to improve congestion notification, maybe we don't have to use Qau if it's not the best one. Donald: I thought it would be easier to leverage the 4-5 years of effort than to start from scratch. Puneet: This draft is just trying to make sure that the congestion points are defined for TRILL. == Fine Grained Labeling Presented by Donald Eastlake. Paul Unbehagen (Alcatel-Lucent): Why not use a straight provider backbone bridging encapsulation? -- There followed a somewhat lengthy TRILL versus SPB discussion some of which was talking past each other as Paul Unbehagen used the term "end device", which, for some time, Donald thought meant "end station" when Paul was actually referring to "egress RBridge". Paul: How do we make sure that the receiving port will understand the ISID [fine grained label]? Donald: With the specifics presented in these slides, the egress RBridge would have to understand an 802.1ah body. Paul: So this is not designed to interoperate with PBB [Provider Backbone Bridging]? Erik Nordmark: The motivation is just getting past the 4k limit for data centers. Puneet: Why are we saying it's 802.1ah? It's just a TRILL encapsulation. Donald: There was some desire expressed on the TRILL mailing list not to define new field types for this but to re-use what 802.1 has done, so this proposal re-used 802.1ah's body. ============ TRILL WG Meeting Adjourned.