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]>]

Hi, Mikael:

On 4/23/17 5:56 AM, Mikael Abrahamsson wrote:
> 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.

I think the premature session bring up is fixable. Your email has been forwarded to
the IOS development team.

> 
> 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?

I don't think that folks are saying this "deny all" doe not make sense.  When you
start a *new* software, certainly you are free to choose a default based on the most
up-to-date knowledge.

As I understand, that was the case for IOS XR as a new and separate software release.
 
Regards,  -- Enke