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
- Re: as4bytes - 4byte speaker receiving new* attri… Enke Chen
- Re: as4bytes - 4byte speaker receiving new* attri… Jeffrey Haas
- Re: as4bytes - 4byte speaker receiving new* attri… Jeffrey Haas
- Re: as4bytes - 4byte speaker receiving new* attri… Enke Chen
- as4bytes - 4byte speaker receiving new* attribute… Jeffrey Haas
- Re: Another suggestion for draft-ietf-idr-bgp4-12… Enke Chen
- Re: Another suggestion for draft-ietf-idr-bgp4-12… Jeffrey Haas
- Re: Another suggestion for draft-ietf-idr-bgp4-12… Jeffrey Haas
- Re: Another suggestion for draft-ietf-idr-bgp4-12… Enke Chen
- Re: Suggested changes to bgp4 draft for maximum p… Enke Chen
- Re: AS-wide Unique BGP Identifier Enke Chen
- Re: A Question about Tie breaking rules (draft-ie… Enke Chen
- Re: Maximum Prefix Limit Enke Chen
- Re: IDR WG Last Call Jeffrey Haas
- Re: IDR WG Last Call Susan Hares
- Re: IDR WG Last Call Susan Hares
- Re: IDR WG Last Call Russ White
- Re: IDR WG Last Call Enke Chen
- Re: IDR WG Last Call Jeffrey Haas
- Re: IDR WG Last Call Enke Chen
- Re: processing order of reach/unreach in rfc2858b… Alex Zinin
- Re: processing order of reach/unreach in rfc2858b… Jeffrey Haas
- Re: processing order of reach/unreach in rfc2858b… Enke Chen
- Re: Graceful restart comment Enke Chen
- Re: Graceful restart comment Gargi Nalawade
- Re: Graceful restart comment Jeffrey Haas
- Re: Graceful restart comment Pedro Roque Marques
- Re: Graceful restart comment Jeffrey Haas
- Re: Graceful restart comment Pedro Roque Marques
- Re: Graceful restart comment Jeffrey Haas
- Re: Graceful restart comment Jeffrey Haas
- Re: Graceful restart comment Kaarthik Sivakumar
- Re: Graceful restart comment Manav Bhatia
- Re: admin dist/gp spec proposal Enke Chen
- Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-… Enke Chen