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

[Claudio Jeker <[e-mail]>]

On Thu, May 18, 2023 at 05:13:12PM +0000, Borchert, Oliver (Fed) wrote:
> See inline for my comments

It is really hard to find your comments since your mailer fails to
properly increase the quoting level. I tried to fix this.
 
> > 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 agree that right now the situation is still not optimal. It is way
better than a few versions ago where there was no implicit action but
instead just a lot of confusion.
 
> 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.

I think there is only one MUST needed. In the definition of the hop-check
function there needs to be something along these lines:

    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 any lookup returns a different
    value the result of the lookup MUST be "Not Provider+".

> > 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.

RTR needs to send a consitent snapshot between "Cache Response" and "End
of Data". So if the RTR cache is adding extra AS0 PDU it also MUST
remove them. An RTR cache not behaving like this is broken.

In my workflow the RTR caches don't need to add extra entries (they can if
they like) since there is no need to add any implicit entries at that
level. At the router all VAP (from all possible sources) are forming the
lookup table via a union. Only at that point some action is needed to
ensure that the hop-check function works according to standard.
In short:
  Only return "No Attestation" if there is no CAS = AS(i) for any AFI in
  the routers ASPA lookup table.

How you get there is up to you. If you implement per AFI lookup tables you
may need to either do an extra search in the other AFI's lookup table or
you inject AS0 entries. In OpenBGPD the CAS lookup is not AFI dependent
and so there is no need to do anything special.
 
> > 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.
 
In the overall design of the ASPA flow it is not a MUST requirement.
Adding a SHOULD in an Appendix seems a bit strange mainly because all
these changes would need to be in draft-ietf-sidrops-8210bis.

> > 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

-- 
:wq Claudio