Two ways to build the broker

Option A puts the packet broker inside the fabric. The P4 pipelines on the spine filter, truncate, tag and mirror traffic, and P4Runtime programs them from the same controller that handles forwarding. This saves ports, optics and rack space, and the filter logic gets the full match-action expressiveness of the ASIC. Option B splits the light before it reaches the switch. Passive optical TAPs on the spine links feed a dedicated broker tier with its own power, its own control plane and its own failure domain. The fabric has no idea it is being watched. On a healthy day the two look alike. They only diverge when something breaks.

The failure mode that decides it

Take one spine ASIC that reboots during a pipeline upgrade. In Option A its forwarding entries and its mirror sessions disappear together. Its flows rehash onto the remaining spines, which typically carry mirror rules for their own ingress ports but none written for flows they never used to see. The controller has to notice the loss, recompute mirror placement and push new entries. That runs on the controller's reconciliation loop, not at hardware failover speed, so you get a visibility gap of seconds (my estimate for a typical P4Runtime controller under load) on exactly the flows that moved. A second effect stacks on the first. The surviving spines now carry extra load, and since mirror copies are usually queued at the lowest priority, they get dropped first when buffers fill. So the fabric loses sight of itself at the moment it is most stressed: forwarding is still running, and the evidence of why it rerouted is gone. Option B doesn't fail this way. The TAPs are passive glass, they keep splitting light whether the switch behind them is up or down, and they keep doing it when the switch is mid-reload.

Where the boundary sits

The decision flips when an automated consumer of broker output acts on a timeout shorter than the fabric's time to rebuild mirror state after losing a spine. When monitoring feeds dashboards, forensics or lawful retention that can tolerate a short gap, Option A wins: it is cheaper, denser and simpler to run. When the broker output feeds a closed loop, such as an AI-native traffic steering function, a slice SLA enforcer or a protection trigger working within a 50 ms budget, the in-fabric gap is longer than the loop's patience. That loop then acts on stale or missing data, or stops acting at all, and Option B wins. The cost of Option B shows up in the optical power budget. A TAP split takes margin from the production link, and the Ethernet optical PHY specifications in the IEEE 802.3 family leave little slack on short-reach PAM4 lanes, so some link classes will need a lower split ratio or active regeneration on the monitor leg. Roughly a few dB of insertion loss on the production side is the usual price (an estimate that depends on split ratio and connector count). Check it against your worst-case link before freeze, not after.

There is also a hybrid: use P4 mirroring for broad, low-stakes visibility, and put passive TAPs only on the spine links whose telemetry drives automated control actions, which keeps the extra optical loss and broker port count limited to the links where a blind spot would actually do harm.