Re: [Sidrops] first route leak prevented by ASPA

Tim Bruijnzeels <tim@nlnetlabs.nl> Wed, 25 January 2023 13:33 UTC

Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <Y9EpXo+sncvtZAGz@diehard.n-r-g.com>
Date: Wed, 25 Jan 2023 14:33:37 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F92A9A9-BF31-44C3-B5A0-D34528C0B9E6@nlnetlabs.nl>
References: <Y9EpXo+sncvtZAGz@diehard.n-r-g.com>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/-mGfZYT7IcVSGB8vPuwkWvENy0c>
Subject: Re: [Sidrops] first route leak prevented by ASPA
Precedence: list

Hi Claudio,

Great news. Thanks for sharing.

I see you mention:

> On 25 Jan 2023, at 14:06, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> 
> combined with a Locally Added Assertion for my upstream AS:
>    customer-as 8271 provider-as { 13030, 174 }

How did you add these assertions?

I am thinking (as one of the authors) that an update to the Slurm RFC (8416) is probably needed sooner rather than later. It was on my radar, but did not make it to the top of my todo list just yet.

While I must apologise for the verbosity in the current JSON naming, I think the easiest update would be to take the existing format as is and just add an additional "ASPA Filter" as if it were a new section 3.3.3 and a "ASPA Assertion" as if it were section 3.4.3.

Do people agree that this is now a useful effort? If so then I am happy to pick it up.

Kind regards,

Tim

[Sidrops] first route leak prevented by ASPA Claudio Jeker
Re: [Sidrops] first route leak prevented by ASPA Tim Bruijnzeels
Re: [Sidrops] first route leak prevented by ASPA Claudio Jeker
Re: [Sidrops] first route leak prevented by ASPA gengnan