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
From: Job Snijders <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked], Hares Susan <[email-masked]>
Date: Thu, 20 Apr 2017 18:43:14 +0200
List-Id: Inter-Domain Routing <idr.ietf.org>

On Thu, Apr 20, 2017 at 08:57:07AM -0700, Enke Chen wrote:
> 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.

If these outages occur, they'll be quickly remedied since the service is
down, which provides incentive to either roll back or deploy a fix.  We
call this "fail hard". However, it is a failure mode that is
preventable, and vendors have a big role in this.

This outage only occurs if and only if there a sequence of process
errors that together are a cascading failure: e.g. absolutely no reading
or reviewing of the release notes by anyone in the organisation, no
taking heed of prior notifications (through for instance operational
mailing lists or customer/vendor meetings), no testing, and no staggered
canary deployment, all of this on top of reliance on the operating
system's default (whatever it may be) when there is no policy configured
for the EBGP peer. 

Why would anyone download a new software if one are not going to read
the release notes? Why would one upgrade a software if one does not know
what it will do? Any problems will be self-inflicted, and easy to remedy
by rolling back or configuring a policy.

Your perceived risk, which can be managed, does not legitimize a
continuation of inconsistent or insecure behaviour.

Kind regards,

Job