Accept a specific prefix from a peer if no route object exists (white_list_prefix)

[job]

job: is there a way to accept a specific prefix from one peer if no route object exists?
job: like when we know the announcement is correct, but they can't figure out how to make a route object
...
pierky: I can introduce a client-level "white_list_prefix"
pierky: it should have highest priority
pierky: if a prefix is in white_list_pref other checks will be skipped

[pierky]

I've added a couple of client-level settings, white_list_pref and white_list_asn, under the irrdb section:

clients:
  - asn: 11
    ip: "192.0.2.11"
    cfg:
      filtering:
        irrdb:
          as_sets:
            - "AS-ONEONE"
          white_list_pref:
            - prefix: "203.0.113.0"
              length: 24
              le: 32
          white_list_asn:
            - 65534

Prefixes and ASNs that are added to these white lists are treated as if they are part of the client's AS-SET.

Do you think this could solve your problem? Would it be better to implement a sort of white_list_route built by touples of (prefix, ASN) that could be used with a priority higher than IRRdb info?

[job]

Yeah i think tuples is maybe easier :)

[job]

syntax proposal:

clients:
  - asn: 11
    ip: "192.0.2.11"
    cfg:
      filtering:
        irrdb:
          as_sets:
            - "AS-ONEONE"
          white_list_prefixes:
            - "203.0.113.0/24AS65534"

[pierky]

So, I also added a third white list, the one that pheraps is better and easier to solve this kind of problems: white_list_route:

clients:
  - asn: 11
    ip: "192.0.2.11"
    cfg:
      filtering:
        irrdb:
          as_sets:
            - "AS-AS11NETS"
          white_list_route:
            - prefix: "203.0.113.0"
              length: 24
              asn: 65534

The syntax is the same already used for other prefix-list entries, with the addition of an optional asn attribute, used to match the origin ASN.

From clients.yml:

The first one, 'white_list_route', allows routes to
"escape" IRRdb-based filters and to be always accepted.
Entries of this list are made up by prefixes and an
optional ASN which, if present, is matched against the
origin ASN. In this case, routes that pass the IRRdb
filters are tagged with 'prefix_not_present_in_as_set'
and 'origin_not_present_in_as_set' accordingly to the
configured policy.

The last two, 'white_list_pref' and 'white_list_asn'
are more "tricky". They allow to treat prefixes and ASNs
as if they were part of the client's AS-SET.
This implies that filters and features based on IRRdb
data are also applied as if routes were validated against
those data.
For example, if tagging via BGP community was enabled,
when a route is accepted because of one or both of these
white lists then the appropriate
'prefix_present_in_as_set' or 'origin_present_in_as_set'
communities are also added.

In any case, these white lists only apply to IRRdb-based
filters; other filters (NEXT_HOP, prefix length, max
AS_PATH length, transit-free/invalid ASN in AS_PATH and
so on) are applied accordingly to the rest of the
configuration.

Prefixes are always intended as being inclusive of more
specifics unless the 'exact' attribute is set to True.
The range of included sub-prefixes can be set using 'ge'
and 'le' attributes; if they are missing,
length-[32|128] is used.

@job: any feedback?

[job]

looks good to me