Re: Last call - RSVP problems

[Guangzhi Li <gli@research.att.com>]

Fong:

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

What are the specific problems? RSVP uses soft state because the traffic
route may change. In transport networks, the working path does not change
except restoration. If you can explain more, that would be help.

Let's see whether we can cover these problems from other methods, such as
link layer hello and reliable transmisson.

> >  (3) is achieved when Refresh Timers are set to Infinite. By default,
> >  circuit is kept irrespective of failures.
> >
>
> Same as (2), any proposals that remove the refresh mechanism
> is going to be difficult to prove that all cases are covered.

Has anybody proved that some cases have not been covered ? or assume that it
will be difficult to prove that all cases are coved. The second claim may
not be enough to avoid the "infinite timer" solution. If there is a
fundamental requirement to require soft-state, the question will become
easy.

> 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.
>
> p.s The text is currently being drafted as we type.

This is one solution. But GMPLS document does not include this.

> Regards,
> -Fong
>

Thanks,

-- Guangzhi