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

[Greg Hankins <[e-mail]>]

I would like to add a couple of points to this discussion wearing my Nokia
Product Manager hat, and specifically as the person who is responsible
for managing this feature in our routing product line.

Our current BGP defaults in Nokia SR OS are insecure, and we are going to
implement this secure behavior because our customers are asking us for it.
Jared, Job, Mikael, Nick, and others have expressed their demand directly
on the GROW and IDR lists as operators, and we are seeing this same demand
as a router vendor too.

Defaults can be changed, it's not an impossible problem.  We put considerable
thought into changing configuration defaults a long time ago, and have
quite a bit of infrastructure support to make sure that changes are handled
correctly between different software releases during an upgrade or downgrade.
This allows us to change a command syntax or default behavior, and preserve
the intended functionality during various software change scenarios.  First,
we are strict about only introducing changes in major releases, unless for
example there is a security issue that needs to be addressed immediately.
Changing defaults or deprecating a command is a multiyear process that
spans multiple major releases, where we first mark a command as deprecated
and eventually remove it as a configuration option.  Our configuration
infrastructure knows how to translate commands between releases if the
syntax changed, or knows how to handle the cases where a default changes
or a command has been removed.

We also have a clear documentation process for communicating changes
to customers in multiple sections of release notes and documentation.
Each version of the release notes has a detailed section ordered by release
that describes new features, deprecated features, and changed or deprecated
commands.  As people have pointed out, operators may not read the available
information, but this doesn't mean that we don't make careful decisions
to change defaults when necessary.  In addition to the documentation,
we communicate roadmap information during customer interactions such as
EBC visits, planning meetings, training sessions, our customer conferences
and even over social media.

There are a number of scenarios we have considered for changing the insecure
default.  This is not an exhaustive list, but here are some examples:
o ISSU upgrade: old behavior
o ISSU downgrade: old behavior
o Reboot: new behavior
o Device that ships with preloaded software in 2017: old behavior
o Device that ships with preloaded software in the future: new behavior

Lastly, we explicitly added the option to the I-D to have a configuration
knob that configures the insecure behavior:
   o  A BGP speaker MAY provide a configuration option to disable the
      preceding behaviors, but it MUST implement them by default.
So if our customers want the old behavior, then we have a way for
them to enable it.

Greg

-- 
Greg Hankins <[e-mail]>