RFC 8390: RSVP-TE Path Diversity Using Exclude Route
In plain English — editorial summary, not part of the RFC
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.
Document record
- Document ID
- RFC8390
- Published
- July 2018
- Authors
- Z. Ali; G. Swallow; F. Zhang; D. Beller
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- rtg
- Pages
- 26
- Also known as
- —
- Updates:
- RFC 4874
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 8388Usage and Applicability of BGP MPLS-Based Ethernet VPNCurrent
May 2018
- RFC 8393Operating the Network Service Header (NSH) with Next Protocol "None"Current
May 2018
- RFC 8394Split Network Virtualization Edge (Split-NVE) Control-Plane RequirementsCurrent
May 2018
- RFC 8385Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLSCurrent
June 2018
- RFC 8395Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport LabelsCurrent
June 2018
- RFC 8384Transparent Interconnection of Lots of Links (TRILL) Smart EndnodesCurrent
July 2018
- RFC 8383Transparent Interconnection of Lots of Links (TRILL): Address Flush MessageCurrent
May 2018
- RFC 8397Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique NicknamesCurrent
May 2018
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?