" With plain IP routers?" Yes, or, well, relatively plain, depending on the implementation. The originally linked project used Arista. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> To: "Matthew Walster" <matthew@walster.org> Cc: "nanog list" <nanog@nanog.org> Sent: Saturday, January 7, 2023 8:44:59 AM Subject: Re: SDN Internet Router (sir) Matthew Walster wrote:
No... It's action based. You can send it a different route, you can replicate it, you can drop it, you can mutate it...
Replication is a poor alternative for multicast.
You conveniently ignore things like IDS, port mirroring, things like that.
Wrong. Instead, you conveniently ignore that such forwarding requires a link between an SDN router and a monitoring device have the same or larger MTU than an incoming link of the SDN router, which means the router and the monitoring device must be tightly coupled effectively to be a single device. Sometimes, packet loss possibility between them often requires they must actually be the same device.
No. There are far more actions than for prioritisation.
Just for fun? I'm afraid I already mentioned so.
What if you want to make sure certain classes of traffic do not flow over a link, because it is unencrypted and/or sensitive, but you're happy to send as much TLS wrapped data as you like?
You are wrongly assuming TLS wrapped packets can be identified packet by packet, as I wrote:
Unless pattern is as simple as having certain port number, stateful filtering almost always needs all packets including those matching expected pattern, I'm afraid.
So?
What if you want to sample some flows in an ERSPAN like mechanism?
See above for MTU issues.
What if you want to urgently drop a set of flows based on a known DDOS signature?
Urgently? Even though a DDOS signature is known in advance? Why?
Unless pattern is as simple as having certain port number, stateful filtering almost always needs all packets including those matching expected pattern, I'm afraid.
Or a certain set of IP addresses. Policy based routing.
That's even simpler than port number to be treated by having or not having proper routing table entries.
If default route is acceptable, just rely on it along with 50 non default routes with plain IP routers.
That's what OP is suggesting.
With plain IP routers?
That's what SIR is. Classifying prefixes by traffic and only keeping the ones with the highest volume of traffic, discarding the rest, relying on the default route to infill.
Given the connectionless nature of the Internet, route change based on volume of traffic averaged over certain period of time is rather harmful than useful. Masataka Ohta