[trill] 答复: Genart telechat review of draft-ietf-trill-smart-endnodes-08

<hu.fangwei@zte.com.cn> Fri, 02 March 2018 03:46 UTC

Return-Path: <hu.fangwei@zte.com.cn>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 220EB126C19; Thu, 1 Mar 2018 19:46:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1F7fec_ebmI3; Thu, 1 Mar 2018 19:46:20 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5AE124D68; Thu, 1 Mar 2018 19:46:19 -0800 (PST)
Received: from mse02.zte.com.cn (unknown []) by Forcepoint Email with ESMTPS id D43DAFBAA9DDC887C495; Fri, 2 Mar 2018 11:46:17 +0800 (CST)
Received: from xgxapp03.zte.com.cn ([]) by mse02.zte.com.cn with SMTP id w223kBKe042464; Fri, 2 Mar 2018 11:46:11 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn)
Received: from mapi (xgxapp01[null]) by mapi (Zmail) with MAPI id mid71; Fri, 2 Mar 2018 11:46:13 +0800 (CST)
Date: Fri, 2 Mar 2018 11:46:13 +0800 (CST)
X-Zmail-TransId: 2af95a98c905526-6b137
X-Mailer: Zmail v1.0
Message-ID: <201803021146131973242@zte.com.cn>
In-Reply-To: <151976308758.28489.12406772916405932448@ietfa.amsl.com>
References: 151976308758.28489.12406772916405932448@ietfa.amsl.com
Mime-Version: 1.0
From: <hu.fangwei@zte.com.cn>
To: <rjsparks@nostrum.com>
Cc: <gen-art@ietf.org>, <ietf@ietf.org>, <draft-ietf-trill-smart-endnodes.all@ietf.org>, <trill@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse02.zte.com.cn w223kBKe042464
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/UTr06QcUtAUHX5r9xcyKkGa5K-w>
Subject: [trill] =?utf-8?b?562U5aSNOiAgR2VuYXJ0IHRlbGVjaGF0IHJldmlldyBv?= =?utf-8?q?f_draft-ietf-trill-smart-endnodes-08?=
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 02 Mar 2018 03:46:22 -0000

Hi, Sparks

Thanks for your review and comments.

A new version(version 10) draft is submitted to fix the issues.



A new version of I-D, draft-ietf-trill-smart-endnodes-10.txthas been successfully submitted by Fangwei Hu and posted to theIETF repository.Name:        draft-ietf-trill-smart-endnodesRevision:    10Title:        TRILL Smart EndnodesDocument date:    2018-03-01Group:        trillPages:        15URL:            https://www.ietf.org/internet-drafts/draft-ietf-trill-smart-endnodes-10.txtStatus:         https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/Htmlized:       https://tools.ietf.org/html/draft-ietf-trill-smart-endnodes-10Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-trill-smart-endnodes-10Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-smart-endnodes-10Abstract:   This draft addresses the problem of the size and freshness of the   endnode learning table in edge RBridges, by allowing endnodes to   volunteer for endnode learning and encapsulation/decapsulation.  Such   an endnode is known as a "Smart Endnode".  Only the attached edge   RBridge can distinguish a "Smart Endnode" from a "normal endnode".   The smart endnode uses the nickname of the attached edge RBridge, so   this solution does not consume extra nicknames.  The solution also   enables Fine Grained Label aware endnodes.


发件人:RobertSparks <rjsparks@nostrum.com>
收件人:gen-art@ietf.org <gen-art@ietf.org>
抄送人:ietf@ietf.org <ietf@ietf.org>draft-ietf-trill-smart-endnodes.all@ietf.org <draft-ietf-trill-smart-endnodes.all@ietf.org>trill@ietf.org <trill@ietf.org>
日 期 :2018年02月28日 04:24
主 题 :[trill] Genart telechat review of draft-ietf-trill-smart-endnodes-08

Reviewer: Robert Sparks
Review result: Ready with Issues

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at


Document: draft-ietf-trill-smart-endnodes-08
Reviewer: Robert Sparks
Review Date: 2018-02-27
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-03-08

Summary: Ready with issues

Major issues

1) In section 4.3 the bullet describing the F bit does not parse. There are two
instances of "Otherwise" that do not work together.

2) All of section 4.3 is confusing as to what the length of the TLV really is.
Row 3 in the diagram says 2 bytes or 4 bytes, but the number of bits called out
in bullets 4 and 5 below it don't seem to add up to those things. Maybe it would
be better to draw a diagram with F=0 and a separate diagram with F=1

3) I think the security considerations section should call out again what an RB
should do if it gets message that looks like it's from a SE, containing the
right nickname, but the RB hasn't done the right Smart-Hello handshaking with
that SE already. What would keep a lazy implementation (or one driven by
product managers picking and choosing features) from just forwarding a message
from a malicious element that just happened to know the RB's nickname?


Terminology: The definition of Transit RBridge says it's also named as a
Transit Rbridge?

trill mailing list