Dear Mark, Thank you for sharing all the details in your previous email. For brevity I'm snipping most of your reply. On Tue, Aug 08, 2023 at 03:59:19PM +0000, Mark Kosters wrote:
Job Snijders wrote:
Would it not be advantageous to create at a minimum the 256 of the 'least-specific' objects?
MK: That may be a reasonable approach. Do you see any adverse effects in simplifying the IRR Route creation logic to just have least-specific?
I don't think I see a downside of mapping a single VRP to a single IRR route/route6 object. Synthesizing only the least-specific is how RPKI-integration was implemented in IRRd v4, and that implemntation has seen quite some flight hours by now. The approach seemed to work well in the last ~ 5 years. No request ever came up to extend IRRd v4 to synthesize (a limited number of) more-specific route/route6 objects if maxLength was present in the ROA generation request. IRRd v4 does expose the 'maxLength' value by inserting a non-standard RPSL attribute called 'max-length:' in the route/route6 object. While this is not IETF-standardized, it seemed intuitive enough. RPSL parsers are expected to ignore what they don't recognize anyway. ARIN could mimick this practise. See the following example: $ whois -h rr.ntt.net -- '-s RPKI -T route6 2001:67c:208c::/48' \ | egrep "route6|max-length|origin" | paste - - - route6: 2001:67c:208c::/48 max-length: 48 origin: AS0 route6: 2001:67c:208c::/48 max-length: 48 origin: AS15562 I'd suggest to consider simplying the IRR creation logic to just a singular least-specific route/route object, and not bother with generating 'potentially up to 256' more-specific route/route6 objects. I see a few advantages: G* Every single VRP resulting from a ROA generation request will always result in the instantiation of exactly one IRR route/route6 object. As I understand the current proposal, sometimes a route/route6 object is created, sometimes not, depending on the value of the maxLength. In this I see a source for potential confusion. * By creating just 1 route/route6 object per validated ROA payload, any potential load on the NRTM mirror ecosystem is minimized to the fullest extend possible: 65,285 ROAs on 'rpki.arin.net' will result in 72,082 Validated ROA Payloads thus result in 13,933 'route6:' objects and 58,149 'route:' objects. A significant smaller number compared to expanding up to 256 additional objects if maxLength is set wide enough. * the use of maxLength isn't really recommended anyway, see BCP 185 / RFC 9319 https://datatracker.ietf.org/doc/html/rfc9319. As a rule of thumb I recommend: 1 BGP announcement == 1 ROA == 1 IRR object and avoid just using maxLength all together. * Most transit providers and IXP route server operators create so-called 'upto /24' prefix-list-filters, regardless of maxLength values. So in the vast majority of cases I don't think the additional up to 256 more-specific route objects would change anything. Finally, if people can articulate why exactly synthesizing up to 256 more-specific route objects really would be a useful feature, it can always be added at a later point in time. Adding extra objects to the IRR has always been easier than removing them. :-) Thanks! Kind regards, Job