Brian, Sorry I didn't reply sooner.
I found it very difficult to follow the details of your example, but I think there is a higher level consideration that makes moot a detailed analysis of optimization the you suggest.
In the early days of RPKI design I raised the same question that you did re allocation uniqueness, and suggested that we include RP checks for overlapping allocations in RP software. I was told (by operators) that the old INR holder and the new INR holder would each need to have certs (and ROas) that are valid, and that encompass the INRs being moved, and that persist for some time. That is a fundamental reason that the RPKI does not specify that the allocations are "unique." The term "unique" used to appear in the text of several of the docs, but was removed to accommodate INR transfers.
I think the primary concern is that one cannot be confident how quickly all RPs will acquire all RPKI data. Thus it seems prudent to allow for the old and new INR holders to have certs that contain the INRs being transferred, for these certs overlap in validity, and for both certs to be available via the repository system at the same time, for some overlap period. This enables old and new ROAs, which may point to the same ASN, to exist, avoiding the need for a flag day.
Steve _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
