{"draft":"draft-ietf-teas-lsp-diversity-10","doc_id":"RFC8390","title":"RSVP-TE Path Diversity Using Exclude Route","authors":["Z. Ali, Ed.","G. Swallow, Ed.","F. Zhang, Ed.","D. Beller, Ed."],"format":["ASCII","HTML"],"page_count":"26","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Traffic Engineering Architecture and Signaling","abstract":"RSVP-TE provides support for the communication of exclusion\r\ninformation during Label Switched Path (LSP) setup.  A typical LSP\r\ndiversity use case is for protection, where two LSPs should follow\r\ndifferent paths through the network in order to avoid single points\r\nof failure, thus greatly improving service availability.  This\r\ndocument specifies an approach that can be used for network scenarios\r\nwhere the full path(s) is not necessarily known by use of an abstract\r\nidentifier for the path.  Three types of abstract identifiers are\r\nspecified: client based, Path Computation Element (PCE) based, and\r\nnetwork based.  This document specifies two new diversity subobjects\r\nfor the RSVP eXclude Route Object (XRO) and the Explicit Exclusion\r\nRoute Subobject (EXRS).\r\n\r\nFor the protection use case, LSPs are typically created at a slow\r\nrate and exist for a long time so that it is reasonable to assume\r\nthat a given (reference) path currently existing (with a well-known\r\nidentifier) will continue to exist and can be used as a reference\r\nwhen creating the new diverse path.  Re-routing of the existing\r\n(reference) LSP, before the new path is established, is not\r\nconsidered.","pub_date":"July 2018","keywords":["LSP diversity"],"obsoletes":[],"obsoleted_by":[],"updates":["RFC4874"],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC8390","errata_url":null}