%% You should probably cite rfc8390 instead of this I-D. @techreport{ietf-teas-lsp-diversity-10, number = {draft-ietf-teas-lsp-diversity-10}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/10/}, author = {Zafar Ali and George Swallow and Fatai Zhang and Dieter Beller}, title = {{RSVP-TE Path Diversity Using Exclude Route}}, pagetotal = 26, year = 2018, month = mar, day = 2, abstract = {RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A typical LSP diversity use case is for protection, where two LSPs should follow different paths through the network in order to avoid single points of failure, thus greatly improving service availability. This document specifies an approach that can be used for network scenarios where the full path(s) is not necessarily known by use of an abstract identifier for the path. Three types of abstract identifiers are specified: client based, Path Computation Element (PCE) based, and network based. This document specifies two new diversity subobjects for the RSVP eXclude Route Object (XRO) and the Explicit Exclusion Route Subobject (EXRS). For the protection use case, LSPs are typically created at a slow rate and exist for a long time so that it is reasonable to assume that a given (reference) path currently existing (with a well-known identifier) will continue to exist and can be used as a reference when creating the new diverse path. Re-routing of the existing (reference) LSP, before the new path is established, is not considered.}, }