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

[Christopher Morrow <[e-mail]>]

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