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

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.