[trill] AD review of draft-ietf-trill-pseudonode-nickname-04

Alia Atlas <akatlas@gmail.com> Thu, 30 July 2015 22:29 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 63E521ACF60 for <trill@ietfa.amsl.com>; Thu, 30 Jul 2015 15:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yYh6wUgE_f6h for <trill@ietfa.amsl.com>; Thu, 30 Jul 2015 15:29:57 -0700 (PDT)
Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B461ACEF7 for <trill@ietf.org>; Thu, 30 Jul 2015 15:29:57 -0700 (PDT)
Received: by obdeg2 with SMTP id eg2so41466211obd.0 for <trill@ietf.org>; Thu, 30 Jul 2015 15:29:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VPY0XxcUSS7rwbu25nep9l2IH3Al04ejPalRsHUpOCc=; b=wsw74XD6CXg6DqT6DFouydogAhmYFuWt/Locg8/0aAicJe9NEcjRdhA/lw7/DItRAO W7HW0dPCe7H9MvyM2qfrRWV1xypHOOko1VDknl6TvUtpZH6TBfZcblHDfY3jedcVCn00 ZxBw4JtvMlvPQO4+CvzWkC8Pbv0LKjOjYQW9hRNZtlvEZV8Q/evgnL83Izf73X1+F/Ng I0jPrWcFciENgMo0BXK0RbDK6F4A8ZVhpxqS1XEsdxVZKznENJZtEPXU7ntPT++R3yQ0 fvgYxkCnWFND1YQPG4a1VtC9QSeF6Raz7kOYY2wydKEW8b36viRR2v3xaNOtc+8FfWjh yYJA==
MIME-Version: 1.0
X-Received: by with SMTP id ro7mr47401065oeb.13.1438295397098; Thu, 30 Jul 2015 15:29:57 -0700 (PDT)
Received: by with HTTP; Thu, 30 Jul 2015 15:29:56 -0700 (PDT)
Date: Thu, 30 Jul 2015 18:29:56 -0400
Message-ID: <CAG4d1rc_zjEkSU+zyvEGR76hmnqbi363-p=frsK192qapCGrDA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: trill@ietf.org, draft-ietf-trill-pseudonode-nickname@tools.ietf.org, Don Eastlake <d3e3e3@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b41c5b439e898051c1f3e53
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/PiPanfGD1YQSC2GyCKLLDJa_bGU>
Subject: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2015 22:29:59 -0000

First, let me thank Hongjun, Tissa, Radia, Mingui, and Yizhou, the authors
of this fine draft, for their hard work in producing a document that is
easy to read and very detailed.

As is customary, I've done my AD review of this draft before requesting
IETF Last Call.  I do have a few questions and clarifications which I will

I intend to review the other two associated trill drafts tomorrow and
progress all 3 to an IETF Last Call with a target of getting on the Aug 20
IESG telechat.  If that telechat gets too full, they might need to move to
two weeks later.

As we finally push through on this process, having very responsive authors
helps immensely in getting drafts through the process.

Here are the details of my review:

Minor concerns:

1) On p. 15 & 16: I'm a bit confused because on p. 15, it says "The basic
idea of DF is to elect one RBridge per VLAN from an RBv to egress
multi-destination TRILL Data traffic and replicate locally-received
multi-destination native frames to the CEs served by the RBv."  but
then on p. 16 in Step 4 part 1), it says: "RBv ports associated with
the same pseudo-nickname as that of the incoming port, no matter
whether RBi is the DF for the frame's VLAN on the outgoing ports
except that the frame MUST NOT be replicated back to the incoming
port".  This seems to be contradictory.  Moreover, if one say CE1,
CE2, and CE3 all in the same RBv, when CE1 sends a packet to RB2 and
RB1 is the DF for the particularly VLAN, then wouldn't RB2 forward the
packet to CE1 and CE2 while RB1 would also do so as the DF?  Could you
please clarify what is causing the inconsistency and problem?  Maybe
the text in 6.1 on p. 18 helps describe that there are actually two
cases to the text on p. 16?

2) On p.23 in Sec 9.1: There is no way of identifying what the type of
the LAALP ID is.  Assuming it is a number and meaning doesn't matter,
it would be really good to clarify that.

3) In Sec 9.2: How can an LAALP ID be withdrawn from PN-RBv
APPsub-TLV?  Could you please describe that sequence?