Showing T07: OV: Scenario4, I-Invalid, I-Unknown

Owner sspies
Date created 2011-06-09 17:39:02 UTC

Test Description


This test checks, if an IUT (Implementation Under Test) can
  • re-validate prefix/origin pairs of incoming BGP announcement Updates according to RPKI/RTR whitelist entries, which are announced afterwards
  • can still operate the acceptance policy (ignore-invalid, ignore-unknown) correctly, when the validation state of prefix/origin pairs changes
  • can fulfil both above, if ROA1 is replaced by ROA1_broken (, OAS4) and ROA3 is replaced by ROA3_broken (, OAS9)
within the following requirements, dataset and scenario 4


  • Policy
    Ignore prefix/origin pairs of incoming BGP announcement updates
    if their validation state is INVALID or UNKNOWN.
  • Cache to Router
    It is expected that the implementation under test will send a "Query Request" message within 60 seconds of the receipt of a "Notify" message.
  • Policy
    Do not execute any other policies on incoming BGP Updates and do not change the default BGP best path selection algorithm.


Scenario 4 and Expectations according to ignore-invalid, ignore-unknown

  • t0: Send all BGP Updates
  • Implicitely do not expect to receive any Updates
  • t60: Send all ROAs as whitelists
  • t60-120 Goal "Valid Updates": Expect to receive announcements for all green BGP routes.
  • t120: Remove ROA1 and ROA3 as whitelists
  • t120-t180 "Valid -> Invalid Routes Withdraw": Expect to receive withdrawals for all green BGP routes.
  • t180: Add ROA1_broken (, OAS4) and ROA3_broken (, OAS9) as whitelists
  • t180-t240 and if "Valid -> Invalid Routes Withdraw" success
    Goal-Set "No Updates after broken WL add": Explicitely wait for 60 seconds to see no BGP Update.