Hi I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-trill-cmt-06 Reviewer: Stig Venaas Review Date: August 11, 2015 IETF LC End Date: Intended Status: Standards Track Summary: I have a couple of potentially major concerns and a few minor ones that I think should be resolved. Comments: The document is generally pretty good, but the sentences are a bit hard to read at times, and there may be a couple of technical issues. Major Issues: 1. The document talks about virtual RBridges. I cannot find any definition of what this means. Also the abstract talks about how virtual RBridges pose serious challenges for RPF checking, but it isn't explained later in the document. My knowledge of TRILL is somewhat limited. 2. The recovery algorithm discussed in 5.6 is just a guideline. What happens if different implementations choose different algorithms? They may not interoperate. Cannot this cause problems? Shouldn't it be more than just a guideline? Minor Issues: 1. I believe the abstract should not contain references. 2. In 1.1 it says: Specific methods in this document for making use of the Affinity sub-TLV are applicable where a virtual RBridge is used to represent multiple RBridges are connected to an edge CE through an LAALP such as multi-chassis link aggregation or some similar arrangement where the RBridges cannot see each other's Hellos. I have trouble parsing this. What are you trying to say? 3. Also in 1.1 it says: This document DOES NOT provide other required operational elements I don't think DOES NOT should be capitalized. Not in 2119. 4. In 4.1 sub-TLV which are resolved as specified in Section 5.3. In the absence of such an Affinity sub-TLV, or if there are any RBridges in the campus that are do not support Affinity sub-TLV, distribution ^^^ I think delete "are". 5. Also in 4.1 trees are calculated as specified in the section 4.5.1 of [RFC6325] as updated by [RFC7180]. Section 4.3. below specifies how to ^^^ I guess delete the period. identify RBridges that support Affinity sub-TLV capability. 6. In 4.2 we have Each edge RBridge RB1 to RBk advertises in its LSP virtual RBridge nickname RBv using the Nickname sub-TLV (6), [RFC7176], along with their regular nickname or nicknames. Wording/punctuation makes this hard to parse. 7. Also in 4.2 It will be possible for any RBridge to determine that RBv is a virtual RBridge because each RBridge (RB1 to RBk) this appears to be advertising that it is holding RBv is also advertising an Affinity sub-TLV asking that RBv be its child in one or more trees. Add some punctuation here? 8. In 5.4.1 fall back options, there are multiple lower case "should" that perhaps should be SHOULD? Stig