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

[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