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

Carl Wallace <> Mon, 14 September 2015 10:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 88E061B53F8 for <>; Mon, 14 Sep 2015 03:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GKeFm-efWx_y for <>; Mon, 14 Sep 2015 03:19:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09D2E1B545F for <>; Mon, 14 Sep 2015 03:19:29 -0700 (PDT)
Received: by qkcf65 with SMTP id f65so55866773qkc.3 for <>; Mon, 14 Sep 2015 03:19:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=T6/Dwf11bOSBwh6QP54xCNkf+Tw32gSCtw+D8QPP0hM=; b=Dk8xfgu4xGfmUKRcbokyqCK5aVHDCWunYk6OdPJFzRJF1a2OrCqEasdZsQPQRITMkd nJZYqiXCMddMGoYX4xHzCtWC+vPB35xAql0mAWt7iLUaYHcu/hgWAXSPxzzz1lBx84MZ xPKNWPURecdKv6RMazE0g5kEiZkav+GBGWdSkAzvOcNm+SCX1k/uR4mEBUbskdzsHlMV cTSCZUcgVpjaSe0pvgTCQCcZDk2Kx/c4FLxf6q1868RV2zapQy3Ia2/p45TB+1ynsDAQ 2sOobqSMOB5cyk9U98hJG6P9uw6Ff2BmJxUZQBuxUUtoV8dU/O3Mfo8/qwSlgqX02IPK UTdw==
X-Gm-Message-State: ALoCoQkhzcBvHXW1YWmKdZK1IoT6Rf6H1c6gSnvBqVewirkFuS8y9ev50gwqFcYTGxlpTKr5eHz/
X-Received: by with SMTP id n8mr20533267qki.85.1442225968170; Mon, 14 Sep 2015 03:19:28 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id 88sm5614103qkr.5.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Sep 2015 03:19:27 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Mon, 14 Sep 2015 06:19:14 -0400
From: Carl Wallace <>
To: Mingui Zhang <>, "" <>
Message-ID: <>
Thread-Topic: draft-ietf-trill-pseudonode-nickname-06
References: <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <>
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 10:19:31 -0000

On 9/13/15, 11:51 PM, "Mingui Zhang" <> 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.

>> -----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
>> effort to review all IETF documents being processed by the IESG.
>> These comments were written primarily for the benefit of the security
>> 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
>> all member RBridges of the new RBv and be egressed to CE1 by either RB2
>> RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the
>> 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
>> and the creation of a new RBv following the failure of RB1 that enables
>> traffic to be forwarded? Generally, mentioning failure of the DF for
>>the virtual
>> RBridge seemed like it might warrant mention in the security
>> section, since that is new relative to the specs noted in the current
>> considerations.