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

Joe Provo <jzp-idr@rsuc.gweep.net> Thu, 27 April 2017 22:54 UTC

Return-Path: <crimson@sidehack.sat.gweep.net>
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 C87A412955B for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 15:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Q5HwO5V856Kv for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 15:54:12 -0700 (PDT)
Received: from sidehack.sat.gweep.net (sidehack.sat.gweep.net [72.93.233.150]) by ietfa.amsl.com (Postfix) with SMTP id 5F463129BAB for <idr@ietf.org>; Thu, 27 Apr 2017 15:51:41 -0700 (PDT)
Received: (qmail 28703 invoked by uid 524); 27 Apr 2017 18:50:17 -0400
Date: Thu, 27 Apr 2017 18:50:17 -0400
From: Joe Provo <jzp-idr@rsuc.gweep.net>
To: Warren Kumari <warren@kumari.net>
Cc: Alexander Azimov <aa@qrator.net>, idr wg <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
Message-ID: <20170427225017.GA25068@gweep.net>
Reply-To: jzp-idr@rsuc.gweep.net
References: <20170426095547.GP25069@Space.Net> <CA+b+ERk4FxB4KQ3N0xtjV6uaQptd=EGKdpbKcpoL2TH41fVSYg@mail.gmail.com> <20170426113954.GA18318@puck.nether.net> <CA+b+ER=Ej7G1EEOQ7uBU-z7LeBAGNSfPkE5yGmo+z52ncKhVdg@mail.gmail.com> <20170426125417.GU25069@Space.Net> <CA+b+ERm1iDv3+GNk+N_gqjDWsd+E4QjmfhmwDN4vQVQVZ1EMpw@mail.gmail.com> <CAL9jLaabkYUO+7jsRbfZg1fXXLHXaWr88AxGyNF+AVTLquyxTQ@mail.gmail.com> <CAHw9_iKhRQpEGigqvqYoF0ca9D=-2VmESO8Fp4P_p1tZqpJgXQ@mail.gmail.com> <CAHgCvCNRYyH9wyT=vtVk34_Wc_rqrX0z1D9FCx+cZzLBOXmFLw@mail.gmail.com> <CAHw9_i+1HA=o+Lh7NgUxzD-OFq8u6kR5Se5z=tHttkVQ_QaSzg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHw9_i+1HA=o+Lh7NgUxzD-OFq8u6kR5Se5z=tHttkVQ_QaSzg@mail.gmail.com>
X-PGP-Key: http://www.gweep.net/~crimson/pgp.txt
X-Disclaimer: "I'm the only one foolish enough to claim these opinions."
Organization: RSUC - Quality UN*X-like systems and IP networking since 1990.
X-Do-Not-Email-Here: dumpy@spammers.can-bite-me.com
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/rFOOjOdGIxBVFxVpreoAOXb_atA>
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: Thu, 27 Apr 2017 22:54:16 -0000

On Thu, Apr 27, 2017 at 03:26:11PM -0400, Warren Kumari wrote:
[snip]
> Empty policy is fine -- I have a number of sessions where I
> intentionally have no policy. What I don't want to have happen is
> *accidental* sessions without policy -- because, Murphy's law says
> that that will happen wherever it is most likely to hurt / just as I
> get onto a plane / right before a RIPE / NANOG meeting, so all my
> closest friends can point and jeer.
 
While I don't disagree, and this is INTER-domain Routing WG, I 
feel it would be remiss to not mention the applicability in the
datacenterBGP world. Fail-close drastically simplifies the deploy
and staging scenario, allowing different teams to be loosely
coupled and not require lockstep. 

I also like this in the generally-overlooked area of deprovisioning
for all applications: remove the call to policy and in one whack
the device is no longer propagating to your mesh.


-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling