Hi Owen, cutting some stuff out, just to keep the thread small. Anyone can very quickly put just about anything in RADB if they want to. > It’s also relatively easy to put nearly anything in the current ARIN IRR > (not to be confused with the ARIN RIR database). There are also some other > IRRs that accept almost anything at face value. >
Exactly, thats why you have so much garbage in RADB and other IRR db. > > Finally, route object based filters tend to get updated rather slowly and > not everyone updates in sync, so it’s a gradually progressing outage that > allows some reaction time before becoming completely catastrophic. > Similarly, not everyone is doing ROV. But for the first time people are worried about consequences of their laziness because RPKI is going to work much better than IRR based filtering. > > OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA >> for the entire netback, then you’re (potentially) talking about near total >> catastrophic routing failure for this ISP and all of his customers. >> > > Let’s assume they accidentally delete the registration for any reason > there are cooling off periods in place which goes up to 60 days or we can > put measures in place through policy to have decent cooking off periods. > Also let’s talk about stats, how many times how many RIRs have deleted > their members by mistake? Do you have any case? > > > Honestly, I have no way to know. Such an event would likely not be made > particularly public. The RIR would consider it confidential to the affected > party and the affected party would have little motivation to announce it to > the world after the fact. > So we are debating a scenario which we are not even aware ever happened. I'm still not saying that it never happened and will not happen but likelihood of such incident is just very small. > > So I am not in favor of asking the RIR to create AS0 ROA. >>> >> >> Thats absolutely fine we can agree to disagree but let’s have a clear >> understanding of the policy. >> >> >> What makes you think he does not understand the policy? >> > > Because the policy only addresses the bogon, how an address space becomes > a bogon is APNIC operating procedure. Do you see the problem of > understanding here? > > > Yes, but it’s not his. The policy creates new more severe consequences for > things moving “routable” -> “bogon”. When you increase the consequences of > an action, it’s often a good idea to review the potential causes of that > action and consider what avenues exist for erroneous triggers. > Absolutely, its a good idea to have measures in place to avoid any erroneous triggers and thats why I said APNIC can put operational practices in place for that. Its shouldn't be part of the policy. > > Also it’s seems you are fine with people advertising bogons just because > fixing it might make one/two people unhappy. > > > I’m not necessarily fine with people advertising bogons, but I’m also not > necessarily convinced that I want the RIRs to become the routing police. > > This proposal literally moves the routing police role from the hands of > those who run routers into the hands of the RIRs (well, specifically it > moves part of that role in one region into the hands of one RIR). > This policy is not doing anything special and giving extra powers to RIR. It happened when we (the community) agreed to move forward with RPKI. Any consequences you are relating to AS0 are also true for any other ROA. Whether its a good thing or bad, we can all have different opinion but its a reality.
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
