Subject: RE: initiating a discussion on mpls singaling protocols

From: [email-masked]
Date: Fri, 19 Jul 2002 16:47:19 +0100

David Charlap wrote 19 July 2002 15:19
> Yangguang Xu wrote:
> > 
> > Cause many folks raise the RSVP-TE soft state issue and its 
> apparent drawbacks
> > for GMPLS environment. Just a question, if we configure the 
> refresh timer very
> > large, disable the refresh reduction and also maximize the 
> time-out multiplier.
> > Will these help, or they make things worse?
> 
> If you do all of these, then you can no longer detect or 
> handle failures 
> that don't cause carrier to be lost in the data-plane.
NH=> Can you elaborate what you mean by this please David, and against which
particular user-plane framing structure you are referring to (ie MPLS or SDH
or OTN) and whether you are referring to cases where the signalling is
in-band or out-of-band wrt to the traffic's user-plane.  Thanks, regards,
Neil
> 
> It is possible to safely use a very large refresh timer, but 
> only when 
> refresh reduction and hello are in use on all peers.  The message-id 
> part of refresh reduction will allow for retransmission of 
> lost packets, 
> and hellos will detect soft failures.
> 
> -- David
> 
>

---

From: David Charlap <[email-masked]>
Date: Fri, 19 Jul 2002 14:59:50 -0400

[email-masked] wrote:
>> handle failures that don't cause carrier to be lost in the data-plane.
> 
> Can you elaborate what you mean by this please David, and against which
> in-band or out-of-band wrt to the traffic's user-plane.

Simple.

Layer-1 protection features will continue to work.  If someone pulls a 
fiber, carrier will be lost and the interface will go down, and RSVP 
will handle that.

But soft-state also detects software failures.

Suppose the RSVP protocol crashes on a box.  The interface remains up. 
Packets continue to arrive, but they aren't processed.

Classical RSVP will detect the loss of refresh messages and will start 
deleting state as it times out.  If you increase the refresh interval or 
multiple, then that amount of time will be much greater.  With a default 
interval of 30 seconds and a default multiple of 3, state will time out 
in 1.5 minutes.  This is already too slow for many situations.

The other thing that soft-state gets is reliable delivery.  If a Path 
message is sent and lost, it will be retransmitted at the next refresh 
interval, and the LSP should continue coming up at that point.  If the 
interval is greatly increased, it will take a long time before this 
retransmission happens.

The Hello part of RSVP-TE solves the first problem.  When Hellos are 
used, a failure will be rapidly detected regardless of the refresh interval.

The Refresh Reduction RFC solves the second problem.  The Message ID 
part of that RFC will cause trigger messages to be rapidly retransmitted 
until they are acknowledged (according to an exponential backoff algorithm.)

Which means it is safe to use a large refresh interval when both Hellos 
and Refresh Reduction are in use.  But not if they aren't.

-- David