%% You should probably cite draft-eckert-bier-te-frr-03 instead of this revision.
@techreport{eckert-bier-te-frr-01,
    number =    {draft-eckert-bier-te-frr-01},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-eckert-bier-te-frr/01/},
    author =    {Toerless Eckert and Gregory Cauchie and Wolfgang Braun and Michael Menth},
    title =     {{Fast ReRoute (FRR) Extensions for BIER-TE}},
    pagetotal = 10,
    year =      ,
    month =     ,
    day =       ,
    abstract =  {This document proposes an Fast ReRoute (FRR) extension to the BIER-TE Architecture {[}I-D.eckert-bier-te-arch{]}. The FRR procedure has to be supported by the BIER-TE Controller host and the BFRs that are attached to a link/adjacency for which FRR support is required. Thus, the FRR concept can be incrementally deployed in the data plane to only those BFR adjacent to adjacencies for which FRR protection is desired. The FRR procedure does not require changes to the packet format described in {[}I-D.ietf-bier-architecture{]} that is also used for BIER- TE. Existing BIER-TE tables do not have to be altered. FRR procedures do require additional forwarding plane logic on the BFR that need to support FRR. An additional table is needed that carries information about pre- computed backup paths. This table is used to modify upon detection of failure the bitstring in the BIER header. To prevent packet duplicates, tunneling mechanisms such as remote adjacencies or BIER- in-BIER encapsulation can be leveraged.},
}