Last Call Review of draft-ietf-idr-bgp-enhanced-route-refresh-06
review-ietf-idr-bgp-enhanced-route-refresh-06-secdir-lc-zhang-2014-06-05-00

Request Review of draft-ietf-idr-bgp-enhanced-route-refresh
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-06-03
Requested 2014-05-22
Other Reviews Genart Last Call review of -06 by Peter Yee (diff)
Genart Last Call review of -06 by Peter Yee (diff)
Review State Completed
Reviewer Dacheng Zhang
Review review-ietf-idr-bgp-enhanced-route-refresh-06-secdir-lc-zhang-2014-06-05
Posted at https://www.ietf.org/mail-archive/web/secdir/current/msg04829.html
Reviewed rev. 06 (document currently at 10)
Review result Has Nits
Draft last updated 2014-06-05
Review closed: 2014-06-05

Review
review-ietf-idr-bgp-enhanced-route-refresh-06-secdir-lc-zhang-2014-06-05

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This short document tries to enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. In order to achieve this, the "Reserved" field of the ROUTE-REFRESH message is redefined to indicate the beginning and the ending of a route refresh. I agree this extension will not introduce new security issues to the BGP protocol.

The document is clear. I consider it ready with a few issues:

I suggest defining how a BGP speaker should handle a EoRR without receiving the associated BoRR especially when the peer does not support graceful start. 

The description in the last paragraph of section 4 is not very clear. It would be better to briefly explain why the introduced procedures can simplify the interaction with the BGP Graceful Restart. In addition, the EOR and EoR messages (the typos of EoRR?) mentioned in this paragraph are not defined elsewhere. 

Cheers

Dacheng