On Dec 14, 2011, at 4:42 PM, Randy Bush wrote: > I am not sure if this is an architectural misunderstanding V a red > herring. > > 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. > > 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. Whoa... I am likely off in the weeds here, but if NetConf is operating on fundamentally different data and doesn't suffice here, wouldn't flow spec work? You know, in the spirit of not reinventing the wheel? > > 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. Would it be possible to get a pointer to some of this eval? I tried some google'ing and my typical ineptitude left me without any leads. > > 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. Wait, is this discussion about the impact of a new provisioning/configuration protocol for BGP routers, or a red herring about the scalability of the current cache design (which is a separate issue, if I'm not mistaken)? imho, the architectural limitations of the cache design should not shift undue onus onto routers and justify new protocols (in of itself). If the only reason not to use NetConf or flow spec is that the caches can't take the load of managing state, then maybe we should refocus on addressing the caches, and presume that new protocols to configure the routers is a last resort (rather than a first step). > > And, sadly, NetConf is not available on significant platforms where > RPKI-rtr is already running today. I just want to understand this: is the statement here that RPKI-rtr is more widely deployed than NetConf, or its deployment base is somehow more valuable, or something? > > 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. > Is there any reference to any sort of evaluation that we can get? I (personally) understand that there are "experts in the room," but it would be nice to be able to look at some information so the rest of us can understand some of these limitations. :) I don't think the current argument justifies this work, but I'm looking forward to hearing about any more info that might change this. Thanks! Eric _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf