> On Nov 17, 2023, at 6:58 AM, Christopher Morrow <morrowc.li...@gmail.com>
> wrote:
>
>> On Thu, Nov 16, 2023 at 9:31 PM Tom Samplonius <t...@samplonius.org> wrote:
>
>>> The most surprising thing in the DE-DIX flow chart, was that they check
>>> that the origin AS exists in the IRR as-set, before doing RPKI, and if the
>>> set existence fails, they reject the route. I don’t see a problem with
>>> this, as maintaining as-sets is easy, but it does prevent an eventual 100%
>>> RPKI future with no IRR at all.
>
> I don't think the future is ever really 'no irr'.
> * RPKI provides: "a cryptographically verifiable method to determine
> authority to use ip number resources"
> * OriginValidation provides: "A route origin authorization
> 'database' for use eventually on BGP speakers"
Those both amount to the ability to originate a prefix though.
> IRR filters provide control over whom is provided reachability through
> a particular peering/path.
How does that work? IRR import: and export: parameters are poorly
implemented. Is anyone actually validating more than the origin with IRR?
> (dale points this out as well, particularly the part about paths he points
> out)
Tom
