Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

[Tim Bruijnzeels <[e-mail]>]

Hi,

> On 25 Mar 2023, at 01:07, Lubashev, Igor <ilubashe=[e-mail]> wrote:
> 
> Comment 1.
> 
> ASPA Profile draft (3. ASPA eContent) says: "all Provider ASes MUST be registered in a single ASPA object".
> ASPA Verification draft (4. ASPA Registration Recommendations) says: "An AS SHOULD NOT have more than one ASPA".
> 
> Since the two drafts are both in the WGLC, it is best if they adopt the same recommendation and choose a MUST or SHOULD here.  My view is that a SHOULD is more appropriate, since the Verification draft already specifies taking the union of ASPA registrations, so multiple registrations could work, albeit in a more fragile way (hence a SHOULD). But agreeing on SHOULD/MUST seems more important than which one is picked.

I believe that SHOULD is appropriate.

But, I also believe that it would be better to move all considerations about ASPA objects, object validation, the definition of Validated ASPA Payloads (VAPs), and a formal specification of how to make a union to the profile document.

The reason for this is that the verification process runs in a BGP speaker, and it will get its data through the RPKI-RTR protocol. Validation and synthesis of any applicable union to get the VAPs will have happened before this point. So, while it should be discussed, I think it's actually not relevant any more in the verification context. The information of whether a given VAP came from 1 or multiple objects (and possibly SLURM at some point) is not available and cannot drive the verification process.

More to the point of SHOULD vs MUST of a having a single object per Customer AS (CAS). I think SHOULD is appropriate. I am not suggesting to add the following to the documents, but to exemplify why multiple objects may exist: there can be transfers of ASNs between organisations or business units, or transfers between RPKI server implementations (rir-hosted to self-hosted, between self-hosted, etc). In such cases a make-before-break policy may be beneficial.

Regarding unions of ASPA objects for the same CAS. This is not formally specified. It may be self-evident, but even if it _is_ obvious it would not hurt to be explicit.

Merging the VAPs from multiple ASPA objects for the same CAS can be done as follows. The RPKI Relying Party (Validator) creates two sets of providers ASNs, one for IPv4 and one for IPv6. Any provider ASN in any of the VAPs that is found to have no afiLimit is added to both sets. If there is an afiLimit then the provider ASN is added to the corresponding set only. Duplicates are ignored (i.e. these are sets). At the end of the process a new VAP can be created. Any provider ASNs that are found in only one of the two sets get the corresponding afiLimit. Any provider ASNs that are in both sets get no afiLimit.

To the authors mainly: please let me know if the above procedure is incorrect. All the more reason for documenting it I would say ;)

Tim