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

[Martin Hoffmann <[e-mail]>]

Hi Sriram!

> All: I just uploaded a revised draft version -13. All comments
> received in this thread have been carefully considered and changes
> incorporated as necessary.

[...]
 
> Tim, Job, Martin, and others: Your comments/discussions relating to
> Sections 3 and 4 carefully considered and folded in.

I am coming around to thinking this would all be much easier to explain
and understand if we followed the lead provided by 8210bis and talked
about these provider sets on a per-AFI basis.

Ie., explicitly describe an algorithm to take all ASPA objects[0] for a
given customer ASN and produce one provider ASN sets for each supported
address family. The remainder of the text then can describe everything
within the context of the single address family for which verification
is performed. Crucially, including the requirements for the resulting
set of provider ASNs[1] for various classes of customer ASes.

For instance, an AS0 provider set is one that only consists of AS0. How
you got there doesn’t need to be explained since it follows directly
from the algorithm.

This eradicates all the complicated text about afiLimit being present
or not.

In addition, it fixes the disconnect between 8210bis and the
verification draft which I feel has gotten worse in the latest
reviwsion of the verification draft. Now the notation explicitly
includes the afiLimit which isn’t something you have if you got your
ASPA data via RTR (or any other format, really, since they all will
follow the RTR lead because that is the data structure that relying
party software will keep). So pretty much every implementer actually
has to work backwards and derive their own algorithm.

If you work with a separate set of provider ASNs per address family,
the notation in section 3 turns in a triple of (AS x, afi, {AS y1, AS
y2, ... }) which is much simpler to understand and also greatly
simplifies the hop-check function in section 5.

  -- Martin


[0] Both ASPA drafts sometimes use the term "ASPA record" and sometimes
    "ASPA objects" -- that should probably be cleaned up into one single
    term, presumably "ASPA object" since that is the term used for all
    the other things appearing in RPKI.
[1] This is likely fight windmills, but the number of abbreviations in
    this document is reaching aviation levels. I honestly believe it
    would be much easier to understand all of this if it would to define
    and the use words and compounds instead such as customer (or
    possibly customer ASN) instead of CAS or provider set instead of SPA
    (I just read it and already can’t remember what the S is for).