The MPLS-OPS Archive

[Ping Pan <pingpan@juniper.net>]

Srihari Raghavan wrote:
> 
>    Am I right in saying the following things about RSVP/RSVP-TE when used
> for MPLS traffic engineering at the core/backbone networks?
> 
>    1. RSVP in its original form is used to set up per-flow (data traffic)
> state at each intermediate router. Is this found not scaleable because of
> the 'soft state', potential large number of data flows and non usage of
> reliable protocols like TCP?
> 

Well. Soft-state mechanism may introduce processing overhead, on the
other hand, full TCP stack is not that cheap in processing either. In
the RSVP refresh reduction draft, we have also introduced a mechanism on
message reliability. Please refer 
http://www.cs.columbia.edu/~pingpan/papers/timergi.ps for detail. 

>    I think what i am trying to understand is how RSVP-TE is scalable while
> there are some concerns about RSVP not being so. Is it because of
> scalability extensions like like message_id extension, Bundle message
> extension, summary refresh extension and hello protocol extension? or is it
> any of the reasons above?
> 

Hello extension is not designed for saving processing overhead (or
scalability). With refresh reduction, we can save a lot of CPU cycles.

--
Ping Pan

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml