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

Alexander Azimov <> Sat, 21 March 2020 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0E5D3A08F8 for <>; Sat, 21 Mar 2020 12:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jb9sFv_RF6Yd for <>; Sat, 21 Mar 2020 12:18:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B81EE3A0902 for <>; Sat, 21 Mar 2020 12:14:25 -0700 (PDT)
Received: by with SMTP id p125so10337930oif.10 for <>; Sat, 21 Mar 2020 12:14:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C4zJeWrnQKSGR3KQ42t0NIMzt/9yQ41Cg5F9piWtfWA=; b=FOP1dzLpxk51sRi0MGLfuOWm6esK+iVc7NcAF50c020Mgex3KOCjROFhUknMM65z17 yrNIujizBuPvuiv80iFquK4AIzZ/Uw2CjROoYOgifx7rncGEspnyVhtIJ5Dc+Ydqa0h2 gU/ehjOYwAIBjfmaDBLMPjEEx3PYC3Wssq9hCCdw/NuhGRqYiHwLJX2tDw5W7t6M/Bh3 1npLm1h8KZXy0AcnEOoaE6tgWSo+Pv6WnQHoQW6EVzcKX1ysJMZ/Sqc5Q5vLMET+btrM 61+4G09YCIhzlNAqmrZk4HAjtE8t8RfPQwFjZPRNsDqarU+a7Lzu1u/xG2snu9aJ8y6H M8yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C4zJeWrnQKSGR3KQ42t0NIMzt/9yQ41Cg5F9piWtfWA=; b=jbLfcbdkhWHq3mVsBW2YkBO/gr+QP8BEvr0fE1yo1NnxPzv2KU9hIRmEM4+eD9VGVp y+GKmH+LVwBMiCO/qz9d4dhV9u/aBT52kh3sBlshpoLnwrb32aUN+JZ6sGmtNH3C76xM ELBNj9hFrobQqvWIi7s4FlRJU8Gb5h8Olk0e+ZQR3QNiE4YAOKEk5Di91RV+ML6R8JOU OnhT5VPER6lwjmnkNyE6kcAJSjzaY95ihHmxIXhxDDdX/R5SsjqIk2hmWu1+HiI+9Mdb 3Io7duh1RzJ5tldVFJ38VrBMM/rvX55t75he0okw/ahSetoGzS/PZZuF9gQL3yECdbWw jaRw==
X-Gm-Message-State: ANhLgQ2sEwzL3CfVjPUX+aKO4abfh5AnzXUyTISNT7JBhwPFBrUaxgRO NkvNFaoiGwQc3piqXC97koX6BL+pBDE402xzTE8=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vucbF0cKD5xvns/Qbt2kOQ54DK/a+cZeIB/sV5x?= =?utf-8?q?uEap411SxC+K2NBDS7opBhe47kGu8T4RaRvX/IUJvrbE4UM=3D?=
X-Received: by 2002:aca:d11:: with SMTP id 17mr11760449oin.128.1584818064932; Sat, 21 Mar 2020 12:14:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Alexander Azimov <>
Date: Sat, 21 Mar 2020 22:14:13 +0300
Message-ID: <>
To: Randy Bush <>
Cc: Martin Hoffmann <>, SIDR Operations WG <>
Content-Type: multipart/alternative; boundary="000000000000cb43c405a16235c1"
Archived-At: <>
Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Mar 2020 19:18:17 -0000

The separated records for v4 and v6 ASPA were inspired by the previous
research that showed a significant difference in the peering relations in
v4 and v6 respectively.
I did this research a couple of years ago, it will be interesting to check
if the situation has significantly changed.

I'd like to get the WG attention on the introduced update of ROA processing.
The current version of the RTR protocol related to ROAs is vulnerable to
possible race conditions: if the prefix has multiple ROA records or it
covering prefixes with different origin asn the state of the partial update
may lead to invalidating of really valid prefixes. Here is fresh statistics:

   - 16153 IPv4 prefixes with equal (5486) or more specific (11872)
   - 2250 IPv6 prefixes with equal (1202) or more specific (1164) conflicts.

The current proposal addresses this issue for ASPA and ROAs in a different

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

вт, 10 мар. 2020 г. в 06:22, Randy Bush <>om>:

> > As a separate note, ASPA in its current form includes the address
> > family, ie., it has different ASPA objects for v4 and v6. This is
> > missing from the proposed ASPA RTR payload PDU, but luckily there is
> > enough zero space to include it.
> i believe this is addressed in the draft out today; though not exactly
> in the way you suggest.  thanks again for pointing this out.
> randy
> _______________________________________________
> Sidrops mailing list

Best regards,
Alexander Azimov