Hi,
On 12 Apr 2012, at 04:16, Christopher Morrow wrote:
> On Wed, Apr 11, 2012 at 5:25 PM, Arturo Servin <[email protected]> wrote:
>> Chris,
>>
>> For the agenda item: "Deployment Discussion -> Discuss the need, and
>> publication location/method, for documentation that details rollout of SIDR
>> technologies in an operational network." Are we going to discuss what Tim
>> suggested in his e-mail on March 30th (subject: rpki repository and
>> validation issues). I think he pointed out three valid points to discuss (at
>> least start with the first 2 as he suggested):
>>
>
> Actually no, Tim wanted to be able to present/be-in-person so the next
> time he can do that is the coincident meeting with IETF in Vancouver,
> BC.
Indeed, I can't make the 30 April interim meeting (not even remote). And it's
also too short notice to bring more real measurements and experience (&
measurements) from piloting possible alternatives to the table.
I agree with Randy (if I understand his point correctly) that measurements are
needed to substantiate any discussion about the problems and possible
alternatives. So... we actually plan to work on this over the following weeks
(after the RIPE meeting):
- Add an automated feedback feature to our validator so that we can get
statistics from wherever people run it (if they enable the feature). We're
thinking of measuring:
= average time to validate enabled TAs
= frequency of rsync repositories being unavailable
= frequency of validation corner cases occurring because we get a repo
*while it is being updated* (eg mft out-of-sync with some object)
= I am open to suggestions of other stuff to measure..
- Do a quick pilot implementation of some ideas:
= Use an rss like notification mechanism to alert RPs of updates
= Use http to fetch *consistent* deltas
= And then do the same measurements as above and possibly more we can think
of (like some controlled load stressing)
Of course there are lots of details involved here that are interesting to
discuss with other RP implementers, RPKI publishers and the sidr wg at large,
but... we feel that at this stage we want to mature and try out our ideas first
so that when we bring this to the table we'll have a reasonable idea of whether
it actually works in real code and helps to solve the real issues that we see.
In short: we want to invest some energy in trying it out first, and then
discuss more, rather than the other way around..
Planning can always change, but it looks like we should be able to do this
without spending too many of our resources and in time to report about it in
Vancouver.
For the time being we will use the list of problems and requirements that I
formulated as a guideline for this pilot, but I am well aware that that list is
subject to change when it's discussed in more detail in sidr on-list or at a
meeting..
Tim
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
