Re: [Sidrops] [[e-mail]: New Version Notification for draft-spaghetti-sidrops-aspa-slurm-00.txt]

[Russ Housley <[e-mail]>]

I am hearing several peopl speak in support of this work getting done, and I am hearing some of the original SLURM authors offering to help finish the work.

Could one of the authors talk about this I-D at IETF 116?

Russ

> On Feb 23, 2023, at 12:33 PM, Job Snijders <job=[e-mail]> wrote:
> 
> Hello Tim, Di Ma, others,
> 
> On Thu, Feb 23, 2023 at 05:23:28PM +0100, Tim Bruijnzeels wrote:
>>> On 23 Feb 2023, at 14:03, Job Snijders <job=[e-mail]> wrote:
>>> While working on running code implementations to support RFC8210bis
>>> in StayRTR and OpenBGPD, it dawned upon us that SLURM for ASPA
>>> wasn't specified yet.
>>> 
>>> This below submission serves to compliment the existing body of work
>>> related to ASPA, and barring any complications, it might be good to try
>>> to make this part of the I-D cluster draft-ietf-sidrops-8210bis,
>>> draft-ietf-sidrops-aspa-profile, & draft-ietf-sidrops-aspa-verification.
>>> 
>>> If the WG & chairs think this make sense, I'd like to ask for a call for
>>> Working Group Adoption for draft-spaghetti-sidrops-aspa-slurm.
>> 
>> I think this should indeed be done.. I have mentioned this on
>> occasion, and quite recently I asked about this explicitly here:
>> https://mailarchive.ietf.org/arch/msg/sidrops/-mGfZYT7IcVSGB8vPuwkWvENy0c/
>> 
>> As one of the original SLURM co-authors I volunteered to work on it,
>> and asked if the WG agrees that it's needed. I got little response to
>> this. As a result talking to the other co-authors, and drafting a
>> proposal did not make it to the top of my todo list yet. Given the
>> lack of responses I am a bit surprised that there is now a document.
> 
> I'm not entirely sure what exactly to make of the above: you volunteered
> to do something but then didn't get to it yet, because other work
> obligations and because of perceived lack of responses from the working
> group? Sure, that happens. Luckily, it seems there now is a chance to
> help progress such a spec and not have to do all the work yourself! :-)
> 
>> As for the content. It is not clear through the references how the
>> Validated ASPA Payloads (VAPs) are made, and fed into RPKI-RTR
>> (8210-bis). There is a reference related to VAP to
>> draft-ietf-sidrops-aspa-profile-12, which in turn refers to
>> draft-ietf-sidrops-aspa-verification-11 for this. The latter document
>> does not mention VAP.
> 
> Perhaps 'Validated ASPA Payloads' should be replaced with "ASPA Record";
> as 8210bis also doesn't make any mention of VAPs.
> 
>> This is important if we are to understand what the format should be
>> for the aspa filter and local assertions. In particular, we need to
>> know whether a VAP is modelled after the 8210-bis section 5.12 ASPA
>> PDU. Or.. that, like Validated ROA Prefixes, it's a tuple of
>> (customer-as, provider-as, optional afi limit) in which case as single
>> ASPA object would contain multiple VAPs, and other ASPA objects could
>> contain some of the same VAPs, as well as additional VAPs. I would
>> then expect these to be combined to form the appropriate ASPA rtr PDU.
> 
> In context of draft-spaghetti-sidrops-aspa-slurm 'aspaFilters', any such
> perceived distinction do not matter: the proposed matching happens based
> on whether the Customer ASID in the RPKI-ASPA-derived information and
> the to-be-generated-ASPA-RTR-PDU are equal or not.
> 
> Whether a single ASPA object listing multiple providers is exploded into
> multiple (Customer_ASID/Provider_ASN) tuples; or remains a single data
> structure; the matching is based on the Customer ASID & Afi, which exist
> in both approaches to model the information.
> 
> As for the 'aspaAssertions', the aspaAssertions are modeled after
> 8210bis ASPA PDUs and there should not be any ambiguity. Each
> 'aspaAssertion' contains the same data fields that a single ASPA RTR PDU
> would contain: afi, customer asid, and one or more provider ASNs.
> 
> Tim & Di Ma if you wish to contribute text and list yourselfs as
> co-authors that's fine by us. Feel free to send pull-requests via
> https://github.com/job/draft-sidrops-aspa-slurm/
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops