The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Between OSPF RSVP...
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
|
|