On Tue, Aug 28, 2012 at 12:23 AM, Stephen Kent <[email protected]> wrote: > Eric, > > It seems likely that not all RPs will have the same view of INR > allocation, e.g., due to differences > in when RPs fetch data from repositories. This seems analogous to the > transient inconsistencies that > ISPs see today if they use IRR or other INR data sources, for similar > reasons. >
I think there are a couple of things that are important, in the duality between INRA<->RPKI<->RP and Originator<->RP<->...<->RP relationships. For example, in the IRR world, there are a number of reasonably well-known processes used by the largest network operators, for IRR-update -> filter-update schedules (and mechanisms). And as such, recipients of new INRs have published rules they need to follow, to ensure their announcements won't be blocked by filters that have yet to be updated. So, there are a couple of analogous elements in the RPKI ecosystem that, IMHO, need to be described, proscribed, or categorized: What model for the processes of maintaining sync between INR and RPKI should be followed? A high-level finite state machine (FSM) model should be an eventual goal, so that implementors have a crystal clear model to follow. At any point in time, what states should any particular element be able to be in? How should an RP interpret each of those states? How can an RP identify the timeline it needs to follow, if it wants to be as current as possible, with as little overhead and work required? Clearly once-per-second polling won't scale. Is there any corresponding place in the RPKI that would allow an Originator to identify expected latency between ROA issuance, and the update towards a given RP which would guarantee that the RP will accept an announcement (in BGPSEC)? This is the level of modeling I'd hope to see, to understand how the overall system behaves, as a potential RP. Brian
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
