Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard
Randy Bush <randy@psg.com> Thu, 15 December 2011 23:56 UTC
Return-Path: <randy@psg.com>
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 6DDD111E808A for <sidr@ietfa.amsl.com>; Thu, 15 Dec 2011 15:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Level:
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599]
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 IL6zvG2HXZBU for <sidr@ietfa.amsl.com>; Thu, 15 Dec 2011 15:56:46 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E1E3211E8098 for <sidr@ietf.org>; Thu, 15 Dec 2011 15:56:46 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from <randy@psg.com>) id 1RbLAL-000Azh-7J; Thu, 15 Dec 2011 23:56:45 +0000
Date: Thu, 15 Dec 2011 15:56:44 -0800
Message-ID: <m239cls81v.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Shane Amante <shane@castlepoint.net>
In-Reply-To: <FF8D803A-4C2D-4A3A-B274-70A9FB514F5C@castlepoint.net>
References: <20111129225106.25323.811.idtracker@ietfa.amsl.com> <FF8D803A-4C2D-4A3A-B274-70A9FB514F5C@castlepoint.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard
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: Thu, 15 Dec 2011 23:56:47 -0000
[ people whacked me to resend to sidr list ] I am not sure if this is an architectural misunderstanding V a red herring. As you say, NetConf is for *configuring* routers. RPKI-rtr is not used for router configuration, but rather dynamic data, a la IS-IS or BGP. In fact, the RPKI-rtr payload data go into the same data structure as the BGP data. Of course, the configuration of the RPKI-rtr relationship to cache(s) is router configuration, similar to configuring BGP peers, and presumably can be done by NetConf on those platforms which support NetConf. Bottom line: NetConf 'replaces' the CLI, not BGP. FWIW, two or three years ago, not wanting to reinvent the wheel, we looked at NetConf-style payload packaging. After all, Bert and I chartered NetConf back in the day. I still owe a dinner to the two NetConf folk who helped try. Unfortunately the mismatch was non-trivial, though nowhere near the mismatch of DNSsec, at which we also looked (as the Tonys and I had published in 1998, Lutz in 2006, etc., of which I presume you are unaware). When we evaluated the data bloat for NetConf-style packaging we were not cheered. While probably not important for a CLI replacement, for a continuous dynamic protocol the overhead of unpacking XML and decoding the contained ASCII payload drew unhappy whining from the router hackers. NetConf is not ideal for a long-session back-and-forth protocol, with RPKI-rtr's serial number exchange which leaves the router in control of the exchanges and enables incremental update of the data. You *really* do not want the cache to send the full data set to the router every time. And you definitely do not want a cache trying to keep track of the state of O(100) router clients which may or may not still think they are its friend. And, sadly, NetConf is not available on significant platforms where RPKI-rtr is already running today. So, all in all, being lazy, of course we tried. But it was not a good fit. Of course, if you want to have a go at it, I am sure we would be willing to at least kibitz. But first you might want to talk to the vendors who have already implemented RPKI-rtr to see if they would be willing to re-code. randy
- [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-19.tx… The IESG
- Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-1… Randy Bush
- Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-1… Warren Kumari
- Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-1… Wes Hardaker
- Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-1… Christopher Morrow