IETF Logo Mail Archive

Re: Graceful restart comment

Gargi Nalawade <gargi@cisco.com> Mon, 29 April 2002 20:12 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 QAA17988 for <idr-archive@ietf.org>; Mon, 29 Apr 2002 16:12:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 439C191227; Mon, 29 Apr 2002 16:12:07 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19A8E9122C; Mon, 29 Apr 2002 16:12:07 -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 2197D91227 for <idr@trapdoor.merit.edu>; Mon, 29 Apr 2002 16:12:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 065495DED8; Mon, 29 Apr 2002 16:12:06 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by segue.merit.edu (Postfix) with ESMTP id 7FA6A5DEB7 for <idr@merit.edu>; Mon, 29 Apr 2002 16:12:05 -0400 (EDT)
Received: from gargi-u5.cisco.com (gargi-u5.cisco.com [128.107.162.118]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3TKC4p6024265; Mon, 29 Apr 2002 13:12:05 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1]) by gargi-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA27096; Mon, 29 Apr 2002 13:12:04 -0700 (PDT)
Message-ID: <3CCDA914.92FE8548@cisco.com>
Date: Mon, 29 Apr 2002 13:12:04 -0700
From: Gargi Nalawade <gargi@cisco.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Enke Chen <enke@redback.com>
Cc: Jeffrey Haas <jhaas@nexthop.com>, idr@merit.edu
Subject: Re: Graceful restart comment
References: <20020429195659.4509F15D3C1@popserv1.redback.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I agree. The semantics of the NOTIFICATION message shouldnt be changed.
We seem to need a new message type, say an INFORMATIONAL message that
sends out information (notifies actually) to the peer, but doesnt 
necessarily cause a session reset.

-Gargi

Enke Chen wrote:
> 
> 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