TRILL Working group minutes Philadelphia IETF 71 Monday 9:00 AM Scribe Matthew Thomas Minutes edited by Co-Chairs Donald Eastlake 3rd and Erik Nordmark Working Group's Area Director: Mark Townsley Matthew Thomas volunteered to take minutes. Suggestion by Silvano Gai to add a slide at the end of the 07->08 presentation. Questions about Jabber: No-one seem to be online. There were no changes to the agenda apart from Silvano's short presentation. [Later during the meeting a short FYI presentation about pseudo-node reduction was added to the agenda.] Chair talks about the progress of the 3 main documents and getting them submitted. Chair also states that the Milestones seemed to be a little aggressive in the past. Are there other documents that we should add to the plate? ===== TRILL: Problem and Applicability Statement draft-ietf-trill-prob-02.txt Joe Touch presents: Joe Touch: No one had spoken up on issues and questions that were pointed out in this draft so I assumed they could be left out or answered no. Unless there are objections I'll leave those issues out. There is mention in the draft about historical summaries of lack of discussion. Joe just sees minor text edits. His goal is to "get it out and wrap it up ASAP" Questions or Comments? Seems to be none. Q. Did anyone read the document? A. Seems to be very few. Donald Eastlake: I posted some high level comments to the mailing list and will send text. Joe said he would send the source file to Donald. ====== Trill Architecture Update - Eric Gray draft-ietf-trill-rbridge-arch-04.txt Eric presents a "really small update, based on feedback". Comment "architecture had no business saying DRB election" The first part of this is the term DRB and the second part is the election. The updated document also assumes we are using IS-IS. This folds the key parts of the routing requirements document into the architecture document. Introduction on Page 6 "- adding what I thought was being said in the minutes of last meeting -" Handling the Shared media "This can give some issues". Eric states that non-optimal routing was out of the scope of the document. Eric is staying clear of the term "DRB Election". More interested in primary point of (end station) attachment. Trying to optimize the possible looping due to designated Rbridge. You can never completely fix this but it could be optimized. Talking about ensuring not having the same source address in the packets coming from differing stations. Pathological forwarding. End station discovery and flooding could be intentionally disabled on a port. Pseudonode optimization mentioned so that people didn't think that he forgot. Auto mechanism? Or not automated? Needed for resilience. Summary of architecture document changes: Removing DRB term. Extensive changes marke din a PDF that is available for download. "All changes were listed in an e-mail message that was sent out." I think that the issues were addressed from comment from James Carlson. Chair: How many people have read the Architecture Document? 3 people. Chair: Are we getting close? How can we get people to read it? Mark Townsley If you are having a hard time, then use the 5 reviewers rule. Get five named people who 'volunteer' to review. A WG last call that is complete silence is not useful. If your last call is silence, then it doesn't tell you a lot. If you have 5 people, OK. The following people volunteered to review the architecture document and either send comments or a "I read it and it is OK" to the mailing list: James Carlson Andrew Leigh Russ White Pekka Savola Bill Fenner Chair: Thank You. ====== Rbridges: Base Protocol Specification: Changes from -06 to -07 draft-ietf-trill-rbridge-protocol-07.txt Donald Eastlake Presents I will go over the changes between version 6 and 7 divided into categories of roughly increasing potential controversy: Editorial Changes: + Fix some places with hop count off by one; that is, they said you can't forward a frame with a hop count of one when the criterion should be a hop count of zero. + Replace remaining Q-tag references with C-tag Radia Perlman: Can you explain the meaning of the Q-tag changes for those new to the group? Donald Eastlake: The tag is used to give VLAN ID and priority (actually PCP: priority code point). It used to be called Q-tag but has now be re-named C-tag in IEEE 802.1Q for Customer Tag. It's just a change in name. + Add a few frame type definitions (Section 1.2) and a list of acronyms (new Section 10). + Re-order some sub-sections. + Make figure numbers section relative and add table numbers. [There were no objections to the "Editorial Changes" except for the objection below by Eric Gray to the replacement of Q-tag by C-tag which he withdrew after the meeting.] Consensus Changes from the Vancouver meeting: + Remove Pseudo-node suppression material [Reverting to the tag name discussion above] Eric Gray: With discussion of C tag renaming with Q tag, this relates to 802.1Q and PBB [Provider Backbone Bridging]. Donald Eastlake: Well? Eric Gray: I suspect you will get heat if you refer to second level encapsulation as a C tag. Donald Eastlake: It is just a renaming. In terms of editorial change then this is not that relevant. You have to say something specific in a standard. The inner tag is only ever seen by TRILL aware devices. Eric Gray: I think that the issue in using Q tag, we were using an abbreviation, and we adopted it. We need to look at what we mean, Radia Perlman: Let me translate and you can correct me... There was an obscure bit they changed the meaning of and they changed the protocol type [Ethertype]? Answer: No, same protocol type. Radia Perlman: Oh, great, so here you are only talking about an editorial change, but if bridges have to understand both then, it depends on the capabilities. Do Rbridges have to understand both? Answer: No, RBridges are customer devices. They don't need to understand S-tags (Service Tags), just C-tags (Customer Tags) which were formerly called Q-tags. Radia Perlman: OK. Punito: So the protocol doesn't matter? Donald Eastlake: Yes, it does. If you want to be able to handled S-tags, you need to at least write a document on how such would differ. Let's do a different document with S-Tags later and call it Provider RBridges. Punito repeat: Does it matter whether we try to handle S-tags? Donald Eastlake: Yes it does. Difference in the tags is small, but it matters. Chair: In IS-IS it matters too. ... more discussion of S-tags and C-tags... Eric Gray: Back to you [addressing Donald] and Radia. Just because it is a global replace does not make it editorial. A global search and replace of AND with NOT isn't an editorial change, Mark Townsley: RAT HOLE. Eric Gray: There is no point in saying C-tag. Donald Eastlake: S-Tags are not and never were mentioned anywhere in the specification. The specification has to be specific enough that people can implement it interoperably. We have to say what the Ethertype of the VLAN tag we are using is. Mark Townsley: Agreed and one of the points is to not have to configure everything. Silvano Gai: I highly recommend we stick with this change [replace Q-tag with C-tag] and accept it! Anoop Ghanwani: Agreed. There is more to supporting S-tag than we have in the specification. ************ Tentative consensus: The TRILL Base Protocol draft should only mention and use C-tags. It should not mention or use S-tags, except possibly to distinguish them from C-tags and to state that they are not used. [Donald then reverts to other changes coming from consensus established at Vancouver/Chicago.] + Add ability to configure a port to drop native frames and not send native frames (i.e., no end station support). + Permit Rbridges to implement GVRP/MVRP. + Add note that difficulties in determining link speed when there are intervening boxes is not unique to Rbridges. + Drop recommendation to set "bridge" flags in some 802.1AB fields. (Actually a consensus from Chicago but accidentally omitted in version -06, fixed in current version -07.) [There were no objections to the "Consensus Changes from the Vancouver meeting" above.] Expansions of the Draft: + Add Section 4.8 giving a more detailed exposition of multipathing. + Add Section 2.5 comparing zero configuration 802.1D, 802.1Q, and Rbridges. + Added note to Security Considerations to use care when using VLANs for security. + Pseudo-Code (Section 5) has been partially updated. [There were no objections to the "Expansions of the Draft" above.] Technical Changes: + IEEE 802.1 VLAN registration protocols (either the older GVRP or newer MVRP) didn't work with version -06 of the draft. We added Section 4.7 which goes about 75% of the way to making MVRP (Multiple VLAN Registration Protocol, 802.1ak-2007) work so that Rbridges can incrementally replace 802.1Q customer bridges where either the replaced or remaining bridges have ports with dynamically registered VLANs. Donald Eastlake: This is important for incremental deployment if you have any dynamic VLANs. If the purpose of a frame is to turn on a VLAN, then you can't restrict that frame's distribution to a particular VLAN. Also the 802.1Q standard prohibits VLAN registration frames from being VLAN tagged. Chair: -some question on more information- Donald Eastlake: The zero configuration state of an RBridge port is for VLAN 1 to be fixed enabled with the recommended default for all other VLANS to be dynamic but initially disabled. You can configure a port on an Rbridge to always send MVRP, never send MVRP, or to send MVRP if it sees a bridge out the port. The last is the default. Donald Eastlake: Any questions on this? [There were no questions on or objections to the "Technical Change" above.] + Options: Donald Eastlake: The -07 draft has critical summary bits in the options area if that area is non-zero in length. These indicate whether there are any hop-by-hop or ingress-to-egress critical options present in the frame. There is a separate draft which provides a more complete syntax and example specific options that will be discussed in a later presentation this meeting. This other draft is set up so that its description of the options area could be substituted for that in draft -07. The issue of options was discussed on the mailing list without a really clear consensus. The separate option draft and the -07 protocol draft present two alternatives for discussion. Any questions? [There were no questions.] ===== Silvano Gai: Can we discuss the paragraph I mentioned at the beginning here now? Chairs: Sure. Silvano now presents his page with the text from the document that he doesn't think is clear. [This was later posted to the mailing list at http://www.postel.org/pipermail/rbridge/2008-March/002898.html] Silvano Gai: We should agree that this isn't very clear in the current draft. We are proposing some text here. Text showed on the projector. Silvano talks about an announcing set. "There are three cases..." Technical explanation follows of the three cases. Silvano Gai: I don't care what the VLAN used for inter-RBridge communication on a port is called. Donald Eastlake: Version -07 of the document uses "Designated VLAN" fairly consistently. Silvano Gai: Fine. Eric Gray: I am concerned about implications that this may have on IS-IS instances. Maybe this has an implication on IS-IS implementations. Silvano Gai: Well we didn't change anything, just made the wording more precise. Eric Gray: I am just saying consider that aspect of it. Erik Nordmark: Does it detect when two ports from an RBridge are connected to the same link? Dave Ward: Yes. Erik Nordmark: Would IS-IS handle this situation sensibly? Dave Ward: Yes. Anoop asks questions about differences in Hellos send on different ports of an RBridge. Donald Eastlake: IS-IS Hellos for different ports on the same RBridge would be different. In general different DRBs, different port indications, etc. Dave Ward: The scenario is unclear as currently described. In fact when IS-IS is running out of different interfaces, the Hellos will look different. Things can work, whether or not it is described correctly as of now. Radia Perlman: If you have two ports onto the same link, so you see your own Hellos, then IS-IS notices this and only makes one port Designated?? Dave Ward: Yes. Radia Perlman: Good! Silvano Gai: Good. We will post text to the mailing list. ===== Rbridges: Base Protocol Specification: Changes from -07 to -08 draft-ietf-trill-rbridge-protocol-07.txt Donald Eastlake Presents + Finish incorporating workable support for MVRP. People should check out Section 4.7. + Add description of contents of IS-IS Hello. + Add section summarizing assumptions for bridged LAN configurations. + Pseudo code improvements, primarily in completeness. [There were no objections to the above suggested completions of parts of the base protocol draft.] + Options. Some decision needs to be made at some time about what goes into the next document with respect to options. Silvano Gai: We can add the VLAN ID to Hellos to check for VLAN mapping at the same time that we look at the Hellos for other things. Donald Eastlake: Sure. Pro and cons for options bits. There is a personal draft (Draft-eastlake-trill-rbrige-options-00.txt) for the syntax and organization of options. It includes specification on a number of specific options and additional options, such as an ECN option, have been suggested on mailing list. We need to choose how much detail on options will be in the next version of the draft. Donald Eastlake: There doesn't need to be complete consensus, but we need to decide to do one of 1- Have nothing in the draft about the contents of the options area. But then when we add first critical option we need to bump the version number of the whole protocol. 2- Having critical summary bits present as in current draft. 3- Replace Section 3.5 of base protocol draft with Section 2 of the options draft giving detailed syntax. 4- Leave in critical summary bits and also add Section 2 of the options draft. Eric Gray: Could I still interact with previous version without supporting critical options? Donald Eastlake: Sure, this is what we have right now. But you would have to discard frames you received with such options, etc. Silvano Gai: I am NOT a fan of parsing 128 bytes of options. This is not an option. I like the top right box (#2). I am against moving from what the current base protocol says (version -07) to anything more. Radia Perlman: I think that what is in the current draft is a reasonable compromise. Of the two extremes, this is in the middle so ... Donald Eastlake: Yes agreed. Is anyone opposed to this? No. Well, this is pretty likely then. I will place a question on the list ************ Tentative Consensus: Leave the provisions in the base protocol (version 07) draft for critical summary bits if the options area has non-zero length and leave further details about options to another document or documents. Moving on and summary: So after producing a version -08, the tentative plan is to run a Working Group last call, 802.1 review, and IETF expert review in parallel. Eric Gray: A Question of clarification on one of the slides: There will be a section on bridge configuration assumptions. Can you put the assumptions that you are planning to use for the document out on the list before including them? Donald Eastlake: That's an excellent idea. (Gives an example of an assumption.) Silvano Gai: Can you include the pseudocode so that we do not need to check the pseudocode against the text? That would save us a LOT of time. Silvano Gai: Is the pseudocode normative? Donald Eastlake: Yes, the document says that where the text and pseudocode differ, the pseudocode is normative. Silvano Gai: ???? Are you sure??? Can we dump the document?? [Room laughs.] Donald Eastlake: Well, in previous reviews the pseudocode has been normative. Dave Ward: That is a terrible idea. Make the text normative! Donald Eastlake: In early versions of the specification, the text was pretty vague in some areas and didn't cover the corner cases. I learned a lot working on the pseudocode because it forced me to think about those corner cases. But I admit that the text is much better now. Dave Ward: So, can you write bug free code? Donald Eastlake: Once in my life I wrote a non-trivial bug free program. Mark Townsley: Make the text normative. We will not be setting a precedent in this group! Writing code helps as a tool to go back and fix your English text. We will recruit people to review the document from L2VPN, etc. People who are not active in this particular group. Radia Perlman: Why is it easier to write text accurately and not pseudocode? ************ Tentative Consensus: Change the base protocol draft so that where the pseudocode and text conflict, the text is normative. ===== Radia presents "TRILL things" Discussion on IS-IS Hellos and which VLANs to send them on: Radia Perlman: If you ignore a bridge, this is worse than ignoring a router (due to loops, no TTL, etc.). The safest thing is to send Hellos on all VLANs, but then there is a scalability issue. Option "Rbridges will only send and receive on VLAN 1 and send on single designated VLAN." but this is not always safe if there are partitioned VLANs. Discussion about Designated VLAN-x forwarder: Radia Perlman: Two bridges that have not heard from each other, both appoint a VLAN-x forwarder for a link. This can lead to a loop. So if you are forwarding, then it would be safer to send Hellos anyway. Radia Perlman: VLAN translation would also be bad, especially with multicast packets. If you detect this, you tell the DRB which makes sure there is only an appointed forward for one of the VLANs which are being mapped into each other. This can be detected by putting the outer VLAN tag inside the Hello body in some TLV and checking on receipt if they still agree. Radia Perlman: But you can configure an RBridge to not send Hellos on VLANs for which it is appointed forwarder. (The above is the proposal). In order to defend against the mapped VLAN frame, we need to add to the text of the Hello possibly something like "warning VLAN-x and VLAN-y map to each other." Defense against merging L2 clouds. When this happens, there will likely be loops for a while till things settle. To detect this quickly, you notice when the root bridge changes. If that happens, you wait 30 seconds (configurable to be less, down to zero) before encapsulating / decapsulating native frames on that port. Dave Ward: Connection verification sounds like the Camel's nose in tent for OAM facilities. [OAM = Operations and Management] Eric Gray: "IEEE says you will be on your own." Radia Perlman: So we will not attempt to defend against loops?? Eric Gray: (some comment missed by the scribe) Donald Eastlake: No. Eric Gray: I agree with the Camel's nose comment. You will go down a path that will involve ever growing complexity. Radia Perlman: What's a Camel's nose? We are not proposing the marriage of your daughter. [Room laughs.] Donald Eastlake: We are not taking this sort of checking further, but we need to detect loops. Dave Ward: I am just saying think about it. Radia Perlman: We need to avoid loops or we are dead. A Layer 2 loop usually makes your network melt down. Silvano Gai: I am very sympathetic with what Donald says. We need to find a balance in the middle. Erik Nordmark: This might be overkill here. We might need to map equivalence sets here. Lets just say that if they map VLANs or do other crazy things, then it isn't possible to provide any service to those VLANs on that link. Radia Perlman: Hmmm. OK. Erik Nordmark: Can the receiver do something locally that makes this happen? Radia Perlman: It seems safer to let the Designated Rbridge to sort it out. It would be nice to alert the designated Rbridge when VLAN mapping is detected. We are not proposing to do this for other things. Eric Gray: It can't be a local message. ALL: General disagreement... Radia Perlman: We want to be defensive in loop detection. Erik Nordmark: Maybe we should take this to the list. Silvano Gai: By default, if you detect problems, you should isolate! Anoop Ghanwani: Provider bridges do bit translation, so the bridge doing the translating would need to snoop all the frames to translate this VLAN ID copy inside the Hello. Donald Eastlake: A provider or provider backbone bridge will generally be TRILL ignorant and won't look into the field. Anoop Ghanwani: I am worried that there will be no action that works. Erik Nordmark: Just turning off service for the VLAN is good enough. Silvano Gai: Per port? On slide 2? Is the set VLAN 1 for Hellos? OK. Comments from many about defaults to understand slide. Eric Gray: Comments about: "per port" notation. Silvano Gai: Discussion about active port. Radia Perlman: We agree and I didn't mean anything silly. [The document will make it clear that all the VLAN discussions are per port of the RBridge.] ************ Tentative consensus: Default and configurable VLANs on which Hellos are transmitted as described by Radia above, i.e., as in Radia's slides. ************ Tentative consensus: The Outer VLAN ID will be duplicated in a TLV inside TRILL IS-IS Hellos to detect VLAN mapping. Further discussion on the list is needed as to what to do about mapped VLANs when that conditions is detected. Radia raises another issue: Getting Rid of the decapsulation check. Radia Perlman: RBridges report the root bridges they see (if any) per VLAN. Then, before decapsulating data onto a link from ingress RBi, they check to see if RBi is seeing the same root bridge for the frame's VLAN. If so, they don't decapsulate. This is painful to check in the data path so the question is can we remove it? (A suggestion by Dinesh.) Eric Gray: I support all of those points. But it seems reasonable to allow a bridge to do this check if it wants to. Getting rid of this is a tough choice. Radia Perlman: Right. This does increase safety. Well, the least controversial thing might be to change it to a MAY. Anoop clarifies that you can't do the check unless all RBridges report this information. Radia Perlman: OK keep a MUST for reporting, and change to a MAY for checking it. Anoop Ghanwani: This ties into the Hello problem. If fewer Hellos are being sent, this check is more important. This needs some thinking about... Silvano Gai: 4000 VLANs? Matthew Thomas: Worst case. Anoop Ghanwani: I think that this should be a MUST but I would like to think about it. Eric Gray: You could configure this. Silvano Gai: Some prefer control plane complexity, and some prefer a complex data plane. Either data plane robust, or control plane robust. Group all murmur agreement. Mark Townsley: Which is the default? Chair "make suggestion in draft" Anoop Ghanwani: To clarify my point... You can't suppress because that is the feature. Eric Gray: ...clarification on his point... Russ: ...there is customer responsibility of course... Russ: ...report but not fix. Lets make this a 'deterministic' failure... Donald Eastlake: We generally do just enough extra to actually prevent loops. Radia Perlman: ...nothing permanent but you do something... ************ Tentative consensus: to keep the reporting by RBridges of root bridge IDs observed mandatory, as in the current draft, but make the "decapsulation" check optional. Radia Perlman: Commented on moving the VLAN tag into TRILL header. Liked protocol encapsulation that Don had suggested on the mailing list. Eric Gray: Oh heck no. Without objection the chairs rescheduled the "Pseudonode Reduction" presentation for directly after "TRILL use of IS-IS" presentation. ===== Donald presents TRILL use of IS-IS Details from power point about interaction between IS-IS and TRILL. Proposes to post a revision of this personal draft (Draft-eastlake-trill-rbridge-isis-00.txt) updated to correspond to base protocol draft and feedback and move this into a working group document if there is consensus. Eric Gray: I personally support this. Does this happen here or the IS-IS working group? Erik Nordmark: This working group can make sure that all of the information needed by TRILL is there. Dave Ward: So you write it here but take to IS-IS to standardize? Erik Nordmark: Yes. TRILL makes sure it has all the needed information and then we give it to IS-IS. Eric Gray: IS-IS for decision and TRILL for information. Dave Ward: Are you bringing in pseudonode reduction into this document? Donald Eastlake: That's not the plan. The TRILL working group decided to remove pseudonode reduction from the base protocol specification and move it to "a document closer to IS-IS" but it is not completely clear what document that is. Dave Ward: OK. Matthew will be presenting pseudonode reduction later in the week for IS-IS. By the way we are not having IS-IS accept this as a working group document this time around. ===== Matthew presents Pseudo-node reduction Dave Ward: Quantify the benefit before for IS-IS. Suggests a small group of TRILL plus IS-IS folks get together during the week do discuss this. ===== Donald briefly presents Future TRILL Work These are mostly potential future additional documents. + RBridge MIB + IP related optimizations (ARP etc). 802.1 Features: + Provider RBridges (802.1ad-2005) + Connectivity Fault Management (802.1ag) Data Center Bridging 802.1 Features: + Congestion Notification (802.1au) + Enhanced Transmission Selection (802.1ax) (Related to per priority pause which will permit pausing and unpausing the queues for different priorities of traffic.) End of the session.