Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05

Mingui Zhang <> Mon, 31 August 2015 03:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E8DC41ACE40; Sun, 30 Aug 2015 20:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fv6DhRIFc7-4; Sun, 30 Aug 2015 20:55:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3ADF1ACE3D; Sun, 30 Aug 2015 20:55:34 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BWY08556; Mon, 31 Aug 2015 03:55:04 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 31 Aug 2015 04:55:03 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Mon, 31 Aug 2015 11:54:56 +0800
From: Mingui Zhang <>
To: Russ Housley <>, "" <>
Thread-Topic: Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
Thread-Index: AQHQ4RO7GL3QfcPgCUuUTfg8C/4Zkp4lTBGw
Date: Mon, 31 Aug 2015 03:54:55 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Cc: IETF Gen-ART <>, IETF <>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Aug 2015 03:55:39 -0000

Hi Russ,

Thanks for the comments. Please see the in-lines below.

> -----Original Message-----
> From: Russ Housley []
> Sent: Friday, August 28, 2015 5:59 AM
> To:
> Subject: Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
> 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
> <>.
> 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".

[MZ] This will be incorporated for easy reading.

> (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?

[MZ] The sort is done in the per-LAALP base. It's not necessary to make the LAALP ID to a constant length. Besides, the 'mod' function always returns a value in [0, k-1] whatever the length of LAALP ID is. 

> (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?

[MZ] The LAALP is REQUIED to keep the consistence. That is to say, if the consistence cannot be maintained, it is not qualified as a LAALP. What TRILL switches can do is that ports connected to inconsistent LAALPs MUST be disabled. This requirement can be added.

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

[MZ] Yes, there was a Capability TLV in [MultiAttach] to handle the interoperability. Explicit consequences can be explained here.

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

[MZ] Yes, this is clear. Will be incorporated. 

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

[MZ] Currently, it is not compatible. In the text, the [CentralReplicate] mentions because it is an alternative of RPF rather than the whole Active-Active mechanism. You know, RPF issue is a sub-issue of Active-Active. I think the last sentence should be removed to avoid confusion.

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

[MZ] Above replacement will be executed. Thanks.

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