--- Begin Message ---
Hi Jakob,
On 12/18, Jakob Heitz (jheitz) wrote:
> Hi Lukas, Mark, Ben,
>
> The default bestpath prefix-validate behavior treats invalid routes
> as unfeasible and prefers valid routes over not-found.
>
> The default bestpath prefix-validate behavior cannot be used unless
> all paths of a net have the correct RPKI validity. That can only
> happen if all EBGP sessions into an AS validate their incoming
> routes and apply the RFC8097 extended community.
And, iff all ASBRs have a consistent set of VRPs from the validation
caches, which is a very fragile assumption, and the root of most of the
impact we've seen from this.
> If these conditions are not satisfied, then you cannot use the
> bestpath prefix-validate behavior and you must use
> route-maps to process the RPKI validity, like this:
>
> router bgp ...
> bgp rpki server tcp [...]
> address-family ipv4
> bgp bestpath prefix-validate disable
> [...]
> route-map RM_EBGP_IN deny 10
> match rpki invalid
> [...]
>
> I have a proposal to improve the bestpath prefix-validate behavior
> to better match how most operators use it. By a new configuration,
> I would treat valid and not-found with the same preference. Invalid
> would continue to be unfeasible. Then, a received IBGP route without
> the RFC8097 community will be fine.
>
> Thoughts?
>
That certainly sounds like an improvement (a large one), but it doesn't go far
enough
for me.
The router should not *act* on validation status unless told to by the
operator at all.
I would suggest that the 'bgp bestpath prefix-validate ...' commands be
deprecated altogether, and be replaced with a single per-afi/safi
command that simply enables rov-checking (i.e. records the status in the
RIB, but takes no policy action).
Everything else can be done in a route-map.
I have heard the argument from other vendors that "operators want a
single command to apply, without touching routing policy".
I think this is false. At least in 2020, you would be very hard pressed
to find an operator doing ROV, but scared of writing a non-trivial
routing policy.
Getting from where you are today, to what I'm advocating obviously means
changing existing behaviors, which can be an unwelcome surprise.
I would suggest the following strategy:
1. Introduce a new address-family mode command (something like 'bgp
rpki-validate origin' to provide syntax space for aspa and others in
future).
Make it a no-op if 'bgp bestpath prefix-validate' is enabled, otherwise
make it enable rov state checking as above.
2. Start issuing a warning on the CLI, in logs, etc, when 'bgp bestpath
prefix-validate'
is used.
3. After some time make 'bgp bestpath prefix-validate' a no-op hidden
command.
4. After some more time, error if 'bgp bestpath prefix-validate' is
used.
Hope that helps.
Cheers,
Ben
signature.asc
Description: PGP signature
--- End Message ---
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/