Re: why am i in this handbasket? (was Devil's Advocate - Segment Routing, Why?)

[Mark Tinka <mark.tinka () seacom mu>]

On 22/Jun/20 14:49, Masataka Ohta wrote:

>  
> But, it should be noted that a single class B...

CIDR - let's not teach the kids old news :-).

 
> If you have 1000 PEs, you should be serving for somewhere around 1000
> customers.

It's not linear.

We probably have 1 edge router serving several-thousand customers.


> And, if I understand BGP-MP correctly, all the routing information of
> all the customers is flooded by BGP-MP in the ISP.

Yes, best practice is in iBGP.

Some operators may still be using an IGP for this. It would work, but
scales poorly.


> Then, it should be a lot better to let customer edges encapsulate
> L2 or L3 over IP, with which, routing information within customers
> is exchanged by customer provided VPN without requiring extra
> overhead of maintaining customer local routing information by the
> ISP.

You mean like IP-in-IP or GRE? That already happens today, without any
intervention from the ISP.


> If a customer want customer-specific SLA, it can be described
> as SLA between customer edge routers, for which, intra-ISP MPLS
> may or may not be used.

l2vpn's and l3vpn's attract a higher SLA because the services are mostly
provisioned on-net. If an off-net component exists, it would be via a
trusted NNI partner.

Regular IP or GRE tunnels don't come with these kinds of SLA's because
the ISP isn't involved, and the B-end would very likely be off-net with
no SLA guarantees between the A-end customer's ISP and the remote ISP
hosting the B-end.


> For the ISP, it can be as profitable as PE-based VRF solutions,
> because customers so relying on ISPs will let the ISP provide
> and maintain customer edges.

There are few ISP's who would be able to terminate an IP or GRE tunnel
on-net, end-to-end.

And even then, they might be reluctant to offer any SLA's because those
tunnels are built on the CPE, typically outside of their control.


> The only difference should be on profitability for router makers,
> which want to make routing system as complex as possible or even
> a lot more than that to make backbone routers a lot profitable
> product.

If ISP's didn't make money from MPLS/VPN's, router vendors would not be
as keen on adding the capability in their boxes.


> Label stack was there, because of, now recognized to be wrong,
> statement of Yakov on day one and I can see no reason still to
> keep it.

Label stacking is fundamental to the "MP" part of MPLS. Whether your
payload is IP, ATM, Ethernet, Frame Relay, PPP, HDLC, e.t.c., the
ability to stack labels is what makes an MPLS network payload agnostic.
There is value in that.

Mark.