Last Call Review of draft-ietf-trill-pseudonode-nickname-05
review-ietf-trill-pseudonode-nickname-05-secdir-lc-wallace-2015-09-17-00

I have reviewed this document as part of the security directorate’s
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

This document describes use of pseudo-nicknames for RBridges in an
Active-Active Edge RBridge group. I am not familiar with TRILL but found
the document to be well written and easy to follow. I did have one
question, which may just be due to my lack of familiarity with relevant
normative specs. The second paragraph of section 8 states the following:

	"However, for multi-destination TRILL Data packets, since they can reach
all member RBridges of the new RBv and be egressed to CE1 by either RB2 or
RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the
packet's Inner.Label maps to in the new RBv), special actions to protect
against downlink failure for such multi-destination packets is not
needed."	 

Why is there no race condition between the arrival of multi—destination
traffic and the creation of a new RBv following the failure of RB1 that
enables the traffic to be forwarded? Generally, mentioning failure of the
DF for the virtual RBridge seemed like it might warrant mention in the
security considerations section, since that is new relative to the specs
noted in the current security considerations.