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

Jeffrey Haas <jhaas@pfrc.org> Wed, 26 April 2017 15:20 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 1A89412ECF5 for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 08:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3lle4TD0lveq for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 08:20:32 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDDA12ECAA for <idr@ietf.org>; Wed, 26 Apr 2017 08:20:30 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 19B6F1E358; Wed, 26 Apr 2017 11:27:50 -0400 (EDT)
Date: Wed, 26 Apr 2017 11:27:49 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: Robert Raszuk <robert@raszuk.net>, idr wg <idr@ietf.org>
Message-ID: <20170426152749.GD4803@pfrc.org>
References: <50353B76-1323-4828-88D6-25954DA1E344@puck.nether.net> <20170425221104.GS30063@pfrc.org> <023e01d2be72$031ac180$4001a8c0@gateway.2wire.net> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL9jLaabkYUO+7jsRbfZg1fXXLHXaWr88AxGyNF+AVTLquyxTQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oVkKzGV6evgAeN3ml357hZXWE24>
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: Wed, 26 Apr 2017 15:20:35 -0000

On Wed, Apr 26, 2017 at 10:08:44AM -0400, Christopher Morrow wrote:
> > And if the end result is what you are doing twice a day why router's can't
> > do it themselves assuming IRRDB or any other src of truth is accurate ?
> >
> >
> 'how often does this data change?'
> 'how often do I want to refresh peering data on devices (from neighbors)'
> 'what is the sla for this part of the service'

I will point out that RPKI-rtr (RFC 6810) is effectively a form of this sort
of dynamic update mechanism. Managing the database and its consistency for
the feed it advertises is certainly no different than what is being talked
about, but the signaling of the *results* is certainly not completely out of
scope of existing or prior work.

It's still gross that RtConfig or equivalent still is the common operational
practice.

-- Jeff