Showing T07: OV: Scenario4, I-Invalid, I-Unknown
||2011-06-09 17:39:02 UTC
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 (126.96.36.199/16, OAS4)
and ROA3 is replaced by ROA3_broken (188.8.131.52/16-24, OAS9)
within the following requirements
and scenario 4
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.
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 (184.108.40.206/16, OAS4) and ROA3_broken (220.127.116.11/16-24, 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