Re: [Sidrops] Making ASPA AFI-Agnostic - coordination

[Alexander Azimov <[e-mail]>]

The second measurement was done in a different direction.
I've measured the number of c2p pairs that are visible only in v4 while
both customer and provider support v4 and v6.

This time numbers are even higher. The number of 'missing' pairs is 12418
from 53968 (23%). It affects 8481 unique ASNs.
The overall number of affected ASNs from the two measurements is 10364.
Relatively high numbers.

For me it raises several questions:

   1. The main point to remove the AFI flag is possible simplification at
   the router side: it will have a single cache of processed/invalid paths
   instead of two hashmaps for v4 and v6. I wonder if anybody has measured the
   memory requirement for such a cache? Keeping in mind, that it should be
   cached with limited ttl. Or may be we just don't need cache since it
   have linear complexity?
   2. What is the trend for the above numbers? Is there a trend in the diff
   reduction during the last years?
   3. Is it possible to model these relaxed rules to see the effect in
   number of leaks?


During next week I'll try to cover point 2. I wonder if anybody from
vendors made implementation evaluations for point 1.
And I'd love to see double check of the above data.


пт, 9 июн. 2023 г. в 18:16, Alexander Azimov <[e-mail]>:

> Gentlmen,
>
> Thank you for your patience.
>
> I believe we are at an important point when the number of prototypes
> related to ASPA objects is not high and we can still change the object
> structure.
> But it should not be done in rush. We are already facing compatibility
> issues with the RTR protocol, let's not make the same mistake twice.
>
> I've made several measurements to find out if it is safe to drop AFI flag
> in ASPA object.
> The idea behind lays in the assumption that IPv4 and IPv6 connectivity is
> merging with the growing adoption of IPv6.
>
> With that in mind, the set of IPv6 c2p pairs should be included in the set
> of IPv4 pairs.
> So, I measured the difference: the number of c2p pairs, where the customer
> supports both v4 and v6 but the selected pair is not visible in v4.
>
> I've got 4149 c2p pairs that are visible only IPv6 from overall 43470 such
> pairs (9.5%).
> This affects 3516 unique ASNs from overall 24286 ASNs with dual stack
> (11%).
>
> The biggest input comes from HE operations, which acts as a provider for
> 1242 ASNs only in v6 while running open peering policy in v4.
>
>
> чт, 8 июн. 2023 г. в 21:20, Job Snijders <job=[e-mail]
> >:
>
>> On Thu, Jun 08, 2023 at 06:12:10PM +0200, Martin Hoffmann wrote:
>> > Russ Housley wrote:
>> > >
>> > > In CMS, the version number indicates which alternatives are possible
>> > > in some CHOICEs.  The point is to ensure that the ASN,1 decode
>> > > operation will work if you recognize the version number.
>> >
>> > But, crucially, the overall structure remains the same. The new version
>> > of the draft changes the structure of the ProviderASSet which I think
>> > warrants to treat this as an entirely new definition and use a new
>> > content type OID.
>>
>> Another relevant question is whether we want to have a 'grace period' in
>> which both formats are valid. I myself would prefer to make this is a
>> 'hard cut', simply a breaking change to avoid the complications of
>> supporting both profiles in my RP implementation.
>>
>> As far as I know there is only one ASPA verifying deployment (YYCIX),
>> and the few already-existing ASPA objects can probably easily be updated
>> through a software update.
>>
>> If the group accepts it as a 'breaking change' and commits to work to
>> migrate the tiny ASPA ecosystem in the span of a few weeks, I see less
>> of a need to get a new content-type OID. Technically if 'breaking
>> change' is the choosen path forward, there wouldn't even be a need to
>> bump the version of contained in the eContent.
>>
>> However, bumping the version contained in the eContent is be a novelty
>> in the RPKI ecosystem, so keep things as-is (profile-15) might have some
>> value as a learning experience for this community.
>>
>> In this situation I suspect there aren't objectively right or wrong
>> choices, but in the interest of time we should converge and agree rather
>> sooner than later on one of the options.
>>
>> For previous ASPA profile changes no new OID were requested.
>>
>> Kind regards,
>>
>> Job
>>
>> _______________________________________________
>> Sidrops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidrops
>>
>
>
> --
> Best regards,
> Alexander Azimov
>


-- 
Best regards,
Alexander Azimov