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

Martin Hoffmann <martin@opennetlabs.com> Fri, 06 March 2020 12:01 UTC

Return-Path: <martin@opennetlabs.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 794BD3A0DB5 for <sidrops@ietfa.amsl.com>; Fri, 6 Mar 2020 04:01:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 nT2V7v7drruM for <sidrops@ietfa.amsl.com>; Fri, 6 Mar 2020 04:01:32 -0800 (PST)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 4B0B93A0DB3 for <sidrops@ietf.org>; Fri, 6 Mar 2020 04:01:31 -0800 (PST)
Received: from glaurung.nlnetlabs.nl (unknown [IPv6:2a04:b904::a2c5:89ff:feb5:e311]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 891171A75E; Fri, 6 Mar 2020 13:01:29 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Fri, 6 Mar 2020 13:01:29 +0100
From: Martin Hoffmann <martin@opennetlabs.com>
To: Randy Bush <randy@psg.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <20200306130129.59c888c1@glaurung.nlnetlabs.nl>
In-Reply-To: <m28skpusek.wl-randy@psg.com>
References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> <m28skpusek.wl-randy@psg.com>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/aO_j7rGMCKwIcWqIcqoBFVo4cwo>
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: Fri, 06 Mar 2020 12:01:35 -0000

Randy Bush wrote:
> A new version of I-D, draft-ymbk-8210bis-00.txt has been successfully
> submitted by Randy Bush and posted to the IETF repository.

I’d like to bring up my earlier proposal to exchange the ASPA contents
as pairs rather than lists again. In this case, the ASPA Payload would
look like this:

   0          8          16         24        31
   .-------------------------------------------.
   | Protocol |   PDU    |                     |
   | Version  |   Type   |         zero        |
   |    2     |    11    |                     |
   +-------------------------------------------+
   |                                           |
   |                 Length                    |
   |                                           |
   +-------------------------------------------+
   |          |                                |
   |  Flags   |             zero               |
   |          |                                |
   +-------------------------------------------+
   |                                           |
   |    Customer Autonomous System Number      |
   |                                           |
   +-------------------------------------------+
   |                                           |
   |   Provider Autonomous System Number       |
   |                                           |
   ~-------------------------------------------~

Much like all the prefixes on a ROA, there would be one ASPA Payload PDU
for each provider ASN in the ASPA RPKI object.

The main reason for proposing this is that this will bring handling of
ASPA PDUs in line with all the other payload PDUs in that the combined
payload is treated as a set: Each payload unit forms its own key for
lookups. Which is what makes the current announce/withdraw model work.

The ASPA PDU proposed in the draft works like a map: The key is the
customer ASN and the list of provider ASNs is the value.

Having two different ways of dealing with payload increases complexity,
both in the standard and in the implementations.

Splitting up the ASPA RPKI object would increase the overall size of the
response to a RTR reset query, but on the other hand decreases the
overall size of serial queries. Given that RTR sessions are very
long-lived, I think (without any actual evidence), that there might
even be an overall advantage in data size.

                                  *   *   *

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.

Kind regards,
Martin