Last Call Review of draft-ietf-idr-bgp-gr-notification-15
review-ietf-idr-bgp-gr-notification-15-opsdir-lc-wu-2018-04-20-00

Request Review of draft-ietf-idr-bgp-gr-notification
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-04-24
Requested 2018-04-10
Draft last updated 2018-04-20
Completed reviews Rtgdir Early review of -03 by Mach Chen (diff)
Rtgdir Early review of -05 by Mach Chen (diff)
Rtgdir Early review of -07 by Emmanuel Baccelli (diff)
Rtgdir Telechat review of -15 by Bruno Decraene (diff)
Opsdir Last Call review of -15 by Qin Wu (diff)
Secdir Last Call review of -15 by Yoav Nir (diff)
Assignment Reviewer Qin Wu
State Completed
Review review-ietf-idr-bgp-gr-notification-15-opsdir-lc-wu-2018-04-20
Reviewed rev. 15 (document currently at 16)
Review result Has Nits
Review completed: 2018-04-20

Review
review-ietf-idr-bgp-gr-notification-15-opsdir-lc-wu-2018-04-20

I have reviewed this document as part of the Operational directorate¡¯s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.
Document reviewed:  draft-ietf-idr-bgp-gr-notification

Summary: 
This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message or the Hold Time expires.

Major issue: None
Minor issue: Editorial
1.Abstraction:
I am not familiar with history of RFC4724 and this document. I am wondering why not relax BGP graceful restart and apply usage of BGP graceful restart message to all BGP protocols messages rather than introduce a new flag within restart flags? Why not make bis document to update RFC4724? 

2.Abstraction:
How session restart is different session reset or the session is fully terminated? Do we use hard reset subcode to indicate those features separately? If they are same things, please make sure to use consistent terminology in the document.
3. Section 2, 3rd paragraph
Why we use a different bit instead ¡°R¡± bit to indicate graceful restart support for BGP notification message.
4. Section 2, last paragraph
Can you give an example what are these new parameters and how these parameters apply? How these parameters are related to relevant routes?
5.Section 3.1 said:
¡°
In short, the Hard
   Reset encapsulates another NOTIFICATION message in its data portion.

¡±
It looks one Notification message is embedded into another notification message? Is there any example for that. Also it is not clear to me what do you mean by as appropriate for in section 3.1 last paragraph? Would it be great to add more text to explain the usage of subcode or add reference to point to section 5 and point 5.2.
6.Section 4.1, 2nd paragraph
I am wondering whether the proposed procedures and rules are back compatible with the procedure and rule defined in RFC4724? 
7.Section 5.1
Can you provide definition of Graceful Cease in the terminology section? How Graceful cease is different from Graceful restart since I am confused.