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
- [Sidrops] 8210bis Randy Bush
- Re: [Sidrops] 8210bis Martin Hoffmann
- Re: [Sidrops] 8210bis Randy Bush
- Re: [Sidrops] 8210bis Randy Bush
- Re: [Sidrops] 8210bis Martin Hoffmann