Re: [Sidrops] 8210bis

Martin Hoffmann <martin@opennetlabs.com> Sun, 09 February 2020 05:51 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 95A1C1200B7 for <sidrops@ietfa.amsl.com>; Sat, 8 Feb 2020 21:51:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 i20zFJYWNaTi for <sidrops@ietfa.amsl.com>; Sat, 8 Feb 2020 21:51:44 -0800 (PST)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.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 EAD3A12008B for <sidrops@ietf.org>; Sat, 8 Feb 2020 21:51:43 -0800 (PST)
Received: from grisu.home.partim.org (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 966F213FA9; Sun, 9 Feb 2020 06:51:41 +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: Sun, 9 Feb 2020 06:51:40 +0100
From: Martin Hoffmann <martin@opennetlabs.com>
To: Randy Bush <randy@psg.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <20200209065140.62e40665@grisu.home.partim.org>
In-Reply-To: <m2h80030t0.wl-randy@psg.com>
References: <m21rr75bxe.wl-randy@psg.com> <20200208103710.249e8166@grisu.home.partim.org> <m2h80030t0.wl-randy@psg.com>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.3 (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/hSUUi_Pve8iS46J_IjQ59v1OMJA>
Subject: Re: [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: Sun, 09 Feb 2020 05:51:46 -0000

Randy Bush wrote:
> 
>    There are zero or more 32-bit Provider Autonomous System Number
>    fields; see [I-D.ietf-sidrops-aspa-profile].

As a mere implementer, I can’t really judge how many Provider ASNs a
single ASPA typically will have, so I am just throwing this out there
for consideration:

ROAs are decomposed into a separate PDU for each prefix. The advantage
is that the PDUs are fixed size and I can keep read buffers on the
stack, whereas for variable length PDUs I will have to have some kind of
allocation strategy. Obviously, there is a 96 byte overhead for each
additional Provider ASN if we did the same for ASPAs. 

Am I assuming correctly that decomposing the ASPA would also make the
other paragraph you were asking for feedback for unnecessary:

>    The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile].  Receipt
>    of an ASPA PDU announcement when the router already has an ASPA PDU
>    with the same Customer Autonomous System Number, replaces the
>    previous one.  This is to avoid surprises when a BGP announcement is
>    received between an withdrawn PDU and a new announced PDU.

Kind regards,
Martin