[32237] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Trusting BGP sessions

daemon@ATHENA.MIT.EDU (Adrian Chadd)
Wed Nov 15 06:54:43 2000

Date: Wed, 15 Nov 2000 19:52:35 +0800
From: Adrian Chadd <adrian@creative.net.au>
To: Sean Donelan <sean@donelan.com>
Cc: nanog@merit.edu
Message-ID: <20001115195235.H35685@ewok.creative.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20001115074822.15909.cpmta@c004.sfo.cp.net>; from sean@donelan.com on Tue, Nov 14, 2000 at 11:48:22PM -0800
Errors-To: owner-nanog-outgoing@merit.edu


On Tue, Nov 14, 2000, Sean Donelan wrote:
> Question: historically have more routing snafus originated in "customer"
> BGP sessions or in "peer" BGP sessions?

Question: Historically have more routing snafus originated in filtered
BGP sessions or in unfiltered BGP sessions?

When I've been involved in network admin, filtering BGP sessions resulted
in less headaches than unfiltered BGP sessions (one problem I did have
was when I was being lazy with filtering and didn't require exact matches,
and a few downstreams decided they wanted to deaggregate aggressively..)

"Its too hard" doesn't cut it with me. I guess thats because I'm used
to having to write RFC compliant code, and there's no "real" RFC
compliance for configuration here..



2c,


Adrian

-- 
Adrian Chadd			"God: Damn! I left pot everywhere!
<adrian@creative.net.au>	  Now I'll have to create Republicans!"
				    - Bill Hicks


home help back first fref pref prev next nref lref last post