--- 1/draft-ietf-mpls-ri-rsvp-frr-09.txt 2020-12-18 07:13:21.658658968 -0800 +++ 2/draft-ietf-mpls-ri-rsvp-frr-10.txt 2020-12-18 07:13:21.810662842 -0800 @@ -1,22 +1,22 @@ MPLS Working Group C. Ramachandran Internet-Draft T. Saad Updates: 4090 (if approved) Juniper Networks, Inc. Intended status: Standards Track I. Minei -Expires: May 26, 2021 Google, Inc. +Expires: June 21, 2021 Google, Inc. D. Pacella Verizon, Inc. - November 22, 2020 + December 18, 2020 Refresh-interval Independent FRR Facility Protection - draft-ietf-mpls-ri-rsvp-frr-09 + 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 @@ -42,21 +42,21 @@ 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 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 May 26, 2021. + 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 @@ -350,33 +350,30 @@ LSP state. See section 4.5 for more details. - Introduce extensions to enable the above procedures to be backward compatible with routers along the LSP path running implementation that do not support these procedures. See section 4.6 for more details. 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP Capability - A node supporting facility backup protection [RFC4090] MAY set the + A node supporting facility backup protection [RFC4090] MUST set the RI-RSVP capability (I bit) defined in Section 3.1 of RSVP-TE Scaling Techniques [RFC8370] only if it supports all the extensions specified - in the rest of this document. A node supporting facility backup - protection [RFC4090] but not supporting the extensions specified in - this document MUST NOT set the RI-RSVP capability (I bit) in the - outgoing Node-ID based Hello messages. Hence, this document updates - RFC 4090 by defining extensions and additional procedures over - facility backup protection [RFC4090] in order to advertise RI-RSVP - capability [RFC8370]. However, if a node supporting facility backup - protection [RFC4090] does set the RI-RSVP capability (I bit) but does - not support all the extensions specified in the rest of this - document, then it leaves room for stale state to linger around for an + in the rest of this document. Hence, this document updates RFC 4090 + by defining extensions and additional procedures over facility backup + protection [RFC4090] in order to advertise RI-RSVP capability + [RFC8370]. However, if a node supporting facility backup protection + [RFC4090] does set the RI-RSVP capability (I bit) but does not + support all the extensions specified in the rest of this document, + then it leaves room for stale state to linger around for an inordinate period of time given the long refresh intervals recommended by RFC 8370 or disruption of normal FRR operation. Procedures for backward compatibility Section 4.6.2.3 delves on this in detail. 4.2. Signaling Handshake between PLR and MP 4.2.1. PLR Behavior As per the facility backup procedures [RFC4090], when an LSP becomes @@ -975,22 +972,23 @@ - If the node reduces the refresh time using the above procedures, it MUST NOT execute MP procedures specified in Section 4.3 of this document. 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR If a node supporting facility backup protection [RFC4090] sets the RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR extensions, then it leaves room for stale state to linger around for - an inordinate period of time or disruption of normal FRR operation. - Consider the example topology Figure 1 provided in this document. + an inordinate period of time or disruption of normal FRR operation + (Section 3). Consider the example topology Figure 1 provided in this + document. - Assume node B does set RI-RSVP capability in its Node-ID based Hello messages even though it does not support RI-RSVP-FRR extensions. When B detects the failure of its Phop link along an LSP, it will not send Conditional PathTear to C as required by the RI-RSVP-FRR procedures. If B simply leaves the LSP state without deleting, then B may end up holding on to the stale state until the (long) refresh timeout. - Intead of node B, assume node C does set RI-RSVP capability in its