Devil's Advocate - Segment Routing, Why?

Fri Jun 19 15:13:30 UTC 2020

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 at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200619/5d1a7a9b/attachment.html>