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

[Mikael Abrahamsson <[e-mail]>]

On Fri, 21 Apr 2017, Enke Chen wrote:

> Job,
>
> IMO the most important point from the discussion is that any BGP extension
> or behavior change must be backward compatible, which this document is lacking
> or even missing.  After more than 20 years of BGP deployment, the world is no
> longer "green field" any more.

I have been involved in running core networks since late 90ties. I've 
deployed several vendors gear. Yes, going from IOS to IOS XR with the 
change to XR having default deny if there is no policy, that was a single 
occasion "oh", and then I knew that. The good part here is that it's 
failsafe "close", so that you don't announce anything by accident. In IOS 
you have to basically paste two lines at once, with the first line being 
the creation of the neighbor, the second line being shutdown. Then you can 
configure the rest. Otherwise there is a race condition in the immediacy 
of a per-line, immediate committing operating system such as IOS.

This is just bad design. It's "fail open" default. If you somehow fail to 
paste that second shutdown line, you're now fully-open, announcing and 
accepting all routes.

If IOS would be changing its defaults, the CLI line migration code could 
by default insert a PERMIT-ALL policy statement, or some other means where 
an upgrade would keep the behaviour of the box intact across operating 
system versions.

So I fully support draft-ietf-grow-bgp-reject-05 because it just makes 
more operational sense than the old default that for instance IOS 
implements. We need default fail-close, because it just creates less 
problems than default fail-open.

If this doesn't make sense, why was it chosen for IOS XR back in the early 
00ds?

-- 
Mikael Abrahamsson    email: [e-mail]