[ARIN-consult] RPKI/IRR Consultation Reminder and Update

[Rhys Barrie]

Hi Mike, everyone,

In my opinion, opt-in is functionally equivalent to not changing anything
at
all, because 95% of organizations will never make the conscious effort to
click
the button. Some won't because of fear or ignorance of what it does, or
because
they don't want to change the status-quo. Far more organizations won't
simply
because they have no idea the button exists or because they aren't
proactively
managed, and popup banners in the web UI or emails to mailing lists aren't
going to significantly change that.

While I'm a fan of Miles' suggestion to highlight discrepancies when
editing
IRR/RPKI entries, particularly when it prompts people to implement/create
RPKI
ROAs where they haven't done so already, I don't think it does much to
mitigate
the problem we're looking at here. If the goal of this project is to
harmonize
IRR data with RPKI data, then I believe that opt-out is the bare minimum
functionality to achieve that with any meaningful significance.

I was originally in favor of the opt-out mechanism, but upon further
contemplation, hearing Job's feedback, and seeing LACNIC's success with a
tightly-coupled integration, I am reasonably convinced as to the validity
and
efficacy of that solution, and I agree that opening the door to
discrepancies
WILL cause discrepancies (and outright issues as a result) to occur. I
believe
that pure opt-in/opt-out exacerbates the long-tail problem as well.

However, given that the addition of this data to the IRR is conceptually
benign, as Job stated earlier, then I suppose the question/proposal I have
is
this: Is it reasonable to tightly couple the creation of IRR route objects,
but
have the _deletion_ of those route objects be optional?

There's no situation that I can think of where you would want an ROA
without
the corresponding route object, and having that additional route object
doesn't
cause any harm. If anyone has a counterexample where this behavior, and the
corresponding automatic "catch-up" mechanism, aren't purely beneficial, I'm
all
ears.I think the tightly-coupled deletion of IRR route objects, however, is
what's causing some people concern. On ROA deletion, it may be preferable /
less objectionable to have a (default-on?) toggle for "Would you like to
delete
this associated route object from the IRR database?". Again, this is on the
premise that having extra IRR data in the form of orphaned route objects is
benign, but that deleting IRR entries is _potentially_problematic for some
(though the only situation where I can see this being the case, is when
someone is attempting to cease using RPKI altogether, which is less-than-
ideal in and of itself!).

I'm still a fan of tightly-coupled automatic maintenance of IRR route
objects
from RPKI ROAs, but perhaps the above is a reasonable middle ground
between opt-out and automatic maintenance.

Thanks for your consideration,

Rhys

*Rhys Barrie* (He/Him)
Senior Network Engineer
Mott Community College

Office (810) 762-0030 <+1-810-762-0030>
rhys.barrie at mcc.edu | https://mcc.edu/


On Fri, Sep 8, 2023 at 9:19 AM Michael Felden via ARIN-consult <
arin-consult at arin.net> wrote:

> Hello everyone,
>
> Initially, I considered an opt-out option as a fine solution.
>
> This perspective was based on a 3 year old ASN with no technical debt and
> a straightforward network.
>
> Putting myself into the shoes of some of the other commenters here, their
> situation is *vastly* different from ours and it becomes clear why opt-in
> might be a more sensible approach.
>
> A possible compromise could involve implementing opt-in at the ORGid
> level, actively promoting it through the user interface and member
> communications, especially for new ORGs during on-boarding.
>
> This will leave 20 year old networks that have been through 5 rounds of
> M&A in peace.
>
> Additionally, we could explore implementing a feature suggested by Miles
> in a previous discussion:
>
> For ORGids that are not opted in who create an IRR object without a
> matching ROA, or vice versa, we could highlight this and provide a "sync
> this for me" button to create the corresponding object. Perhaps also
> display this delta when an org with existing objects opts in. Don't just
> create objects in the background but show them their status quo and have
> them confirm that they are happy with the before and after.
>
>
> Best,
>
> Mike Felden
>
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN
> Consult Mailing
> List (ARIN-consult at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-consult Please contact the
> ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20230908/1663c7b0/attachment.htm>