Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021

[Tim Bruijnzeels <[e-mail]>]

> On 28 Nov 2021, at 03:35, Randy Bush <[e-mail]> wrote:
> 
>> I think that a model similar to multiple ROA objects and resulting VRP
>> PDUs is preferred.
> 
> From: Randy Bush <[e-mail]>
> Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00
> To: Alexander Azimov <[e-mail]>
> Cc: SIDR Operations WG <[e-mail]>, Tim Bruijnzeels <[e-mail]>
> Date: Sun, 06 Oct 2019 17:07:36 -0700
> 
> i have not thought deeply abut this.  but it seems to me that, as in
> ROAs, one enters into and leaves relationship with a provider.  whacking
> a multi-AS ROA or a multi-provider ASPA record seems ill advised.  for
> example, what if there is a delay between delete and recreate?
> 
> keep things simple, please.
> 

I am all for simple, but you cannot assume there will only ever be one
valid ASPA object for a customer AS.

I know the profile text says the a CA MUST make a single ASPA for a customer,
and I agree. But there are a number of reasons why RPs need to be prepared to
see multiple valid ASPA objects in the RPKI:

1 CA migration make before break

Suppose that I want to change from one CA implementation to another, then
I want to ask my parent to authorise my new CA and set up everything, ROAs,
ASPAs etc before removing and breaking my old CA.

2 Parent publishing ASPA

A parent can publish an ASPA for my customer ASN, delegate the ASN to me,
and then I can publish a second ASPA. Ill advised indeed, but we cannot
assume it won't happen.

3 Multi TA

ASPA objects for the same customer ASN can appear in different trees, at
least in theory.

4 (future) Local exceptions (SLURM)

While this would not be an object as such, we can (and should) extend
SLURM to allow for local ASPA filters / additions. This could also cause
overlaps with actual objects.

5 Algorithm Roll?

I need to re-read this in detail (RFC 6916) but I think there may be
duplicate objects in there as well, though I am not sure whether RPs
are required to validate both for the same CA. But, there may be something
here too.


In short I think RPs should process all *valid* ASPA objects and then
derive the *union* of all providers for a given customer ASN and AFI.

Note that this is orthogonal to the question of whether that union should
be presented to routers as a single PDU, or that single provider announcement/
withdrawal PDUs could be used.


> randy
> 
> 
> From: Randy Bush <[e-mail]>
> Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt
> To: Alexander Azimov <[e-mail]>
> Cc: SIDR Operations WG <[e-mail]>
> Date: Tue, 24 Mar 2020 12:02:10 -0700
> 
>> The current proposal addresses this issue for ASPA and ROAs in a different
>> way:
>> 
>>   - For ASPA a single PDU per customer AS is neveling the issue;
>>   - For ROAs the draft introduces ordering of the updates + suggests
>>   sending updates with the same prefix back to back.
>> 
>> The way ROAs will be processed decreases the chances that valid prefixes
>> will be marked as invalid, but they are not zero. My thinking is, that
>> since RTR protocol is negotiating its version at the start of the session
>> there is no need to keep full backward compatibility with the way ROAs were
>> processed previously. Instead, we can change ROA RTR PDUs is the same
>> fashion as it is introduced for ASPA: a single PDU for a selected prefix
>> that replaces previous records.
> 
> two dimensions of why not
> 
>  o the ASPA is a single atomic assertion signed by the only party who
>    has the authority.  it's pretty simple.

See above, there can be, and therefore RPs must assume there will be, more
than one object.

> 
>  o ROAs for a range are not atomic and may be asserted by many parties.
>    e.g. a /15 with two delegated /16s, each with delegated /whatevers.
>    if a /29 down the subnet-chain changes, you have to re-do the whole
>    shebang.
> 
>    a number of these are likely to be via CA delegation; more and more
>    as alex's marketing engine revs up.  so they will arrive at a cache
>    skewed in time.
> 
>    think what this does to the load on the router; and remember that
>    one major goal here is to minimize router load so current hardwhere
>    running on 6502s with 640k can route origin validate.

I am all for reducing the load on routers.

How is presenting a single PDU with a provider list that is supposed to
replace the previous list better on routers than having multiple PDUs
in a single update - i.e. before the end of data as Oliver mentioned?

In the first case there is possible overhead in case lists get long,
the second puts some burden on the router to build up its own new version
of a list before replacing the one it had. I expect that burden to be
low, but if router implementers can attest that it isn't then I would
love to hear it.

As I said, multi ASPA objects is orthogonal. If we MUST have a single
PDU then the cache can send the union of providers in ASPA objects as
a single PDU.

> and ask folk such as mark how rov deployment is going on some of the
> more common platforms.

I don't know who you mean by mark and what you mean by this. If there
are lessons to be shared, then please share specifics.

> 
> randy
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops