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

[Mingui Zhang <[e-mail]>]

Hi Carl,

I agree that it is more clear if the transient condition is explicitly state in the text of paragraph 2. That will be done before it is published.

Thanks,
Mingui

> -----Original Message-----
> From: Carl Wallace [mailto:[e-mail]]
> Sent: Monday, September 14, 2015 6:19 PM
> To: Mingui Zhang; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: draft-ietf-trill-pseudonode-nickname-06
> 
> 
> 
> 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.
> >>
> >
>