Hi claudio,
Seems we are getting very close. Some suggestions to simplify the
experience for the end user.
Let's start with supporting just one (unnamed) roa-set, so far I've
really not come across a use case where multiple ROA tables are useful.
I say this having implemented origin validation on both ISPs and IXPs.
The semantics of the Origin Validation procedure that apply to
"Validated ROA Payloads" are not compatible with how the ARIN WHOIS
OriginAS semantics, so roa-set will never be used for ARIN WHOIS data.
There currently is 1 RPKI, and therefor we should have just 1 roa-set.
The advantage of having only one roa-set is that it does not need to be
referenced in the policies.
I propose the patch is amended to accomodate the following:
roa-set {
165.254.255.0/24 source-as 15562
193.0.0.0/21 source-as 3333
}
deny from any ovs invalid
match from any ovs valid set community local-as:42
match from any ovs unknown set community local-as:43
I suggest the filter keyword 'ovs' (origin validation state) is
introduced to allow easy matching. I think this looks better. If the
roa-set is not defined or empty, all route announcements are 'unknown'.
I'm working on a patch to introduce the 'ovs' keyword to bgpctl too,
folks can do stuff like "bgpctl show rib ovs valid". I'll share that
with you privately.
Kind regards,
Job
