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

[Martin Hoffmann <[e-mail]>]

Claudio Jeker wrote:
> On Thu, Mar 23, 2023 at 01:22:32PM +0000, Amreesh Phokeer wrote:
> > Hello,
> > 
> > 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  
> 
> In general this is a bad adivice and therefor should not be further
> clarified.

I don’t think that’s what the comment is about. Rather, there is an
inconsistency in the document. Section 4 first RECOMMENDS against using
the AFI limit and then proceeds to say you SHOULD only have one ASPA
objects. This can be interpreted that if you are using the AFI limit
(which you are allowed to, it is just not recommended), you still can
only have one ASPA object. So, if you use the AFI limit, you can only
use ASPA for IPv4 or IPv6 but not for both. Surely that is not the
intention?

> As with all ASPA objects the RP software and router must
> build the union of all providers per CAS. Now one could issue an
> object per provider and AFI but it is not a very sensible thing to do.
> 
> The CAS is the primary lookup key.

Is it? In RTR, an ASPA entry contains both a mandatory customer AS and
a mandatory AFI -- you cannot say “this entry is for both.” This means
that in RTR land, the ASPA sets for IPv4 and IPv6 are distinct. The
primary key is the pair of customer AS and AFI.

This is the disconnect I mentioned earlier -- perhaps I posted this to
the wrong thread. The verification draft talks about things in terms of
the ASPA objects published but a router actually implementing it has to
build its data structures based on RTR.

Thus, the verification draft follows your argument: Don’t use the
afiLimit, have one ASPA object for your customer ASN. But 8201bis then
twists that around and has a mandatory AFI field on the RTR PDU.

Given that this is already leading to confusion here, it should
probably be resolved before publishing.

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

That the sets of provider AS of multiple ASPA objects for the same
customer AS should be merged is only mentioned in 8210bis but at no
point in either the profile or verification drafts. One of them should
probably spell out how the (on or two) VAPs for a customer AS are to be
created from a the set of ASPA objects.

  -- Martin