File formats:

Status:

PROPOSED STANDARD

Updates:

RFC 4874

Authors:

Z. Ali, Ed.
G. Swallow, Ed.
F. Zhang, Ed.
D. Beller, Ed.

Stream:

IETF

Source:

teas (rtg)

Cite this RFC: TXT  |  XML  |   BibTeX

DOI:  https://doi.org/10.17487/RFC8390

Discuss this RFC: Send questions or comments to the mailing list teas@ietf.org

Other actions: Submit Errata  |  Find IPR Disclosures from the IETF  |  View History of RFC 8390

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.

For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 8729.