[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) by ietfa.amsl.com (Postfix) with ESMTP id B6D301B2BF9; Thu, 27 Aug 2015 14:59:42 -0700 (PDT)
Received: from localhost (unknown []) 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 ([]) by localhost (ronin.smeinc.net []) (amavisd-new, port 10024) with ESMTP id VvTY4MGTUyA0; Thu, 27 Aug 2015 17:58:14 -0400 (EDT)
Received: from [] (pool-108-51-128-219.washdc.fios.verizon.net []) (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

   ... 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

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.