Re: [secdir] draft-ietf-trill-pseudonode-nickname-06

[Mingui Zhang <[e-mail]>]

Hi Carl,

Thanks for the comment.

If the DF fails, the failure will be noted by other member RBridge through LSDB sync. Then the DF election algorithm defined in Section 5.2 will be locally used to determine who is the new DF. 
In the transient condition when LSDB has not been sync-ed, there might be packet lost but there is no racing: suppose, RB1 is the old DF before the failure while RB2 is the new DF after RB1 fails according to the election algorithm. If RB2 has been sync-ed while RB3 is not, then RB2 will begin to do forwarding; If RB3 is sync-ed while RB2 is not, then no member RBridge will do the forwarding. 

Thanks,
Mingui

> -----Original Message-----
> From: Carl Wallace [mailto:[e-mail]]
> Sent: Sunday, September 13, 2015 4:00 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: draft-ietf-trill-pseudonode-nickname-06
> 
> 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.
>