Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks
RFC 8355
Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 8355 S. Previdi, Ed.
Category: Informational Cisco Systems, Inc.
ISSN: 2070-1721 B. Decraene
Orange
R. Shakir
Google
March 2018
Resiliency Use Cases
in Source Packet Routing in Networking (SPRING) Networks
Abstract
This document identifies and describes the requirements for a set of
use cases related to Segment Routing network resiliency on Source
Packet Routing in Networking (SPRING) networks.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8355.
Filsfils, et al. Informational [Page 1]
RFC 8355 SPRING Resiliency Use Cases March 2018
Copyright Notice
Copyright (c) 2018 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. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Path Protection . . . . . . . . . . . . . . . . . . . . . . . 4
3. Management-Free Local Protection . . . . . . . . . . . . . . 6
3.1. Management-Free Bypass Protection . . . . . . . . . . . . 7
3.2. Management-Free Shortest-Path-Based Protection . . . . . 8
4. Managed Local Protection . . . . . . . . . . . . . . . . . . 8
4.1. Managed Bypass Protection . . . . . . . . . . . . . . . . 9
4.2. Managed Shortest Path Protection . . . . . . . . . . . . 9
5. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . . 10
6. Coexistence of Multiple Resilience Techniques in the Same
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Manageability Considerations . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Filsfils, et al. Informational [Page 2]
RFC 8355 SPRING Resiliency Use Cases March 2018
1. Introduction
This document reviews various use cases for the protection of
services in a SPRING network. The terminology used hereafter is in
line with [RFC5286] and [RFC5714].
The resiliency use cases described in this document can be applied
not only to traffic that is forwarded according to the SPRING
architecture, but also to traffic that originally is forwarded using
other paradigms such as LDP signaling or pure IP traffic (IP-routed
traffic).
Three key alternatives are described: path protection, local
protection without operator management, and local protection with
operator management.
Path protection lets the ingress node be in charge of the failure
recovery, as discussed in Section 2.
The rest of the document focuses on approaches where protection is
performed by the node adjacent to the failed component, commonly
Show full document text