Hi,

I have been selected as the Routing Directorate QA reviewer for this draft.

Document: draft-ietf-trill-multi-topology-01
Reviewer: Martin Vigoureux
Review Date: May 20, 2016
Intended Status: Proposed Standard



The draft is both quite well written and well structured such that I did 


not have to go back and forth in the doc.



As a result also, I have only very few editorial comments and questions.

Section 1
   If routers in the network do not agree on the topology
   classification of packets or links, persistent routing loops can
   occur.
It is not clear if that could happen in mt-trill or if mt-trill solves that.



Section 1.1 goes beyond defining acronyms but specifies some pieces of 


technology:



   By implication, an "FGL TRILL switch" does not support MT.
   An MT TRILL switch MUST support FGL in the sense that it MUST be FGL
   safe [RFC7172].


Is this the right place to do this? By the way, this requirement is 


stated further down in the doc.




Section 2.2
s/and received/and receive/

Section 2.4
   Commonly, the topology of a TRILL Data packet is commonly
One superfluous occurrence of "commonly"

Section 2.4.1
It would be better to write "2/3" as "2 and 3"

   A TRILL switch advertising in a Hello on Port P support for topology
   T but not advertising in those Hellos that it requires explicit
   topology labeling is assumed to have the ability and configuration to
   correctly classify TRILL Data packets into topology T by examination
   of those TRILL Data packets and/or by using the fact that they are
   arriving at port P.
Does this mean that Value 1 is default behaviour?

Section 3.4.1
s/are determine/are determined/

Section 7
s/some links was more/some links were more/