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