draft-ietf-mpls-ri-rsvp-frr-06.txt   draft-ietf-mpls-ri-rsvp-frr-07.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: December 22, 2019 Google, Inc. Expires: March 6, 2020 Google, Inc.
D. Pacella D. Pacella
Verizon, Inc. Verizon, Inc.
June 20, 2019 September 3, 2019
Refresh-interval Independent FRR Facility Protection Refresh-interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-06 draft-ietf-mpls-ri-rsvp-frr-07
Abstract Abstract
RSVP-TE relies on periodic refresh of RSVP messages to synchronize RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two
and maintain the Label Switched Path (LSP) related states along the local repair techniques to reroute Label Switched Path (LSP) traffic
reserved path. In the absence of refresh messages, the LSP-related over pre-established backup tunnel. Facility backup method allows
states are automatically deleted. Reliance on periodic refreshes and one or more LSPs traversing a connected link or node to be protected
refresh timeouts are problematic from the scalability point of view. using a bypass tunnel. The many-to-one nature of local repair
The number of RSVP-TE LSPs that a router needs to maintain has been technique is attractive from scalability point of view. This
growing in service provider networks and the implementations should document enumerates facility backup procedures in RFC 4090 that rely
be capable of handling increase in LSP scale. on refresh timeout and hence make facility backup method refresh-
interval dependent. The RSVP-TE extensions defined in this document
RFC 2961 specifies mechanisms to eliminate the reliance on periodic will enhance the facility backup protection mechanism by making the
refresh and refresh timeout of RSVP messages, and enables a router to corresponding procedures refresh-interval independent and hence
increase the message refresh interval to values much longer than the compatible with Refresh-interval Independent RSVP (RI-RSVP) specified
default 30 seconds defined in RFC 2205. However, the protocol in RFC 8370. Hence, this document updates RFC 4090 in order to
extensions defined in RFC 4090 for supporting Fast ReRoute (FRR) support RI-RSVP capability specified in RFC 8370.
using bypass tunnels implicitly rely on short refresh timeouts to
cleanup stale states.
In order to eliminate the reliance on refresh timeouts, the routers
should unambiguously determine when a particular LSP state should be
deleted. Coupling LSP state with the corresponding RSVP-TE signaling
adjacencies as recommended in RFC 8370 will apply in scenarios other
than RFC 4090 FRR using bypass tunnels. In scenarios involving RFC
4090 FRR using bypass tunnels, additional explicit tear down messages
are necessary. Refresh-interval Independent RSVP FRR (RI-RSVP-FRR)
extensions specified in this document consists of procedures to
enable LSP state cleanup that are essential in scenarios not covered
by procedures defined in RSVP-TE Scaling Recommendations. Hence,
this document updates the procedures defined in RFC 4090 to support
Refresh-interval Independent RSVP (RI-RSVP) capability specified in
RFC 8370.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 26 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 December 22, 2019. This Internet-Draft will expire on March 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5
4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7 4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . 8 Capability . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Signaling Handshake between PLR and MP . . . . . . . . . 8 4.2. Signaling Handshake between PLR and MP . . . . . . . . . 8
4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9 4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10 4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10
4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10
4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 11 4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 11
4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12 4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12
skipping to change at page 3, line 42 skipping to change at page 3, line 24
6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 22 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
RSVP-TE Fast ReRoute [RFC4090] defines two local repair techniques to RSVP-TE relies on periodic refresh of RSVP messages to synchronize
reroute Label Switched Path (LSP) traffic over pre-established backup and maintain the Label Switched Path (LSP) related states along the
tunnel. Facility backup method allows one or more LSPs traversing a reserved path. In the absence of refresh messages, the LSP-related
connected link or node to be protected using a bypass tunnel. The states are automatically deleted. Reliance on periodic refreshes and
many-to-one nature of local repair technique is attractive from refresh timeouts are problematic from the scalability point of view.
scalability point of view. This document enumerates facility backup The number of RSVP-TE LSPs that a router needs to maintain has been
procedures in [RFC4090] that rely on refresh timeout and hence make growing in service provider networks and the implementations should
facility backup method refresh-interval dependent. The RSVP-TE be capable of handling increase in LSP scale.
extensions defined in this document will enhance the facility backup
protection mechanism by making the corresponding procedures refresh- RFC 2961 specifies mechanisms to eliminate the reliance on periodic
interval independent. refresh and refresh timeout of RSVP messages, and enables a router to
increase the message refresh interval to values much longer than the
default 30 seconds defined in RFC 2205. However, the protocol
extensions defined in RFC 4090 for supporting Fast ReRoute (FRR)
using bypass tunnels implicitly rely on short refresh timeouts to
cleanup stale states.
In order to eliminate the reliance on refresh timeouts, the routers
should unambiguously determine when a particular LSP state should be
deleted. In scenarios involving RFC 4090 FRR using bypass tunnels,
additional explicit tear down messages are necessary. Refresh-
interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in
this document consists of procedures to enable LSP state cleanup that
are essential in supporting RI-RSVP capability for RFC 4090 FRR using
bypass tunnels.
1.1. Motivation 1.1. Motivation
Base RSVP [RFC2205] maintains state via the generation of RSVP Path/ Base RSVP [RFC2205] maintains state via the generation of RSVP Path/
Resv refresh messages. Refresh messages are used to both synchronize Resv refresh messages. Refresh messages are used to both synchronize
state between RSVP neighbors and to recover from lost RSVP messages. state between RSVP neighbors and to recover from lost RSVP messages.
The use of Refresh messages to cover many possible failures has The use of Refresh messages to cover many possible failures has
resulted in a number of operational problems. resulted in a number of operational problems.
- One problem relates to RSVP control plane scaling due to periodic - One problem relates to RSVP control plane scaling due to periodic
skipping to change at page 4, line 35 skipping to change at page 4, line 33
standard RSVP. Procedures specified in [RFC2961] address the above standard RSVP. Procedures specified in [RFC2961] address the above
mentioned problems by eliminating dependency on refreshes for state mentioned problems by eliminating dependency on refreshes for state
synchronization and for recovering from lost RSVP messages, and by synchronization and for recovering from lost RSVP messages, and by
eliminating dependency on refresh timeout for stale state cleanup. eliminating dependency on refresh timeout for stale state cleanup.
Implementing these procedures allows implementations to improve RSVP- Implementing these procedures allows implementations to improve RSVP-
TE control plane scalability. For more details on eliminating TE control plane scalability. For more details on eliminating
dependency on refresh timeout for stale state cleanup, refer to dependency on refresh timeout for stale state cleanup, refer to
"Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling "Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling
Techniques [RFC8370]. Techniques [RFC8370].
However, the procedures specified in RSVP-TE Scaling Techniques However, the facility backup protection procedures specified in
[RFC8370] do not fully address stale state cleanup for facility [RFC4090] do not fully address stale state cleanup as the procedures
backup protection [RFC4090], as facility backup protection still depend on refresh timeouts for stale state cleanup. The updated
depends on refresh timeouts for stale state cleanup. facility backup protection procedures specified in this document, in
combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this
The procedures specified in this document, in combination with RSVP- dependency on refresh timeouts for stale state cleanup.
TE Scaling Techniques [RFC8370], eliminate facility backup protection
dependency on refresh timeouts for stale state cleanup. The document
hence updates the semantics of Refresh-interval Independent RSVP (RI-
RSVP) capability specified in Section 3 of RSVP-TE Scaling Techniques
[RFC8370].
The procedures specified in this document assume reliable delivery of The procedures specified in this document assume reliable delivery of
RSVP messages, as specified in [RFC2961]. Therefore this document RSVP messages, as specified in [RFC2961]. Therefore this document
makes support for [RFC2961] a pre-requisite. makes support for [RFC2961] a pre-requisite.
2. Terminology 2. Terminology
The reader is expected to be familiar with the terminology in The reader is expected to be familiar with the terminology in
[RFC2205], [RFC3209], [RFC4090] and [RFC4558]. [RFC2205], [RFC3209], [RFC4090] and [RFC4558].
skipping to change at page 5, line 14 skipping to change at page 5, line 4
2. Terminology 2. Terminology
The reader is expected to be familiar with the terminology in The reader is expected to be familiar with the terminology in
[RFC2205], [RFC3209], [RFC4090] and [RFC4558]. [RFC2205], [RFC3209], [RFC4090] and [RFC4558].
Phop node: Previous-hop router along the label switched path Phop node: Previous-hop router along the label switched path
PPhop node: Previous-Previous-hop router along the label switched PPhop node: Previous-Previous-hop router along the label switched
path path
Nhop node: Next-hop router along the label switched path Nhop node: Next-hop router along the label switched path
PPhop node: Next-Next-hop router along the label switched path NNhop node: Next-Next-hop router along the label switched path
PLR: Point of Local Repair router as defined in [RFC4090] PLR: Point of Local Repair router as defined in [RFC4090]
MP: Merge Point router as defined in [RFC4090] MP: Merge Point router as defined in [RFC4090]
LP-MP node: Merge Point router at the tail of Link-Protecting bypass LP-MP node: Merge Point router at the tail of Link-Protecting bypass
tunnel tunnel
NP-MP node: Merge Point router at the tail of Node-Protecting bypass NP-MP node: Merge Point router at the tail of Node-Protecting bypass
tunnel tunnel
skipping to change at page 20, line 48 skipping to change at page 20, line 48
- If B is not an MP and if Phop link of B fails, B cannot send - If B is not an MP and if Phop link of B fails, B cannot send
Conditional PathTear to C but MUST time out the PSB state from A Conditional PathTear to C but MUST time out the PSB state from A
normally. This would be accomplished if A would also reduce the normally. This would be accomplished if A would also reduce the
refresh time to default value. So if C does not support the RI- refresh time to default value. So if C does not support the RI-
RSVP-FRR extensions, then Phop B and the PPhop A SHOULD reduce the RSVP-FRR extensions, then Phop B and the PPhop A SHOULD reduce the
refresh period to the default short refresh interval. refresh period to the default short refresh interval.
4.6.2.2. Lack of support on Upstream Node 4.6.2.2. Lack of support on Upstream Node
The procedures on the upstream direction are as follows. The procedures are as follows.
- If Phop node does not support the RI-RSVP-FRR extensions, then the - If Phop node does not support the RI-RSVP-FRR extensions, then the
node SHOULD reduce the "refresh period" in the TIME_VALUES object node SHOULD reduce the "refresh period" in the TIME_VALUES object
carried in the Resv to the default short refresh interval. carried in the Resv to the default short refresh interval.
- If node protection is requested and the Phop node does not support - If node protection is requested and the Phop node does not support
the RI-RSVP-FRR extensions, then the node SHOULD reduce the the RI-RSVP-FRR extensions, then the node SHOULD reduce the
"refresh period" in the TIME_VALUES object carried in the Path to "refresh period" in the TIME_VALUES object carried in the Path to
the default short refresh interval. the default short refresh interval (thus, the Nhop can use
compatible values when sending a Resv).
- If node protection is requested and the PPhop node does not - If node protection is requested and the PPhop node does not
support the RI-RSVP-FRR extensions, then the node SHOULD reduce support the RI-RSVP-FRR extensions, then the node SHOULD reduce
the "refresh period" in the TIME_VALUES object carried in the Resv the "refresh period" in the TIME_VALUES object carried in the Resv
to the default short refresh interval. to the default short refresh interval.
- If the node reduces the refresh time from the above procedures, it - If the node reduces the refresh time from the above procedures, it
SHOULD also not execute MP procedures specified in Section 4.3 of SHOULD also not execute MP procedures specified in Section 4.3 of
this document. this document.
skipping to change at page 23, line 34 skipping to change at page 23, line 34
Cisco Systems, Inc. Cisco Systems, Inc.
Email: mtaillon@cisco.com Email: mtaillon@cisco.com
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-mpls-summary-frr-rsvpte] [I-D.ietf-mpls-summary-frr-rsvpte]
Taillon, M., Saad, T., Gandhi, R., Deshmukh, A., Jork, M., Taillon, M., Saad, T., Gandhi, R., Deshmukh, A., Jork, M.,
and V. Beeram, "RSVP-TE Summary Fast Reroute Extensions and V. Beeram, "RSVP-TE Summary Fast Reroute Extensions
for LSP Tunnels", draft-ietf-mpls-summary-frr-rsvpte-04 for LSP Tunnels", draft-ietf-mpls-summary-frr-rsvpte-05
(work in progress), May 2019. (work in progress), July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
 End of changes. 13 change blocks. 
63 lines changed or deleted 56 lines changed or added

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