Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Claudio,

Thanks again for your comments. I have a draft v-14 (verification) which I will upload to the IETF in a few days. I have incorporated your latest comments there. I have also provided edits for draft v-13 (profile) in Github where I have included new text to incorporate your comments that pertain to that draft (see text copied below).

>First of all I think large parts of Section 3 and 4 should also be added to the aspa-profile specification. An RP / RTR implementer may only glance at draft-ietf-sidrops-aspa-verification-13 and miss these bits.

The material in Sections 2 and 4 (verification draft) firmly belongs in the verification draft as it relates closely to verification. I thought there should be no repetition (of whole sections) but instead, a strong coupling was needed between the two drafts. I have done that with additional text in updated Sections 1 and 3 in the profile draft. I've added texts as follows:

In the Intro Section 1 (profile draft):

   The BGP Roles that an Autonomous System (AS) may have in its peering
   relationships with eBGP neighbors are discussed in
   [I-D.ietf-sidrops-aspa-verification].  The details of ASPA
   registration requirements for ASes in different scenarios are also
   specified in that document.  In addition, the procedures for
   verifying AS_PATHs in BGP UPDATE messages using Validated ASPA
   Payloads (VAPs) are described in that document.

In the Section 3 (profile draft):

   A user registering ASPA(s) must be cognizant of Sections 2, 3, and 4
   of [I-D.ietf-sidrops-aspa-verification] and the user (or their
   software tool) must comply with the ASPA registration recommendations
   in Section 4 of that document.

>I wonder if instead of talking about fixing ASPA(s) the text could be altered to work on the VAP-SPAS.

The text in Section 5 already talks about using VAP-SPAS in the hop-check function. It carries over naturally into Section 6 algorithms. 

>So it is clear that this fixup should happen in the BGP instance when compiling the VAP-SPAS tables.

I have added this new text at the top of Section 5 (verification draft):

   An implementation may make its own choice regarding maintaining a
   single VAP-SPAS table or two separate tables (i.e., one per AFI).
   The former choice may have the advantage of memory savings and higher
   cache-hit ratio, while the latter may be faster for memory lookups.

About the Provider+ terminology, I think that actually works well (Amir Herzberg also liked it). To think about hop-check outcome as Provider or Not Provider seem more intuitive (in the route leaks context) rather than some other terminology (like match and mismatch).

For further clarity, I have added this wording immediately following the hop-check function definition (in Section 5) where Provider+ is used:

   To be clear, this function checks if AS(j) is included in the VAP-
   SPAS of AS(i), and in doing so it does not need to distinguish
   between Provider, non-transparent RS, and Sibling.

>At least extend the RS to non-transparent RS in:
>       A provider AS ID included in the SPAS can correspond to a Provider, RS, or
>         Sibling.  An RS is effectively a Provider to its RS-client.
>
>Since the AS IDs of transparent RSs are not supposed to be in SPAS.

Done.  s/RS/non-transparent RS/. Good catch.

Thank you.

Sriram
==========================


-----Original Message-----
From: Claudio Jeker <[e-mail]> 
Sent: Friday, March 31, 2023 5:53 AM
 
Hi Sriram,

I had a look at draft-ietf-sidrops-aspa-verification-13 changes.

First of all I think large parts of Section 3 and 4 should also be added to the aspa-profile specification. An RP / RTR implementer may only glance at draft-ietf-sidrops-aspa-verification-13 and miss these bits.

I think Section 4 is quite good. It ensures that a CAS always includes something for both AFI. I wonder if instead of talking about fixing
ASPA(s) the text could be altered to work on the VAP-SPAS. So it is clear that this fixup should happen in the BGP instance when compiling the VAP-SPAS tables. I suggest that since the ASPA SHALL NOT not be rejected and since VAP-SPAS need to build the union of all all ASPA objects it is the right place to ensure this.

In my opionion the introduction of "Provider+" in Section 5 is not helpful. Also the whole additoin about possible roles is just confusing and not helpful. The Hop-Check Function is role independent it only looks at the SPAS set. So talking about roles is unnecessary there. If people put wrong things in their ASPA object they do get what they want.
If people think that "Provider" is an overloaded term then maybe some other alternative could be used:
   "Provider+" -> InSPAS or match
   "Not Provider+" -> notInSPAS or missmatch
   "No Attestation" -> keep term, noCAS or notFound

At least extend the RS to non-transparent RS in:
   A provider AS ID included in the SPAS can correspond to a Provider, RS, or
   Sibling.  An RS is effectively a Provider to its RS-client.

Since the AS IDs of transparent RSs are not supposed to be in SPAS.

I have no big opionion about Section 8 and 12 changes. My big conclusion from those sections is mainly that CAS should minimize the SPAS they announce (and a reason why I insist that non-transparent RS are not put into SPAS).

--
:wq Claudio