Re: [Sidrops] draft-ymbk-rpki-rov-timing-00.txt

[Tim Bruijnzeels <[e-mail]>]

hi,

> On 22 Apr 2020, at 14:28, Randy Bush <[e-mail]> wrote:
> 
> mornin' tim,
> 
> thanks for review!
> 
>> s/rcynic/rsync/g
> 
> massimiliano already beat me up on that this morning.  he had done a PR,
> i merged it, and then let spell check revert it <blush>.
> 
>> Furthermore, I think the document could use some words on the chain
>> before the CA. i.e. timing of creation of ROAs in the CA w.r.t.
>> changes in announcements done.
> 
> i am not understanding.  do you mean possible CA to publication point
> delay?

No I mean the delay between deciding to make a change in routing announcements that one does, and using one's CA to create the ROAs. I.e. before section 4 in your draft applies.

> 
>> I would say that for planned changes ROAs should be created in
>> advance
> 
> yes.  this was discussed many time in the design team.  the ddos defense
> folk essentially said that most of the 'customers' come running in the
> door in panic and had never thought to do advanced planning.  while i
> have some sympathy for that, i am not sure what we can say here other
> than
>  o try to constrain the propagation time
>  o point out that roa creation in advance of operational changes, be it
>    circuit moves, ddos sinking, ... should be done sufficiently in
>    advance.
> 
> i'll try to do more.
> 
>> As a side note. We are discussing moving from rsync to RRDP in another
>> thread. I believe that RRDP will help reduce propagation times.
> 
> i tried to say that.  will look again.

You did, this was just a lead to the following.

> 
>> I have no doubt that further improvements can be conceived in future.
>> It helps to have guidance for maximum propagation times to serve as
>> guidance for requirements there.
> 
> i am not understanding.  maybe some coffee will help.

What I am trying to say is thank you :)

In more words, hopefully less confusing, I find it useful to have this document say what the operational expectations are w.r.t. total propagation times:

Planned:
 1 - Create ROAs in CA (implied in section 4, but logically a step before the next)
 2 - Let CAs publish (your section 4)
 3 - Let RPs fetch and valid (section 5)
 4 - Let routers fetch and apply (section 6)
 5 - Do the actual announcement 

Unplanned:

 5 - Do the actual announcement
Becomes:
 0 - Do the actual announcement

But then you will still need to keep in mind how much time 1-4 takes, because until 4 is reached your announcement may be dropped.

RRDP has a limit of 60 seconds for fetching, w.r.t. point #3 (section 5). I think it will actually scale up to something faster if needed. Alternatively one could thing of push mechanisms or some flooding protocol in future. That said, it's only one kink in the chain. E.g. if there is a delay of an hour between #1 (create ROAs) and #2 (actual publication) then this won't matter much - yes, I am using a hyperbole to make a point :)

In any case, knowing how long the propagation from 1 through 4 can reasonably take will help guide what to improve.



> 
> thanks again.
> 
> randy