Refresh Interval Independent FRR Facility Protection
draft-chandra-mpls-ri-rsvp-frr-04

Document Type Replaced Internet-Draft (mpls WG)
Last updated 2016-07-17 (latest revision 2016-05-07)
Replaces draft-chandra-mpls-enhanced-frr-bypass
Replaced by draft-ietf-mpls-ri-rsvp-frr
Stream IETF
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state Candidate for WG Adoption
Document shepherd No shepherd assigned
IESG IESG state Replaced by draft-ietf-mpls-ri-rsvp-frr
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-chandra-mpls-ri-rsvp-frr-04.txt

Abstract

RSVP-TE relies on periodic refresh of RSVP messages to synchronize and maintain the LSP related states along the reserved path. In the absence of refresh messages, the LSP related states are automatically deleted. Reliance on periodic refreshes and refresh timeouts are problematic from the scalability point of view. The number of RSVP-TE LSPs that a router needs to maintain has been growing in service provider networks and the implementations should be capable of handling increase in LSP scale. RFC 2961 specifies mechanisms to eliminate the reliance on periodic refresh and refresh timeout of RSVP messages, and enables a router to increase the message refresh interval to values much larger than the default 30 seconds defined in RFC 2205. However, the protocol extensions defined in RFC 4090 for supporting fast reroute (FRR) using bypass tunnels implicitly rely on short refresh timeouts to cleanup stale states. In order to eliminate the reliance on refresh timeouts, the routers should unambiguously determine when a particular LSP state should be deleted. Coupling LSP state with the corresponding RSVP-TE signaling adjacencies as recommended in RSVP-TE Scaling Recommendations (draft-ietf-teas-rsvp-te-scaling-rec) will apply in scenarios other than RFC 4090 FRR using bypass tunnels. In scenarios involving RFC 4090 FRR using bypass tunnels, additional explicit tear down messages are necessary. Refresh-interval Independent RSVP FRR (RI- RSVP-FRR) extensions specified in this document consists of procedures to enable LSP state cleanup that are essential in scenarios not covered by procedures defined in RSVP-TE Scaling Recommendations.

Authors

Chandrasekar R (csekar@juniper.net)
Ina Minei (inaminei@google.com)
Dante Pacella (dante.j.pacella@verizon.com)
Tarek Saad (tsaad@cisco.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)