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

[Wes Hardaker <[e-mail]>]

>>>>> 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].
-- 
Wes Hardaker
SPARTA, Inc.