%% You should probably cite draft-ietf-mpls-ri-rsvp-frr instead of this I-D.
@techreport{chandra-mpls-ri-rsvp-frr-03,
    number =    {draft-chandra-mpls-ri-rsvp-frr-03},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-chandra-mpls-ri-rsvp-frr/03/},
    author =    {Chandrasekar R and Ina Minei and Dante Pacella and Tarek Saad},
    title =     {{Refresh Interval Independent FRR Facility Protection}},
    pagetotal = 24,
    year =      2016,
    month =     apr,
    day =       17,
    abstract =  {RSVP-TE relies on periodic refresh of RSVP messages to 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 refresh timeouts to cleanup stale states. This document defines extensions to bypass FRR related procedures defined in RFC 4090 to support refresh-interval independent FRR.},
}