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

Mingui Zhang <> Mon, 03 August 2015 03:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 09FA41B2BB3 for <>; Sun, 2 Aug 2015 20:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 fxwnG3X-HO6A for <>; Sun, 2 Aug 2015 20:45:21 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2AE1E1A8A1F for <>; Sun, 2 Aug 2015 20:45:20 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BVT97392; Mon, 03 Aug 2015 03:45:18 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 3 Aug 2015 04:45:17 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Mon, 3 Aug 2015 11:45:13 +0800
From: Mingui Zhang <>
To: Alia Atlas <>, "" <>, "" <>, Don Eastlake <>
Thread-Topic: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04
Thread-Index: AQHQyxdMwlqv6LDvGkeIt5RtbF9LPZ35iaNw
Date: Mon, 3 Aug 2015 03:45:13 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E787164186nkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Aug 2015 03:45:25 -0000

Hi Alia,

Please see comments inline with [mingui].

From: trill [] On Behalf Of Alia Atlas
Sent: Friday, July 31, 2015 6:30 AM
To:;; Don Eastlake
Subject: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04

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.

[mingui] Let me explain the logic. If the RBridge in a RBv group receives a BUM packet from a locally connected CE.  Other CEs will receive the packet replicated by the DF only. Other RBridges will refrain from replicating.
Having said that, it is also important that the DF never replicates the BUM packet back to the incoming port (Say CE1 sends the BUM packet to the DF RB1 via port 1, then RB1 does not send the replicated BUM packet back to CE1 via port 1.)

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?

[mingui] As explained above, RB2 will refrain from replicating since it is not 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?

[mingui] Yes, I agree.

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.

[mingui] Agree.

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

[mingui] I think, if RBx needs to just withdraw one LAALP ID, it will refresh the previous announced LSP by omitting that LAALP ID from the LAALP ID list in the PN-RBv APPsub-TLV.