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

[Job Snijders <[e-mail]>]

Hi folks,

Thanks for your time and message.

On Thu, Mar 23, 2023 at 01:22:32PM +0000, Amreesh Phokeer wrote:
> Thank you to all those involved in this draft. We have reviewed the
> document and here are our comments:
> 
>   1.  Section 4: “An AS SHOULD NOT have more than one ASPA”
>      * It should be clarified that one ASPA per AFI is tolerated

Why?

>      * How do you do “make before break” in case an AS is changing
>        provider or in the case of a resource transfer?

I feel I'm perhaps missing some context behind this question.  Isn't it
standard make before break? Add the new provider, set up BGP
configurations accordingly, decommission BGP with the old provider, and
then update the ASPA? 

>   2.  VAP: it is unclear whether how the VAP will be merged but
>       grouped by AFI in the case of multiple ASPAs?

Ok, I suppose some 'merging' examples can be added in a non-normative
Appendix. Something along the lines of "given ASPA 1 and ASPA 2, the VAP
outcome is ABC". Thank for the suggestion.

>   3.  Validation of the ASPA payload
>      *   A Customer ASID cannot be 0, should it be mentioned in the
>          document or rather in the profile document?

I'm not entirely sure its worth mentioning: the CustomerASID is
constrained through the RFC 3779 delegation of authorizations: it seems
unlikely a RIR will delegate the ability to sign for AS 0 to any LIR.
Secondly, 'AS 0' cannot appear as value in BGP AS_PATHs, so such an ASPA
would never match any BGP updates.

>      *   To make it clear “AS 0 ASPA MUST only have AS 0 as Provider
>          AS”, it doesn’t clearly mention that “normal” ASPA (non AS 0
>          ASPA) MUST NOT have AS 0 in the Provider AS.
>      *   In the absence of point ‘b’ what if AS 0 is added as Provider
>          AS in the ‘normal’ ASPA?

I'm a bit unclear on what is meant with the above two points, can you
further clarify?


>   4.  ROV vs ASPA validation states, keep the states consistent (Unknown/notfound)
>      *   ROV States [valid, invalid, notfound] vs ASPA states [valid, invalid, unknown]

Why? Route Origin Validation and ASPA verification are two different
algorithms with different inputs and different outputs. To me it doesn't
seem to increase consistency.

Thanks for the feedback so far!

Kind regards,

Job