The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Mar> msg00218



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Between OSPF RSVP...

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Wed, 12 Mar 2003 18:01:04 -0500
  • cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>


In message <C77B73BC1A3ED4118C2000508BAD8A7C0651F47B@ma8117exch001u.inse.lucent
.com>, "Nair, Girish (Girish)" writes:
> 
> 
> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Wednesday, March 12, 2003 4:21 PM
> To: Nair, Girish (Girish)
> Cc: 'john151@libero.it'; mpls
> Subject: Re: Between OSPF RSVP... 
> 
> 
> 
> In message
> <C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.inse.lucent
> .com>, "Nair, Girish (Girish)" writes:
> > Giovanni,
> > 
> > I agree. Link down LSP rerouting can be done a little more efficiently
> > using the IGP. This has been done in some proprietary signaling
> > implementations
> > and works well. It involves tighter coupling between the IGP and signaling
> > though.
> > 
> > Girish
> 
> 
> 	There is nothing proprietary about this.  ***All*** IP routers that
> 	implement OSPF/TE and/or ISIS/TE do this AFAIK and probably all LSR
> 	that implement OSPF/TE and/or ISIS/TE (the remaining subset is
> mostly
> 	ATM switches).
> 
> 	I welcome corrections from anyone that knows of an LSR that
> implements
> 	OSPF/TE or ISIS/TE that doesn't use the flooded information as a
> hint
> 	that some of the LSPs are down.
> 
> 	Curtis
> 
> 
Curtis,
> 
> When a link goes down, the LERs which had an LSP over that
> link, get a Path Tear and intermediate nodes Path Tears or 
> Resv Tears for each LSP affected. If this PSB 
> clean up happens via OSPF-TE first, and each node cleans up 
> intelligently, do the nodes just ignore the Path Tear or 
> Resv Tear messages coming later? 
> 
> Girish


The path tear is specific to a particular LSP.  A new LSP is created,
sharing the resources (which handles the case where not all downstream
nodes know the original went down) but distinct from the first.
Traffic is switched to the new LSP.  The LSP is then torn down if the
Path Tear has not yet arrived.

If the path tear arrives after the new LSP comes up that's OK too
because the new LSP is distinct from the old one and is unaffected.
If tears are lost and some resources of the old LSP time out then
thats almost OK (in some cases, not really) since the new LSP shares
resources with the old.

AFAIK ***every*** LSR does this.

If the "new" LSP is presignaled then some time is saved and the
recovery is often complete before the path tear arrives.  This is very
much implementation dependent with some implementations flooding IGP
change faster than propogating RSVP and others propogating RSVP
changes faster.

This is the same procedure as a make-before-break reroute but with a
somewhat involuntary trigger on the reroute.

Curtis