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> Thu, 20 April 2017 16:07 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 E774B129487 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 09:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 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] 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 3ToqaReg4ZEo for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 09:07:36 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 80250127871 for <idr@ietf.org>; Thu, 20 Apr 2017 09:07:36 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 162) id 0E71E540D51; Thu, 20 Apr 2017 12:07:36 -0400 (EDT)
Date: Thu, 20 Apr 2017 12:07:36 -0400
From: Jared Mauch <jared@puck.Nether.net>
To: Enke Chen <enkechen@cisco.com>, aretana@cisco.com
Cc: Job Snijders <job@ntt.net>, Jared Mauch <jared@puck.nether.net>, Hares Susan <shares@ndzh.com>, idr@ietf.org
Message-ID: <20170420160736.GB15676@puck.nether.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>
User-Agent: Mutt/1.8.0 (2017-02-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QVjVE3aH-kGlcsY73gSYjCIT26o>
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:07:38 -0000

On Thu, Apr 20, 2017 at 08:57:07AM -0700, Enke Chen wrote:
> Job,
> 
> 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.
> 
> Perhaps, changing "impossible" to "impractical" :-)

	I'd like to call it well-considered. :-)

	I'm operating a network with Juniper, NX-OS, IOS-XR, IOS-Classic, IOS-XE,
and various implementations that require custom policy to be implemented.

	There can be a path forward plotted that would prevent currently
deployed people from having issues, we're surely bright enough to do that.

	To make it clear: I don't want to break someones routers.

	I do want to make it harder for someone to leak a table when they
have a new router.

	I don't belive the bar should be high, it can be embedded in whatever
configuration/ZTP/automation/cut+paste template out there.  It could come
in the form of yang over netconf, or a DHCPv6/DHCPv4 option.  It could
come from a TXT record in DNS, or wahtever configuration method the vendor
invents that is new and unimagined by th WG today.

	I don't feel it requires updating 4271 to attain that goal, it's
clear implementors have seen a path to do this today without having
a concern with 4271, and I believe that Alvaro is wrong in the presumption
this document updates 4271.  (I'm also willing to be told that I'm too rough
for consensus :-).

	- Jared

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