Hi Maria.

Maybe I'm misunderstanding the RPKI instances. My local bird2 instance is connected to two routinator cache servers. Both are sending IPv4 and IPv6 information over. This is the outputs of both on this particular bird2 instance:

bird> show protocols all routinator1
Name       Proto      Table      State  Since         Info
routinator1 RPKI       ---        up     2019-10-22    Established
  Cache server:     10.0.0.1:3323
  Status:           Established
  Transport:        Unprotected over TCP
  Protocol version: 1
  Session ID:       766
  Serial number:    73
  Last update:      before 0.309 s
  Refresh timer   : 899.690/900
  Retry timer     : ---
  Expire timer    : 172799.690/172800
  Channel roa4
    State:          UP
    Table:          roa_v4
    Preference:     100
    Input filter:   ACCEPT
    Output filter:  REJECT
    Routes:         96534 imported, 0 exported, 50987 preferred
    Route change stats:     received   rejected   filtered    ignored   accepted
      Import updates:          96696          0          0          0      96696
      Import withdraws:          162          0        ---          0        162
      Export updates:              0          0          0        ---          0
      Export withdraws:            0        ---        ---        ---          0
  Channel roa6
    State:          UP
    Table:          roa_v6
    Preference:     100
    Input filter:   ACCEPT
    Output filter:  REJECT
    Routes:         16307 imported, 0 exported, 8638 preferred
    Route change stats:     received   rejected   filtered    ignored   accepted
      Import updates:          16311          0          0          0      16311
      Import withdraws:            4          0        ---          0          4
      Export updates:              0          0          0        ---          0
      Export withdraws:            0        ---        ---        ---          0

bird> show protocols all routinator2
Name       Proto      Table      State  Since         Info
routinator2 RPKI       ---        up     2019-10-22    Established
  Cache server:     10.0.0.2:3323
  Status:           Established
  Transport:        Unprotected over TCP
  Protocol version: 1
  Session ID:       632
  Serial number:    71
  Last update:      before 162.554 s
  Refresh timer   : 737.445/900
  Retry timer     : ---
  Expire timer    : 172637.445/172800
  Channel roa4
    State:          UP
    Table:          roa_v4
    Preference:     100
    Input filter:   ACCEPT
    Output filter:  REJECT
    Routes:         96086 imported, 0 exported, 45547 preferred
    Route change stats:     received   rejected   filtered    ignored   accepted
      Import updates:          96232          0          0          0      96232
      Import withdraws:          146          0        ---          0        146
      Export updates:              0          0          0        ---          0
      Export withdraws:            0        ---        ---        ---          0
  Channel roa6
    State:          UP
    Table:          roa_v6
    Preference:     100
    Input filter:   ACCEPT
    Output filter:  REJECT
    Routes:         16271 imported, 0 exported, 7669 preferred
    Route change stats:     received   rejected   filtered    ignored   accepted
      Import updates:          16275          0          0          0      16275
      Import withdraws:            4          0        ---          0          4
      Export updates:              0          0          0        ---          0
      Export withdraws:            0        ---        ---        ---          0

 So here I see both instances with both address families, and the local bird instance is using both of them. 

On Tue, 22 Oct 2019 at 08:36, Maria Matějka <jan.matejka@nic.cz> wrote:

Hello!

On October 22, 2019 5:51:56 AM GMT+02:00, Darren O'Connor <mellow.drifter@gmail.com> wrote:
>I was reading the documentation for bird2 when I came across this:
>You can validate routes (RFC 6483) using function roa_check() in filter
>and
>set it as import filter at the BGP protocol. BIRD should re-validate
>all of
>affected routes after RPKI update by RFC 6811, but we don't support it
>yet!
>You can use a BIRD's client command reload in bgp_protocol_name for
>manual
>call of revalidation of all routes.
>
>Is there a rough timeline for when bird2 will correct re-validate
>affected
>routes? As I run multiple table, is the best thing to simply run a
>cronjob
>telling bird 'reload in all' a few times a day until that support is
>added?

There is no exact time line as we found out that we want first to do substantial changes in internal API between protocols and tables w.r.t. multithreading and parallel execution plans.

Anyway, the parallel execution thing is currently under development and we suppose we'll get to automatic re-evaluation in several months. (To be honest, I said the same thing last year so don't trust me.)

One workaround you can do is to enable debug on the rpki protocol instance and reload the affected channels on roa change detected by reading the log file. This is somehow dirty, yet developing a consistent automatic route reload also eats some time, sorry for the inconvenience.

>The second item is this:
>We currently support just one cache server per protocol. However you
>can
>define more RPKI protocols generally.
>
>This doesn't seem true though, as I have two cache servers configured
>for
>both ipv4 and ipv6 and it seems to be fine?

Do you mean two cache servers for one RPKI protocol instance? I'm not now looking into the code, I may be wrong, I'd only suppose that the latter server is used exclusively.

Maria
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.