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

Tony Przygienda <tonysietf@gmail.com> Thu, 20 April 2017 21:09 UTC

Return-Path: <tonysietf@gmail.com>
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 A40C21316C6 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 14:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LIn9kb5fpMiT for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 14:09:33 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 EE8951316C1 for <idr@ietf.org>; Thu, 20 Apr 2017 14:09:27 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id w64so2561956wma.0 for <idr@ietf.org>; Thu, 20 Apr 2017 14:09:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IsxR7mFYSLM4W8BcEuN84NILeSqjPJu2stnxV41kl84=; b=acxfb/ug+VSx0yIJLdI6ki4yYph2+S2bp/deZT91Q0lOLoqqml0/lYmBI1OlJoL7X9 uy+PzohSTKG5gauoB4WH8ySzzs82OWcidnVac2e7v1s060ymUoTUjSSM5bYmjjBfiUGw EdzdfZ+gaFLEetTP3amB0W+gBEqZOS1tAlGy82+baJ0umyNUEaWC7RXRfOHTPKo2FJqe XrZCvTVCKoru6Tz/oEoewIX85m4tYLOJensLEj1ZmZkBHY7pOeKY+RNj53BiCyo3IyFF Y9xpdz7Kl+D3Cz71J0ebrnVOrOACzFYYca0MTgb38K1EUiwWatJHce+UQR/AsEFYOQ+3 OnQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IsxR7mFYSLM4W8BcEuN84NILeSqjPJu2stnxV41kl84=; b=NRpA9cSy7aaL6gGK0PzLu1+erBzeRKtziwnga76be8kn7n000KzgPAqB1C2hgWBC/W skVXdTHR2FPvycZMBhPNL5GK/8QIkCnPri8+p0nxbEP4EHbJwUBKKQUyf374VMmPg/JV feOch0CyjiGlEqlzWZS0A8ywP5mv2LFBLdDd4UMplzM2IDEiR3V03kz2GA0VeiiDE/wY tSjqo04BxfqNk9NnsIgbeMznlqGcaFY9MW7YmBWoyviW+XyNUsQARIzdhQlTak531xWv VrmsVrsJXyfEVJQg0xbtjT3UKwqgdctXOn8W3M/W70aEAnNitj2gEdgdTPgb8fpQ/or/ 3m2g==
X-Gm-Message-State: AN3rC/7s0Z6QJ9Ka0IXzZ9ZVbaLuALVcGPmatp2kWsnezS4NeLp0sWV5 Yf0+qm7wkWxdOFxb42oyB3K16UyWWg==
X-Received: by 10.28.54.205 with SMTP id y74mr4784430wmh.93.1492722566572; Thu, 20 Apr 2017 14:09:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.136.9 with HTTP; Thu, 20 Apr 2017 14:08:45 -0700 (PDT)
In-Reply-To: <dc04fe80-f844-29b1-2676-8f2bbda0ecbe@juniper.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> <20170420160736.GB15676@puck.nether.net> <75AC1A50-3DF8-4852-8FC6-BC302B121946@cisco.com> <CAH1iCirf=ha1mrw8EUzPp34R-DF=4J+=aFyMwVn2udi1UKNifw@mail.gmail.com> <CA+wi2hMPYcwbNhHtuWKWUXb4Lg3x81p786yLqeNEHFV1okGRvg@mail.gmail.com> <dc04fe80-f844-29b1-2676-8f2bbda0ecbe@juniper.net>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Thu, 20 Apr 2017 14:08:45 -0700
Message-ID: <CA+wi2hMiC08RxUNtWbb3W7AE1ZyrA3vBogPd_PguKAbbBU6Asw@mail.gmail.com>
To: Eric C Rosen <erosen@juniper.net>
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a1143689a542f18054d9f8e65
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xUOX_xDfkhaG24_nfqRDmWx3Dd0>
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 21:09:36 -0000

amen ...

On Thu, Apr 20, 2017 at 1:00 PM, Eric C Rosen <erosen@juniper.net>; wrote:

> On 4/20/2017 2:24 PM, Tony Przygienda wrote:
>
>> Can't miss that food fight ;-)
>>
>
> It did seem to degenerate rapidly into "if you don't agree with my
> proposal, you don't care about security".  ;-(
>
> I agree with Enke that surprising your customers with a change in behavior
> due to altered defaults is generally considered to be a big no-no.
>
> When the customers complain about a change in behavior, it is not
> considered appropriate to respond with "it's not my fault, you should have
> read the release notes", or "it's not my fault that you don't know how to
> troubleshoot BGP", or "it's not my fault that you didn't do your due
> diligence".
>
> Phasing in a change of behavior over several releases is not a practical
> solution, because:
>
> a) Customers will still be surprised when the default behavior finally
> changes, and
> b) Many customers won't deploy all the releases anyway.
>
>
>> Having said that, I think this is BCP material at best and if this is a
>> BCP then
>>
>> i) a "backward compatibility a.k.a which end of the stick is sharp"
>> section is very advisable
>>
>
> I would agree that something more than "figure out how to configure the
> new release to behave like the old release" would be helpful.
>
> ii) the BCP should describe which customer segment is best served with
>> which default
>>
>>
> But then operators from different segments would have to get together to
> understand each others' requirements, and they'd have to respect each
> others' opinions as well.   I can't wait to see what happens when the
> "trust nobody" folks get together with the "zeroconfig plug and play" folks
> ;-)
>
> The dilemma is that there is a real security problem in certain
> environments, but the proposed solution seems to have unintended
> side-effects that are problematic.  Then the question becomes whether the
> benefits are worth the cost, and this is not really a question that can be
> resolved by IETF consensus.
>
>
>
>
>
>
>


-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky