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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/