Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt

The separated records for v4 and v6 ASPA were inspired by the previous
research that showed a significant difference in the peering relations in
v4 and v6 respectively.
I did this research a couple of years ago, it will be interesting to check
if the situation has significantly changed.

I'd like to get the WG attention on the introduced update of ROA processing.
The current version of the RTR protocol related to ROAs is vulnerable to
possible race conditions: if the prefix has multiple ROA records or it
covering prefixes with different origin asn the state of the partial update
may lead to invalidating of really valid prefixes. Here is fresh statistics:

   - 16153 IPv4 prefixes with equal (5486) or more specific (11872)
   conflicts;
   - 2250 IPv6 prefixes with equal (1202) or more specific (1164) conflicts.

The current proposal addresses this issue for ASPA and ROAs in a different
way:

   - For ASPA a single PDU per customer AS is neveling the issue;
   - For ROAs the draft introduces ordering of the updates + suggests
   sending updates with the same prefix back to back.

The way ROAs will be processed decreases the chances that valid prefixes
will be marked as invalid, but they are not zero. My thinking is, that
since RTR protocol is negotiating its version at the start of the session
there is no need to keep full backward compatibility with the way ROAs were
processed previously. Instead, we can change ROA RTR PDUs is the same
fashion as it is introduced for ASPA: a single PDU for a selected prefix
that replaces previous records.

вт, 10 мар. 2020 г. в 06:22, Randy Bush <randy@psg.com>:

> > As a separate note, ASPA in its current form includes the address
> > family, ie., it has different ASPA objects for v4 and v6. This is
> > missing from the proposed ASPA RTR payload PDU, but luckily there is
> > enough zero space to include it.
>
> i believe this is addressed in the draft out today; though not exactly
> in the way you suggest.  thanks again for pointing this out.
>
> randy
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>

-- 
Best regards,
Alexander Azimov