Early Review of draft-ietf-trill-cmt-06
review-ietf-trill-cmt-06-rtgdir-early-venaas-2015-08-12-00

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