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, 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
> ...
>