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

From: Carl Wallace <[email-masked]>
Date: Sat, 12 Sep 2015 15:59:48 -0400

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.

---

From: Carl Wallace <[email-masked]>
Date: Mon, 14 Sep 2015 06:19:14 -0400

On 9/13/15, 11:51 PM, "Mingui Zhang" <[email-masked]> 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:[email-masked]]
>> Sent: Sunday, September 13, 2015 4:00 AM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: draft-ietf-trill-pseudonode-nickname-06
>> 
>>ongoing
>> effort to review all IETF documents being processed by the IESG.
>> 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:
>> 
>>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."
>> 
>>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.
>> 
>

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 14 Sep 2015 03:51:58 +0000

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

> I have reviewed this document as part of the security directorate’s ongoing
> 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
> RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the packet's
> 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.
>

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 15 Sep 2015 01:15:19 +0000

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

> Sent: Monday, September 14, 2015 6:19 PM
> To: Mingui Zhang; [email-masked]
> Subject: Re: draft-ietf-trill-pseudonode-nickname-06
> 
> 
> 
> >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
> 
> >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.
> 
> 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
> >
> >> 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.
> >>
> >>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
> >>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.
> >>
> >
>