MPLS-TE path-options

[leedavies]

Hi

Can you please clarify my understanding of MPLS-TE path-options and how the head-end fails over to less-preferred paths when using inter-area tunnels? Assuming I have a working inter-area tunnel with multiple explicit paths defined:

• The tunnel head-end will switch from path-option 1 to path-option 2 based on RSVP events only, eg. tunnel preemption or lack of bandwidth somewhere along path 1.
  
• A node or link failure along path 1 will not trigger the switch to path-option 2 it will drop the tunnel instead.
  

Is this the expected behaviour? Is there another way to trigger the failover to the second path?

Thanks in advance

[maayre]

To clarify when you mention a node failure is the node in the same area as the headend or a remote area?

When you contrast preemption vs node fail you say switch paths vs drop paths. Can you explain exactly what you mean here?

It's logical that you would tear down a tunnel if a node failed and try to signal again. I think you are referring to when preemption occurs the tunnel has some time to signal the new path and switch. Ultimately if the new path is not found eventually the same outcome will be reached.

Actually preemption is tunable between hard and soft which are tear down and reoptimize respectively.

Maybe my answer just introduces new questions..

HTH,

Matt

[judebryant]

Lee,

When I have multiple paths to a destination via MPLS, I use the pseudowire-class with preferred-path peer option.

This allows me to create a preferred path instead of relying on the IGP.  If this preferred path were to fail then the IGP takes over and switches the path to an alternate using its forumula.

Hope this helps.

Jude Bryant

[leedavies]

Thanks for your replies.

I've got this working now by changing my explicit-paths to use interface addresses instead of RID's and getting RSVP Hellos working properly.  I'm testing in Dynamips and the RSVP Hellos weren't triggering the reroute until I raised the interval and misses threshold.