Hi Mark,

As actually someone who was at that table you are referring to - I must say that MPLS was never proposed as replacement for IP. 

MPLS was since day one proposed as enabler for services originally L3VPNs and RSVP-TE. Then bunch of others jumped on the same encapsulation train. If at that very time GSR would be able to do right GRE encapsulation at line rate in all of its engines MPLS for transport would never take off. As service demux - sure but this is completely separate. 

But since at that time shipping hardware could not do the right encapsulation and since SPs were looking for more revenue and new way to move ATM and FR customers to IP backbones L3VPN was proposed which really required to hide the service addresses from anyone's core. So some form of encapsulation was a MUST. Hence tag switching then mpls switching was rolled out. 

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. 

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. Till L3VPN arrived which was game changer and run for new revenue streams ... 

Best,
R.


On Fri, Jun 19, 2020 at 5:00 PM Mark Tinka <mark.tinka@seacom.mu> wrote:


On 19/Jun/20 16:45, Masataka Ohta wrote:

> The problem of MPLS, or label switching in general, is that, though
> it was advertised to be topology driven to scale better than flow
> driven, it is actually flow driven with poor scalability.
>
> Thus, it is impossible to deploy any technology scalably over MPLS.
>
> MPLS was considered to scale, because it supports nested labels
> corresponding to hierarchical, thus, scalable, routing table.
>
> However, to assign nested labels at the source, the source
> must know hierarchical routing table at the destination, even
> though the source only knows hierarchical routing table at
> the source itself.
>
> So, the routing table must be flat, which dose not scale, or
> the source must detect flows to somehow request hierarchical
> destination routing table on demand, which means MPLS is flow
> driven.
>
> People, including some data center people, avoiding MPLS, know
> network scalability better than those deploying MPLS.
>
> It is true that some performance improvement is possible with
> label switching by flow driven ways, if flows are manually
> detected. But, it means extra label-switching-capable equipment
> and administrative effort to detect flows, neither of which do
> not scale and cost a lot.
>
> It cost a lot less to have more plain IP routers than insisting
> on having a little fewer MPLS routers.

I wouldn't agree.

MPLS is a purely forwarding paradigm, as is hop-by-hop IP. Even with
hop-by-hop IP, you need the edge to be routing-aware.

I wasn't at the table when the MPLS spec. was being dreamed up, but I'd
find it very hard to accept that someone drafting the idea advertised it
as being a replacement or alternative for end-to-end IP routing and
forwarding.

Whether you run MPLS or not, you will always have routing table scaling
concerns. So I'm not quite sure how that is MPLS's problem. If you can
tell me how NOT running MPLS affords you a "hierarchical, scalable"
routing table, I'm all ears.

Whether you forward in IP or in MPLS, scaling routing is an ever clear &
present concern. Where MPLS can directly mitigate that particular
concern is in the core, where you can remove BGP. But you still need
routing in the edge, whether you forward in IP or MPLS.

Mark.