On Wed, Aug 29, 2012 at 1:25 AM, Stephen Kent <[email protected]> wrote: > Brian, > > As I mentioned in my rely to Eric, I think this is a topic to be addressed > in an RPKI > operational considerations doc. We have draft-ietf-sidr-origin-ops-19 in > progress now,
i had actually thought that both of the ops docs had this data, yes. <http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19#section-3> <http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05#section-3> I had thought were the likely locations. Some of what both Eric and Brian are poking at is what Danny poked at long ago: "As a number resource 'owner' (user? lessor? operator?) how long does it take for my shiny new ROA to get from me to 'everywhere I care about?'" the 'everywhere I care about' is probably 'everywhere' and is probably here more of a guideline than a hard rule... I suspect given the origin-ops + bgpsec-ops docs suggestions you're looking at ~12 hrs from start/finish for today's 4-ASHOP interwebs. (just a guess, someone could do the math... in fact, this is one of the math bits I was asking about in a previous message: <http://www.ietf.org/mail-archive/web/sidr/current/msg04939.html>) > so I suggest you discuss this with the author of that doc. Nonetheless, I'll > offer my > views on a few of the topics you mentioned: > >> ... >> >> 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. > > I rarely see FSMs in RFCs these days, although I agree that they are > valuable in many contexts. Do > we have an FSM for IRR data use by RPs? > >> 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. > > As I mentioned at the SIDR interim, each manifest contains a next issue > date/time, which is a > way for the CA to tell RPs when the RPs should expect to see new objects > published. An RP could use > that value as an indication of when to check the pub point for the CA in > question (vs. using some > fixed, periodic checking interval for all CAs). > >> 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)? > > I don't think that the term "guarantee" is applicable here, given the > vagaries of communication :-) . for quite some time the discussion has been: "Hey, all of your internal caches, in the most simplistic deployment, may not have all the same data. Additionally, you will have to gather from all over the globe data at all publication points, by the time you finish gathering you may also be behind." I don't see that that has changed much ... has it? I do think that understanding "hey, this publication of a new ROA/CRL/EE takes 12hrs to get everywhere[*]" is important though. -chris [*]: 'everywhere' means 'to each asn/RP', I think inside that ASN it's harder to decide if the job is done, BUT it's on the local AS operator to 'get it done'. > > > > > Steve > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
