Notification Message Support for BGP Graceful Restart
RFC 8538
Yes
No Objection
Note: This ballot was opened for revision 15 and is now closed.
Alvaro Retana Yes
Warren Kumari (was Discuss) No Objection
Thank you for addressing my concerns / the clue bat.
(Adam Roach; former steering group member) No Objection
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 steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
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 steering group member) No Objection
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 steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
(Ignas Bagdonas; former steering group member) No Objection
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 steering group member) No Objection
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 steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
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 steering group member) No Objection
(Terry Manderson; former steering group member) No Objection