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 <job@ntt.net> Thu, 20 April 2017 09:50 UTC

Return-Path: <job@instituut.net>
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 4C9C212EC2B for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 02:50:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level:
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no
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 HhtyX37ALS1q for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 02:50:50 -0700 (PDT)
Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6269F12EC4E for <idr@ietf.org>; Thu, 20 Apr 2017 02:50:35 -0700 (PDT)
Received: by mail-wr0-f181.google.com with SMTP id z109so31917898wrb.1 for <idr@ietf.org>; Thu, 20 Apr 2017 02:50:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=/ESPjmJZCnsHw9//2S0imsanxDvpTam/p2jIsv0wAQo=; b=M/XssooH6koNjHexvmJEBAE7fUs8k70unHOxoidfhefvtbVLiPv7w4WhMDHkAvPAII z/0LBBnX3DC1ydlD4su34IX9RpuSTLKcupt0innjtGgBTPGtLATl9L/qkPQY73n9BrcM xv0EXov9Ra/wvPdYNdtJW34VJyrC7bZH4ZueLWejGZKiSc8FlR2Ei5MKyWTj5BNoEzFr GRygv6eKUXSYUlI/5PbXst1idcXilzpFvoW2pnsBoiGOcjA+wrt6j9Ni4hzhrNhVl3RP 12BzB9kNnys+iRRX3Sk8CYfLSav4+ZISAyz+GHGJlQ1ablnOzWURHXdlwVoTXm4e8rIt OuXQ==
X-Gm-Message-State: AN3rC/6JzeGAK/iJt9ueKGfcipEv5bd2S9MB3lKrwnK9an/y/5iazziW 2VIYzYs2+OFtVw==
X-Received: by 10.223.163.17 with SMTP id c17mr6625234wrb.186.1492681833809; Thu, 20 Apr 2017 02:50:33 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:4cc4:bdef:de0c:32e0]) by smtp.gmail.com with ESMTPSA id w126sm22449070wmb.25.2017.04.20.02.50.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 02:50:32 -0700 (PDT)
Date: Thu, 20 Apr 2017 11:50:31 +0200
From: Job Snijders <job@ntt.net>
To: bruno.decraene@orange.com
Cc: Enke Chen <enkechen@cisco.com>, Hares Susan <shares@ndzh.com>, idr wg <idr@ietf.org>
Message-ID: <20170420095031.oxtnocmjkt3zavge@hanna.meerval.net>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com> <CA+b+ERnRz8BEO3mb1fnsDPoiL6Wxjdfw9vQPbyODNEa+xCJdnw@mail.gmail.com> <D51D67E4.A9782%acee@cisco.com> <AF07526F-F08B-4084-937B-A9A2D2DD2813@juniper.net> <2b8a94bb-4f40-6c1d-05ff-9cf11ad93646@cisco.com> <20170420090941.c5yi72mzleto64ph@hanna.meerval.net> <25911_1492681251_58F88222_25911_625_1_53C29892C857584299CBF5D05346208A31CBFF52@OPEXCLILM21.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <25911_1492681251_58F88222_25911_625_1_53C29892C857584299CBF5D05346208A31CBFF52@OPEXCLILM21.corporate.adroot.infra.ftgroup>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XituRbPckk9SwLB8ThvkbNeg5ts>
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, 20 Apr 2017 09:50:52 -0000

On Thu, Apr 20, 2017 at 09:40:50AM +0000, bruno.decraene@orange.com wrote:
> > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders  > Sent: Thursday, April 20, 2017 11:10 AM
> > 
>  > On Wed, Apr 19, 2017 at 04:34:10PM -0700, Enke Chen wrote:
>  > > I had "in this case" with the statement "the default can not be changed".
>  > > The reason is that the behavior change may completely cutoff connectivity
>  > > in this case.
>  > 
>  > And very soon after the cutoff a customer may elect to roll back the
>  > change and read the release notes!
>  > 
>  > The 'complete cutoff' only occurs after a specific sequence of events
>  > which together would represent a cascading failure in due diligence.
> 
> The document is asking network operators which have correctly
> configured their network to retrofit the configuration of 1000s of
> EBGP configurations, in order to accommodate some operators which are
> not capable of correctly configuring their EBGP session.

No, the beneficiaries of this draft are the users of Internet at large,
not just 'incapable operators'.

It is ludicrous to argue that an operator has 1000s of EBGP
configurations but would not be able to accomodate any changes in the
software's behaviour. A parallel can be drawn with the 'IOS
small-servers' which over time were disabled by default, rather then
enabled. I don't recall any outcry over that either.

> Plus the solution is asking those later operators to do a
> configuration, while the assumption is that they can't be trusted to
> correctly configured their EBGP session. Why do you think that they
> won't just copy/past 1 additional line of configuration in order
> automatically distribute all the routes for each new EBGP session?

Ah, there may lay our misunderstaanding. We do not blame operators or
make any judgement on whether they can be trusted or not. 

The problem is that there are some platforms which _immediately_
activate a line of configuration after you press enter, and a BGP
session may already come up before you get to the configuration line
which restricts what should be announced or accepted. This draft
rectifies that behaviour to 'start closed' (i guess this is a variant of
the "fail closed" concept) rather then 'start open', or differently
phrase: one should not start insecure.

Kind regards,

Job