The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

Fong Liaw wrote:
> 
> "Infinite timer" is actually very problematice with RSVP.
> We have specifically recommend NOT to use this, after attempting
> to do it.

Eliminating refreshes over a link can cause a lot of problems in RSVP,
unless two things are done:

1: Hellos must be active on the link.  Without refreshes, the only
   way to detect failures is either Hello or loss of carrier on the
   fiber.  And loss of carrier won't happen in the case of a software
   failure.  Without Hellos, the only way to detect a software failure
   is missed refresh messages.

2: The reliable message delivery (MESSAGE_ID) mechanism of the RSVP
   Refresh Reduction RFC (Section 4 of RFC 2961) is in place on the
   link.  Without this, you can't be sure that a message sent was
   actually received.  Straight RSVP doesn't have a problem with this,
   because a missed packet will be repeated via the refresh mechanism.
   But if the refresh interval is very large, there must be some other
   means to make sure a message is delivered.

When both of these are in place, then there shouldn't be a problem
increasing the refresh interval to a very large amount, or infinite.

> Instead, we (will) recommend the following in OIF UNI document:
> 
>    Use RSVP Hello to detect control channel failure.
>    If a control channel failure is detected, LSPs states
>    are maintained as if a node continues to receive
>    RSVP refresh message from the failed control channel.
>    The recommended Hello timer will be in second range,
>    instead of ms range specified in RSVP-TE draft.
> 
>    If a control channel failed permanently, manual intervention
>    may be required. This is to be studied.

If you don't tear down state when a failure is detected, what's the
point of having a failure detection mechanism at all?

-- David