the three pieces are futures, services, and filters. i will get to each. the reason i am writing this is that i spent the last several months building modgrad, a neural-net SDK in Rust, a domain with nothing obvious to do with RPC servers, and modgrad's core is eriksen's three abstractions, on purpose. we had the paper open. the surprise was never that we used it, it was how little we had to bend it: the mapping comes out almost line for line, down to a trait literally named Filter that composes with a method literally named and_then. this post is about how cleanly a 2013 server paper transfers to backprop, and where it stops.

the short version: a neural net is just a service, a filter, and a runtime. (the fourth piece, futures, doesn't map as cleanly. we'll deal with it last.)

the paper, compressed

eriksen's argument is that safe, modular, efficient server software falls out of three abstractions, and that almost everything else is plumbing.

a future is a handle on the result of an asynchronous operation: empty, succeeded, or failed. futures compose through combinators, and the composition is a dataflow graph that the runtime evaluates on your behalf. you describe the dependencies. you do not schedule them.

a service is an asynchronous function, and the definition is the entire idea:

type Service[Req, Rep] = Req => Future[Rep]

the same type is both a client and a server. (sounds like a trick until you notice it means a proxy is just a server whose handler happens to be a client.)

a filter is a service that wraps a service:

type Filter[Req, Rep] = (Req, Service[Req, Rep]) => Future[Rep]

everything application-agnostic (timeouts, retries, auth, logging) lives in a filter, and filters compose with andThen. Twitter's frontend proxy is, end to end, a filter stack. an excerpt of the real configuration:

recordHandletime andThen
traceRequest andThen
collectJvmStats andThen
parseRequest andThen
sanitize andThen
applyTrafficControl andThen
virtualHostServer

and then the sentence the whole paper rests on: "operations describe what is computed; execution is handled separately." you write semantics. the runtime (Finagle) owns mechanism: threads, pools, retries, tracing, cancellation. the contract between the two is the only thing you have to get right, and you only have to get it right once.

ok, that's the paper. here are the same three again, in a deep learning library.

a brain is a service

everything in modgrad hangs off a single trait. trimmed down:

trait Brain {
    type Weights;
    type State;
    type Input;
    type Cache;
    type Gradients;

    fn forward(
        weights: &Self::Weights,
        state: Self::State,
        input: &Self::Input,
    ) -> (BrainOutput, Self::State);

    // same call, but keep the intermediates the backward pass will need
    fn forward_cached(
        weights: &Self::Weights,
        state: Self::State,
        input: &Self::Input,
    ) -> (BrainOutput, Self::State, Self::Cache);

    fn backward(
        weights: &Self::Weights,
        cache: Self::Cache,
        d_predictions: &[Vec<f32>],
    ) -> Self::Gradients;
}

the signature says most of it: a brain is a pure function from (weights, state, input) to (output, new state). state is threaded through explicitly and never mutated behind your back. there is no module registry, no implicit graph, no global tape. (our own docs call this "pure functions over magic," and the landing page says "no framework, no YAML, just functions." i will not pretend those particular slogans were conscious nods to eriksen, but the structural decisions in the rest of this post were.)

put it beside the service type. Req => Future[Rep] is "request in, response later." (Weights, State, Input) => (Output, State) is the same arrow with recurrent state carried across the gap, because a model that thinks over time has to hand something to its future self. a continuous thought machine is, with very little squinting, a service you call in a loop, where last tick's state is part of next tick's request.

the forward and backward halves are paired at the type level, the same way eriksen ties asynchrony to the Future type. modgrad has a Vjp trait (vector-Jacobian product) whose two methods share associated types:

trait Vjp {
    type Primal;
    type Output;
    type Cache;
    type Cotangent;
    type Grad;

    fn forward(primal: &Self::Primal) -> (Self::Output, Self::Cache);
    fn backward(primal: &Self::Primal, cache: &Self::Cache, cotangent: &Self::Cotangent) -> Self::Grad;
}

you cannot write a forward without committing to the backward that undoes it, and the Cache type is the contract between them. a signature returning Future[T] tells you a call is async without your reading the body. a type implementing Vjp tells you it is differentiable, and exactly what it needs to remember for the backward pass. the type is the spec.

filters

modgrad has an inference path where a backbone emits logits and a stack of cognitive modules edits them before they become a token. an amygdala suppresses dangerous continuations. a hippocampus injects biases from recalled episodes. a cerebellum applies learned rules. working memory tracks recent context. i built each as an isolated unit, mostly because i wanted to test them without standing up the whole brain, and the trait i converged on lives in modgrad-io:

trait Filter {
    fn apply(&mut self, req: Request, mods: &mut LogitMods, inner: &mut dyn Service) -> Response;
}

trait ServiceExt: Service + Sized {
    fn and_then<F: Filter>(self, filter: F) -> Filtered<F, Self> {
        Filtered { filter, inner: self }
    }
}

that is eriksen's filter, almost unchanged. (Req, Service) => Rep, composed onto a service with and_then to produce a new service. and yes, the paper was open on the other monitor: the name and the and_then are borrowed on purpose. but a borrowed type only sticks if the problem actually has its shape, and this one did. i had a pile of modules that each wanted to see a request, do one thing, and pass it down. the paper handed me the abstraction. the problem is what made it fit.

here is the brain's actual pipeline, lifted from the doc comment over the type:

request
  → CTM deliberation    (4-region thinking loop)
  → AvoidanceFilter     (amygdala)
  → EpisodicFilter      (hippocampus)
  → RulesFilter         (cerebellum)
  → WorkingMemoryFilter (PFC)
  → InferenceService    (backbone)

now set it next to Twitter's proxy stack from two sections ago. one threads an HTTP request through logging and traffic control to a virtual host. the other threads a thought through fear, memory, and habit to a language model. same andThen, same orthogonal modules, same property that you can unit-test any single one of them with a fake inner service and about three lines of setup. eriksen, on filters: "quite simple to unit test in isolation, without any set up, and with minimal mocking." that holds here: each of these cognitive filters tests on its own, against a fake inner service, with nothing else stood up.

composition as data

this is where modgrad leaves the paper. the way it leaves is, i suspect, the interesting part.

a server is a line. requests flow one direction and andThen is concatenation. a brain is not a line. it is a graph with feedback: the cortical loop runs input to attention to output to motor and then motor feeds back to input, the cerebellum and basal ganglia hang off the side, the hippocampus reads and writes from the middle. you cannot say that with a linear chain.

so modgrad does not compose regions in code. it composes them as data:

struct RegionalConfig {
    regions: Vec<CtmConfig>,      // what
    connections: Vec<Connection>, // how
    // ...
}

struct Connection {
    from: Vec<usize>, // source regions; their states get summed at the target
    to: usize,        // target region
    receives_observation: bool,
    // ...
}

the eight-region brain is a Vec<Connection> plus a runtime that walks it each tick, summing signals where edges meet (they sum at the target, which is also how biological synapses work). there is even a learned variant: a small router that decides the wiring per tick instead of you fixing it once, up front.

this is not really a departure from eriksen. it is taking him at his word: he separates what from how, and his what happens to be a chain. make the what a value instead of a chain and you can serialize it, diff it, mutate it, search it, or learn it. we do all five. the principle (describe the computation, hand execution to a runtime) does not care whether the description is a pipeline or a directed graph. it cares only that you wrote down structure instead of control flow.

the runtime is the entire point

the most important sentence in the paper is easy to read past. Finagle is separate from everything above it, and because the semantics never name an execution strategy, Twitter could add Dapper-style tracing, QoS, thread affinity, and end-to-end cancellation "without changing APIs or otherwise modifying any existing user code." they bought themselves one place to put every hard thing, and amortized it across every service they would ever write.

modgrad has the same seam, and it is a large part of why a small team can carry a project this size. model code does not name hardware. a backward pass deep inside a continuous thought machine says:

ops::matvec_t(d_out, &linear.weight, d_input, out_dim, in_dim)?;

that is the whole call. no CUDA, no ROCm, no CPU anywhere in sight. underneath, ops are values in an Op enum (a small IR) and backends are plugins behind a trait:

trait Backend: Send + Sync + 'static {
    fn name(&self) -> &'static str;
    fn supports(&self, op: &Op) -> bool;
    fn dispatch(&self, op: &mut Op) -> Result<(), BackendError>;
}

a registry probes the host and routes each op to the best target it has: a hand-written fast path for our GPU, then ROCm, then CUDA, then Vulkan, then CPU, which is registered last and handles everything the others cannot. set MODGRAD_BACKEND=cpu and the identical binary runs on a laptop with no GPU at all. we added full GPU residency (weights pinned on-device across steps) without editing a single Brain impl. that is the Finagle move: the hard work goes behind the seam once, and everything above it benefits from then on. a good seam is a complexity reset. below it live five backends, device memory, and kernel dispatch; above it none of that exists, and model code stays as simple as the trait it calls. complexity stops at the boundary instead of leaking upward through the codebase. <TODO: insert OOP joke here>

it is also why a brain runs in a browser tab. compile to wasm, the registry finds exactly one backend (CPU), and dispatch goes there. nothing upstream notices. (this is literally how the demo on our site runs.)

where the analogy breaks

ok, the honest part. one leg of the analogy does not hold, and it is worth being specific about which.

eriksen's futures are asynchronous and read-only: producer and consumer are held apart, and you compose operations that have not happened yet. modgrad is eager. you call forward and it runs, right then, on this thread. there is no promise, no scheduler, nothing waiting on I/O.

what there is instead is the autodiff tape. the forward pass records a Cache per step (every tick of a CTM stashes its intermediates) and the backward pass walks that record in reverse. so there is a deferred computation here, the gradient, latent in the cache and executed separately, which rhymes with a future but is not one. if you wanted the real thing (concurrent, cancelable, "this might fail in 50ms") you would reach for an async executor, and modgrad does not ship one, because a synchronous training step is compute-bound, with no I/O latency worth hiding work behind. two of the three abstractions map exactly; the third maps only in spirit.

so, did we just copy a server framework

a little, and that is the point rather than the embarrassment. we had a hard problem (compose neural modules you can reason about, run them on whatever silicon is in the room, and refuse to drown in framework magic), we knew eriksen had solved the structural half of it for a different domain, and we borrowed his answer instead of rediscovering it the slow way. the thing worth noticing is not that we reused a paper. it is that a paper about RPC servers had anything to say about backprop at all. that is what a good abstraction is: not tied to the domain it was invented for. services, filters, and the semantics-versus-runtime split are facts about composition, and composition does not care whether the parts are RPC handlers or brain regions.

nor is the trick specific to servers or brains. bend the three types a little and they fit most software. express and axum middleware are filters on a request service. unix pipes are filters between processes. a compiler is a service (source in, IR out) with passes as filters and codegen as the runtime seam. a shell, a message queue, a game loop: same skeleton. most systems reduce to a core function, the concerns you want kept out of that function, and an execution layer you want to swap without touching either. eriksen did not invent that decomposition, but he named the pieces and showed how little glue they need, and once you have the names you start seeing them everywhere.

the payoff is the one the paper promised, in a new domain. import one modgrad crate or fourteen; the compute crate has never heard of the brain crate. every module tests in isolation. the hardware target is an environment variable. and you can hand a stranger a URL where a real eight-region brain (the same functions we train on a GPU, not a reimplementation of them) runs in their browser, reads a maze through a visual retina, thinks for sixteen ticks, commits to a move, and learns its own motor readout while they watch. it is at modgrad.com/play: give it the 21×21 maze, flip it to hardcore, and watch where it still gets lost.

eriksen wrote his paper to keep a website up. thirteen years later we used it to build a brain. good abstractions travel.

i recently got to write the design and configuration for a client's new rack (AS64500). most network work is migrating and iterating on someone's old setup. this one was a blank page, nothing to inherit, so i did the opposite and configured the interior fabric with BGP unnumbered. no addresses on the internal links. peers find each other over IPv6 link-local, IPv4 routes ride an IPv6 next-hop, and the numbered links are the external ones, where the other side isn't ours to configure.

this is the long version of how it's built, node by node, plus the two things that didn't work the way i expected.

none of this went onto the hardware blind. i built the whole rack in containerlab first (full anonymized lab on github), cEOS standing in for the arista switches and FRR for the vyos edges. in that fabric lab FRR also stands in for the cilium leaves, so i can iterate on switch and edge configs without booting kubernetes for every change. a second lab runs the real thing, Cilium on a kind cluster with its own BGP control-plane, where the server side gets validated against the same switches. that's the pre-production stage: every change goes through a lab before it touches a real port. the diagram above is generated from the fabric topology, and it's where the two bugs further down turned up.

the rule

everything follows from one decision. the interior is IPv6-only, and IPv4 only appears on numbered external links.

inside the AS, switch to switch, switch to edge, edge to edge, there are no IPv4 addresses and no /31s. the loopbacks are IPv6 (fd00::1, fd00::2, fd00::11, fd00::12). the router-ids are still dotted-quad (10.0.0.1, 10.0.0.11, and so on) but that's a 32-bit identifier, not an address you can ping. IPv4 only shows up where it has to, on the transit and customer links, where the peer can't hand us an IPv6-only session.

the topology is two arista 7060cx switches (sw1 AS65001, sw2 AS65002), two vyos edges sharing one external face (vyos1 and vyos2, both AS64500), and two cilium speakers (cilium1 AS65301, cilium2 AS65302). transit comes in from two upstreams, and a customer hangs off the switches. it's eBGP everywhere except the single iBGP session between the two edges: per-switch and per-server private ASNs, no route reflector.

the switches run arista EOS. the edges run vyos, which is FRR under the hood. the servers run Cilium, and in the fabric lab FRR stands in for them. so the configs below are EOS on the switches, FRR on the edges, and Cilium on the servers.

in the diagram, every solid teal link is unnumbered and every dashed grey link is numbered. the dashed ones are the links that leave the building.

first, a little ipv6

most people never learn IPv6 properly. they assume it's just IPv4 with hexadecimals. but the protocol has real depth, and this whole trick leans on one piece of it that IPv4 never had: link addressing without your help, no config required. it's worth two minutes at the packet level. if you want more than two minutes, APNIC's week-long onsite IPv6 fundamentals course is where i actually learned this, and it was worth the week.

the moment an interface comes up it gives itself a link-local address in fe80::/10, with a stable, opaque interface id (RFC 7217). no DHCP, no assignment, and the address never leaves the link it's on.

before it uses that address it checks nobody else has it. that's duplicate address detection (DAD, RFC 4862): it sends one neighbor solicitation, an NS (ICMPv6 type 135), with the source set to ::, the unspecified address, because it has no valid address yet, and the destination set to the solicited-node multicast of the tentative address, ff02::1:ffXX:XXXX, formed from the low 24 bits of the target. if some other node already holds that address it answers with a neighbor advertisement (NA, type 136) and the tentative address is abandoned. if nothing answers, it flips from tentative to usable. the interface id is 64 bits of effectively random, so a collision is vanishingly unlikely and DAD passes on the first NS.

then the routers make themselves known. a host can ask with a router solicitation (RS, type 133) sent to ff02::2, the all-routers group, and routers answer, and also advertise on their own schedule, with router advertisements (RA, type 134) to ff02::1, all-nodes. the RA is sourced from the router's own link-local and carries its presence, the on-link prefixes, the MTU. resolving an address to a MAC uses the same NS/NA pair aimed at the solicited-node multicast, the IPv6 replacement for ARP: a targeted multicast that only the likely owner hears, not a broadcast to the whole segment.

tldr: on any IPv6 link, both ends come up with a stable, unique, self-assigned address and a built-in way to find and reach each other, before a single line of config. that is the property the rest of this rides on.

what unnumbered means here

we lean on exactly that. an interior link gets no /31. FRR peers over the fe80:: IPv6 already put on the interface, and the arista side just needs ipv6 enable. the only thing we switch on is RAs, so each end learns the other's link-local and knows who its neighbor is:

interface eth1
 no ipv6 nd suppress-ra
 ipv6 nd ra-interval 5

without that, neighbor eth1 interface has nothing to discover and the session stays down.

the last piece is carrying IPv4 over that IPv6 next-hop. that's RFC 5549 (updated by 8950): an IPv4 prefix advertised with an IPv6 next-hop, so 192.0.2.0/24 crosses a link with no IPv4 address on it. arista has to be told to do this; FRR does it on its own. both below.

the switch side

arista EOS doesn't implement remote-as external. you give it the AS per neighbor and peer the interface into a peer-group:

neighbor PG-INTERIOR peer group
neighbor PG-INTERIOR timers 10 30
neighbor PG-INTERIOR bfd
!
neighbor interface Et33 peer-group PG-INTERIOR remote-as 65002   ! peer-link to sw2
neighbor interface Et1  peer-group PG-INTERIOR remote-as 64500   ! vyos1
neighbor interface Et2  peer-group PG-INTERIOR remote-as 64500   ! vyos2

and the IPv4-over-IPv6 next-hop that FRR did for free has to be turned on by hand:

address-family ipv4
   neighbor PG-INTERIOR activate
   neighbor PG-INTERIOR next-hop address-family ipv6 originate

next-hop address-family ipv6 originate is the EOS knob for advertising IPv4 NLRI with an IPv6 next-hop. the interior interfaces themselves are just no switchport, no ip address, ipv6 enable, with RA on. the only interior neighbors missing here are the servers, which peer by address in a separate group, for reasons that come up below.

the edge

the vyos edges are where the two worlds meet. inside, the iBGP between the edges and the eBGP down to the switches is all unnumbered:

! ibgp to vyos1 (unnumbered)
neighbor eth3 interface remote-as 64500
neighbor eth3 timers 10 30
neighbor eth3 bfd
!
! ebgp to switches (unnumbered)
neighbor eth1 interface remote-as external
neighbor eth1 timers 10 30
neighbor eth1 bfd
neighbor eth2 interface remote-as external
neighbor eth2 timers 10 30
neighbor eth2 bfd

remote-as 64500 on the iBGP peer is the one place we give an explicit AS instead of external. the two edges are the same AS on purpose: AS64500 is the single face we show the world, one origin for the prefixes, not two. that makes the link between them iBGP, the only iBGP in the network. everything else has its own private ASN, so it's eBGP. with just two edges that one session is already a full mesh, so there's no route reflector to run.

interior timers are tightened to 10 30 from FRR's default 60 180, with BFD doing the sub-second work on top.

outside, the transit sessions stay numbered. real addresses on the upstream links, local-role customer (RFC 9234) and ttl-security hops 1 (GTSM) per peer, bgp ebgp-requires-policy left on for BCP 194. that's the normal ISP pattern and there's no reason to fight it. unnumbered is for links you own both ends of.

the result is less to manage, and it scales without planning. adding an interior link is ip link set up, no ipv6 nd suppress-ra, and one neighbor ethN interface line, the same on every box, so a new switch or edge is that recipe plus its ASN, nothing to look up. no subnet to allocate, no IPAM row, no /31 pool that grows with the fabric. that's why unnumbered is the default for large leaf-spine networks, where the interior links dwarf a two-switch rack and hand-numbering them would be a job in itself (RFC 7938).

the server side

the one interior link that doesn't get unnumbered is the server. the servers run Cilium, and Cilium's BGP control-plane only peers by explicit address, there's no interface peer the way FRR has one. so the cilium-to-switch links are the single interior exception: numbered, a /31 and a /127 per leg.

the speaker is declared in a CiliumBGPClusterConfig, one BGP instance per node with a peer entry per switch and family:

apiVersion: cilium.io/v2
kind: CiliumBGPClusterConfig
metadata:
  name: cilium1
spec:
  nodeSelector:
    matchLabels:
      server: "1"
  bgpInstances:
    - name: "65301"
      localASN: 65301
      peers:
        - name: sw1-v4
          peerASN: 65001
          peerAddress: 10.10.110.0
          peerConfigRef: { name: cilium-peer }
        - name: sw1-v6
          peerASN: 65001
          peerAddress: "fd00:10:110::"
          peerConfigRef: { name: cilium-peer }
        - name: sw2-v4
          peerASN: 65002
          peerAddress: 10.10.111.0
          peerConfigRef: { name: cilium-peer }
        - name: sw2-v6
          peerASN: 65002
          peerAddress: "fd00:10:111::"
          peerConfigRef: { name: cilium-peer }

the parts that matter:

• every peer is keyed by a peerAddress, so a node brings up four sessions, a v4 and a v6 to each switch. the unnumbered side of the fabric gets one interface session that carries both families; here it's a session per family per neighbor, with an address to allocate for each.
• the matching switch side is plain numbered eBGP in its own PG-CILIUM group: neighbor 10.10.110.1 remote-as 65301, neighbor fd00:10:110::1 remote-as 65301, and so on. same peer-group and timers, just addresses instead of interfaces.
• what gets advertised isn't a network statement, it's a Cilium object. a CiliumLoadBalancerIPPool hands out the service IPs and a CiliumBGPAdvertisement picks which to announce. the anycast LB address comes out of both cilium1 and cilium2 and gets ECMP'd at the switches.

this is the boundary between the routed fabric and kubernetes, and it's the one spot in the interior that looks like an ordinary numbered eBGP session.

where it broke

unnumbered works well until something downstream doesn't speak it. two things caught us.

BFD is fine on unnumbered, broken on numbered eBGP, at least on this EOS. on ceos:4.36.0.1F, BFD on the unnumbered link-local peers comes up reliably, show bfd peers brief shows up. but add neighbor X bfd to a numbered eBGP peer, the switch-to-customer link, and that session wedges in Idle with Last reset: Address family activated (n/a) and never establishes. the unnumbered peers on the same switch stay up. FRR-to-FRR numbered eBGP does BFD fine, so it's specific to numbered eBGP on EOS. we left the numbered customer peers without BFD and let them fall back to BGP holdtime plus GTSM. the link you'd reach for BFD on first, the external one, is the one place it wouldn't go.

the second one is cilium, the place i wanted unnumbered most. the server links above are numbered because they have to be: cilium's BGP doesn't implement interface peering (cilium/cilium#22132, open since 2022), and it doesn't negotiate BFD either (#22394) in the OSS build. so failure detection on those links drops from BFD's sub-second to BGP holdtime, around 30 seconds. the FRR stand-ins in the fabric lab do speak unnumbered and BFD, so any demo that shows sub-second cilium failover is really showing the FRR stubs, not stock cilium.