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 15:41 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 6B27113149E for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 08:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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, RCVD_IN_SORBS_SPAM=0.5] 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 QRVf5PO7eg3m for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 08:41:53 -0700 (PDT)
Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) (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 D64AE129AD2 for <idr@ietf.org>; Thu, 20 Apr 2017 08:41:46 -0700 (PDT)
Received: by mail-wr0-f172.google.com with SMTP id c55so38333274wrc.3 for <idr@ietf.org>; Thu, 20 Apr 2017 08:41:46 -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=s3hqa1eDmoiIJpbgpy3Nru8aPp+H38i2CbD6fKL1dJs=; b=OZYdRVAfTQh6PGqDYORsqOpi+diDAPSIAlDn6lRnuu3DAjLG+0kWOj/8kYTJ012wpc suuRCl1WIHNBdh4EfThQ6kj7Wnh92OS9hPmWquMytQyPLinkPS3qdh8we/BblqeMNRcg SnXvSVmKL8CCBSYn8y8AC4Xb1GB8mqjjk3LzByE5WMrvaMJWLw+25YaTq9SVLTYgqnGZ UCAS1t7pRQMy4eOPHlItgIJGYoDDw+C03oFHYhYPQfpQB6jDgEkgoOnDRQK/49ZfiQUf RR589vCa5QXBjMtq1ojQZ/JcAepoVpGAoj/ik8x96hzZBLloeoMmri/LttNPZlcZlxR9 1Qsg==
X-Gm-Message-State: AN3rC/4PSEHopBb4l0GNQTZgqOfL2uevVue1g8yaff6dww9Sq6Ddvywh EwIKdhNxr1Jsxg==
X-Received: by 10.223.154.240 with SMTP id a103mr3348315wrc.5.1492702905154; Thu, 20 Apr 2017 08:41:45 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:4cc4:bdef:de0c:32e0]) by smtp.gmail.com with ESMTPSA id i21sm8049245wrc.50.2017.04.20.08.41.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 08:41:43 -0700 (PDT)
Date: Thu, 20 Apr 2017 17:41:42 +0200
From: Job Snijders <job@ntt.net>
To: Enke Chen <enkechen@cisco.com>
Cc: Jared Mauch <jared@puck.nether.net>, Hares Susan <shares@ndzh.com>, idr@ietf.org
Message-ID: <20170420154142.lacvtplusepy3qcf@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <275cf744-1f64-bcbc-dabe-a47479921230@cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RUApekmQu5-0z-p4P6ZSY90Raoc>
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 15:41:55 -0000

On Thu, Apr 20, 2017 at 08:36:17AM -0700, Enke Chen wrote:
> If it is not obvious, let me state the I participate in IDR WG as an
> individual contributor, just like you do I suppose.
> 
> Let me rephrase what I said, for a code base with a large and diverse
> customer base I do not foresee any possibility for the default
> behavior change in this case. Again please treat it as my personal
> opinion.
> 
> I am certainly aware of other cases where the default behavior has
> been changed. But this one is different.  This case seems similar to
> the default behavior ("permit" or "deny") for an empty ACL.  Once the
> "permit" or "deny" is set in the code and is widely deployed for a
> long time, it is just not possible to make the switch between "permit"
> and "deny".

You say "it is not possible", however there are examples where it turned
out to be possible. At least one implementer confirmed on this list that
they plan to change their default.

Perhaps, "impossible" should be phrased as "unwilling".

Kind regards,

Job