Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard

Christopher Morrow <> Sat, 04 February 2012 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64A4121F848B for <>; Sat, 4 Feb 2012 11:03:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cmyWsG3NDemv for <>; Sat, 4 Feb 2012 11:03:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7AF6E21F8473 for <>; Sat, 4 Feb 2012 11:03:12 -0800 (PST)
Received: by iagf6 with SMTP id f6so7729961iag.31 for <>; Sat, 04 Feb 2012 11:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6eMq6lQn4h7ZTewzh4fR1Jv4NYHyF1FPSqeOFx/O8vQ=; b=TNswDsXpSSBtq16zzRXz0P7N/9LKR9AoPoezS7UeGmKcSOJEIW1LHA+ego6nG8dEYQ SnWagIRmlfF2XEwUBFyjBhT7zURGvnnJ3XlghyrmfMrF1nCvisXc2stuROXu9ey0oQW8 UJ9Lfz57EqNaw2vlck2ITi7+pKCv2BctrDX0A=
MIME-Version: 1.0
Received: by with SMTP id uh5mr13488986icb.34.1328382192126; Sat, 04 Feb 2012 11:03:12 -0800 (PST)
Received: by with HTTP; Sat, 4 Feb 2012 11:03:11 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Sat, 4 Feb 2012 14:03:11 -0500
X-Google-Sender-Auth: 0BXNrX-ntPZXngN_DsnhmsZSqu0
Message-ID: <>
From: Christopher Morrow <>
To: Wes Hardaker <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: sidr wg list <>
Subject: Re: [sidr] Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 04 Feb 2012 19:03:13 -0000

On Sat, Feb 4, 2012 at 1:01 PM, Wes Hardaker <> wrote:
>>>>>> On Thu, 15 Dec 2011 15:56:44 -0800, Randy Bush <> 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].

part of what you (wes) are getting at, and what terry/shane had
pointed at before is that there are other options. the current
rpki-rtr protocol is the first of potentially many (like sending
config to a router, you can use snmp, scp, tftp, ftp, http,

Maybe the real answer is, if you don't like rpki-rtr for your
deployment/environment, look to your vendor with $$ and requirements
and get them to build you a better mousetrap? This worked well for
lots of other 'solutions' on routing platforms in the past.