Network Working Group H. Zhang
Internet-Draft HangZhou H3C Co. Limited
Updates: RFC 4724 (if approved) A. Retana
Intended status: Standards Track Cisco Systems, Inc.
Expires: September 26, 2013 March 25, 2013
Transitive BGP Graceful Restart
draft-zhang-idr-transitive-gr-02
Abstract
This document defines an extension to BGP Graceful Restart that
reduces the negative impact of multiple inter-connected routers
restarting. The proposed mechanism does not require any changes to
the BGP protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 May 18, 2013.
Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zhang & Retana Expires September 26, 2013 [Page 1]
Internet-Draft Transitive BGP GR March 25, 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Zhang & Retana Expires September 26, 2013 [Page 2]
Internet-Draft Transitive BGP GR March 25, 2013
1. Introduction
The BGP Graceful Restart [RFC4724] process defines a mechanism that a
restarting router can use with its non-restarting peers. The
existence of other restarting routers results in the use of the base
route exchange mechanism [RFC4271] with them, even if the forwarding
state has indeed been preserved for (and by) those peers during the
restart. As a result, traffic forwarding between restarting routers
is disrupted.
This document defines an extension to BGP Graceful Restart that
reduces the negative impact of multiple inter-connected restarting
routers. The proposed mechanism does not require any changes to the
BGP protocol.
The current process [RFC4724] states that routes from restarting
peers are to be removed from the local forwarding state when the non-
restarting peers converge (the End-of-RIB marker is received from all
of them). Assuming a simple topology:
NR1 - R2 - R3 - NR2
where NRx are non-restarting routers, Rx are restarting routers
and the lines between them represent BGP sessions.
There are two types of routes affected (from R2's point of view) by
the current process:
1. Routes that are only reachable through R3. These routes will be
removed from the forwarding table when the non-restarting routers
converge, and installed back in when the convergence with R3 is
done.
2. Routes that are reachable through both R3 and NR1. These routes
will first change to NR1 when the non-restarting routers
converge, and later back to R3 (assuming that is in fact still
datatracker.ietf.org