Robert Raszuk wrote:
MPLS was since day one proposed as enabler for services originally L3VPNs and RSVP-TE. There seems to be serious confusions between label switching with explicit flows and MPLS, which was believed to scale without detecting/configuring flows.
At the time I proposed label switching, there already was RSVP but RSVP-TE was proposed long after MPLS was proposed. But, today, people are seems to be using, so called, MPLS, with explicitly configured flows, administration of which does not scale and is annoying. Remember that the original point of MPLS was that it should work scalably without a lot of configuration, which is not the reality recognized by people on this thread.
So I think Ohta-san's point is about scalability services not flat underlay RIB and FIB sizes. Many years ago we had requests to support 5M L3VPN routes while underlay was just 500K IPv4.
That is certainly a problem. However, worse problem is to know label values nested deeply in MPLS label chain. Even worse, if route near the destination expected to pop the label chain goes down, how can the source knows that the router goes down and choose alternative router near the destination?
Last - when I originally discussed just plain MPLS with customers with single application of hierarchical routing (no BGP in the core) frankly no one was interested.
MPLS with hierarchical routing just does not scale. Masataka Ohta