Ballot for draft-ietf-idr-bgp-gr-notification
Yes
No Objection
Note: This ballot was opened for revision 15 and is now closed.
Thank you for addressing my concerns / the clue bat.
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"?
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.
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?
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.
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?
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.