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

[Claudio Jeker <[e-mail]>]

On Tue, Mar 28, 2023 at 04:41:57AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> All: I just uploaded a revised draft version -13. All comments received in this thread have been carefully considered and changes incorporated as necessary.
> Version-13 Draft: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ 
> Diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-verification-12&url2=draft-ietf-sidrops-aspa-verification-13&difftype=--html 
> 
> Hi Claudio: I went with many of your suggestions below and earlier. It
> is easy enough to assume a single VAP-SPAS table even in the description
> in this doc. You should like what I did in the revised Sections 3, 4,
> and 5. 
> 
> Igor: I addressed your discomfort with the earlier rosier description of
> the merits of ASPA verification in Section 8. I now systematically
> describe the key properties (mitigation capabilities) in Sec. 8 and the
> limitations are stated in Section 12. Hopefully, you'll find it accurate
> and more insightful.
> 
> Tim, Job, Martin, and others: Your comments/discussions relating to
> Sections 3 and 4 carefully considered and folded in.
> 
> Amir, Nan:  The changes promised are included.
> 
> Amreesh, Aftab, Yangyang: Please review the diff. You should find your
> comments addressed as well.
> 
> Please let me know if missed anything important. 
> 
> Thanks to all who have kindly devoted time to reading and giving feedback. 
 
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