Re: [sidr] the need for speed

[Arturo Servin <[e-mail]>]

On 20/12/2012 15:35, Eric Osterweil wrote:
> 
> On Dec 20, 2012, at 11:59 AM, Arturo Servin wrote:
> 
>> "> I would really like to echo Chris's last paragraph here. What do you
>>> think is a reasonable time to propagate from an operator editing the
>>> RPKI (A) -> 99.9% of Bs?
>>>
>>> I understand that half a day is way too long. Instantaneous is
>>> theoretically impossible when BGP and RPKI are separate. But is there
>>> really no reasonable pragmatic indication of what would be 'good
>>> enough' for the real world? E.g. if we can come up with a structure
>>> that enables repositories to support 100k RP tools ('B', assuming 2
>>> gatherers per ASN) getting their *updates* (full dump separate thread
>>> please) every 10 minutes, is that good enough?
>>>
>>
>> 	So, instead of continuing a futile discussion, why not better start
>> working on a workable requirement?
> 
> I think a number of us in this ``futile'' argument have been pushing pretty hard to start (or some may claim revive) the requirements process.  The very fact that we are even talking about freshness and liveliness of data is a result of a few of us having to request/re-request/write drafts/do formal analysis on existing measurement/swrite tech notes/re-request again/etc.  imho, the only reason anyone is _now_ saying, ``half a day is way too long'' is because it has taken this long to get traction from the group.
> 

That's is not true. We have seen some challenges in the current
architecture since long ago and some are trying to address them:

https://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-points/

https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-delta-protocol/

https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-validation-local-cache/



> My 0.02 about the above is that the first part of Tim's para talks about finding a requirement, but the 2nd part presumes the existence of a design (repos and structures)...  

Yes. That is what we have now. If you have a better way I would like to
hear a proposal.

Let's talk about requirements first.  If we need use cases and threat
models before that, then let's go _there_ first, and then on to
requirements.  I feel like your comments above take for granted the fact
that several of us have had to work very hard to get to this stage.
> 

Let's talk about requirements, what do you think is a reasonable time to
propagate?

> Eric
> 

Regards,
as