draft-ietf-idr-bgp-gr-notification-08.txt   draft-ietf-idr-bgp-gr-notification-09.txt 
Internet Engineering Task Force K. Patel Internet Engineering Task Force K. Patel
Internet-Draft R. Fernando Internet-Draft Arrcus
Intended status: Standards Track Cisco Systems Intended status: Standards Track R. Fernando
Expires: June 12, 2017 J. Scudder Expires: June 13, 2017 Cisco Systems
J. Scudder
J. Haas J. Haas
Juniper Networks Juniper Networks
December 9, 2016 December 10, 2016
Notification Message support for BGP Graceful Restart Notification Message support for BGP Graceful Restart
draft-ietf-idr-bgp-gr-notification-08.txt draft-ietf-idr-bgp-gr-notification-09.txt
Abstract Abstract
The current BGP Graceful Restart mechanism limits the usage of BGP The current BGP Graceful Restart mechanism limits the usage of BGP
Graceful Restart to BGP protocol messages other than a BGP Graceful Restart to BGP protocol messages other than a BGP
NOTIFICATION message. This document defines an extension to the BGP NOTIFICATION message. This document defines an extension to the BGP
Graceful Restart that permits the Graceful Restart procedures to be Graceful Restart 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 40 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 June 12, 2017. This Internet-Draft will expire on June 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 18 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Modifications to BGP Graceful Restart Capability . . . . . . 3 2. Modifications to BGP Graceful Restart Capability . . . . . . 3
3. BGP Hard Reset Subcode . . . . . . . . . . . . . . . . . . . 4 3. BGP Hard Reset Subcode . . . . . . . . . . . . . . . . . . . 4
3.1. Sending a Hard Reset . . . . . . . . . . . . . . . . . . 4 3.1. Sending a Hard Reset . . . . . . . . . . . . . . . . . . 4
3.2. Receiving a Hard Reset . . . . . . . . . . . . . . . . . 5 3.2. Receiving a Hard Reset . . . . . . . . . . . . . . . . . 4
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Rules for the Receiving Speaker . . . . . . . . . . . . . 5 4.1. Rules for the Receiving Speaker . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
For many classes of errors, the BGP protocol must send a NOTIFICATION For many classes of errors, the BGP protocol must send a NOTIFICATION
message and reset the peering session to handle the error condition. message and reset the peering session to handle the error condition.
The BGP Graceful Restart extension defined in [RFC4724] requires that The BGP Graceful Restart extension defined in [RFC4724] requires that
normal BGP procedures defined in [RFC4271] be followed when a normal BGP procedures defined in [RFC4271] be followed when a
NOTIFICATION message is sent or received. This document defines an NOTIFICATION message is sent or received. This document defines an
extension to BGP Graceful Restart that permits the Graceful Restart extension to BGP Graceful Restart that permits the Graceful Restart
procedures to be performed when the BGP speaker receives a procedures to be performed when the BGP speaker receives a
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Modifications to BGP Graceful Restart Capability 2. Modifications to BGP Graceful Restart Capability
The BGP Graceful Restart Capability is augmented to signal the The BGP Graceful Restart Capability is augmented to signal the
Graceful Restart support for BGP NOTIFICATION messages. In Graceful Restart support for BGP NOTIFICATION messages. The Restart
particular, the Restart flags field and the Flags field for Address flags field is augmented as follows:
Family are augmented as follows:
+--------------------------------------------------+ +--------------------------------------------------+
| Restart Flags (4 bits) | | Restart Flags (4 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Restart Time in seconds (12 bits) | | Restart Time in seconds (12 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Address Family Identifier (16 bits) | | Address Family Identifier (16 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Subsequent Address Family Identifier (8 bits) | | Subsequent Address Family Identifier (8 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
skipping to change at page 4, line 10 skipping to change at page 4, line 9
[RFC4724]. [RFC4724].
The second most significant bit ("N") is defined as the BGP Graceful The second most significant bit ("N") is defined as the BGP Graceful
Notification bit, which is used to indicate Graceful Restart support Notification bit, which is used to indicate Graceful Restart support
for BGP NOTIFICATION messages. A BGP speaker indicates support for for BGP NOTIFICATION messages. A BGP speaker indicates support for
the procedures of this document, by advertising a Graceful Restart the procedures of this document, by advertising a Graceful Restart
Capability with its Graceful NOTIFICATION bit set (value 1). This Capability with its Graceful NOTIFICATION bit set (value 1). This
also implies support for the format for a BGP NOTIFICATION Cease also implies support for the format for a BGP NOTIFICATION Cease
message defined in [RFC4486]. message defined in [RFC4486].
Flags for Address Family:
This field contains bit flags relating to routes that were
advertised with the given Address Family Identifier (AFI)
and Subsequent Address Family Identifier (SAFI).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|N| Reserved |
+-+-+-+-+-+-+-+-+
The usage of second most significant bit "N" (which was defined in a
previous draft version of this specification) is deprecated. This
bit MUST be advertised as 0 and MUST be ignored upon receipt.
3. BGP Hard Reset Subcode 3. BGP Hard Reset Subcode
A new BGP NOTIFICATION Cease message subcode is defined known as the A new BGP NOTIFICATION Cease message subcode is defined known as the
BGP Hard Reset Subcode. The value of this subcode is discussed in BGP Hard Reset Subcode. The value of this subcode is discussed in
Section 6. We refer to a BGP NOTIFICATION Cease message with the Section 6. We refer to a BGP NOTIFICATION Cease message with the
Hard Reset subcode as a Hard Reset message, or just a Hard Reset. Hard Reset subcode as a Hard Reset message, or just a Hard Reset.
3.1. Sending a Hard Reset 3.1. Sending a Hard Reset
A Hard Reset message is used to indicate to a peer with which the A Hard Reset message is used to indicate to a peer with which the
skipping to change at page 5, line 50 skipping to change at page 5, line 33
not set, then according to the procedures of [RFC4724] S. 4.2, the not set, then according to the procedures of [RFC4724] S. 4.2, the
relevant routes will be flushed, defeating the goals of this 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] S. 4.2 defines rules for the Receiving Speaker. These are
modified as follows. 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 timer mentioned in stale MUST NOT be deleted, until and unless the optional timer
the final paragraph of [RFC4724] S. 4.2 expires, or unless a Hard mentioned in the final paragraph of [RFC4724] S. 4.2 expires, or
Reset is performed. This supersedes the "consecutive restarts" unless a Hard Reset is performed. This supersedes the "consecutive
requirement in the third paragraph of [RFC4724] S. 4.2. restarts" requirement in the third paragraph of [RFC4724] S. 4.2.
In addition to the rules already specified in [RFC4724] S. 4.2 for In addition to the rules already specified in [RFC4724] S. 4.2 for
how variations in the received Graceful Restart Capability should be how variations in the received Graceful Restart Capability should be
interpreted (the paragraph that begins "Once the session is re- 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] S. 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
Bruno Decraene, Chris Hall, Paul Mattes and Robert Raszuk for their Emmanuel Baccelli, Bruno Decraene, Chris Hall, Paul Mattes and Robert
review and comments. Raszuk for their review and comments.
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign a new subcode in the "BGP Cease IANA is requested to assign a new subcode in the "BGP Cease
NOTIFICATION message subcodes" registry. The suggested name for the NOTIFICATION message subcodes" registry. The suggested name for the
code point is "Hard Reset". The suggested value is 9. code point is "Hard Reset". The suggested value is 9.
7. Security Considerations 7. Security Considerations
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues
skipping to change at page 7, line 13 skipping to change at page 6, line 46
April 2006, <http://www.rfc-editor.org/info/rfc4486>. April 2006, <http://www.rfc-editor.org/info/rfc4486>.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
DOI 10.17487/RFC4724, January 2007, DOI 10.17487/RFC4724, January 2007,
<http://www.rfc-editor.org/info/rfc4724>. <http://www.rfc-editor.org/info/rfc4724>.
Authors' Addresses Authors' Addresses
Keyur Patel Keyur Patel
Cisco Systems Arrcus
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: keyupate@cisco.com
Email: keyur@arrcus.com
Rex Fernando Rex Fernando
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: rex@cisco.com Email: rex@cisco.com
John Scudder John Scudder
Juniper Networks Juniper Networks
 End of changes. 12 change blocks. 
39 lines changed or deleted 20 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/