Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access
draft-ietf-trill-pseudonode-nickname-07

Agree with Spencer's first comment.

-- section 12, last paragraph:

Elaboration on the details would be useful. This draft adds new procedures; what analysis was done to show those new procedures have no new security impact?

Editorial:

-- 1.1, definition of AAE, "AAE is also referred to as edge group or Virtual RBridge in this document"
Why use multiple terms for the same thing? This seems to create awkward wording in several places, where the text  repeats things like “In an AAE group (i.e. RBv)…”

This was an easy document for me to read through (I have some exposure to TRILL but am not skilled in the art). Thank you for that.

I did have some questions, but nothing at Discuss level. 

In this text:

Introduction

   Other methods are possible; for example the
   specification in this document and the specification in [MultiAttach]
   could be simultaneously deployed for different AAE groups in the same
   campus. It is RECOMMENDED that only one method be adopted in a TRILL
                 ^^^^^^^^^^^
   campus. For example, if the method is [MultiAttach] is used, TRILL
   switches need to support the capability indicated by the Capability
   Flags APPsub-TLV as specified in Section 4.2 of [MultiAttach]. If the
   method defined in this document is adopted, TRILL switches need to
   support the Affinity sub-TLV defined in [RFC7176] and [CMT]. For a
   TRILL campus that deploys both AAE methods, TRILL switches are
   required to support both methods.
   
I'm not thinking that RECOMMENDED is an RFC 2119 RECOMMENDED, but more broadly, I THINK this paragraph is saying, "using multiple methods on a TRILL campus will work, but if you use multiple methods, all of the TRILL switches on the campus MUST support both methods". Did I get that right?

If so ... you might give some justification for adopting only one method (my guesses were capital expense? operating expense? complexity in troubleshooting?), and perhaps even some explanation why you might adopt more than one method (I was guessing that you'd use more than one because some of your equipment doesn't support the method you want to use, but if TRILL switches have to support both methods, that isn't the reason, is it?)

In this text:

3. Virtual RBridge and its Pseudo-nickname

   Since RBv is not a physical node and no TRILL frames are forwarded
   between its ports via an LAALP, pseudo-node LSP(s) MUST NOT be
   created for an RBv. RBv cannot act as a root when constructing
   distribution trees for multi-destination traffic and its pseudo-
   nickname is ignored when determining the distribution tree root for
   TRILL campus [CMT]. So the tree root priority of RBv's nickname MUST
   be set to 0, and this nickname SHOULD NOT be listed in the "s"
                                  ^^^^^^^^^^
   nicknames (see Section 2.5 of [RFC6325]) by the RBridge holding the
   highest priority tree root nickname.
   
what happens if this SHOULD NOT is ignored? Do things still work?

Thanks for addressing my discuss points.