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

[Claudio Jeker <[e-mail]>]

On Tue, Mar 07, 2023 at 08:36:19PM -0500, Christopher Morrow wrote:
> Guess who's not jumping the gun this time?? <this guy!>
> 
> Ok, the authors have asked ot re-issue this WGLC!!
> I believe 3/22 will be 'just before ietf meeting' (25th start) so that
> MAY be a little tight, if so we can skip til 4/12/2023. Either way,
> please give the updated version:
>   https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/
> 
> a solid read/consider and let's see how things feel by F2F meeting time?
> 
> Thanks for hanging in there:
>   https://m.media-amazon.com/images/I/41iPPNniyOL._AC_.jpg
> 
> -chris
> co-chairiot
> 

I had a look at draft 12. It is a great step but I see still a few points
that need some work:

Section 3:

    The CAS can choose to specify an AFI (i.e., afiLimit = 1 for IPv4 or 2 for
    IPv6) in the ASPA or it may omit it in which case the ASPA applies to both
    IPv4 and IPv6.

This is incorrect the AFI is per Provider AS and not per ASPA.

Because of this the notation (AS1, [AS2,...], AFI) also does not follow
how the profile in [I-D.ietf-sidrops-aspa-profile] is specified. The
profile defines a record as (AS1, [AS2 [AFI], ...]). This discrepancy
results in further question marks and problems down the road.

Section 4:

    It is RECOMMENDED that the afiLimit parameter in the ASPA object be left
    unspecified (unless there is compelling reason to specify) so that the
    ASPA applies to both IPv4 and IPv6 prefixes.

Again, the afiLimit is part of ProviderAS object and therefor it applies
to the providerASID and not the ASPA. It is enough to fix this like:

    It is RECOMMENDED that the afiLimit parameter in the ProviderAS object
    be left unspecified (unless there is compelling reason to specify) so
    that the providerASID applies to both IPv4 and IPv6 prefixes.

There is a lot of MUST in this section that feel off:
    Any AS, including an RS AS, MUST have an ASPA.
If it is this simple to make everyone create an ASPA record...

    An RS AS MUST register an AS 0 ASPA.
I think this needs to be a SHOULD, I think there are still RS AS that
actually have transit providers and for them the ASPA should include these
providers.

I think the definition of AS0 ASPA and normal ASPA is not helpful. There
is no other reference in the text for normal ASPA. Wouldn't it be better
to actually describe the effect of a 0 providerASID?
In the end you could create the same with a providerASID of 23456, 65535
or 4294967295. The goal is to create an ASPA record that returns "Not
Provider" for any valid provider AS (PAS) and AFI in hop(AS, PAS, AFI).

Section 5:

More AFI nightmares in figure 1:
          "no Attestation" if AS(i)
          does not have ASPA (i.e., VAP)
          for mentioned AFI

Again there is no conept of an ASPA for mentioned AFI. So what does that
mean? I already asked this question and did not get a reponse. So let me
ask again:

Consider the following ASPA entry:
	customerASID: 42
	ProviderASSet: [ { providerASID: 4242, afiLimit: 0001 } ]
an ASPA entry for AS42 with a single provider AS4242 that is limited to
IPv4.

What is the result of hop(42, 4242, 2) and what about hop(42, 123, 2)?

The specification is ambiguous in this case because both "Not Provider"
and "no Attestation" could be considered a valid outcome. Now my view is
that the result MUST be "Not Provider" since 42 has an ASPA record but
this really needs to be clarified before this draft can pass WGLC.

-- 
:wq Claudio