Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01

[Nick Hilliard <[e-mail]>]

Linda Dunbar via Datatracker wrote on 17/03/2020 21:53:
> Section 3 Egress Processing only has one sentence stating that
> "When applied to egress policy, validation state MUST be determined using the
> effective origin AS of the route as it will (or would) be announced to the
> peer." What other choices there are ?   Are there any routers that support  RFC
> 6480 RPKI  not performing this step? how?

jumping the gun on the authors here, there's a mismatch between what 
coders implemented and what operators figured would be workable in terms 
of how policy semantics need to be handled on production routers.

This is a fancy way of saying that some router vendors ticked the ROV 
tickbox, but the way they did it was too limited for real life.

RPKI provides a policy management mechanism.  The ID says that this 
needs to be hooked into the three major policy application points which 
are implemented in most, if not all, bgp rib engines.  These points are:

1. bgp ingress, i.e. at the point between the adj-rib-in and loc-rib
2. on redistribution to other routing protocols
3. bgp egress, i.e. at the point between the loc-rib and adj-rib-out

This didn't happen for ROV on all vendor stacks.

It's kinda obvious to operators that it should have been.

Also, it's not the first time that this sort of feature lapse has 
happened in the history of routing management.  There's been a bit of a 
history of this sort of thing happening over the years.

Nick