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 <> Wed, 26 April 2017 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3790128792 for <>; Wed, 26 Apr 2017 11:07:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jb-29JYlToct for <>; Wed, 26 Apr 2017 11:07:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 102F7131560 for <>; Wed, 26 Apr 2017 11:07:48 -0700 (PDT)
Received: by with SMTP id p80so8007914iop.3 for <>; Wed, 26 Apr 2017 11:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y51uRM3cjfiD+9imNwe1BYybij/K5uvdnCyDGgwGegM=; b=RfhkEJejJpH+JHtdcNs2H14BhbT5OPwI7liOAGpBHa6rwGVNe+buyKmKaDDfSBo0Ws jn11Rglsm5jH9FDPbRhBS9BylhCEnZ2C0T55rdbXdv0IGq4bhrBL+woegTT1evXNzkUD GPN7sl5xmcuJJs3J3MyVUfXbUz4etl+RWsTfYWHgfc1G1HCWbz1BX3CIQ0PZxsUzhq7a F7y7yqKOt1Yhdhv2DYzzqJslXy4YZvFEanBGK7jabBWxQulgeNfCecRUer7GmK23NuKE 1R2KjX0s7FbsEm4PifbGcefNGN51WhHw+JJejMMnuyF6bGUw32kuNHax3GFDXObCb61G KtyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y51uRM3cjfiD+9imNwe1BYybij/K5uvdnCyDGgwGegM=; b=oe21IYAFCj2IEStPfIFkUjE20o4z7jhspWe+/+OLwP0/4mhAfUe2CLdaugpZ7Nhska ida1IJwHAw9T77C7s+E3lZ5D7YcghqUXeyJNJMV244cM9mQnteKO4eoppqMFFD9xsBhk kOE8cy67oYAPedZMM3jpVrOarfW6mvyIQXLgfOhXpSxJJT0rjF26RY0/4dEvo8wxz4Fj r1zQfpioogtmcj0ygkTFR4aEw9ORmA61QUPlluOpw7WA3da4GwuQXBqgxf0Ljqrh6TW3 SAHKy1hVAXwDrk5xnp7FeHggP3wi+2gxpCpcO0rugRSa/oPLms+fA+Ys+91ivsHtBdRR bOLQ==
X-Gm-Message-State: AN3rC/6qWBdsq8IDeEc1Khua/+VlMyxifKK3Iug95IMkIJVuKLUeqVBh dXr6jczq7WrBb0s+hcsB2i6OxI6wvg==
X-Received: by with SMTP id i12mr1061658ioa.225.1493230067291; Wed, 26 Apr 2017 11:07:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 26 Apr 2017 11:07:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <023e01d2be72$031ac180$> <20170426095547.GP25069@Space.Net> <> <> <> <20170426125417.GU25069@Space.Net> <> <> <>
From: Brian Dickson <>
Date: Wed, 26 Apr 2017 11:07:46 -0700
Message-ID: <>
To: "John G. Scudder" <>
Cc: Christopher Morrow <>, idr wg <>, Robert Raszuk <>
Content-Type: multipart/alternative; boundary="94eb2c0633e6baba6a054e15b7b1"
Archived-At: <>
Subject: 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
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Apr 2017 18:07:58 -0000

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


On Wed, Apr 26, 2017 at 8:02 AM, John G. Scudder <> wrote:

> #include individual_contributor_disclaimer
> On Apr 26, 2017, at 10:08 AM, Christopher Morrow <>
> 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.
> - 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