Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic
draft-ietf-trill-centralized-replication-13

Thanks to Alia for helping me understand TRILL scaling for this sort of thing - balloting NoObj in response.

TRILL is pretty far outside my area of expertise, so I might be simply misunderstanding the protocol extension model here, but it seems to me that the changes to the RPF port calculation represent a formal update to RFC6325. If so, the metadata and abstract should indicate that.

I have some non-blocking comments.  I would like to see the ones related to Normative Language addressed before publication.

- From the Abstract: "RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge..."  Using Normative Language in the Abstract seems strange to me, specially since the same language is not used later in the text.  The document does get to the same point later, but not with the same language.

- The Introduction says that "...a centralized node, which SHOULD be a distribution tree root", but Section 3 says otherwise: "The centralized node MUST be a distribution tree root."  Suggestion: use Normative Language in just one place.  IMO, the Introduction may not be the right place for it.  

- BTW, what is a "distribution tree root"?  The definition is probably intuitive since we're talking about replication, but explicitly defining it would clear any possible confusion.

- I appreciate the background and the description of the problem and the mechanism, but there's a lot of repetition.  Section 3 presents for the third time an overview of the mechanism -- Abstract, Introduction, and Section 3...note that even the last paragraph repeats information about the replication from this same section.

- Section 9: "An edge group using CMT [RFC7783] MUST NOT set the C-nickname flag on the pseudo-nickname it is using. This is already mandatory behavior..." If "already mandatory" then there's no need to use Normative Language here, right?

- Section 11.1 ("R" and "C" Flag in the Nickname Flags APPsub-TLV):  I'm not sure if I understand correctly, but because there's a distinction between the R-nickname and the C-nickname, both bits should not be set at the same time, right?  What happens if they are?  It seems that the last paragraph tries to address that question ("due to errors")...but I'm then not sure what the action is: "it is RECOMMENDED that the nickname be treated as if the R / C flag was set if any Nickname Flags APPsub-TLV for that nickname has the R / C flag set." Again, what if both are set?  And "RECOMMENDED" implies that there are reasons not to do it this way...what are those cases?

   if a triple of {ingress nickname, tree, receiving RBridge port} is
   allowed. (The tree is indicted by the nickname of its root which is
   stored in the TRILL Header "egress nickname" field.) When
I think this probably should be "indicated"



7. Centralized replication forwarding process
This diagram would be helpful earlier



                     *   ----------*-------------*--    ^
                     ***************************** |     ^
              LAALP1 *                      LAALP2 |      ^
What are the asterisks?



   equals (m mod k) as egress nickname for BUM traffic unicast TRILL
   encapsulation.
This text might be easier to read as:

"For data label ID m, choose R-nickname = m mod k"

The "equals" isn't that helpful here, but if you wanted to say it that way, you might try 
"choose the R-nickname n which is equal to m (mod k)"



            o C = If C flag is one, it indicates that the TRILL traffic
   with this nickname as an ingress nickname that requires the special
Nit: I would use ":" here instead of equals

Thanks for fixing the SHOULD/MUST in the intro per the SecDir review.

No TSV concerns from me, but I was interested in the MUST/SHOULD mismatch that Joseph Salowey mentioned in his review of -10. I didn't see a change about that in -11. 

I'm assuming the right thing will happen after the holidays, so no Discuss :-) ...