Notification Message Support for BGP Graceful Restart
RFC 8538

Note: This ballot was opened for revision 15 and is now closed.

Alvaro Retana Yes

Ignas Bagdonas No Objection

Comment (2018-05-24 for -15)
No email
send info
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.

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-05-23 for -15)
No email
send info
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.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2018-05-21 for -15)
No email
send info
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.

Benjamin Kaduk No Objection

Comment (2018-05-18 for -15)
No email
send info
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?

Suresh Krishnan No Objection

Warren Kumari (was Discuss) No Objection

Comment (2018-05-23 for -15)
No email
send info
Thank you for addressing my concerns / the clue bat.

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

Alexey Melnikov No Objection

(Eric Rescorla) No Objection

Adam Roach No Objection

Comment (2018-05-21 for -15)
No email
send info
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"?

Martin Vigoureux No Objection

Comment (2018-05-23 for -15)
No email
send info
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?