Hello Robert, On Wed, Jun 24, 2026 at 08:42:48PM +0200, Robert Scheck wrote:
> On Tue, 08 Apr 2025, Maria Matejka wrote: > > And with that, exactly as Jelle writes, you do the _downstream_ check > > for all your transits, i.e. > > > > ``` > > if aspa_check_downstream(ASPAS) = ASPA_INVALID then reject "ASPA INVALID ", > > net, " ", bgp_path, " ", proto; > > ``` > > just to get whether I understood you correctly: If I have transits (local > role customer), such as Arelion, Deutsche Telekom or Vodafone, I need the > aspa_check_downstream(), as written by you, in my import filter? Yes. There is kinda a little catch though, and that is the rejection itself. While the current draft stipulates to drop downstream invalids, it may cause connectivity degradation in specific situations. There is nothing wrong witn dropping Upstream invalids; both customer and peer routes should be validated and invalids dropped. But then there are prefixes where all candidates for the best route have come from your transits. If your transits validate ASPA, they are going to drop ASPA-invalid routes, and probably won't send trash to you, and everything is still OK. But it they do not validate ASPA, they may easily select a leaked best route, and the only thing you get is trash. And while you could say whatever, it's still trash, drop it, the problem is that often such a leak works well, other customers of your transit therefore don't complain, and there is no easy way to get the leak rectified. For this reason, I would very much recommend only depreferencing downstream invalids (i.e. setting `preference = 67;`) or something like that. There is a rather long thread on this in the sidrops mailing-list, and I'm still quite surprised that this operational catch has been quite actively rejected by the authors of the draft. https://mailarchive.ietf.org/arch/msg/sidrops/FotQhXB7t-XsRMD2hGAj3VfdS4o/ Note: a situation like this, in a simplified form, happened with the RIPE network and CZ.NIC, which has been affected by Hurricane Electric leaking CZ.NIC routes. https://ripe92.ripe.net/programme/meeting-plan/sessions/109/ZT9NYU/ Note: The connectivity was hotfixed by temporarily adding HE as CZ.NIC provider in ASPA, and later returned to normal (checked right now). -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
