Re: [trill] corrections on draft-ietf-trill-p2mp-bfd-00

Mingui Zhang <zhangmingui@huawei.com> Mon, 14 September 2015 03:54 UTC

Return-Path: <zhangmingui@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350681B3475 for <trill@ietfa.amsl.com>; Sun, 13 Sep 2015 20:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHWXdrFcEWvD for <trill@ietfa.amsl.com>; Sun, 13 Sep 2015 20:54:34 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0B61B5ABE for <trill@ietf.org>; Sun, 13 Sep 2015 20:54:29 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBF72613; Mon, 14 Sep 2015 03:54:27 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Sep 2015 04:54:26 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.166]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Mon, 14 Sep 2015 11:54:20 +0800
From: Mingui Zhang <zhangmingui@huawei.com>
To: gayle noble <windy_1@skyhighway.com>, "trill@ietf.org" <trill@ietf.org>
Thread-Topic: [trill] corrections on draft-ietf-trill-p2mp-bfd-00
Thread-Index: AQHQ7WtjoJxRbZQbQkWYNlqUCJnPjJ47Sxyw
Date: Mon, 14 Sep 2015 03:54:19 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E7871BB1FE@nkgeml512-mbx.china.huawei.com>
References: <20150912050428.3487.28490.idtracker@ietfa.amsl.com> <CAF4+nEGrEMC-Zio+T6xyQxg1QmKnMzYR=HieuO4zKntY71YR3w@mail.gmail.com> <201509121457.t8CEvOFQ024944@skyhighway.com>
In-Reply-To: <201509121457.t8CEvOFQ024944@skyhighway.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.146.93]
Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E7871BB1FEnkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/_tawSwvPD5h6Dz-Ie7XthygYUuM>
Subject: Re: [trill] corrections on draft-ietf-trill-p2mp-bfd-00
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Sep 2015 03:54:36 -0000

Hi Gayle,

Thanks very much! The correction will be incorporated soon.

Mingui

From: trill [mailto:trill-bounces@ietf.org] On Behalf Of gayle noble
Sent: Saturday, September 12, 2015 10:58 PM
To: trill@ietf.org
Subject: [trill] corrections on draft-ietf-trill-p2mp-bfd-00

In draft-ietf-trill-p2mp-bfd-00 I found four things that I'd like re-worded :)

1.     page 2 Introduction third paragraph second and third sentence
[The first sentence states the tail LOST connectivity from the head. This translates to meaning there is no way for the tail to talk to the head. Then the next sentence states it must inform this head that it cannot talk to (based on the first sentence) it using the existing RBridge Channel. I think the first sentence needs to be re-worded for clarity as I am now assuming the first sentence really is trying to say that the tail lost connectivity on the new RBridge Channel that was allocated for this purpose. Also - the word "when" implies this will happen more often then not. I'd use the word "If" to imply this is a rare occurrence. But that's me]
(as written)
When the tail loses connectivity from the head, the tail should notify the head of the lack of multipoint connectivity with unicast BFD Control packets.
These packets are transmitted using the existing RBridge Channel assigned to BFD Control [RFC7175].
(I'd write)
If the tail loses connectivity from the head on the new RBridge Channel protocol, the tail should notify the head of the lack of multipoint connectivity with unicast BFD Control packets. These packets are transmitted using the existing RBridge Channel assigned to BFD Control [RFC7175].

2.   page 3 #4 A New RBridge Channel for P2MP BFD first paragraph third sentence
[Sentence reads weird - normally if "while for" is used there would be something before that was different in the same sentence]
(as written)
While for P2MP BFD, the head is required to probe tails using multicast.
(I'd write)
In P2MP BFD, the head is required to probe tails using multicast.

3.   page four first paragraph
[In case someone is skimming the document I'd make it a bit clearer which channel is being referenced in this sentence]
(as written)
As specified in [RFC7178], when the tail receives TRILL Data packets sent on the channel, it will absorb the packets itself rather than deliver these packets to its attached end-stations.
(I'd write)
As specified in [RFC7178], when the tail receives TRILL Data packets sent on this newly specified channel, it will absorb the packets itself rather than deliver these packets to its attached end-stations.

4.   page four Discriminators and Packet Demultiplexing second paragraph last sentence
[ "need" should be "needs" as tail is singular]
(as written)
If the tail need to notify the head about the failure of a multipath, the tail is required to send unicast BFD Control packets using the same Data Label as used by the head.
(as written)
If the tail needs to notify the head about the failure of a multipath, the tail is required to send unicast BFD Control packets using the same Data Label as used by the head.


thanks!
gayle