Skip to main content

RSVP-TE Path Diversity Using Exclude Route
RFC 8390

Revision differences

Document history

Date By Action
2018-12-19
(System)
Received changes through RFC Editor sync (changed abstract to 'RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A …
Received changes through RFC Editor sync (changed abstract to '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.')
2018-07-18
(System)
Received changes through RFC Editor sync (created alias RFC 8390, changed title to 'RSVP-TE Path Diversity Using Exclude Route', changed abstract to 'RSVP-TE provides …
Received changes through RFC Editor sync (created alias RFC 8390, changed title to 'RSVP-TE Path Diversity Using Exclude Route', changed abstract to '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).', changed pages to 26, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-07-18, changed IESG state to RFC Published, created updates relation between draft-ietf-teas-lsp-diversity and RFC 4874)
2018-07-18
(System) RFC published