Re: [sidr] the need for speed

[Eric Osterweil <[e-mail]>]

On Dec 20, 2012, at 1:27 PM, Arturo Servin wrote:

> 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/

I totally appreciate the efforts behind these design enhancements, and I am trying impugn the work that has clearly gone into them (or the people who did the work).  However, my concern is that without requirements analysis around the core of the architecture that these enhancements speak to, how do you know that you're not just building on a shaky/unstable foundation, or trying to overcome fundamental flaws in its architecture?  We haven't taken the time to outline what bgpsec needs to do in order for us to be protected by it.  Therefore, we can't describe when we've met our goals.

Note: a lot of the above work (I believe) surrounds just the RPKI, and bgpsec's requirements on _it_ may change dramatically in the face of what bgpsec ultimately needs to do.  I am becoming increasingly convinced that it is important to make the rpki vs. rpki+bgpsec distinction crystal clear.

>> 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.

So, despite my suggestions to start with requirements, you're asking for a design?  :)

Throwing something together in a tit-for-tat would be reckless, as we don't have a solid agreement of _what_ we are trying to protect against, and therefore, we don't know _how_ we want to protect ourselves from it.  Admittedly, opinions in this group seem to vary, but we do not have a reasonable/accepted draft.

I am so glad meatspace bridges aren't built this way... We'd be driving down the road trying to convince ourselves that a 1,000 meter wide gorge up ahead was really just 900 meters of meaningful danger, and the 900 meter bridge that we built part of the way across it is good enough.

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


I'm happy to have the requirements discussion, but it starts with higher level questions like: what (specifically) are we trying to accomplish?  What are we trying to protect ourselves against?  What is the nature of that danger?  How do we address it? etc.  Then we can go to lower level requirements that may come out of that, like freshness.  Without understanding the high level requirements, I would worry that deciding we need to enshrine a specific deadline, and then choosing a value could be as dangerous as presuming we don't need one at all.

Eric