The MPLS WG Archive

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

I've a question regarding interaction between RSVP-TE Refresh Reduction 
and Fast Reroute.

There is obviously no problem using Refresh Reduction for signaling 
Detour LSPs and bypass LSPs.

A potential problem, however, is using it when sending Path messages 
into bypass tunnels (as a part of facility backup.)

If it is not used, then the PLR and MP may be unable to maintain state. 
  If you create several hundred thousand LSPs (which most hardware will 
require refresh reduction in order to maintain stably), and then these 
all fail-into a bypass, it's unlikely that the PLR will be able to 
refresh all of these every 30 seconds.

On the other hand, actually implementing refresh reduction in this 
context is not trivial.  The RR control data that is normally associated 
with an interface (e.g. most recently received message ID, list of 
message IDs to Ack/Nack, etc.) must now also be associated with every 
bypass LSP.  Code that works with these structures must now be able to 
work with them, both on interfaces and on LSPs, instead of just on 
interfaces.

On the other other hand, RR may be overkill in this context.  We don't 
necessarily need all the overhead of RR in this case, because we have 
the state of the bypass itself.  We don't need to refresh LSPs in 
bypasses, because failures will cause the bypass itself to go down, 
which we will detect.  So maybe we can just set the refresh interval to 
a very large number when sending Paths into bypasses and avoid this 
issue altogether.

Opinions?

-- David