Re: [Sidrops] draft-ietf-sidrops-8210bis

Di Ma <madi@zdns.cn> Mon, 31 August 2020 01:59 UTC

Return-Path: <madi@zdns.cn>
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 AE8903A0C97 for <sidrops@ietfa.amsl.com>; Sun, 30 Aug 2020 18:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uOIl4F1cBHJc for <sidrops@ietfa.amsl.com>; Sun, 30 Aug 2020 18:59:38 -0700 (PDT)
Received: from smtpproxy21.qq.com (smtpbg704.qq.com [203.205.195.105]) (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 3B3733A0C96 for <sidrops@ietf.org>; Sun, 30 Aug 2020 18:59:35 -0700 (PDT)
X-QQ-mid: bizesmtp13t1598839169tnucmnpc
Received: from [192.168.218.230] (unknown [202.173.9.210]) by esmtp6.qq.com (ESMTP) with id ; Mon, 31 Aug 2020 09:59:28 +0800 (CST)
X-QQ-SSF: 00400000002000X0Z000B00A0000000
X-QQ-FEAT: tvOgVvG7QYDx4jvxRmRm64ZdV5kmdFiHM4VZLwsW9CncYRD9vJbmviHi0lOAf 5ue3H4afNbUQIc3VfuH4n4FbhZe5mXIhjpNncPkAHnpUhxOyQO1YZNxsf/V7JW7WYJ2oCLA BkAv1uBu6sOcFZOzIw6QPg73Sa+5Gm2pbs+kTCo8z3UtaV6uu4Zlmz7hao4/PRm7oxPzedm WrkwHIhPGWKSy9HPycv6VCn0H/QGUCL4EtgtpNMqjX/Pc07WM+HjrmQYedaQX5pacIdfnFh mJ1j+CQp117tXUc7t+1Dy0E+wAwkX8B5hAfkKI0YkzoU3JmuotDzNEfliEioyGEYmZk5tYd 9Lrxvp6nzNtwe6LFLJVv10w5S91ZA==
X-QQ-GoodBg: 2
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Di Ma <madi@zdns.cn>
In-Reply-To: <m2k0xhtlvz.wl-randy@psg.com>
Date: Mon, 31 Aug 2020 09:59:25 +0800
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E0C1C56B-7201-478F-A296-1F88A480E8C2@zdns.cn>
References: <m2k0xhtlvz.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign5
X-QQ-Bgrelay: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/0srKb4hxub1p6Chb_nFB2mTyhYk>
Subject: Re: [Sidrops] draft-ietf-sidrops-8210bis
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: Mon, 31 Aug 2020 01:59:43 -0000

Randy,

As far as I observe, two measures can be taken to avoid ROA PDU race.

One could be done by RP software by sorting PDU as per prefix and its length, before sending to routers.

The other one could be done by routers by establishing a transaction of RTR session before effecting those in routing table.

I think the first one can only mitigate the issue but the second one can really resolve the problem which calls for router software update.

Di

> 2020年8月30日 01:14,Randy Bush <randy@psg.com> 写道:
> 
> draft-ietf-sidrops-8210bis has
> 
>   1.2.  Changes from RFC 8210
> 
>   This section summarizes the significant changes between [RFC6810] and
>   the protocol described in this document.
> 
>   o  New ASPA PDU type (Section 5.12) added to support
>      [I-D.ietf-sidrops-aspa-profile].
> 
>   o  A small section, Section 11, has been added to handle two ROA PDU
>      race conditions, Break Before Make and Shorter Prefix First.
> 
> it is not clear there is a rush on ASPA.  as ROA PDU Race Minimization
> has serious effect on cache behavior,
> 
>   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.
> 
> this has overlap with a discussion Job was having.  i would like to
> close on this and get it out the door.  but it would be good if folk,
> reread, thought, and commented.
> 
> randy
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>