[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.60.141.135 with SMTP id ro7mr47401065oeb.13.1438295397098; Thu, 30 Jul 2015 15:29:57 -0700 (PDT)
Received: by 10.60.41.99 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 describe. 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? Thanks, Alia
- [trill] AD review of draft-ietf-trill-pseudonode-… Alia Atlas
- Re: [trill] AD review of draft-ietf-trill-pseudon… Mingui Zhang
- Re: [trill] AD review of draft-ietf-trill-pseudon… Donald Eastlake
- Re: [trill] AD review of draft-ietf-trill-pseudon… Donald Eastlake
- Re: [trill] AD review of draft-ietf-trill-pseudon… Mingui Zhang
- Re: [trill] AD review of draft-ietf-trill-pseudon… Alia Atlas
- Re: [trill] AD review of draft-ietf-trill-pseudon… Mingui Zhang