RFC 8390 on RSVP-TE Path Diversity Using Exclude Route

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A new Request for Comments is now available in online RFC libraries.

        
        RFC 8390

        Title:      RSVP-TE Path Diversity Using Exclude Route 
        Author:     Z. Ali, Ed.,
                    G. Swallow, Ed.,
                    F. Zhang, Ed.,
                    D. Beller, Ed.
        Status:     Standards Track
        Stream:     IETF
        Date:       July 2018
        Mailbox:    zali@cisco.com, 
                    swallow@cisco.com, 
                    zhangfatai@huawei.com,
                    dieter.beller@nokia.com
        Pages:      26
        Characters: 59106
        Updates:    RFC 4874

        I-D Tag:    draft-ietf-teas-lsp-diversity-10.txt

        URL:        https://www.rfc-editor.org/info/rfc8390

        DOI:        10.17487/RFC8390

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.

This document is a product of the Traffic Engineering Architecture and Signaling Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC




[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux