From job at fastly.com Wed Sep 6 17:52:44 2023 From: job at fastly.com (Job Snijders) Date: Wed, 6 Sep 2023 23:52:44 +0200 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> Message-ID: Dear ARIN & community, Thank you for this opportunity to provide feedback on proposed changes! [ TL;DR - by and large the proposed changes are a positive step forward in harmonizing IRR & RPKI ROAs, this is beneficial to the community as it removes friction in operations: maintaining data in 2 places always leads to discrepancies ] Before venturing into the questions put forward by this consultation, I'd like to share some background on my own experiences harmonizing IRR & RPKI: I am the initiator of the IRRd v4 project (http://irrd.net/), and its RPKI integration. In IRRdv4 the integration was twofold: the first aspect is that *all* RPKI ROAs are transformed into IRR route/route6 objects, the second aspect is that IRR consumers (bgpq4, irrtoolset, etc) are blinded from RPKI-invalid route/route6 objects. This latter aspect in effect made RPKI a 'higher source of truth', and permitted operators to focus their energy only on configuring RPKI ROAs, as the associated IRR route/route6 objects automatically were instantiated tracking the associated ROAs. IRRdv4 nowadays is deployed at major transit carriers, multiple RIRs, and multiple major third-party IRR databases. I also was a driving force behind the ARIN/ARIN-NONAUTH split, the RIPE/RIPE-NONAUTH split, the RPKI-based filtering mechanism of RIPE-NONAUTH (RIPE-731), and the upcoming deprecation of the 'OriginAS' attribute in the ARIN-WHOIS database. As it stands, many operators already today enjoy (indirect) benefit from the design choices of IRRdv4 and tools like 'bgpq4'. I argue that we should be careful not dismiss prior work and experiences at Internet-scale in this space. On Fri, Aug 25, 2023 at 01:31:35PM -0400, ARIN wrote: > As of 24 August, we have received a range of opinions on how best to > proceed. As a result of the feedback received so far, we are planning > to develop the following features: > > - A per-OrgID setting entitled ? Automatic IRR Route Object > Maintenance for RPKI ROAs?. This setting will be ?on? by default when > we add it to all OrgIDs, but customers can readily turn it off I've not yet seen anyone argue a compelling case why it should be made possible to turn this off. Also, over the years of IRRd v4 deployments I have not seen requests to opt-out of RPKI-based automatic instantiation of IRR route/route6 object. Therefor I fear that allowing customers to opt-out might lead to both needless complications in the codebase & support procedures, for no obvious benefit other than "more buttons is more better" (which usually really isn't better). I see an opportunity to improve things in a central location (ARIN's IRR), and think that the trigger for these improvements should not be pushed down to requiring action from thousands of Orgs operators. > - On the Routing Security Dashboard, there will be a checkbox entitled > ?Automatic IRR Route Object Maintenance? which is where an Org can > opt-out of the default IRR route automation I don't think Orgs should be able to opt-out. In my years of experience with RPKI-to-IRR mechanisms this did not came up as a request. As it stands, in the world's deployments of the RFC 6811 Route Origin Validation procedure the existence of ROAs takes precedent over subsequent ingress EBGP filtering. There are benefits to 'downsampling' RPKI-to-IRR, but not for the IRR to contain information inconsistent with the RPKI. > - At the Org ID level, there will be an option for a one-time ?catch > up? that will automatically create Route Objects for each ROA in > question. This one time ?catch up? will also result in existing Route > Objects being automatically maintained. I believe the "catch up" should happen automatically, and not require operator intervention. The leading principle here is that data addition to IRR databases is benign. The existence of a "catch up"-button implies that thousands of Orgs need to understand and edifice themselves as to the exact ramifications (which are beneficial, as shown by prior work in this space), and the more barriers to entry are introduced the more operators drop off, potentially partially nullifying the goal of this project. > We are also planning to make the following changes to RPKI and IRR functionality: > > - Upon creation or removal of a ROA with the default automation > attribute set to on, we will make the appropriate change to > corresponding IRR Route Object(s) Nice! > - When a Route Object is automatically generated by ROA creation, its > existence is dependent on the ROA; however, the customer will maintain > the ability to delete or modify the Route Object and not impact the > state of its corresponding ROA I would prefer a simpler mechanism, because making it technically possible to have discrepancies between IRR and RPKI *will* cause discrepancies between IRR and RPKI to exist. The more discrepancies exist, the harder it becomes in the future to fully transition from IRR (an unsafe plain-text relic from the past) to modern cryptographically secure attestations like RPKI ROAs. > Regarding the question of the appropriate number of Route Objects that > should be created based on the ROA prefix and max length > configuration, ARIN plans to provide an additional checkpoint that > will require a user to positively select the option to apply a > maxLength value, only after being presented with information about the > RFC 9319 best practice recommendation to limit the use of maxLength in > ROAs, and the exposure to a potential forced origin sub-prefix hijack > with a liberal use of maxLength. If an organization has automatic IRR > generation turned on, and a maxLength is set on a ROA, ARIN will > generate the IRR Route Object with the least specific match based on > the prefix(s) in the triggering ROA. Am I correct in my understanding that the conclusion was that the appropriate number of Route Objects is 1 (one), regardless of the maxLength value submitted by the user? If yes, that indeed would be my preference, and align with the established practise as promoted by the various deployments of IRRdv4. > There has been strong and consistent feedback against automatically > creating managed IRR Route Objects for all validated ROAs in the > Hosted RPKI repository that do not have matching IRR Route Objects, so > we will not force this action. No IRR objects will be created without > the customers' expressed permission. I'd like to receive more information from the opposition as to why not. Again, the aforementioned previous experiences show that 'automation' is key to the success, and reduces the burden. RPKI should be considered the higher source of truth, and it makes a lot of sense to me to coalesce the higher-source-of-truth into the existing ARIN IRR. Thanks! Kind regards, Job From bill at herrin.us Wed Sep 6 19:05:25 2023 From: bill at herrin.us (William Herrin) Date: Wed, 6 Sep 2023 16:05:25 -0700 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> Message-ID: On Wed, Sep 6, 2023 at 2:52?PM Job Snijders via ARIN-consult wrote: > I've not yet seen anyone argue a compelling case why it should be made > possible to turn this off. Because you are not smart enough to imagine all of the operational situations a user of the system might face and need to work around. The failing isn't unique to you: no one is that smart. Which is why the really smart people design systems that are flexible enough to let their users deal with the unexpected. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From job at fastly.com Wed Sep 6 19:41:49 2023 From: job at fastly.com (Job Snijders) Date: Thu, 7 Sep 2023 00:41:49 +0100 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> Message-ID: On Thu, 7 Sep 2023 at 00:05, William Herrin wrote: > On Wed, Sep 6, 2023 at 2:52?PM Job Snijders via ARIN-consult > wrote: > > I've not yet seen anyone argue a compelling case why it should be made > > possible to turn this off. > > Because you are not smart enough to imagine all of the operational > situations a user of the system might face and need to work around. > The failing isn't unique to you: no one is that smart. Which is why > the really smart people design systems that are flexible enough to let > their users deal with the unexpected. Thanks for the pinch, Bill :-) You appear to argue it must be made possible to allow for all configuration permutations (for the sake of it being possible). One can easily construct Venn diagrams of RPKI and IRR data, and conclude that it makes no sense to consider disjoint IRR data if one has deployed RPKI-ROV (or has plans to). The real opt-out is to not create ROAs, if one doesn?t wish IRR objects to be created following ROA creation. As I understand the ARIN consultation so far, it?ll be perfectly possible to create IRR objects without creating RPKI ROAs - that should satisfy some. If I?m understanding you correctly, you don?t offer a compelling case, other than that - theoretically - one must exist. And yes, it?s possible such a case exists, thus I?m asking, and also sharing my experience with this community about how automated RPKI-to-IRR conversion services in practise have proven to be very beneficial at Internet-scale, so that?s what I recommend ARIN to implement. Kind regards, Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Sep 6 22:14:48 2023 From: bill at herrin.us (William Herrin) Date: Wed, 6 Sep 2023 19:14:48 -0700 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> Message-ID: On Wed, Sep 6, 2023 at 4:42?PM Job Snijders wrote: > You appear to argue it must be made possible to allow for all configuration permutations (for the sake of it being possible). One can easily construct Venn diagrams of RPKI and IRR data, and conclude that it makes no sense to consider disjoint IRR data if one has deployed RPKI-ROV (or has plans to). Hi Job, No, but I do argue that if there's no technical requirement that the configurations for two separate systems be linked, then any such linkage should be optional and under the control of the user. > If I?m understanding you correctly, you don?t offer a compelling case, other than that - theoretically - one must exist As one of the users, I don't want it. That's as compelling an argument as there needs to be. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From job at fastly.com Thu Sep 7 11:16:41 2023 From: job at fastly.com (Job Snijders) Date: Thu, 7 Sep 2023 16:16:41 +0100 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> Message-ID: Dear colleagues, Perhaps it is good to study how a neighbouring RIR harmonised RPKI and IRR. LACNIC, serving more than 12,000 member organisations in 33 countries, is a sizeable operation in terms of regional coordination and facilitation or IP/ASN registration services, IRR & RPKI. Perhaps it?s lesser known how exactly their IRR system works. In the LACNIC service region RPKI ROAs and IRR route/route6 object management is tightly coupled: meaning, when one creates an RPKI ROA in the ?MiLACNIC? web portal - automatically - without additional user intervention - corresponding route/route6 objects are created in the LACNIC IRR service. When a ROA is deleted, the corresponding IRR objects are also deleted. Irrespective of the maxLength value, only a ?least-specific? route-object is created. Thus, all LACNIC members use a single interface to manage both IRR and RPKI - they don?t have to worry about discrepancies because the system doesn?t allow for discrepancies. It?s not possible to accidentally forget to create IRR objects, because the system will always do it for you! The way LACNIC approached this has greatly simplified IRR operations and widely is regarded as a positive. Over the years I?ve never seen anyone ask for an opt-out mechanism! I believe the success of the LACNIC approach can serve as an inspiration how to tackle this in the ARIN region too. A few advantages of their approach I see are simplifications in the training materials used to educate new operators how to publish their routing intentions, reduction of cost maintaining multiple similar systems, ease of use - people only have to learn and maintain a single thing, and improved accuracy as there are no discrepancies between IRR and RPKI data sources. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tony_Tauber at comcast.com Thu Sep 7 14:16:22 2023 From: Tony_Tauber at comcast.com (Tauber, Tony) Date: Thu, 7 Sep 2023 18:16:22 +0000 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> Message-ID: <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> ?On 9/6/23, 10:15 PM, "ARIN-consult on behalf of William Herrin" on behalf of bill at herrin.us > wrote: > On Wed, Sep 6, 2023 at 4:42 PM Job Snijders > wrote: > > If I?m understanding you correctly, you don?t offer a compelling case, other than that - theoretically - one must exist > > As one of the users, I don't want it. > That's as compelling an argument as there needs to be. > > Regards, > Bill Herrin You don't say _why_ you don't want it. Looking back to other commentors on this thread: I found three that I think touched on this: Dale Carder (ESnet): ---- I am estimating the default behavior should skew heavily towards Orgs who are relatively uncomplicated, and for them, the automagic maintenance of IRR objects can be a huge win in terms of simplicity as well as providing immediate benefit for the Internet at large with more data in trustworthy IRR sources. We do need to recognize there are Orgs for whom this default behavior would not be necessary, or perhaps even reasonable. I would believe them to be in the minority. A few have chimed in as part of this discussion and to me, this effectively makes a case for opt-out functionality, communicated well in advance. ---- Miles McCreadie (Midco Comm.): ---- Opt-in at the Organization level. Opting in should not remove existing IRR route(6) objects that do not match a ROA though it would probably be useful to highlight any differences between IRR data and ROAs, possibly with an option to fully align the IRR data with the ROA. (ie "The following IRR route(6) objects either match or are more specifics of the prefix in this ROA, click here to remove all the IRR route(6) objects that do not match the prefix in the ROA. The non-matching IRR route(6) objects can be managed separately from the ROA.") ---- Chuck Hague (Charter Comm): ---- I believe either and opt-in or opt-out option would be best per ORGID ---- It seems these could be summarized as ?I imagine there should be a knob but have no concrete reason why?. Obviously, I'm removing some context and apologize for what may seem like a glib characterization. I really mean no disrespect, just trying to move things forward. I found Job?s extensive, detailed discussions to not including the opt-out to be compelling and will express my support for that approach. Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Sep 7 14:37:58 2023 From: bill at herrin.us (William Herrin) Date: Thu, 7 Sep 2023 11:37:58 -0700 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> Message-ID: On Thu, Sep 7, 2023 at 11:16?AM Tauber, Tony wrote: > It seems these could be summarized as ?I imagine there should be a knob but have no concrete reason why?. Hi Tony, I don't disagree, but decades of experience have taught me that's a compelling reason to have a knob. It's better to have a capability and not need it than to need a capability and not have it. That doesn't mean you build every conceivable capability, but it does mean that when you have a choice between creating a hard link between two otherwise separate systems and creating a soft link between them, the smart choice is nearly always a soft link with a disable knob. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From dwcarder at es.net Thu Sep 7 15:02:18 2023 From: dwcarder at es.net (Dale W. Carder) Date: Thu, 7 Sep 2023 14:02:18 -0500 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> Message-ID: Thus spake Tauber, Tony via ARIN-consult (arin-consult at arin.net) on Thu, Sep 07, 2023 at 06:16:22PM +0000: > On 9/6/23, 10:15 PM, "ARIN-consult on behalf of William Herrin" on behalf of bill at herrin.us > wrote: > > > On Wed, Sep 6, 2023 at 4:42 PM Job Snijders > wrote: > > > If I?m understanding you correctly, you don?t offer a compelling case, other than that - theoretically - one must exist > > As one of the users, I don't want it. > > That's as compelling an argument as there needs to be. > > > > Regards, > > > Bill Herrin > > > You don't say _why_ you don't want it. > > Looking back to other commentors on this thread: > > I found three that I think touched on this: > > Dale Carder (ESnet): > > ---- > I am estimating the default behavior should skew heavily towards > Orgs who are relatively uncomplicated, and for them, the automagic > maintenance of IRR objects can be a huge win in terms of simplicity > as well as providing immediate benefit for the Internet at large > with more data in trustworthy IRR sources. > > We do need to recognize there are Orgs for whom this default behavior > would not be necessary, or perhaps even reasonable. I would believe > them to be in the minority. A few have chimed in as part of this > discussion and to me, this effectively makes a case for opt-out > functionality, communicated well in advance. > > ---- > > Miles McCreadie (Midco Comm.): > > ---- > Opt-in at the Organization level. > > Opting in should not remove existing IRR route(6) objects that do not match a ROA though it would probably be useful to highlight any differences between IRR data and ROAs, possibly with an option to fully align the IRR data with the ROA. (ie "The following IRR route(6) objects either match or are more specifics of the prefix in this ROA, click here to remove all the IRR route(6) objects that do not match the prefix in the ROA. The non-matching IRR route(6) objects can be managed separately from the ROA.") > > ---- > > Chuck Hague (Charter Comm): > > ---- > I believe either and opt-in or opt-out option would be best per ORGID > > ---- > > It seems these could be summarized as ?I imagine there should be a knob but have no concrete reason why?. > > Obviously, I'm removing some context and apologize for what may seem like a glib characterization. > I really mean no disrespect, just trying to move things forward. That is a completely fair assessment of my comment! > I found Job?s extensive, detailed discussions to not including the opt-out to be compelling and will express my support for that approach. I too find Job's commentary on the matter to be insightful and do believe that the approach he describes would put the ARIN region in a much stronger position than where we are with the current proposal. Dale From mfelden at zav.sh Fri Sep 8 09:19:05 2023 From: mfelden at zav.sh (Michael Felden) Date: Fri, 8 Sep 2023 13:19:05 +0000 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> Message-ID: 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 From rhys.barrie at mcc.edu Fri Sep 8 10:54:44 2023 From: rhys.barrie at mcc.edu (Rhys Barrie) Date: Fri, 8 Sep 2023 10:54:44 -0400 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> Message-ID: 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: From info at arin.net Fri Sep 8 14:28:01 2023 From: info at arin.net (ARIN) Date: Fri, 08 Sep 2023 14:28:01 -0400 Subject: [ARIN-consult] RPKI/IRR Consultation Extended Until 20 September Message-ID: Due to the recent increase of interest and feedback, we are extending the ongoing consultation on possible new features in ARIN Online that will provide tighter integration of ARIN?s Resource Public Key Infrastructure (RPKI) and Internet Routing Registry (IRR) routing security services until 20 September. You can review the original consultation published on 10 August and the update published on 25 August at: https://www.arin.net/participate/community/acsp/consultations/2023/2023-4/ We hope you will take advantage of this extra time to share your thoughts on this important consultation on pending features and functionality that will integrate ARIN?s routing security services. Please provide your comments to arin-consult at arin.net. You can subscribe to this mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult. We look forward to your feedback on this important topic. Regards, American Registry for Internet Numbers (ARIN) From rlaager at wiktel.com Mon Sep 11 15:41:11 2023 From: rlaager at wiktel.com (Richard Laager) Date: Mon, 11 Sep 2023 14:41:11 -0500 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> Message-ID: <25c185cb-6220-2cef-7e00-5645e7b1136a@wiktel.com> On 2023-09-08 09:54, Rhys Barrie via ARIN-consult wrote: > 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. Agreed. > 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. Agreed. As long as we are talking about RPKI automating IRR, this should be fine. The opposite (creating a route object creates a ROA) is not reasonable, IMHO. I don't think anyone has suggested that approach, though. Also, AFAIK, nobody has suggested that IRR route objects would require ROAs, right? As of right now, I still have the problem that I can create IRR records, but not ROAs, as ROAs can only be created for direct allocations, not reallocations. -- Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Sep 11 15:46:11 2023 From: owen at delong.com (Delong.com) Date: Mon, 11 Sep 2023 12:46:11 -0700 Subject: [ARIN-consult] RPKI/IRR Consultation Reminder and Update In-Reply-To: <25c185cb-6220-2cef-7e00-5645e7b1136a@wiktel.com> References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> <25c185cb-6220-2cef-7e00-5645e7b1136a@wiktel.com> Message-ID: <31CBB865-77F4-4B66-9E67-5D53028C7BA3@delong.com> The problem I see with that thinking is I wouldn?t want to see IRR objects that were not the automatic result of ROA creation removed when the ROA expires or is removed. Owen > On Sep 11, 2023, at 12:41, Richard Laager wrote: > > On 2023-09-08 09:54, Rhys Barrie via ARIN-consult wrote: >> 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. > Agreed. > > >> 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. > Agreed. > > > > As long as we are talking about RPKI automating IRR, this should be fine. > > The opposite (creating a route object creates a ROA) is not reasonable, IMHO. I don't think anyone has suggested that approach, though. > > Also, AFAIK, nobody has suggested that IRR route objects would require ROAs, right? As of right now, I still have the problem that I can create IRR records, but not ROAs, as ROAs can only be created for direct allocations, not reallocations. > > -- > Richard > _______________________________________________ > 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: From jcurran at arin.net Thu Sep 14 19:42:55 2023 From: jcurran at arin.net (John Curran) Date: Thu, 14 Sep 2023 23:42:55 +0000 Subject: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) In-Reply-To: <31CBB865-77F4-4B66-9E67-5D53028C7BA3@delong.com> References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> <25c185cb-6220-2cef-7e00-5645e7b1136a@wiktel.com> <31CBB865-77F4-4B66-9E67-5D53028C7BA3@delong.com> Message-ID: <27535DE7-2024-47CF-94AF-D19C15F401ED@arin.net> Folks - Based on the discussion to date, I believe the following approach for synchronized route object creation for RPKI ROAs in ARIN Online would cover most of the expressed requirements ? ? In addition to the present ?Auto-renewing? attribute for a ROA, there would be ?Auto-Matching-IRR-Objects? attribute for ROAs that could be set during ROA Creation or Manage ROA in ARIN Online ? The ?Auto-Matching-IRR-Objects? attribute could be On or Off, and would initially be set to the Organizational ?Automatic Matching IRR Object Creation for ROAs? default value ? which would be On unless/until changed otherwise by the organization. ? New ROAs created with ?Auto-Matching-IRR-Objects? set to On would result in the matching route objects being created. ? Customers could manage existing ROAs and turn "Auto-Matching-IRR-Objects? to On, in which case the matching route objects would be created. ? Existing ROAs with ?Auto-Matching-IRR-Objects? set to On that are then changed to Off would result in matching route objects being deleted ? but only if the route objects in question were automatically created. ? Existing ROAs that are deleted or that expire with ?Auto-Matching-IRR-Objects set to On would result in matching route objects being deleted - but only if the route objects in question were automatically created. ARIN would not change the ?Auto-Matching-IRR-Objects? for any existing ROAs, and these would be set to Off by default ? so as to avoid routing changes that would otherwise occur at time of matching route object feature rollout. (Customers with existing ROAs who wished automatic matching route objects to be created would just have to log into ARIN Online, and manage toggle Auto-Matching-IRR-Objects to On for each ROA.) Are there any particular comments or concerns with the above approach? Thanks! /John John Curran President and CEO American Registry for Internet Numbers From athompso at athompso.net Thu Sep 14 22:03:06 2023 From: athompso at athompso.net (Adam Thompson) Date: Fri, 15 Sep 2023 02:03:06 +0000 Subject: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) In-Reply-To: <27535DE7-2024-47CF-94AF-D19C15F401ED@arin.net> References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> <25c185cb-6220-2cef-7e00-5645e7b1136a@wiktel.com> <31CBB865-77F4-4B66-9E67-5D53028C7BA3@delong.com> <27535DE7-2024-47CF-94AF-D19C15F401ED@arin.net> Message-ID: One thing I'm still unclear on after reading many, many words is: if *want* ARIN to manage everything for me automatically to the maximum extent possible, but I've already manually created both ROAs and IRR objects, is there a non-disruptive, non-service-affecting, path to get from my current state into this brave new fully-automated world? Thanks, -Adam Thompson -----Original Message----- From: ARIN-consult On Behalf Of John Curran Sent: Thursday, September 14, 2023 6:43 PM To: Subject: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) Folks - Based on the discussion to date, I believe the following approach for synchronized route object creation for RPKI ROAs in ARIN Online would cover most of the expressed requirements ? ? In addition to the present ?Auto-renewing? attribute for a ROA, there would be ?Auto-Matching-IRR-Objects? attribute for ROAs that could be set during ROA Creation or Manage ROA in ARIN Online ? The ?Auto-Matching-IRR-Objects? attribute could be On or Off, and would initially be set to the Organizational ?Automatic Matching IRR Object Creation for ROAs? default value ? which would be On unless/until changed otherwise by the organization. ? New ROAs created with ?Auto-Matching-IRR-Objects? set to On would result in the matching route objects being created. ? Customers could manage existing ROAs and turn "Auto-Matching-IRR-Objects? to On, in which case the matching route objects would be created. ? Existing ROAs with ?Auto-Matching-IRR-Objects? set to On that are then changed to Off would result in matching route objects being deleted ? but only if the route objects in question were automatically created. ? Existing ROAs that are deleted or that expire with ?Auto-Matching-IRR-Objects set to On would result in matching route objects being deleted - but only if the route objects in question were automatically created. ARIN would not change the ?Auto-Matching-IRR-Objects? for any existing ROAs, and these would be set to Off by default ? so as to avoid routing changes that would otherwise occur at time of matching route object feature rollout. (Customers with existing ROAs who wished automatic matching route objects to be created would just have to log into ARIN Online, and manage toggle Auto-Matching-IRR-Objects to On for each ROA.) Are there any particular comments or concerns with the above approach? Thanks! /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ 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. From jcurran at arin.net Fri Sep 15 08:14:44 2023 From: jcurran at arin.net (John Curran) Date: Fri, 15 Sep 2023 12:14:44 +0000 Subject: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) In-Reply-To: References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> <25c185cb-6220-2cef-7e00-5645e7b1136a@wiktel.com> <31CBB865-77F4-4B66-9E67-5D53028C7BA3@delong.com> <27535DE7-2024-47CF-94AF-D19C15F401ED@arin.net> Message-ID: <5FB9675B-D936-4D11-8D02-B23F8F28E8A2@arin.net> Adam - I believe that would be: * Set aside some time when you can watch your network * Go into ARIN Online, and for each ROA, toggle ?Auto-Matching-IRR-Objects? to On for each ROA ? this will cause automatic generation of matching IRR route objects. * Watch your network carefully over the next few hours * Declare success, and get on with life as usual? The risk involved would be if the route objects that are automatically created don?t match your current set and somehow conflict ? but that?s unlikely since only a ?least-specific? route-object will be created and any more specifics that you have would take precedence. Thanks! /John John Curran President and CEO American Registry for Internet Numbers On Sep 14, 2023, at 10:03 PM, Adam Thompson wrote: One thing I'm still unclear on after reading many, many words is: if *want* ARIN to manage everything for me automatically to the maximum extent possible, but I've already manually created both ROAs and IRR objects, is there a non-disruptive, non-service-affecting, path to get from my current state into this brave new fully-automated world? Thanks, -Adam Thompson -----Original Message----- From: ARIN-consult On Behalf Of John Curran Sent: Thursday, September 14, 2023 6:43 PM To: Subject: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) Folks - Based on the discussion to date, I believe the following approach for synchronized route object creation for RPKI ROAs in ARIN Online would cover most of the expressed requirements ? ? In addition to the present ?Auto-renewing? attribute for a ROA, there would be ?Auto-Matching-IRR-Objects? attribute for ROAs that could be set during ROA Creation or Manage ROA in ARIN Online ? The ?Auto-Matching-IRR-Objects? attribute could be On or Off, and would initially be set to the Organizational ?Automatic Matching IRR Object Creation for ROAs? default value ? which would be On unless/until changed otherwise by the organization. ? New ROAs created with ?Auto-Matching-IRR-Objects? set to On would result in the matching route objects being created. ? Customers could manage existing ROAs and turn "Auto-Matching-IRR-Objects? to On, in which case the matching route objects would be created. ? Existing ROAs with ?Auto-Matching-IRR-Objects? set to On that are then changed to Off would result in matching route objects being deleted ? but only if the route objects in question were automatically created. ? Existing ROAs that are deleted or that expire with ?Auto-Matching-IRR-Objects set to On would result in matching route objects being deleted - but only if the route objects in question were automatically created. ARIN would not change the ?Auto-Matching-IRR-Objects? for any existing ROAs, and these would be set to Off by default ? so as to avoid routing changes that would otherwise occur at time of matching route object feature rollout. (Customers with existing ROAs who wished automatic matching route objects to be created would just have to log into ARIN Online, and manage toggle Auto-Matching-IRR-Objects to On for each ROA.) Are there any particular comments or concerns with the above approach? Thanks! /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ 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: From Miles.McCredie at midco.com Fri Sep 15 08:44:23 2023 From: Miles.McCredie at midco.com (Miles McCredie) Date: Fri, 15 Sep 2023 12:44:23 +0000 Subject: [ARIN-consult] [EXTERNAL] - Re: Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) In-Reply-To: <5FB9675B-D936-4D11-8D02-B23F8F28E8A2@arin.net> References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> <25c185cb-6220-2cef-7e00-5645e7b1136a@wiktel.com> <31CBB865-77F4-4B66-9E67-5D53028C7BA3@delong.com> <27535DE7-2024-47CF-94AF-D19C15F401ED@arin.net> <5FB9675B-D936-4D11-8D02-B23F8F28E8A2@arin.net> <2eb1185c-da57-49c1-9307-39d169cb262b.4ed73c0e-3647-455d-a83f-39a249afb096.acd14015-282f-4c93-a069-da8887f61488@emailsignatures365.codetwo.com> Message-ID: One thing that I have been assuming in this discussion that would be good to make explicit ? any new ROA or route(6) attributes should be exposed and manageable via API, not just via ARIN Online. [http://images.midcocomm.com/ES_MidcoLogo.png] Miles McCredie Principal Network Engineer II-Core IP Office: 6052755192 Miles.McCredie at midco.com Midco.com From: ARIN-consult On Behalf Of John Curran Sent: Friday, September 15, 2023 7:15 AM To: Adam Thompson Cc: Subject: [EXTERNAL] - Re: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) CAUTION: This email originated from outside of MIDCO. Do not click links or open attachments unless you recognize the sender and know the content is safe. Adam - I believe that would be: * Set aside some time when you can watch your network * Go into ARIN Online, and for each ROA, toggle ?Auto-Matching-IRR-Objects? to On for each ROA ? this will cause automatic generation of matching IRR route objects. * Watch your network carefully over the next few hours * Declare success, and get on with life as usual? The risk involved would be if the route objects that are automatically created don?t match your current set and somehow conflict ? but that?s unlikely since only a ?least-specific? route-object will be created and any more specifics that you have would take precedence. Thanks! /John John Curran President and CEO American Registry for Internet Numbers On Sep 14, 2023, at 10:03 PM, Adam Thompson wrote: One thing I'm still unclear on after reading many, many words is: if *want* ARIN to manage everything for me automatically to the maximum extent possible, but I've already manually created both ROAs and IRR objects, is there a non-disruptive, non-service-affecting, path to get from my current state into this brave new fully-automated world? Thanks, -Adam Thompson -----Original Message----- From: ARIN-consult On Behalf Of John Curran Sent: Thursday, September 14, 2023 6:43 PM To: Subject: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) Folks - Based on the discussion to date, I believe the following approach for synchronized route object creation for RPKI ROAs in ARIN Online would cover most of the expressed requirements ? ? In addition to the present ?Auto-renewing? attribute for a ROA, there would be ?Auto-Matching-IRR-Objects? attribute for ROAs that could be set during ROA Creation or Manage ROA in ARIN Online ? The ?Auto-Matching-IRR-Objects? attribute could be On or Off, and would initially be set to the Organizational ?Automatic Matching IRR Object Creation for ROAs? default value ? which would be On unless/until changed otherwise by the organization. ? New ROAs created with ?Auto-Matching-IRR-Objects? set to On would result in the matching route objects being created. ? Customers could manage existing ROAs and turn "Auto-Matching-IRR-Objects? to On, in which case the matching route objects would be created. ? Existing ROAs with ?Auto-Matching-IRR-Objects? set to On that are then changed to Off would result in matching route objects being deleted ? but only if the route objects in question were automatically created. ? Existing ROAs that are deleted or that expire with ?Auto-Matching-IRR-Objects set to On would result in matching route objects being deleted - but only if the route objects in question were automatically created. ARIN would not change the ?Auto-Matching-IRR-Objects? for any existing ROAs, and these would be set to Off by default ? so as to avoid routing changes that would otherwise occur at time of matching route object feature rollout. (Customers with existing ROAs who wished automatic matching route objects to be created would just have to log into ARIN Online, and manage toggle Auto-Matching-IRR-Objects to On for each ROA.) Are there any particular comments or concerns with the above approach? Thanks! /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ 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: From jcurran at arin.net Fri Sep 15 08:54:32 2023 From: jcurran at arin.net (John Curran) Date: Fri, 15 Sep 2023 12:54:32 +0000 Subject: [ARIN-consult] [EXTERNAL] - Re: Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) In-Reply-To: References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> <25c185cb-6220-2cef-7e00-5645e7b1136a@wiktel.com> <31CBB865-77F4-4B66-9E67-5D53028C7BA3@delong.com> <27535DE7-2024-47CF-94AF-D19C15F401ED@arin.net> <5FB9675B-D936-4D11-8D02-B23F8F28E8A2@arin.net> <2eb1185c-da57-49c1-9307-39d169cb262b.4ed73c0e-3647-455d-a83f-39a249afb096.acd14015-282f-4c93-a069-da8887f61488@emailsignatures365.codetwo.com> Message-ID: <64428A75-5A03-440E-9E38-08BFCEC40619@arin.net> Miles - Excellent point - we?ll make sure to clarify such at the close of the consultation. Thanks! /John John Curran President and CEO American Registry for Internet Numbers On Sep 15, 2023, at 8:44 AM, Miles McCredie wrote: One thing that I have been assuming in this discussion that would be good to make explicit ? any new ROA or route(6) attributes should be exposed and manageable via API, not just via ARIN Online. [http://images.midcocomm.com/ES_MidcoLogo.png] Miles McCredie Principal Network Engineer II-Core IP Office: 6052755192 Miles.McCredie at midco.com Midco.com From: ARIN-consult > On Behalf Of John Curran Sent: Friday, September 15, 2023 7:15 AM To: Adam Thompson > Cc: > > Subject: [EXTERNAL] - Re: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) CAUTION: This email originated from outside of MIDCO. Do not click links or open attachments unless you recognize the sender and know the content is safe. Adam - I believe that would be: * Set aside some time when you can watch your network * Go into ARIN Online, and for each ROA, toggle ?Auto-Matching-IRR-Objects? to On for each ROA ? this will cause automatic generation of matching IRR route objects. * Watch your network carefully over the next few hours * Declare success, and get on with life as usual? The risk involved would be if the route objects that are automatically created don?t match your current set and somehow conflict ? but that?s unlikely since only a ?least-specific? route-object will be created and any more specifics that you have would take precedence. Thanks! /John John Curran President and CEO American Registry for Internet Numbers On Sep 14, 2023, at 10:03 PM, Adam Thompson wrote: One thing I'm still unclear on after reading many, many words is: if *want* ARIN to manage everything for me automatically to the maximum extent possible, but I've already manually created both ROAs and IRR objects, is there a non-disruptive, non-service-affecting, path to get from my current state into this brave new fully-automated world? Thanks, -Adam Thompson -----Original Message----- From: ARIN-consult On Behalf Of John Curran Sent: Thursday, September 14, 2023 6:43 PM To: Subject: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) Folks - Based on the discussion to date, I believe the following approach for synchronized route object creation for RPKI ROAs in ARIN Online would cover most of the expressed requirements ? ? In addition to the present ?Auto-renewing? attribute for a ROA, there would be ?Auto-Matching-IRR-Objects? attribute for ROAs that could be set during ROA Creation or Manage ROA in ARIN Online ? The ?Auto-Matching-IRR-Objects? attribute could be On or Off, and would initially be set to the Organizational ?Automatic Matching IRR Object Creation for ROAs? default value ? which would be On unless/until changed otherwise by the organization. ? New ROAs created with ?Auto-Matching-IRR-Objects? set to On would result in the matching route objects being created. ? Customers could manage existing ROAs and turn "Auto-Matching-IRR-Objects? to On, in which case the matching route objects would be created. ? Existing ROAs with ?Auto-Matching-IRR-Objects? set to On that are then changed to Off would result in matching route objects being deleted ? but only if the route objects in question were automatically created. ? Existing ROAs that are deleted or that expire with ?Auto-Matching-IRR-Objects set to On would result in matching route objects being deleted - but only if the route objects in question were automatically created. ARIN would not change the ?Auto-Matching-IRR-Objects? for any existing ROAs, and these would be set to Off by default ? so as to avoid routing changes that would otherwise occur at time of matching route object feature rollout. (Customers with existing ROAs who wished automatic matching route objects to be created would just have to log into ARIN Online, and manage toggle Auto-Matching-IRR-Objects to On for each ROA.) Are there any particular comments or concerns with the above approach? Thanks! /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ 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: From Chuck.Hauge at charter.com Fri Sep 15 09:11:58 2023 From: Chuck.Hauge at charter.com (Hauge, Chuck P) Date: Fri, 15 Sep 2023 13:11:58 +0000 Subject: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) Message-ID: I have just one point regarding the below statement, if this strategy is used, a per RPKI ROA matching IRR Route object toggle combined with default set to off for existing ROAs. We have 7K+ ROAs over 4 ORGID's, there will need to be an API created (or extended functionality of existing API) so that we could edit the ROA record (not actually editing the ROA, that is prefix, AS, and ML are not changed) to enable/disable this toggle for each ROA. When the API enables/disables the toggle, an IRR route object will be generated/removed. ARIN would not change the ?Auto-Matching-IRR-Objects? for any existing ROAs, and these would be set to Off by default ? so as to avoid routing changes that would otherwise occur at time of matching route object feature rollout. (Customers with existing ROAs who wished automatic matching route objects to be created would just have to log into ARIN Online, and manage toggle Auto-Matching-IRR-Objects to On for each ROA.) Regards, ------------------------------------------------------------------------------------------------------------------------------------- CHUCK HAUGE | CCNP, MBA | IP Management - Systems Engineer IV | c. 303.915.5512 | o. 303.323.6056 ? 6175 South Willow Drive |? Greenwood Village, CO? 80111 ------------------------------------------------------------------------------------------------------------------------------------- From owen at delong.com Fri Sep 15 13:16:27 2023 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Sep 2023 10:16:27 -0700 Subject: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) In-Reply-To: <5FB9675B-D936-4D11-8D02-B23F8F28E8A2@arin.net> References: <186236C4-8CBA-42D3-B0E6-D7B2C32F1550@arin.net> <389E2E4E-C18B-4595-850E-11CF3E1546ED@cable.comcast.com> <25c185cb-6220-2cef-7e00-5645e7b1136a@wiktel.com> <31CBB865-77F4-4B66-9E67-5D53028C7BA3@delong.com> <27535DE7-2024-47CF-94AF-D19C15F401ED@arin.net> <5FB9675B-D936-4D11-8D02-B23F8F28E8A2@arin.net> Message-ID: > On Sep 15, 2023, at 05:14, John Curran wrote: > > Adam - > > I believe that would be: > > Set aside some time when you can watch your network > Go into ARIN Online, and for each ROA, toggle ?Auto-Matching-IRR-Objects? to On for each ROA ? this will cause automatic generation of matching IRR route objects. Perhaps: delete any overlapping or no longer desired IRR objects > Watch your network carefully over the next few hours > Declare success, and get on with life as usual? > > The risk involved would be if the route objects that are automatically created don?t match your current set and somehow conflict ? > but that?s unlikely since only a ?least-specific? route-object will be created and any more specifics that you have would take precedence. > Just a thought? Owen > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > >> On Sep 14, 2023, at 10:03 PM, Adam Thompson wrote: >> >> One thing I'm still unclear on after reading many, many words is: if *want* ARIN to manage everything for me automatically to the maximum extent possible, but I've already manually created both ROAs and IRR objects, is there a non-disruptive, non-service-affecting, path to get from my current state into this brave new fully-automated world? >> Thanks, >> -Adam Thompson >> >> >> -----Original Message----- >> From: ARIN-consult On Behalf Of John Curran >> Sent: Thursday, September 14, 2023 6:43 PM >> To: >> Subject: [ARIN-consult] Short summary of requirements (was: Re: RPKI/IRR Consultation Reminder and Update) >> >> Folks - >> >> Based on the discussion to date, I believe the following approach for synchronized route object creation for RPKI ROAs in ARIN Online would cover most of the expressed requirements ? >> >> ? In addition to the present ?Auto-renewing? attribute for a ROA, there would be ?Auto-Matching-IRR-Objects? attribute for ROAs that could be set during ROA Creation or Manage ROA in ARIN Online >> ? The ?Auto-Matching-IRR-Objects? attribute could be On or Off, and would initially be set to the Organizational ?Automatic Matching IRR Object Creation for ROAs? default value ? which would be On unless/until changed otherwise by the organization. >> >> ? New ROAs created with ?Auto-Matching-IRR-Objects? set to On would result in the matching route objects being created. >> ? Customers could manage existing ROAs and turn "Auto-Matching-IRR-Objects? to On, in which case the matching route objects would be created. >> >> ? Existing ROAs with ?Auto-Matching-IRR-Objects? set to On that are then changed to Off would result in matching route objects being deleted ? but only if the route objects in question were automatically created. >> ? Existing ROAs that are deleted or that expire with ?Auto-Matching-IRR-Objects set to On would result in matching route objects being deleted - but only if the route objects in question were automatically created. >> >> ARIN would not change the ?Auto-Matching-IRR-Objects? for any existing ROAs, and these would be set to Off by default ? so as to avoid routing changes that would otherwise occur at time of matching route object feature rollout. >> (Customers with existing ROAs who wished automatic matching route objects to be created would just have to log into ARIN Online, and manage toggle Auto-Matching-IRR-Objects to On for each ROA.) >> >> Are there any particular comments or concerns with the above approach? >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> American Registry for Internet Numbers >> >> >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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: From info at arin.net Fri Sep 22 15:16:59 2023 From: info at arin.net (ARIN) Date: Fri, 22 Sep 2023 15:16:59 -0400 Subject: [ARIN-consult] =?utf-8?q?Now_Closed_=E2=80=94_RPKI/IRR_Consultat?= =?utf-8?q?ion?= Message-ID: ARIN thanks those who provided valuable feedback during this consultation on pending functionality for automatic creation of Internet Routing Registry (IRR) Route Objects for uncovered Route Origin Authorizations (ROAs). This feedback will be factored into the decision on development of future IRR, Resource Public Key Infrastructure, and ROA features. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) Consultation link: https://www.arin.net/participate/community/acsp/consultations/2023/2023-4/