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 <> Thu, 20 April 2017 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E774B129487 for <>; Thu, 20 Apr 2017 09:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.203
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3ToqaReg4ZEo for <>; Thu, 20 Apr 2017 09:07:36 -0700 (PDT)
Received: from ( [IPv6:2001:418:3f4::5]) by (Postfix) with ESMTP id 80250127871 for <>; Thu, 20 Apr 2017 09:07:36 -0700 (PDT)
Received: by (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 <>
To: Enke Chen <>,
Cc: Job Snijders <>, Jared Mauch <>, Hares Susan <>,
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.8.0 (2017-02-23)
Archived-At: <>
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-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
clue++;      |  My statements are only mine.