Notification Message Support for BGP Graceful Restart
draft-ietf-idr-bgp-gr-notification-16
Yes
(Alvaro Retana)
No Objection
(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Eric Rescorla)
(Mirja Kühlewind)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 15 and is now closed.
Warren Kumari
(was Discuss)
No Objection
Comment
(2018-05-23 for -15)
Unknown
Thank you for addressing my concerns / the clue bat.
Alvaro Retana Former IESG member
Yes
Yes
(for -15)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2018-05-21 for -15)
Unknown
Thanks for your work on this document. I have only one very small question to ask. §4: > When a BGP speaker resets its session due to a HOLDTIME expiry, it > should generate the relevant BGP NOTIFICATION message as mentioned in Is this intended to be "should" or "SHOULD"?
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -15)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -15)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2018-05-23 for -15)
Unknown
Please consider using the boilerplate from RFC 8174 instead of 2119. There are multiple lower case instances of normative keywords; the 8174 boilerplate is designed to handle that.
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-05-18 for -15)
Unknown
The table in Section 5.1 suggests that nesting a Hard Reset in a Hard Reset is a supported operation. When would it make sense to do so/should this be forbidden?
Deborah Brungard Former IESG member
No Objection
No Objection
(for -15)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(for -15)
Unknown
Ignas Bagdonas Former IESG member
No Objection
No Objection
(2018-05-24 for -15)
Unknown
Thank you for this document, it specifies a practical mechanism for increasing overall BGP state stability. A nit - interworking with RFC7606 error handling may be mentioned in the case of error resulting in disabling the offending AFI.
Martin Vigoureux Former IESG member
No Objection
No Objection
(2018-05-23 for -15)
Unknown
Hello, primarily, I strongly support Benjamin's COMMENT. Section 3.1 is confusing and one may not understand the exact format of the NOTIFICATION to send in the context of this draft. minor comment: Isn't the use of "protocol" in "BGP protocol" redundant?
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -15)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2018-05-21 for -15)
Unknown
Is there a pointer to a formal definition for "full session reset" that you could provide at the end of this text? At a high level, this document can be summed up as follows. When a BGP session is reset, both speakers operate as "Receiving Speakers" according to [RFC4724], meaning they retain each other's routes. This is also true for HOLDTIME expiration. The functionality can be defeated using a "Hard Reset" subcode for the BGP NOTIFICATION Cease Error code. If a Hard Reset is used, a full session reset is performed.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -15)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -15)
Unknown