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

[Carl Wallace <[e-mail]>]

On 9/13/15, 11:51 PM, "Mingui Zhang" <[e-mail]> wrote:

>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

Sorry, ‘race condition’ may not have been the best term to use here.

>: 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.

That there could be a lost packet (or traffic disruption as mentioned
elsewhere) was what I was getting at. The language in the first paragraph
of section 8 indicated unicast could have trouble but as I read it the
second paragraph intimated that multicast could not. It wasn’t clear to me
that was true and it sounds like it isn’t true for all cases (but is true
after a new DF has been elected).

Re-reading it now it is clear the point is that no ‘special actions’ are
required not that there can be no lost packet. It might be more clear if
it stated acknowledged the hang time between failure and full
establishment of the new RBv following the failure.



> 
>
>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.
>> 
>