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

Hey Job,

At least I am not seeing that much of a problem for large networks with
bgp-reject. We can collectively go around and educate folks at various NOGs
what is coming well before any vendor publishes code with that change,

The worry is about little guys with one or two routers which never attend
NOGs and which in fact still want to send everything and get default out
from upstream. I am feeling a bit sorry to expose them to such pain
regardless if they use cisco, quagga, ubiquiti, goBGP, snaproute ... you
name it.

//R



On Thu, Apr 20, 2017 at 11:08 PM, Job Snijders <[e-mail]> wrote:

> So a change like bgp-reject will take many years to be deployed within a
> single network, how can that be reconciled with the perceived "surprise"?
>
> Kind regards,
>
> Job
>
> On Thu, 20 Apr 2017 at 23:05, Robert Raszuk <[e-mail]> wrote:
>
>> +
>>
>> c) deployment of new code release in large network takes months if not
>> years
>>
>> On Thu, Apr 20, 2017 at 11:03 PM, Enke Chen <[e-mail]> wrote:
>>
>>> Hi, John:
>>>
>>> It's not like the issues with software update are new :-)
>>>
>>> As we all know, there is a complete lack of uniformity (on a global
>>> scale) with
>>> the procedures for software update. As a result, a proposal that assumes
>>> certain
>>> procedures is bound to be incomplete, and will not work for some.
>>>
>>> As Eric summarized,
>>>
>>> ---
>>> Phasing in a change of behavior over several releases is not a practical
>>> solution, because:
>>>
>>> a) Customers will still be surprised when the default behavior finally
>>> changes, and
>>> b) Many customers won't deploy all the releases anyway.
>>> ---
>>>
>>> Thanks.  -- Enke
>>>
>>> On 4/20/17 11:40 AM, John G. Scudder wrote:
>>> > Enke,
>>> >
>>> > On Apr 20, 2017, at 11:57 AM, Enke Chen <[e-mail]> wrote:
>>> >
>>> >> It depends on the customer base and also how long the software has
>>> been deployed.
>>> >> Just think about the scenario that a large number of customers would
>>> lose network
>>> >> connectivity unexpectedly due to a default behavior change in the
>>> code. Such outages
>>> >> could keep happening to different customers for years to come.
>>> >>
>>> >> Perhaps, changing "impossible" to "impractical" :-)
>>> >
>>> > Various people have provided worked examples of how they think this
>>> change could be effected without causing the disruptions you warn of. I've
>>> pasted one example (from Jared) below. I haven't seen any response or
>>> acknowledgement from you, to those suggestions, just the repetition of your
>>> initial concern. I for one don't understand why you think a scheme such as
>>> Jared describes would be either "impossible" or "impractical".
>>> >
>>> > If you are unconvinced about the practicality of such a scheme, it
>>> would be great if you could describe why.
>>> >
>>> > Thanks,
>>> >
>>> > --John
>>> >
>>> > Jared's message:
>>> >> On Apr 20, 2017, at 9:40 AM, Jared Mauch <[e-mail]>
>>> wrote:
>>> >>
>>> >>
>>> >>> On Apr 19, 2017, at 6:26 PM, Robert Raszuk <[e-mail]>
>>> wrote:
>>> >>>
>>> >>> Keyur,
>>> >>>
>>> >>> You can not set "insecure mode" before you reload the OS as current
>>> OS does not have such knob. Unless you delay the deployment across N
>>> releases and enforce sequenced upgrade.
>>> >>
>>> >> Infact, this is the recommendation that I’ve provided to vendors that
>>> have expressed concerns.  There are many defaults that have not always been
>>> displayed, but things like IOS have “show run all” so you can see these.
>>> >>
>>> >> Something like the ‘bgp unsafe-ebgp-policy’ could be generated on
>>> their respective implementations.  I didn’t think that GROW/IDR needed to
>>> tell implementors this level of how to manage their release, so this does
>>> seem somewhat out of scope, but a concern I can see needs to be thought
>>> about.
>>> >>
>>> >>> The only way to prevent massive reachability failure upon reload due
>>> to complete silent bgp prefix drop is to configure inbound policy for all
>>> EBGP sessions before the reload and run with new image.
>>> >>
>>> >> Since we’re talking about how to operate a network:
>>> >> - People who are taking advantage of an undefined behavior will
>>> always be surprised
>>> >> - Vendors can take the N+1.x and N+2.x release strategy, where in N
>>> and N+1 they generate their equivalent of IOS-XR and the "bgp
>>> unsafe-ebgp-policy” policy to prevent their customers from breaking
>>> >> - In a release N+2(or more) that would become the “default”.
>>> >>
>>> >>> Of course this is all assuming that someone will read carefully the
>>> release notes :)
>>> >>
>>> >> Most people don’t, and I’ve always suggested to vendors they
>>> implement some sort of incremental approach to resolving this.
>>> >>
>>> >> What worries me is that there is a major incumbent provider who
>>> doesn’t see this as the serious (and well-documented) security issue that
>>> it is for those operating large networks.
>>> >>
>>> >>> If they do not the troubleshooting of this will be really painful !
>>> CE will see EBGP session as UP, will get all the routes and will send his
>>> routes. CE will have no clue if PE dropped or accepted his routes. Likewise
>>> on the other end .. Only imagine a network which has 10s of thousands of
>>> VPN CEs as Bruno mentioned and their provider not following all releases
>>> CEs are running.
>>> >>
>>> >>
>>> >> If they don’t know how to troubleshoot BGP, that isn’t the vendors
>>> fault.
>>> >>
>>> >>> At least doing it as part of OPEN msg will be immediately indicated
>>> to both ends.
>>> >>
>>> >> This is you promoting a different draft, I recommend another thread
>>> for that draft.
>>> >>
>>> >> - Jared
>>> > ...
>>> >
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>