[RTG-DIR] RtgDir QA review on draft-ietf-idr-bgp-gr-notification-03

Mach Chen <mach.chen@huawei.com> Mon, 22 September 2014 07:19 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840FE1A1A42; Mon, 22 Sep 2014 00:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.833
X-Spam-Level:
X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 DMydZZtYJIqN; Mon, 22 Sep 2014 00:19:47 -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 04C481A1A40; Mon, 22 Sep 2014 00:19:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR91121; Mon, 22 Sep 2014 07:19:45 +0000 (GMT)
Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 22 Sep 2014 08:19:43 +0100
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Mon, 22 Sep 2014 15:19:40 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-bgp-gr-notification@tools.ietf.org" <draft-ietf-idr-bgp-gr-notification@tools.ietf.org>
Thread-Topic: RtgDir QA review on draft-ietf-idr-bgp-gr-notification-03
Thread-Index: Ac/WNY9hijUo731zTvqx4ERfOezi8Q==
Date: Mon, 22 Sep 2014 07:19:39 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DAD3D70@SZXEMA510-MBX.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/E3ngJKUjPZmeAsaXzqCAgBKIMzA
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: [RTG-DIR] RtgDir QA review on draft-ietf-idr-bgp-gr-notification-03
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Sep 2014 07:19:50 -0000

Hi Authors,

I was assigned to do a QA review on draft-ietf-idr-bgp-gr-notification-03. For more detail what's is RtgDir QA review, please refer to https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa 

Overall, the document is well-written and clear, after review, I have the following comments. 

1.  Abstract
s/BGP NOTIFICATION Message/ BGP NOTIFICATION message;

2.  Section 2:
"
    Flags for Address Family:

            This field contains bit flags relating to routes that were
            advertised with the given AFI and SAFI.

                0 1 2 3 4 5 6 7
               +-+-+-+-+-+-+-+-+
               |F|N| Reserved  |
               +-+-+-+-+-+-+-+-+

   The usage of second most significant bit "N" is deprecated.  This bit
   MUST be advertised as 0 and MUST be ignored upon receipt.
"
The "N" bit was firstly introduced in a previous version of this document, but deprecated in later version. I don't understand why a document need deprecate a functionality introduced by itself, why not just remove it?

In addition, since there is no changes to the AF related flags, the last sentence of the first paragraph of section 2 should be changed as bellow:

OLD:
"the Restart flags field and the Flags field for Address Family are augmented as follows:"

New:
"the Restart flags field are augmented as follows:"

3.  Section 3.1

"Subcode is a BGP Error Subcode (as documented in the IANA BGP Error
   Subcodes registry) as appropriate for the ErrCode.  Similarly, Data
   is as appropriate for the ErrCode and Subcode."
This is just an introduction to the Subcode itself, it's better to explicitly state that the subcode should be set to the Hard Reset (9).

4.  Section 4
"Once the session is re-established, both BGP speakers SHOULD set
   their "Forwarding State" bit to 1."

Here it implies that the speakers are required to set the "Forwarding State" no matter what the speakers have the ability to preserve the forwarding state. Is it the intention?  

I guess it's not, if so, some text may needed to clarify this.

5. I run idnits tool and found the following nits:

== Unused Reference: 'RFC3392' is defined on line 269, but no explicit reference was found in the text.


Best regards,
Mach