Re: [Sidrops] Which 8210-bis error code should be used?

[Claudio Jeker <[e-mail]>]

On Fri, May 19, 2023 at 02:26:09PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> Claudio, Oliver, and all:
> 
> 
> 
> How does this change in the verification draft (Section 4) sound to you?
> 
> This is the change you seem to be saying will fix the issue (eliminate the possibility of implementation error).
> We'll also reference this (or state it) in the main body (not appendix) of the profile draft.
> 
> 
> 
> OLD text:
> 
> 
>    If, despite the above recommendations, the ASPA(s) of a CAS includes
>    SPAS for one AFI but not for the other AFI (not even an AS 0), the
>    ASPA SHALL NOT be rejected just for that reason.  However, such an
>    ASPA(s) will be presumed to imply that the CAS has no providers
>    (equivalent to AS 0 SPAS) for the AFI that they neglected to include.
> 
> 
> 
> NEW text:
> 
> 
>    If, despite the above recommendations, the ASPA(s) of a CAS includes
>    SPAS for one AFI but not for the other AFI (not even an AS 0), a SPAS
>    containing only AS 0 MUST be included in the VAP-SPAS for the
>    neglected AFI for the CAS.  In this case, later if the ASPA(s) in
>    consideration is withdrawn and given no other ASPA changes for the
>    CAS, said SPAS containing only AS 0 MUST be removed from the VAP-SPAS
>    list, resulting in no entry in the list for the CAS (for both AFIs).
> 
> --------
> 
> Claudio: You were suggesting the following in your reply to Oliver:
> 
> >So you should not error out if an AFI object is missing instead an implicit
> >AS 0 entry for the missing AFI should be inserted. How this is done is up
> >to the implementation.
> 
> Would you say the need for new error code is obviated with the above change in text?
> 
> Do you see a need for any other changes in the profile or verification
> drafts on this issue?

I really deslike this change. It makes the current version even more
brittle and confusing. What about ASAP records that use an explicit AS0
entry. Do these now need to be removed?

I think all of this can be fixed by walking back and adjusting the
hop-check function and Section 5. Which I suggested some time ago.

There is no need for implicit AS0 entries if the hop-check function
definition is:


                          /
                          | "No Attestation" if there is no entry
                          |   in VAP-SPAS table for CAS = AS(i)
                          |   for all possible AFI values
                          |
hop(AS(i), AS(j), AFI) =  / Else, "Provider+" if VAP-SPAS entry for
                          \   CAS = AS(i) for the mentioned AFI includes
                          |
                          | Else, "Not Provider+"
                          \

Additionally the following text can be added to Section 5:

    The hop-check function MUST only return "No Attestation" if for all
    possible AFI values the result of the hop-check function (with equal
    AS(i) and AS(j)) is "No Attestation", if for any possible AFI value
    a different value is returned the result MUST be "Not Provider+".

With this in a lot of the confusing text in Section 4 can be removed.
Especially:
    If, despite the above recommendations, the ASPA(s) of a CAS includes SPAS
    for one AFI but not for the other AFI (not even an AS 0), the ASPA SHALL
    NOT be rejected just for that reason. However, such an ASPA(s) will be
    presumed to imply that the CAS has no providers (equivalent to AS 0 SPAS)
    for the AFI that they neglected to include.

Since these extra AS0 entries were only added to work around the
underspecified definition of the hop-check function.

-- 
:wq Claudio