Re: Devil's Advocate - Segment Routing, Why?

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

On 20/Jun/20 14:41, Masataka Ohta wrote:

>  
> There are many. So, our research group tried to improve RSVP.

I'm a lot younger than the Internet, but I read a fair bit about its
history. I can't remember ever coming across an implementation of RSVP
between a host and the network in a commercial setting. If I missed it,
kindly share, as I'd be keen to see how that went.


> Practically, the most serious problem of RSVP is, like OSPF, using
> unreliable link multicast to reliably exchange signalling messages
> between routers, making specification and implementations very
> complicated.
>
> So, we developed SRSVP (Simple RSVP) replacing link multicast by,
> like BGP, link local TCP mesh (thanks to the CATENET model, unlike
> BGP, there is no scalability concern). Then, it was not so difficult
> to remove other problems.

Was "S-RSVP" ever implemented, and deployed?


> However, perhaps, most people think show stopper to RSVP is lack
> of scalability of weighted fair queueing, though, it is not a
> problem specific to RSVP and MPLS shares the same problem.

QoS has nothing to do with MPLS. You can do QoS with or without MPLS.

I should probably point out, also, that RSVP (or RSVP-TE) is not MPLS.
They collaborate, yes, but we'd be doing the community a disservice by
interchanging them for one another.


> Obviously, weighted fair queueing does not scale because it is
> based on deterministic traffic model of token bucket model
> and, these days, people just use some ad-hoc ways for BW
> guarantee implicitly assuming stochastic traffic model. I
> even developed a little formal theory on scalable queueing
> with stochastic traffic model.

Maybe so, but I still don't see the relation to MPLS.

All MPLS can do is convey IPP or DSCP values as an EXP code point in the
core. I'm not sure how that creates a scaling problem within MPLS itself.

If you didn't have MPLS, you'd be encoding those values in IPP or DSCP.
So what's the issue?


> So, we have specification and working implementation of
> hop-by-hop, scalable, stable unicast/multicast interdomain
> QoS routing protocol supporting routing hierarchy without
> clank back.
>
> See
>
>     http://www.isoc.org/inet2000/cdproceedings/1c/1c_1.htm
>
> for rough description of design guideline.

If I understand this correctly, would this be the IntServ QoS model?

 
> I didn't attempt to standardize our result in IETF, partly
> because optical packet switching was a lot more interesting.

Still is, even today :-)?


> That should be a reasonable way of practical operation, though I'm
> not very interested in OCS (optical circuit switching) of GMPLS

Design goals are often what they are, and then the real world hits you.



> For IP layer, that should be enough. For ASON, so complicated
> GMPLS is actually overkill.
>
> When I was playing with ATM switches, I established control
> plain network with VPI/VCI=0/0 and assign control plain IP
> addresses to ATM switches. To control other VCs, simple UDP
> packets are sent to switches from controlling hosts.
>
> Similar technology should be applicable to ASON. Maintaining
> integrity between wavelength switches is responsibility
> of controllers.

Well, GMPLS and ASON is basically skinny OSPF, IS-IS and RSVP running in
a DWDM node's control plane.


> No, I just explained what was advertised to be MPLS by people
> around Cisco against Ipsilon.
>
> According to the advertisements, you should call what you
> are using LS or GLS, not MPLS or GMPLS.

It takes a while for new technology to be fully understood, which is why
I'm not rushing on to the SR bandwagon :-).

I can't blame the sales droids or the customers of the day. It probably
sounded like dark magic.


> Assuming a central controller (and its collocated or distributed
> back up controllers), we don't need complicated protocols in
> the network to maintain integrity of the entire network.

Well, that's a point of view, I suppose.

I still can't walk into a shop and "buy a controller". I don't know what
this controller thing is, 10 years on.

IGP's, BGP and label distribution protocols have proven themselves, in
the interim.


> What if, an inner label becomes invalidated around the
> destination, which is hidden, for route scalability,
> from the equipments around the source?

I can't say I've ever come across that scenario running MPLS since 2004.

Do you have an example from a production network that you can share with
us? I'd really like to understand this better.


> No, as "the destination expected to pop the label" is located somewhere
> around the final destination end-host.
>
> If, at the destination site, connectivity between a router to pop nested
> label and the fine destination end-host is lost, we are at a loss,
> unless source side changes inner label.

Maybe a diagram would help, as I still don't get this failure scenario.

If a host lost connectivity with the service provider network, getting
label switching to work is pretty low on the priority list.

Again, unless I misunderstand.


> If you are using intra-domain hierarchical routing for
> scalability within the domain, you still suffer from
> lack of scalability of MPLS.
>
> And, VRF is, in a sense, a form of intra-domain hierarchical
> routing with a lot of flexibility, which means a lot of
> unnecessary complications.

I don't think stuffing your VRF's full of routes is an intrinsic problem
of MPLS.

MPLS works whether you run l3vpn's or not. That MPLS provides a
forwarding paradigm for VRF's does not put it and the potential poor
scalability VRF's in the same WhatsApp group.

Mark.