The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <HBNK5E$B65A1A02511883B158F736061C040B88@libero.it>, "john151@libero
.it" writes:
> Hi Curtis hi all,
> essentially my considerations are: if i have two pre-calculated disjoint back
> up paths and i use opaque LSA to flood the link failure information,
> it could be a reasonable faster  way of proceeding instead of using RSVP if i
>  have an intelligence in the source routers (routers have to be able to switc
> h among the two LSPs if they receive that particular opaque LSA; note that fo
> r a restoration of many LSPs RSVP will work in series, but OSPF will work in 
> parallel with its flooding mechanism).
> So the basic question is: is it a reasonable way the use of OSPF  and opaque 
> LSA? Is there a reason to the use always RSVP for path protection, since, i t
> hink, increasing the LSPs corrupted by one link failure (if there are many ac
> tive LSPs on the link that goes down) the OSPF mechanism of flooding is more 
> efficient than using many RSVP messages from node that detects the failure to
> wards the LSPs senders?


You just described standby LSPs.

Apparently you don't understand how RSVP/TE works.

Each ingress discovers that the LSP is no longer feasible through RSVP
and through OSPF.  It determines how the topology has changed through
the flooded OSPF information.  If the paths are setup in advance, the
LSR doesn't care why one LSP is no longer feasible so it doesn't
matter if the RSVP or OSPF information arrives first.  It switches to
the other LSP immediately.

Not only is it reasonable, it is how existing implementations
currently work.

Curtis