It turns out I made an error in the IRR prefix enforcement. So while we were enforcing the as-set requirement as intended, we were not enforcing the route object requirement on rs2. Accordingly, I did not make that enforcing on rs1 today as scheduled. Instead, I corrected it on rs2 and will wait another week before making it enforced on rs1.
I have separately emailed everyone who has prefixes being filtered.
From my perspective, I am on track to make this enforcing
tomorrow.
I have again emailed everyone who has prefixes being filtered.
For the last two emails, I added the ARIN WHOIS contacts for the
originating ASes (and for one email, the ARIN WHOIS contacts for
the IP space involved).
I've had a number of email and phone conversations with people. The list has definitely gotten much better.
I have begrudgingly made exceptions for two networks. They have
ARIN issues to sort out. (Yes, I am aware they could use some
other registry and have mentioned that.) These exceptions will be
time limited. These exceptions allow specifically the prefixes
they are currently announcing that are being rejected. So these
exceptions will not defeat IRR security in general (unlike just
turning it off for them entirely). These exceptions will be on rs1
only, which will allow them/me to use the looking glass to rs2 to
know if things are fixed. As a consequence, their routes will
still be filtered when rs1 is down, e.g. for patching. They have
been so informed.
-- Richard