Last Call Review of draft-ietf-trill-pseudonode-nickname-05

Request Review of draft-ietf-trill-pseudonode-nickname
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-09-15
Requested 2015-08-20
Authors Hongjun Zhai, Tissa Senevirathne, Radia Perlman, Mingui Zhang, Li Yizhou
Draft last updated 2015-09-17
Completed reviews Genart Last Call review of -05 by Russ Housley (diff)
Genart Last Call review of -06 by Russ Housley (diff)
Secdir Last Call review of -05 by Carl Wallace (diff)
Opsdir Last Call review of -05 by Linda Dunbar (diff)
Rtgdir Early review of -05 by Russ White (diff)
Assignment Reviewer Carl Wallace 
State Completed
Review review-ietf-trill-pseudonode-nickname-05-secdir-lc-wallace-2015-09-17
Reviewed rev. 05 (document currently at 07)
Review result Has Nits
Review completed: 2015-09-17


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

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.