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 <brian.peter.dickson@gmail.com> Sat, 29 April 2017 00:05 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C39129529 for <idr@ietfa.amsl.com>; Fri, 28 Apr 2017 17:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQE_9qVZA24D for <idr@ietfa.amsl.com>; Fri, 28 Apr 2017 17:05:03 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3917129421 for <idr@ietf.org>; Fri, 28 Apr 2017 17:02:27 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id 70so12341261ita.0 for <idr@ietf.org>; Fri, 28 Apr 2017 17:02:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=peiL0mMZKOc/BbKvJbhl5qxqr7p9fA1+xbiOlayAKR8=; b=jZjSCmhCrJD3GXsdCVz7972yx38dsaBqEooJC/IZCAEUNYh1dku0BlwlrmqPgBw6OK FzyGA6WucuYgTMQQQ6tH12569RXIPGEqECzeA4CdvMpshXPAel+GrN9OFxqmkZksMnmq EJ4O3DQ3czyUbLMf7QQLFYBYjpbwwdX5cUrjkbzNh9ltO/74mlQEvDbvVgUuZ4FWsLiv MdezAr5G1EIEFTqUb4oauXFE0eDTLeu1vIQ5mFsD4wbNhDdNBCg9DrRfiBMRVX2dsjbF lWxv4vsMFpP7KQp0rCcgooJaRubZB+pDugcTgTE03F+NJavX088AEQE05J+JB6Ig6bY1 N2pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=peiL0mMZKOc/BbKvJbhl5qxqr7p9fA1+xbiOlayAKR8=; b=uFRyPsUv+88rfgdheGOKT6Y4s6T5JqrBPT8Bm83JT6XoizGztqnhfi+8k/VzSU0siv jU9cVRbZt6+AaXNSSfV/tbStlPbV1G+d2Cw6jpksMm169ujlRJs+++v3b+c3aRtb+hiC DvAx1By89wYIWqvGZckzQUNvOkpO9jlGwdiBywDJ0W7yc5mq2jh1iqKehEOhb5qWN+EM pGDiI0fcIl8Zi543lT7xL9gI2azbRratX7wt+d7r7sF801IpqSWAgb8wPaADgc95svmz Hc8ynw2Oa/NFNSm2u3Ov5nn7VEZE+qxuIscKSX+CyE20C5CXysQhRhreRCGq7UNWEvW4 g1dQ==
X-Gm-Message-State: AN3rC/561NuyX3e4pmQ8MfmEfO41HijGOrZ//RSITtBpFLHP+1IUcMpG sL5oUX8SZABwi1TAcpnX4/lfvl6YYQ==
X-Received: by 10.36.53.12 with SMTP id k12mr12798266ita.15.1493424147327; Fri, 28 Apr 2017 17:02:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.90.77 with HTTP; Fri, 28 Apr 2017 17:02:26 -0700 (PDT)
In-Reply-To: <m2o9vg6snc.wl-randy@psg.com>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <9047A5A0-ED12-43C2-B2C5-D2A71CBB4373@arrcus.com> <D51D46A7.A9732%acee@cisco.com> <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net> <D95C67A4-AEBF-400B-A360-61C342FD6E4A@arrcus.com> <CA+b+ER=hq0=JNRfF8VA76_aqeRMBCeyQm5aTbapysXGTgaGS_g@mail.gmail.com> <CAL9jLaakVACiZKjk6XUi9mwkrCRsPqONUQmrTBCN7V43y+RtrQ@mail.gmail.com> <m2y3uk7h8p.wl-randy@psg.com> <CAL9jLaZXqA8-LnAdNOfhCQA+pq1fh1site_shSH+-gH0hCNeqQ@mail.gmail.com> <m2o9vg6snc.wl-randy@psg.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 28 Apr 2017 17:02:26 -0700
Message-ID: <CAH1iCirW2qnmXyGQb5Db0UYjKhODhbeRxdZEGCWfiQRjWnkn5w@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Cc: Christopher Morrow <morrowc.lists@gmail.com>, Interminable Discussion Room <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a114abf94ccf148054e42e798
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/PwAwfeB3gQhlHW6mniXgcRmZue0>
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-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Apr 2017 00:05:07 -0000

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 <randy@psg.com>; 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>