One document matched: draft-psarkar-rtgwg-rlfa-node-protection-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-psarkar-rtgwg-rlfa-node-protection-00" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Node Protecting Remote-LFA and Manageability</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author initials="P." surname="Sarkar" fullname="Pushpasis Sarkar" role="editor">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Electra, Exora Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>psarkar@juniper.net</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Electra, Exora Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>shraddha@juniper.net</email>
</address>
</author>
<author initials="H." surname="Raghuveer" fullname="Harish Raghuveer">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Electra, Exora Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>hraghuveer@juniper.net</email>
</address>
</author>
<date day="8" month="July" year="2013"/>
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<keyword>LFA</keyword>
<keyword>Remote-LFA</keyword>
<keyword>IGP</keyword>
<keyword>Node Protection</keyword>
<abstract>
<t>The loop-free alternates computed following the current
<xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref>
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.</t>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The <xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref>
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.</t>
<t>Also, the <xref target="I-D.ietf-rtgwg-lfa-manageability">
LFA Manageability</xref> 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.</t>
<t>With current LFA <xref target="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.</t>
<t> 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.</t>
</section>
<section title="Node Protection with Remote-LFA">
<section title="The Problem">
<t>To better illustrate the problem and the solution proposed in
this document the following topology diagram from the
<xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref>,
draft is being re-used with slight modification.</t>
<figure anchor="ring-topology" title="Sample Ring Topology">
<artwork>
F
/
S-x-E
/ \
A D--G
\ /
B---C
</artwork>
</figure>
<t>In the above topology, for all (non-ECMP) destinations reachable via
the S-E link there is no standard LFA alternate. As per the
<xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref> alternate
specifications node C being the PQ-node for the S-E link provides
nexthop for all the above destinations. <xref target="table1"/>
below, shows all possible primary and Remote-LFA alternate paths for each
destination.</t>
<texttable anchor="table1" title="Backup paths with Remote-LFA">
<ttcol align="left">Destination</ttcol>
<ttcol align="left">Primary Path</ttcol>
<ttcol align="left">Remote-LFA Backup Path</ttcol>
<c>D</c>
<c>S->E->D</c>
<c>S=>A=>B=>C->D</c>
<c>E</c>
<c>S->E</c>
<c>S=>A=>B=>C->D->E</c>
<c>F</c>
<c>S->E->F</c>
<c>S=>A=>B=>C->D->E->F</c>
<c>G</c>
<c>S->E->D->G</c>
<c>S=>A=>B=>C->D->G</c>
</texttable>
<t>A closer look at <xref target="table1"/> 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. </t>
</section>
<section title="The Solution">
<t>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.</t>
<t>The additional forward SPF computation for each PQ-node, shall
help determine, if a given primary nexthop node is on shortest paths
from 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.</t>
<t>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 <xref target="ring-topology"/>.</t>
<texttable anchor="table2" title="Types of protection with Remote-LFA">
<ttcol align="left">Destination</ttcol>
<ttcol align="left">PQ-node</ttcol>
<ttcol align="left">Shortest Path(PQ-node to Dest)</ttcol>
<ttcol align="left">Link-Protection</ttcol>
<ttcol align="left">Node-Protection</ttcol>
<c>D</c>
<c>C</c>
<c>C->D</c>
<c>Yes</c>
<c>Yes</c>
<c>E</c>
<c>C</c>
<c>C->D->E</c>
<c>Yes</c>
<c>No</c>
<c>F</c>
<c>C</c>
<c>C->D->E->F</c>
<c>Yes</c>
<c>No</c>
<c>G</c>
<c>C</c>
<c>C->D->G</c>
<c>Yes</c>
<c>Yes</c>
</texttable>
<t>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.</t>
<t>Alternatively, an implementation may also run the node-protection
condition from the LFA <xref target="RFC5286"/> specification with
slight modification as shown in <xref target="node-prot-ineq"/>
below. PQ-nodes that does not qualify the condition for a given
destination, does not gaurantee node-protection for the same.</t>
<figure anchor="node-prot-ineq"
title="Node-Protection Condition for Remote-LFA">
<artwork>
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.
</artwork>
</figure>
<t>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 <xref target="ring-topology"/>,
<xref target="table3"/> below shows how the above condition can be used
to determine node-protection with a PQ-node.</t>
<texttable anchor="table3"
title="Using Node-protecting condition for Remote-LFA">
<ttcol align="center">Destination (Dst)</ttcol>
<ttcol align="center">Primary-NH (Np)</ttcol>
<ttcol align="center">PQ-node (Npq)</ttcol>
<ttcol align="center">D_opt (Npq, Dst)</ttcol>
<ttcol align="center">D_opt (Npq, Np)</ttcol>
<ttcol align="center">D_opt (Np, Dst)</ttcol>
<ttcol align="center">Condition Met</ttcol>
<c>D</c>
<c>E</c>
<c>C</c>
<c>1</c>
<c>1</c>
<c>1</c>
<c>Yes</c>
<c>E</c>
<c>E</c>
<c>C</c>
<c>2</c>
<c>2</c>
<c>0</c>
<c>No</c>
<c>F</c>
<c>E</c>
<c>C</c>
<c>3</c>
<c>2</c>
<c>1</c>
<c>No</c>
<c>G</c>
<c>E</c>
<c>C</c>
<c>2</c>
<c>2</c>
<c>1</c>
<c>Yes</c>
</texttable>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="Manageabilty of Remote-LFA Alternate Paths">
<section title="The Problem">
<t>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.</t>
<t><list style="numbers">
<t>Path segment from the computing router to the
PQ-node (Remote-LFA alternate nexthop), and</t>
<t>Path segment from the PQ-node to the destination
being protected. </t>
</list></t>
<t>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.</t>
</section>
<section title="The Solution">
<t>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.</t>
</section>
</section>
<section title="Prior Solutions">
<t>A recent <xref
target="I-D.litkowski-rtgwg-node-protect-remote-lfa">
Node Protecting Remote-LFA</xref> 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
SPF computations is exponential, and can be a substantial computation
overhead.</t>
<section title="Advantage of this Proposal">
<t>Following are the advantages of the mechanism proposed in this
document.</t>
<t><list style="symbols"> <t>The recent Remote-LFA
node-protection document
<xref target="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
<xref target="I-D.litkowski-rtgwg-node-protect-remote-lfa"/>,
and imply less computational overhead.</t>
<t>Also the extra reverse SPF proposed per nextnexthop in
<xref target="I-D.litkowski-rtgwg-node-protect-remote-lfa">
Remote-LFA node-protection</xref> 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.</t>
</list></t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>N/A. - No protocol changes are proposed in this document.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-remote-lfa-02.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-lfa-manageability-00.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-litkowski-rtgwg-node-protect-remote-lfa-00.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:22 |