Re: [Sidrops] 8210bis

Martin Hoffmann <> Sun, 09 February 2020 05:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95A1C1200B7 for <>; Sat, 8 Feb 2020 21:51:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i20zFJYWNaTi for <>; Sat, 8 Feb 2020 21:51:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAD3A12008B for <>; Sat, 8 Feb 2020 21:51:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPSA id 966F213FA9; Sun, 9 Feb 2020 06:51:41 +0100 (CET)
Authentication-Results:; dmarc=none (p=none dis=none)
Authentication-Results:; spf=none
Date: Sun, 9 Feb 2020 06:51:40 +0100
From: Martin Hoffmann <>
To: Randy Bush <>
Cc: SIDR Operations WG <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
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: <>
Subject: Re: [Sidrops] 8210bis
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: 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,