Re: [sidr] Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
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
Re: [sidr] Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
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
Re: [sidr] Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
On Nov 29, 2011, at 5:51 PM, The IESG wrote: The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The RPKI/Router Protocol' draft-ietf-sidr-rpki-rtr-19.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-12-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Support. I have (carefully) read and reviewed this document and support publication…. W Abstract In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
