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

[Enke Chen <[e-mail]>]

Job,

My personal opinion:

Vendors are *not* in the business of intentionally creating network outages :-)
Those that do may not stay in the business for long :-)

Regards,  -- Enke 

On 4/20/17 9:43 AM, Job Snijders wrote:
> 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
>