Paolo Lucente built the junction between traffic and routing data

Summary

• Lucente created pmacct in 2003 and still maintains a suite that collects packets, NetFlow or IPFIX, sFlow, Linux accounting, BGP, BMP and streaming telemetry.
• Its configurable aggregation and output plugins let operators enrich traffic with prefixes, paths, communities and validation state, then publish records into memory, files, databases or brokers.
• That flexibility creates governance work: aggregation keys, timestamps, sampling, templates, schema versions and routing viewpoints determine what later analysis can honestly claim.
• pmacct can support peering, capacity and cost analysis, but contracts and local classification supply the economic meaning; open collection does not remove storage costs or maintainer dependence.

Ten terabytes do not reveal who created the traffic

An interface counter can show that ten terabytes crossed a port. It cannot tell a network whether those bytes belonged to a customer, arrived from a peer, used paid transit or shifted after a routing change. That gap between observation and commercial meaning is the problem Paolo Lucente began addressing when he created pmacct in 2003.

Flow export adds addresses, ports, protocol, packet and byte counts, interfaces and time. sFlow provides sampled packet evidence. Packet capture sees one observation point more closely. BGP and the BGP Monitoring Protocol expose routing state. None of those sources, alone, answers the questions that capacity planners, peering teams, security analysts and finance departments ask.

pmacct became a family of collectors and enrichment tools rather than one dashboard. pmacctd captures packets; nfacctd receives NetFlow and IPFIX; sfacctd receives sFlow; uacctd consumes Linux accounting; pmtelemetryd handles streaming telemetry; pmbgpd and pmbmpd collect routing state. Plugins can retain aggregates in memory or send them to files, SQL databases, Kafka, AMQP, JSON or Avro.

The architecture gives operators control over the join between traffic and routing data. It also transfers responsibility for aggregation keys, sampling, timestamp policy, schema evolution, broker reliability and the local dictionaries that turn a community or interface into a customer, peer or transit relationship.

The article’s central question is evidentiary: when can an enriched traffic record support a capacity, peering or cost decision, and when does a precise-looking number outrun the collector’s viewpoint? Lucente’s contribution is the open junction. The network still has to preserve provenance and supply the business meaning.

pmacct grew from accounting software into a family of observers

Early pmacct work focused on collecting packets and flow records, grouping them by selected fields and writing the resulting counters into stores that operators could query. The initial problem was practical. A network needed repeatable accounting without buying a closed appliance or writing a new collector for every project.

The project’s shared aggregation model allowed different input daemons to produce comparable records. A direct packet collector and a NetFlow collector do not observe traffic in the same way, but both can accumulate bytes and packets by prefix, autonomous system, protocol or interface. The configuration determines which dimensions form the key. This separation between observation source and aggregation question became one of the suite’s durable strengths.

As the internet and operator data stacks changed, pmacct added more inputs and outputs rather than abandoning the model. sFlow support addressed sampled visibility common in switching environments. Linux accounting interfaces supported host and software-router use. BGP integration attached routing information to traffic. Message brokers allowed collectors to decouple ingestion from storage. Streaming telemetry and BMP extended the suite into newer device-state models.

The resulting architecture is modular in two directions. On the input side, an operator can select the source appropriate to the network: packet capture, NetFlow or IPFIX, sFlow, kernel accounting, BGP, BMP or structured telemetry. On the output side, it can keep live aggregates in memory, write rows to SQL, emit files or publish records into a broker for multiple consumers.

Modularity allows small and large deployments to use the same project differently. A laboratory may run one collector and query its memory table with the pmacct client. A service provider may distribute collectors near exporters, enrich records with routing feeds and publish them to Kafka for storage and analysis elsewhere. The project does not claim that one topology is correct.

That flexibility also increases the number of ways a deployment can be wrong. A collector may use an aggregation key with excessive cardinality. A broker may accept records faster than consumers can process them. A database schema may lose fields required for later analysis. An exporter may reset without the pipeline noticing. A BGP feed may represent a different router from the device that generated the flows.

Lucente’s long-term maintenance role has involved keeping these components coherent while protocols and downstream systems evolve. The repository and documentation identify him as the creator and principal maintainer, but the suite is collaborative. Router vendors define exporter behaviour, standards communities define protocols, users contribute fixes and database teams control the final system. A profile of Lucente has to follow those boundaries rather than crediting every integrated technology to pmacct.

Aggregation keys decide what the network will be able to know later

At the centre of pmacct is a deceptively simple operation: build a key from selected fields and add counters for records that share it. The selection of fields determines what information survives. A key containing source prefix, destination prefix and origin AS supports one kind of analysis. Adding ports, protocol, interface, VLAN, BGP communities, MPLS labels and timestamps supports more detailed questions and creates a much larger state space.

Cardinality is the governing constraint. Each additional dimension multiplies the number of possible combinations. A network with millions of addresses, thousands of prefixes and many communities can generate enormous numbers of unique keys. More detail is not automatically more useful. It can consume memory, increase broker traffic and make queries slower without improving a decision.

Good design therefore begins with the question rather than the exporter. To plan capacity, an operator may need traffic by site, peer and broad service class. To investigate a customer dispute, it may need a narrower period and richer dimensions. To monitor RPKI exposure, it may need origin and validation state. Keeping every field at full granularity for every record is often too expensive.

Aggregation also changes the evidentiary meaning of the result. Once flows are grouped, the analyst may no longer be able to reconstruct an individual conversation. That can be appropriate for privacy and cost, or it can remove information needed for incident response. Retention policy should distinguish operational aggregates from forensic data rather than assuming one table can serve both.

Time is part of the key even when it is not explicitly named. Flow exporters divide long conversations according to active and inactive timeouts. Records may carry start, end, export and observation timestamps. A collector has its own ingestion time. An hourly report can change depending on which boundary is used. Two systems can appear to disagree while assigning the same flow to adjacent periods.

pmacct gives operators control over these choices, but it cannot determine the correct answer. The project’s value is that the choices are visible in configuration and schema rather than embedded inside a closed product. The risk is that an operator can build a precise-looking data set whose assumptions were never documented.

Lucente’s work repeatedly returns to this theme: telemetry becomes useful when the dimensions match an operational question and when the provenance of those dimensions remains available. A byte count without context is weak evidence. A richly labelled record without a clear source can be equally misleading.

NetFlow and IPFIX bring templates, sequence gaps and silent loss

NetFlow and IPFIX reduce the volume of measurement data by exporting summaries instead of every packet. Devices create records for observed flows and send them to collectors, often over UDP. IPFIX uses templates that describe which fields are present and how they should be interpreted. Exporter identity, observation domain, sequence numbers and timing are therefore part of the record’s meaning.

nfacctd has to track this control information as well as the traffic fields. A data record received before the corresponding template may be unusable. A router restart can reset sequence numbers and timers. A template can change. Several exporters can use overlapping identifiers. Without careful handling, the collector may ingest values under the wrong schema or discard data without making the loss obvious to the analyst.

UDP transport is efficient and common, but it provides no end-to-end delivery guarantee. Congestion, collector overload or network faults can remove datagrams. Sequence information can reveal some gaps, subject to exporter implementation. A dashboard that shows lower traffic during a collection outage can be mistaken for a real demand change unless telemetry health is monitored separately from traffic telemetry.

Sampling adds another qualification. Exporters can select only a fraction of packets and scale the result. This reduces device and collector load, but rare or short flows may be underrepresented. A sampling rate suitable for capacity planning may be unsuitable for billing or security investigation. Reports need to preserve the sampling method and avoid presenting estimates as exact counts.

IPFIX extensibility is both a strength and a source of fragmentation. Vendors can export enterprise-specific fields. Two devices may use similarly named concepts with different semantics. A collector can parse both while the downstream schema collapses distinctions. Interoperability therefore requires more than protocol compliance; it requires an agreement about field meaning.

pmacct’s open collector model helps because operators can inspect template handling, monitor sequence information and adapt parsing. It does not remove the need to test each exporter. The quality of the final data set is bounded by what the device observed, what it chose to export and what arrived at the collector.

This boundary is central to Lucente’s editorial profile. He built tools that make flow evidence more useful, while repeatedly working in standards to improve what devices can expose. The project cannot compensate for an exporter that omits the state needed to answer the question.

sFlow trades completeness for bounded measurement overhead

sFlow approaches visibility through sampling. A device selects packets according to a configured rate and exports information about the samples, along with counters. The method allows high-speed switches to provide useful traffic evidence without creating a record for every conversation.

sfacctd can ingest those samples, aggregate them and attach routing context. For many capacity, peering and traffic-mix questions, statistical estimates are sufficient. A network does not need a complete copy of every packet to learn that one origin or service category is driving growth.

The limitation is not a defect in the collector. Sampling changes the probability that an event will be observed. Large flows are likely to appear repeatedly; very small or rare flows may not appear at all. An unusual packet sequence can be operationally important and statistically invisible. Scaling sampled counts can estimate volume while leaving uncertainty around specific events.

Sampling configuration also varies by interface, device and time. Combining data requires preserving the rate and understanding whether the exporter uses systematic or random selection. A report that mixes samples without normalisation can assign false differences to traffic rather than measurement.

This makes sFlow well suited to some questions and inappropriate for others. Capacity planning, broad peer analysis and traffic composition can tolerate estimation. Exact customer invoicing, legal evidence or reconstruction of a short attack may require a different source. An operator should define the evidentiary threshold before selecting the collection method.

pmacct’s support for several source types allows a layered design. sFlow can provide broad visibility, while targeted packet capture or unsampled flow export supplies detail for selected links and periods. The project does not force the network to choose one method for every use case.

The larger lesson is that observability is an allocation of measurement resources. A network decides where to spend device CPU, bandwidth, storage and analyst time. Lucente’s software makes the trade configurable. It does not make the trade disappear.

Direct packet capture and Linux accounting expose different truths

pmacctd works closer to the packet than a flow-export collector. It can capture traffic from an interface through supported packet-capture mechanisms and apply the same aggregation and output model used elsewhere in the suite. That makes it useful when a device does not export flows, when an operator needs fields absent from the exporter or when a controlled observation point can see the traffic of interest directly.

Closeness to the packet does not mean universal completeness. The capture interface may see traffic after filtering, before encapsulation or only on one side of a bridge. High packet rates can exceed the capture path or host capacity. Offloads can change how packets appear to software. A span or mirror port can drop under congestion. The observation point needs to be documented as carefully as an exporter.

Direct capture also changes privacy and security exposure. Packet headers can contain more detailed information than an aggregated flow record, and payload may be visible depending on configuration. An operator should minimise fields early and isolate the collector. Running the software on a general-purpose host does not make the captured data low risk.

uacctd addresses another environment: Linux systems that expose accounting through kernel and user-space interfaces. This is relevant to software routers, hosts and virtual network functions where the operating system itself is the forwarding platform. The collector can associate local networking state with the broader pmacct pipeline without requiring a separate hardware exporter.

Host accounting has its own boundaries. Namespaces, virtual interfaces, tunnels and offloads can make the apparent interface different from the service the operator intends to measure. A container platform may create and destroy interfaces rapidly. Kernel version and configuration determine which fields are available. The deployment needs an inventory that connects low-level objects with stable business or service identifiers.

Using several observation sources can improve coverage and create reconciliation work. Packet capture, flow export and host accounting may count at different layers and time boundaries. Their totals should not be expected to match exactly without a model. Comparing them can reveal loss or blind spots, but only when the differences in scope are explicit.

That helps explain why pmacct’s common aggregation model is useful. The project can bring several sources into related schemas while preserving source identity. A disciplined design does not collapse them into one undifferentiated total. It uses overlap to test measurement quality and assigns each source to questions it can answer defensibly.

Streaming telemetry adds structured device state but not one common implementation

Modern network devices can stream structured operational data rather than relying only on periodic polling or flow export. pmtelemetryd extends pmacct into this environment. The collector can receive modelled state and publish it into the same operator-owned data architecture used for other observations.

Structured telemetry can expose counters, interface state, queue information and protocol data with clearer types than scraped command output. Subscriptions can deliver updates when values change or at defined intervals. This reduces polling delay and makes automation less dependent on human presentation formats.

The word structured should not be confused with uniform. Vendors support different data models, paths and update modes. A field can be present on one platform and absent on another. Units and counter-reset behaviour may differ. Model revisions can change a path or type. A collector that accepts the transport still needs mappings and tests for the devices in scope.

Telemetry frequency is an engineering choice. High-rate updates provide detail and can overwhelm devices, networks, collectors and brokers. Slow updates lower cost and miss short events. The appropriate interval depends on the decision. Capacity planning and microburst investigation have different needs.

Backpressure deserves particular attention. A device may keep sending while a downstream consumer is slow, or it may drop, buffer or terminate the session. The architecture needs explicit behaviour for overload. Otherwise, the period of greatest operational stress can produce the least reliable telemetry.

Lucente’s current standards work on YANG, service assurance, message brokers and new transports reflects the gap between device data and operator systems. A YANG model can define a common structure. A broker can distribute updates. A transport can improve session behaviour. None of them guarantees that vendors implement the same set or that the resulting state maps cleanly onto a service.

RFC 9418, the YANG data model for service assurance, is relevant because it moves the discussion above individual counters. Operators want to understand whether a service is meeting its intended behaviour, not simply whether a specific interface is up. A model can relate symptoms, dependencies and service objectives, subject to the data supplied by the network.

pmacct’s place in this evolution is pragmatic. It can be one collector and normalisation point inside a telemetry fabric. It does not need to become the only control system. The project’s value is strongest when it preserves device provenance and allows downstream teams to combine structured state with flows and routing evidence.

BGP enrichment connects a flow with the route the operator saw

An IP address can be mapped to an autonomous system using a public table or static database, but that mapping may not represent the routing state of the network that forwarded the traffic. A prefix can be announced by different origins, carried along different paths and marked with communities that encode local relationships. Routing changes over time.

pmacct can maintain BGP state through pmbgpd and use it to enrich traffic records. The collector can attach the matching prefix, origin AS, AS path, next hop, local preference and communities available in its view. This moves the analysis from generic address classification toward the operator’s actual control plane.

The benefit is substantial. A peering team can classify traffic according to communities that mark customer, peer or transit routes. A capacity planner can group demand by origin or path. An incident analyst can compare a traffic shift with a routing change. A network can distinguish traffic whose origin validation state is Valid, Invalid or NotFound when that data is integrated.

The correlation remains an inference. The BGP collector may peer with a different router from the flow exporter. Its route can arrive earlier or later. Policy-based routing, tunnels, MPLS and segment-routing behaviour can direct packets differently from the selected IP route. Asymmetric paths mean the observed direction may not represent the return direction.

Timestamps and viewpoint are therefore critical. A record should indicate which routing feed supplied the context and when the lookup was made. A later analyst should not assume that today’s BGP table explains traffic collected months earlier. Historical reports need either contemporaneous state or a carefully bounded reconstruction.

Communities require local knowledge. A value used to identify a customer in one network can mean something else in another. pmacct can carry the field, but only the operator can supply the dictionary. That dictionary is often business-sensitive and may change as routing policy evolves.

This is where Lucente’s open-pipeline philosophy matters. The project does not claim to know the universal meaning of a route. It provides the mechanism for a network to join its control-plane state with its forwarding observations. The analysis becomes more faithful to local reality and more dependent on local governance.

BMP reveals routing state that an ordinary BGP feed cannot see

A collector that establishes a normal BGP session sees the routes a router chooses to advertise to that peer. It does not automatically see every route the router received, every route after policy or the complete local routing table. The BGP Monitoring Protocol was designed to export internal routing information for monitoring without requiring the collector to become a conventional peer for every view.

Lucente’s standards work has been closely associated with this area. RFC 8671 added support for reporting Adj-RIB-Out, the routes a router has prepared for advertisement after policy. RFC 9069 added Local RIB support, exposing selected local routing information. RFC 9736 created a namespace for information associated with the BMP Peer Up message. His current work has continued into BMP extensions, YANG models, transport and brokered telemetry.

These additions matter because an operator often needs to compare stages. A route can be received from a neighbour, rejected by import policy, selected into a local table and then withheld from another peer. Observing only the final advertisement conceals where the decision occurred. BMP can expose more of that chain.

pmbmpd gives pmacct a way to ingest such records and connect them with other telemetry. A traffic report can be interpreted alongside what a router received or intended to send. A route-server operator can inspect member views. A policy team can confirm whether a route existed before or after a filter.

The scale can be demanding. A router may send an initial dump of large tables and then bursts during convergence. Multiple peers, address families and path identifiers increase volume. Collectors have to preserve peer identity and implementation-specific details. Broker and storage design can become the limiting factor even when the BMP session itself is healthy.

Vendor support also varies. A specification can define an information type without every router implementing it, or implementations can differ at the edges. Standards work narrows the gap, but operators still need interoperability tests against the exact software release.

BMP does not prove the physical path of traffic. It exposes routing state. The value comes from joining that state with flow observations and knowing which layer each record represents. Lucente’s work has expanded the set of states that can be examined without pretending they are interchangeable.

RPKI state adds security context only when provenance survives

Route Origin Validation can classify an announcement according to cryptographically signed authorisations published in RPKI. A route whose origin and prefix length match an applicable authorisation is Valid. A conflicting announcement is Invalid. A route with no covering authorisation is NotFound.

pmacct can attach this state to routing or traffic records, allowing operators to measure how much traffic is associated with each category. That can identify exposure before a policy change, show the business impact of rejecting Invalid routes or help prioritise outreach to customers with incorrect authorisations.

The label is time-sensitive. Authorisations can be added, changed or revoked. Validators can become stale. A historical report that stores only “Invalid” without the validation time and source loses important evidence. The route may have been invalid when observed and valid later, or the collector may have used incomplete data.

RPKI also addresses origin, not the complete path. A Valid route can still be leaked or carried through an undesirable relationship. A NotFound route is not necessarily suspicious. The state should enrich analysis rather than replace it.

The operator’s policy determines consequence. It can reject Invalid routes, reduce preference, flag them for investigation or create bounded exceptions. pmacct records and reports; it does not decide the balance between security and reachability.

This separation is consistent with Lucente’s standards work. Protocols should expose state with enough structure for operators to apply policy. The collection system should preserve provenance. Business and risk decisions remain outside the collector.

BGP-LS adds topology description without turning telemetry into a controller

pmacct’s documented scope includes BGP-LS, which can carry link-state topology information through BGP. That input can enrich a measurement pipeline with nodes, links and attributes beyond ordinary reachability announcements.

The data remains a control-plane description. It does not prove that a packet followed a particular path, that every metric is current or that an optical or tunnel layer beneath the advertised link was healthy. Different domains can expose different detail, and policy can limit what reaches the collector.

The value is correlation. Traffic volume can be examined beside advertised topology and routing state, helping operators ask whether a heavily used relationship corresponds to a known link or whether a change aligns with a control-plane event. Path computation and network changes remain functions of external controllers and operators.

Adding another input also increases schema and identity work. A router, interface or link needs stable keys across BGP-LS, BMP, flow records and inventory. Without those joins, a richly described topology becomes a separate data set rather than useful context.

Lucente’s project is strongest at this boundary: it can receive and normalise evidence from several planes while refusing to pretend that collection alone owns network intent.

Schema evolution is a governance process disguised as data engineering

A long-running telemetry platform accumulates consumers. Capacity reports, anomaly detectors, customer portals and research queries can all depend on the same fields. Changing a schema therefore resembles changing a public API. A new field is easy to add and difficult to remove once teams build around it.

JSON makes records easy to inspect, while Avro and similar structured formats can attach explicit schemas. SQL tables encode types and indexes. Brokers may use a registry to coordinate versions. Each mechanism can support disciplined evolution and each can be bypassed by informal conventions.

The hardest changes are semantic rather than syntactic. Renaming peer to neighbor is visible. Changing the meaning from BGP session peer to commercial peer while keeping the same field name can silently corrupt analysis. A community value reclassified from transit to customer can restate months of reports without changing the record format.

Versioning should therefore include dictionaries and derivation rules. An enriched record needs to identify the routing view, validation source and policy version used. A business classification needs an effective date. Consumers should be able to reject unknown versions rather than accepting plausible but incorrect data.

Replay is a useful test. If a pipeline stores a bounded raw or minimally transformed stream, a new consumer can process historical data and compare results before deployment. Replay also reveals whether transformations are deterministic and whether external lookups have been preserved. Without provenance, reprocessing may apply today’s route or contract state to yesterday’s traffic.

Retention makes the governance problem larger. Keeping raw records supports future questions and increases cost and privacy exposure. Keeping only aggregates reduces risk and limits reinterpretation. A tiered policy can retain short-lived detail, longer-lived operational summaries and carefully controlled accounting evidence.

pmacct does not prescribe this governance, but its flexible outputs make the choices unavoidable. A closed product may hide schema evolution behind a vendor upgrade. An operator-owned pipeline has to establish its own contracts between producers and consumers. That work is part of the price of control.

Brokers and databases turn a collector into a distributed system

Writing enriched records to Kafka or an AMQP broker can decouple collection from analysis. A collector can continue ingesting while several consumers store, aggregate or alert on the same stream. The architecture supports scale and reduces dependence on one database.

It also introduces a new failure chain. Brokers have partitions, retention limits and authentication. Producers can retry and create duplicates. Consumers can lag or fail. Schema changes can break one application while another continues. A dashboard may be current for one topic and stale for another.

Exactly-once accounting is difficult. A system can choose idempotent record keys, transactions or downstream deduplication, but each method has cost and assumptions. If a collector crashes after the broker accepts a record but before the acknowledgement is processed, a retry may duplicate it. If the system drops on error, the record may disappear.

SQL outputs have a different profile. They can provide durable, queryable tables with familiar controls, but write rates, indexes and schema design become constraints. Partitioning by time can help retention and queries. High-cardinality dimensions can make indexes expensive. A relational database may be appropriate for aggregated accounting and unsuitable for every raw flow.

JSON improves accessibility and Avro can support structured schema evolution, but neither guarantees semantic consistency. A field named peer_as needs a definition: the BGP neighbour, the origin, or a business classification. The producer and consumers must share that meaning.

The downstream platform can recreate lock-in even when the collector is open. Proprietary query languages, managed-broker dependencies, dashboards and retention economics can make migration expensive. pmacct gives the operator a choice of outputs; preserving choice requires portable schemas and tested export paths.

This is a key part of the project’s economic story. Open source can remove a software licence fee while leaving servers, storage, broker operation, engineering and support as the dominant costs. At high scale, the data platform may cost much more than the collector. Lucente’s architecture makes that cost visible because the operator assembles the system rather than paying one bundled price.

Time boundaries decide whether the same bytes belong to an incident, a bill or neither

Flow data looks naturally chronological because records contain timestamps. In practice, an operator has several clocks and several possible definitions of when traffic occurred. A flow can begin in one reporting period, end in another and be exported later. The collector can ingest it after a broker delay. A routing update used for enrichment can have its own observation time.

NetFlow and IPFIX exporters often use active and inactive timeouts. A long conversation can be divided into a sequence of records even though the application sees one connection. A quiet interval can close the record and a later packet can begin another. Counting conversations from exported records without understanding those boundaries can inflate or fragment the result.

Clock skew adds another ambiguity. The router, collector, BGP source and database may not agree exactly. A route change that appears to precede a traffic shift can reverse order after clock correction. Incident reconstruction should preserve source timestamps, ingestion time and the uncertainty between them rather than overwrite everything with one warehouse time.

The reporting rule must be explicit. An hourly utilisation table can assign bytes according to flow start, flow end, export time or a prorated interval. Each choice is defensible for a purpose and can move traffic across a billing or capacity boundary. pmacct supplies the observations and configurable aggregation; it does not decide which accounting convention is contractually correct.

Broker retries and replay make time interact with identity. A delayed record can arrive after a dashboard window closed. A retried record can be counted twice unless the downstream system has an idempotent key or deduplication rule. Exactly-once language should be treated cautiously when exporters, UDP transport, collectors and consumers do not share one transactional boundary.

Lucente’s open-junction model is useful because it lets operators retain this provenance. The same flexibility can be squandered if a pipeline flattens timestamps and discards sequence health. A precise chart is credible only when the organisation can explain which clock, record boundary and late-data policy produced it.

False precision begins when measurement health is hidden from the report

A flow dashboard can display exact-looking numbers even when the underlying evidence is sampled, delayed or incomplete. The most important operational discipline in a pmacct deployment is therefore to measure the measurement system itself.

Exporters should be monitored for sequence gaps, template changes, resets and sampling configuration. Collectors should expose packet loss, parse errors, queue depth and resource pressure. Brokers need lag, retention and error metrics. Databases need write-failure and freshness checks. A traffic graph without these health indicators can convert a collection failure into a business conclusion.

Asymmetric routing complicates interpretation. A collector may see only one direction of a conversation. The return path can cross a different link or network. If reports combine directions using address assumptions, they can double-count or misclassify. Placement and topology documentation are part of the data model.

Tunnels and MPLS create another gap. An exporter may report outer headers, inner headers or labels depending on device capability and configuration. BGP context applied to the visible address may describe the tunnel endpoint rather than the ultimate destination. The report should state which layer is observed.

Clock quality matters during incidents. An exporter timestamp, collector timestamp and broker timestamp can differ. If a routing event is compared with a traffic change at one-minute resolution, clock skew can reverse their apparent order. Operators need synchronisation and an explicit choice of event time.

Sampling uncertainty should be communicated according to the question. A high-volume category may have a narrow estimate while a rare flow has a high chance of being missed. Scaling every sample into an integer does not remove variance. Reports can present confidence ranges or, at minimum, distinguish estimated from observed values.

Data cleaning can also erase useful evidence. A pipeline may discard malformed records, unknown templates or new vendor fields. That protects downstream consumers and can conceal an interoperability problem. Quarantine and error stores allow engineers to investigate without contaminating primary analytics.

pmacct’s modularity supports this discipline because collection, enrichment and export are visible stages. It does not automatically configure the controls. The project’s documentation gives operators mechanisms; production assurance depends on treating data loss as an incident rather than as a footnote.

Traffic becomes economic evidence only after contracts are joined

The phrase network economics can make a telemetry system sound more intelligent than it is. pmacct can measure traffic by customer, peer, transit provider, prefix, community, path or interface when the necessary observations and classifications are available. It cannot know the price of a transit contract, the terms of settlement-free peering or the internal cost of a port unless the operator supplies those data.

The distinction begins with relationship classification. A network may mark routes learned from customers, peers and transit providers with communities. pmacct can use those communities to group traffic. If the markings are incomplete or inconsistent, the accounting inherits the error. An interface label can be a useful fallback, but shared links and route changes can make interface-based assumptions inaccurate.

Cost allocation then requires a model. Transit may be billed on a percentile, committed rate or other structure. Exchange ports have fixed and variable costs. Private interconnects include cross-connects, optics, equipment and operational labour. Internal backbone capacity has depreciation and power costs. A byte does not carry one intrinsic price.

pmacct can provide the measurement side of that model. An operator can calculate how much traffic was associated with a transit path during a billing interval, how a peering change shifted load or which customer group drives peak capacity. The finance system supplies contract terms and accounting policy. The result is a derived estimate, not a fact emitted by the router.

This separation matters when analysis is used in negotiation. A peering team may show that traffic volume supports direct interconnection. Another network may value the traffic differently because its costs, geography or customer demand differ. The collector can establish a common measurement basis without deciding the commercial outcome.

Traffic engineering uses similar evidence. If a route policy change moves a large volume onto a constrained link, pmacct can help show the effect by joining the flow records with communities and paths. It may not prove that the control-plane change caused every byte movement, especially in a network with tunnels or distributed load balancing. Correlation with configuration history and device counters strengthens the conclusion.

Customer accounting has a higher evidentiary burden. Sampled records or lossy export may be adequate for internal planning and inappropriate for invoicing unless the contract and method allow estimation. The collection pipeline needs completeness monitoring, time-boundary rules and dispute procedures. Open software gives the operator control over the method; it also removes the convenience of blaming a black-box vendor for assumptions the operator chose.

Lucente’s contribution is to make the join possible in an operator-owned system. The route, traffic and business layers remain distinct enough that each can be audited. That is more useful than claiming that telemetry has discovered the true value of a path.

Privacy and security belong in the collector architecture

Flow records are metadata, but they can reveal customer behaviour, internal topology, service usage and communication patterns. BGP communities and subscriber classifications can add commercial sensitivity. A telemetry pipeline therefore needs access control, encryption, retention and audit comparable to other high-value operational systems.

Collectors often sit near routers and accept data from trusted addresses. That network trust should not replace authentication and isolation. Spoofed or malformed records can corrupt reports or exhaust resources. Management interfaces and broker credentials can expose a broad view of network activity.

Data minimisation begins with aggregation design. A capacity report may not require full source and destination addresses. Removing unnecessary fields reduces privacy risk and storage cost. The choice has to be made before long-term retention; deletion later may be difficult across brokers, replicas and backups.

Cross-border architecture adds legal questions. An exporter in one jurisdiction can send records to a broker or cloud database in another. pmacct provides the transport and output mechanisms, not legal compliance. Operators need to map data flows and retention obligations themselves.

Open source improves auditability because security teams can inspect parsing and output code. It also means the operator is responsible for patching and hardening. There is no central service automatically updating every deployment. Maintainer concentration makes timely monitoring of releases especially important.

The project has no published global security certification or complete deployment audit. That absence is not evidence of insecurity, but it limits broad assurance claims. Each organisation should threat-model the exact inputs, privileges and data stores in its architecture.

Standards work extended Lucente’s influence beyond one code base

Lucente’s current IETF record places him in a different role from the maintainer of an open collector. He chairs the Global Routing Operations Working Group and is associated with five published RFCs. RFC 7789 concerns the impact of BGP filtering on inter-domain routing policies; RFC 8671 covers BMP Adj-RIB-Out; and RFC 9069 covers BMP Local RIB. RFC 9418 defines a YANG data model for service assurance, while RFC 9736 defines the BMP Peer Up Message Namespace.

These documents reflect a recurring concern with making network state available and interpretable. BGP filtering changes which paths the internet can use. Adj-RIB-Out shows what a router intends to advertise. Local RIB exposes selected state. A service-assurance model connects lower-level telemetry with a service view. A namespace makes BMP session information extensible without every addition colliding.

The work should not be described as unilateral protocol design. RFCs are products of co-authors, working groups, review and implementation experience. A working-group chair manages process and consensus rather than owning the subject. Lucente’s contribution lies in bringing operational and collector experience into that process.

At the August 2026 research cutoff, his IETF profile listed thirteen active Internet-Drafts. The number is a snapshot, not a measure of final output. Drafts can change, expire, merge or never become RFCs. Their themes—BMP TLVs, YANG, QUIC transport and message-broker telemetry—show where his current attention is directed.

The movement toward brokers is significant. Traditional telemetry often assumes a device or collector connects directly to a consumer. Large organisations increasingly use shared fabrics in which producers publish state and several applications subscribe. Standard representations can reduce custom integration, but they also add intermediaries, schema versions and security boundaries.

QUIC-based transport work reflects a similar attempt to reconsider the connection layer. A newer transport can offer stream and security properties useful to telemetry. It does not solve the semantics, loss policy or operational complexity above it. Standards have to specify enough for independent implementations without prescribing one deployment architecture.

Lucente’s dual role creates a feedback loop. pmacct reveals where available protocols are insufficient or ambiguous. Standards work can improve what routers export. Implementations then test whether the specification is usable. The loop is valuable because it ties protocol design to operational evidence, while remaining subject to the IETF’s collective process.

NTT provides operating context without turning pmacct into a company product

Lucente’s current IETF profile uses an ntt.net address, and professional biographies associate him with NTT. That relationship provides credible context for work on routing operations and telemetry at scale. It does not support a claim that every pmacct feature comes from NTT, that the company owns the project or that Lucente controls the telemetry architecture of the entire network.

A large backbone presents the problems pmacct was built to address: many routers and exporters, substantial route state, international links, several business relationships and a need to distinguish measurement failure from traffic change. It also has internal systems and confidential contracts that public project documentation does not reveal.

The responsible inference is that operational exposure informs Lucente’s priorities. BMP support, brokered telemetry and routing-aware accounting are not abstract concerns. They correspond to problems that become more visible as network scale grows. Exact deployments, performance and internal decision-making remain outside the evidence.

This boundary is important because open-source projects often sit beside employer systems. An engineer may contribute general code in public while the company maintains private integration, dashboards and operational procedures. The public project should not be credited with every private capability, and the company should not be assumed to control every public decision.

The relationship can support sustainability. Employer-funded time and production feedback can keep a maintainer engaged for years. It can also concentrate priorities around the problems faced by one large network. A diverse user and contributor base helps test whether the abstractions remain general.

No public accounts show how much of pmacct development is funded by NTT, other users or Lucente’s independent time. That uncertainty should be stated rather than replaced with estimates. The observable fact is continued maintenance and standards activity more than two decades after the project began.

Open collection competes with managed certainty and packaged convenience

pmacct overlaps with commercial network-observability platforms and other open-source collectors, but its value proposition is not one feature comparison. It gives operators a modular, routing-aware collection layer they can inspect and integrate into their own systems.

A managed platform can reduce time to value. It may bundle collectors, storage, visualisation, support and updated integrations. The customer pays licence and data costs but avoids operating every component. A commercial vendor can also provide a tested user interface and incident escalation.

pmacct avoids dependence on one hosted backend and allows networks to keep sensitive data in their chosen environment. It can adapt to local communities, schemas and accounting rules. That freedom requires engineers who understand exporters, brokers and databases. An organisation without that capacity may create a fragile system whose nominal software cost is low and whose operating cost is high.

Focused open-source alternatives make different trade-offs. Some combine collection and visualisation more tightly. Others optimise a particular storage engine or protocol. General routing-data platforms such as RIPE RIS or BGPStream provide broad internet views rather than local forwarding accounting. OpenTelemetry addresses application and infrastructure telemetry with a different semantic model.

The comparison should therefore start with control requirements. Does the network need to join traffic with its private BGP communities? Must data remain on premises? Does it require a supported dashboard or an API for internal systems? What is the retention scale? Which team will own schema and upgrades? pmacct is compelling when local control and routing context matter enough to justify the engineering.

The open design can also serve as a hedge. Even when a network uses a commercial analytics backend, an independent collector and portable record format can reduce the cost of changing destinations later. That benefit disappears if the pipeline depends on proprietary processors or if the data model is undocumented.

Lucente’s project has survived because it does not try to win every layer. It concentrates on collection, aggregation and enrichment. The discipline is similar to an infrastructure utility: remain useful to many downstream architectures without turning each into a dependency of the core.

Free software can still be expensive to sustain

pmacct has no published standalone revenue, valuation or conventional company structure. The code can be obtained without a project licence fee. Those facts do not describe the economics of the system or the labour required to keep it useful.

Development depends on Lucente’s time, contributions from users, employer context and the wider standards ecosystem. The exact funding mix is not public. A network using the software may pay internal engineers, consultants, infrastructure vendors and cloud or data-platform providers. None of that appears as pmacct revenue.

The maintenance burden spans protocols and integrations controlled elsewhere. IPFIX changes require exporter testing. Kafka and database libraries evolve. Operating systems change packet-capture and networking interfaces. BMP specifications gain features. Security fixes can affect parsers that accept data from many devices. A small project has to decide which combinations it can support credibly.

Users benefit from contributing reproducible bug reports, sample records and general fixes. Private deployments that consume the project without returning operational knowledge increase concentration around the maintainer. The open licence permits that behaviour; sustainability depends on whether enough organisations choose to invest in the shared layer.

The absence of a public installation census is relevant here. Repository stars and downloads do not reveal how many collectors are active, how large they are or whether they run current versions. A handful of large operators could create more maintenance value and risk than thousands of experiments. Funding decisions need better evidence than popularity metrics.

Lucente’s continuing IETF and project activity indicates durable commitment. It does not answer the succession question. A healthy future would include more people able to review protocol parsing, prepare releases and maintain major output paths. The best evidence will be responsibility distributed in the repository, not a broad claim about community size.

Lucente’s durable achievement is an open measurement boundary

Paolo Lucente’s work is sometimes easiest to describe through a list of protocols. The more durable contribution is the boundary he created between network observation and operator interpretation.

pmacct accepts evidence from packets, exporters, routing sessions and telemetry systems. It normalises and enriches that evidence. It sends the result into stores and applications chosen by the user. The architecture avoids claiming that one dashboard knows the network’s business meaning.

That restraint is essential. A flow record is not the packet path. A BGP route is not a contract. A community is not self-explanatory. A sampled estimate is not an exact bill. The collector becomes valuable when it preserves enough provenance for those distinctions to remain visible.

Lucente’s IETF work extends the same approach into standards. Routers should expose more of their internal routing state in interoperable forms. Collectors should be able to consume it. Operators should retain the authority to decide what the state means and what action follows.

The project’s openness does not eliminate cost or lock-in. Engineering, storage and schema can become substantial dependencies. It does give networks a way to own the junction at which raw traffic becomes an operational claim. That is a consequential form of control in an industry where the most expensive decisions are often justified by data collected somewhere else.