In MPLS enabled routers, is a unique label generated per Destination prefix in routing Table or is it per Next-hop in the routing table if not both, how is the mapping between unique labels and routing table entry ? Also, if it is per Destination prefix, how sclable is it? As per my understanding maximum label value is 2^20 = 1048576. What if number of routing table entries is greater than 1048576?
is a unique label generated per Destination prefix in routing Table or is it per Next-hop in the routing table? ...i have seen customer scenarios approaching 1 million routes... But the MPLS doesn't have any common guidelines for label generation ? Is there not a common rule saying a unique label should be generated per Destination-prefix or per nexthop ? or is it just implementation specific?
There seems to be a little confusion. It's rather unlikely that someone would ever want to allocate a unique label per internet route. A well-designed MPLS network should allocate labels based on IGP prefixes that are bound to your BGP next-hops (ref RFC 3031, Section 4.6).
As such, I'm not really sure 1 Million labels in the LFIB is a serious MPLS design constraint today.
The exact practical scenario when labels might run out is debatable. There are some house-keeping issues also which are not directly related to labels running out but contribute to that effect.
Label managers today in major vendors (CSCO, JNPR at least) are programmed so that they need continuous block per label application. Of course this could be fixed, with some cost in performance and complexity, but is certainly another issue to consider.
Some MPLS services are quite hungry for label-space in the core, in the edge is mostly irrelevant as we can mask them under our 'IGP label'.
We need to remember MPLS is not just about IP, it is about FEC, if we need to give some service different treatment/path in the core, we need new FEC.
There are some discussions about supporting mega labels and big labels, their use cases, although more likely implementation will via special purpose labels. Personally I'd hope/expect MPLS wire-format to be changed before 2^20 becomes an issue. As MPLS is mostly used only inside one operator network, changing the wire-format is super easy in comparison to IPv4->IPV6 migration, so what ever problems we'll run into, addressing them will be quite simple. Some issues I'd like to be solved:
- Ability to retain label history in-transit
- Low byte overhead (TTL, TC are redundant in stacked labels)
- Remove need for transit P 'duck-typing' MPLS payload (breaks ECMP today)
- Extendable by design (special purpose labels introduce huge byte-cost)
- Increased label space
- Co-existence with MPLSv1