<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.eckert-bier-te-frr" target="https://datatracker.ietf.org/doc/html/draft-eckert-bier-te-frr-03">
   <front>
      <title>Protection Methods for BIER-TE</title>
      <author initials="T. T." surname="Eckert" fullname="Toerless Eckert">
         <organization>Huawei USA - Futurewei Technologies Inc.</organization>
      </author>
      <author initials="G." surname="Cauchie" fullname="Gregory Cauchie">
         <organization>Bouygues Telecom</organization>
      </author>
      <author initials="W." surname="Braun" fullname="Wolfgang Braun">
         <organization>University of Tuebingen</organization>
      </author>
      <author initials="M." surname="Menth" fullname="Michael Menth">
         <organization>University of Tuebingen</organization>
      </author>
      <date month="March" day="5" year="2018" />
      <abstract>
	 <t>   This document proposes protection methods for the BIER-TE
   architecture [I-D.ietf-bier-te-arch].  These include 1+1 (live-live)
   path/tree [RFC7431] redundancy, 1:1 path/tree protection, as well as
   fast reroute (FRR) methods.  The latter may protect against link and/
   or node failures and leverage infrastructure tunnels, BIER-in-BIER
   encapsulation, or header modification for implementation.

   In particular, this memo describes FRR for BIER-TE in detail.  FRR
   for BIER-TE requires support from the BIER-TE controller and the BFRs
   that are attached to a link/adjacency for which FRR protection is
   desired.  FRR relies on the BIER header described in [RFC8279] which
   is also used by BIER-TE.  It does not require extensions or
   modifications to existing BIER-TE tables.  However, the presented FRR
   procedures need some additional forwarding plane logic on the BFR.
   An additional table is needed that carries information about pre-
   computed backup paths.  When a failure is detected, the information
   from this table is used to modify the bitstring in the BIER header
   before forwarding a packet over a backup path.  To prevent undesired
   packet duplication, packets should be tunneled on the backup paths.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-eckert-bier-te-frr-03" />
   
</reference>
