Re: [Sidrops] some wording improvements in draft-ietf-sidrops-aspa-verification

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

Also, to remove any confusion, I propose a modification in the ASPA Profile draft to completely remove the Note in Appendix B that reads:


  Note that two PDUs are always generated per Customer ASID: one with
  AFI Flags = IPv4 and one with AFI Flags = IPv6.

Oliver

From: Sriram, Kotikalapudi (Fed) <[e-mail]>
Date: Monday, May 22, 2023 at 12:53 PM
To: Claudio Jeker <[e-mail]>
Cc: Borchert, Oliver (Fed) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: some wording improvements in draft-ietf-sidrops-aspa-verification
[We are now talking about edits in the ASPA verification draft;
so I've changed the subject line;
it was "Re: [Sidrops] Which 8210-bis error code should be used?"]

Claudio,

It appears we are converging well. Thanks for your suggestions. I've incorporated them.

The paragraph in consideration is now simplified as follows (the "Note: ..." stuff is deleted):

   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), then
   for AS_PATH verification purposes, the CAS is considered to have no
   providers (i.e., absent VAP-SPAS) for the neglected AFI (see the hop-
   check function computation in Section 5).

I have improved the hop-check function description per your suggestion as follows:

                                             /
                                             |  "No Attestation" if there is no entry
                                             |     in VAP-SPAS table for CAS = AS(i)
                                             |     regardless of the AFI value
                                             |
   hop(AS(i), AS(j), AFI) =  /   Else, "Provider+" if a VAP-SPAS entry for
                                            \     CAS = AS(i) for the mentioned AFI
                                            |     is present and includes AS(j)
                                            |
                                            |  Else, "Not Provider+"
                                            \

Also made the following change for clarity regarding the "No Attestation" outcome (in Section 5 after the above equation):

OLD text:

    The hop-check function is AFI dependent because an AS may have
    different SPAS for different AFI.

NEW text:

   The "No Attestation" result is returned only when the CAS = AS(i) has
   no ASPA(s) registered or none of its ASPAs are cryptographically
   valid, resulting in no entry for the CAS in the VAP-SPAS table
   (regardless of the AFI value).  The hop-check function is AFI
   dependent because an AS may have different SPAS for different AFIs.

Thanks.

Sriram

==============================

From: Claudio Jeker <[e-mail]> Mon, 22 May 2023

On Mon, May 22, 2023 at 05:05:21AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> Oliver and I have discussed the issue off-list. Requiring an artificial
> insertion of an AS 0 only VAP-SPAS for the neglected AFI for the CAS is
> not required. The verification algorithm (hop-check function in Section
> 5) inherently takes care of the neglected AFI (absent VAP-SPAS)
> situation.

I agree with this direction. I suggested a very similar change in a
previous mail.

> The previously proposed text change (
> https://mailarchive.ietf.org/arch/msg/sidrops/C5newCanz60yBNc6myoEZfQnMoc/
> ) is retracted.
>
> But a slight modification of the paragraph in consideration would be
> good as follows:
>
>
> 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), then
>    for AS_PATH verification purposes, the CAS is considered to have no
>    providers (i.e., absent VAP-SPAS) for the neglected AFI (see the hop-
>    check function computation in Section 5).  (Note: Artificial
>    insertion of an AS 0 only VAP-SPAS for the neglected AFI for the CAS
>    is not required.)

I think one should just remove this section and offload all of this into
Section 5. Especially the added Note: does not help at all and is just
confusing for a reader of the draft/RFC who does not know the backstory.
We need to write this for people not knowing all the discussions we had.

> The hop-check function is slightly tweaked as follows:
>
>                              /
>                              | "No Attestation" if there is no entry
>                              |   in VAP-SPAS table for CAS = AS(i)
>                              |
>    hop(AS(i), AS(j), AFI) =  / Else, "Provider+" if a VAP-SPAS entry for
>                              \   CAS = AS(i) for the mentioned AFI
>                              |   is present and includes AS(j)
>                              |
>                              | Else, "Not Provider+"
>                              \
>
>
> This is basically the same function definition as before but makes it
> clearer that since VAP-SPAS is absent for the neglected AFI, there would
> be no match in the VAP-SPAS for AS(j) and hence the outcome for that AFI
> would be "Not Provider+".

While already better I prefer if in the "No Attestation" case a clear
statement that this applies to all possible AFI values.
A possible option is:
                             | "No Attestation" if there is no entry
                             |   in VAP-SPAS table for CAS = AS(i)
                             |   independent of the AFI value

I really prefer the definition of the hop-check function to be explicit
to avoid any possible misinterpretation.

--
:wq Claudio