Re: Graceful restart comment

Jeffrey Haas <jhaas@nexthop.com> Mon, 29 April 2002 21:23 UTC

Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20396 for <idr-archive@ietf.org>; Mon, 29 Apr 2002 17:23:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2780C91232; Mon, 29 Apr 2002 17:22:47 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDB1B91233; Mon, 29 Apr 2002 17:22:46 -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 DF44C91232 for <idr@trapdoor.merit.edu>; Mon, 29 Apr 2002 17:22:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B209D5DED4; Mon, 29 Apr 2002 17:22:45 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 5A95C5DDAD for <idr@merit.edu>; Mon, 29 Apr 2002 17:22:45 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g3TLMYh13885; Mon, 29 Apr 2002 17:22:34 -0400 (EDT) (envelope-from jhaas@nexthop.com)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g3TLMVO13878; Mon, 29 Apr 2002 17:22:31 -0400 (EDT) (envelope-from jhaas@nexthop.com)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g3TLMVw00585; Mon, 29 Apr 2002 17:22:31 -0400 (EDT)
Date: Mon, 29 Apr 2002 17:22:31 -0400
From: Jeffrey Haas <jhaas@nexthop.com>
To: Pedro Roque Marques <roque@juniper.net>
Cc: Gargi Nalawade <gargi@cisco.com>, Enke Chen <enke@redback.com>, idr@merit.edu
Subject: Re: Graceful restart comment
Message-ID: <20020429172231.G21276@nexthop.com>
References: <20020429195659.4509F15D3C1@popserv1.redback.com> <3CCDA914.92FE8548@cisco.com> <20020429162659.F21276@nexthop.com> <200204292058.g3TKw4r95825@roque-bsd.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200204292058.g3TKw4r95825@roque-bsd.juniper.net>; from roque@juniper.net on Mon, Apr 29, 2002 at 01:58:04PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: owner-idr@merit.edu
Precedence: bulk

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,

Turn your wayback machine to the IDR list when we had the leaking
confederation segments incident killing parts of the Internet. :-)

The specific circumstances I have in mind are where we have a well-formed
packet, but the information is semantically incorrect, discard the
PDU.

> Accepting bad routing information is usually much harder to debug than
> not accepting information...

Hence the reason for telling your peer that you're doing this.

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... if your
> neighbor is sending you packets for an NLRI that it hasn't negociated,
> chances are that there is something else wrong with it.

RFC 2858, section 6, paragraph 1. :-)

Mind you, I don't really have a problem with the portion I just cited,
but implementing that without having dynamic capabilities nor 
some sort of informational pushback is asking for your OAM people to
put your head on a plate. :-)

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies