Job Snijders writes:
> Dear Jay, AT&T,
>
> > The AT&T/as7018 network is now dropping all RPKI-invalid route
> > announcements that we receive from our peers.
>
> Thanks for filtering us! 
Any time!
> If you can share more about the experience in terms of load on the
> support tiers in your organisation, or questions from peering partners,
> that could perhaps be helpful information for others in their
> preparations.
>
A few reports of resulting connectivity loss have come in through
various channels: on Jared's outages mailing list, on IRC, through our
customer care ticket system, etc.
Thusfar I have been very pleased with the reactions folks have had
when we described how our policy change caused us to lose their
affected route announcement. Everyone so far has understood the
purpose of the RPKI, they understood why the affected route
announcements were deemed invalid and thus were dropped, and best of
all -- they understood what they needed to do to fix things.
We got some very good advice watching this video from your most recent
NLNOG day:
https://www.youtube.com/watch?v=vrzl__yGqLE
... but there is one place where I disagree with Niels. He advised
against lowering the local-pref of invalid routes. I agree that this
should not be anyone's target policy, but it is a useful step along
the way. To set invalid routes a lower local-pref, one needs to
establish RTR sessions from routers to relying party servers, and to
configure a policy that takes validation state into account. The
policy here can also set community based on the validation state,
which can help with flow-based traffic analysis. Then, when you are
comfortable operating RPs that talk RTR to your routers and you're
ready to implement a meaningful policy, it's a simple matter of
changing from:
if validation-state = invalid
then
local-pref = $LOWER
community = foo
fi
to:
if validation-state = invalid
then
drop
fi
In short: C'mon in! The water's fine!
Thanks.
Jay B.
