IETF Logo Mail Archive

Re: Graceful restart comment

Manav Bhatia <manav@samsung.com> Tue, 07 May 2002 03:12 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA22682 for <idr-archive@nic.merit.edu>; Mon, 6 May 2002 23:12:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AEAE59120A; Mon, 6 May 2002 23:12:00 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80CC691214; Mon, 6 May 2002 23:12:00 -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 316239120A for <idr@trapdoor.merit.edu>; Mon, 6 May 2002 23:11:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AABC45DDDF; Mon, 6 May 2002 23:11:58 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from ep_mailout1 (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 488D75DD9D for <idr@merit.edu>; Mon, 6 May 2002 23:11:58 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GVQ00M010TU2H@mailout1.samsung.com> for idr@merit.edu; Tue, 07 May 2002 12:10:42 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GVQ00LC80TT9D@mailout1.samsung.com> for idr@merit.edu; Tue, 07 May 2002 12:10:42 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GVQ00J0Q0TFM6@mmp2.samsung.com> for idr@merit.edu; Tue, 07 May 2002 12:10:29 +0900 (KST)
Date: Tue, 07 May 2002 08:40:18 +0530
From: Manav Bhatia <manav@samsung.com>
Subject: Re: Graceful restart comment
To: Jeffrey Haas <jhaas@nexthop.com>, Pedro Roque Marques <roque@juniper.net>
Cc: Gargi Nalawade <gargi@cisco.com>, Enke Chen <enke@redback.com>, idr@merit.edu
Reply-To: Manav Bhatia <manav@samsung.com>
Message-id: <010c01c1f574$b8d39510$b4036c6b@sisodomain.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <20020429195659.4509F15D3C1@popserv1.redback.com> <3CCDA914.92FE8548@cisco.com> <20020429162659.F21276@nexthop.com> <200204292058.g3TKw4r95825@roque-bsd.juniper.net> <20020429172231.G21276@nexthop.com>
Sender: owner-idr@merit.edu
Precedence: bulk

Hi All,
I am sorry for opening up this thread after so long but i am just back to
work and i read these mails today itself :-)

----- Original Message -----
From: "Jeffrey Haas" <jhaas@nexthop.com>

| On Mon, Apr 29, 2002 at 01:58:04PM -0700, Pedro Roque Marques wrote:
| > If you have errors in a PDU the best thing to do is to tear down the
| > session not to selectivly ignore bits... if you can't trust your peer
| > to format updates correctly then you can't trust any of the nlri that
| > it has sent you.
|
| Pedro,
|
..
|
| Can you think of circumstances where your implementation will drop
| an update where it doesn't drop the peering session?
|
| > I can't think of any scenario where it is reasonable to discard
| > packets from the neighbor while maintaining the session up...

Yes there are circumstances when an implementation will drop an update
while it doesn't kill the peering session. One such case is when a speaker
receives an update and finds its local CLUSTER_ID in the cluster-list.

v2.23.0 | Report a Bug | By Email