LDP Label Allocation Revisited

One of my readers was having an LDP argument with his colleague:

Yesterday I was arguing with someone who works for a large MPLS provider about LDP label allocation. He kept saying that LDP assigns a label to each next-hop, not to each prefix. Reading your blog, I believe this is the default behavior on Juniper but on Cisco LDP assigns a unique label for each IGP (non-BGP) prefix.

He’s absolutely right; Cisco and Juniper use different rules when allocating MPLS labels.

Cisco IOS allocates a label to every IGP prefix in the IP routing table (not to BGP prefixes). Junos allocates a label to every local loopback interface and to all prefixes that have label assigned by the downstream router, resulting in labels assigned to all loopback interfaces.

Loopback interfaces happen to be BGP next hops in MPLS/VPN environments, and for regular BGP destinations if you’re using next-hop-self on IBGP sessions, so his colleague was probably used to Junos way of doing things.

But then that brings up an interesting question. The max number of labels you can have is close to 1 million (2 to the power of 20) which is not enough if you want to assign a label to reach internet prefix.

Nobody is allocating prefixes to BGP routes unless you’re using send-label with a BGP neighbor. Cisco IOS is using recursive route lookup and uses MPLS label for BGP next hop for BGP prefixes.

I know it’s crazy thought to carry a full Internet routing table in IGP, but assuming that is the case how is LDP going to scale?

Nobody is doing that either. Dumping BGP table into IGP successfully kills every IGP known to mankind at this moment.

I wonder why Cisco chose this approach as the default? Does allocating a label per prefix have some advantages I’m not seeing?

I guess it’s mostly for historic reasons. I don’t see other advantages… and of course I’m probably missing something obvious, so please write a comment and fix it.


  1. I suppose another historic reason is Independent Label Distribution Mode used by Cisco. I dont see why would it be nowadays profitable to have label allocatel right away and not to wait till the whole path would have labels allocated.

    As for Alcatel-Lucent routers they also bind labels for "system" ip address and for prefixes with allocated labels from a downstream router http://noshut.ru/2015/06/ldp-ordered-label-distribution-control-explained/

    One interesting question I faced when learning LDP is how do routers perform split-horizon? If we have three routers in line (R1-R2-R3) and R1 starts tp propagate label for its lo1=, how would R2 determine not to send it back to R1?
    1. Actually R2 will assign a label for and send this to R1, even though it does not make much sense in this case. LDP is relying on the underlying IGP.

      So at the end this label would be ignored on R1 as the path-calculation of the IGP will not use R2 as next-hop for as it is directly connected.
    2. @sgraf, It seems to be open to vendors optimizations. I have not tested Junos, but ALU routers will not send LDP binding back to its originator (wireshark dumps are available)
    3. ok, nice to know. Actually on Junos you would see these "useless" Labels in the input database of LDP.
  2. This comment has been removed by the author.
  3. I'm surprised ALU does not advertise the labels back, as their implementation is basically the same as Juniper, ordered control and liberal label retention.

    Independent label allocation came from the original Cisco TDP. Maybe Bruce Davies could answer what the exact reasoning was. I've heard faster convergence before since the whole network doesn't have to be "up" speaking MPLS before MPLS could be switched.
  4. Q: Does allocating a label per prefix have some advantages I’m not seeing?
    Sure it does, just look for the "mpls label mode all-vrfs protocol bgp-vpnv4 per-?
    per-prefix per-vrf" command and its limitations for different platforms. On MPLS PE routers VRFs there are several limitations once you decide to allocate per vrf or per CE label, you cannot use (e|i)BGP multipath, EIGRP multipath, BGP PIC,CSC scenarios...

    This means that the per prefix allocation on Cisco makes use of mpls label switching at the edge, so once you use 1 label to represent more prefixes you need additional lookup at the edge to forward the packet to the correct next hop.
    1. For IOS, as I know there is 3 label allocation modes. Per-prefix uses most label but allows PE to forward packets w/o lookup. Per-VRF uses least label w/o trade-off of additional lookup within the VRF. Per-CE is kind of hybrid, PE allocates label based on CE/nexthop, saving label and w/o lookup.

      But as you said, if you like to deploy these "advanced" features like BGP PIC, per-prefix is a must.
    2. Solomon - you are mixing label allocation for VPN prefixes with LDP allocation modes.There are some semantics we could discuss another time.
  5. Those of us, old enough.. remember endless discussion about faster convergence (flood bindings ASAP) with potential to blackhole (readvertising without ensuring downstream has a label) on IOS (Independent) vs waiting to receive binding from downstream and then advertising it upstream on Junos (Ordered)
    In real life however it wasn't as clear, Ordered has some issues with convergence time in rings, which led to lot's of mess and some shortcuts in implementations...
    Old good times :)
Add comment