Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt

[Randy Bush <[e-mail]>]

> 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.

  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.

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

randy