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 16:43 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 4238E129AF6 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 09:43:20 -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 vDSE7BbaXxjg for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 09:43:18 -0700 (PDT)
Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com [209.85.128.178]) (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 B03A112422F for <idr@ietf.org>; Thu, 20 Apr 2017 09:43:18 -0700 (PDT)
Received: by mail-wr0-f178.google.com with SMTP id z109so39481216wrb.1 for <idr@ietf.org>; Thu, 20 Apr 2017 09:43:18 -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=zlzozVXMQHZE2/Y9IsGNtgPuTETEkFYRIxMCTdIC3Uk=; b=XnBTrVIeZTzDXgq7jZYuIx2s33cTX5DRLKNlizxbsiXC864hm1NKea9H+WU0P6YyCP DvsOhKhyVXl89OCPwMV6wbHCWtJ55rYXV6Ovbq0VEJGOn8yaxdLk4s1axWO5AaKR/ctD V66U0dShVBjNXmBYhXnP9eAJnqOR94x/ZKSXOZx1bktElUx+2omIkJfpemR0sUP4TnhP FCasDB6srj0ZzfDjJprwENDWaee1VmLrEqtJ65n2tAMqUZwneb1v8JfcKGX9muu0YbMV u9j4lrDhyKZYb6ciGbz2EaBzq66UWX4LDMnZjdcz60DfEIchhqZOTqyxYr5oWHv74I7a Eqaw==
X-Gm-Message-State: AN3rC/4mswQQGPS9DU91MkON5aX/4RB1nZZL0uQBiJiQFNDuOXINFtgH XgiSWCdbSTmMjtpbW1M=
X-Received: by 10.223.155.134 with SMTP id d6mr8153093wrc.113.1492706596974; Thu, 20 Apr 2017 09:43:16 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:4cc4:bdef:de0c:32e0]) by smtp.gmail.com with ESMTPSA id i144sm8708767wmf.13.2017.04.20.09.43.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 09:43:15 -0700 (PDT)
Date: Thu, 20 Apr 2017 18:43:14 +0200
From: Job Snijders <job@ntt.net>
To: Enke Chen <enkechen@cisco.com>
Cc: idr@ietf.org, Hares Susan <shares@ndzh.com>
Message-ID: <20170420164314.av26kcxvxglg4oet@hanna.meerval.net>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com> <68B29403-9AD9-4F06-9FE4-3F077E793D9F@puck.nether.net> <275cf744-1f64-bcbc-dabe-a47479921230@cisco.com> <20170420154142.lacvtplusepy3qcf@hanna.meerval.net> <b57162ec-f806-6e86-7713-58608f72c468@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <b57162ec-f806-6e86-7713-58608f72c468@cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/L2RnbwnCe7ZvqhaIV9BtygIFIJ4>
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 16:43:20 -0000

On Thu, Apr 20, 2017 at 08:57:07AM -0700, Enke Chen wrote:
> It depends on the customer base and also how long the software has
> been deployed. Just think about the scenario that a large number of
> customers would lose network connectivity unexpectedly due to a
> default behavior change in the code. Such outages could keep happening
> to different customers for years to come.

If these outages occur, they'll be quickly remedied since the service is
down, which provides incentive to either roll back or deploy a fix.  We
call this "fail hard". However, it is a failure mode that is
preventable, and vendors have a big role in this.

This outage only occurs if and only if there a sequence of process
errors that together are a cascading failure: e.g. absolutely no reading
or reviewing of the release notes by anyone in the organisation, no
taking heed of prior notifications (through for instance operational
mailing lists or customer/vendor meetings), no testing, and no staggered
canary deployment, all of this on top of reliance on the operating
system's default (whatever it may be) when there is no policy configured
for the EBGP peer. 

Why would anyone download a new software if one are not going to read
the release notes? Why would one upgrade a software if one does not know
what it will do? Any problems will be self-inflicted, and easy to remedy
by rolling back or configuring a policy.

Your perceived risk, which can be managed, does not legitimize a
continuation of inconsistent or insecure behaviour.

Kind regards,

Job