[arin-ppml] Modified Header Forwarding for scalable routing

[michael.dillon at bt.com]

> Short version:   MPLS doesn't seem to be suitable for the task of
>                  scalably transporting traffic packets across the
>                  DFZ in a core-edge separation solution to the
>                  routing scaling problem.

That is an opinion, but I don't think that anyone has examined
the suitability of MPLS for this role in enough detail in order
to determine whether or not it is suitable. In particular, the
role under discussion is such a key role than any inadequacy
of any given technology could be changed and those changes 
would be implemented by all the vendors that matter.

>  Even if it was suitable,
>                  it involves encapsulation overhead and therefore
>                  Path MTU Discovery problems.

How many nanoseconds of encap overhead are there on 10G links?
As for PMTU discovery, this is a solveable problem since
if there is a will to make an MPLS core, there would also be
a will to establish a set of standard MTUs that would guarantee
a specified MTU size across the entire core. Or maybe there 
would be separate cores for jumbo MTUs and smaller ones.

> MPLS's extra packet length represents inefficiency, 
> especially for small VoIP packets, 

In the UK, the PSTN is being migrated onto VoIP over MPLS
As of the 16th of December there are over 700 telephone
exchanges running on MPLS and around 800 exchanges ready
for Ethernet local access connections. In other words, in
addition to VoIP packets, this network carries normal IP
traffic such as business VPNs and last mile broadband
Internet access for ISPs.

You may be correct that MPLS packets take an extra nanosecond
to transit a router, but to call that inefficient ignores
all of the other benefits of having a converged core.

I recognize that my employer is a pioneer in doing this much
with MPLS, but many more carriers are running international
MPLS networks carrying VoIP along with Internet traffic,
VPNs, telepresence, streaming video, video backhaul and other
things. The arguments of 1995 do not apply to today's MPLS.

> So I don't think MPLS is a suitable technique.  AFAIK, no RRG 
> proposal uses MPLS.

There is no guarantee that the RRG will agree with any of the 
proposals before it nor is there any guarantee that the RRG 
won't go with something completely different from all current
proposals. It's not a beauty contest. The RRG wants something
that will work in the real world, and that can be transitioned
without causing massive network disruption.

In the meantime, the real world has already solved the problem
and is continuing to build out more infrastructure BYPASSING
THE PUBLIC INTERNET. If growth goes elsewhere, then the Internet
core has less need to grow.

--Michael Dillon