wdiff rfc8355.original rfc8355.txt

Network Working Group
Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Internet-Draft
Request for Comments: 8355 S. Previdi, Ed.
Intended status:
Category: Informational Cisco Systems, Inc.
Expires: June 22, 2018
ISSN: 2070-1721 B. Decraene
Orange
R. Shakir
Google
December 19, 2017
March 2018

Resiliency use cases Use Cases in SPRING networks
draft-ietf-spring-resiliency-use-cases-12 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 Segment Source
Packet Routing in Networking (SPRING) networks.

Requirements Language

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in
this document are used to define requirements for protocol and
architecture design.

Status of This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents valid
approved by the IESG are candidates for a maximum any level of Internet
Standard; see Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 June 22, 2018.
https://www.rfc-editor.org/info/rfc8355.

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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Path Protection . . . . . . . . . . . . . . . . . . . . . . . 4
3. Management-free Management-Free Local Protection . . . . . . . . . . . . . . 5
3.1. Management-free Management-Free Bypass Protection . . . . . . . . . . . . 6
3.2. Management-free Shortest Path Based Management-Free Shortest-Path-Based Protection . . . . . 6
4. Managed Local Protection . . . . . . . . . . . . . . . . . . 7
4.1. Managed Bypass Protection . . . . . . . . . . . . . . . . 7
4.2. Managed Shortest Path Protection . . . . . . . . . . . . 8
5. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . . 8
6. Co-existence Coexistence of multiple resilience techniques Multiple Resilience Techniques in the same
infrastructure Same
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Manageability Considerations . . . . . . . . . . . . . . . . 10
10. Contributors References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . 10
12. References . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . 11
Contributors . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11

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
architecture, but also to traffic that originally is forwarded using
other paradigms such as LDP signalling signaling or pure IP traffic (IP routed (IP-routed
traffic).

Three key alternatives are described: path protection, local
protection without operator management 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
referred to as local protection techniques or Fast Reroute fast-reroute techniques
([RFC5286], [RFC5714]).
[RFC5286] [RFC5714].

In Section 3 3, we discuss two different approaches providing unmanaged
local protection, namely link/node bypass protection and shortest
path based shortest-
path-based protection.

Section 4 illustrates a case allowing the operator to manage the
local protection behavior in order to accommodate specific policies.

In Section 5 5, we discuss the opportunity for the SPRING architecture
to provide loop-avoidance mechanisms, mechanisms such that transient forwarding
state inconsistencies during routing convergence do not lead into
traffic loss.

The purpose of this document is to illustrate the different use cases
and explain how an operator could combine them in the same network
(see Section 6). Solutions are not defined in this document.

B------C------D------E
/| | \ / | \ / |\
/ | | \/ | \/ | \
A | | /\ | /\ | Z
\ | | / \ | / \ | /
\| |/ \|/ \|/
F------G------H------I

Figure 1: Reference topology Topology

We use Figure 1 as a reference topology throughout the document.
Following The
following link metrics are applied:

Link metrics are bidirectional. In other words, the same metric
value is configured at both side of each link.

o Links from/to A and Z are configured with a metric of 100.

o CH, GD, DI DI, and HE links are configured with a metric of 6.

o All other links are configured with a metric of 5.

Note: Link metrics are bidirectional; in other words, the same metric
value is configured at both sides of each link.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2. Path Protection

As a reminder, one of the major network operator requirements is path
disjointness capability. Network operators have deployed
infrastructures with topologies that allow paths to be computed in a
complete disjoint fashion where two paths wouldn't share any
component (link or router) router), hence allowing an optimal protection
strategy.

A first protection strategy consists of excluding any local repair
but
and instead uses end-to-end path protection where each SPRING path is
protected by a second disjoint SPRING path. In this case, the local
protection is not used along the path.

For example, a Pseudo Wire pseudowire (PW) from A to Z can be "path protected" in
the direction A to Z in the following manner: the operator configures
two SPRING paths paths, T1 (primary) and T2 (backup) (backup), from A to Z.

The two paths may be used:

o concurrently, where the ingress router sends the same traffic over
the primary and secondary path. This path (this is usually known as 1+1
protection.
protection);

o concurrently, where the ingress router splits the traffic over the
primary and secondary path. This path (this is usually known as equal cost
multi path Equal-Cost
Multipath (ECMP) or unequal cost multi path (UCMP). Unequal-Cost Multipath (UCMP)); or

o as a primary and backup path, where the secondary path is used
only when the primary failed. This failed (this is usually known as 1:1
protection.
protection).

T1 is established over path {AB, BC, CD, DE, EZ} as the primary path path,
and T2 is established over path {AF, FG, GH, HI, IZ} as the backup
path. The two paths MUST be disjoint in their links, nodes nodes, and
shared risk link groups
Shared Risk Link Groups (SRLGs) to satisfy the requirement of
disjointness.

In the case of primary/backup paths, when the primary path T1 is up,
the packets of the PW are sent on T1. When T1 fails, the packets of
the PW are sent on the backup path T2. When T1 comes back up, the
operator either allows for an automated reversion of the traffic onto
T1 or selects an operator-driven reversion. Typically, the
switchover from path T1 to path T2 is done in a fast reroute fast-reroute fashion
(e.g.:
(e.g., sub-50 milliseconds range) but milliseconds) but, depending on the service that needs
to be delivered, other restoration times may be used.

It is essential that any path, primary or backup, benefit from an
end-to-end liveness monitoring/verification. The method and
mechanisms that provide such a liveness check are outside the scope
of this document. An example is given by [RFC5880].

There are multiple options for a liveness check, e.g., path liveness liveness,
where the path is monitored at the network level (either by the head-
end node or by a network controller/monitoring system). Another
possible approach consists of a service-based path monitored by the
service instance (verifying reachability of the endpoint). All these
options are given here as examples. While this document does express
the requirement for a liveness mechanism, it does not mandate, nor
define, any specific one.

From a SPRING viewpoint, we would like to highlight the following
requirements:

o SPRING architecture MUST provide a way to compute paths that are
not protected by local repair techniques (as illustrated in the
example of paths T1 and T2).

o SPRING architecture MUST provide a way to instantiate pairs of
disjoint paths on a topology based on a protection strategy (link,
node
node, or SRLG protection) and allow the validation or re-
computation
recomputation of these paths upon network events.

o The SPRING architecture MUST provide an end-to-end liveness check
of
SPRING based SPRING-based paths.

3. Management-free Management-Free Local Protection

This section describes two alternatives providing that provide local protection
without requiring operator management, namely bypass protection and
shortest-path based
shortest-path-based protection.

For example, a traffic from A to Z, transported over the shortest paths
provided by the SPRING architecture, benefits from management-
free management-free
local protection by having each node along the path automatically pre-compute
precompute and pre-install preinstall a backup path for the destination Z. Upon
local detection of the failure, the traffic is repaired over the
backup path in sub-50 milliseconds. When the primary path comes back
up, the operator either allows for an automated reversion of the
traffic onto it or selects an operator-
driven operator-driven reversion.

The backup path computation SHOULD support the following
requirements:

o 100% link, node, and SRLG protection in any topology. topology;
o Automated automated computation by the IGP. IGP; and

o Selection selection of the backup path such as to minimize the chance for
transient congestion and/or delay during the protection period, as
reflected by the IGP metric configuration in the network.

3.1. Management-free Management-Free Bypass Protection

One way to provide local repair is to enforce a fail-over failover along the
shortest path around the failed component.

In case of link protection, the point of local repair will create a
repair path avoiding the protected link and merging back to the
primary path at the nexthop. next hop.

In case of node protection, the repair path will avoid the protected
node and merge back to the primary path at the next-nexthop. next-next hop.

In case of SRLG protection, the repair path will avoid members of the
same group and merge back to the primary path just after.

In our example, C protects destination Z against a failure of the CD
link by enforcing the traffic over the bypass {CH, HD}. The resulting end-
to-end
end-to-end path between A and Z, upon recovery against from the failure of
CD, is depicted in Figure 2.

B * * *C------D * * *E
*| | * / * \ / |*
* | | */ * \/ | *
A | | /* * /\ | Z
\ | | / * * / \ | /
\| |/ **/ \|/
F------G------H------I

Figure 2: Bypass protection Protection around link Link CD

When the primary path comes back up, the operator either allows for
an automated reversion of the traffic onto the primary path or
selects an operator-driven reversion.

3.2. Management-free Shortest Path Based Management-Free Shortest-Path-Based Protection

An alternative protection strategy consists in management-free local
protection, aiming
protection that is aimed at providing a repair for the destination
based on the shortest path to the destination.

In our example, C protects Z, that it Z (which the traffic initially reaches via CD,
CD) by enforcing the traffic over its shortest path to Z, Z and
considering the failure of the protected component. The resulting
end-to-end path between A and Z, upon recovery against from the failure of
CD, is depicted in Figure 3.

B * * *C------D------E
*| | * / | \ / |\
* | | */ | \/ | \
A | | /* | /\ | Z
\ | | / * | / \ | *
\| |/ *|/ \|*
F------G------H * * *I

Figure 3: Shortest path protection Path Protection around link Link CD

When the primary path comes back up, the operator either allows for
an automated reversion of the traffic onto the primary path or
selects an operator-driven reversion.

4. Managed Local Protection

There may be cases where a management free management-free repair does not fit the
policy of the operator. For example, in our illustration, the
operator may not want to have CD and CH used to protect each other
due to the BW bandwidth (BW) availability in each link and that could not
suffice to absorb the other link traffic.

In this context, the protection mechanism MUST support the explicit
configuration of the backup path either under the form of high-level
constraints (end at the next-hop, next hop, end at the next-next-hop, next-next hop, minimize
this metric, avoid this SRLG...) SRLG, etc.) or under the form of an explicit
path. Upon local detection of the failure, the traffic is repaired
over the backup path in sub-50 milliseconds. When the primary path
comes back up, the operator either allows for an automated reversion
of the traffic onto it or selects an operator-driven reversion.

We discuss such aspects for both bypass and shortest path based shortest-path-based
protection schemes.

4.1. Managed Bypass Protection

Let us illustrate the case using our reference example. For the
demand from A to Z, the operator does not want to use the shortest
failover path to the nexthop, next hop, {CH, HD}, but rather the path {CG, GH,
HD}, as illustrated in Figure 4.

B * * *C------D * * *E
*| * \ / * \ / |*
* | * \/ * \/ | *
A | * /\ * /\ | Z
\ | * / \ * / \ | /
\| */ \*/ \|/
F------G * * *H------I

Figure 4: Managed Bypass Protection

The computation of the repair path SHOULD be possible in an automated
fashion as well as statically expressed in the point of local repair.

4.2. Managed Shortest Path Protection

In the case of shortest path protection, the operator does not want
to use the shortest failover via link CH, but rather the traffic
should reach H via {CG,
GH}, for example, GH} due to constraints such as delay, BW, SRLG or other constraint.
SRLG.

The resulting end-to-end path upon activation of the protection is
illustrated in Figure 5.

B * * *C------D------E
*| * \ / | \ / |\
* | * \/ | \/ | \
A | * /\ | /\ | Z
\ | * / \ | / \ | *
\| */ \|/ \|*
F------G * * *H * * *I

Figure 5: Managed Shortest Path Protection

The computation of the repair path SHOULD be possible in an automated
fashion as well as statically expressed in the point of local repair.

The computation of the repair path based on a specific constraint
SHOULD be possible on a per-destination prefix base.

5. Loop Avoidance

It is part of routing protocols protocols' behavior to have what are called
"transient routing inconsistencies". This is due to the routing
convergence that happens in each node at different times and during a
different lapse of time.

These inconsistencies may cause routing loops that last the time that
it takes for the node impacted by a network event to converge. These
loops are called "microloops". "micro-loops".

Usually, in a normal routing protocol operations, microloops micro-loops do not
last long and in general they are only noticed during the time it takes the network
to converge. However, with the emerging emergence of fast-
convergence fast-convergence and
fast-reroute technologies, microloops micro-loops can be an issue in networks
where sub-50 millisecond convergence/reroute is required. Therefore,
the microloop micro-loop problem needs to be addressed.

Networks may be affected by microloops micro-loops during convergence depending
of their topologies. Detecting microloops micro-loops can be done during
topology computation (e.g., SPF computation) Shortest Path First (SPF) computation),
and therefore
microloops-avoidance techniques to avoid micro-loops may be applied. An
example of such technique is to compute microloop-free a path free of micro-loops
that would be used during network convergence.

The SPRING architecture SHOULD provide solutions to prevent the
occurrence of microloops micro-loops during convergence following a change in
the network state. Traditionally, the lack of packet steering
capability made it difficult to apply efficient solutions to microloops. micro-
loops. A
SPRING enabled SPRING-enabled router could take advantage of the increased
packet steering capabilities offered by SPRING in order to steer
packets in a way that packets do not enter such loops.

6. Co-existence Coexistence of multiple resilience techniques Multiple Resilience Techniques in the same
infrastructure Same
Infrastructure

The operator may want to support several very different services on
the same packet-switching infrastructure. As a result, the SPRING
architecture SHOULD allow for the co-existence coexistence of the different use
cases listed in this document, in the same network.

Let us illustrate this with the following example:

o Flow F1 is supported over path {C, CD, E}

o Flow F2 is supported over path {C, CD, I}

o Flow F3 is supported over path {C, CD, Z}

o Flow F4 is supported over path {C, CD, Z}

It should be possible for the operator to configure the network to
achieve path protection for F1, management free management-free shortest path local
protection for F2, managed protection over path {CG, GH, Z} for F3,
and management free management-free bypass protection for F4.

7. Security Considerations

This document describes requirements for the SPRING architecture to
provide resiliency in SPRING networks. As such such, it does not
introduce any new security considerations beyond that is those discussed in
[RFC7855].

8. IANA Considerations

This document does not request any has no IANA allocations. actions.

9. Manageability Considerations

This document provides use cases. Solutions aimed at supporting
these use cases should provide the necessary mechanisms in order to
allow for manageability as described in [RFC7855].

Manageability concerns the computation, installation installation, and
troubleshooting of the repair path. Also, necessary mechanisms
SHOULD be provided in order for the operator to control when a repair
path is computed, how it has been computed computed, and if it's installed and
used.

10. Contributors

Pierre Francois contributed to the writing of the first version of
this document.

11. Acknowledgements

Authors would like to thank Stephane Litkowski and Alexander
Vainshtein for the comments and review of this document.

12. References

12.1.

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>.

12.2.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References

[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>.

[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>.

[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.

Acknowledgements

The authors would like to thank Stephane Litkowski and Alexander
Vainshtein for the comments and review of this document.

Contributors

Pierre Francois contributed to the writing of the first draft version
of this document.

Authors' Addresses

Clarence Filsfils (editor)
Cisco Systems, Inc.
Brussels
BE
Belgium

Email: cfilsfil@cisco.com

Stefano Previdi (editor)
Cisco Systems, Inc.
Via Del Serafico, 200
Rome 00142
Italy

Email: stefano@previdi.net

Bruno Decraene
Orange
FR
France

Email: bruno.decraene@orange.com
Rob Shakir
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America

Email: robjs@google.com