IETF Logo Mail Archive

Re: Graceful restart comment

Enke Chen <enke@redback.com> Mon, 29 April 2002 19:57 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17274 for <idr-archive@ietf.org>; Mon, 29 Apr 2002 15:57:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6FF7591228; Mon, 29 Apr 2002 15:57:02 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45FCA9122A; Mon, 29 Apr 2002 15:57:02 -0400 (EDT)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47E2F91228 for <idr@trapdoor.merit.edu>; Mon, 29 Apr 2002 15:57:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2CFB05DED7; Mon, 29 Apr 2002 15:57:01 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id E1FBB5DE4C for <idr@merit.edu>; Mon, 29 Apr 2002 15:57:00 -0400 (EDT)
Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 383F0F2C52; Mon, 29 Apr 2002 12:57:00 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 4509F15D3C1; Mon, 29 Apr 2002 12:56:59 -0700 (PDT)
To: Jeffrey Haas <jhaas@nexthop.com>
Cc: idr@merit.edu, enke@redback.com
Subject: Re: Graceful restart comment
In-Reply-To: Message from Jeffrey Haas <jhaas@nexthop.com> of "Mon, 29 Apr 2002 12:00:08 EDT." <20020429120008.A21737@nexthop.com>
Date: Mon, 29 Apr 2002 12:56:58 -0700
From: Enke Chen <enke@redback.com>
Message-Id: <20020429195659.4509F15D3C1@popserv1.redback.com>
Sender: owner-idr@merit.edu
Precedence: bulk

Hi, Jeffrey:

> Date: Mon, 29 Apr 2002 12:00:08 -0400
> From: Jeffrey Haas <jhaas@nexthop.com>
> To: idr@merit.edu
> Subject: Graceful restart comment
> Message-ID: <20020429120008.A21737@nexthop.com>
> 
> One of the cirumstances that a graceful restart would be useful is
> for a software upgrade where the box is really "gracefully" going down.
> However, the graceful restart specification requires a TCP reset
> to signal that the peer is going down and graceful restart is to
> be applied.
> 
> Wouldn't it be cleaner if a NOTIFICATION with a particular subcode
> is used for the case where the speaker is intentionally requesting
> a graceful restart?

A NOTIFICATION message has traditionally meant the "non-graceful"
restart, and both the sender and the receiver of the message would
clear the related RIB. I do not think that we should change the
semantics of NOTIFICATION.

---------------------
6. BGP Error Handling

   When any of the conditions described here are detected, a
   NOTIFICATION message with the indicated Error Code, Error Subcode,
   and Data fields is sent, and the BGP connection is closed. If no
   Error Subcode is specified, then a zero must be used.

   The phrase "the BGP connection is closed" means that the transport
   protocol connection has been closed, the associated Adj-RIB-In has
   been cleared, and that all resources for that BGP connection have
   been deallocated. Entries in the Loc-RIB associated with the remote
   peer are marked as invalid. The fact that the routes have become
   invalid is passed to other BGP peers before the routes are deleted
   from the system.
---------------------

-- Enke

v2.23.0 | Report a Bug | By Email