TRILL Working Group Meeting 69th IETF Meeting, Palmer House Hilton Hotel, Chicago, Illinois ************* TRILL 13:00-15:00, Wednesday July 25, 2007, Adams Room Minutes taken by Radia Perlman, augmented and edited by co-chairs Erik Nordmark and Donald Eastlake 3rd Chairs politely asked for notetakers, then pleaded, then pleaded again, and finally got someone to agree to take notes. No one volunteered to be Jabber scribe. Agenda bashing by Donald. There were no changes in the agenda but it was noted that the division of topics between the two sessions is not firm and topics might slide from today's session into tomorrow's or be advanced from tomorrow's to today, depending on how things go. Erik Nordmark went over our goals and milestones, and what we are behind on. Although we have achieved the milestone of sending a Routing Requirements document to the IESG for review, events have somewhat passed that document by. Working group consensus has been determined via the mailing list to be the selection of IS-IS as the routing protocol for TRILL and to withdraw the Routing Requirements document and include its key points in the Architecture document. Although WG consensus had already been reached on these points, as a further confirmation the meeting was asked if there were any objections and there were none. There was then some discussion about the IESG "discuss" votes that had been cast questioning the routing requirements document. These were numerous and partly due to it being the first TRILL output document the IESG had seen and partly due to a misconception that it was intended to provide overall TRILL requirements rather than just routing requirements. Presumably these "discuss" votes go away when the document is withdrawn. There was discussion of the IEEE 802.1 review of the architecture and protocol documents required by the TRILL Charter. Eric Gray has already informally presented the architecture to 802.1 and posted to the TRILL mailing list the feedback he got. Nevertheless, it is felt that a more formal review, requested in writing, is required making clear that the primary goal is feedback on any changes TRILL makes in the Ethernet service model. It was generally felt that IEEE review could overlap WG Last Call but no specific consensus determination was made on this point. ****** "The Architecture of an RBridge Solution to TRILL" draft-ietf-trill-rbridge-arch-03.txt, Eric Gray. See slides "TRILL Rbridge Architecture". Eric Gray presented changes in Architecture document since last meeting. Terminology: Architecture and protocol spec had different terminology. A small subgroup managed, with lots (350 emails over 20 days) of emails, to come to agreement on terminology. Thanked Silvano for his leader- ship of that effort. Terminology results are linked from the TRILL WG home page at http://www.postel.org/rbridge. Latest Architecture document revisions are mostly getting terminology consistent with that agreement. Raised some questions about whether some additional issues needed to be explicitly addressed in the Architecture document. The specific points mentioned in the slides will probably have to be resolved on the mailing list. Ques: What is an architecture and why do we need a separate document for it? For instance, should how to determine the initial value of a hop count be in an architecture document? Discussion followed, saying specifically for a hop count, the architecture document shouldn't specify mechanisms such as initial values, but instead concentrate on saying that it is important to limit the impact of tempoarary loops, and leave specific mechanisms chosen (such as initial hop count setting) to the protocol document. Comment: There should be a model in the architecture document. Comment: Having a good tutorial document plus a design rationale that explained the design decisions would be great. Comment: A tutorial document makes sense. Comment: Divergence between unicast and multi-destination paths is an important topic. The topic of multi-pathing then came up starting with a comment that there is nothing in the architecture document on this subject today. It only talks about shortest path. Comment: The architecture document should mostly just say that multi-pathing is possible, should be based on flows, and may cause reordering between flows. The criterion for being in a flow is outside the scope of the TRILL WG. Other issues with the architecture document will be discussed on the list. Suggested addition to the architecture document to talk about VLANs raised all sorts of issues. There were discussions of whether it makes sense to think of per VLAN instances of TRILL, VLANs versus subnets, etc. Comment: TRILL does not provide a native method for inter-VLAN communication. Suggest just saying that RBridges only route within a VLAN. Ans: It is important to capture in the architecture the separation of core from endnode/VLAN information. The author asked for input and hopes to finish up the Architecture document by the next meeting including slimming the document down somewhat. *********** "Rbridges: Base Protocol Specification" the past draft-ietf-trill-rbridge-protocol-05.txt Slide presentation by Donald Eastlake 3rd: "Base Protocol Document: -03 to -04 to -05 Changes" What changes have occurred since last meeting? Changes between Version -03 and Version -04: Terminology changes. For instance, TRILL is the protocol, RBridge is the device. ARP/ND optimization removed Made it possible to do options by adding an optional length field, version/variation field. Allow for learning of remote end station addresses from decapsulated data packets; use of per VLAN IS-IS made optional for transmitting that information. Add priority for nickname allocation, as well as the ability to configure nicknames. Moved the "multicast router attached" and IP multicast group membership information to the core IS-IS instance so trees can be pruned in the core. TRILL IS-IS frames are always encapsulated in TRILL Ethertype and Header, and have inner MAC DA = All-RBridges. There was some somewhat complex discussion about using a second multicast, different from All-RBridges, say All-IS-IS-Rbridges, as the inner MAC DA for TRILL IS-IS frames for pedagogical value, to make the protocol easier to understand, and perhaps clarify things if you have TRILL in TRILL encapsulations. It was noted that this would mean that the All-RBridges multicast address would never, in the current protocol, appear as the inner MAC DA, as the only case where it had appeared was with TRILL IS-IS frames where it would now be replaced by this new multi-cast address. ** New Consensus to be confirmed on mailing list: Utilize a different multicast address ("All-IS-IS-RBridges"), allocated to RBridges, as the inner MAC destination address of TRILL IS-IS Frames. It was suggested that, since we will now need two multicast addresses, perhaps, as was suggested a long time ago, TRILL should request an allocation of a block of 16 multicast addresses to allow for future evolution of the protocol. The question was then discussed as to whether this new multicast address should be used as the outer MAC DA for TRILL IS-IS frames. It was pointed out that the TRILL protocol (in draft -05) permits unicasting a TRILL frame out a port if there is only one intended receiver even if it is a "multi-destination" frame. The reason for this is reduce the burden if the inter-RBridge link is a bridged LAN. If the frame were multicast, it would be an unknown layer-2 multicast and would flood the bridged LAN, while a unicast frame would normally follow a single path to the destination. It was argued that it is easier to filter multicast than unicast, that making a special case for two parties is a bad idea because it makes things more complex, and the multicast could actually be one derived from an IP address (which version was not stated) and fake IP multicast membership reports issued so as to try to induce snooping bridges on a bridged LAN between RBridges to optimize distribution of the TRILL frames. There was no consensus reached at the meeting on this outer MAC DA question. There was only one speaker arguing for always using multicast for multi-destination frames. One person commented that the inner VLAN tag information should be in the TRILL Header to decrease the depth of packet inspection required. Other changes in the -04 version of the protocol draft were provisions for per VLAN Designated RBridge (DRB) election, adding a section on incremental deployment which dicusses the "wiring closet" problem, and adding considerable pseudo code, as well as expanding the Security Considerations section. Changes between Version -04 and Version -05: Eliminate "V" bit, which was to distinguish IS-IS messages, but was found to not be necessary. Changes to permit an outer unicast MAC address for an inner multicast MAC address if only one receiver. One way to look at the TRILL encapsulation is that the outer MAC addresses and outer VLAN tag are just transport artifacts to get the frame to the next RBridge or RBridges. They might not even be present on some types of links. After a TRILL frame coming into an RBridge passes a few basic checks, further processing depends only on the TRILL Header and information after the TRILL Header, not on the outer envelope information. Separate the IPv4 and IPv6 router attachment bits. It was suggested to add a bit to say "I'm interested in non-IP-derived multicast", with default on, that is "give me all of it". This bit wouldn't apply to the broadcast address. This met with general agreement. ** New Consensus to be confirmed on mailing list: Add a third per RBridge per VLAN bit which indicates that that RBridge wants non-IP derived multicast. Defaults to on but can be configured off. It was suggested that there should be less specific text about IGMP and MLD snooping. Just refer to the IGMP/MLD snooping RFC. Draft -05 has 4 values for the V field. For multi-destination frames, these indicates which of the three possible prunings should be applied to the distribution tree or that the frame had not been fully analyzed so no pruning beyond VLAN was possible without deeper analysis. The purpose of these bits is to encode the results of deeper frame analysis so that subsequent RBridges will have less work to do. All but one speaker opposed these V field provisions. ** New Consensus to be confirmed on mailing list: Elminate different V field values and revert to two version bits and two reserved bits with previous provisions that this draft specifies version zero, frames with an unknown version are discarded, reserved bits MUST be zero and are ignored on receipt. Meeting recessed until its Thursday session. ************* TRILL 09:00-11:30, Thursday, July 25, 2007, Crystal Room Minutes taken by Radia Perlman, augmented and edited by co-chairs Erik Nordmark and Donald Eastlake 3rd ************* Radia Perlman gave a slide presentation entitled "TRILL End Station learning" There are two ways to learn remote end station addresses: 1. Advertise - only DRB in VLAN A does the advertisement. It decides when to time out and withdraws the advertisement. 2. Learning while decapsulating. The DRB decapsulates, looks at ingress Rbridge and inner SA. The decapsulator decides when to time out the information. Gets updates from new frame's ingress/SA. IS-IS advertisements take bandwidth but cut down on flooding. If there are L2 end station enrollment/registration protocols, then sending via IS-IS with IS-IS security is more secure in a heterogeneous campus where forged encapsulated data messages could be inserted or the like. Some router implementations find it hard to learn from data plane as required if you learn from decapsulation. Learning from data is a MUST. It is optional to implement transmission of per-VLAN LSAs. It is optional to process per-VLAN LSAs on receipt. Discussion about threat model. MAY implement IS-IS VLAN instance. But even if implemented, it wouldn't originate LSAs unless enabled. The possibility of an "I don't want to learn remote end station addresses via IS-IS" bit was discussed. If all the RBridges who were DRBs for a VLAN had the bit on, then an RBridge that would otherwise communicate such information by per VLAN IS-IS instance messages would know not to bother for that VLAN. Most people spoke against adding this bit. There was a lengthy discussion of timers for remembering ingress and egress MAC addresses, ARP caches, etc. It was suggested that timer values for MAC addresses should be larger than the ARP cache timer to avoid periodic flooding. but then pointed out that ARP cache timers are reset by use so if there is continuing traffic being sent, ARP cache entries never time out. It was suggested that egress RBridges should remember a remote address longer than ingress RBridges remember a local address. It was suggested that we don't need to worry about timers at all. People were reminded to consider ND and IPv6. Eventually, the consensus was as follows: ** New Consensus to be confirmed on mailing list: MAC address remembering timers in TRILL should have the same configuration limits and default as in 802.1Q. The topic of an egress RBridge handling of unknown inner destination MAC addresses was discussed. Because distribution tree pruning is optional (currently a SHOULD), receipt of frames which should have been pruning is not an error and they are just discarded. It is not so clear for unicast. There are several things an egress RBridge could do with a known unicast frame sent to a destination MAC address it doesn't know. The possibility of sending an error message back to the ingress RBridge was discussed. It would cause the ingress RBridge to discard learned information. However, most of those who spoke were against defining such an error message at this time and suggested it be put off and considered later. The following consensus was reached: ** New Consensus to be confirmed on mailing list: Egress RBridges that receive a known unicast TRILL data frame whose inner destination address is not known locally should send the native form of the frame out on every link for which the RBridge is DRB for the frame's VLAN unless it knows that an end station with that MAC address could not be on that link. (For example, there is a layer-2 registration procedure for end stations on that link and the destination MAC address in question is not registered.) This is a local decision. No "error" message will be defined for this condition at this time. ************* Radia Perlman gave a slide presentation entitled "Scaling of pseudo-nodes" Issue is that a bridged LAN that is partitioned for some VLANs and connected for some other ones. So, in some sense you need a different DRB election for each VLAN tag Treating each different VLAN through a port as a different port can lead to having 4000 pseudo-nodes. However, the DRB can just advertise a single pseudo-node. There is already logic in IS-IS so that if two nodes appear to both be adjacent to the pseudo-node but do not see each other as adjacent, they know to send via the DRB. The possibility of dispensing entirely with pseudo-nodes was mentioned but there was opposition on the grounds that this would unacceptably increase the amount of Dijkstra calculations. ** New Consensus to be confirmed on mailing list: Each RBridge which is DRB for one or more VLANs out one physical port should announce only one pseudo-node for the port. What VLANs a Hello applies to should be noted in the Hello. Could just be a bit map. Core IS-IS instance pseudo-nodes should indicate the root bridge seen by the DRB and list the VLANs they apply to. Ques: Should advertise root bridge be optional or mandatory? It was noted that it is pretty easy to extract the root bridge ID from BPDUs received for the various versions of spanning tree. ** New Consensus to be confirmed on mailing list: It is mandatory for an RBridge to announce the bridge root that it sees out each physical port. One suggestion was (1) on an "access port" (a port with end stations and no other RBridges), send one Hello per VLAN, and (2) on a trunk port (a port with just RBridges and no end stations connected to it), send one Hello and assume consistent connectivity. Ques: Should we check that trunk ports don't connect to access ports? Comment: trunk port above means "direct RB to RB connection", that is "core port", Ques: What about point-to-point links between RBridges? ** New Consensus to be confirmed on mailing list: If it is known that a link is a point to point link between two RBridges, then the outer header, if it is an Ethernet header, can have any source and/or destination addresses, those addresses will be ignored on receipt, and the outer VLAN tag can be omitted. There was some discussion of how you would determine that a link, especially an Ethernet link, was point-to-point. It was noted that you could do this automatically with 802.1AB. 802.1AB is the Local Link Discovery Protocol (LLDP). It uses a multicast address in the block of 16 bridging multicast addresses that all 802.1 bridges will not forward. Therefore, if two RBridges can see each other's 802.1AB frames, they know there are no intervening 802.1 bridges. Comment: RBridges take a global view of the campus and will interconnect all the links in a particular VLAN even if they are replacing bridges that had been configured to maintain separated islands for that VLAN. If it is desired to avoid this, it might be necessary to increase the size of the VLAN ID or add some other qualifier to indicate what is supposed to be separate. Some people were surprised by this and indicated they wanted to think about it some more. At a minimum, the protocol document should make note of this campus wide VLAN connectivity effect. ******** Slide presentation by Donald Eastlake 3rd entitled: "Base Protocol Document: Possible -05 to -06 Changes" Next version of protocol draft with have updated pseudo code. Proposed to eliminate the TRILL Header M bit because it in redundant in protocol draft -05. However, this is a moot point since we had consensus to remove V != 0 and thus M is necessary. Proposed to change the inner VLAN tag from Q-tag to S-tag because the S-tag is more expressive and provides the Drop Eligible Indication (DEI) bit. Ques: What if there is already a Q-tag in the native frame? Ans: So what? The bit corresponding to the DEI bit in a Q-tag (now officially called a C-tag) is the cannonical format indicator (CFI) bit which, for 802.3, must always be zero. Frames that arrive on an 802.3 interface with a non-zero CFI are discarded. So you can convert a Q-tag to an S-tag without loss of information other than what kind of tag it was and, in any case, what kind of tag is used on the output frame at bridge egress is determined by the egress rule configuration, not by what kind of tag was on the ingressed frame. Several people spoke strongly in favor of the change to an S-tag. Comment: Want to be able to preserve Q-tag so frame can just be copied. Answer: But IEEE processing describes VLAN ID (and priority) as meta-data that is synthesized or extracted from the frame on ingress to a bridge and possibly reinserted into the frame on the output port depending on the bridge egress rules that have been configured. The 802.1 model is that there is no "Q-tag" or the like in the frame while the frame transits the bridge. Inside an 802.1Q bridge, the Q-tag data is meta data associated with but not part of the frame. There being no agreement on this, it was decided to take it to the list for discussion. Proposal to reduce the default number of trees by adopting a simple rule (an example was given) that would by default dynamically clear the RequestTree flag for some RBridges. Two speakers were sympathetic to the goal, but suggested this could be done more simply by selecting 1 or 2 RBridges as the only distribution tree roots in the default case. Proposal to define the format of "error" messages now and specify actual messages later. ******** Silvano presented without slides. Proposed to split out the frame format / encapsulation into a separate document that could be working group last called first. Would be designed to include all the specification necessary to make silicon; essentially the data plan behavior. There were a number of impassioned speeches for and against this idea. Our area director, Mark Townsley indicated the IESG would probably be OK with this if the Working Group is sure that is what it wants. A majority of the WG seemed to favor this split but there was not a clear consensus. ******** Donald Eastlake 3rd gave a slide presentation entitled "Additional TRILL Work/Documents" Because time remaining in the session was short, this presentation was given quickly with little time for questions. This was a presentation concerning additional documents that may need to be done or issues that might need mention in or modification of existing documents, from the near term to things much further out. It was also an appeal for people who would like to work on such documents. Sooner or later we will need something on management, presumably an RBridge MIB some of which would be specific to RBridges but which might also include existing bridge and IS-IS MIBs with minor modifications. The Base Protocol document says there will be another document giving details on TRILL Header options. Such an options document should probably also include at least a few specific options. ARP/ND optimizations were originally included in the Base Protocol document. The WG consensus which removed them also indicated they should be put into a separate document. Consideration could be given to specifying "Provider RBridges" whose relationship to the currently specified RBridges would be similar to the relationship between "Provider Bridges" and "Customer Bridges". See 802.1ad. Do RBridges need modification to work with 802.1ag, Connectivity Fault Management? How important is 802.1ag? 802.1ag is pretty close to final in the 802.1 standards process. One person said it was not too important for customer premises equipment but quite important for carriers. It is anticipated that RBridges will need extension to handle 802.1au, Congestion Management. This has been discussed extensively on the WG mailing list. However, 802.1au has been proceeding slowly in the 802.1 standard process. It has been stuck at draft D0.01 for a while but a draft D0.02 of 802.1au has just been authorized. At least in the case where a backward congestion notification message is generated by a TRILL data frame at an 802.1 bridge, RBridges will need to know how to reflect this back to the native frame source. ******** Adjourn