On Wed, Mar 18, 2020 at 12:44:29AM +0000, Nick Hilliard wrote:
> 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.
Perhaps:
OLD:
It might be affected by removal of private AS(s), confederation, AS
migration, etc. If there are any AS_PATH modifications resulting in
origin AS change, then these MUST be taken into account.
NEW:
BGP implementations have to take removal of private AS(s),
confederation, AS migration, etc into consideration. If there are
any AS_PATH modifications resulting in an Origin AS change, then
these MUST be taken into account and only the final Origin AS is to
be used as input into the Origin Validation procedure.
Kind regards,
Job
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
