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 <> Sun, 23 April 2017 12:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0363127978 for <>; Sun, 23 Apr 2017 05:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 89zRews7hMNi for <>; Sun, 23 Apr 2017 05:56:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 095FE126B71 for <>; Sun, 23 Apr 2017 05:56:08 -0700 (PDT)
Received: by (Postfix, from userid 501) id 70D12A5; Sun, 23 Apr 2017 14:56:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1492952165; bh=L5obmkARMK2UhO7VxpZaImjDTUy/IqWp2HX9GLBSYAg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=MpB3pIarf6xz/elOD0pQ78sIV+bcDZY3rdu5jumcH1KdJG5UPNOHyQ9O6627tthQE +BHoBf5jcPhf7i9rZJV3jf4e4drvSJLUdNRCWBN6ci/aGZbEWo7Oz++40ZsOuTTPbw 3iKSWn4FRjRtII86dvxvRwDMiVtqBFp46gQrzEfE=
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E98BA4; Sun, 23 Apr 2017 14:56:05 +0200 (CEST)
Date: Sun, 23 Apr 2017 14:56:05 +0200
From: Mikael Abrahamsson <>
To: Enke Chen <>
cc: "" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <23283_1492759950_58F9B58E_23283_375_1_53C29892C857584299CBF5D05346208A31CC352B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421084638.l6pbvtznfsxnq2wy@Vurt.local> <23291_1492766305_58F9CE61_23291_9725_1_53C29892C857584299CBF5D05346208A31CC399E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421095839.sralcy7aos5mzzic@Vurt.local> <>
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: <>
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-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 Apr 2017 12:56:11 -0000

On Fri, 21 Apr 2017, Enke Chen wrote:

> Job,
> IMO the most important point from the discussion is that any BGP extension
> or behavior change must be backward compatible, which this document is lacking
> or even missing.  After more than 20 years of BGP deployment, the world is no
> longer "green field" any more.

I have been involved in running core networks since late 90ties. I've 
deployed several vendors gear. Yes, going from IOS to IOS XR with the 
change to XR having default deny if there is no policy, that was a single 
occasion "oh", and then I knew that. The good part here is that it's 
failsafe "close", so that you don't announce anything by accident. In IOS 
you have to basically paste two lines at once, with the first line being 
the creation of the neighbor, the second line being shutdown. Then you can 
configure the rest. Otherwise there is a race condition in the immediacy 
of a per-line, immediate committing operating system such as IOS.

This is just bad design. It's "fail open" default. If you somehow fail to 
paste that second shutdown line, you're now fully-open, announcing and 
accepting all routes.

If IOS would be changing its defaults, the CLI line migration code could 
by default insert a PERMIT-ALL policy statement, or some other means where 
an upgrade would keep the behaviour of the box intact across operating 
system versions.

So I fully support draft-ietf-grow-bgp-reject-05 because it just makes 
more operational sense than the old default that for instance IOS 
implements. We need default fail-close, because it just creates less 
problems than default fail-open.

If this doesn't make sense, why was it chosen for IOS XR back in the early 

Mikael Abrahamsson    email: