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

[Jeffrey Haas <[e-mail]>]

[I'm picking on this specific message to make my points.]

On Thu, Apr 20, 2017 at 09:40:13AM -0400, Jared Mauch 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.

My own thoughts on this draft haven't really changed since my original
comments at the microphone and in the halls after grow when it was
introduced:

- I'm supportive of this idea.  Safe by default is significantly better than
  unsafe by default.
- Moving to this as a new behavior will be extremely painful.  The word I've
  used internally has been "excruciating".

The tenor of this thread has really taken a disservice by conflating the
"this is a good idea" and the "we're going to make long-standing
implementations non-conformant" via the document status bludgeon.  The
latter isn't the fault of the document authors, but it's where I think we
took a wrong turn.

My personal recommendation is, presuming Alvaro and the IESG can live with
the particular bending of the meaning of BCP, that we go for that status.

This thread has generated a lot of good ideas about how to mitigate the pain
of moving existing implementations to support this practice.  It'd be good
if we summarize those some place.  Perhaps that place should be in the
RFC-to-be.

That said, even with some of the techniques involved, implementors will take
considerable pain in making these changes.  Defaults do change.  Impacted
operators get cranky with them and they cause outages.  Sane developers do
not tend to want to be the one tagged as responsible for the change because
the hate mail in the form of bug reports, regressions, broken tests that comes
back to them. :-)

I'm not the most sane of our developers and I've been spending time since
this was originally proposed in grow to allow such a change in our
implementation and mitigate the results.  The change is easy, the mitigation
is not.  And even I'm sensitive to how much pain this will be.  I dare say
my operator friends can't buy me quite enough beer to make it "easy".

But it's worth continuing the conversation.

-- Jeff