[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Routing Area Working Group                                     S. Bryant
Internet-Draft                                               U. Chunduri
Intended status: Informational                                 T. Eckert
Expires: January 3, 2020                      Futurewei Technologies Inc
                                                           July 02, 2019


               Preferred Path Loop-Free Alternate (pLFA)
                       draft-bryant-rtgwg-plfa-00

Abstract

   Fast re-route (FRR) is a technique that allows productive forwarding
   to continue in a network after a failure has occurred, but before the
   network has has time to re-converge.  This is achieved by forwarding
   a packet on an alternate path that will not result in the packet
   looping.  Preferred Path Routing (PPR) provides a method of injecting
   explicit paths into the routing protocol.  The use of PPR to support
   FRR has a number of advantages.  This document describes the
   advantages of using PPR to provide a loop-free alternate FRR path,
   and provides a framework for its use in this application.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents 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 January 3, 2020.

Copyright Notice

   Copyright (c) 2019 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Bryant, et al.           Expires January 3, 2020                [Page 1]


Internet-Draft                    pLFA                         July 2019


   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.  A Note on the term IPFRR  . . . . . . . . . . . . . . . .   3
   2.  PPR Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Preferred Path LFA (pLFA) Deployment Advantages . . . . . . .   4
   4.  Simple Repair Using pLFA  . . . . . . . . . . . . . . . . . .   6
     4.1.  Link Repair . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Node Repair . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Shared Risk Link Groups . . . . . . . . . . . . . . . . .   8
     4.4.  Local Area Networks . . . . . . . . . . . . . . . . . . .   9
     4.5.  Multiple Independent Failures . . . . . . . . . . . . . .   9
     4.6.  Multi-homed Prefixes  . . . . . . . . . . . . . . . . . .   9
     4.7.  ECMP  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Repair To A Traffic Engineered Alternate Path . . . . . . . .  10
   6.  Use of a Repair Graph . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Single Repair Graph . . . . . . . . . . . . . . . . . . .  11
     6.2.  Multiple Disjoint Graphs  . . . . . . . . . . . . . . . .  11
   7.  Centralized and Decentralized Approaches  . . . . . . . . . .  13
   8.  Independence of operation . . . . . . . . . . . . . . . . . .  14
   9.  Data-plane Considerations . . . . . . . . . . . . . . . . . .  14
     9.1.  Traditional IP  . . . . . . . . . . . . . . . . . . . . .  15
     9.2.  Segment Routing over an IPv6 Data Plane (SRv6)  . . . . .  15
     9.3.  MPLS  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   10. Loop Free Convergence . . . . . . . . . . . . . . . . . . . .  16
   11. OAM Considerations  . . . . . . . . . . . . . . . . . . . . .  16
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  16
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  17
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     15.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   Preferred Path Routing (PPR)
   [I-D.chunduri-lsr-isis-preferred-path-routing] is a method of
   introducing explicit paths to a network.  Such a path may be any
   loop-free path between two points in the network that satisfies the
   need for which the path was created.  The PPR path is not constrained
   to be the shortest path between any points in the network, although



Bryant, et al.           Expires January 3, 2020                [Page 2]


Internet-Draft                    pLFA                         July 2019


   the use of shortest path segments is provided for in order to
   compress the size of the path description flooded by the routing
   protocol.  The advantages of PPR over alternate methods of creating
   such paths is described in
   [I-D.chunduri-lsr-isis-preferred-path-routing].

   A packet is carried over the network in an appropriate form using the
   Preferred Path Routing Identifier (PPR-ID) as the data plane
   identifier to map the packet to the PPR path, and hence the resources
   and next-hop (NH).  One way of adding a PPR-ID to a packet would be
   to encapsulate it, but PPR does not restrict the user to the use of
   encapsulation.  How the PPR-ID is carried in the general case is
   outside the scope of this document.  Various methods of adding the
   PPR-ID to a packet for the purposes of Fast-Reroute (FRR) are
   described in Section 9.

   IP Fast Re-route (IPFRR) Section 1.1 and the methods known at the
   time of its writing is described in [RFC5714].  A number of later
   methods are described in [RFC6981], [RFC7490], [RFC7812] and
   [I-D.ietf-rtgwg-segment-routing-ti-lfa].

   This document is a framework describing various methods whereby PPR
   can be used to provide IP Fast Reroute (IPFRR) paths.  PPR can
   provide IPFRR in a number of ways.

   o Signaling pre-computed preferred alternatives for the primary path
   o Signaling individual segments on the repair path.  o Selective
   overriding of locally computed Loop Free Alternates (LFA) for the NH
   failure.  o Local repair to a Traffic Engineered paths avoiding the
   need for multi-hop Bidirectional Forwarding Detection (BFD)
   [RFC5880].  o Micro-loop elimination [RFC5715].

   These are described in more detail within this memo.

1.1.  A Note on the term IPFRR

   The term IP fast re-route (IPFRR) was adopted by the IETF as the
   general name for best-effort Fast Re-route (FRR) in best effort IP
   and MPLS networks.  This was to distinguish this new work from the
   then established FRR as described in [RFC4090] which uses RSVP
   Traffic Engineered (RSVP-TE) MPLS paths [RFC3936].

   Within this document the terms IPFRR and FRR are used
   interchangeably.







Bryant, et al.           Expires January 3, 2020                [Page 3]


Internet-Draft                    pLFA                         July 2019


2.  PPR Overview

   PPR works by injecting into the network a path or a graph and a
   corresponding forwarding identifier (PPR-ID).  A node examines each
   PPR path description and if it is on the path it inserts into the
   Forwarding Information Database (FIB) an entry for the PPR-ID with
   the next hop as either the next entry along the PPR path, or if a
   loose path is specified, the next hop on the shortest path to the
   next hop along the PPR path.  This is described in
   [I-D.chunduri-lsr-isis-preferred-path-routing].

   PPR also has the ability to inject into a network a tree rooted at a
   node identified a PPR-ID.  This is described in
   [I-D.ce-lsr-ppr-graph].  This graph mechanism provides a compact
   representation of a set of paths to a given PPR-ID.  This works in a
   similar manner to the linear path case, in which a node on the graph
   inserts a FIB entry for the PPR-ID with the next hop as either the
   next node in the graph, or the next hop on the shortest path to the
   next node in the graph.  Clearly the graph needs to be a spanning
   tree and must not contain a cycle.

   In the description of the FRR methods provided in the text, the term
   encapsulation (and decapsulation) is frequently used in connection
   with the addition (and removal) of a PPR-ID to be used by the
   forwarding later to identify to the forwarders the PPR path that the
   packet needs to traverse to be follow the repair path.  Encapsulation
   is only one of a number of methods that can be used and is used in
   this memo as a convenience without loss of generality.  For more
   information see Section 9.

3.  Preferred Path LFA (pLFA) Deployment Advantages

   PPR allows the construction of arbitrary engineered backup paths.  In
   this respect it is like similar to RSVP-TE and Topology Independent
   Loop-Free Alternates (TI-LFA)
   [I-D.ietf-rtgwg-segment-routing-ti-lfa].  However, unlike those
   approaches PPR is applicable to any forwarding plane.  For example,
   it is possible to support MPLS, both IPv4 and IPv6 and Ethernet.

   Like Segment Routing (SR) [RFC8402], PPR uses extensions to the
   existing IGP, however, unlike SR, PPR requires no extension to the
   data plane.  Again, unlike SR, which requires a Segment Identifier
   (SID) in the network layer header for every non-shortest path
   forwarding instruction, an arbitrary path does not require expansion
   of the user data packet beyond that needed for the initial insertion
   of the PPR-ID.  This mitigates the MTU stress that SR introduces to
   the network.




Bryant, et al.           Expires January 3, 2020                [Page 4]


Internet-Draft                    pLFA                         July 2019


   PPR based IPFRR supports 100% failure coverage similar to RSVP-TE
   [RFC4090], TI-LFA, Maximally Redundant Trees (MRT) [RFC7812] and Not-
   Via [RFC6981].  It does not have the coverage restrictions that apply
   to Loop-Free Alternate (LFA) [RFC5286] and Remote LFA (RLFA)
   [RFC7490].

   Shared Risk Link Groups (SRLGs) make it more difficult find repairs
   in LFA and RLFA reducing repair coverage.  TI-LFA can address this,
   but only at a cost of expanding the number of SIDs and hence the
   packet size.

   Supporting multiple concurrent failures is difficult in all of the
   IPRFF approaches except MRT, which can repair two concurrent
   failures.  However unlike MRT, which is constrained by its network
   wide algorithm, PPR allows individual, arbitrary repair paths to
   instantiated, for any failure.

   In the current TI-LFA design, priority is given to repairing
   connectivity rather than conforming to the operator traffic policy.
   A PPR based FFR approach can apply policy to the repaired traffic,
   including, if required multiple policies to an individual failure.

   One of the main advantages of TI-LFA compared to other IPFRR
   approaches is that it creates repair paths that are congruent with
   the post convergence path from the Point of Local Repair (PLR)
   [RFC4090] to the destination.  These paths, which may be longer than
   strictly necessary to reach Q-space [I-D.bryant-ipfrr-tunnels], stop
   micro-loops from forming along the repair path during re-convergence.
   PPR can also create these congruent paths without the need to
   introduce SR into the network.

   One of the limitations in TI-LFA, RLFA and LFA is that they do not
   have a method of selectively creating alternative next-hops or indeed
   full repair paths based on policy, or traffic engineering information
   known to the operator.  PPR provides a simple way to inject arbitrary
   paths.  It may therefore be used to enhance an existing LFA/RLFA/TI-
   LFA IPFRR enabled network by selectively injecting paths to provide a
   repair for business critical links with a policy in the PLR that
   where provided a PPR path should be preferred over a local calculated
   LFA based paths.

   PPR is applicable to both centralized and PLR computed repair paths
   each of which has advantages in different circumstances.  A centrally
   computed repair path only requires interaction with one network node
   which then floods the instruction.  This differs from the normal SDN
   approach which requires interaction with all of the nodes along the
   path and RSVP-TE which requires interaction with at least one end-
   point of every repair.



Bryant, et al.           Expires January 3, 2020                [Page 5]


Internet-Draft                    pLFA                         July 2019


   Like TI-LFA, pLFA is based on a small extension to the IGP.  It uses
   the IGP flooding mechanism and in-built state maintenance and
   consistency checks.  This contrasts with RSVP-TE which needs its own
   separate Signaling and soft-state maintenance method.

   The requirement that the pLFA solution addresses is thus the ability
   to construct repair paths that conform to operator policy without
   data-plane changes or significant MTU increase, and without
   introducing any control plane changes other than a small addition to
   the existing IGP.

   A more detailed technical comparison between pLFA and the existing
   solutions is provided in the technical description of pLFA that
   follows.

4.  Simple Repair Using pLFA

4.1.  Link Repair

   In this, the most basic, scenario Figure 1 we assume that we have a
   path A-B-C-D that the packet must traverse.  This may be a normal
   best effort path or a traffic engineered path.

              c'
   A---B--//--C---D
       |      |
       E---F--G
           f'

                     Figure 1: Simple IPFRR Using pLFA

   PPR is used to inject the repair path B->E->F->G->C into the network
   with a PPR-ID of c'.  B is monitoring the health of link B->C, for
   example looking for loss-of-light, or using Bidirectional Forwarding
   Detection (BFD) [RFC5880].  When B detects a failure it encapsulates
   the packet to C by adding to the packet the PPR-ID for c' and sending
   it to E.  At C the packet is decapsulated and sent to D.  The path
   C->E->F->G->C may be a traffic engineered path or it may be a best
   effort path.  B may have at its disposal multiple paths to C with
   different properties for different traffic classes.  In this case
   each path to be used would require its own PPR-ID (c', c'' etc).

   In some circumstances, the repair path may be terminated at another
   point in Q-space or at a node between C and D.  For example, in
   Figure 1 if all costs are 1, F is in Q-space with respect to a B->C
   failure (F->G->C cost = 2, whilst F->E->B->C cost = 3) and thus the
   packet can safely be encapsulated and send to F with a PPR-ID of f'.
   Releasing the packet early in Q-space has two advantages, firstly the



Bryant, et al.           Expires January 3, 2020                [Page 6]


Internet-Draft                    pLFA                         July 2019


   packet can take a shorter path to its destination if one is available
   rather than traveling to the far side of the failure and then back
   tracking.

   Releasing a packet in Q-space also reduces the size of the PPR path
   that needs to be advertised, and potentially allows a repair path to
   be shared among a number of failures.  For example in Figure 2 G with
   PPR-ID g' via B->E->F->G can be used to provide an IPFRR path for the
   failure of both B->C and B->H.

              c'
   A---B--//--C---D
       |\     |
       | H--+ |
       |     \|
       E---F--G
              g'

           Figure 2: Simple IPFRR Using pLFA With Shared Repair

   Shared paths are useful in reducing the number of PPR paths that need
   to be flooded to support FRR.

   Note that where the packet takes the shortest path to the point in
   Q-space that is closest to the destination, it will be taking a path
   that is congruent with the post convergence path from the PLR to the
   destination.  This is the path that TI-LFA chooses to avoid its loop-
   free convergence.  However this is not the only loop-free strategy
   available to a pLFA based solution.

4.2.  Node Repair

   Consider the network fragment shown in Figure 3 taken from
   [I-D.bryant-ipfrr-tunnels], and consider that node A needs to deal
   with the possible failure of node E.
















Bryant, et al.           Expires January 3, 2020                [Page 7]


Internet-Draft                    pLFA                         July 2019


           Repair S-E
         +----------------+
         |                |
         | Repair S-S  s1'|
         |+---------->[S1]|
         ||            |  /
         ||            | /
         ||            |/e'         s2'
   ----->[S]----//-----[E]---------[S2]
         ||            |           ^
         ||            |           |
         ||Repair S-S3 |           |
         |+---------->[S3]         |
         |             s3'         |
         +-------------------------+
           Repair S-S2

                   Figure 3: Simple IPFRR - Node Failure

   Node S needs the use of four repair paths to address the failure of
   node E, one repair to each of E's neighbours for which E is on the
   path to that neighbour.  In Figure 3 there are three of these next-
   next-hop repairs, noted as Repair S-Sx in the figure.  In addition a
   repair to E (Repair S->E) using a path other than along the path S-E>
   should be installed for traffic to E on the basis that the problem
   may be a failure of link S->E rather than a failure of the node.

   The three repair paths to the next-next-hops of E can be installed as
   PPR path S-Sx with a PPR-ID of sx'.  The link repair for E a PPR path
   to E which avoids link S-E with a PPR-ID of e'.

4.3.  Shared Risk Link Groups

   A shared risk link group (SRLG) is a set of links that are believed
   to have some systematic connection such that when one fails there is
   a high probability of all of them failing.  This occurs, for example,
   where all of the members of the group run in a common cable duct.
   Where this relationship is known, and the simultaneous failure does
   not partition the network,PPR can install paths such that all members
   of the SRLG are avoided. pLFA has fewer constraints than other
   methods in constructing arbitrary repair paths in the network.
   [RFC6981] Section 6.1 describes the SRLG problem as it applies to
   IPFRR. pLFA can address all of the cases described in [RFC6981].

   SRLG avoiding IPFRR paths can be complex.  Since a packet can be
   attracted towards the failure whenever it is released from a strict
   path, the repair path may need a number of segments to steer it
   safely into Q-space.  If this is done in the data-plane this can



Bryant, et al.           Expires January 3, 2020                [Page 8]


Internet-Draft                    pLFA                         July 2019


   stress the MTU.  pLFA creates the path in the control plane and its
   encapsulation is invariant with respect to the complexity of the
   path.  Furthermore, if the need to reduce the data-plane
   encapsulation side means that the repair path needs to use a sequence
   of loose hops it is necessary to determine the behaviour of each
   router on the chosen path.  This contrasts with pLFA which can
   determine the path using whatever metrics and policy is appropriate,
   and then simply impose it without any data-plane overhead beyond that
   needed for a simple repair.

4.4.  Local Area Networks

   LANs are a special type of SRLG and are solved using the SRLG
   mechanisms outlined above.  With all SRLGs, there is a trade-off
   between the sophistication of the fault detection and the size of the
   SRLG.  [RFC6981] Section 6.2 describes the LAN problem as it applies
   to IPFRR. pLFA can address all of the cases described in [RFC6981].

4.5.  Multiple Independent Failures

   The Multiple Independent Failure cases described in [RFC6981]
   Section 6.3 will be analyzed in a future version of this document.

4.6.  Multi-homed Prefixes

   The Multi-Homed Prefix (MHP) problem is described in [RFC5286]
   Section 6.1, [RFC6981] Section 5.3 and [RFC8518].  MHP will be
   addressed in a future version of this document.

4.7.  ECMP

   Equal Cost Multi-Path (ECMP) is a consideration in any IPFRR method
   that does not use strict paths, and can be both an opportunity and
   threat.  It is an opportunity in that it allows for the repair
   traffic to be distributed over a number of alternative paths to
   minimize congestion.  If a loose pLFA path is injected into the
   network, then any available ECMP paths that fulfill the PPR path
   constraints can be installed following the same procedure used in
   normal IGP path computation.

   However, care must be taken that a packet is not in a position where
   it is released from a repair at an ECMP point such that one of the
   ECMP paths is back via the failure.  This can never happen if the
   correct definition of Q-space [RFC7490] is used in calculating the
   repair path.






Bryant, et al.           Expires January 3, 2020                [Page 9]


Internet-Draft                    pLFA                         July 2019


5.  Repair To A Traffic Engineered Alternate Path

   In this approach there are two traffic engineered paths from A to D
   (Figure 4.

                     d'
   A-??-B--??--C--??-D
   |    |      |     |
   E----F------G-----+

               Figure 4: Traffic Engineered IPFRR Using pLFA

   The primary path A->B->C->D is protected by a traffic engineered path
   A->F->G->D (PPR-ID d') with traffic engineered connectors from B
   (B->F) and C (C->G).  The path A->F->G->D and its connectors can be
   created and injected by any node with access to the IGP, but it is
   more likely to be created by a traffic engineering controller.

   If link B->C fails, B re-routes packets destined for D to the traffic
   engineered path A->F->G->D via connector B->F.  It does this by
   encapsulating the packet with a PPR-ID of d'.

   Clearly there is nothing special needed to get the packet from B to F
   as they are adjacent but if there is a node say X on the path from B
   to F an explicit path needs to be created from B to F via X.
   Normally the repair would be created as a single PPR path (i.e.
   B->F->G->D) with a PPR-ID of d'.  In this approach the repair from A
   would be A->F->G->D with a PPR-ID of d' also.  Similarly C-G-D would
   again share the PPR-ID d'.

   If preferred the repair path could also be constructed using double
   encapsulation or using an SR approach in which the first segment was
   B-F with a PPR-ID/SID f' and the second segment was F-D with PPR-ID
   of d'.

   In the example shown in Figure 4 the proposed B-//->C protection path
   was B->F->G->D.  This is node protecting on C since the repair path
   avoids C.  Although link failures tend to be more common than node
   failures some critical applications would prefer node protection
   where possible.  Node avoidance may not be possible within the
   network, and may come at a cost of increased path repair path length.
   However, whether to include node protection and as what cost to
   accept its inclusion is a matter of network operator policy.

   The repair constructed in this section required the inclusion of a
   set of PPR defined links to construct the repair.  PPR has the
   ability to construct graphs [I-D.ce-lsr-ppr-graph] which can simplify




Bryant, et al.           Expires January 3, 2020               [Page 10]


Internet-Draft                    pLFA                         July 2019


   the specification of the required repair topology.  This is discussed
   in Section 6.

6.  Use of a Repair Graph

   PPR has the ability to inject graphs into a network as well as linear
   paths [I-D.ce-lsr-ppr-graph].  PPR graphs specify the paths from a
   set of nodes to a single node, and are a compact method of
   representing a set of paths to that destination with shared
   properties.

6.1.  Single Repair Graph

   In [I-D.ce-lsr-ppr-graph] the S bit in the PPR Path Description
   Element (PDE) specifies that a a network node is a Source and a D bit
   specifies that it is a destination.  A graph with all S bits set on
   the leaves and a D bit on the root is a unidirectional tree.

                     d'
   S    S      S     D
   A-??-B--??--C--??-D
   |    |      |     |
   E----F------G-----+

                      Figure 5: pLFA using PPR Graphs

   Consider the network fragment shown in Figure 5.  A graph with a PPR-
   ID d' is constructed attaching each of the nodes A, B, and C to D.
   Should any of the nodes A, B or C fail the packet can be forwarded on
   the PPR graph to D with the PPR-ID of d'.  In the unidirectional
   repair graph A, B, and C are all sources (signaled with the S bit
   set), and D is the only destination (signaled with the D bit set.

6.2.  Multiple Disjoint Graphs

   Consider Figure 1 from [RFC7812] which illustrates the problem of
   IPFRR in a network that is 2-connected.














Bryant, et al.           Expires January 3, 2020               [Page 11]


Internet-Draft                    pLFA                         July 2019


   [E]---[D]---|           [E]<--[D]<--|             [E]-->[D]---|
    |     |    |            |     ^    |                    |    |
    |     |    |            V     |    |                    V    V
   [R]   [F]  [C]        r'[R]   [F]  [C]        r''[R]    [F]  [C]
    |     |    |                  ^    ^             ^      |    |
    |     |    |                  |    |             |      V    |
   [A]---[B]---|           [A]-->[B]---|             [A]<--[B]<--|

         (a)                     (b)                         (c)
   a 2-connected graph     Blue Tree towards R     Red Tree towards R

                      Figure 6: A 2-Connected Network

   Figure 6(a) is the full network, and Figure 6(b) and (b) are two
   corresponding redundant trees from [RFC7812].  Using the Red and Blue
   trees towards R every node has at least two paths to R.  We give R a
   PPR-ID of r' in the Blue tree and a PPR-ID of r'' in the Red tree.  R
   is the only destination in the PPR graph (D bit set), but all other
   nodes are sources (S bit set).  For clarity this bit setting is not
   shown in Figure 6.

   It is worth noting what happens at nodes B and D in Figure 6(b).  B
   is an ECMP to D via F and C.  What happens at node B is a matter of
   implementation and operator preference.  Either B can choose one of
   the next-hops, or it use them as an ECMP pair.  It can also use the
   availability of the pair to protect against B->F or B->C being an
   unexpected SRLG with respect to link A->R.  D is a merge point for
   traffic destined for r' arriving from F and from C.  It simply
   forwards the traffic to r' as normal.  Similarly in Figure 6(c) D can
   sent traffic to r'' via F or C.

   Whilst in this example the Red and Blue trees use exactly the same
   links and nodes used by the main topology, a repair graph could use
   available nodes and links outside this network fragment.

   Now consider Figure 2 from [RFC7812] which illustrates the problem of
   IPFRR in a network that is not 2-connected.














Bryant, et al.           Expires January 3, 2020               [Page 12]


Internet-Draft                    pLFA                         July 2019


                  [E]---[D]---|     |---[J]
                   |     |    |     |    |
                   |     |    |     |    |
                  [R]   [F]  [C]---[G]   |
                   |     |    |     |    |
                   |     |    |     |    |
                  [A]---[B]---|     |---[H]

                 (a) a graph that is not 2-connected

   [E]<--[D]<--|         [J]        [E]-->[D]---|     |---[J]
    |     ^    |          |                |    |     |    ^
    V     |    |          |         r''    V    V     V    |
   [R]   [F]  [C]<--[G]   |         [R]   [F]  [C]<--[G]   |
   r'     ^    ^     ^    |          ^     |    |          |
          |    |     |    V          |     V    |          |
   [A]-->[B]---|     |---[H]        [A]<--[B]<--|         [H]

    (b) Blue Tree towards R          (c) Red Tree towards R

                Figure 7: A Network That Is Not 2-Connected

   Again there are two paths (with PPR-IDs r' and r'') to R from all
   nodes except that G, J and H all depend on link G->C and node C which
   is a single point of failure in the network.

   Again note that B in the Blue tree and D in the Red tree has two
   paths to r' and r'' respectively that it may use according to
   configuration or preference.

7.  Centralized and Decentralized Approaches

   pLFA paths can be established through both centralized and
   decentralized approaches.

   A centralized system has a more holistic view of the network and its
   policies, its resource constraints and resource usage.  A
   decentralized system is inherently more resilient to failure and is a
   good fit where the network is a simple best effort network as is
   commonly deployed.

   A centralized system gathers the network state, just as any SDN
   system does, and computes the FRR paths needed.  However, unlike
   normal SDN operation where the controller needs to individually
   instruct every entity on the path for every path, in a PPR network it
   is only necessary to inject the PPR path at one point.  In practice,
   for reliability, it would inject the PPR paths in a small number of
   places, and the naturally reliability of the IGP would ensure the



Bryant, et al.           Expires January 3, 2020               [Page 13]


Internet-Draft                    pLFA                         July 2019


   complete distribution of the paths.  Furthermore, the system
   collecting the network state would naturally send the PPR LSPs back
   to the SDN controller providing quality assurance that the FRR paths
   had been distributed.

   In a decentralized approach the pLFA path is computed within the
   network, normally by the PLR.  Further details of this approach will
   be provided in a future version of this document.

8.  Independence of operation

   Each PPR path is independent of all other paths in the network.  This
   means that there is no constraint on how the path is calculated, and
   a different algorithm can be used on every path.  Some of the other
   FRR approaches have this property, but not all.  For example LFA is
   constrained by the properties of the base IGP as to a large degree is
   RLFA.  PPR can incorporate best effort segments if required, but from
   a data-plane perspective there is no advantage in doing so.  In this
   case there is a dependence on the path choice in the base routing
   protocol.

   MRT and Not-Via can use any algorithm to calculate the repair, but it
   needs to be common across the network, although the expectation in
   the case of Not-Via is that the algorithm would be a Dijkstra based
   SPF calculation.  In both these cases to change the algorithm would
   require turning off FRR for the whole network, re-configuring and
   then restarting FRR.

   RSVP-TE based FRR can specify any path, but at the cost of
   maintaining the soft-state.

   A PLR in a TI-LFA or any SR based approach can also compute paths
   independent of each other, but they tend to need to do this as a
   concatenation of a series of shortest paths in order to reduce the
   number of SIDs they need to form the path.  TI-LFA is thus highly
   dependent on the underlying best effort paths.

   pLFA can be used as a method of converting classic LFA or RLFA to
   full coverage by providing the paths that these methods are unable to
   support, or to provide any the sub-paths needed to reduce the number
   of TI-LFA SIDs.

9.  Data-plane Considerations

   This section is a survey of a number of data-planes in each case
   considering how a PPR-ID could added to map the packet to required
   FRR path.




Bryant, et al.           Expires January 3, 2020               [Page 14]


Internet-Draft                    pLFA                         July 2019


9.1.  Traditional IP

   Where the data-plane is "traditional" IP the user packet needs to be
   encapsulated such that the outer IP address is the PPR-ID.  Any
   preferred encapsulation can be used such as: IP in IP, IP in GRE, or
   IP in UDP.

   The tunnel capabilities of a node can be advertised using the method
   described in [I-D.xu-isis-encapsulation-cap] allowing different
   tunnel types to be used for different PPR paths, depending on the
   capability of the various nodes in the network.

   A common operational issue with this type of encapsulation for IPFRR
   has been the shortage of IP addresses.  However this is not an issue
   in an IPv6 network.

9.2.  Segment Routing over an IPv6 Data Plane (SRv6)

   Where the data-plane is SRv6 [I-D.ietf-6man-segment-routing-header]
   pLFA would be used to steer a packet towards the next segment end-
   point.  Clearly an extra level of IP encapsulation could be used
   Section 9.1, but that expands the packet by adding at least 36
   octets.

   Where the packet is a "traditional" IP packet, and the repair end-
   point is SRv6 capable, an alternative to the methods described in
   Section 9.1 is to insert an SRH into the IP packet setting the SID in
   the SRH to the original packet DA and replacing the outer DA with the
   PPR-ID.  If this method is used the semantics of the PPR-ID must
   include the reconstruction of the packet, by replacing the DA with
   the original DA retrieved from the SRH and the removal of the SRH.

9.3.  MPLS

   Where the data-plane is MPLS any encapsulation needed is tiny (a
   label push), but the exact action depends on the repair strategy, and
   there is the usual FRR problem of the setting of the new value for
   the top label prior to pushing the PPR-ID label.

   Where the FRR path terminates at an MPLS node other than the network
   egress provider edge (PE) in the type of pLFA repair described in
   Section 4, the original top label needed to be set to the label the
   node was expecting.

   Consider the network fragment shown in Figure 1.  This is straight
   forward case because node B swaps the top label the label it would
   have used without the failure and then pushes the label that
   corresponds to c'.  If the repair strategy had been to exit Q-space



Bryant, et al.           Expires January 3, 2020               [Page 15]


Internet-Draft                    pLFA                         July 2019


   at the earliest opportunity for example at F, then B would have
   needed to know what label F required to reach the destination.  A
   very similar problem occurs when a node repair is undertaken
   Figure 3, where S needs to know the label that the next-next-hops
   (S1, S2 and S3) need to reach the destination.

   Where the traffic is being moved to a new path terminating at the
   egress PE as shown in Figure 4, the problem much simpler and only
   requires the swapping of the top label with the label that represents
   d'.

10.  Loop Free Convergence

   Whilst IPFRR puts in place a temporary network repair, eventually the
   network needs to re-converge around the surviving network components.
   During this phase there is a danger that micro-loops will form and
   disrupt the traffic flowing across the network.  A similar problem
   can occur when the failed component returns to service, or when a new
   component is introduced into the network.  [RFC5715] describes the
   problem of loop-free convergence in detail and examines the methods
   known at the time of its writing.  Since that time [RFC8333] has
   proposed a timer based loop mitigation (but not elimination) process,
   and [I-D.ietf-rtgwg-segment-routing-ti-lfa] has proposed that by
   making the IPFRR path congruent with the post convergence path loops
   can be eliminated along the repair path.  However whilst these
   mitigation techniques address component failure, neither are targeted
   at the repair/new component case.

   These problems only effect best effort paths and path segments, fully
   defined paths do not have this problem.

   A network using pLFA is compatible with all of the know loop-free
   convergence and loop mitigation approaches.

11.  OAM Considerations

   PPR may also be used in a way that provides an alternative to running
   multi-hop BFD from ingress on a traffic engineered (TE) path with
   reducing the complexities that arise from echo reply false alarms.
   In this use case pLFA works by locally detecting the failure and
   transferring the traffic to preferred TE backups which are in time
   replaced by the newly computed TE paths to the same PPR-ID.

12.  Privacy Considerations

   As noted in Section 13 pLFA paths are constrained by the routing
   domain and thus the traffic will be no more subject to observation
   than it would in normal operation.  Indeed PPR has the capability to



Bryant, et al.           Expires January 3, 2020               [Page 16]


Internet-Draft                    pLFA                         July 2019


   constrain the path of the traffic more tightly than other IPFRR
   approaches.  pLFA therefore does not reduce the privacy of user
   traffic on the network.

13.  Security Considerations

   The security considerations of PPR are discussed in
   [I-D.chunduri-lsr-isis-preferred-path-routing] which in turn refers
   the reader to the security considerations of the underlying routing
   protocol and the data-plane in use.  The pLFA application of PPR to
   IPFRR introduces no additional security regarding PPR itself.

   General IPFRR security considerations are discussed in [RFC5714] and
   these apply to this solution.

   One further consideration, is the whether policy that applied to the
   original path needs to be applied to the repair path.  The decision
   is operator and application specific, however pLFA is better than
   some other IPFRR solution in that it is possible to precisely choose
   the repair path.

   IPFRR is deployed within the scope of the routing protocol that
   underpins it which limits the security vulnerability.  Furthermore it
   is unlikely that IPFRR would be deployed outside a well managed
   network.  These restrictions in-turn significantly mitigate any
   security threat.

14.  IANA Considerations

   This document makes no IANA requests.

15.  References

15.1.  Normative References

   [I-D.ce-lsr-ppr-graph]
              Chunduri, U. and T. Eckert, "Preferred Path Route Graph
              Structure", draft-ce-lsr-ppr-graph-02 (work in progress),
              May 2019.

   [I-D.chunduri-lsr-isis-preferred-path-routing]
              Chunduri, U., Li, R., White, R., Tantsura, J., Contreras,
              L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS",
              draft-chunduri-lsr-isis-preferred-path-routing-03 (work in
              progress), May 2019.






Bryant, et al.           Expires January 3, 2020               [Page 17]


Internet-Draft                    pLFA                         July 2019


15.2.  Informative References

   [I-D.bryant-ipfrr-tunnels]
              Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP
              Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03
              (work in progress), November 2007.

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
              Routing Header (SRH)", draft-ietf-6man-segment-routing-
              header-21 (work in progress), June 2019.

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B.,
              Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
              Camarillo, "Topology Independent Fast Reroute using
              Segment Routing", draft-ietf-rtgwg-segment-routing-ti-
              lfa-01 (work in progress), March 2019.

   [I-D.xu-isis-encapsulation-cap]
              Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras,
              L., and L. Jalil, "Advertising Tunnelling Capability in
              IS-IS", draft-xu-isis-encapsulation-cap-07 (work in
              progress), October 2016.

   [RFC3936]  Kompella, K. and J. Lang, "Procedures for Modifying the
              Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936,
              DOI 10.17487/RFC3936, October 2004, <https://www.rfc-
              editor.org/info/rfc3936>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005, <https://www.rfc-
              editor.org/info/rfc4090>.

   [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>.

   [RFC5715]  Shand, M. and S. Bryant, "A Framework for Loop-Free
              Convergence", RFC 5715, DOI 10.17487/RFC5715, January
              2010, <https://www.rfc-editor.org/info/rfc5715>.



Bryant, et al.           Expires January 3, 2020               [Page 18]


Internet-Draft                    pLFA                         July 2019


   [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>.

   [RFC6981]  Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
              and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981,
              DOI 10.17487/RFC6981, August 2013, <https://www.rfc-
              editor.org/info/rfc6981>.

   [RFC7490]  Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
              So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
              RFC 7490, DOI 10.17487/RFC7490, April 2015,
              <https://www.rfc-editor.org/info/rfc7490>.

   [RFC7812]  Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
              IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
              FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
              <https://www.rfc-editor.org/info/rfc7812>.

   [RFC8333]  Litkowski, S., Decraene, B., Filsfils, C., and P.
              Francois, "Micro-loop Prevention by Introducing a Local
              Convergence Delay", RFC 8333, DOI 10.17487/RFC8333, March
              2018, <https://www.rfc-editor.org/info/rfc8333>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8518]  Sarkar, P., Ed., Chunduri, U., Ed., Hegde, S., Tantsura,
              J., and H. Gredler, "Selection of Loop-Free Alternates for
              Multi-Homed Prefixes", RFC 8518, DOI 10.17487/RFC8518,
              March 2019, <https://www.rfc-editor.org/info/rfc8518>.

Authors' Addresses

   Stewart Bryant
   Futurewei Technologies Inc

   Email: stewart.bryant@gmail.com


   Uma Chunduri
   Futurewei Technologies Inc

   Email: uchundur@futurewei.com





Bryant, et al.           Expires January 3, 2020               [Page 19]


Internet-Draft                    pLFA                         July 2019


   Toerless Eckert
   Futurewei Technologies Inc

   Email: tte+ietf@cs.fau.de















































Bryant, et al.           Expires January 3, 2020               [Page 20]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/