MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
In-Reply-To: <0lehuaiiky.fsf@wjh.hardakers.net>
References: <20111129225106.25323.811.idtracker@ietfa.amsl.com>
 <FF8D803A-4C2D-4A3A-B274-70A9FB514F5C@castlepoint.net>
 <m239cls81v.wl%randy@psg.com> <0lehuaiiky.fsf@wjh.hardakers.net>
Date: Sat, 4 Feb 2012 14:03:11 -0500
Message-ID: <CAL9jLaZKjoe4LRT6mqeqxpfSxa8z0AU7ohRr-3qOL6PeR74LUg@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Wes Hardaker <wjhns1@hardakers.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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
Precedence: list

On Sat, Feb 4, 2012 at 1:01 PM, Wes Hardaker <wjhns1@hardakers.net> wrote:
>>>>>> On Thu, 15 Dec 2011 15:56:44 -0800, Randy Bush <randy@psg.com> said:
>
> RB> As you say, NetConf is for *configuring* routers. =A0RPKI-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. =A0The 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? =A0Yes. =A0But...
>
> Routers, operating in the defacto state of doing what they're supposed
> to be doing (routing), need to be fast and efficient. =A0And that's an
> understatement. =A0The rpki-rtr protocol is clearly designed to make sure
> this is the case. =A0It's a cache-query protocol designed to keep a fairl=
y
> large, complex and constantly changing data set in sync with the router
> that actually needs to use it. =A0It'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. =A0Especially when the data is large and changing at =
a
> rapid rate.
>
> Now, lets compare those needs against netconf. =A0Netconf was designed to
> be a protocol that operated on a data storage full of configuration
> data. =A0The configuration data is likely to be static, except when rarel=
y
> manipulated through CLI, netconf or some other actions. =A0But those
> modifications will be rare, not frequent. =A0The language is verbose (lot=
s
> 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). =A0And it's designed not for operational data, but for
> configuration data, which is an entirely separate beast.
>
> Could it be used? =A0Yes, 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). =A0Certainly 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? =A0No.... =A0it's just not a g=
ood
> fit.
>
> I can shoe-horn the rpki-rtr protocol into a number of other shoes, but
> none of them are right either. =A0Consider tftp, snmp, http, or even bgp
> itself. =A0They all could be used in theory, but none of them really meet
> the operational needs either (so don't get any ideas!). =A0Could they be
> used? =A0Yes. =A0Should they be? =A0No.
>
> [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,
netconf...).

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.

-chris