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

[Claudio Jeker <[e-mail]>]

On Fri, Mar 24, 2023 at 11:35:35AM +1100, Aftab Siddiqui wrote:
> Hi Job,
> 
> 
> >
> > >      *   To make it clear “AS 0 ASPA MUST only have AS 0 as Provider
> > >          AS”, it doesn’t clearly mention that “normal” ASPA (non AS 0
> > >          ASPA) MUST NOT have AS 0 in the Provider AS.
> > >      *   In the absence of point ‘b’ what if AS 0 is added as Provider
> > >          AS in the ‘normal’ ASPA?
> >
> > I'm a bit unclear on what is meant with the above two points, can you
> > further clarify?
> >
> 
> As per the definition "An ASPA object showing only AS 0 as a provider AS is
> referred to as an AS0 ASPA." i.e. {CAS, AS(0)}
> Any ASPA which is not "AS 0 ASPA" is referred to in the draft as "normal
> ASPA" but it doesn't say that normal ASPA can't have AS 0 in the provider
> AS. i.e. {CAS, AS(139038), AS(0)}. Yes, there is no reason to have AS 0 in
> the provider AS but make it clear in the draft.
 
Adding AS0 to any ASPA object with other ASID in the SPAS is not altering
the outcome. {CAS, [AS(139038), AS(0)]} and {CAS, [AS(139038)]} are
equivalent. The big unsolved question is if the profile spec should limit
this alternative encoding (with the RP software enforcing that MUST).
 
> > >   4.  ROV vs ASPA validation states, keep the states consistent
> > (Unknown/notfound)
> > >      *   ROV States [valid, invalid, notfound] vs ASPA states [valid,
> > invalid, unknown]
> >
> > Why? Route Origin Validation and ASPA verification are two different
> > algorithms with different inputs and different outputs. To me it doesn't
> > seem to increase consistency.
> >
> 
> OK then why using terms like "valid", "invalid" and "unknown" why not just
> use "Provider", "Not Provider" and "No Attestation" because these are
> actual outputs of the function? don't you think the latter creates more
> clarity than the former?

Remember that "Provider", "Not Provider" and "No Attestation" are the
return value of the hop() function and only define the outcome of a single
hop lookup. These outcomes are very different from the end result.
I noticed that many people I talked to about ASPA get quickly confused
about the return values of the hop function and the resulting outcome of the
upstream/downstream algorithm. Often I got asked why a path is valid even
though one particular hop returned "Not Provider". This argumentation is
less confusing if the terms are not aligned.

So no, I think alignment of terms results in less clarity since there is
no immediate alignment from one output to the other.

-- 
:wq Claudio