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

["Borchert, Oliver (Fed)" <[e-mail]>]

See inline for my comments

From: Claudio Jeker <[e-mail]>
Date: Thursday, May 18, 2023 at 5:04 AM
To: Borchert, Oliver (Fed) <oliver.borchert=[e-mail]>
Cc: [e-mail] <[e-mail]>, Borchert, Oliver (Fed) <[e-mail]>
Subject: Re: [Sidrops] Which 8210-bis error code should be used?
On Wed, May 17, 2023 at 06:56:45PM +0000, Borchert, Oliver (Fed) wrote:
> All,
>
>
>
> When processing the ASPA PDU of https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-sidrops-8210bis-10&data=05%7C01%7Coliver.borchert%40nist.gov%7Cbe7158429bf94b8d969008db577ee823%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C638199974800535960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BXUnFJllutHaMWJhJmsqFIOa1PGaanhEKBv9cpLNn9E%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis-10>, the profile draft https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-sidrops-aspa-profile-13.txt&data=05%7C01%7Coliver.borchert%40nist.gov%7Cbe7158429bf94b8d969008db577ee823%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C638199974800535960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2F7RHLX%2FTWzNrGo%2Fk3LbsM4LlXCDpjsReBA%2BQHtmKsTs%3D&reserved=0<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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-sidrops-aspa-verification&data=05%7C01%7Coliver.borchert%40nist.gov%7Cbe7158429bf94b8d969008db577ee823%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C638199974800535960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LP%2BMoCBGS8xt24dO0GPMVZZTabsMk3%2FByRR3%2BwzGQLQ%3D&reserved=0<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.

I don’t like it when drafts include implicit actions; that always leads to bad implementations, especially if implicit actions are expected to be taken.

I personally believe it is bad design to presume certain implications. Why not getting to the point and either use SHOULD or MUST. With SHOULD it makes it clear that there might be some implementations that follow the “or not” path and it means we need to have something in place that takes this case under account.
On the other hand, why being so shy and not demand what action is to be taken in the absence of an AFI and use a MUST. This reduces the change of unexpected behavior drastically.


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.

Reversing the implicit action from above, any single withdrawal of an ASPA PDU also results in the withdrawal of the PDU for the other AFI. And that should happen right away, otherwise it might not be possible to determine if the remaining PDU is just missing an AS0 PDU companion or if it is the leftover of a withdrawal of the other AFI PDU companion. Both would result in a different action to be taken.

Appendix B in https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-sidrops-aspa-profile&data=05%7C01%7Coliver.borchert%40nist.gov%7Cbe7158429bf94b8d969008db577ee823%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C638199974800535960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BzKNxjz67hgtnfpF77NKJyDPGxV0Nq26LvXY8ZKU1ag%3D&reserved=0<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 am very sorry to say but trying to ensure a behavior should at least include a should or SHOULD, otherwise means nothing. Even better is to use a “MUST” or don’t even bother.


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

I am completely in agreement with you on that point,

Oliver