The MPLS WG Archive

[Tony Li <tli@juniper.net>]

Chris,


|  True, as long as the reservation protocol itself is deemed suitable and
|  appropriate for the purpose.  Other than "lets reuse something we already
|  have", what is the real argument for using RSVP for engineering paths within
|  a label cloud?  Maybe I've just missed it in all the mail about this subject
|  recently.


We know that we need a signaling protocol.  It need not run end to end, but
must run from domain edge to domain edge.  We know that we need certain
properties, such as the ability to describe the traffic load associated
with an LSP (i.e., carry a flowspec).  We know we need to be able to
provide explicit routing.  For the sake of explicit routing, we would like
a protocol that runs from source to sink (and not vice versa).  To improve
scalability, we need a protocol that allows us to merge LSPs.  The protocol
MUST NOT scale with the number of IP prefixes in the network.

So.... not only is RSVP something that we already have, but it addresses
many of these issues, so leveraging their work is to our benefit.


|  My interest in RSVP is primarily because it is the only thing of its kind
|  out there right now.   But, just as others do, I have strong concerns about
|  its architecture (most of which boild down to scalability eventually).  


With all due respect to the RSVP folks....  You should note that the
architectural scalability issue that we've found is related to the
distribution of per-flow state.  As we're not dealing with per-flow state,
but per-LSP state [which is pretty much inevitable], this doesn't seem like
a significant architectural problem.

The other scalability problems that we've found are protocol design
problems not truly architectural, which we simply need to work through.

Tony