[c-nsp] RPKI extended-community RFC8097

[Ben Maddison]

Hi Jakob,

On 12/18, Jakob Heitz (jheitz) wrote:
> There is an issue with route-maps.
> 
> Testing the RPKI validity in route-map causes BGP REFRESH messages.
> Lots of them.
> soft-reconfig helps, but that causes risk of memory exhaustion and does
> not fix the internal CPU usage of evaluating the needed route-maps.
> (soft-reconfig saves a copy of all pre-policy incoming routes).
> Using the validity in the bestpath computation does not cause REFRESHes.
> 
Thanks for the insight - this is really helpful to know.
I wasn't aware that a modified VRP set would trigger a REFRESH
automatically. I suppose I had assumed that either operator intervention
or a refresh UPDATE as the result of natural churn would be required if
a new VRP sent a route from invalid to valid/unknown.

We typically have soft-reconfig enabled for customers and all but the
largest peers anyway, so I guess I wouldn't have seen this all that
often.

> Consider if validity is used in a route-map and the router drops a route.
> When a ROA update comes from the validator, then the route-map needs
> to be re-evaluated to determine if the route can now be used and what
> sets need to be made to it.
> For all routes, not just one.
> Because when a route is dropped, all information about which route was
> dropped is lost.
> The REFRESH must go to any router that has dropped at least one incoming
> route and that tests RPKI validity in its route-map.
> 
To what extent is this true for other types of import policy change?
A referenced prefix-list or community-list in a route-map that changes,
for example?

> We have some work going on in XR to reduce the impact of the REFRESH
> messages and to reduce the risk of memory exhaustion when using soft-reconfig.
> 
I would be interested to hear the details of that if/when you're at
liberty.

> When validity is used in bestpath computation, invalids are not actually
> dropped. They are made unfeasible. It's effectively dropped, but can
> come back from the dead after a ROA update from the validator.
> Importantly, the route-map has already run on it and does not need to run
> again when the validity changes. Thus no REFRESH.
> 
Makes sense.
Presumably the memory consumption of the unfeasible routes would be
equivalent to doing soft-reconfig given the same number of paths?

I'm a big fan of explicit configuration when it comes to this stuff (as
you can probably tell from my previous comments).
Making use of this behaviour as a form of "selective soft-reconfig"
would be helpful in other contexts than ROV.

Consider:

route-map customer-AS65000-in deny 100
  match ip address prefix-list martians
route-map customer-AS65000-in deny 200
  match rpki invalid
route-map customer-AS65000-in permit 300
  match ip address prefix-list AS65000-IRR
route-map customer-AS65000-in deny 400

In this case, the set of VRPs that the router has changes frequently,
and so does the contents of the AS65000-IRR prefix-list (assuming it is
built from the IRR automatically on some timer).
The martians list will change very infrequently.

How straightforward would something like a 'set unfeasible' command be,
that would operate in a 'deny' statement and cause the denied paths to
be retained a-la soft-reconfig?
In the above example, I would use it in clauses 200 and 400. But not in
100.

That way you can store the routes that are likely to be re-evaluated
later, but not the ones that are likely to stay garbage forever.

Cheers,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20201219/37360f62/attachment.sig>