[Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
Russ Housley <housley@vigilsec.com> Thu, 27 August 2015 21:59 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D731B2CAE; Thu, 27 Aug 2015 14:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wkfc7RJIb5iw; Thu, 27 Aug 2015 14:59:53 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id B6D301B2BF9; Thu, 27 Aug 2015 14:59:42 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 5E177F24169; Thu, 27 Aug 2015 17:59:32 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id VvTY4MGTUyA0; Thu, 27 Aug 2015 17:58:14 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4F960F2415F; Thu, 27 Aug 2015 17:59:11 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Thu, 27 Aug 2015 17:59:00 -0400
Message-Id: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com>
To: draft-ietf-trill-pseudonode-nickname.all@ietf.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/Ak9mJGNEvbchHiPOADgtaOy-mek>
Cc: IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
Subject: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 21:59:55 -0000
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-trill-pseudonode-nickname-05 Reviewer: Russ Housley Review Date: 2015-08-24 IETF LC End Date: 2015-09-01 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: (1) In section 5.2, the document provides this formula: "(System IDj | LAALPi) mod k". In my first reading, I missed the overloading of "LAALPi", and I think it would be more clear to say "(System IDj | LAALP IDi) mod k". If this is accepted, the description becomes simple: "... and the LAALP IDi is the LAALP ID for LAALPi". (2) Also, in Section 5.2, Step 1, I think the intended sort order depends on all of the LAALP IDi values being represented with the same number of bits. Since Section 9.1 provides a variable length field to carry a LAALP ID value, I assume that they are not always the same length. Is a step needed to encode the LAALP ID to a consistent length? (3) In Section 11, we learn that the VLAN membership of all the RBridge ports in an LAALP MUST be the same. Any inconsistencies in VLAN membership may result in packet loss or non-shortest paths. Is there anything that can be added to the Security Considerations that can help avoid these inconsistencies? Minor Concerns: (1) In section 1, we learn that there is more than one way to handle nicknames: ... A member RBridge of such a group uses a pseudo-nickname, instead of its own nickname, as the ingress RBridge nickname when ingressing frames received on attached LAALP links. Other methods are possible; for example the specification in this document and the specification in [MultiAttach] could be simultaneously deployed for different AAE groups in the same campus. Both of these specifications are Internet-Drafts in the TRILL WG. Given this situation, I was expecting some discussion about how an implementer was expected to choose and any consequences on interoperability that result from that choice. (2) I found the last sentence of Section 2 confusing. I am suggesting a rewording to see if I figured it out. If I did not figure it out properly, then the sentence really does need to be reworked. Under the assumption that the default learning is enabled at edge RBridges, MAC flip-flopping can be solved by using a Virtual RBridge together with its pseudo-nickname. This document specifies a way to do so. (3) In Section 5.1, it says: This document uses the approach proposed in [CMT] to fix the RPF check violation issue. Please refer to [CMT] for more details of the approach. An alternative solution is proposed in [CentralReplicate]. Is the alternate solution compatible or incompatible with this document? I am not sure from this paragraph; please add a few words to be clear. Other Comments: The document uses "RPF Check" and "RPF check". Please pick one. In Section 4.1: s/RB3 announces {LAALP1, LAALP2, LAALP3, LAALP}/ /RB3 announces {LAALP1, LAALP2, LAALP3, LAALP4}/ In Section 16.1: s/trill-frc7180bis/trill-rfc7180bis/ In Section 5.1: s/a distribution tree Tx/a distribution tree/ -- The Tx is not referenced later, so it is not needed here In Section 5.1: s/Coordinated Multicast Trees (CMT)/ /Coordinated Multicast Trees (CMT) [CMT]/ In Section 5.3: s/The idea of this check is to check the/ /The idea of this check is to determine the/ In section 11: s/It is important that the VLAN membership of all/ /The VLAN membership of all/ Process Observation: This document contains a normative references to draft-ietf-trill-cmt and draft-ietf-trill-rfc7180bis, both of which have been submitted to the IESG for publication. An updated I-D is needed for draft-ietf-trill-cmt to progress. If this document is approved now, it was wait in the RFC Editor queue for missing references.
- [Gen-art] Gen-ART Review of draft-ietf-trill-pseu… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Sandra Murphy
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Sandra Murphy
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Russ Housley
- [Gen-art] Gen-ART Review of draft-ietf-trill-pseu… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Steve Crocker
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- [Gen-art] Gen-ART Review of draft-ietf-mpls-self-… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-mpls-s… Ronald Bonica
- [Gen-art] Gen-ART Review of draft-ietf-lisp-impac… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-mpls-s… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-lisp-i… Luigi Iannone
- Re: [Gen-art] Gen-ART Review of draft-ietf-lisp-i… Jari Arkko
- [Gen-art] Gen-ART Review of draft-ietf-l2vpn-vpls… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jiangyuanlong
- [Gen-art] Gen-ART Review of draft-ietf-eppext-tmc… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… BRUNGARD, DEBORAH A
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jiangyuanlong
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jari Arkko
- [Gen-art] Resolution on comments of draft-ietf-l2… Jiangyuanlong
- [Gen-art] Gen-ART Review of draft-ietf-dnsop-edns… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… Warren Kumari
- Re: [Gen-art] Resolution on comments of draft-iet… Ben Campbell
- Re: [Gen-art] Resolution on comments of draft-iet… Jiangyuanlong
- Re: [Gen-art] Resolution on comments of draft-iet… Sheng Jiang
- Re: [Gen-art] Resolution on comments of draft-iet… Jiangyuanlong
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… David C Lawrence
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… Warren Kumari
- [Gen-art] Gen-ART Review of draft-ietf-dnsop-edns… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… Jari Arkko
- [Gen-art] Gen-ART Review of draft-ietf-eppext-tmc… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-eppext… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-eppext… Gustavo Lozano
- Re: [Gen-art] Gen-ART Review of draft-ietf-eppext… Gustavo Lozano
- [Gen-art] Gen-ART Review of draft-ietf-rtcweb-aud… Russ Housley