Job Snijders via NANOG wrote:
> Dear Lee,
Hi Job,
> *ring ring* - "IRR/RPKI helpdesk how may I help you today?" :-)
What a fantastic helpdesk it is, too! ;-)
> Another way to satisfy this request is to ask the organization's
> provider to create an AS-SET (preferably RIR-operatored IRR such as
> ARIN, RIPE, etc), and then reference their AS-SET on your own AS-SET.
> IRR AS-SETs permit both referencing AS Numbers and AS-SETs as 'members:'.
This brings up a question I've been mulling over lately - if AS64500 has
AS64500:AS-CUSTOMERS and has a customer AS64510, and AS64510 only ever
plans to originate routes themselves, with no downstreams, is there any
reason other than "future flexibility" for AS64510 to create an AS-SET,
e.g.:
as-set: AS64500-CUSTOMERS
|-> members: AS64510:AS-AS64510
|-> members: AS64510
versus simply the following:
as-set: AS64500-CUSTOMERS
|-> members: AS64510
It seems to me both are entirely functionally equivalent, aside that if
AS64510 ever wants to change things they would need to get AS64500 to
update their AS64500-CUSTOMERS members.
> The industry trend (very noticable the last 3 years) is that the ability
> to create proxy route object registrations is slowly fading away.
>
> At at first glance proxy registrations seem better than 'no
> registration', the downside is that anyone can create proxy
> registrations for any prefix: proxies are not very safe!
I wonder what this means (eventually, anyway) for RADB, NTTCOM, LEVEL3,
etc. Though LEVEL3 can hardly be considered on the bleeding edge of
IRR...
> The recommendation is that each and every IP resource holder creates IRR
> and/or RPKI objects themselves, or delegates the authority to do so to
> their service provider.
What is the mechanism for such a delegation?
It seems to me that with enough RPKI adoption, IRR will eventually go
away, but you mention "and/or" - is that just for current
interoperability?
Taking it a step futher, let's say I have valid ROAs for all my prefixes
today, because I do. But I don't maintain my objects in ARIN's IRR. Do
I need to migrate, and if so, assuming my upstreams still "reject RPKI
invalid but permit rpki unknown AND require an IRR AS-SET to build BGP
filters in the first place" it seems to me that maintaining IRR is
necessary because otherwise the upstream won't listen to the
announcements at all, much less verify RPKI.
> Technically this is likely to work, but the downside is that you end up
> with a hard dependency on another ISP's proxy registration. If for
> whatever reason that registration lapses (failure to pay bills, M, who
> knows) ... you might end up with a hard to troubleshoot situation where
> it is not immediately clear "it was working yesterday, but not today?!".
FWIW, Lee, I ran into this exact scenario this week. Everything was
working, but the route was only being permitted by the customer's
upstream because of a stale object proxy registered by someone else. My
two cents is that this is an exceedling common occurence.
> The best course of action is to ensure that objects are either managed
> by yourself, or by the customer, so the responsibilities and object
> ownership are clear to everyone involved.
And yet, there's probably double-digits of people that fully grok IRR,
despite the years and years of NOG presenations and tutorials and
everything else.
> A great tool to gain some insight into various IRR/BGP/RPKI data sources
> and what the registration status of various objecst might mean can be
> found at this awesome tool: https://irrexplorer.nlnog.net/
There's also a command-line irrtree that's pretty slick, and if you want
to verify AS-SET recursion and ultimately expansion into prefixes,
point your whois client toward filtergen.level3.net [1] and/or
filtergen.dan.me.uk [2]
--Adam
[1] But be careful because L3 filtergen doesn't recurse across
registries and will ignore data that's not source: LEVEL3 +unless* you
put 'remarks: Level3 members: RADB::AS-FOO' in the AS-SET.
[2] If you instead want to filtergen against RADB data (and objects
which RADB mirrors from others) see https://www.dan.me.uk/filtergen
