RFC 8355

Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks

📅 published March 2018, from ietf

RFC 8355: Resiliency Use Cases in SPRING Networks 🦋

okay bestie, this one is a whole vibe. It's an Informational RFC from March 2018 (ISSN 2070-1721), so it's a discussion doc, not a standard you have to implement. The authors are C. Filsfils (Ed.) and S. Previdi (Ed.) from Cisco Systems, Inc., B. Decraene from Orange, and R. Shakir from Google. The title block doesn't list anything it obsoletes or updates. 💅

The title is Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks 🌸

Abstract ✨

So the whole point is this: it lays out and describes the requirements for a bunch of use cases about Segment Routing resiliency on SPRING networks. Basically, what happens when stuff breaks and how the network keeps your traffic alive 🫶

Status of This Memo 📜

Not a Standards Track spec, just published for info 🎀

This one is still a product of the IETF, so it's the community's consensus and it went through public review, then got approved by the IESG. Not everything the IESG approves ends up being a candidate for any level of Internet Standard, though. See Section 2 of RFC 7841 for that. 🧚

If you want the current status, errata, or a place to leave feedback, go to https://www.rfc-editor.org/info/rfc8355 🍓

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. Any Code Components you pull out of here must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says. 🔥

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

1. Introduction ✨

This doc tours the different use cases for keeping services protected in a SPRING network. The terminology matches [RFC5286] and [RFC5714], so if you've read those you're already ahead 🧠

The resiliency use cases here aren't just for traffic that SPRING forwards. They also work for traffic that's forwarded some other way, like LDP signaling or plain IP-routed traffic 💖

There are three key alternatives: path protection, local protection without operator management, and local protection with operator management. 👑

Path protection means the ingress node is the one in charge of recovering from a failure, which is covered in Section 2 🫶

Everything after that focuses on approaches where the node right next to the failed component does the protecting. People usually call these local protection or fast-reroute techniques [RFC5286] [RFC5714] 🔥

Section 3 talks about two unmanaged local protection approaches, link/node bypass protection and shortest-path-based protection 🦋

Section 4 is the case where the operator gets to manage local protection behavior, so it can fit specific policies 💅

Section 5 looks at loop avoidance. The idea is that SPRING could offer mechanisms so temporary forwarding inconsistencies during routing convergence don't turn into traffic loss. Main character energy 🌸

The point of this doc is to show the different use cases and how an operator could mix them together on the same network (see Section 6). It doesn't define any solutions, though 🙈

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

                Figure 1: Reference Topology

We use Figure 1 as the reference topology all the way through. These link metrics apply:

  • Links from/to A and Z have a metric of 100.
  • The CH, GD, DI, and HE links have a metric of 6.
  • Every other link has a metric of 5.

Note: Link metrics are bidirectional, so the same metric value is set on 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 🛤️

Quick reminder: one of the big things network operators need is path disjointness. Operators have built networks where paths can be computed to be completely disjoint, meaning two paths don't share any component (link or router). That makes for a really optimal protection strategy 👑

The first strategy skips local repair entirely and uses end-to-end path protection, where each SPRING path gets protected by a second disjoint SPRING path. Local protection isn't used anywhere along the path in this case 🧚

Here's an example. A pseudowire (PW) from A to Z can be "path protected" in the direction A to Z like this: the operator sets up two SPRING paths from A to Z, T1 (primary) and T2 (backup) 🦋

There are three ways the two paths can be used:

  • concurrently, where the ingress router sends the same traffic over the primary and secondary path (this is usually known as 1+1 protection);
  • concurrently, where the ingress router splits the traffic over the primary and secondary path (this is usually known as Equal-Cost Multipath (ECMP) or Unequal-Cost Multipath (UCMP)); or
  • as a primary and backup path, where the secondary path is used only when the primary failed (this is usually known as 1:1 protection).

T1 goes over the path {AB, BC, CD, DE, EZ} as the primary, and T2 goes over the path {AF, FG, GH, HI, IZ} as the backup 🌈

The two paths MUST be disjoint in their links, nodes, and Shared Risk Link Groups (SRLGs) to satisfy the requirement of disjointness. 🔥

When T1 is up, the PW packets go over T1. When T1 fails, they switch to the backup path T2. When T1 comes back up, the operator either lets the traffic automatically revert onto T1 or picks an operator-driven reversion. Usually the switch from T1 to T2 happens in a fast-reroute fashion (e.g., sub-50 milliseconds), but other restoration times are fine depending on what service has to be delivered ⚡

It's essential that every path, primary or backup, gets end-to-end liveness monitoring/verification. The methods and mechanisms for that liveness check are outside the scope of this document. [RFC5880] is an example 💖

There are a bunch of ways to do a liveness check. For example, path liveness, where the path is monitored at the network level (either by the head-end node or by a network controller/monitoring system). Another option is a service-based path monitored by the service instance, which checks reachability of the endpoint. All of these are just examples. This document does express the requirement for a liveness mechanism, but it doesn't mandate or define any specific one 🫶

From the SPRING side, these are the requirements we want to highlight:

  • 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).
  • SPRING architecture MUST provide a way to instantiate pairs of disjoint paths on a topology based on a protection strategy (link, node, or SRLG protection) and allow the validation or recomputation of these paths upon network events.
  • The SPRING architecture MUST provide an end-to-end liveness check of SPRING-based paths. 💅

3. Management-Free Local Protection 🌷

This section covers two options that give you local protection without any operator management: bypass protection and shortest-path-based protection 🧚

Say traffic goes from A to Z over the shortest paths SPRING provides. It gets management-free local protection because each node along the path automatically precomputes and preinstalls a backup path for the destination Z. When a failure gets detected locally, the traffic is repaired over that backup path in sub-50 milliseconds. Once the primary path is back up, the operator either lets traffic automatically revert onto it or picks an operator-driven reversion 🦋

The backup path computation SHOULD support the following requirements: ✨

  • 100% link, node, and SRLG protection in any topology;
  • automated computation by the IGP; and
  • 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 Bypass Protection 🎀

okay so one way to do local repair is to enforce a failover along the shortest path around the failed component 💅

  • Link protection: the point of local repair creates a repair path that avoids the protected link and merges back onto the primary path at the next hop 🦋
  • Node protection: the repair path avoids the protected node and merges back onto the primary path at the next-next hop 🌈
  • SRLG protection: the repair path avoids members of the same group and merges back onto the primary path just after 💜

in our example, C protects destination Z against a failure of the CD link by pushing traffic over the bypass {CH, HD} 🧚 the end-to-end path between A and Z, once the CD failure is recovered, looks like this:

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

Figure 2: Bypass Protection around Link CD

when the primary path comes back up, the operator either allows an automated reversion of the traffic onto the primary path, or picks an operator-driven reversion 🔥

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

another strategy is management-free local protection that aims to provide a repair for the destination based on the shortest path to that destination 🍓

in our example, C protects Z (which the traffic initially reaches via CD) by enforcing the traffic over its shortest path to Z while considering the failure of the protected component. the resulting end-to-end path between A and Z, once CD is recovered, is shown in Figure 3:

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

Figure 3: Shortest Path Protection around Link CD

when the primary path comes back up, the operator either allows an automated reversion of the traffic onto the primary path, or picks an operator-driven reversion 💖

4. Managed Local Protection 🌸

sometimes a management-free repair just doesn't fit the operator's policy 🙈 for example, in our illustration, the operator may not want CD and CH protecting each other, because the bandwidth (BW) available on each link might not be enough to absorb the other link's traffic 😭

in this context, the protection mechanism MUST support explicit configuration of the backup path, either as high-level constraints (end at the next hop, end at the next-next hop, minimize this metric, avoid this SRLG, etc.) or as an explicit path. once the failure is detected locally, the traffic is repaired over the backup path in sub-50 milliseconds ⚡ when the primary path comes back up, the operator either allows an automated reversion of the traffic onto it, or picks an operator-driven reversion.

we'll talk through these aspects for both the bypass and shortest-path-based schemes 🫶

4.1. Managed Bypass Protection 🦋

let's use our reference example. for the demand from A to Z, the operator doesn't want the shortest failover path to the next hop, {CH, HD}. they want the path {CG, GH, HD} instead, as shown 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 at the point of local repair 🧠

4.2. Managed Shortest Path Protection 💅

with shortest path protection, the operator doesn't want the shortest failover via link CH. instead, traffic should reach H via {CG, GH}, because of constraints such as delay, BW, or SRLG 🌷

the resulting end-to-end path once the protection kicks in is shown 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 at the point of local repair 🫧

the computation of the repair path based on a specific constraint SHOULD be possible on a per-destination prefix basis 🎀

5. Loop Avoidance 🔁

routing protocols have what are called "transient routing inconsistencies" as part of how they behave 🌀 this happens because routing convergence takes place at each node at different times, and over different stretches of time.

these inconsistencies can cause routing loops that last as long as it takes the node hit by a network event to converge. these loops are called "micro-loops" 😵‍💫

usually, in normal routing protocol operation, micro-loops don't last long and only show up while the network is converging. but with fast-convergence and fast-reroute technologies on the rise, micro-loops can become a real problem in networks that need sub-50 millisecond convergence or reroute 💀 so the micro-loop problem needs to be addressed.

whether a network is affected by micro-loops during convergence depends on its topology 🗺️ micro-loops can be detected during topology computation (for example, Shortest Path First (SPF) computation), so techniques to avoid them can be applied. one example of such a technique is computing a micro-loop-free path to be used during network convergence ✨

the SPRING architecture SHOULD provide solutions that prevent micro-loops during convergence after a change in network state. traditionally, the lack of packet steering capability made efficient micro-loop solutions hard to apply 😤 a SPRING-enabled router can take advantage of the extra packet steering capabilities SPRING offers, steering packets so they don't enter such loops 🦋

6. Coexistence of Multiple Resilience Techniques in the Same Infrastructure 🌈

an operator may want to support several very different services on the same packet-switching infrastructure 💼 so the SPRING architecture SHOULD allow the different use cases listed in this document to coexist in the same network.

let's see this with an example 👀

  • Flow F1 is supported over path {C, CD, E}
  • Flow F2 is supported over path {C, CD, I}
  • Flow F3 is supported over path {C, CD, Z}
  • Flow F4 is supported over path {C, CD, Z}

it should be possible for the operator to configure the network so that F1 gets path protection, F2 gets management-free shortest path local protection, F3 gets managed protection over path {CG, GH, Z}, and F4 gets management-free bypass protection 🧚💖

7. Security Considerations 🔐

this document describes requirements for the SPRING architecture to provide resiliency in SPRING networks. as such, it does not introduce any new security considerations beyond those discussed in [RFC7855]. the security tea is already spilled over there, so go read it 🍵💀

8. IANA Considerations 📋

this document has no IANA actions. nothing to register, nothing to update, we're all good here ✅

9. Manageability Considerations 🛠️

this document provides use cases. solutions aimed at supporting these use cases should provide the mechanisms needed to allow for manageability as described in [RFC7855] 💅

manageability covers the computation, installation, and troubleshooting of the repair path 🔧 necessary mechanisms SHOULD also be provided so the operator can control when a repair path is computed, how it was computed, and whether it gets installed and used 👑

10. References 📚

10.1. Normative References

10.2. Informative References

Acknowledgements 💜

the authors would like to thank Stephane Litkowski and Alexander Vainshtein for their 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
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
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

that's a wrap, bestie!! 🌈✨💖 you made it through the whole RFC 🎉

📦 where this page comes from