draft-ietf-mpls-ri-rsvp-frr-09.txt   draft-ietf-mpls-ri-rsvp-frr-10.txt 
MPLS Working Group C. Ramachandran MPLS Working Group C. Ramachandran
Internet-Draft T. Saad Internet-Draft T. Saad
Updates: 4090 (if approved) Juniper Networks, Inc. Updates: 4090 (if approved) Juniper Networks, Inc.
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: May 26, 2021 Google, Inc. Expires: June 21, 2021 Google, Inc.
D. Pacella D. Pacella
Verizon, Inc. Verizon, Inc.
November 22, 2020 December 18, 2020
Refresh-interval Independent FRR Facility Protection Refresh-interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-09 draft-ietf-mpls-ri-rsvp-frr-10
Abstract Abstract
RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two
local repair techniques to reroute Label Switched Path (LSP) traffic local repair techniques to reroute Label Switched Path (LSP) traffic
over pre-established backup tunnel. Facility backup method allows over pre-established backup tunnel. Facility backup method allows
one or more LSPs traversing a connected link or node to be protected 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 using a bypass tunnel. The many-to-one nature of local repair
technique is attractive from scalability point of view. This technique is attractive from scalability point of view. This
document enumerates facility backup procedures in RFC 4090 that rely document enumerates facility backup procedures in RFC 4090 that rely
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 34 skipping to change at page 8, line 34
LSP state. See section 4.5 for more details. LSP state. See section 4.5 for more details.
- Introduce extensions to enable the above procedures to be backward - Introduce extensions to enable the above procedures to be backward
compatible with routers along the LSP path running implementation compatible with routers along the LSP path running implementation
that do not support these procedures. See section 4.6 for more that do not support these procedures. See section 4.6 for more
details. details.
4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP
Capability 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 RI-RSVP capability (I bit) defined in Section 3.1 of RSVP-TE Scaling
Techniques [RFC8370] only if it supports all the extensions specified Techniques [RFC8370] only if it supports all the extensions specified
in the rest of this document. A node supporting facility backup in the rest of this document. Hence, this document updates RFC 4090
protection [RFC4090] but not supporting the extensions specified in by defining extensions and additional procedures over facility backup
this document MUST NOT set the RI-RSVP capability (I bit) in the protection [RFC4090] in order to advertise RI-RSVP capability
outgoing Node-ID based Hello messages. Hence, this document updates [RFC8370]. However, if a node supporting facility backup protection
RFC 4090 by defining extensions and additional procedures over [RFC4090] does set the RI-RSVP capability (I bit) but does not
facility backup protection [RFC4090] in order to advertise RI-RSVP support all the extensions specified in the rest of this document,
capability [RFC8370]. However, if a node supporting facility backup then it leaves room for stale state to linger around for an
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 inordinate period of time given the long refresh intervals
recommended by RFC 8370 or disruption of normal FRR operation. recommended by RFC 8370 or disruption of normal FRR operation.
Procedures for backward compatibility Section 4.6.2.3 delves on this Procedures for backward compatibility Section 4.6.2.3 delves on this
in detail. in detail.
4.2. Signaling Handshake between PLR and MP 4.2. Signaling Handshake between PLR and MP
4.2.1. PLR Behavior 4.2.1. PLR Behavior
As per the facility backup procedures [RFC4090], when an LSP becomes As per the facility backup procedures [RFC4090], when an LSP becomes
skipping to change at page 21, line 44 skipping to change at page 21, line 44
- If the node reduces the refresh time using the above procedures, - If the node reduces the refresh time using the above procedures,
it MUST NOT execute MP procedures specified in Section 4.3 of this it MUST NOT execute MP procedures specified in Section 4.3 of this
document. document.
4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR
If a node supporting facility backup protection [RFC4090] sets the If a node supporting facility backup protection [RFC4090] sets the
RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR 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 extensions, then it leaves room for stale state to linger around for
an inordinate period of time or disruption of normal FRR operation. an inordinate period of time or disruption of normal FRR operation
Consider the example topology Figure 1 provided in this document. (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 - Assume node B does set RI-RSVP capability in its Node-ID based
Hello messages even though it does not support RI-RSVP-FRR Hello messages even though it does not support RI-RSVP-FRR
extensions. When B detects the failure of its Phop link along an 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 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 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 deleting, then B may end up holding on to the stale state until
the (long) refresh timeout. the (long) refresh timeout.
- Intead of node B, assume node C does set RI-RSVP capability in its - Intead of node B, assume node C does set RI-RSVP capability in its
 End of changes. 7 change blocks. 
17 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/