Last Call Review of draft-ietf-trill-tree-selection-04

Request Review of draft-ietf-trill-tree-selection
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-07-01
Requested 2016-06-20
Authors Li Yizhou, Donald Eastlake, Hao Weiguo, Hao Chen, Somnath Chatterjee
Draft last updated 2016-06-28
Completed reviews Genart Last Call review of -04 by Robert Sparks (diff)
Secdir Last Call review of -04 by Leif Johansson (diff)
Opsdir Last Call review of -04 by Linda Dunbar (diff)
Rtgdir Early review of -02 by Daniele Ceccarelli (diff)
Assignment Reviewer Robert Sparks 
State Completed
Review review-ietf-trill-tree-selection-04-genart-lc-sparks-2016-06-28
Reviewed rev. 04 (document currently at 05)
Review result Ready with Nits
Review completed: 2016-06-28


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-trill-tree-selection-04
Reviewer: Robert Sparks
Review Date: 28 Jun 2016
IETF LC End Date: 1 Jul 2016
IESG Telechat date: 7 Jul 2016

Summary: Ready (with nits) for publication as Proposed Standard

This document is easy to read, even for someone not deeply steeped in trill.

I have a few questions and suggestions to consider

1) The essence of the idea this document provides support for is that an 

operator will create and install a configuration that meets the one tree 

per identifiable thing (such as VLAN) constraint. The protocol proposed 

here does not try to enforce that the operator supplies a configuration 

meeting that constraint. Should the things that generate messages with 

the TLVs defined in this document be restricted from sending messages 

that would map the same VLAN to two trees? I understand things will 

still work (suboptimally, as pointed out in the backwards-compatibility 

section), but it seems this configuration error should be mitigated. 

Section 3.3 also pulls the punch a little with it's discussion at the 

end of the second paragraph. If you're going to leave it up to the 

unspecified way the operator installs this configuration, you might at 

least point out that this is something to look for and complain about. 

If you think the optimal configuration isn't a likely thing to reach, 

then consider a pass through the document that sets that expectation 


2) There are a couple of places where you use 2119 where you appear to 

be restating requirements from other documents. That's dangerous, from a 

document set maintenance point of view. Please consider changing these 

to simple prose, leaving the 2119 requirements to the protocol you're 

defining in this document. Please look at the SHOULD in the Background 

Description, and the SHOULD NOT in the first paragraph of the Overview. 

(2119 in sections like backgrounds and overviews is usually a sign that 

somethings in the wrong place.)

3) In the 3rd paragraph of 3.3, why is the requirement SHOULD strength? 

What else would the RBridge do, and when would it be reasonable for it 

to do that something else?

Nits/editorial comments:

* You use a lot of domain-specific acronyms in section 1 before saying 

what they mean in section 2.

* The first sentence in the 8th paragraph of 1.2 is very complex. (It's 

the one that starts "In cases where blocks of"). Please consider 

simplifying it.

* Section 2: (I'm no fun) Do you want this alternate expansion of FGL to 


* Figure 2: the left table has a VLAN of 4095, which is inconsistent 

with the prose.

* In section 3.4 you use 2119 RECOMMENDED (which is equivalent to 

SHOULD) when describing how the operator configures things. This isn't a 

constraint on the protocol defined in this document. Please consider 

rewriting the sentence without the 2119 keyword.

* Micronits: there's spurious space at the beginning of the 3rd line on 

page 6. There's an occurrence of BRridge that probably should have been 

RBridge in section 3.4, and "assigne" appears in the IANA Considerations.