draft-ietf-idr-bgp-gr-notification-07.txt   draft-ietf-idr-bgp-gr-notification-08.txt 
Network Working Group K. Patel Internet Engineering Task Force K. Patel
Internet-Draft R. Fernando Internet-Draft R. Fernando
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 9, 2016 J. Scudder Expires: June 12, 2017 J. Scudder
J. Haas J. Haas
Juniper Networks Juniper Networks
June 7, 2016 December 9, 2016
Notification Message support for BGP Graceful Restart Notification Message support for BGP Graceful Restart
draft-ietf-idr-bgp-gr-notification-07.txt draft-ietf-idr-bgp-gr-notification-08.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 to prevent BGP speakers supporting NOTIFICATION Cease Error subcode whose effect is to request a full
the extension defined in this document from performing a Graceful session restart instead of a Graceful Restart.
Restart.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 9, 2016. This Internet-Draft will expire on June 12, 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 19 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . 4 3.2. Receiving a Hard Reset . . . . . . . . . . . . . . . . . 5
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
skipping to change at page 3, line 47 skipping to change at page 3, line 47
Restart Flags: Restart Flags:
This field contains bit flags relating to restart. This field contains bit flags relating to restart.
0 1 2 3 0 1 2 3
+-+-+-+-+ +-+-+-+-+
|R|N| | |R|N| |
+-+-+-+-+ +-+-+-+-+
The most significant ("Restart State", or "R") bit is defined in
[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: Flags for Address Family:
This field contains bit flags relating to routes that were This field contains bit flags relating to routes that were
advertised with the given AFI and SAFI. advertised with the given Address Family Identifier (AFI)
and Subsequent Address Family Identifier (SAFI).
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F|N| Reserved | |F|N| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The usage of second most significant bit "N" (which was defined in a The usage of second most significant bit "N" (which was defined in a
previous draft version of this specification) is deprecated. This previous draft version of this specification) is deprecated. This
bit MUST be advertised as 0 and MUST be ignored upon receipt. bit MUST be advertised as 0 and MUST be ignored upon receipt.
skipping to change at page 5, line 47 skipping to change at page 6, line 5
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 timer mentioned in
the final paragraph of [RFC4724] S. 4.2 expires, or unless a Hard the final paragraph of [RFC4724] S. 4.2 expires, or unless a Hard
Reset is performed. This supersedes the "consecutive restarts" Reset is performed. This supersedes the "consecutive restarts"
requirement of [RFC4724] S. 4.2. 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
 End of changes. 10 change blocks. 
11 lines changed or deleted 14 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/