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

[Brian Dickson <[e-mail]>]

The analogy I would use next, is the US "national electrical code" (itself
a subset of the national fire code).

Specifically, the analogy would be how and when to use "new" NEC code,
which is basically: for new builds, or upgrades that "touch" deployed
infrastructure.
Anything already deployed is de-facto grandfathered, and does not need to
be brought up to code. (But may be by anyone who does not wish to burn to
death.)

And a specific example that fits the use-case of both "fail closed" (or
"open" for electrical circuits), AND the POLA: GFCI outlets.
(GFCI = ground fault circuit interrupt; if the ground connector has any
measurable current, the hot connector has its power turned off within one
"cycle".)

New GFCI outlets (things you wire into an outlet box, and into which
electrical devices get plugged), are REQUIRED to do the following:
- ship in the "tripped" state
- fail to engage unless wired and grounded correctly (engage = hit the
"reset" button to make the outlet electrically "live")

It is now literally impossible to improperly wire a GFCI in such a way that
it provides power without providing GFCI function.


How is does this compare to BGP, under the proposal?

In the specific use case of a new install out-of-the-box:
- configuring BGP globally is the equivalent to wiring an outlet
- configuring a neighbor/address family is the equivalent to hitting the
"reset" button (to try to enable the connection)
- if (and only if) there is a policy on the neighbor, can the BGP session
come up; if (and only if) the outlet is wired correctly can something
plugged in get power

How is this actually POLA?

In the current BGP world, if you configure a BGP neighbor, your router
attempts to bring up a session with the far end. If it succeeds, it
immediately sends/receives/propagates routes whether or not there is a
policy (plus, race condition!).
In the absence of a policy, for a novice engineer, this behavior is
surprising. (It was for me the first time I did it in 1995 (oops), and
others have shared similar experiences.)
Note also, that only when both parties have configured their respective
sessions does peering come up. If the first party forgot to apply policy,
they won't discover the error until the second party brings up their end,
which could be hours or days later.

If the scope of the proposal is limited in a reasonable manner (e.g.
address family, and/or new device, and/or built-in protections to upgraded
code, etc.), no more surprise-by-this-specific-operator-error.

The only "astonishment" should be that vendors (finally) provide code that
stops operators from shooting themselves in the head.
(Shooting the feet is still in the realm of operator error, such as
configured-but-ineffective policy logic.)

Vendors should implement appropriate warnings, of course, but that is a
per-vendor issue, rather than having a sane out-of-the-box behavior which
is consistent within and between vendors.

Brian

On Fri, Apr 28, 2017 at 4:04 PM, Randy Bush <[e-mail]> wrote:

> > POLA - principle of least resistance
>
> A is for astonishment
>
> > Setting a well known standard starting point really would be helpful
> > here.
>
> but the vendors will need to SERIOUSLY warn users affected by possible
> change for a number of years.  bill's bait and sushi could go from
> release 8 to 42 two years from now.
>
> randy
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>