Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] End of LAST call

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Sun Feb 2 08:45:06 UTC 2020


Actually, we forgot it is much easier because there is one more point here.

This 24-hour period (or whatever timing is decided by AFRINIC operational procedure) to revocate the relevant AS0 ROA, if the member that just got that prefix allocated/assigned is using RPKI, his own ROA takes precedence over the AS0 one. So, he doesn't need to wait even a single minute.

So, the "24-hour delay" period is only an issue if the resource holder:
1) is NOT using RPKI
and
2) is using the new allocation/assignment in that 24-hour period

Again, AFRINIC may have already stats (or probably run a simple script for obtain them) to see what is the average delay from assignments/allocations to announcements. I bet is beyond several weeks if not months!

I've explained this as well here:

https://lists.afrinic.net/pipermail/rpd/2020/010282.html

Note that if there is a real case for that, I've put an example of an operational solution:
The impact may be that AFRINIC need to ask in the resource request form “if you’re not using RPKI AND *REALLY* intend to use the resources in the next 48 hours (to consider caches?) immediately after allocation, please mark this check-box”.

For example, if you really know, in advance, that when you get the prefix allocated you will announce it, the procedure could be:
1) You mark the check-box
2) AFRINIC procedure automatically, during the *evaluation* (which I guess typically takes several days), provisionally revoque the relevant AS0 ROA to free the requested prefix (making a new AS0 to cover the rest of the prefixes)
3) If the evaluation fails, a new AS0 ROA is done for the more specific prefix previously created (no need to revoque the previous one)
4) If the evaluation passes, there is not need for 1 extra day delay.

The revocation of the less specific AS0 ROA in 2 may be not needed, if AFRINIC, for example, already has several more specific AS0 ROAs for IPv6 /32, IPv4 /24, IPv4 /23 and IPv4 /22 (just a few examples). So they are ready for those cases where the resource holder not using RPKI indicates that they will use it "in minutes/hours". It is a kind of "buffer" of more specifics AS0 ROAs, that just need to be big enough to consider the "daily" average number of allocations/assigments (or may be for a complete week).

This is all operational procedures. The policy don't need to enter into that, because in fact there are several possible ways to handle it, while still following the policy.

Regards,
Jordi
@jordipalet



El 2/2/20 8:07, "Frank Habicht" <geier at geier.ne.tz> escribió:

Hi,

I trust that AfriNIC staff will only inform members of their new
delegations _after_ the changes to ROAs for non-delegated space were done.

[optionally AfriNIC could add to their email about resource delegation a
statement "because of previous issuance of a ROA of same prefix with
AS0, global routability might be delayed by 24h"; but this does not need
to be specified in policy]

After member is informed of the delegation, they will create ROAs, route
objects [possibly reverse DNS]; will start originating that prefix
globally via BGP...
and can only 24 hours later [SAD!!!] put production traffic on that prefix.

I think that's acceptable.
If you disagree, it's a small operational update internal to AfriNIC to
just wait 24 hours from the update of the ROAs until the member gets
informed of the delegation.

Regards,
Frank

On 02/02/2020 00:39, Daniel Yakmut wrote:
> To response to your questions,
>
>
> at least I will like to see about 24 hours, which will be minimally
> impactful, but the current infrastructure does not allow this small
> amount of time.
>
> The impact I possibly see is the delay in allocation.
>
>
> Simply,
>
> Danile
>
> On 31/01/2020 7:34 am, Frank Habicht wrote:
>> Hi,
>>
>> On 31/01/2020 08:51, Daniel Yakmut via RPD wrote:
>>> I don't agree with your submission that; "All of the “objections” I saw
>>> seemed to indicate a clear lack of understanding of RPKI in general and
>>> the proposal in specific."
>>>
>>> I particularly raised a concern "The current state of RPKI
>>> infrastructure, does not provide a sufficient period between revocation
>>> of ROA and notification that a given prefix has been allocated to an
>>> organization, which can impact considerably on allocations.
>> I would like to get more specific information:
>>
>> 1. According to you, Daniel: how much time does the "current state of
>> RPKI" provide between revocation of ROA and notification that a given
>> prefix has been allocated to an organization?
>>
>> 2. How much time would you consider "sufficient"?
>>
>> 3. which impact on allocations to you see?
>>
>>
>> Thanks,
>> Frank
>> (co-author)
>>
>>> Except we
>>> can be able to provide a sufficient period or create a different
>>> procedure, the proposal for the RPKI-ROAs does not fly"
>>> and I did not receive any response from the author(s), I suspect this is
>>> a concern that is critical and important to possible adoption and
>>> implementation this proposal
>>>
>>> However, I will agree that the author(s) may have been overwhelm with
>>> the number of "objections" raised and could not keep track of it and
>>> response, hence I will suggest that the co-chairs could help by
>>> summarising the objections for the action of the author(s).
>>>
>>> Simply.
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>> On 31/01/2020 3:18 am, Owen DeLong wrote:
>>>> I agree with Nishal, Jordi, and Frank.
>>>>
>>>> All of the “objections” I saw seemed to indicate a clear lack of
>>>> understanding of RPKI in general and the proposal in specific.
>>>>
>>>> All of them raised concerns that simply don’t fit the facts of what
>>>> is being proposed.
>>>>
>>>> I did not see any legitimate or critical objections. If there is
>>>> something I missed, please enumerate it (them) for the edification
>>>> of the list.
>>>>
>>>> Owen
>>>>
>>>>
>>>>> On Jan 29, 2020, at 03:58 , Nishal Goburdhan
>>>>> <nishal at controlfreak.co.za> wrote:
>>>>>
>>>>> On 29 Jan 2020, at 12:35, ABDULKARIM AYOPO OLOYEDE wrote:
>>>>>
>>>>>> Dear PDWG,
>>>>>> The following policy proposals have been on the Last call for
>>>>>> about 4 weeks
>>>>>> 1. Multihoming not required for ASN
>>>>>> 2. Adjusting IPv6 PA Policy
>>>>>> 3. RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space
>>>>>>
>>>>>> However, we received some critical objections that should be
>>>>>> addressed on
>>>>>> the policy named "RPKI ROAs for Unallocated and Unassigned
>>>>>> AFRINIC Address
>>>>>> Space" therefore we believe it requires more discussion.
>>>>> could you enumerate those “critical objections” please. that would
>>>>> help the authors to fix this for round two.
>>>>> from my perspective, the last series of responses, came from a
>>>>> fundamental misunderstanding of what RPKI is, and how it works.
>>>>>
>>>>> (bear in mind, that it’s not the authors’ - or this list’s -
>>>>> responsibility to explain RPKI ..)
>>>>>
>>>>> -n.
>>>>>
>>>>> _______________________________________________
>>>>> RPD mailing list
>>>>> RPD at afrinic.net
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>> _______________________________________________
>>>> RPD mailing list
>>>> RPD at afrinic.net
>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net
>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd

_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.






More information about the RPD mailing list