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

[Brian Dickson <[e-mail]>]

For those not intimately familiar with non-Internet AFI/SAFI use cases (ie
other than 1/1 and 2/1), could someone explain which ASNs get used?

I am wondering if applying the "new rules" only when global ASNs (those not
reserved for private use) would be a suitable alternative to specific
AFI/SAFI combos?

And, to be clear, IMHO, the difference across AFI/SAFI should probably be
MUST vs SHOULD (or maybe MAY).

Also, don't at least some vendors have different code bases depending on
the use case, in which case the default could differ by code base?
E.g. ISP vs Enterprise vs (whatever other groupings/labels exist).

Plus, IMHO, a global knob to change the default is something that would be
wise to implement; I don't know whether recommending that belongs in the
document

Brian

On Sun, Apr 23, 2017 at 6:42 AM, Robert Raszuk <[e-mail]> wrote:

>
> > 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
>>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>