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

[Job Snijders <[e-mail]>]

On Fri, Apr 21, 2017 at 07:32:29AM +0000, [e-mail] wrote:
> > From: John Scudder  Sent: Thursday, April 20, 2017 11:13 PM
> > 
>  > (as an individual contributor)
>  > 
>  > On Apr 20, 2017, at 5:03 PM, Enke Chen <[e-mail]> wrote:
>  > > It's not like the issues with software update are new :-)
>  > 
>  > Yes, exactly. That's why I'm so surprised by this discussion.
>  > 
>  > What I still see here is
>  > 
>  > - on one hand, a worked example showing how an implementor could
>  > roll out the functionality without causing heartburn for users. (My
>  > paraphrase: expose the default in the configuration. When upgrading
>  > old->new, automatically create the corresponding configuration
>  > line(s) to configure for legacy behavior.)
>  > 
>  > - on the other hand, general statements about how this is a hard problem.
>  > 
>  > I find the specific worked example more convincing.
> 
> Good point. Thanks for the useful contribution to the debate.
> 
> a) Regarding this specific point, could the draft refer to this point.
> e.g. add this requirement (if this is a requirement draft, which it
> looks like it when reading the first sentence of section 2) or add the
> solution (space) (if the draft define a solution).
> e.g. "When the BGP speaker is upgraded to those new default behavior,
> existing BGP sessions, configured using the old default, must be
> unaffected". Or whatever text.

You are adding complexity and increasing inconsistency rather then
reducing it.

> That is indeed the most significant deployment impact, so it's good
> that it can be addressed/included, rather than silently ignored.
> 
> b) Still, this draft introduce new deployment impact to all network
> operators using EBGP, including the ones not concerned with this
> problem space, as provisioning tools need to be updated prior to this
> deployment, otherwise provisioning would fails. Plus silently fails as
> the session is kept up, silently ignoring the route with no feedback
> to the EBGP peer). Plus for each plateform, they need to selectively
> handle both configurations depending on the software version of this
> plateform.

So, going forward, any IDR proposal that requires a change to any
provision system is a no-go?

For the record: NTT has many conditional clauses in their configuration
generation system to deal with configuration differences between
different versions of the software on the same platforms. This is
common. I do not believe you or anyone else operate your networks
without the accepting that different versions may have for example
different syntax.

I've already stated how the failure scenario can only occur after a
missteps in the process, and that outages are likely to be remedied
swiftly and permanently. I've also contributed a case where bgp-reject
actually reduces the duration of outages that would otherwise be
caused and prolonged if an insecure mode of operation is used.

Kind regards,

Job