Per-VRF Label or Per-Prefix? The Real Capacity Bill

Two designs advertise the same customer prefix across the same provider core. One allocates a label per prefix, the other allocates a single label for the whole VRF, and the second looks cheaper on every slide. The label count is real, but it is not the budget that usually runs out first. Deciding between the two means counting four resources, not one, and the labels are the smallest of them.

The choice also depends on what the egress router must do with the packet after it pops the label. That functional difference, not the label arithmetic, should drive the decision.

What each allocation actually saves

A per-prefix allocation carries forwarding information in the label. The egress router can send the packet straight to the right adjacency without a destination lookup, which is why it scales well for large VRF route sets and why it consumes one label for every advertised prefix in every VRF. A per-VRF allocation, such as Junos vrf-table-label, advertises one label per routing instance and uses that label to select the VRF table; the router then performs an IP lookup inside the table.

That is a real architectural difference rather than a tuning knob. Per-VRF labeling gives you a smaller label space and a simpler label advertisement, at the cost of one lookup and of a label that says nothing about the destination. Per-prefix labeling gives the egress line card more information up front and costs labels in proportion to the routes you carry.

The label ledger is the small one

MPLS labels are finite, but the label space is large enough that ordinary service providers do not exhaust it with a few thousand prefixes. Where per-VRF labeling genuinely helps is on platforms with small hardware label tables, or in designs where a single VRF carries a full Internet feed and per-prefix labels would multiply the label demand by the route count. Those are real constraints, and they are the reason the feature exists. None of them is about the number of prefixes in the table.

Count labels for both the service and the transport before you choose. A per-VRF design still needs transport labels for the loopbacks and for every hop along the path, and it still needs adjacency state. If the design brief only counts service labels, the saving is being measured on the wrong ledger.

Route feeds cost memory before labels

Every received path consumes control-plane memory, update processing, and convergence time, whether the VRF uses one label or ten thousand. A full Internet feed inside a VRF is expensive because of the BGP paths, the RIB, the FIB entries, and the churn behind them, not because of the label that fronts the table. The same feed also raises the blast radius of a route leak or a policy mistake inside that tenant.

So ask what the customer actually requires. If the contract is private sites plus a default exit, a full table adds cost without adding a requirement. That is a commercial question, and it deserves a written answer rather than an assumption inherited from the last design. If the service genuinely needs the feed for policy or for local egress selection, make that an explicit line item with its own capacity reservation and its own failure behavior.

When per-VRF labeling is the right default

It is a good default when the platform documents it as supported, when the VRF route count is large, and when the egress lookup cost is acceptable for the traffic profile. It is also the natural fit when operational simplicity matters more than squeezing the last microsecond out of forwarding, because one label per tenant is easier to explain and audit than a label per prefix.

It is the wrong default when the platform's documentation ties the feature to specific hardware or release constraints, or when the design depends on per-prefix forwarding decisions at the egress. Read the platform's own statement reference before assuming the behavior; the Junos command is documented, but the hardware and release limits around it are what actually decide the deployment.

A budget you can defend

Build the capacity case as five separate numbers: received paths, selected routes, installed forwarding entries, service labels, and transport labels. Add next-hop and adjacency state, tenant count, and the redundancy model. A single VRF's happy-path snapshot is not a scale figure, and a nominal label-space size is not an available hardware table.

Then agree the failure mode as well as the steady state. What happens when the feed grows by half, when a tenant adds a second VRF, or when the platform needs a reboot to resize a table? A budget that survives those questions is worth more than a label count that only works on paper.

Choose the allocation from the egress action and the platform limits, then make the route feed an explicit service decision. The label is the visible part of the design; the routes are the part that has to be paid for every day.