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

Randy Bush <randy@psg.com> Tue, 24 March 2020 19:02 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2213A1268 for <sidrops@ietfa.amsl.com>; Tue, 24 Mar 2020 12:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTi7r5BD1pat for <sidrops@ietfa.amsl.com>; Tue, 24 Mar 2020 12:02:13 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544343A124E for <sidrops@ietf.org>; Tue, 24 Mar 2020 12:02:13 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1jGooU-0006cd-PL; Tue, 24 Mar 2020 19:02:10 +0000
Date: Tue, 24 Mar 2020 12:02:10 -0700
Message-ID: <m2h7ydzidp.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Alexander Azimov <a.e.azimov@gmail.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <CAEGSd=CdsLNRWKw_Pb7E328jso0gCqAbg8rWRwG+cOWpXjZGfA@mail.gmail.com>
References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> <m28skpusek.wl-randy@psg.com> <20200306130129.59c888c1@glaurung.nlnetlabs.nl> <m2a74ogai8.wl-randy@psg.com> <CAEGSd=CdsLNRWKw_Pb7E328jso0gCqAbg8rWRwG+cOWpXjZGfA@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/A4_JbL73-5RL6a9chkQoy6cuudQ>
Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 19:02:31 -0000

> 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