Refresh-interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-10
Document | Type | Active Internet-Draft (mpls WG) | |
---|---|---|---|
Authors | Chandrasekar R , Tarek Saad , Ina Minei , Dante Pacella | ||
Last updated | 2021-03-10 (latest revision 2020-12-18) | ||
Replaces | draft-chandra-mpls-ri-rsvp-frr | ||
Stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Proposed Standard | ||
Formats | plain text pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | WG Document | |
Document shepherd | Nicolai Leymann | ||
Shepherd write-up | Show (last changed 2019-01-18) | ||
IESG | IESG state | AD is watching | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Martin Vigoureux | ||
Send notices to | Nicolai Leymann <n.leymann@telekom.de> | ||
IANA | IANA review state | Version Changed - Review Needed |
MPLS Working Group C. Ramachandran Internet-Draft T. Saad Updates: 4090 (if approved) Juniper Networks, Inc. Intended status: Standards Track I. Minei Expires: June 21, 2021 Google, Inc. D. Pacella Verizon, Inc. December 18, 2020 Refresh-interval Independent FRR Facility Protection draft-ietf-mpls-ri-rsvp-frr-10 Abstract RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnel. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout and hence make facility backup method refresh- interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Ramachandran, et al. Expires June 21, 2021 [Page 1] Internet-Draft RI-RSVP FRR Bypass December 2020 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 21, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5 4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP Capability . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Signaling Handshake between PLR and MP . . . . . . . . . 9 4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10 4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 11 4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12 4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12 4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 14 4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15 4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15 4.4.2. Processing Conditional PathTear . . . . . . . . . . . 15 4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16Show full document text