Last message for a bit, as I do have other things I need to do today. At Wed, 4 Aug 2010 19:02:09 +0000, Jeffrey Haas wrote: > > Let me attempt to correct my incorrect verbiage. It's been a while since > I've read the -arch document. > > -arch notes that a provider must maintain a Local Cache.
Yes. > The Local Cache may contain configuration - policy - that directs things > like which TAs to use. After processing the RPKI objects, the output is > effectively a database of prefixes (and max-lengths) and their origin ASes. And other data which you appear to be ignoring, but let that pass for now. > A provider may wish to override validated RPKI data for their own purposes. > While not explicitly a SIDR-driven requirement, this was discussed multiple > times as a requirement during the original RPSEC work. What RPSEC did or did not say is not my problem, but I agree that an operator has policy settings somewhere. At present, they're mostly in the router itself, thanks to Doctor Knob; the only policy setting in the RPKI part of the picture at the moment is choice of trust anchor, which is a basic configuration issue for the validator and something we almost certainly do not want to extrude into the rpki-rtr protocol. > The resulting output (override or no), is a set of AS:prefix/maxlen tuples > that reflects the provider's routing policy with regard to origin > validation. You're jumping to the conclusion that policy is applied before distribution. > This policy must now be distributed to routers for implementation. The > mechanism for distributing the policy is currently > draft-ymbk-rpki-rtr-protocol. No. That protocol is specified as distributing distilled RPKI data (or distilled IRR data, if you're trusting enough to use that). Show me where that draft says -anything- about distributing policy. The word never even appears in the draft. The rest of your message is a detailed derivation of how you get into trouble by attempting to feed policy down a protocol pipe that was not designed to carry it. I will note that, of your two options, ignoring your injection of policy into the protocol, the first one (co-location of RPKi validator with rpki-rtr server) is the one we envisioned, although one can imagine more complex topologies where validators fetch from pre-aggregated caches generated by other validators, to reduce external load and promote a weak form of coherence. Note that in a complex topology the object timestamps will tend to do what you want automatically, given that we're using rsync as the RPKi data gathering tool. Also note that all of the fancy topology stuff would happen in front of RPKI validation, by the time one has gotten past that it's just the rpki-rtr protocol feeding results to the routers. Your second option, on the other hand, creates a nasty single point of failure. Insert Randy's standard comment about encouraging all of my competitors to do that. But I really think your problem here is confusion of the rpki-rtr protocol with a policy distribution service. It's not intended to be that, thus your call for a scheme to detect skew in something it was never intended to carry looks out of scope to me. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
