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

Enke Chen <enkechen@cisco.com> Fri, 21 April 2017 16:22 UTC

Return-Path: <enkechen@cisco.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 BFC2F12946D for <idr@ietfa.amsl.com>; Fri, 21 Apr 2017 09:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 iKhuaT-m8mpj for <idr@ietfa.amsl.com>; Fri, 21 Apr 2017 09:22:49 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB80129A92 for <idr@ietf.org>; Fri, 21 Apr 2017 09:22:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3164; q=dns/txt; s=iport; t=1492791764; x=1494001364; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=dfXS+cMx1Nq/ktD34QDxGmOINIHt/yA0HHW/6tPksXs=; b=DSG/4jxcZ8jnlGEc0Z5mLR+pCOlv8Yu/WwLsvrItnEgqEETFBznaM31y ohQOtdicIWNQ6sTvOpgVot7zvLOQXEEAqIizfULV4Z/9R8eS/MfSNjC2p ndrOnicpBar0b6hxCZlju36p1Xl32ayxOAO8T+w27IUPq7ZZa8oYqg3Lt A=;
X-IronPort-AV: E=Sophos;i="5.37,230,1488844800"; d="scan'208";a="233990791"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2017 16:22:43 +0000
Received: from [10.82.178.208] ([10.82.178.208]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3LGMf2E019826; Fri, 21 Apr 2017 16:22:42 GMT
To: Job Snijders <job@instituut.net>
References: <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> <32C0B4EE-6241-49F9-97F2-7107AC68678D@juniper.net> <e513849d-f895-0499-7bf4-5ecb24cadab7@cisco.com> <4CE4AF1E-0C80-423E-B19D-5750FCAFAD89@juniper.net> <23283_1492759950_58F9B58E_23283_375_1_53C29892C857584299CBF5D05346208A31CC352B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421084638.l6pbvtznfsxnq2wy@Vurt.local> <23291_1492766305_58F9CE61_23291_9725_1_53C29892C857584299CBF5D05346208A31CC399E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421095839.sralcy7aos5mzzic@Vurt.local>
Cc: bruno.decraene@orange.com, Hares Susan <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, Enke Chen <enkechen@cisco.com>
From: Enke Chen <enkechen@cisco.com>
Message-ID: <d57ed214-945a-54b8-e04f-cb8610f789e4@cisco.com>
Date: Fri, 21 Apr 2017 09:22:41 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170421095839.sralcy7aos5mzzic@Vurt.local>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/DWFUdNvzrzv60e6NKbcRL2fiJoE>
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: Fri, 21 Apr 2017 16:22:52 -0000

Job,

IMO the most important point from the discussion is that any BGP extension
or behavior change must be backward compatible, which this document is lacking
or even missing.  After more than 20 years of BGP deployment, the world is no
longer "green field" any more.

Regards,  -- Enke

On 4/21/17 2:58 AM, Job Snijders wrote:
> On Fri, Apr 21, 2017 at 09:18:24AM +0000, bruno.decraene@orange.com wrote:
>>  > 
>>  > So, going forward, any IDR proposal that requires a change to any
>>  > provision system is a no-go?
>>  
>> It's not about a no-go. It's about understanding and considering the
>> tradeoffs.
> 
> Bruno, through this thread I have learned:
> 
>     - Release notes are not read, and it is unreasonable to expect
>       people to read them.
>     - Software will not be tested prior to deployment, not even to see
>       whether it boots.
>     - We cannot expected staggered software deployments, people will
>       upgrade all their BGP speakers at the same time (again, without
>       testing the software).
>     - Any change to a provisioning system is an insurmountable
>       imposition.
> 
> I'm sure you appreciate how these new insights will affect all future
> IDR work. I assure you that if such weak rethoric continues to be
> admitted as valid justifications for lethargy, this will affect IDR's
> productivty the coming years.
> 
> If you want to play the game of 'tradeoffs have to be made', I have not
> seen any appreciation in this thread for the cost on the Internet as a
> whole resulting from insecure defaults. Robert Raszuk even went as far
> to argue that we'd be doing the "little guys" (surely that was not meant
> in a belligerent way) a favor by allowing insecure defaults to persist. 
> 
> I theorize that for instance this outage was the result of a 'fail open'
> rather then 'fail closed' (as proposed in bgp-reject) implmentation
> choice. See https://www.theregister.co.uk/2015/06/12/level_3_down_after_routing_through_malaysia_like_idiots/
> or https://bgpmon.net/massive-route-leak-cause-internet-slowdown/
> 
> Outages like these affect everyone, whether they were a directly
> involved party or indirectly involved. Did you notice this event in your
> own network? Or perhaps you did notice it because payment terminals in
> some countries stopped working?
> 
> The BGP Default-Free Zone is composed of roughly 55,000 autonomous
> systems operated by as many organisations, who are densily
> interconnected with each other through milions of EBGP sessions. When DC
> equipment is connected to Internet, or when a CLI-style makes accidents
> easy, or when a lack of education results in a common misconfiguration,
> there should be checks and balances in place to dampen the negative
> effects on the Internet as a whole. The Internet Engineering Task Force
> (notice the 'Internet' in IETF) has a responsiblity to promote and
> define safe and secure default behaviours.
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>