[trill] 答复: WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017)

Haoweiguo <haoweiguo@huawei.com> Mon, 16 January 2017 01:48 UTC

Return-Path: <haoweiguo@huawei.com>
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 9B475127058; Sun, 15 Jan 2017 17:48:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.419
X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fiuPUjDCZDU7; Sun, 15 Jan 2017 17:48:47 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E723128824; Sun, 15 Jan 2017 17:48:46 -0800 (PST)
Received: from (EHLO lhreml708-cah.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYV48219; Mon, 16 Jan 2017 01:48:43 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com ( by lhreml708-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 16 Jan 2017 01:48:41 +0000
Received: from NKGEML513-MBS.china.huawei.com ([]) by NKGEML413-HUB.china.huawei.com ([]) with mapi id 14.03.0235.001; Mon, 16 Jan 2017 09:48:37 +0800
From: Haoweiguo <haoweiguo@huawei.com>
To: Susan Hares <shares@ndzh.com>, "trill@ietf.org" <trill@ietf.org>
Thread-Topic: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017)
Thread-Index: AdJuc2ZW/JsGLZoBSw2sBH+1A+0GaQBJyThQ
Date: Mon, 16 Jan 2017 01:48:37 +0000
Message-ID: <DD5FC8DE455C3348B94340C0AB5517336602DCB1@nkgeml513-mbs.china.huawei.com>
References: <01fe01d26e78$52a06560$f7e13020$@ndzh.com>
In-Reply-To: <01fe01d26e78$52a06560$f7e13020$@ndzh.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517336602DCB1nkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.587C267C.008A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 50be3ac7de77e0bd4bd681af0f4999ca
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/-ApvkOVrimrvn9rMQxhSB-ebwGU>
Cc: "draft-ietf-trill-address-flush@ietf.org" <draft-ietf-trill-address-flush@ietf.org>, "trill-chairs@ietf.org" <trill-chairs@ietf.org>
Subject: [trill] =?gb2312?b?tPC4tDogIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0?= =?gb2312?b?Zi10cmlsbC1hZGRyZXNzLWZsdXNoICgxLzEzLzIwMTcgdG8gMS8yNy8yMDE3?= =?gb2312?b?KQ==?=
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 16 Jan 2017 01:48:49 -0000

Thanks Sue, I will update the draft as per your comments ASAP.

·¢¼þÈË: Susan Hares [mailto:shares@ndzh.com]
·¢ËÍʱ¼ä: 2017Äê1ÔÂ14ÈÕ 23:10
ÊÕ¼þÈË: trill@ietf.org
³­ËÍ: draft-ietf-trill-address-flush@ietf.org; trill-chairs@ietf.org
Ö÷Ìâ: RE: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017)

Weiquo, Donald, Yizhou, and Mohammed:

Thank you for your work on draft-ietf-trill-address-flush. This is a shepherd¡¯s review for draft-ietf-trill-address-flush.    ¡®

Shepherd¡¯s answer to questions:

1)      Deployment experience ¨C No deployment experience, but this target action has been useful in other protocols.

2)      Convergence experience ¨C No convergence measurement experience, but targeted convergence based on a centralized controllers can provide better convergence theoretically.

3)      Mechanisms comments below ¨C seem to be editorial, but may be minor.

4)      With editorial/minor changes ¨C document is ready for publication

Status: Ready with minor/editorial comments.

Minor/editorial changes:

#1 page 10,m paragraph 2 ¨C after table, beginning with ¡°All RBridges implementing¡±

Editorial change:  The next 4 paragraph state requirements for processing need to be clearly laid out.  A set of suggested text that replaces paragraphs 2, 3, 4 (p. 10-11).

Processing Requirements:

The processing requirements based on support for Address Flush Channel message plus the additional types:

¡¤         Basic RBridges functionality:  All RBridges supporting the Address Flush Channel message MUST implement type 1 (Blocks of VLANs),  type 2 (Bit map of VLANs), and type 6 (All Data labels).  Type 6 indicates that all addresses are to be flushed for all data labels.

¡¤         Optional RBridges functionality:  RBridges SHOULD implement types 7 and type 8 so that specific MAC addresses can be can be flushed.  If a set of RBridges does not implement types 7 and 8, the flush will be inefficient as those not intent to be flashed will have to be relearned.

¡¤         FGL functionality : All RBridges implementing the FGL ingress/egress support and the Address Flush Channel message MUST implement type 3 (Blocks of FGLs), type 4 (Lists of FGLs), and type 5 (Bit Map of FGL).  An RBridge that is merely FGL safe [RFC7172], but cannot egress TRILL data packets, SHOULD ignore the FGL types with the Address Flush Channel message as it will not learn any MAC addresses with FGL scope from the MAC data plane.

Processing interactions:

The parsing of the TLVs in an Rbridge Channel Message in the Address Flush Protocol Specific TLVS by a receiving bridge results in three items:

1)      All-Data-label-found flag indicating whether one or more types 6 TLVs (All Data Labels) were encountered,

2)      A set of Data labels and blocks of data labels compiled from VLAN TLVs (types 1 and 2), and/or FGL TLVs (types 3, 4, and 5),

3)      If a MAC TLVs types (type 6 and 7)  are implemented, a set of MAC addresses and Blocks of MAC addresses from the MAC TLVs.

For the following flag settings, the processing is as follows:

a)      If the set of MAC addresses and Block of MAC address is null (item 3 above) then Address Flush applies to all messages.

b)      If the  All-Data-label-found flag (item 1 above) is true, then the address flush message applies to all data labels.  The set of Data label and block of data labels (item 2 above) does not have any effect.

c)       If the All-Data-label-found flag (item 1 above) is false, then the Address Flush message applies to the set of Data labels (see item 2 above) found in VLAn TLVs (types 1 and 2), and/or FGLs TLVS (types 3, 4, and 5).   If the set of Data Labels (see item 2 above) is null, the Address Flush message does nothing.

#2 ¨C editorial nits
#2.a) p. 9, figure 4 ¨C bottom +-+ does not match top ¨C Is this what you wanted or an error?
#2.b) p. 9, paragraph beginning  ¡°Type: The 8 bit¡±

Old/ of this Section 2.2 for details on each type /
New/of this section (section 2.2) for details on each type/

Sue Hares

From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, January 13, 2017 8:45 PM
To: trill@ietf.org<mailto:trill@ietf.org>
Cc: draft-ietf-trill-address-flush@ietf.org<mailto:draft-ietf-trill-address-flush@ietf.org>; trill-chairs@ietf.org<mailto:trill-chairs@ietf.org>
Subject: [trill] WG Last Call for draft-ietf-trill-address-flush (1/13/2017 to 1/27/2017)

This begins a 2 week WG Last Call for (1/13/2017 to 1/27/2017) for draft-ietf-trill-address-flush which you can access at:

In your review please consider the following questions:

1)      Do you think this request from one TRILL Rbridge to another TRILL Rbridges is useful in deployments?

2)      Does it supplement TRILL¡¯s automatic address forgetting and achieve better convergence times when topologies or configuration changes?

3)      Are the mechanisms described in this draft technically sound without adding lots of complexity to Trill?

4)      Is this document ready for publication?

Will the authors please indicate if they know of any IPR relating to this draft in their response to this WG LC?  I would appreciate if the authors will answer these four questions as well.

Sue Hares
TRILL WG Co-chair