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

Jared Mauch <jared@puck.Nether.net> Fri, 21 April 2017 00:40 UTC

Return-Path: <jared@puck.nether.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 3A87A1293EB for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 17:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 iy2v3TYfCpkb for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 17:40:28 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 545C5128B4E for <idr@ietf.org>; Thu, 20 Apr 2017 17:40:28 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 162) id 11C0A5409AE; Thu, 20 Apr 2017 20:40:28 -0400 (EDT)
Date: Thu, 20 Apr 2017 20:40:28 -0400
From: Jared Mauch <jared@puck.Nether.net>
To: Eric C Rosen <erosen@juniper.net>
Cc: Tony Przygienda <tonysietf@gmail.com>, Brian Dickson <brian.peter.dickson@gmail.com>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20170421004028.GB22223@puck.nether.net>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <dc04fe80-f844-29b1-2676-8f2bbda0ecbe@juniper.net>
User-Agent: Mutt/1.8.0 (2017-02-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4MgIzWpum5QokyJt3r7b1y6cNso>
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 00:40:30 -0000

On Thu, Apr 20, 2017 at 04:00:39PM -0400, Eric C Rosen 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.

	I'm sure you are surprised that I might disagree here.

	I've experienced many software defects with disastrous side-effects,
this has not stopped the vendors from releasing junk code and people
running said-junk :-)

	What I see here is a complete capitulation of "this is hard,
lets go shopping".

> 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".

	Customers who do extensive testing still find issues that
are not found in labs, their own testing and limited deployments, does this
mean all software developers are out of a job as it's not worthwhile
to invest in development?

> Phasing in a change of behavior over several releases is not a practical
> solution, because:

I must disagre.

> a) Customers will still be surprised when the default behavior finally
> changes, and

	Customers who do no testing will always be surprised.  Customers who
do hopefully have a process for things, and while annoying may be less surprised.

	I recall when a vendor made /31's illegal on ethernet interfaces,
testing was done in my lab, but not with /31s, there was a gap.  This caused an
outage as it wiped the infrastructure links.  This wasn't release noted,
the vendor was briefly flogged and we moved on to more pressing defects.  This
is very similar to what John  and others suggested, you downgrade and try again
later.

> b) Many customers won't deploy all the releases anyway.

	I'm not sure the relevance here?  Some people upgrade often, some people
upgrade once a year, some never.  aka, Sky still blue.

> > 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.

	Text welcome.

> > 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.

	I disagree here, we can say "routing leaks are a problem, we should
minimize them".  This has been documented by IETF consensus in RFC7908.

	It may well be the various camps can't agree, because there are:

a) internet-at-large
   (who cares about the global reachability?  i do!)

b) datacenter
   (what i do on my own turf is my own problem! ztp ftw!)

c) enterprise
   (i'm paid to not rock the boat)

	What I'm hoping we can find consensus on is this is a problem
worthwhile fixing and IDR/GROW/IETF care enough to fix it vs the taylor swift
response of "we are never ever getting back together", "this is unsolvable",
"my default behavior is right", "i am a granite rock".

	To those who say BCP-38 is a failure because it's not 100%, you are
right and wrong.  Significant parts of networks are BCP-38 enabled, some parts
are not.  Losing sight of the goal is easy when you're throwing stones.

	Text mitigating what your concerns are is welcome to the authors alias
or the IDR/GROW lists.

	(note to self, unsubscribe from the other ietf lists you are not reading).

	- Jared
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.