[trill]  I-D Action: draft-ietf-trill-smart-endnodes-06.txt ///   答复: Comments on draft-ietf-trill-smart-endnodes

<hu.fangwei@zte.com.cn> Tue, 21 November 2017 05:51 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297C1127011 for <trill@ietfa.amsl.com>; Mon, 20 Nov 2017 21:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 vJ8C_IsY9qeT for <trill@ietfa.amsl.com>; Mon, 20 Nov 2017 21:50:59 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 B200A126CF6 for <trill@ietf.org>; Mon, 20 Nov 2017 21:50:57 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id ECE5FD93BC3495C44E13; Tue, 21 Nov 2017 13:50:54 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Forcepoint Email with ESMTPS id 964066D71624359E66F9; Tue, 21 Nov 2017 13:50:54 +0800 (CST)
Received: from xgxapp01.zte.com.cn ([10.30.14.22]) by mse02.zte.com.cn with SMTP id vAL5onwE032852; Tue, 21 Nov 2017 13:50:49 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn)
Received: from mapi (xgxapp02[null]) by mapi (Zmail) with MAPI id mid71; Tue, 21 Nov 2017 13:50:51 +0800 (CST)
Date: Tue, 21 Nov 2017 13:50:51 +0800
X-Zmail-TransId: 2afa5a13bebb6b5-4fe6d
X-Mailer: Zmail v1.0
Message-ID: <201711211350511882652@zte.com.cn>
Mime-Version: 1.0
From: hu.fangwei@zte.com.cn
To: d3e3e3@gmail.com, shares@ndzh.com, trill@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse02.zte.com.cn vAL5onwE032852
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/Lo6uWFDc_fxsLmstODxHchR17mM>
Subject: [trill]  I-D Action: draft-ietf-trill-smart-endnodes-06.txt ///   答复: Comments on draft-ietf-trill-smart-endnodes
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: Tue, 21 Nov 2017 05:51:02 -0000

Hi, The smart endnode draft was pudlished to 06 version( https://www.ietf.org/internet-drafts/draft-ietf-trill-smart-endnodes-06.txt) to fix the Donald and Julien Meuric's comments.



And I presented the changes from the lastest presentations in the IETF 100th meeting last week.


The presentation slides is as following:


https://datatracker.ietf.org/meeting/100/materials/slides-100-trill-smart-endnodes/










原始邮件



发件人:胡方伟10075772
收件人: <d3e3e3@gmail.com>;
抄送人: <trill@ietf.org>;
日 期 :2017年08月03日 09:11
主 题 :[trill] 答复:  Comments on draft-ietf-trill-smart-endnodes



Hi, Donlad

Thanks for your comments.

A new version(draft-ietf-trill-smart-endnodes-06) is uploaded to IETF to fix the comments.







A new version of I-D, draft-ietf-trill-smart-endnodes-06.txthas been successfully submitted by Fangwei Hu and posted to theIETF repository.Name:        draft-ietf-trill-smart-endnodesRevision:    06Title:        TRILL Smart EndnodesDocument date:    2017-08-02Group:        trillPages:        14URL:            https://www.ietf.org/internet-drafts/draft-ietf-trill-smart-endnodes-06.txtStatus:         https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/Htmlized:       https://tools.ietf.org/html/draft-ietf-trill-smart-endnodes-06Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-trill-smart-endnodes-06Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-smart-endnodes-06Abstract:   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.




Regards.

Fangwei.



        










发件人: <d3e3e3@gmail.com>;
收件人: <trill@ietf.org>;
日 期 :2017年07月21日 17:07
主 题 :[trill] Comments on draft-ietf-trill-smart-endnodes





I support this draft and have the following comments:

Technical
-------------

It is not made clear how Smart End Nodes learn the Designated VLAN of
the link they are on or, considering the paragraph just before the
Section 5.2 header, the Appointed Forwarder for a VLAN or the DRB. It
seems to me the draft needs to say explicitly that the smart end node
snoops on TRILL IS-IS Hellos. Also, it needs to say that a smart end
node, when encapsulating traffic in VLAN X, needs to use the nickname
of the appointed forwarder for VLAN X, regardless of which edge
RBridge it sends the encapsulated frame to, to avoid MAC flip-flop at
the egress RBridge.

The point paragraph just before the Section 6 header provides two
approaches to handling a hybrid local link (a hybrid link is one with
both smart and non-smart end nodes on it). As a Proposed Standard and
in accordance with TRILL's general design approach, the document needs
to select one and make it be the default.

Section 6 also has two alternatives and does not seem clear.
Presumably there isn't a single link with SE1, RB1, and RB2 on it
since that case is well handled by the smart end node using the
appointed forwarder nickname regardless of which edge RBridge it sends
the encapsulated user data to. So it must be that SE1 is dual ported.
If so, probably these ports have different MAC addresses and I'm not
sure what the problem is....

I think it is inconsistent that IANA Considerations says "Smart-Hello"
while near the start of the draft, the TLV is called
"Smart-Parameters".

"The mechanism for querying a directory is out of scope for this
document." -> "The mechanism for querying a directory is given in
[RFC8171]."

Editorial
-----------

Change ".While when" to ". When"

"nicknamae" -> "nickname"

There are also some other more minor editorial things I can
communicate directly to the principal author.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill