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 <[e-mail]>]

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 [e-mail]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.