The MPLS WG Archive

[Fong Liaw <fliaw@zaffire.com>]

See inline

>  -----Original Message-----
>  From: David Charlap [mailto:david.charlap@marconi.com]
>  Sent: Friday, May 25, 2001 2:49 PM
>  To: mpls@UU.NET
>  Subject: Re: Last call - RSVP problems
>  
>  
>  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.

This is being recommended, plus using LMP hello etc, per Jonathan's
comment.

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

This is also been recommended. The MESSAGE_ID ACK draft gives up
the retransmission after a preconfigured retry. We know we would
have very high probably that messages will be acked, but can we be
100% sure about the states in the case we receive no ackwnologyment 
to these message and we have extended the timer to infinite ?

>  
>  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?

This is to address the requirement from transport networks
where a failure of control channel can not affect the
data plane state.  We wouldn't be having this discussion
if that is not a requirement :-)

-Fong

>  
>  -- David
>