Mark Tinka wrote:
At the time I proposed label switching, there already was RSVP but RSVP-TE was proposed long after MPLS was proposed.
RSVP failed to take off, for whatever reason (I can think of many).
There are many. So, our research group tried to improve RSVP. 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. 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. 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. 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.
I'm not sure any network operator, today, would allow an end-host to make reservation requests in their core.
I didn't attempt to standardize our result in IETF, partly because optical packet switching was a lot more interesting.
Even in the Transport world, this was the whole point of GMPLS. After they saw how terrible that idea was, it shifted from customers to being an internal fight between the IP teams and the Transport teams. Ultimately, I don't think anybody really cared about routers automatically using GMPLS to reserve and direct the DWDM network.
That should be a reasonable way of practical operation, though I'm not very interested in OCS (optical circuit switching) of GMPLS
In our Transport network, we use GMPLS/ASON in the Transport network only. When the IP team needs capacity, it's a telephone job :-).
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.
Remember that the original point of MPLS was that it should work scalably without a lot of configuration, which is not the reality recognized by people on this thread.
Well, you get the choice of LDP (low-touch) or RSVP-TE (high-touch).
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.
We don't use RSVP-TE because of the issugaes you describe above.
We use LDP to avoid the issues you describe above.
In the end, SR-MPLS is meant to solve this issue for TE requirements. So the signaling state-of-the-art improves with time. Assuming a central controller (and its collocated or distributed back up controllers), we don't need complicated protocols in
Good. the network to maintain integrity of the entire network.
That is certainly a problem. However, worse problem is to know label values nested deeply in MPLS label chain.
Why, how, is that a problem? For load balancing? What if, an inner label becomes invalidated around the destination, which is hidden, for route scalability, from the equipments around the source?
Even worse, if route near the destination expected to pop the label chain goes down, how can the source knows that the router goes down and choose alternative router near the destination?
If by source you mean end-host, if the edge router they are connected to only ran IP and they were single-homed, they'd still go down.
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.
MPLS with hierarchical routing just does not scale.
With Internet in a VRF, I truly agree.
But if you run a simple global BGP table and no VRF's, I don't see an issue. This is what we do, and our scaling concerns are exactly the same whether we run plain IP or IP/MPLS.
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. Masataka Ohta