Subject: RSVP-TE: what to do if a link or node is lost?

From: "Zhang, Jeffrey" <[email-masked]>
Date: Thu, 30 Sep 1999 10:20:35 -0400

Hi,

draft-ietf-mpls-rsvp-lsp-tunnel-04.txt says:

   The RSVP Hello extension enables RSVP nodes to detect when a
   neighboring node is not reachable.  The mechanism provides node to
   node failure detection.  When such a failure is detected it is
   handled much the same as a link layer communication failure.

How is a link failure handled (other than that routing tells RSVP a new (set
of) nexthop)? Neither rfc2205 nor the draft talks about what to do when RSVP
detects that a link failed or a neighbor is lost (neighbor reset is indeed
covered in the draft).

Should the detecting node send a PATH-ERR message to the ingresses of LSP
tunnels that use the link/neighbor as nexthop, so that re-calculations for
the tunnels can triggered? Is so, what's the error code/value? Should it be
included in the draft?

Thanks.

Jeffrey

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Sep 1999 11:20:37 -0400

We tried a more detailed description of behavior in an earlier version of
the draft.  Consensus was that we should base our description on the
standard specification, RFC2205.  (Including it's level of detail.)  In
addition to mentioning route change, RFC2205 also mentions Interface
Discovery and interfaces being disabled.   Neighbor failures can be treated
as interfaces being disabled.  I guess the draft could use sightly more
parallel language.   

Alos, the draft does mentioned the use of an error message in section 4.
Under the conditions described in section 4, the "Routing Problem" error
code may be used.  

Lou