Fast ReRoute (FRR) Extensions for BIER-TE
draft-eckert-bier-te-frr-00
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Authors | Toerless Eckert , Gregory Cauchie , Wolfgang Braun , Michael Menth | ||
| Last updated | 2017-01-09 (Latest revision 2016-07-08) | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| 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
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.
Authors
Toerless Eckert
Gregory Cauchie
Wolfgang Braun
Michael Menth
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)