Summary: Has enough positions to pass.
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.
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.
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.
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 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"?
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?