[RTG-DIR] RtgDir review: draft-ietf-idr-bgp-extended-messages-11

"Brian Weis (bew)" <bew@cisco.com> Thu, 03 September 2015 23:02 UTC

Return-Path: <bew@cisco.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 EE2C91B2A48; Thu, 3 Sep 2015 16:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 OmUC28y2KgON; Thu, 3 Sep 2015 16:02:31 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F6D1A893A; Thu, 3 Sep 2015 16:02:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6748; q=dns/txt; s=iport; t=1441321351; x=1442530951; h=from:to:cc:subject:date:message-id:mime-version; bh=EjOTQTGoTZ+PxJl4Ed5KYSblorI6i86xsmwRGORtebo=; b=Lb0evvJhc78NQVurum3uRGU11DSv02OfOyL2GQVxYNe4dW2YZcDYruK9 oeYfrKH+33Lad2RwRLVuaMNGhr3jfQ6tmxLDvsdOqr28Wm1ObFABjx5jU 9ubImuNBXGEVuZsol4sMqWcW+P7irN1cdP9050K7iVvXCuLnbvQII5ZqB E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CbAgBJ0OhV/5BdJa1dgyFUaQaDHrl9KgEJgXeFex6BGTgUAQEBAQEBAX8LhCYEI1YSAQwQLgIEMCcEDogzDbZqlDwBAQEBAQEBAQEBAQEBAQEBAQEBGYkCh2YRgnAvgRQFlVEBhQaHcIFKRoNslHMRFYQAcohGgQUBAQE
X-IronPort-AV: E=Sophos; i="5.17,464,1437436800"; d="scan'208,217"; a="26051355"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 03 Sep 2015 23:02:30 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t83N2Tj1024156 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Sep 2015 23:02:29 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 3 Sep 2015 18:02:28 -0500
Received: from xhc-rcd-x08.cisco.com (173.37.183.82) by xch-aln-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 3 Sep 2015 18:02:28 -0500
Received: from xmb-aln-x04.cisco.com ([169.254.9.110]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0248.002; Thu, 3 Sep 2015 18:02:28 -0500
From: "Brian Weis (bew)" <bew@cisco.com>
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Thread-Topic: RtgDir review: draft-ietf-idr-bgp-extended-messages-11
Thread-Index: AQHQ5pyavJqj3SsTMUuXdi1VXKYzow==
Date: Thu, 3 Sep 2015 23:02:27 +0000
Message-ID: <AF599976-2CAE-4180-998B-47C1EA6CFF79@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.37.102.18]
Content-Type: multipart/alternative; boundary="_000_AF5999762CAE4180998B47C1EA6CFF79ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/6EJK3UC7bFnTps0afdpl2Iw3d5Y>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-bgp-extended-messages.all@tools.ietf.org" <draft-ietf-idr-bgp-extended-messages.all@tools.ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-extended-messages-11
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 03 Sep 2015 23:02:33 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-idr-bgp-extended-messages-11
Reviewer: Brian Weis
Review Date: September 3, 2015
IETF LC End Date: Unknown
Intended Status: Standards Track

Summary:
I have a minor concern about this document that I think should be resolved before publication.

Comments:
The document is clearly written and easy to understand.

Major Issues:
No major issues found.

Minor Issues:
Section 5 (Error Handling) delineates two error cases possible when a BGP speaker has not advertised that it can use extended messages, but does receive one from a peer. Each case has its own paragraph in this section. The first paragraph describes a BGP speaker that can use extended messages (but has not advertised it); the second paragraph describes a BGP speaker that actually cannot use extended messages. In the second paragraph the error response is clearly stated (i.e., follow the error handling procedures of RFC 4221 and reset the session). But as written it does not seem that any such response is required for the first case. It isn’t clear to me why this type of BGP speaker would respond differently, and if the error response was intended for both cases then I suggest the text describing the response be separated into a third paragraph. In any case it would be valuable to explicitly describe the expected response of the BGP speaker in both cases.