Showing T16: OV: ROA Parent Prefix Revoked,New ROA SameAS,I-Unknown,I-Invalid
||2011-11-14 21:13:08 UTC
Same as test OV: ROA Parent Prefix Revoked,New ROA Same AS,Ignore Invalid,
but the policy used in this test is to accept "valid" only.
The IUT MUST be configured to accept "valid", and ignore both "unknown" and
"invalid" validity state of a received route (i.e., a prefix and an originAS)
for further process.
Here, the ROA is defined as "data record" received by the IUT from a RPKI Cache.
Scenario and Expectations
- 00:00 - BRITE cache sends two ROAs (data records) to the IUT:
- ROA 2 [10.10.0.0/20,24,AS30]: ROA for covering prefix (i.e., super prefix) with maxLength.
- ROA 3 [10.10.0.0/24,24,AS30]: ROA for end-entity prefix with no maxLength (or prefix length is
equal to maxLength).
- 00:01 - The following BGP Updates are sent to the IUT:
- Update 2 (10.10.0.0/20, AS30)
- Update 3 (10.10.128.0/20, AS30)
- Update 4 (10.10.0.0/24, AS30)
- Update 5 (10.10.15.0/24, AS30)
- Update 6 (10.10.128.0/24, AS30)
- Update 7 (10.10.0.0/24, AS20)
- BRITE expects to receive three Updates (Updates 2, 4 and 5) from the IUT.
- 00:02 - BRITE revokes ROA 2 and later receives WDs for Updates 2 and 5. The IUT announces
WDs for the previously "valid" routes (Updates 2 and 5), which became "unknown".
Update 4 is still valid since the exact match ROA exists.
- 00:03 - BRITE sends ROA 2 again. The IUT advertises Updates 2 and 5, which became "valid"
from previously "unknown"
- 00:04 - Test ends.