IETF Logo Mail Archive

Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 27 April 2017 04:57 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDAB13159C for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 21:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkPd9aOcDYxI for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 21:57:15 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C1B13159B for <idr@ietf.org>; Wed, 26 Apr 2017 21:57:15 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id ABB18A6; Thu, 27 Apr 2017 06:57:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1493269032; bh=Ppw8LRQQp692dsFbmiZKY8a6Hb/J5QCXtI7wm4eBdcI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UV86uhjkVH/cW+04lwGrNqMMoJ86+ydbX5GCNnvOBcZrxQ/HiQBOJdiq++Cuge0oS FE2ocA5Dqh/Yb2Akc+JYWqoH60b70UueWxShCaIZnrmspF40edRh1Pm3yOXPM2rCXM TUBgKyqAdBKx5hiiG6VCqCY+glVlFdQb6bhB/iA8=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A60FEA4; Thu, 27 Apr 2017 06:57:12 +0200 (CEST)
Date: Thu, 27 Apr 2017 06:57:12 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Warren Kumari <warren@kumari.net>
cc: idr wg <idr@ietf.org>
In-Reply-To: <CAHw9_iKhRQpEGigqvqYoF0ca9D=-2VmESO8Fp4P_p1tZqpJgXQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1704270653291.5591@uplift.swm.pp.se>
References: <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net> <D95C67A4-AEBF-400B-A360-61C342FD6E4A@arrcus.com> <CA+b+ER=hq0=JNRfF8VA76_aqeRMBCeyQm5aTbapysXGTgaGS_g@mail.gmail.com> <50353B76-1323-4828-88D6-25954DA1E344@puck.nether.net> <20170425221104.GS30063@pfrc.org> <023e01d2be72$031ac180$4001a8c0@gateway.2wire.net> <20170426095547.GP25069@Space.Net> <CA+b+ERk4FxB4KQ3N0xtjV6uaQptd=EGKdpbKcpoL2TH41fVSYg@mail.gmail.com> <20170426113954.GA18318@puck.nether.net> <CA+b+ER=Ej7G1EEOQ7uBU-z7LeBAGNSfPkE5yGmo+z52ncKhVdg@mail.gmail.com> <20170426125417.GU25069@Space.Net> <CA+b+ERm1iDv3+GNk+N_gqjDWsd+E4QjmfhmwDN4vQVQVZ1EMpw@mail.gmail.com> <CAL9jLaabkYUO+7jsRbfZg1fXXLHXaWr88AxGyNF+AVTLquyxTQ@mail.gmail.com> <CAHw9_iKhRQpEGigqvqYoF0ca9D=-2VmESO8Fp4P_p1tZqpJgXQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9px2pS3ApAHrjPlB9D4EvnBpahI>
Subject: Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2017 04:57:18 -0000

On Wed, 26 Apr 2017, Warren Kumari wrote:

>
> I was turning up Global Naps as a peer, so I log on and type:
> router bgp 8120
> neighbor 192.0.2.1 peer-as 1784
>
> ... and, as I press enter, one of the sysadmin folk turns around and
> asks me to hand him a sharpie. While doing so I bump my coffee mug,
> spilling 3 week old coffee (and a very cool mold colony I was
> culturing) all over my desk. What with the cursing and running to find
> paper towels and similar I don't come back to the router for a minute
> or two... by which time I can mysteriously no longer reach it. Turns
> out that becoming transit between 2 (at the time) large providers over
> a T1 makes your router unavailable. Eventually BGP falls down (because
> keepalives get starved), and then, before you are able to login again,
> it comes up.

This is a perfect example from the real world why a fail-close design is 
needed. What you described, we all have happened to us if we've worked 
long enough in this field.

Trains have brakes that need air pressure to release them. If hose breaks, 
compressor breaks, whatever breaks, the brakes are applied.

A BGP session should never come up and pass prefixes any direction without 
a policy.

Oh btw, another story. I've had happen to me several times that all my 
sessions were flapped causing large outage, because I added or removed 
address family from a peer-group. Why is this still a thing? Why can't we 
dynamically add or remove address families from a running session?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email