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

[Robert Raszuk <[e-mail]>]

> If this doesn't make sense,

No one said here that it does not make sense. All comments so far are
rather about few points:

-  what real problem does it solve
-  should it apply to all address families or just 1/1 & 2/1 and all
profiles of BGP use
-  if done should it be silent ? (**)
-  should routes still be in BGP Adj_RIB_In and be sent by BMP (further
hiding the issue)


> why was it chosen for IOS XR back in the early 00ds?

Because 3 first major customers of XR said they prefer AF centric BGP
config and to have such policy for eBGP route announcement. As XR was not
deployed anywhere making that default was zero pain for anyone.

** Making route ineligible for best path and local RIB insertion is one
thing. But if you also are using say "add-paths  all" I would not be
surprised if those bgp implementation which care less if the route is
inserted in RIB and FIB before propagation would advertise it anyway to
iBGP peers (**) making even bigger mess in your network.

- - -

Besides to make sure the BGP policy is there before route is annouced or
accepted very is much simpler way. It is not about changing default, mess
with 100s of corner cases in the code. BGP configuration parser may just
not allow to configure "activate" under a given neighbor in selected (or
all) AFs if policy is not there. Done and makes everyone happy ! On upgrade
to new OS optionally you can still run fine with auto-addition of this
proposed "bgp insecure-mode" global bgp config line.


Example:

router bgp 65000

neighbor  192.168.1.1 remote-as 65001
address-family ipv4 unicast

neighbor 192.168.1.1 activate

                                          ^^^^^^^^^

!!! COMMAND NOT ACCEPTED .. ACTIVATE NOT ALLOWED BEFORE POLICY FOR EBGP
PEER IS SET.

//R

On Sun, Apr 23, 2017 at 2:56 PM, Mikael Abrahamsson <[e-mail]>
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.
>
> 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]
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>