[rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02

[Ben Maddison]

Hi Patrick,

On 02/13, Patrick Okui wrote:

> On 13 Feb 2021, at 16:26 EAT, Ben Maddison via RPD wrote:

> 

> > At time t2, the RIR re-allocates 2001:db8:foo::/48 to member Y, who also

> > has AS65001.

> > Member Y issues ROA:

> >     2001:db8:baa::/48 asID:65001

> 

> Bad things will always happen if member Y attempts to create a ROA different

> from what they were allocated.

> 

> If I understand correctly at time t2 2001:db8:baa::/48 is still legitimately

> allocated to AS65000.


I don't think that you got the point that I was trying to make.
Apologies if my explanation was unclear.

The hypothetical timeline is:
t0: AS65000 has 2001:db8:f00::/48, and has issued a ROA for it, and
    originates it in BGP;
t1: The allocation of 2001:db8:f00::/48 is revoked (why is not
    important). The RIR shrinks the resources on the member CA cert,
    making the AS65000 ROA "disappear".
t2: AS65001 receives 2001:db8:f00::/48, and issues a new ROA (with
    asID:65001), and begins originating the prefix in BGP.

The bit that this policy adds is that at t1 the RIR would also issue an
AS0 ROA for the prefix.

The point I was making is that this only changes the validation status
of a bogon announcement during the interval t1-t2.
After t2, the newly issued ROA (with asID:AS65001) is sufficient to make
any lingering bogon announcements ROV-Invalid. The presence, or not, of
an AS0 ROA becomes irrelevant.

Thus, any suggestion that this policy makes *re-allocation* of resources
easier is bogus. It *only* helps to clean up bogons.

Hope that makes more sense?

Cheers,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210215/9ee8dcda/attachment.sig>