RFC 8390

RSVP-TE Path Diversity Using Exclude Route, July 2018

Canonical URL:
https://www.rfc-editor.org/rfc/rfc8390.txt
File formats:
Plain TextPDF
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

DOI:  10.17487/RFC8390

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

Other actions: Submit Errata  |  Find IPR Disclosures from the IETF


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 4844.


Download PDF Reader