On Sat, Feb 4, 2012 at 1:01 PM, Wes Hardaker <wjh...@hardakers.net> wrote: >>>>>> 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].
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 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
