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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf