Early Review of draft-ietf-idr-bgp-extended-messages-11

Request Review of draft-ietf-idr-bgp-extended-messages
Requested rev. no specific revision (document currently at 36)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2015-09-08
Requested 2015-08-25
Authors Randy Bush, Keyur Patel, David Ward
Draft last updated 2015-09-08
Completed reviews Rtgdir Early review of -11 by Brian Weis (diff)
Genart Last Call review of -33 by Paul Kyzivat (diff)
Opsdir Last Call review of -33 by Jouni Korhonen (diff)
Secdir Last Call review of -35 by Rich Salz (diff)
Rtgdir Telechat review of -33 by Himanshu Shah (diff)
Assignment Reviewer Brian Weis 
State Completed
Review review-ietf-idr-bgp-extended-messages-11-rtgdir-early-weis-2015-09-08
Reviewed rev. 11 (document currently at 36)
Review result Has Issues
Review completed: 2015-09-08



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 ​<



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



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


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.