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

Job Snijders <> Fri, 21 April 2017 08:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83FC81294F4 for <>; Fri, 21 Apr 2017 01:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xc-olre6IT-1 for <>; Fri, 21 Apr 2017 01:46:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E5C7129476 for <>; Fri, 21 Apr 2017 01:46:42 -0700 (PDT)
Received: by with SMTP id r190so11447160wme.1 for <>; Fri, 21 Apr 2017 01:46:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=20wzRskGOJAlwrpeeIqZkUZMzXdY3e3UizxThsIpXT8=; b=b3sxf3qAFIIhIkBGhedF5hzYN7oO1c3mFAL+B/+ZtwJGrH87AYMG8kPx6/fUY9LWoL +4TP08xADHSCuxJjWfrrcYLWT3KUVQfaSOPbt4jSG1kzZm00xxYA3azLWr/48cABV/K7 je31KNO3BGKlqSWbLvoqIJYwG+mL8XgvqCuy2MBxN0kUUEtOR8Y/G7rWFWF/C5bmIhLA pbijTLcUK5EZ4ub0YEkhlWlboqP0r/7yMf8OI4qC8EaPTXDJ35ONGIvRvgpMdAiDv8Ov Ct9G66tkSRA6ZvyP39gN7AQCDb2Jv5Ye9Je0H8PwFtpBGSq/+gkZmPQHUY/Colv2snf8 NV3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=20wzRskGOJAlwrpeeIqZkUZMzXdY3e3UizxThsIpXT8=; b=kUToZMsRiJDkI/ryf/7sihsxZ3OhRI9pd6TWRLBeA81EbfwO/RHmX3dXS9gc/xFpRy TjzfzEloekCYteBzPESWOAiVrP29d3C+DaGx67KAZN+cO7OZX8VZDH0VKlVbkaPWX9Y/ dJ0Az9M3TZ+eTYAtG4Yopu/GFCPgA8+Okc9/YeaDJwk+V8b233+fxB3LGCIuvyvXZTpR RtjLDaz73Vsuc8WcjNnroZDe/JB8HEAsccZERPJCT1VLtyJV642D3QZOTvHA05s3LjQ6 wlpt2qcHw1SuhQRl/8vOgPV4Spzb++wJOGhUCfRmoSLZqje1Jwdo7Qr6KznBqfJKToNW CWHg==
X-Gm-Message-State: AN3rC/57LC6qNZk4r6WFexAKiJHqdpW50cDJR7K4NLQE9HAF6VsjNfR7 05MSXAWDBEbL2g==
X-Received: by with SMTP id o5mr47337edo.93.1492764400667; Fri, 21 Apr 2017 01:46:40 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:154d:67d1:53a6:3be]) by with ESMTPSA id f37sm249455ede.4.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 01:46:39 -0700 (PDT)
Date: Fri, 21 Apr 2017 10:46:38 +0200
From: Job Snijders <>
Cc: John Scudder <>, "" <>, Hares Susan <>
Message-ID: <20170421084638.l6pbvtznfsxnq2wy@Vurt.local>
References: <> <> <> <> <> <> <> <> <> <23283_1492759950_58F9B58E_23283_375_1_53C29892C857584299CBF5D05346208A31CC352B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <23283_1492759950_58F9B58E_23283_375_1_53C29892C857584299CBF5D05346208A31CC352B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
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: Fri, 21 Apr 2017 08:46:44 -0000

On Fri, Apr 21, 2017 at 07:32:29AM +0000, wrote:
> > From: John Scudder  Sent: Thursday, April 20, 2017 11:13 PM
> > 
>  > (as an individual contributor)
>  > 
>  > On Apr 20, 2017, at 5:03 PM, Enke Chen <> wrote:
>  > > It's not like the issues with software update are new :-)
>  > 
>  > Yes, exactly. That's why I'm so surprised by this discussion.
>  > 
>  > What I still see here is
>  > 
>  > - on one hand, a worked example showing how an implementor could
>  > roll out the functionality without causing heartburn for users. (My
>  > paraphrase: expose the default in the configuration. When upgrading
>  > old->new, automatically create the corresponding configuration
>  > line(s) to configure for legacy behavior.)
>  > 
>  > - on the other hand, general statements about how this is a hard problem.
>  > 
>  > I find the specific worked example more convincing.
> Good point. Thanks for the useful contribution to the debate.
> a) Regarding this specific point, could the draft refer to this point.
> e.g. add this requirement (if this is a requirement draft, which it
> looks like it when reading the first sentence of section 2) or add the
> solution (space) (if the draft define a solution).
> e.g. "When the BGP speaker is upgraded to those new default behavior,
> existing BGP sessions, configured using the old default, must be
> unaffected". Or whatever text.

You are adding complexity and increasing inconsistency rather then
reducing it.

> That is indeed the most significant deployment impact, so it's good
> that it can be addressed/included, rather than silently ignored.
> b) Still, this draft introduce new deployment impact to all network
> operators using EBGP, including the ones not concerned with this
> problem space, as provisioning tools need to be updated prior to this
> deployment, otherwise provisioning would fails. Plus silently fails as
> the session is kept up, silently ignoring the route with no feedback
> to the EBGP peer). Plus for each plateform, they need to selectively
> handle both configurations depending on the software version of this
> plateform.

So, going forward, any IDR proposal that requires a change to any
provision system is a no-go?

For the record: NTT has many conditional clauses in their configuration
generation system to deal with configuration differences between
different versions of the software on the same platforms. This is
common. I do not believe you or anyone else operate your networks
without the accepting that different versions may have for example
different syntax.

I've already stated how the failure scenario can only occur after a
missteps in the process, and that outages are likely to be remedied
swiftly and permanently. I've also contributed a case where bgp-reject
actually reduces the duration of outages that would otherwise be
caused and prolonged if an insecure mode of operation is used.

Kind regards,