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

Randy Bush <randy@psg.com> Sun, 15 November 2020 21:22 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 37F193A0DD9 for <sidrops@ietfa.amsl.com>; Sun, 15 Nov 2020 13:22:01 -0800 (PST)
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 zprVVaqb6q8G for <sidrops@ietfa.amsl.com>; Sun, 15 Nov 2020 13:21:59 -0800 (PST)
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 9DDC03A0DD8 for <sidrops@ietf.org>; Sun, 15 Nov 2020 13:21:59 -0800 (PST)
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 1kePTA-0008AF-MO; Sun, 15 Nov 2020 21:21:56 +0000
Date: Sun, 15 Nov 2020 13:21:56 -0800
Message-ID: <m25z665n9n.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Cc: Alexander Azimov <a.e.azimov@gmail.com>, SIDR Operations WG <sidrops@ietf.org>, Martin Hoffmann <martin@opennetlabs.com>
In-Reply-To: <BYAPR11MB3207F821FF385403F3874360C0E40@BYAPR11MB3207.namprd11.prod.outlook.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> <BYAPR11MB3207F821FF385403F3874360C0E40@BYAPR11MB3207.namprd11.prod.outlook.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/gIMUq50sMcnoEzR3VYbaQLWV0mE>
X-Mailman-Approved-At: Mon, 16 Nov 2020 00:35:17 -0800
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: Sun, 15 Nov 2020 21:22:01 -0000

> One more race condition is more-specifics vs. less specifics.
> A less-specific ROA will invalidate a more specific prefix that would
> be not-found if the ROA were to not exist. 
> Invalids are increasingly being dropped, whereas not-founds are not
> dropped and will not be dropped in the foreseeable future. 
> So this matters.
> More-specific ROAs should be updated before less-specific.

rtfd

11.  ROA PDU Race Minimization

   When a cache is sending ROA PDUs to the router, especially during an
   initial full load, two undesirable race conditions are possible:

   Break Before Make:  For some prefix P, an AS may announce two (or
      more) ROAs because they are in the process of changing what
      provider AS is announcing P.  This is is a case of "make before
      break."  If a cache is feeding a router and sends the one not yet
      in service a significant time before sending the one currently in
      service, then BGP data could be marked invalid during the
      interval.  To minimize that interval, the cache SHOULD announce
      all ROAs for the same prefix as close to sequentially as possible.

   Shorter Prefix First:  If an AS has issued a ROA for P0, and another
      AS (likely their customer) has issued a ROA for P1 which is a sub-
      prefix of P0, a router which receives the ROA for P0 before that
      for P1 is likely to mark a BGP prefix P1 invalid.  Therefore, the
      cache SHOULD announce the sub-prefix P1 before the covering prefix
      P0.