Refresh Interval Independent FRR Facility Protection
draft-chandra-mpls-ri-rsvp-frr-04
Document | Type |
Replaced Internet-Draft
(mpls WG)
Expired & archived
|
|
---|---|---|---|
Authors | Chandrasekar R , Ina Minei , Dante Pacella , Tarek Saad | ||
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 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Candidate for WG Adoption | |
Document shepherd | (None) | ||
IESG | IESG state | Replaced by draft-ietf-mpls-ri-rsvp-frr | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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
Ina Minei
Dante Pacella
Tarek Saad
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)