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

[Claudio Jeker <[e-mail]>]

On Wed, May 17, 2023 at 06:56:45PM +0000, Borchert, Oliver (Fed) wrote:
> All,
> 
> 
> 
> When processing the ASPA PDU of https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis-10, the profile draft https://www.ietf.org/archive/id/draft-ietf-sidrops-aspa-profile-13.txt and in particular Appendix A mentions that: “Note that two PDUs are always generated per Customer ASID: one with AFI Flags = IPv4 and one with AFI Flags = IPv6.”. This requires when using 8210bis to propagate the data to the router (client) that 2 separate PDU’s need to be generated because a single ASPA PDU only contains provider information for a single AFI.
> 
> Question:
> =========
> What error code should I use when the router only receives in total one of them?
> 
> The fact that the content for IPv4 and IPv6 are not in the same PDU might make this a possibility. I checked the error codes and at this point I only can think of error code 0.
> 
> 0: Corrupt Data (fatal):
> The receiver believes the received PDU to be corrupt in a manner not specified by another error code.
> 
> Though the received PDU is not corrupted, data is missing and should trigger an error.
> Would it make sense to add a new error code that deals with the missing ASPA PDU?
> 
> 
> Furthermore, this requirement does add additional workload on the router? The ASPA PDU’s for AFI=IPv4 and AFI=IPv6, let’s call them ASPA-PDU pairs for simplicity, might not be send in sequence, there is no requirement to do so and with the lack thereof, one should not expect it to. Maybe the cache processes first all AFI=IPv4 and then all AFI=IPv6 PDU’s. In this case the router needs to parse through all data it received to assure all ASPA-PDU pairs are accounted for.
> 
> Now after the initial set of ASPA-PDU siblings were received, the AFI=IPv4 ASPA data changes for one ASPA object and therefore triggers the need for an update. Because both PDU’s were send already, only the AFI=IPv4 PDU needs to be generated. The AFI=IPv6 PDU remains the same and therefore no re-send is necessary. Here too, the router, in order to comply with the requirement listed in Appendix A of the profiles draft, must verify that all ASPA-PDU pairs do exist and throw an error if not.
> 
> Should there be more wording in any of the drafts to address this situation?
> 

All of this is covered by Section 4 of
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification

    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.

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.

Btw. the router needs to merge all ASPA data received from RTR sessions
and static config and at that point that rule has to be applied. It can
already be done for each source as well but be careful if you add implicit
elements they need to be removed when the ASPA object covering the other
AFI for that CAS is removed.

Appendix B in https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile
tries to ensure that RTR cache servers provide full coverage so that the
ASPA objects at the router are always fully specified. This is good
practive but not a requirement in terms of a MUST clause.

I do not like how this is handled in this set of drafts. It is the number
one question that pops up over and over again.
-- 
:wq Claudio