Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard
Wes Hardaker <wjhns1@hardakers.net> Sat, 04 February 2012 18:01 UTC
Return-Path: <wjhns1@hardakers.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 DD5A121F851A for <sidr@ietfa.amsl.com>; Sat, 4 Feb 2012 10:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 loqV7PYgRXBW for <sidr@ietfa.amsl.com>; Sat, 4 Feb 2012 10:01:20 -0800 (PST)
Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE8621F84DA for <sidr@ietf.org>; Sat, 4 Feb 2012 10:01:20 -0800 (PST)
Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 50D7057C; Sat, 4 Feb 2012 10:01:18 -0800 (PST)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Randy Bush <randy@psg.com>
References: <20111129225106.25323.811.idtracker@ietfa.amsl.com> <FF8D803A-4C2D-4A3A-B274-70A9FB514F5C@castlepoint.net> <m239cls81v.wl%randy@psg.com>
Date: Sat, 04 Feb 2012 10:01:17 -0800
In-Reply-To: <m239cls81v.wl%randy@psg.com> (Randy Bush's message of "Thu, 15 Dec 2011 15:56:44 -0800")
Message-ID: <0lehuaiiky.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
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: Sat, 04 Feb 2012 18:01:21 -0000
>>>>> On Thu, 15 Dec 2011 15:56:44 -0800, Randy Bush <randy@psg.com> said: RB> As you say, NetConf is for *configuring* routers. RPKI-rtr is not used RB> for router configuration, but rather dynamic data, a la IS-IS or BGP. RB> In fact, the RPKI-rtr payload data go into the same data structure as RB> the BGP data. Having finally read through the rtr-25 document, and having some background in following the Netconf work, I finally am in a position to give my opinion on this thread. The thread is a bit old, but consensus never seemed to be "full there" so I figure one more opinion might be helpful. The short summary: Randy is right (this time; don't let it go to your head Randy :-) ) The longer explanation: Could netconf be used to send this type of data over? Yes. But... Routers, operating in the defacto state of doing what they're supposed to be doing (routing), need to be fast and efficient. And that's an understatement. The rpki-rtr protocol is clearly designed to make sure this is the case. It's a cache-query protocol designed to keep a fairly large, complex and constantly changing data set in sync with the router that actually needs to use it. It's binary in nature (ironically written by some people that used to stamp on the ground about how annoying binary protocols are) because it needs to be in order to be efficient and fast. Especially when the data is large and changing at a rapid rate. Now, lets compare those needs against netconf. Netconf was designed to be a protocol that operated on a data storage full of configuration data. The configuration data is likely to be static, except when rarely manipulated through CLI, netconf or some other actions. But those modifications will be rare, not frequent. The language is verbose (lots of commands/pdus/operations), large (XML encoded) and complex to parse (XML is easy-ish for humans and easy-ish for machines, but not fast for either). And it's designed not for operational data, but for configuration data, which is an entirely separate beast. Could it be used? Yes, but with the drawbacks hinted at above: a reduction in speed and an increase in stealing the memory CPU cycles from what the router really should be doing (routing). Certainly the data isn't the same vein as the normal netconf data, so it would likely need a separate storage container running on a separate port even if the same protocol was used. So if it could be used, should it be used? No.... it's just not a good fit. I can shoe-horn the rpki-rtr protocol into a number of other shoes, but none of them are right either. Consider tftp, snmp, http, or even bgp itself. They all could be used in theory, but none of them really meet the operational needs either (so don't get any ideas!). Could they be used? Yes. Should they be? No. [and I'd argue that at least one of them might be a better choice than netconf itself]. -- Wes Hardaker SPARTA, Inc.
- [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