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

Mingui Zhang <> Mon, 14 September 2015 03:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E516F1B5A8F; Sun, 13 Sep 2015 20:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NHAOVBrtpsKa; Sun, 13 Sep 2015 20:52:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1763D1B5A85; Sun, 13 Sep 2015 20:52:08 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BXO46959; Mon, 14 Sep 2015 03:52:07 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 14 Sep 2015 04:52:04 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Mon, 14 Sep 2015 11:51:59 +0800
From: Mingui Zhang <>
To: Carl Wallace <>, "" <>
Thread-Topic: draft-ietf-trill-pseudonode-nickname-06
Thread-Index: AQHQ7ZWmwM2br1fzd0eZlb8TxXO1+547X/TQ
Date: Mon, 14 Sep 2015 03:51:58 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
X-Mailman-Approved-At: Mon, 14 Sep 2015 08:03:52 -0700
Cc: "" <>, "" <>
Subject: Re: [secdir] draft-ietf-trill-pseudonode-nickname-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Sep 2015 03:52:13 -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. 


> -----Original Message-----
> From: Carl Wallace []
> Sent: Sunday, September 13, 2015 4:00 AM
> To:
> Cc:;
> 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.