Skip to main content

Last Call Review of draft-ietf-idr-bgp-gr-notification-15

Request Review of draft-ietf-idr-bgp-gr-notification
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-04-24
Requested 2018-04-10
Authors Keyur Patel , Rex Fernando , John Scudder , Jeffrey Haas
I-D 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
Request Last Call review on draft-ietf-idr-bgp-gr-notification by Ops Directorate Assigned
Reviewed revision 15 (document currently at 16)
Result Has nits
Completed 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:

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

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.