Re: [sidr] WGLC: draft-ietf-sidr-origin-ops

Danny McPherson <danny@tcb.net> Sun, 30 October 2011 13:41 UTC

Return-Path: <danny@tcb.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E749D21F8B2A for <sidr@ietfa.amsl.com>; Sun, 30 Oct 2011 06:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.542
X-Spam-Level:
X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN8RJDLAH--V for <sidr@ietfa.amsl.com>; Sun, 30 Oct 2011 06:41:16 -0700 (PDT)
Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7783F21F8B1C for <sidr@ietf.org>; Sun, 30 Oct 2011 06:41:16 -0700 (PDT)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id C8C4F190194; Sun, 30 Oct 2011 13:41:15 +0000 (UTC)
Received: from dul1dmcphers-m2.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id BA7973201C8; Sun, 30 Oct 2011 13:41:14 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <m2hb2q4uhj.wl%randy@psg.com>
Date: Sun, 30 Oct 2011 09:41:14 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <39878AC4-65F0-429A-AF56-665598D6F383@tcb.net>
References: <CAL9jLaaOm_=W85r3P990A6DtROTcQwSJ-KBRzAi9ugw1Bo1_cQ@mail.gmail.com> <E4B4DE52-BBB3-4FA0-A75A-B51824BA83E7@lacnic.net> <m2hb3a7uqp.wl%randy@psg.com> <m2fwiu7uji.wl%randy@psg.com> <CAL9jLabcaLnBbZXbNf7Lbv+ppm-h9yO+wBHunG4s1=emOyM6=w@mail.gmail.com> <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <m2hb2q4uhj.wl%randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.1084)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Oct 2011 13:41:17 -0000

On Oct 30, 2011, at 6:57 AM, Randy Bush wrote:

> 
> note that the RIRs were talking 24 hour publication cycles, last i heard
> (long ago, i admit).  [ i thought this was nutso ]  so a lot of this has
> yet to play out.

I see 4-6 hours in the document, but what do you really think is 
reasonable here for RIRs or other participants Randy?

One of the concerns I have is publication or download delays for new 
information resulting in operational issues we all experienced with 
IRR object publication and mirroring that led to a slew of manual IRR 
[repository] downloads, routing policy updates, and route "bounces" 
or session resets.   

Given, we're in a far better place than this today with incrementally 
updated prefix filters and route refresh offsetting BGP/TCP statefulness, 
and prefix-validation with rpki-rtr to delivery origin validation 
data to routers helps with where we're going, but I'm still concerned 
that if we don't expressly aim to understand publication and 
synchronization dynamics issues can arise that lead to considerable
delays in getting even "business day" resolution to a problem.

-danny