Devil's Advocate - Segment Routing, Why?

Sun Jun 21 10:10:43 UTC 2020

Mark Tinka 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.

No, of course, because, as we agreed, RSVP has a lot of problems.

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

It was implemented and some technology was used by commercial
router from Furukawa (a Japanese vendor selling optical
fiber now not selling routers).

>> 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.

GMPLS, you are using, is the mechanism to guarantee QoS by
reserving wavelength resource. It is impossible for GMPLS
not to offer QoS.

Moreover, as some people says they offer QoS with MPLS, they
should be using some prioritized queueing mechanisms, perhaps
not poor WFQ.

> I should probably point out, also, that RSVP (or RSVP-TE) is not MPLS.

They are different, of course. But, GMPLS is to reserve bandwidth
resource. MPLS, in general, is to reserve label values, at least.

> 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.

I didn't say scaling problem caused by QoS.

But, as you are avoiding to extensively use MPLS, I think you
are aware that extensive use of MPLS needs management of a
lot of labels, which does not scale.

Or, do I misunderstand something?

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

No. IntServ specifies format to carry QoS specification in RSVP
packets without assuming any specific model of QoS.

>> I didn't attempt to standardize our result in IETF, partly
>> because optical packet switching was a lot more interesting.
> 
> Still is, even today :-)?

No. As experimental switches are working years ago and making
it work >10Tbps is not difficult (switching is easy, generating
10Tbps packets needs a lot of parallel equipment), there is little
remaining for research.

	https://www.osapublishing.org/abstract.cfm?URI=OFC-2010-OWM4

>> 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.

SDN, maybe. Though I'm not saying SDN scale, it should be no
worse than MPLS.

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

I did some retrospective research.

    https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching
    History
    1994: Toshiba presented Cell Switch Router (CSR) ideas to IETF BOF
    1996: Ipsilon, Cisco and IBM announced label switching plans
    1997: Formation of the IETF MPLS working group
    1999: First MPLS VPN (L3VPN) and TE deployments
    2000: MPLS traffic engineering
    2001: First MPLS Request for Comments (RFCs) released

as I was a co-chair of 1994 BOF and my knowledge on MPLS is
mostly on 1997 ID:

    https://tools.ietf.org/html/draft-ietf-mpls-arch-00

there seems to be a lot of terminology changes.

I'm saying that, if some failure occurs and IGP changes, a
lot of LSPs must be recomputed, which does not scale
if # of LSPs is large, especially in a large network
where IGP needs hierarchy (such as OSPF area).

						Masataka Ohta