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

[Job Snijders <[e-mail]>]

On Thu, Apr 20, 2017 at 09:40:50AM +0000, [e-mail] wrote:
> > From: Idr [mailto:[e-mail]] On Behalf Of Job Snijders  > Sent: Thursday, April 20, 2017 11:10 AM
> > 
>  > On Wed, Apr 19, 2017 at 04:34:10PM -0700, Enke Chen wrote:
>  > > I had "in this case" with the statement "the default can not be changed".
>  > > The reason is that the behavior change may completely cutoff connectivity
>  > > in this case.
>  > 
>  > And very soon after the cutoff a customer may elect to roll back the
>  > change and read the release notes!
>  > 
>  > The 'complete cutoff' only occurs after a specific sequence of events
>  > which together would represent a cascading failure in due diligence.
> 
> The document is asking network operators which have correctly
> configured their network to retrofit the configuration of 1000s of
> EBGP configurations, in order to accommodate some operators which are
> not capable of correctly configuring their EBGP session.

No, the beneficiaries of this draft are the users of Internet at large,
not just 'incapable operators'.

It is ludicrous to argue that an operator has 1000s of EBGP
configurations but would not be able to accomodate any changes in the
software's behaviour. A parallel can be drawn with the 'IOS
small-servers' which over time were disabled by default, rather then
enabled. I don't recall any outcry over that either.

> Plus the solution is asking those later operators to do a
> configuration, while the assumption is that they can't be trusted to
> correctly configured their EBGP session. Why do you think that they
> won't just copy/past 1 additional line of configuration in order
> automatically distribute all the routes for each new EBGP session?

Ah, there may lay our misunderstaanding. We do not blame operators or
make any judgement on whether they can be trusted or not. 

The problem is that there are some platforms which _immediately_
activate a line of configuration after you press enter, and a BGP
session may already come up before you get to the configuration line
which restricts what should be announced or accepted. This draft
rectifies that behaviour to 'start closed' (i guess this is a variant of
the "fail closed" concept) rather then 'start open', or differently
phrase: one should not start insecure.

Kind regards,

Job