Skip to main content

Node Protecting R-LFA and Manageability
draft-psarkar-rtgwg-rlfa-node-protection-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Hannes Gredler , Shraddha Hegde , Harish Raghuveer
Last updated 2013-07-09
Replaced by draft-ietf-rtgwg-rlfa-node-protection, RFC 8102
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-psarkar-rtgwg-rlfa-node-protection-01
Routing Area Working Group                                P. Sarkar, Ed.
Internet-Draft                                                H. Gredler
Intended status: Standards Track                                S. Hegde
Expires: January 9, 2014                                    H. Raghuveer
                                                  Juniper Networks, Inc.
                                                            July 8, 2013

                Node Protecting R-LFA and Manageability
              draft-psarkar-rtgwg-rlfa-node-protection-01

Abstract

   The loop-free alternates computed following the current Remote-LFA
   [I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link-
   protection.  The resulting Remote-LFA nexthops (also called PQ-
   nodes), may not gaurantee node-protection for all destinations being
   protected by it.

   This document describes procedures for determining if a given PQ-node
   provides node-protection for a specific destination or not.  The
   document also shows how the same procedure can be utilised for
   collection of complete characteristics for alternate paths.
   Knowledge about the characteristics of all alternate path is
   precursory to apply operator defined policy for eliminating paths not
   fitting constraints.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

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

Sarkar, et al.           Expires January 9, 2014                [Page 1]
Internet-Draft   Node Protecting R-LFA and Manageability       July 2013

   This Internet-Draft will expire on January 9, 2014.

Copyright Notice

   Copyright (c) 2013 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
   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.

Sarkar, et al.           Expires January 9, 2014                [Page 2]
Internet-Draft   Node Protecting R-LFA and Manageability       July 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Node Protection with Remote-LFA  . . . . . . . . . . . . . . .  4
     2.1.  The Problem  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  The Solution . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Manageabilty of Remote-LFA Alternate Paths . . . . . . . . . .  8
     3.1.  The Problem  . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  The Solution . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Prior Solutions  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Advantage of this Proposal . . . . . . . . . . . . . . . .  9
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Sarkar, et al.           Expires January 9, 2014                [Page 3]
Internet-Draft   Node Protecting R-LFA and Manageability       July 2013

1.  Introduction

   The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] specification provides
   loop-free alternates that gaurantees only link-protection.  The
   resulting Remote-LFA alternate nexthops (also referred to as the PQ-
   nodes) may not provide node-protection for all destinations covered
   by the same, in case of failure of the primary nexthop node.  Neither
   does the specification provide a means to determine the same.

   Also, the LFA Manageability [I-D.ietf-rtgwg-lfa-manageability]
   document, requires a computing router to find all possible (including
   all possible Remote-LFA) alternate nexthops, collect the complete set
   of path characteristics for each alternate path, run a alternate-
   selection policy (configured by the operator), and find the best
   alternate path.  This will require the Remote-LFA implementation to
   gather all the required path characteristics along each link on the
   entire Remote-LFA alternate path.

   With current LFA [RFC5286] and Remote-LFA implementations, the
   forward SPF (and reverse SPF) is run on the computing router and its
   immediate 1-hop routers as the roots.  While that enables computation
   of path attributes (e.g.  SRLG, Admin-groups) first alternate path
   segment from the computing router PQ-node, there is no means for the
   computing router to gather any path attributes for the path segment
   from the PQ-node to destination.  Consecutively any policy-based
   selection of alternate paths will consider only the path attributes
   from the computing router up until the PQ-node.

   This document describes a procedure for determining node-protection
   with Remote-LFA.  The same procedure are also extended for collection
   of complete set of path attributes, enabling more accurate policy-
   based selection for alternate paths obtained with Remote-LFA.

2.  Node Protection with Remote-LFA

2.1.  The Problem

   To better illustrate the problem and the solution proposed in this
   document the following topology diagram from the Remote-LFA
   [I-D.ietf-rtgwg-remote-lfa], draft is being re-used with slight
   modification.

Sarkar, et al.           Expires January 9, 2014                [Page 4]
Internet-Draft   Node Protecting R-LFA and Manageability       July 2013

                                             F
                                            /
                                       S-x-E
                                      /     \
                                     A       D--G
                                      \     /
                                       B---C

                      Figure 1: Sample Ring Topology

   In the above topology, for all (non-ECMP) destinations reachable via
   the S-E link there is no standard LFA alternate.  As per the Remote-
   LFA [I-D.ietf-rtgwg-remote-lfa] alternate specifications node C being
   the PQ-node for the S-E link provides nexthop for all the above
   destinations.  Table 1 below, shows all possible primary and Remote-
   LFA alternate paths for each destination.

          +-------------+--------------+------------------------+
          | Destination | Primary Path | Remote-LFA Backup Path |
          +-------------+--------------+------------------------+
          | D           | S->E->D      | S=>A=>B=>C->D          |
          | E           | S->E         | S=>A=>B=>C->D->E       |
          | F           | S->E->F      | S=>A=>B=>C->D->E->F    |
          | G           | S->E->D->G   | S=>A=>B=>C->D->G       |
          +-------------+--------------+------------------------+

                   Table 1: Backup paths with Remote-LFA

   A closer look at Table 1 shows that, while the PQ-node C provides
   link-protection for all the destinations, it does not provide node-
   protection for destinations E and F. In the event of the node-failure
   on primary nexthop E, the alternate path from Remote-LFA nexthop C to
   E and F also becomes unavailable.  So for a Remote-LFA nexthop to
   provide node-protection for a given destination, it is mandatory
   that, the shortest path from the given PQ-node to the given
   destination must not traverse the primary nexthop.

2.2.  The Solution

   This document proposes an additional forward SPF computation for each
   of the PQ-nodes, as a mechanism to provide node-protection with
   remote LFA.  In case, a alternate selection policy has been
   configured, the mechanism proposed, shall also provide a means to
   collect complete path attributes for the alternate path via a Remote-
   LFA nexthop to a given destination.

   The additional forward SPF computation for each PQ-node, shall help
   determine, if a given primary nexthop node is on shortest paths from

Sarkar, et al.           Expires January 9, 2014                [Page 5]
Internet-Draft   Node Protecting R-LFA and Manageability       July 2013

   a given PQ-node to any given destination or not.  To determine if a
   given PQ-node provides node-protecting alternate for a given
   destination, the primary nexthop node should not be on any of the
   shortest paths from the given PQ-node to the given destination.

   Some SPF implementations may produce a list of links and nodes
   traversed on the shortest path(s) from a given root to others.  In
   such implementations, running a forward SPF rooted at a given PQ-node
   will produce a list of nodes (one per each destination), on one or
   more shortest path(s) from the PQ-node to other destinations in the
   network.  To determine whether a PQ-node provides node-protection for
   a given destination or not, the list of nodes computed from forward
   SPF run on the PQ-node, for the given destination, should be
   inspected.  In case the list contains the primary nexthop node, the
   PQ-node does not provide node-protection.  Else, the PQ-node
   guarantees node-protecting alternate for the given destination.
   Below is an illustration of the mechanism with the topology in
   Figure 1.

   +-----------+--------+------------+----------------+----------------+
   | Destinati | PQ-nod | Shortest   | Link-Protectio | Node-Protectio |
   | on        | e      | Path(PQ-no | n              | n              |
   |           |        | de to      |                |                |
   |           |        | Dest)      |                |                |
   +-----------+--------+------------+----------------+----------------+
   | D         | C      | C->D       | Yes            | Yes            |
   | E         | C      | C->D->E    | Yes            | No             |
   | F         | C      | C->D->E->F | Yes            | No             |
   | G         | C      | C->D->G    | Yes            | Yes            |
   +-----------+--------+------------+----------------+----------------+

               Table 2: Types of protection with Remote-LFA

   As seen in the above example while C is node-protecting Remote-LFA
   nexthop for D and G, it is not so for E and F, since the primary
   nexthop E is in the shortest path from C to E and F.

   Alternatively, an implementation may also run the node-protection
   condition from the LFA [RFC5286] specification with slight
   modification as shown in Figure 2 below.  PQ-nodes that does not
   qualify the condition for a given destination, does not gaurantee
   node-protection for the same.

Sarkar, et al.           Expires January 9, 2014                [Page 6]
Internet-Draft   Node Protecting R-LFA and Manageability       July 2013

         D_opt(Npq, Dst) < D_opt(Npq, Np) + Distance_opt(Np, Dst)

         - D_opt(X, Y) : Distance on most optimum path from X to Y.
         - Npq         : The PQ-node being considered.
         - Dst         : The destination being protected.
         - Np          : The primary nexthop node on shortest path
                         from computing router to destination.

            Figure 2: Node-Protection Condition for Remote-LFA

   All of the above metric costs except D_opt(Npq, Dst), can be obtained
   with forward and reverse SPFs with Np(the primary nexthop) as the
   root, run as part of the regular LFA and Remote-LFA implementation.
   The Distance_opt(Npq, Dst) metric can only be determined by the
   additional forward SPF run with Npq(PQ-node) as the root.  With
   reference to the topology in Figure 1, Table 3 below shows how the
   above condition can be used to determine node-protection with a PQ-
   node.

   +-----------+----------+--------+-------+-------+-------+-----------+
   | Destinati | Primary- | PQ-nod | D_opt | D_opt | D_opt | Condition |
   |  on (Dst) |  NH (Np) |    e   | (Npq, | (Npq, |  (Np, |    Met    |
   |           |          |  (Npq) |  Dst) |  Np)  |  Dst) |           |
   +-----------+----------+--------+-------+-------+-------+-----------+
   |     D     |     E    |    C   |   1   |   1   |   1   |    Yes    |
   |     E     |     E    |    C   |   2   |   2   |   0   |     No    |
   |     F     |     E    |    C   |   3   |   2   |   1   |     No    |
   |     G     |     E    |    C   |   2   |   2   |   1   |    Yes    |
   +-----------+----------+--------+-------+-------+-------+-----------+

          Table 3: Using Node-protecting condition for Remote-LFA

   As seen in the above example above, C does not meet the node-
   protecting inequality for destination E, and F. And so, once again,
   while C is a node-protecting Remote-LFA nexthop for D and G, it is
   not so for E and F.

   The procedure described in this document helps no more than to
   determine whether a given Remote-LFA alternate provides node-
   protection for a given destination or not.  It does not find out any
   new Remote-LFA alternate nexthops, outside the ones already computed
   by standard Remote-LFA procedure.  However, in case of availability
   of more than one PQ-node (Remote-LFA alternates) for a destination,
   and node-protection is required for the given primary nexthop, this
   procedure will eliminate the PQ-nodes that do not provide node-
   protection and choose only the ones that does.

Sarkar, et al.           Expires January 9, 2014                [Page 7]
Internet-Draft   Node Protecting R-LFA and Manageability       July 2013

3.  Manageabilty of Remote-LFA Alternate Paths

3.1.  The Problem

   With the regular Remote-LFA functionality the computing router may
   compute more than one PQ-node as usable Remote-LFA alternate
   nexthops.  Additionally a alternate selection policy may be
   configured to enable the network operator to choose one of them as
   the most appropriate Remote-LFA alternate.  For such policy-based
   alternate selection to run, all the relevant path characteristics for
   each the alternate paths (one through each of the PQ-nodes), needs to
   be collected.  The Remote-LFA alternate path through a given PQ-node
   to a given destination comprises of two path segments as follows.

   1.  Path segment from the computing router to the PQ-node (Remote-LFA
       alternate nexthop), and

   2.  Path segment from the PQ-node to the destination being protected.

   The first Path segment can be calculated from the regular forward SPF
   done as part of standard and remote LFA computations.  However
   without the mechanism proposed in this document, there is no way to
   determine the path characteristics for the second path segment.  In
   the absence of the path characteristics for the second path segment,
   two Remote-LFA alternate path may be equally preferred based on the
   first path segments characteristics only, although the second path
   segment attributes may be different.

3.2.  The Solution

   The additional forward SPF computation being proposed in this
   document shall also collect links, nodes and path characteristics
   along the second path segment.  This shall enable collection of
   complete path characteristics for a given Remote-LFA alternate path
   to a given destination.  The complete alternate path characteristics
   shall then facilitate more accurate alternate path selection while
   running the alternate selection policy.

4.  Prior Solutions

   A recent Node Protecting Remote-LFA
   [I-D.litkowski-rtgwg-node-protect-remote-lfa] draft proposes a
   solution for providing node-protection with Remote-LFA.  It requires
   the computing router to additionally run reverse SPFs rooted at the
   nextnexthop routers (i.e. all the 2-hop neighborhood) as well.  A
   simple study of standard IGP network topologies in real-life
   deployments shall reveal that, the increase in the number of required

Sarkar, et al.           Expires January 9, 2014                [Page 8]
Internet-Draft   Node Protecting R-LFA and Manageability       July 2013

   SPF computations is exponential, and can be a substantial computation
   overhead.

4.1.  Advantage of this Proposal

   Following are the advantages of the mechanism proposed in this
   document.

   o  The recent Remote-LFA node-protection document
      [I-D.litkowski-rtgwg-node-protect-remote-lfa] proposes an extra
      reverse SPF computation for each nextnexthop of the computing
      router.  The mechanism in this document proposes an extra forward
      SPF for each of the PQ-nodes.  Considering some of the standard
      IGP network topologies in real-life service-provider deployments,
      the number of nextnexthops will be substantially higher than the
      number of PQ-nodes discovered in those topologies.  Hence the
      number of additional SPFs required in the proposed mechanism in
      this document will be considerably less compared to the procedures
      outlined in [I-D.litkowski-rtgwg-node-protect-remote-lfa], and
      imply less computational overhead.

   o  Also the extra reverse SPF proposed per nextnexthop in Remote-LFA
      node-protection [I-D.litkowski-rtgwg-node-protect-remote-lfa]
      specification does not provide a means to collect the path
      characteristics for the alternate path segment from the PQ-node to
      the destination.  The additional forward SPF for each PQ-node, as
      proposed in this document facilitates the same.

5.  Acknowledgements

   Many thanks to Bruno Decraene and Stephane Litkowski for their useful
   comments.

6.  IANA Considerations

   N/A. - No protocol changes are proposed in this document.

7.  Security Considerations

   This document does not introduce any change in any of the protocol
   specifications.  It simply proposes to run an extra SPF rooted on
   each PQ-node discovered in the whole network.

8.  References

Sarkar, et al.           Expires January 9, 2014                [Page 9]
Internet-Draft   Node Protecting R-LFA and Manageability       July 2013

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [I-D.ietf-rtgwg-lfa-manageability]
              Litkowski, S., Decraene, B., Filsfils, C., and K. Raza,
              "Operational management of Loop Free Alternates",
              draft-ietf-rtgwg-lfa-manageability-00 (work in progress),
              May 2013.

   [I-D.ietf-rtgwg-remote-lfa]
              Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
              Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02
              (work in progress), May 2013.

   [I-D.litkowski-rtgwg-node-protect-remote-lfa]
              Litkowski, S., "Node protecting remote LFA",
              draft-litkowski-rtgwg-node-protect-remote-lfa-00 (work in
              progress), April 2013.

   [RFC5286]  Atlas, A. and A. Zinin, "Basic Specification for IP Fast
              Reroute: Loop-Free Alternates", RFC 5286, September 2008.

Authors' Addresses

   Pushpasis Sarkar (editor)
   Juniper Networks, Inc.
   Electra, Exora Business Park
   Bangalore, KA  560103
   India

   Email: psarkar@juniper.net

   Hannes Gredler
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: hannes@juniper.net

Sarkar, et al.           Expires January 9, 2014               [Page 10]
Internet-Draft   Node Protecting R-LFA and Manageability       July 2013

   Shraddha Hegde
   Juniper Networks, Inc.
   Electra, Exora Business Park
   Bangalore, KA  560103
   India

   Email: shraddha@juniper.net

   Harish Raghuveer
   Juniper Networks, Inc.
   Electra, Exora Business Park
   Bangalore, KA  560103
   India

   Email: hraghuveer@juniper.net

Sarkar, et al.           Expires January 9, 2014               [Page 11]