On Dec 14, 2011, at 2:42 PM, Randy Bush wrote: > I am not sure if this is an architectural misunderstanding V a red herring. Let's call it an architectural misunderstanding. > As you say, NetConf is for *configuring* routers. RPKI-rtr is not used > for router configuration, but rather dynamic data, a la IS-IS or BGP. > In fact, the RPKI-rtr payload data go into the same data structure as > the BGP data. "Dynamic data"? Isn't that a truism? We're not carving RPKI data out of stone tablets are we? :-) > Of course, the configuration of the RPKI-rtr relationship to cache(s) is > router configuration, similar to configuring BGP peers, and presumably > can be done by NetConf on those platforms which support NetConf. > > Bottom line: NetConf 'replaces' the CLI, not BGP. Here's another bottom-line: today, in my network, there is only one thing that can/does influence BGP policy on an individual router: locally configured (on the router itself) policy. There is a well-established operational practice that only policy on the router itself, consumed through either CLI or NETCONF, will affect routing decisions made by that box. RPKI-RTR is introducing a *new* side-channel, (I'm being kind by not calling it a 'backdoor'), through which "dynamic data" is now injected directly to the BGP routing process that "dynamically impacts" BGP policy and, ultimately, it's route-selection. The key concern I have is: RPKI-RTR is another entry-point into BGP on the router for which I, and every other operator, now need to perform regression testing for each version of code, on each make & model of router!, I roll-out to my network. If RPKI-RTR had used NETCONF, instead, this likely would have used an existing mechanism of loading, and evaluating, BGP policy in routers that exist *today*, (and since the dawn of time). This is a non-trivial operational expense bourne by the entire SP industry for the lifetime of RPKI-RTR. > FWIW, two or three years ago, not wanting to reinvent the wheel, we > looked at NetConf-style payload packaging. After all, Bert and I > chartered NetConf back in the day. I still owe a dinner to the two > NetConf folk who helped try. Unfortunately the mismatch was > non-trivial, though nowhere near the mismatch of DNSsec, at which we > also looked (as the Tonys and I had published in 1998, Lutz in 2006, > etc., of which I presume you are unaware). > > When we evaluated the data bloat for NetConf-style packaging we were not > cheered. While probably not important for a CLI replacement, for a > continuous dynamic protocol the overhead of unpacking XML and decoding > the contained ASCII payload drew unhappy whining from the router > hackers. Was this discussed in the IETF? If so, do you have a pointer to the evaluation or results of those findings? Most importantly, why this overwhelming concern about "bloat" from NetConf-style packaging? Surely there is substantial 'overhead' in pushing around just the RPKI data amongst the RPKI caches, (even within a single ISP), including having RPKI caches verify signatures associated with new RPKI updates on the caches? NetConf would seem to be the least of the concerns here, but without an elaboration of the issues you cite, it's unclear if those issues were valid, let alone if they could have been mitigated. > NetConf is not ideal for a long-session back-and-forth protocol, with > RPKI-rtr's serial number exchange which leaves the router in control of > the exchanges and enables incremental update of the data. You *really* > do not want the cache to send the full data set to the router every > time. And you definitely do not want a cache trying to keep track of > the state of O(100) router clients which may or may not still think they > are its friend. Hrm, I think there is a grave misunderstanding indeed. A few points: a) The current draft, draft-ietf-sidr-rpki-rtr-20, contradicts what you say above wrt not sending the full data set every time: ---snip--- [...] As with any update protocol based on incremental transfers, the router must be prepared to fall back to a full transfer if for any reason the cache is unable to provide the necessary incremental data. ---snip--- b) I think there is a very bad assumption, above, that the router is a "database of record" and, therefore, should be the one in control of consuming configuration, excuse me: "dynamic", updates from RPKI caches. That's not how networks are, or should be, run in my experience. ISP's already have systems that maintain physical & logical inventory in offline DB's and, just as importantly, coordinate/synchronize changes from their offline systems to O(1,000's) of routers. You need that for physical & logical inventory purposes alone, let alone more fancy configuration of routing protocols on those same devices. c) In draft-ietf-sidr-origin-ops-13, there is a suggestion that if "RPKI data [is used] as an input to operational routing decisions, they SHOULD ensure local cache freshness at least every four to six hours." However, I believe it's been suggested that (Global?) RPKI synchronization intervals may, in practice, be as large as 24 hours. Regardless, in my experience, anything that's updated on the order of hours is surely the domain of "configuration" and isn't what I would consider "dynamic" like would be the case in a routing protocol such as IS-IS or BGP. d) Given the above, very lax synchronization intervals of the underlying RPKI data, I don't see the need to open a long-lived TCP connection, (or as you said a couple of paragraphs ago: "continuous dynamic protocol"), between RPKI cache to receiving RPKI router. Instead, do what is done today: NETCONF/SSH into the box when needed, i.e.: every 4 - 6 hours or 24 hours when new RPKI data arrives at the cache(s). e) Given the success operators have today with generating very, very large prefix-lists, (today based on IRR data), and periodically pushing them through the CLI into routers, it seems a misguided assumption that one is "required" to have incremental updates of data, particularly given the several hour intervals we're talking about here for new/updated RPKI data to arrive. Nonetheless, if one wanted to do this, then please at least give us operators some credit that we're smart enough to (help) create NETCONF schemas that would be amenable to incremental updates onboard the router, based on a variety of well-known CompSci techniques, and which could also take advantage of RFC 5717, NETCONF Partial Locking. > And, sadly, NetConf is not available on significant platforms where > RPKI-rtr is already running today. That's a bit of a circular argument isn't it? RPKI-RTR is in existence today due to pre-standards development, which is fine, everyone does it. Certainly a RPKI-RTR NETCONF schema would be there, today, had SIDR gone that as a direction, no? > So, all in all, being lazy, of course we tried. But it was not a good > fit. Of course, if you want to have a go at it, I am sure we would be > willing to at least kibitz. But first you might want to talk to the > vendors who have already implemented RPKI-rtr to see if they would be > willing to re-code. > > randy -shane _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf