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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
