There has been a lot of discussion about different topics related, I
wasn't sure what we were going to discuss.
Thanks for clearing this out.
Regards,
as
On 12 Apr 2012, at 11:38, Tim Bruijnzeels wrote:
> 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
