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

I'll see your $0.02, and raise you $0.02:

The argument against this being only a BCP, has to do with it being,
effectively, a safety issue.

A BCP is fine if the only person injured by making an error is the
operator.
However, this is clearly not the case.
(Or should be clear; PM me if you would like an explanation.)

The analogy would be the difference between general features and safety
features, on automobiles.

General features are a great way for auto manufacturers to differentiate
themselves.
And even SOME safety features can be such a differentiator, if they relate
to occupant protection alone (anti-whiplash headrests, side airbags).
However, ONE feature protects against collateral damage, and is MANDATED as
a result:

     The "brake pedal interlock".

The automobile mandate is both simple, and general: At some point in the
"operate the vehicle" process, the brake pedal must be depressed while
performing some other act, in order to put the vehicle in motion.
(The generality allows different mechanisms to be used on automatic vs
manual gear shifts: automatics require brake pedal to shift out of park;
manuals require brake pedal to start the engine.)
The brake pedal interlock is intended to prevent a number of use cases,
from accidental gear-shift by an adult, to unattended child operation, to
inadequately-trained young adult error.
The result in all of those cases is the same: unintended vehicle
motion/operation, with potential for third party loss of life.

This analogy fits very nicely with the -reject use case: in order to
prevent collateral damage (leaking the entire routing table), regardless of
who or why, the brake pedal (ingress/egress filter) must be applied before
the vehicle (BGP peering session) starts (begins).

For the same reason that government regulations mandate this, rather than
leaving it as a voluntary compliance thing, it behooves us (the standards
setting body for BGP) to make this mandatory.

There's nothing wrong with mandatory things having grandfather clauses
("any vehicle/router sold after such-and-such date"). However, that does
not preclude making the thing mandatory on a going-forward basis.

(Yes, analogies are always imperfect, but the sentiment here fits.)

Brian

On Wed, Apr 26, 2017 at 8:02 AM, John G. Scudder <[e-mail]> wrote:

> #include individual_contributor_disclaimer
>
> On Apr 26, 2017, at 10:08 AM, Christopher Morrow <[e-mail]>
> wrote:
>
> 'why not do it more!' has lots of reasons in both directions, but really
> that's not the point of this draft anyway.
>
>
> Seems that way to me, too.
>
> AFAICT:
>
> - bgp-reject is a case of trying to patch one special case, but an
> important special case. If the special case is important enough, the
> cost/benefit analysis works out.
> - Perfect is often the enemy of good.
> - The case Robert has just raised ("it's difficult for providers to filter
> their customers") is EXACTLY WHY bgp-reject exists, to put the onus on the
> customer to configure a filter.
> - Putting all our eggs in the basket of "perfect filtering by providers"
> is known from experience to be imprudent (see also: BCP-38).
>
> $0.02,
>
> --John
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>