--- 1/draft-ietf-idr-bgp-gr-notification-12.txt 2017-06-15 19:13:16.747212017 -0700 +++ 2/draft-ietf-idr-bgp-gr-notification-13.txt 2017-06-15 19:13:16.767212492 -0700 @@ -1,22 +1,22 @@ Internet Engineering Task Force K. Patel Internet-Draft Arrcus Updates: 4724 (if approved) R. Fernando Intended status: Standards Track Cisco Systems -Expires: November 10, 2017 J. Scudder +Expires: December 17, 2017 J. Scudder J. Haas Juniper Networks - May 9, 2017 + June 15, 2017 Notification Message support for BGP Graceful Restart - draft-ietf-idr-bgp-gr-notification-12.txt + draft-ietf-idr-bgp-gr-notification-13.txt Abstract The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message or the Hold Time expires. This document also defines a new BGP NOTIFICATION Cease Error subcode whose effect is to request a full @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 10, 2017. + This Internet-Draft will expire on December 17, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -198,45 +198,46 @@ has not received the "N" bit. We note, however, that if it did so the effect would be as desired in any case, since according to [RFC4271] and [RFC4724] any NOTIFICATION message, whether recognized or not, results in a session reset. Thus the only negative effect to be expected from sending the Hard Reset to a peer that hasn't advertised compliance to this specification would be that the peer would be unable to properly log the associated information. Once the session is re-established, both BGP speakers SHOULD set their "Forwarding State" bit to 1. If the "Forwarding State" bit is - not set, then according to the procedures of [RFC4724] S. 4.2, the - relevant routes will be flushed, defeating the goals of this + not set, then according to the procedures of [RFC4724] section 4.2, + the relevant routes will be flushed, defeating the goals of this specification. 4.1. Rules for the Receiving Speaker - [RFC4724] S. 4.2 defines rules for the Receiving Speaker. These are - modified as follows. + [RFC4724] section 4.2 defines rules for the Receiving Speaker. These + are modified as follows. As part of this extension, routes from the peer previously marked as stale MUST NOT be deleted, until and unless the optional timer - mentioned in the final paragraph of [RFC4724] S. 4.2 expires, or + mentioned in the final paragraph of [RFC4724] section 4.2 expires, or unless a Hard Reset is performed. This supersedes the "consecutive - restarts" requirement in the third paragraph of [RFC4724] S. 4.2. + restarts" requirement in the third paragraph of [RFC4724] section + 4.2. - In addition to the rules already specified in [RFC4724] S. 4.2 for - how variations in the received Graceful Restart Capability should be - interpreted (the paragraph that begins "Once the session is re- + In addition to the rules already specified in [RFC4724] section 4.2 + for how variations in the received Graceful Restart Capability should + be interpreted (the paragraph that begins "Once the session is re- established..."), if the Graceful Notification ("N") bit is not set in the newly received Graceful Restart Capability, no new actions are triggered on the Receiving Speaker -- in particular, a clear "N" bit does not trigger deletion of stale routes. Other than these modifications, the rules for the Receiving Speaker - are as specified in [RFC4724] S. 4.2. + are as specified in [RFC4724] section 4.2. 5. Acknowledgements The authors would like to thank Jim Uttaro for the suggestion, and Emmanuel Baccelli, Bruno Decraene, Chris Hall, Paul Mattes and Robert Raszuk for their review and comments. 6. IANA Considerations IANA has temporarily assigned subcode 9, named "Hard Reset", in the