datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

Accelerated Routing Convergence for BGP Graceful Restart
draft-ietf-idr-enhanced-gr-04

Document type: Active Internet-Draft (idr WG)
Document stream: IETF
Last updated: 2014-02-05
Intended RFC status: Unknown
Other versions: plain text, pdf, html

IETF State: WG Document
Document shepherd: No shepherd assigned

IESG State: I-D Exists
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                          K. Patel
Internet Draft                                                  E. Chen
Intended Status: Standards Track                            R. Fernando
Expiration Date: August 6, 2014                           Cisco Systems
                                                             J. Scudder
                                                       Juniper Networks
                                                       February 5, 2014

        Accelerated Routing Convergence for BGP Graceful Restart
                   draft-ietf-idr-enhanced-gr-04.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 6, 2014.

Copyright Notice

   Copyright (c) 2014 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

Patel, Chen, Fernando and Scudder                               [Page 1]

Internet Draft      draft-ietf-idr-enhanced-gr-04.txt      February 2014

   described in the Simplified BSD License.

Abstract

   In this document we specify extensions to BGP graceful restart in
   order to avoid unnecessary transmission of the routing information
   preserved across a session restart, thus accelerating the routing
   convergence.

1. Introduction

   Currently the BGP graceful restart (GR) mechanism specified in
   [RFC4724] requires a complete re-advertisement of the routing
   information across a session restart, even though the routing
   information may have been preserved.  For example, as described in
   [RFC4724], the "Receiving Speaker" temporarily maintains the routes
   received from its neighbor with the GR Capability.  In addition, the
   "Restarting Speaker" may also be able to preserve routing information
   across a BGP restart by check-pointing routing information to a
   standby or secondary facility.

   Clearly the routing re-convergence post a session restart would be
   faster if we can avoid unnecessary transmission of the routing
   information preserved across a session restart. That is the goal of
   this document.

   In this document we specify extensions to BGP graceful restart in
   order to avoid unnecessary transmission of the routing information
   preserved across a session restart, thus accelerating the routing
   convergence.  More specifically, we describe a "version number" based
   mechanism for keeping track of the routing information across a
   session restart.  A new BGP message type, UPDATE-VERSION, is
   introduced for checkpointing the update version maintained for a
   neighbor.  We also introduce the Enhanced Graceful Restart
   Capability, and specify procedures for handling routing update across
   a session restart.

1.1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Patel, Chen, Fernando and Scudder                               [Page 2]

Internet Draft      draft-ietf-idr-enhanced-gr-04.txt      February 2014

2. Version Numbers for Routing Entities

   In order to avoid unnecessary transmission of the routing information
   preserved across a session restart, a BGP speaker will need to
   identify exactly "what" has been preserved by a remote speaker.

   The approach described here is "version number" (or "sequence

[include full document text]