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

[t.petch <[e-mail]>]

----- Original Message -----
From: "Jeffrey Haas" <[e-mail]>
To: "Jared Mauch" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, April 25, 2017 11:11 PM

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

[me too]

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

I see it as an operator bludgeon (good word that) to fix the problem
that some experience but without considering the impact thereof.

If you stop propagating routes, then you create black holes.  How many
black holes of what size will this change create?  How will those black
holes be detected?  What will be the damage to the Internet as a result?

I see no sign of this having been considered by those in favour of the
change and would expect this to be in the I-D before now.  Since the I-D
categorises this change as making BGP safer, I am asking how unsafe this
change is making BGP, at the same time.

Tom Petch

>
> 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
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>