RE: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Adam Thompson <athompson () merlin mb ca>]

> -----Original Message-----
> From: NANOG <nanog-bounces+athompson=merlin.mb.ca () nanog org> On
> Behalf Of Joe Maimon
> Sent: Thursday, March 31, 2022 6:20 PM
> Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255
> times
>
> [...]
> I think more and perhaps different knobs were and still are needed.

YES.  YESYESYES.

Having said that, I am currently able to express my local traffic policies (roughly 1/3 due to one particular upstream 
hamstrung by their parent company, 1/3 due to NREN, 1/3 due to local IXP) using prepends of no more than +2 (both 
outbound and inbound, which I gather might be somewhat unusual).  That includes dealing with a "special" issue because 
both my local NREN RAN and I are both connected to the local IXP, and to a mutual downstream, which produces an 
interesting double-triangle topology, and this topology produces surprising emergent behaviours that I haven't seen 
described anywhere.

Prior to some reorganization (and several compromises) I needed +5 on both inbound and outbound (usually not at the 
same time) to adequately steer normal traffic.


Prepending is, IMHO literally, the abuse of a mechanism not initially designed to express complex policies.  It's a 
1-dimensional tool in a space that really needs a 2- or 3-dimensional tool.

LOCAL_PREF is not useful for me and my upstreams, downstreams and peers: I have not yet found a scenario where it fixes 
any of my problems without creating even greater ones.  My traffic-steering issues ~all exist n>3 hops away, not 
directly with my BGP peers.

So prepending remains the only useful, usable knob I have.  And it's not a great knob for this, which I think might be 
the one thing everyone here can agree on!


> through nowadays, how about a long call back to each AS in the path

I'm not really loving that solution more than prepends, but at least it's something different?


> Would be nice to be able to publish your community scheme as simply
> conforming with RFCX and the to configure peers with process-rfcX
> statement and be mostly done.

That's a LONG way off!  Not that any other solution isn't equally far off, so... <shrug>  Gotta start somewhere, I 
guess!

I don't have any better suggestions, other than I wish the LOCAL_PREF crowd could understand that it doesn't solve all 
the world's problems.  (Neither of my commercial upstreams currently admit to supporting communities that control it, 
anyway!)


Frustrated at the state of the world today,
-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson () merlin mb ca
www.merlin.mb.ca