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
