>>>>> On Thu, 15 Dec 2011 15:56:44 -0800, Randy Bush <ra...@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 mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
