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
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-04-24
Requested 2018-04-10
Other 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
Secdir Last Call review of -15 by Yoav Nir
Review State Completed
Reviewer Qin Wu
Review review-ietf-idr-bgp-gr-notification-15-opsdir-lc-wu-2018-04-20
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/mo-H0N4Q3iGijVuqkJdgzws6VAw
Reviewed rev. 15
Review result Has Nits
Draft last updated 2018-04-20
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.