+1. Was going to follow up to Saku's message about how/if folks are doing that in JunOS [or other OS] natively without outside automation. Our backbone has scavenger style plp in BE, I control admission via prefix-list in ingress fwfilter on untrusted interfaces. Haven't personally tested but looks like DCU + forwarding-table export policy + output firewall filter, maybe this is possible today but requires output fwfilter to family mpls. I don't currently have a fwfilter there so ideally another option exists. -Michael

-----Original Message----- From: jim deleskie via NANOG <nanog@lists.nanog.org> Sent: Tuesday, August 4, 2026 9:00 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: jim deleskie <deleskie@gmail.com> Subject: Re: how about a well-known DOWNGRADE BGP Community? (Was: RTBH Support Across the Industry)

I fully support this direction.

Job, anything I can do to assist, let me know please

-jim

On Tue, Aug 4, 2026 at 9:38 AM Job Snijders via NANOG <nanog@lists.nanog.org> wrote:

...

Dear all,

Following up on the RTBH thread, we'd like to put forward an different strategy for DoS attack mitigation. Perhaps just as an extra tool in the toolbox.

Abstract -- This document outlines a method to mitigate Denial of Service (DoS) attacks by using a well-known BGP community named "DOWNGRADE" as signal to neighboring networks to treat traffic destined towards "DOWNGRADE" tagged IP prefixes with low precedence. The "downgrade" strategy offers an appealing alternative to Remote Triggered Blackhole (RTBH) filtering, because RTBH filtering completes the DoS attack and hampers the defender's ability to monitor whether the attack is still ongoing.

Read the full draft document here:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- spaghetti-grow-downgrade-bgp- community__;!!Mak6IKo!I84uSQpoZr3Hgeb0DCb0OohZiOXtp1cZcaeVckp1CLt4n T_niCJvjcUFGnTGsreTP8yeCSencjX90coak9bz$

Your feedback is most welcome!

Kind regards,

Job _______________________________________________ NANOG mailing list

https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... anog.org/message/UGA3PTY45ILBQRASIJJVHAF3M57MQQ5I/__;!!Mak6IKo!I84u SQpoZr3Hgeb0DCb0OohZiOXtp1cZcaeVckp1CLt4nT_niCJvjcUFGnTGsreTP8yeCSe ncjX90TqgTZE0$

...

_______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... anog.org/message/XQBBQVQTEKIECEDDE3TAE4BN2GQO5Q7Z/__;!!Mak6IKo!I8 4uSQpoZr3Hgeb0DCb0OohZiOXtp1cZcaeVckp1CLt4nT_niCJvjcUFGnTGsreTP8yeC SencjX90aGXE2jb$

Saku- Thanks for link. This is what I had in mind, but I presumed if output interface was into an LSP maybe I'd need output filter in family MPLS. At this point, I'll just try this out in the lab. -Michael

-----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Tuesday, August 4, 2026 11:30 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Michael Hare <michael.hare@wisc.edu> Subject: Re: how about a well-known DOWNGRADE BGP Community? (Was: RTBH Support Across the Industry)

On Tue, 4 Aug 2026 at 18:20, Michael Hare via NANOG <nanog@lists.nanog.org> wrote:

...

+1. Was going to follow up to Saku's message about how/if folks are doing that in JunOS [or other OS] natively without outside automation. Our backbone has scavenger style plp in BE, I control admission via prefix-list in ingress fwfilter on untrusted interfaces. Haven't personally tested but looks like DCU + forwarding-table export policy + output firewall filter, maybe this is possible today but requires output fwfilter to family mpls. I don't currently have a fwfilter there so ideally another option exists.

Something to this note, nothing really specific to any AFI: https://urldefense.com/v3/__https://raw.githubusercontent.com/job/draft- downgrade-bgp- community/refs/heads/main/nos/junos.txt__;!!Mak6IKo!IOVZQT4Lf7E7zL5MWS bICpNXJnyzuaVs2NnLxqdQJftUH3NI3k00Ws0VNddwQDb250bo4F95RdUFgnqM$

For context, remainder of QoS config would look something to: https://urldefense.com/v3/__https://p.ip.fi/Nott.txt__;!!Mak6IKo!IOVZQT4Lf7E... zL5MWSbICpNXJnyzuaVs2NnLxqdQJftUH3NI3k00Ws0VNddwQDb250bo4F95Rb4 m1HQV$

-- ++ytti

Hello, I would be very happy to see this feature implemented at transit providers, because it takes the guesswork out of RTBH and allows visibility into the attack patterns without sacrificing not attacked destinations. But ... TL;DR: know the routing platform your are implementing this on inside and out. Take an ASR9000 for example. A basic implementation that sets a ingress qos-group/cos/dscp/exp bit for the attacked /32 and has an egress queue configurations which deprioritizes scavenger traffic can do nothing in a DoS situation. Let's say the core is Nx100G, the customer has a single 10G (on a different line card), and a 40G attack goes through from the core towards a customer IP, customer enables scavenger marking for the attacked /32, and then nothing happens. The customers continues to see heavy packet loss and huge latency even on IP addresses that are not under attack and egress QoS doesn't seem to do that much considering the attack size. Why is this happening? HoLB avoidance with Virtual Output Queues and back pressure [1]. The ingress line card (with Nx100G core links) on the 9k has a virtual output queue for each egress 10G entity. The ingress line card does NOT apply egress QoS port settings of course, that's the job of the egress line card. All traffic destined for the 10G customer port including attack traffic is treated equally by the ingress line card, meaning it is queued at 10G without consideration for egress port QoS settings before entering the fabric. That is why the egress line cards receives a 10G limited stream of traffic (per ingress LC), which the DoS obviously dominates and the actual configured egress port QoS setting has nothing left to do. VoQ QoS is extremely limited (4 queues: default, multicast, priority 1 and priority 2). IIRC priority queues are strict (policer) and cause back pressure to fabric interface ASICs when congested (so inverting the logic and putting normal traffic into a priority queue would never work, not that anybody would do something like this). I really don't know how you'd implement this on a 9k, unless a fifth scavenger/below normal queue for VoQ would be implemented on the ingress LC (and this would be a per LC HW dependant feature). When you try to protect your customer from a DoS with an egress port ACL (like drop all IP frag + UDP traffic to this /32), a similar thing happens: TX traffic dips below normal on the customer port. Again because *all* traffic is queued unconditionally before the ACL on the egress line card can make a difference and then, the ACL actually drops (and therefore hides) the attack traffic, leaving less than normal but still heavily congested legitimate traffic left for TX. Of course if the traffic never goes to the fabric (ingress and egress port on the same LC), this is not an issue or when you have 8 linecards and each linecards has 1 core link, all perfectly load balanced, than you'd probably still get a huge benefit from this. However this is a lot more complex than just a adding another logic to the routing policy. Kind regards, Lukas [1] https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-u...

Mind you, in your scenario, even without ASR9k priorities, the network is protected. DoS -> IngressPE -> Core1 -> Core2 -> ASR9k -> Victim As the victim prefix has community, IngressPE sets the LE QoS bits. Each hop egress side stops congesting the far end ingress side Even if ASR9k congests the victim (which it shouldn't with the right priority level), the rest of the core is protected, so the blast zone is still just the victim. Having said that, of course to do QoS, you need a device which has QoS. That feels tautology, but I think it needs to be said. If any reasonable definition of QoS works, this works. Your congestion scenario is reserved, as far as I understand - ASR9k does not have VoQ priorities set properly - There is speed step-down from core->victim Both of these need to be true, for the issue to happen. Bigger, imho, concern in ASR9k is that you cannot do volumetric egress ACL, and here priorities won't help you. If a customer gets bad traffic, which you can easily ACL off in egress direction, it does nothing for you. And while this is a fundamental problem in VoQ platforms, rest of the platforms, like PTX, actually return credits to ingress, if egress drops them. ASR9k you just need to exceed egress capacity by trivial percentage (not 2x) in PTX you need a large multiplier, before you congest the credit-return mechanism. ASR9k is basically a really cheap and stupid pipeline box disguised as an SP edge device, with software complexity that is too high for Cisco to manage. This is not hyperbole, I've repeatedly had to tell TAC how ASR9k works, because they've closed NOC tickets with obviously incorrect answers. One particular issue which TAC worked on for months, was us dropping customer BGP sessions, and TAC claiming the problem is our egress QoS, despite LPTS packets not being subject to either QoS or ACL. On Wed, 5 Aug 2026 at 09:22, Saku Ytti <saku@ytti.fi> wrote:

On Wed, 5 Aug 2026 at 00:01, Lukas Tribus <lukas@ltri.eu> wrote:

...

Take an ASR9000 for example. A basic implementation that sets a ingress qos-group/cos/dscp/exp bit for the attacked /32 and has an egress queue configurations which deprioritizes scavenger traffic can do nothing in a DoS situation.

I don't think this is true.

You set 'priority level 1' for NC+AF, 'priority level 2' for BE, and leave LE unset on the ingress policy.

This sets the fabric priority, and VoQ will honor it.

-- ++ytti

-- ++ytti

We ran this very config in production while we still had asr9k. It is slightly confusing as 0, 1 and 2 on CLI are not same in Tomahawk, in HW they are well ordered. But in CLI unconfigured 0 is worst, 1 is best and 2 is middle, so can be confusing if you debug in HW level to see where packets are going. ++ytti ________________________________ Lähettäjä: Lukas Tribus <lukas@ltri.eu> Lähetetty: Wednesday, 05 August 2026 22:32:26 Vastaanottaja: Saku Ytti <saku@ytti.fi> Kopio: North American Network Operators Group <nanog@lists.nanog.org>; Job Snijders <job@bsd.nl> Aihe: Re: how about a well-known DOWNGRADE BGP Community? (Was: RTBH Support Across the Industry)

You set 'priority level 1' for NC+AF, 'priority level 2' for BE, and leave LE unset on the ingress policy.

This sets the fabric priority, and VoQ will honor it.

I am very glad this is possible on the 9k. Are you certain there are no negative consequences moving the entire BE traffic into a fabric priority queue (back-pressure, etc)?

Mind you, in your scenario, even without ASR9k priorities, the network is protected. [...] Even if ASR9k congests the victim (which it shouldn't with the right priority level), the rest of the core is protected, so the blast zone is still just the victim.

The *transit* network is technically protected. But the incentive for the *customer* network to actually announce the scavenger route is gone. If the transit network is injecting a scavenger route itself without involving the customer, sure, then this makes sense for the benefit of the transit network. But more likely the transit customer already switched to RTBH instead anyway. I'm happy to hear this is possible on the 9k. Lukas